Pete Dowson

Previous version of... GFDisplay I assume since FSUIPC wouldn't be looking at x2B00? Of course. FSUIPC is certainly okay. The variable at 2B00 is changing continuously when I turn, in FS2004. I've checked this using both the FSUIPC monitor (Logging page, right-hand side -- select "Advdisplay" option for real-time on screen updates) and using FSInterrogate. So it has to either be GFdisplay, or possibly the GFdev.dll. I wouldn't know if the problem lies with the bank angle (why would it) or the rate of turn, or even the rate of bank, but... Please, can you check it with the whiskey compass? I am going through a process of elimination. For all the values it's just a simple comparison of previous displayed value to the current value, to the number of fractional places you specify, and a half (i.e. greater than 0.5 difference for zero fractional places). By all means, try increasing the number of fractional places -- if displaying it as D33 "fixes" it, try D32 and D31, see if each needs a faster and faster rate of change. If so it points to something wrong in the way I'm storing the "previously displayed value". Okay. Good. I've not messed anything up in GFdisplay, then. If it doesn't update with 'slow' changes here, maybe it doesn't with any displays of anything? Maybe it's a 5 year old bug and no one has ever noticed? It needs testing with other variables, like the whiskey compass and so on. Please. Also, maybe its a problem with GFDEV. Try different versions of that (are you using the latest or an older one?). Regards Pete

Seems that GFdisplay isn't working properly at all then? I may have to withdraw it if so, as there's no way I can debug it here with no displays. Could it be I messed it up with my alignment changes? Can you test with the previous version? Can you also test with the Whiskey compass instead, just to make sure it isn't something strange with the FS value rather than GFdisplay? (Though if it was I don't see that re-writing the INI would magically "fix" it). Pete

Hmmm. That's strange. It shouldn't have a problem keeping up then. I'm afraid I'm at a bit of a loss on that. Did you get the same thing happening when you tried using the whiskey compass? Pete

No, sorry. The 2B00 offset is updating normally,, at the same rate as most of the other fast-update stuff in FSUIPC, and it certainly says it's the gyro compass value. If the FS panel gyro compass display isn't suffering then the problem must be that GFDisplay is not getting the processing time. A dual core CPU should fix that. Not sure how you'd do it in your PC. Regards Pete

I've just checked, and it looks pretty easy to add it to FSUIPC3 (for FS2002 and FS2004 only, not FS2000 or CFS), so I'll do that in the next increment (3.732) which I'll post in the "Other Downloads" announcement above, probably later today ... Regards Pete

It's a one-off purchase fee, per version. There are two separate versions - 3 for FS2004 and before, 4 for FSX. Please check http://www.schiratti.com/dowson where you can download the version you are interested in, and browse the User Guide which explains all. On that website there are also links to the place where you can purchase them. Prices and offsers are shown there. Regards Pete

No, but that's not relevant in any case. The gyro heading is easy in FSX because SimConnect provides it ready-made and FSUIPC4 is completely table-driven around SimConnect's variables. It isn't so easy in FS2004 because it isn't available ready-made in the same way, and each new variable "mapped" from FS2004 and before needs extra code specifically written to compute it. Eryou've got something really set up wrong for FSX if you are getting such poor performance on your PC, a 3.2 gig machine with a Radeon 9800? FSX can be made to run pretty smoothly on such a machine. I know this, I've done it. You should be able get up to 20 fps at airports, certainly rarely if ever single digits. You can't have all those sliders up full -- turn off autogen completely, and turn down Traffic or invest in a faster traffic set like MyTrafficX. There are lots of good hints on getting the most out of FSX, and they are worth following. See the FSX forum. Yes, sorry. Anyway, in FSUIPC 4.086 (or whatever the next interim release will be) I've added the gyro compass value as a 64-bit float in FSX/FSUIPC4, at offset 2B00, so it will be ready for you when you do move on to FSX! ;-) Regards Pete [/img]

That gives the magnetic heading, subject to flying level. Isn't that what you wanted? The only other headings are non-drifting exact simulated values. Is that what you want? Otherwise, for the correct gyro reading you'd have to add the drift value (a separate offset again). The same formula, though. Ah, no. For your accuracy you only need the upper half of the 0580 offset, so it's the same multiplication for both: X0582 U16 * 0.0054932 You can combine the mult/div into one number too, as shown. That's 360/65536. So, it might have been possible to allow + or - as one of the two operations, with the understanding that it would be a strict left-to-right parsing, but ... ... the big problem is having references to two offsets, both of which may change independently, in one statement. The whole (simple) way GFDisplay works is to process statements only when THE offset they depend upon changes. To make this work with two offset references is pretty much a rewrite, maybe introducing local variables to make my data structures reasonably simple. It's all geared to maximum efficiency in processing, I'm afraid, not maximum user flexibility. Anyway, I'm not sure you get anything useful this way. Unless you also added in the drift you aren't getting a proper instrument readout -- or are you making a GPS display? Perhaps you should tell me exactly what it is you are trying to do. For FSX, at least, it would certainly be much easier to provide an offset in FSUIPC4 for it -- SimConnect provides the Gyro reading directly, I just need to map it to an offset, a moment's work really. Regards Pete

