Pete Dowson

If FSUIPC doesn't see the vertical modes being switched on in the AP, as in some of these sophisticated aircraft which do their own thing, then this automatic option cannot work. One way would be to "park" your trim in a non-jitter zone so it doesn't feed any conflicting values -- axes only have an effect when their values change. Another way is by programming a key or button to disconnect/reconnect the axis manually, in FSUIPC -- more below. Ideally, of course, the panel itself should do this. I think the PMDG aircraft already do so, and also any Fly-by-Wire aircraft using FSUIPC to disconnect your axes from direct control. But the 767PIC predates this, and in any case it doesn't use FSUIPC. The offset is 310A and the bit for elevator trim is bit 5 (value 32 or 0x20). Program a button or key for "Offset Byte Togglebits" offset x310a, parameter 32. Or you can have one to disconnect it and another to reconnect it -- Offset Byte SetBits and Offset Byte ClrBits, in the drop-down lists in FSUIPC. Regards, Pete

The MAGDEC.BGL (in FS2004 it's in the Scenery\BASE folder) contains all the magnetic variations as 16-bit words (0x8000 = -180 to 0x7fff <= +180) in a 360 x 180 matrix, one value per "square" degree of Lon/Lat. So it is easy enough to update if you have a good source and are handy with VB or something. Naturally, the FS values, when released, are frozen to match the state of the FS Jepp database for the airport facilities data, and navaids. Normally I think that data is frozen about one year before release, so the FS2004 values would now be over two years old and the FS2002 values over four. Regards, Pete

The single lever Prop pitch calibration is on Page 2, along with the mixture and left and right brakes. In order to use Page 5, for all the separate engine controls, you EITHER need to select "map to 4 props" on page 2, or you need to ensure that you are assigning your levers to the individual engine controls in FS's own assignments first. Have you done one of these things? Are you following the step-by-step instructions? If not, try them. If you are, which step are you stumbling on? I cannot understand how you can go wrong? Please explain. Regards, Pete

If removing FSUIPC altogether like that has no effect then it isn't FSUIPC which has anything to do with the problem. Sounds like you have something else messed up somewhere. Sorry. Most likely causes of freezes are video card drivers, corrupted weather files, some add-ons, or probably any of many other FS file corruptions. Your best bet, if you've not too many add-ons installed yet, is to completely uninstall FS2004 and start again. Don't forget to remove the FS9.CFG file in your Document and Settings folder someplace and any saved flights in your "My Documents/Flight Simulator Files" folder. If that's the complete log, all that shows is that FS is hanging during or immediately after loading data for your startup file, the default one with the Cessna by the look of it. Regards, Pete

Okay. In investigating this track versus heading business I have found two oddities. One is the error in the RMA sentence, which I don't think would be related to track or heading -- it would simply be an invalid sentence and be discarded. The other is that there are times (most times I've tested so far) where the MAGNETIC track supplied to me from the GPS part of FS is correct, whilst the TRUE track supplied is wrong, and in some cases wildly so! Note that all the standard NMEA sentences use the TRUE track, whilst the AV400 format uses Magnetic. As well as fixing the RMA sentence formatting, I have now discarded the use of the GPS True track reading and only used the Magnetic one. To provide the True track for the NMEA sentences I adjust by the Magnetic Variation, which I already know. These changes are in version 2.57 of GPSout which I will release today. As it is such a small ZIP I attach it here, too. Regards, Pete GPSout.zip

Further to the above, please now see the message I have added to your "NMEA Track" thread.

Ah, that is nice to hear. I knew it could be done!! :D Thanks, Pete

