Pete Dowson

Sorry, I don't see the point. The computation to get your 0-360 is so easy, just simple arithmetic. Why would you need any change to FSUIPC? Yes, except for the deliberate error -- the case where the pitch is < 0 should be 360 + pitch, of course, or 360 - abs(pitch). Anyway, you can test this with a simply Lua plug in. Here, copy this and save it in the FS Modules folder as "pitch.lua", then load up FS, assign a Key press to "Lua pitch" and then use that keypress to start it. Put FS into slew mode, plane horizontal (Ctrl+Space on FSX) and use the slew pitch up slow or down slow control to make it turn the whole 360 degrees and observe the values on screen: -- "Pitch" example LUA plug-in to show pitch 0-360, by Pete Dowson, January 2009 -- Loop forever: to stop this you'll have to use the LuaKill control on it. while 1 do -- Get the pitch and bank data we want to display -- (Note that it is read in one instruction, so that all values -- apply to the same FS frame) pitch, bank = ipc.readStruct(x0578, "2SD") -- and convert them from FS units to units we like pitch = pitch * 360 / (65536 * 65536) bank = bank * 360 / (65536 * 65536) -- compute 0-360 value for pitch if math.abs(bank) &gt;= 90 then realpitch = 180 - pitch elseif pitch &lt; 0 then realpitch = 360 + pitch else realpitch = pitch end -- display it all in an FS window ipc.display("pitch="..pitch.."\nbank="..bank.."\n\nrealpitch="..realpitch) -- Sleep for 50 mSecs so the update gets done roughly 20 times per second ipc.sleep(50) end Regards Pete

The log file you already sent shows nothing useful I'm afraid. Of course it was for a hang, not a crash, and for 3.82, not the current version. The procedure to narrow this down has simply got to be a process of elimination. there are too many things going on with your system normally. Something certainly has a bug in it -- a program sending invalid data to FSUIPC. I can deal with that (rejecting the data) but I would then have no idea what it would do to that program. Best to isolate it first. Pete

The current interim updates for FSUIPC, from the Announcements, allows users to assign names (only single letters, but not numbers) to their known named devices, and FSUIPC then automatically finds the correct device -- provided it still has the same name. Obviously it can't handle a name change automatically, but at least then the change that you accomplished in the assignments would simply be a change in the [JoyNames] section, to associate the joystick letter to the new names for devices. All the other sections are then unaffected. The letters can be auto-assigned by FSUIPC, or can be chosen to suit usage -- eg "R" for rudder, "J" for joystick, "Y" for Yoke, "Q" for throttle Quadrant, and so on. Regards Pete

I always reply to non-spam emails i receive, so either it got lost in one of the many outages I used to have (dodgy power cable, overhead ones disturbed easily by wind -- now fixed1) or it got seized and dumped by my ISP. Sorry. Well, Microsoft and others seem to manage with the information supplied. I repeat what I said in my last message. I CANNOT after 10 years, change what is reported as pitch by FSUIPC. It is merely relaying what is supplied by FS to all gauges and anything else which asks. Surely the algorithm I outlined does it all for you. What IS the problem you have with it? It gives you the pitch from 0 - 360, as you asked. Your software needs to do a little computation using the Bank value as well. Please tell me what you don't understand. I am perplexed! Regards Pete

Not before now, no. I just believed what I thought MS stuff told me. I never have time to check and test every value -- especially those simply passed straight through from FS, or given direct access into FS innards, like the LLAPBH values. I do check values computed or derived by my own code of course. For interpretation of the rest I am completely dependent upon feedback from those who use the data. Anyway, you are completely correct. And it is the same in all versions of FS. So my documentation has been wrong now for nearly 10 years, and you are the first to even notice it -- or maybe just the only one to bother to tell me! I will correct the documentation. I cannot change what FS provides -- it will certainly mess up existing programs if I do. The Bank angle will have to be read too, in order to compute the 0-360 pitch. The absolute value of the bank angle is between 90 and 180 when the aircraft is "upside down", and between 0 and 90 otherwise. So, the three resulting cases are: Pitch >= 0, abs(bank angle) < 90: real pitch = pitch Any pitch, abs(bank angle) >= 90: real pitch = 180 - pitch Pitch < 0, abs(bank angle) < 90: real pitch = 360 - pitch Check that for me please. If you agree, I'll include it in the documentation the next time I update it. Regards Pete