Ah, wellI've just added the Tailwheel lock switch to FSUIPC4 (FSX only) in version 4.085, released here tomorrow. It is at offset 29A0. It is waiting for you! ;-) Regards Pete

Thanks again Frank! You are doing a splendid job! Best Regards Pete

I've not tried that --- it may just makes defaults, anyway, but it would be worth a try. Back up the DEVICES CFG files first. Find the section(s) corresponding to your joystick names (as shown in FS assignments dialogues) in one or other of the DEVICES CFG files, and either remove the assignments or make them into ones that don't do anything or don't matter. Sorry, I really don't have any magic solutions. I don't know why you are getting deleted assignments re-made in any case unless every time you boot it sees the joystick as a new connection? WideServer.INI too, and your FSUIPC.KEY file of course. For scenery installation there's SCENERY.CFG. Most if my hardware controls are PFC, so not using FS assignments at all but my PFC driver. The one exception is an Aerosoft (Oz) GA-28R cockpit (a Piper Arrow III) which is driving FS through FSUIPC using an Aerosoft driver. I only have "normal" joysticks, cheap gamepads and the like, for testing. In terms of add-on software, I use all the Project Magenta Boeing package, and pmSystems, pmSounds, pmInstructor, plus Radar Contact, ActiveSky, AISmooth, FSRealTime, MyTrafficX (on FSX), Ultimate Traffic (on FS9), plus most of the best scenery, texture and mesh add-ons for UK and Europe. I use Jeppesen FliteMap to prepare flight plans for the pilot, PM's CDU and Radar Contact, and FliteMap is also used as a Moving Map. On my main sim I fly the PMDG 737-700 or -800, but without any of PMDG's panel stuff -- that's alll replaced by the Project Magenta parts. The 737 cockpit is the ready-made one by PFC (see http://www.flypfc.com) which itself has 6 mini-PCs driving it, under the hood, with four further PCs networked out side the cockpit running FS itself and the assorted external add-on programs. Regards Pete

Hmmm. I've never had that sort of problem, provided the joystick stays connected. Are you using winXP? There used to be problems with USB in Win98. Otherwise all I can think is that you disable the joystick in FS altogether and use only FSUIPC. There's one FS option for that -- diable/enable joystick. You don't need to de-assign things then. Pete

This is a general problem with many functions in FS cockpits. The best way to deal with those for which you only have a toggle is to synchronise to start with. Save a Flight with all the positions known and start your cockpit that way. The offsets do sometimes (in fact many times) provide a better solution, but certainly the tailwheel lock isn't one of those. in fact no one has ever asked for it before, in the 7+ years of FSUIPC. I just checked, and it is actually readable in FSX, so I can implement an offset for it in FSUIPC4 if you wish. Not FSUIPC3 though. Regards Pete

Yes, but please read the notes. You need to remember to write the value for the magneto setting after the engine has started. Generally, the starter switch is spring-loaded, so you just release it when you have a start, and the released position should write the magneto value (generally 3 for both, but dependent upon another switch). The actual values in 0892 etc are based on a typical Cessna type keyswitch which, as rotated, goes through 0-4, with the 4 position being spring-loaded not latched. From buttons or switches you don't need to use the offsets for any of this, there are FS controls. I don't really know what you are talking about there, but there's no "bits" to set or clear here. Those offsets deal in Word values (0-4), not individual bits. FSUIPC has no such thing. There's an FS control for it listed in FSUIPC as it appears in FS's CONTROLS.DLL. I've never tried it, no idea if it works. Never known a location in FS for it. Sorry. There are many things only accessible by FS control. I'm not sure why you are getting obsessed by offsets. Try using the controls as MS intended first. ;-) Regards Pete

Hey, thank you very much! It is really appreciated! ;-) Regards Pete

Well, the PayPal account is still open (petedowson@btconnect.com), but mainly I pay for my hobby with FSUIPC and WideFS sales through SimMarket. Regards Pete

Last chance todaytry 1.222 attached. Pete GFdisplay1222.zip