IN is the value being read from the joystick, OUT is the result of your calibrations. Those are the two values shown on the extreme left. Neither are relevant here at all. You simply click the "set" buttons above the Min/Centre (twice)/Max slots when calibrating. Don't worry about the actual numbers, you should only be concerned about the lever positions. With the extremes there are of course two values -- but one is implied, it is any value less than (for reverse) or greater than (for takeoff) the value you 'set'. The setting of a value OTHER than the extremes gives you the "dead zone" at the extremes which guarantees you can always achieve full off aqnd max thrust. Always allow leeway at either extreme. With the centre values, here used for idle, you have to click the "set" above the values twice, de-limiting the zone in which you want idle to operate. Don't rely on the lever always giving the same output when it's at the detente! All this is clearly explained, step-by-step, in the FSUIPC user documentation. Why is it confusing you, please? Jitter, temperature variation, poor electrical contact on potentiometers, all sorts of things cause that. This is precisely why you should calibrate a zone around the detente, exactly as described in the documentation! If you do not use these facilities, for precise zone definitions, then you may as well not use FSUIPC to calibrate but simply rely on the Game Controllers and FS default settings! Regards, Pete

I have no home page. If you are referring to Enrico Schiratti's "Dowson" page, there are most certainly links there to both here and to the place where you can purchase FSUIPC or WideFS. Five days is rather a long time to leave it! It does say "Personal Registration Key will be Generated and Emailed within 24 hours" on the site. After that you should fill in a "trouble ticket" (I think that's what they call it) -- this is via either the "Customer Services" link at the top of every sales page, or the "Contact Us" in the "Information" lists on the left. When you get to the Customer Service page (which you can also get to via http://www.simmarket.com ands the link at the top of the page), I think the very first selection takes you to where you can report your problem. I think that such problems are usually either a difficulty over payment, or an incorrect email -- in the latter case things go astray, of course. I think I will make a "Sticky" thread about this! :wink: Regards, Pete

Ah, I have indevertently answered this in that other thread. Could you refer there, please, to avoid duplication? Thanks. [LATER] On further investigation I have found some oddities which I will report on in this thread -- see next message. Regards, Pete

Actually, if you have a dual monitor PC and one with enough capacity to drive FS and the GPS emulator, and you either have two COM ports spare, or a USB serial adapter or two, you can simply loop the cable back to the same PC and do all this on the one PC. I expect this would work best on an Intel P4 with hyperthreading, as it seems FS only uses one of the two "virtual processors". The RMA sentence is really a subset of RMC -- its data is completely duplicated. It is just missing the date and time. You shouldn't need both. Much of the data is also reproduced in GGA (full latitude and longitude), but it does supply the altitude as extra to the others. GPSout provides the TRACK in the GPRMA and GPRMC sentences, and both TRACK and Magnetic HEADING in the GPVTG sentence. The wind details are not supplied in any of the GPSout sentences, so I don't know how the emulator is deriving the heading from the track. That is most odd. GPSout calculates the track itself using wind values unless you are using FS2004 -- then it gets the track from the built in FS GPS, which is probably a little more accurate. Perhaps you can compare values there? One thing to note: in the RMA, RMC and VTG sentences, the Track is degrees TRUE *not* magnetic, as per NMEA specification. The magnetic variation is also given. The difference in the AV400 format is that the Track is degrees Magnetic. Perhaps your observations are only a mix-up between degrees magnetic and true? If you were testing with the default FS2004 startup, i.e. at Seattle, the variation there is about 20 degrees. WARNING! In putting this together, I have just noticed that in the current version of GPSout the RMA sentence is, in fact, wrong -- it is undoubtedly being ignored in any case. I will fix this and release an update this weekend. (And, no, it isn't wrong in that it gives heading instead of track, it is simply formatted wrongly altogether). Meanwhile, take RMA out of the equation please. Regards, Pete

Designed to prevent the arming of the spoilers except by mouse? How perverse. Do they not want anyone to arm the spoilers at all, and simply failed to ignore the mouse activation? So you, yourself, don't bother to arm the spoilers, or are happy to use the mouse? Okay, thanks for the help. Regards, Pete

No, that should be okay. Although really, of course, I'd prefer that you insist that folks keep their FSUIPC up to date! (Makes support much easier! :wink: ). You could work that out from the code, as you have looked at it in any case to do the above changes. The FSUIPC_Read and _Write calls are entirely dealt with in your program, not in FSUIPC. You'd only get a FALSE return if you hadn't got a correct Open to start with, or you run out of space in the memory you provided for the transfer (or, in the case of the external library, the maximum allowed -- around 30k I think. Yes, you could do -- but the results you do get will be okay for the Reads which worked, of course. Really such errors should be found during testing, and rectified before release. Once the program is working they should not occur. I agree that the program should be bullet-proof though and the cost in extra code is minimal to leave checks in. Regards, Pete

You may need to design this for a specific aircraft, because the extent of the trim available is probably aircraft-dependent. If you want to use it with a variety you'll need to measure that value (in radians) for those and select the maximum. The it is merely a matter of simple arithmentic to scale the value. For example, if the trim varies from -0.2 to +0.2 radians and you want a range from 0 (for -ve extreme) via 128 (centre) to 255 (+ve extreme) you would need to do this: ScaledValue = (RadiansValue + 0.2) * 255 / 0.4 The "+0.2" is to get the -ve maximum to your zero, giving a Radians range of 0.0 to +0.4. Then the * 255 / 0.4 merely scales that to the range 0-255. As for the rest, I'm sorry but you need someone who knows Visual Basic. I have no idea why you are using this "currency" type when I am pretty sure VB supports double floating point numbers as a type on its own. Isn't "currency" a way of faking 64-bit FIXED POINT numbers, like the latitude/longitude, not floating point doubles like this? Are you perhaps getting confised between totally different 64 bit representations? I expect someone who knows VB will jump in. Regards, Pete

Well, I'm not sure how you are coming to that conclusion from what's been said here. However, I've just switched on my FS PC and loaded up the PMDG 700 (I don't normally use any panels at all), and you are correct in that none of the controls which should arm the spoilers will do so. Worse, it even defeats direct FSUIPC offset writes to arm the spoilers -- I use the PFC Jetliner console with a spoiler lever, and this won't arm them either. I feel sure this must be an oversight by the designers. A bug even. Have you actually tried to get a solution in the PMDG forum at all? I would expect there to be a higher proportion of PMDG flyers there than here. And either way it is certainly worth reporting to PMDG themselves as a probable bug, or certainly a serious omission. Why sorry? Key2Mouse is by Luciano Napolitano, author also of WidevieW, see http://www.wideview.it/key2mouse.htm. Regards, Pete

Well, it does help me. Thank you David. Regards, Pete

Maybe, but that is not a button/key control. Test the keystroke/control only in the air. You'd never arm the spoiler when on the ground in any case as they are triggered by a switch on the undercarriage and during takeoff roll they could deploy accidentally and cause a nasty incident. I think those aircraft which do deploy spoilers on RTO do so without any arming needed -- and, actually, I think the real 737NG deploys them without ariming on touchdown (maybe when reverse is armed, I don't recall offhand) -- perhaps the PMDG cockpit is emulating that correctly? Have you tried simply landing without arming and seeing if the spoilers are correctly deployed? Test in the air, as I said. But if this is only with the PMDG aircraft, it is likely they have taken over the operation of the spoiler and perhaps made it operate as in the real aircraft. Have you tried using it as in the real aircraft, to see? Does the PMDG package offer its own spoler controls, perhaps? Because mouse actions operate directly on the gauge which then uses a different input to the simulation engine. It doesn't emulate either keystroke or button controls, which are processed in a different way. Why are you so desperate to arm spoilers on the ground? Regards, Pete