None of the code I have produced have "ReadAndProcess" or "WriteAndProcess" calls. I wouldn't ever propose such calls because they tend to encourage folks to use one process call for each and every offset read or write. Ugh. The whole interface is designed to be used with regular blocks of requests -- one Process call for many reads and writes, mixed. The Process call in my code is a "SendMessageTimeOut" with the timeout set to a number of seconds (you'd need to check the code for that, I don't recall), so yes, the Process call blocks unless it fails and so times out, in which case you'd get an error returned. On top of that I think some parts of the library code i provided do a number of retries, within the part incorporated into your code. These calls have to block because the memory FSUIPC is being asked to dump the data into belongs to your program. If control were returned whilst FSUIPC was still accessing it, and you freed it or terminated, FS would crash. The normal way to get around such blocking calls is to use threads. Regards Pete

O2C8 is the value updated directly by SimConnect, the others are derivative. It will be updated at the same time as the other flight related values like pitch, bank, heading and airspeed. I know of nothing to make it different (but see [LATER]). It isn't an autopilot, but a series of little feedback loops for pitch, bank and speed, so the V/S didn't come into it. Maybe. I really don't know how it is computed in the sim. If you monitor it on screen with, say, the "Display Vals" Lua plug-in, is certainly seems to change rapidly enough. [LATER] Checking my code, the V/S is actually in the "visual frame rate" group rather than in the "Sim Rate group" like the latitude, longitude and so on. But so are the speeds. I can move them to the faster group, though I think a lot of the time the two equate. If you don't get anywhere, check again with version 4.415 or later when you see it posted in the updates announcement, probably before the weekend. Regards Pete

No need to apologise, and thanks in any case for trying to help. I like to see that happen on the Forum. Too often it appears to be just me talking to everyone else, but actually that's probably because I am usually very fast at responding. When I am away for a few days others do jump in to help a lot more, which is most gratifying! This is why I switched from email support to the Forum system. Regards Pete