Please check the revised reply. The unedited one, you replied to, was sent in error. I still want your comments on that. Incidentally, regarding your comment "I fail to see how D02 is the same as D2, I should be getting to decimal places, right?", the problem was that I convert the number after the D to decimal, so I get 2 for D02 (or D002 etc etc). I have to treat leading zeroes as a special case. Another problem I just noticed is that the converted value is stored in an 8-bit value (byte). Since this only has a capcity up to 255, it explains the "overflow" results for your D3nn tests. The only problem I think I have left is the disappearance of the leading digits as the values are shifted left. I just cannot see why that is happening by inspection of the code. :-( Regards Pete

You are replying to an earlier edit of my message, now deleted. Please read the later one. Pete

Well, no versions of GFdisplay would have ever understood Dn (one digit) properly -- it isn't really valid. The - and the X were optional, but the i and f were always necessary. That's why I asked what you thought the Dn values should do. Anyway, I've decided for you. It now needs only 1 2 or 3 digits: 1 digit = i, number of integer digits. f and s assumed zero 2 digits = if, as before, s assumed zero 3 digits = ifs, the whole nine yards. Try 1.221, up replacing the attachment earlier. Regards Pete

Maybe i'm forgetting stuff but ... ... before you had no D parameter at all (meaning what?), now you have D with one digit. Is that supposed to do something too? How do you think that is supposed to fit into the D-Xifs format? I don't understand what you intend it to mean. Just checking, yet, I do have the 100's and units digits mixed up in one place, but I'm not sure fixing that will do anything for you if you only specify one digit. What do you intend "Dn" to convey? Dn00 or D0n0 or D00n?

Hmmm. Wonder how. Reading my doc again it seems like there should be a formating code, like D30 or similar? Maybe I resort to a default. From reading the document I don't think that's possible. Well, I'd be concerned about adding new bugs, as the code is now a couple of years old and doesn't look familiar to me at all. Also, I'm not using any GF display devices at all it isn't possible to test changes here either. Maybe the Dxxxx parameter needs an extra optional value: D-Xifs where s is the number of spaces to be left after the value (i+f+s must of course be less than or equal to the capacity of the display, or one less for signed numbers). If you want to risk new bugs I could try adding code for this, but you'd have to do all the testing. Thanks. I've reproduced the earlier explanation in the Appendix, so if I ever do make a new release it will be okay. Regards Pete

Okay. Not hearing anything from you so far, I've been checking. FSUIPC supplies two separate EGT values: 08BE (a 16-bit value), where it says "Engine 1 EGT, 16384 = 860 C. [Note that for Props this value is not actually correct. You will get the correct value from 3B70. The value here has been derived by FSUIPC to be compatible with FS2004, FS2002 et cetera]" and 3B70 (a 64-bit floating point value), where it says "General engine 1 EGT in degrees Rankine, as a double (FLOAT64). Convert to Fahrenheit by Rankine – 459.67. FS default gauges show Centigrade." Now, contrary to where it says "for Props this value is not actually correct" for the first value, it is, in FSX, actually correct -- the derivation FSUIPC is supposed to do is not actually being executed. :-( I suspect that SimKits are using the 08BE value, the incorrect one, and so, now having the correct one supplied, are displaying it incorrectly, if you see what I mean! ;-) I run some comparisons between the 3B70 and 08BE values on the Cessna in FS2004, and it appears the value for Props in Fs2004 is about 2.96 times the value I am reading in 3B70. It most certainly isn't a value is degrees C scaled so that 16384 represents 860C! None of the values I read in either FS2004 or FSX semed to tie in with the Cessna's own default EGT gauge, which is difficult to read but has tiny divisions with a label saying 25C per div. The third tick (idle) seems to represent about 150C and each subsequent tick seems worth about 100C, as by the 7th or 8th (full throttle) the true EGT is up to 1554R or 1094F which is 590C. Weird. It's a bit daft havng someone like me, who doesn't know an EGT from a XYZ, testing and trying to calibrate this sort of stuff -- this is where SimKits feedback would have been, er, useful ... Anyway, I am fiddling the reading in 08BE to be just as inaccurate/wrong as it was in previous FS versions, so hopefully your gauge will show something approximating the truth (?). This will be in the next increment (probably 4.084 or 4.085) which I will post in the FSX downloads announcement above. When you have tried it, please let me know. Incidentally, the FSX Cessna seems to have slightly higher EGTs than the FS2004 one in any case, espcially when idling (152C rather than 80C). Regards Pete

No one of that name is known to me and I've certainly never had any emails from SimKits or TRC about any problems with EGT. But I was on holiday on the 15th and when I returned found my father had died on the 11th, so a lot of emails had to be processed a lot later. There's a possibility that it got swallowed in the process, even by my spam eater! However, if it was important or they had done any testing you'd think they would have asked again, wouldn't you? I would need to know which offset they are reading so I can check it. First, please make sure you are using the latest version (4.08 or 4.081). Assuming it is still wrong, you could try establishing a known EGT (from the FS panel), then logging IPC reads (FSUIPC logging page) and emailing me the log (ZIP and attach, to petedowson@btconnect.com). Tell me what FS was reading. I'll tell you when I have feedback from those who use it. Unfortunately I cannot possibly test all of the offsets for all types of aircraft, even if I understood them all. As in all previous versions of FS since Fs2000, I am completely dependent upon feedback from those who use them, and I fix any errors as they are discovered. I'm afraid TRC and Simkits, although one of the main users, seem to be generally rather poor at testing and reporting problems, at least from where I sit, and although their use of FSUIPC gives me lots of work, they don't actually pay any license fees (I wouldn't mind so much supporting them if they did! :-(. ) Regards Pete