Are you testing it whilst on the ground? If so, don't -- try it in the air only. Most of the time in FS2002 and FS2004, arming spoilers on the ground will deploy them 100% in any case. You realise also that when spoilers are used as speed brakes, in the air, they don't deploy 100%? There's a maximum flight detente at about 70% on the 737, I believe. You can only actually get 100% after touchdown. I find it best to program an axis for spoiler control so you have fine use of them as speed brakes. Anyway, back to the PMDG aircraft. Are the keypresses you are using the standard FS ones, or does PMDG do its own? In other words, what are you actually programming? Regards, Pete

Actually, I have heard of "No", but I don't seem to be all that good at using it I'm afraid! :) Regards, Pete

No. What parts of it would you expect to interface to? It's really a program which interfaces to the Traffic DLL -- i.e. a front-end user interface. If I were to implement something it would be to the part of FS which does things, not really the part which display menus, tables and maps. Have you tried the facilities at offset 2900? Regards, Pete

You had problems before? What were they? Are there errors reported in the Log? Did you check to ensure that you have a properly updated FS9.1? So far I think all these problems are a result of an FS9.1 update which did not complete correctly. See the list of changed modules in my own FS9.1 update announcement at the top of this forum and check your installation please. The DLL causing most of the problems appears to be WEATHER.DLL. It seems there's a patched version of the 9.0 DLL going around. If this was installed before you applied the FS9.1 update, then the latter will not replace it with the new one, and the result will stop FSUIPC from working. If this is the case, and it sounds like it, then I am surprised FS itself doesn't give other problems. It will certainly cause problems for many add-ons in such a mixed up state. And it won't operate as Microsoft intended it to -- you will be missing many of the improvements. I am working on trying to make FSUIPC deal with any horrible mixture of FS9.0 and FS9.1 modules, but it isn't easy, and a horror to test. And it won't make your FS work as FS9.1 should be, it would just stop people writing to me about it! :wink: Regards, Pete