One possibility, if you have them assigned in FSUIPC (not just calibrated there), is that the new drivers have effectively changed the identity of them as seen by FS, and FS, in its wisdom, has seen them and automatically assigned them as new devices. If you have things assigned in more than one place it can produce some very weird results, so that's the first thing I'd check. Of course they may also look like new devices to FSUIPC too. So check both. If you are using the latest interim update for FSUIPC (available here, in the Announcements), it creates a section in your FSUIPC INI file listing the "JoyNames" it finds associated with each joystick number assigned by Windows. There are facilities for assigning letters instead, and then FSUIPC will automatically handle such changes as best it can (assuming the names don't change, only the numbers). Otherwise, have you asked on the Saitek forum? They should know what their driver updates do? Regards Pete

I need more information before I even look at it, please. Both of these are always absolutely necessary: 1. Version of FS (FSX, FS9, FS2002, FS2000, FS98, CFS1 or CFS2?) 2. Version of FSUIPC (if not the latest, please update first). Then can you please go to the FSUIPC "Logging" page, enable Monitoring of 3122 as type UByte, check "normal log", and also enable IPC Write logging. Then re-test, and show me the parts of the log where you write to 3122 and the results are shown. Thanks, Pete

The pitch data is complete. No more is needed. It gives all 360 degrees -- 0 to 179.999999.... pitch down and -0.000001... to -180.0 pitch up. What more could there possibly be? If your pitch reference zero is other than the horizontal it is just a matter of arithmetically adding or subtracting that reference, surely? What is the difficulty? It's only one dimension, there are no other factors. Pete

Okay, but now you know. It's just as much stealing as those who take copies of friends CDs and DVDs, denying the makers/artistes their income. Sharing a copyright product is a violation of that copyright. Yes, when they have given me the original, leaving them without. That isn't possible with software, which is why it is either licensed to the individual (as with my stuff), or to the one specific PC (as with Microsoft Windows and most other licensed software). I tend to think the latter is too restrictive, but perhaps I should consider going that way. :-( This is exactly the same. What is the difference between your friend making you a copy (which is actually how most CD and DVD sales are lost) and you downloading it from the internet? In fact, it isn't the copy of the software which is illegal, it is the Key to allow you to use it. You cannot get that from the Internet without purchasing. Any downloadable keys you may find are either pirated and fall foul of traps set into the software, or are revoked as and when discovered, as, indeed, your friend's should be if you will reveal it in your honesty. Please go and buy your own Key, and update your version of FSUIPC -- or simply delete the FSUIPC.KEY file from the FS modules folder so making your copy unregistered, as it would be if you had downloaded it. And then thank your friend but warn him not to do such things again. Regards Pete

Stutters in FS9? On a machine like that? Could your hard disk have been getting full or badly needing defragmenting? That's illegal. The license is sold to a specific user and registered in his name and email or home address. If he"gave" you those details he's in violation of his license, and the registration must be revoked. You are effectively using stolen property. I deliberately didn't go down the road of restricting use of FSUIPC to a particular PC as i think this is unfair on the user -- I prefer it licensed to the person. But that doesn't give any one the right to make copies and give them to friends. That's stealing and is akin to making copies of CDs and DVDs. And it isn't supported either. If you want support you need to purchase your own key and update to the latest version. I'd appreciate it if you'd show me the Key you are using, too, please, so I can revoke it. Otherwise we cannot be on good terms. Pete

Do you always load FS from ASA? It is looking more and more like a bug in ASA rather than the add-on aircraft. I'm not sure it is wise, until we get to the bottom of this, to run ASA until FS is loaded and ready to fly. All sorts of things might be going wrong if ASA is messing with FS whilst it is initialising. Why have you reverted to FSUIPC version 3.82? That's really very old, and no use to anything I can do. Please stay with 3.858 until i send an update for you to try. It is huge even though FS crashed/hung on loading? That is VERY suspicious, and even more indicative of a problem caused by ASA trying to do something whilst FS is initialising, before it is ready for whatever it is ASA wants it to do. The MOST important part is the last part, the bit before the crash, though if FS hung instead of crashing that might not be so useful. ZIP it and send it as an attachment to petedowson@btconnect.com. Do NOT send it without Zipping -- it will zip up quite small. I'll look at that one, but please try to get one from a CRASH not a HANG, and using FSUIPC 3.858, not 3.82. Please also do some testing where you run ASA later, when FS is ready to fly. It sounds like it isn't waiting for the "FS is ready" signal from FSUIPC before trying to set the weather -- FS will certainly not like attempts to set weather when it is still initialising all that stuff! Have you reported all this yet to HiFi Simulation, as a potential ASA bug? If not I think you should. I am on good terms with them and we can resolve it between us, but bugs need to be reported by users, not by third parties like me. Oh, just looking at the start of the Log, you have other FSUIPC clients also running. "SBMPJOIN9.DLL" (part of Squawkbox?) and "SDscene.DLL", which I don't know though must have licensed. Then, later, SBMOD9.DLL starts up too, followed by ACTIVERADAR.DLL. You didn't mention any of this before, did you? Any one of those could also be part or the whole of the problem. Maybe you should continue doing some elimination. Do you know what SDscene.DLL is for? Try removing it temporarily from the Modules folder. SBMPJOIN9.DLL and SBMOD9.DLL too if you aren't flying on-line during these tests. You really do need to pare it down to the minimum setup which crashes if we are ever to resolve it! You don't need ACTIVERADAR.DLL either just to use ASA. Move all these optional FSUIPC-using DLLs out of the Modules folder for now -- keep them safe, then run more tests with just ASA. If that's then okay, add them back, bit by bit. ActiveRadar first, test, then the two Squawkbox ones, test, then finally that SDscene, whatever that's for. If it still fails with no FSUIPC users excepting ASA, we know it is definitely ASA. Regards Pete

Not sure why you'd want to use "GEAR TOGGLE" for separate up and down operations when there are perfectly good GEAR UP and GEAR DOWN controls available for such separate assignment? This was why I was puzzled by the original question, and still am. If you are going to all the trouble of editing the XML files, why not take advantage of the controls FSX actually does support, not just the ones MS thought you should be ogffered in its assignments menu? I had assumed, wrongly maybe, that the fact that the original question was asked here, in the FSUIPC support forum, implied it was related to assigning buttons in FSUIPC. ALL of the FS controls (and more added by FSUIPC) are available for direct assignment through FSUIPC. If you really do wish to take advantage of the XML file instead to program FS controls, you will find a full list of names for all FSX controls in a PDF installed for you into the FSX Modules folder when you install FSUIPC4. Any of those should be usable in the XML file -- just omit the underscores separating the words. (You do not need to purchase FSUIPC4 to be able to install it and read this, and you can always delete FSUIPC afterwards if you don't want it installed). Regards Pete

Any of the cockpit selection controls will highlight or select that other cockpit function or view and so "un-highlight" the previous one. Have you not looked at the extensive list of controls provided (installed) in the FSX Modules folder for you when you install FSUIPC4? Examples of selecting controls are: ADF COM_RADIO DME MAGNETO NAV_RADIO VIEW VOR_OBS XPNDR If you simply want keyboard focus back to the normal view, I think the VIEW command does it. Regards Pete

Did you get my email, sent yesterday (Monday), Bill? Regards Pete

The documentation simply reproduces what the Microsoft SDK says for the same variable. I have never used those so I've no idea whether Microsoft are mistaken or not. They have been consistent throughout the life of FS, and they are documented as ft/sec in the latest SimConnect SDK for both FSX and ESP, so I really do think they are correct. You can easily check. For the specific aircraft the speeds are given in the Aircraft.CFG file. For example, the FS9 737-400: [Reference Speeds] flaps_up_stall_speed = 142.0 //Knots True (KTAS) full_flaps_stall_speed = 113.0 //Knots True (KTAS) cruise_speed = 477.0 //Knots True (KTAS) max_mach = 0.82 max_indicated_speed = 340 //Red line (KIAS) So for this one, VS1 is 142, VS0 is 113, VC is 477. Max Mach is in another offset I think. Why? Are the values inconsistent with that? 194.12639 ft/sec = 115 knots 261.64862 ft/sec = 155 knots Those seem reasonable for an airliner. What aircraft is this? Have you checked the Aircraft.CFG file, where they are defined? I've never heard of VLS before now, and there's no sign of it in FS, nor can I find any references to it in technical aviation books. Can you elucidate? Regards Pete

Sounds like he has an invalid registration. If it works okay when he deletes the FSUIPC KEY file, then that is the problem. Either the key was purchased AFTER his system's date (i.e. he has the date wrong) or he is using an illegal (pirated) key. If he believes it is okay he should ZIP the key file and send it to me at petedowson@btconnect.com. If it still fails without registration is could be a code signature failure -- it will tell him in the FSUIPC Log file. That could be due to a DLL which has been tampered with, or possibly because he has Pete L. Dowson recorded as an untrusted publisher. Regards Pete

FS calls it "suction". The Gyro suction in inches of mercury is available at offset 0B18. Pete

It is next to the FSUIPC.DLL and the FSUIPC.LOG you already managed to find! All of FSUIPC stuff is always in the FS Modules folder. Regards Pete

The FSUIPC log isn't much use, except that it looks like, although you said ASA was running, I'd be surrised if it had yet had time to do anything. So far the most likely culprit is that Ariane 737. Why can't you test for a while with default aircraft, as I suggested? Since it appears that this problem is unique to you and is happening so frequently, it suggests that one or more of your add-ons, probably the 737, is corrupted and messing the memory values up thereby corrupting and crashing other parts of FS, including FSUIPC an, previously, another component. If I were in your shoes I'd be seriously considering a complete uninstall and re-install of FS, testing fully before installing any add-ons and after installing each one. I'll certainly have a look at that location, Offset 00027646 in FSUIPC 3.858 -- it appears to inside the Process Request routine, processing a request from an add-on. Does that Ariane 737 use FSUIPC? Otherwise I can't see what should be running which would be trying to access it so early. There's certainly no record here of any Ariane product licensed to use FSUIPC, but it may just be a re-badged older product from FS2000 or FS2002 days. If it is accessing FSUIPC and this crash is in one of the calls that it is making, then it is in the wrong place -- the routine is for EXTERNAL programs only. If there's a Gauge in the Ariane 737 accessing FSUIPC using the external method then this can certainly cause crashes. It is breaking the rules. Some very old (FS2000, FS2002) gauges used to do this and create no end of such problems. If you can definitely reproduce the crash right at the start like that, it would be worthwhile first editing the FSUIPC.INI file and adding LogReads=Yes LogWrites=Yes to the [General] section. This will log all attempts to access FSUIPC for any reason, and the last one before the crash may show us something. However, if it does turn out to be all down to that add-on aircraft I shall not be pleased and will not be able to do anything about it. [LATER] I've located exactly in FSUIPC where that crash occurs, and it is where it is processing the data passed by a program trying to use FSUIPC. Either something is passing invalid data (wrong length by the look of it), or, more likely from the logs, an internal Gauge or DLL is incorrectly calling FSUIPC using the external method. If it is the latter I can probably stop them doing that, which would cause whatever it is (e.g. that 737) not to work any more, which might be the best thing. I may supply you with a little updated version of FSUIPC3 which protects itself as far as possible against rogue programs, but I think you need to carry out a process of elimination to see what it is, whether it genuinely is that 737 or not. So, stop using it for a while and see what crashes you do or don't get then. Regards Pete

Well, it's whatever SimConnect considers the freame rate -- the one it reports. Well, might as well try 30 Hz (33 mSecs interval) first if you have FS set to that. Not sure i use anything as sophisticated as your stuff, and those terms are too technical for me. Isn't the information provided? It was all done so long ago, and so little interest was shown by anyone, that i just left it as it was, a curiosity. If the information for modifying it isn't already provided I'd have to search for it. Of course, nowadays, with the built-in Lua threads running in-process, you could write your own algorithms as plug-ins. Lua's quite powerful, and, although it is interpreted, it is quite fast once loaded and running. Being in-process with FS helps a lot, of course. Regards Pete

You have only one FSUIPC_Process call per Timer call? That's important. 50 fps seems pretty high to attain as a normal mininum in FSX -- what clock speed is your Core2 Duo E8500 running at? I use 2 x QX9775's overclocked to 4.0 GHz, watercooled, with an nVidia GTX280 (or 9800GTX+, not sure which is best at present), and I set the limiter to 25, which i can attain most of the time, but not all -- Aerosoft Heathrow drags it down to 10-12. Don't you think you are letting FSX take so much of your system that your program simply isn't getting timers at 50 Hz in any case? Timer calls are low priority, you know. if you want strict timing you need to run a timing thread which sleeps for n mSecs and sends a message or calls a routine regularly. You could also consider running your program on a client PC. You still need to regulate FSX, though. Have you tried other programs? FSInterrogate2 is useful for this, especially if you use the Quick Data Windows, as you should be able to build one up with exactly the same data set that you are reading, then vary its cycle time, exactly, using the slider provided for it. FSUIPC itself doesn't take any time at all measurably on each request, excepting perhaps when it is asked, through a WRITE, to request FS to do something long like load a flight or change the time by more than a minute. But those times are taken by FS doing whatever it needs to do. For FSX, FSUIPC reads are filled in from data which is arriving all the time, completely aysnchronously, from SimConnect. From the time FSUIPC receives the Message stating your requests, to the time it exits from that message, so allowing, theoretically, transfer of control back to you, all it is doing is reading the offsets and sizes from the table, as sent in the shared memory pointed to by the message, and doing memory copies from its own 65k offset data table into the shared memory. That never takes more than a millisecond, usually much much less. On FS9 and before it was a little different because most data items were only read when requested, and this sometimes involved actually calling routines inside FS. On the other hand, many values were grabbed directly from known structures in memory -- so, in fact, very fast. Overall it probably balances out, though with the difference that the FS9 and before values tend to be real-time synchronous whereas the FSX values will be read asynchronously (by SimConnect) and only "pretend" to be synchronous from FSUIPC to the application. (WideFS is like the latter in any case, on all versions of FS). The main time involved, when running on the same PC, is in the process changes (from you to FS and back), and the list of messages in FS's message queue awaiting attention before the one FSUIPC needs is forwarded to it. All that is done once per Process Call. Once you start WRITING things via FSUIPC it changes of course, because the actions required to achieve whatever you ask varies. Many will be fast, some will not. I use Project Magenta, no FS panels, not the FS autopilot or any of its subsystems. I don't know of any serious cockpit builders using default aircraft. Many use PMDG aircraft -- i use the PMDG 737NG model and air file from FS9, but none of its panels or systems, all of which are replaced by Project Magenta modules. Regards Pete

No idea, but I run a cockpit with 10 PCs. The autopilot is on one WideFs client, PFD/ND displays for Pilot and Copilot are maintained on two others, the EICAS screen and Radar Contact menu are maintained on another, there are 2 PCs running the CDU/FMS, a main ancillary PC running Active Sky, Radar Contact, pmsystems and assorted other FSUIPC clients, a moving map (Jeppesen FliteMap) on another, and so on. There are also a couple of FSUIPC clients on the FS PC itslef, and with all that going on there's little measurable impact at all on FS. No idea what you mean by "PID", but surely your polling should be at the frequency YOU choose, not some random affair. Aren't you regulating it? The data you are reading or writing is pretty irrelevant unless it is extreme. Try FSInterrogate, for example. Run it on the same PC as FS, in Windowed mode. If you select ALL of the values, the whole lot, and tell it to repeatedly read them, it will probably achieve 10Hz with no real problem -- but observe what happens to FS frame rates caused by the intense activity in FSInterrogate! Ugh. But that's nothing to do with what is happening in FSUIPC, that is to do with how much processor time is being stolen from FS to run FSInterrogate. Actually, for a multi-core PC, the bottleneck there is probably the screen drivers. You should be polling at the frame rate. The data won't change faster than that in any case (well, mostly). set FS's frame rate to, say, 25, then poll once every 40 mSecs. You can go higher, depending on your system, but you should be choosing, not letting it loop with no governor. Make sure you relinquish the processor whilst you are waiting, of course. It wouldn't make much difference really. It's the FSUIPC_Process call which takes the time. Do only one per cycle -- e.g. one per 40 mSecs. The individual Reads and Writes merely add data to a structure, all in your program. On WideFS, if you were to run your program over a Network, only the Writes actually do anything once the Server knows which data you are reading -- it supplies the latter automatically then, only when it changes. Sorry, that's all gibberish to me. What's a PID anyway? Regards Pete