I'll have a look when I've finished testing what I've done to date. If it is easy I may slip it in on this next release, but otherwise it may slip. It will get done though. Regards, Pete

Yes, that's good. Furthermore, there is absolutely no sign of Squawkbox even attempting to access FSUIPC -- so it doesn't look like it is getting that far. I don't think this can be anything to do with either your FS9.1 or FSUIPC 3.40 upgrades. Something else is bad in the Squawkbox side separate entirely from this -- unless it attempts to connect to Multiplayer before FSUIPC and that is where it is reporting this "no response"? I call that "hanging" (or "freezing" for visual things like FS). But you did say it was reporting an error, didn't you? Here: ... or did I misunderstand that? Is that a message from Windows when you try to do something, rather than a message from Squawkbox complaining about FS or FSUIPC? Yes, good idea. I'm sorry I have no idea now. You could try a fresh install of SB in case the earlier fiasco with a partially-installed FS9.1 mucked up something vital in its data files. Regards, Pete

You can only use FSUIPC 3.40 or later (when a later one exists) with an updated FS 9.1. There should be no reason for Squawkbox "crashing" -- though from what you say it isn't crashing exactly, is it? Where's the log from FSUIPC for this, please? Are you sure you registered Squawkbox as an application, using its Freeware Key, or is your FSUIPC fully user-registered? I assume you have checked the FS DLLs against the list I mentioned? Regards, Pete

Well, so far I have added: Offset Byte Cyclic Inc Offset Byte Cyclic Dec Offset Word Cyclic Inc Offset Word Cyclic Dec These four operate on specific FSUIPC offsets and allow cyclic changes between zero and an upper value. They complement the existing Offset Inc/Dec facilities but deal with cases where you need to make a choice with only one button instead of two to search up and down. Then there's a set of controls to handle the current in-use COM1, COM2, NAV1 and NAV2 frequencies (separate inc/decs for whole and fractional parts). These are for single display type devices like the GoFlight GF45 and GF46 modules, ones with no way to show both standby and in-use values. Finally, for Button programming only (not Keys at present) I've added a conditional facility based on reading FSUIPC offset byte, word or double word values. The reasons for these choices will be clear when I release the GoFlight display handling program I've developed and am testing now. This complements the FSUIPC GoFlight button programming facilities. Regards, Pete