Pete Dowson

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

You are right! It IS wrong, and has been wrong for, well, for all of FSUIPC's 9 year life, or at least since I added Slopes which was many years ago! The bitmaps for the display are generated okay, as are the look-up tables for the conversion of IN values to the OUT values, but the indexing of the one is done differently to the indexing to the other -- the negative values are indexing backwards! Huh, shows how many folks don't use that area! ;-) This is a very good catch. I'm fixing it now. It will mean, unfortunately, that anyone who is already using the -ve slopes will have to re-select the 'correct' one now. If you want to test the interim version with this fixed, please email me at petedowson@btconnect.com. Thanks & Regards Pete

No. Offsets are mainly for VALUES rather than ACTIONS. For most all actions you use CONTROLS. Those keypresses will be translated inside FS into FS controls, then re-sent to itself and obeyed. Keypresses can be re-assigned, so they aren't generally a useful way to refer to things. Find out what controls they are. With FSUIPC (registered or not) this is easy to do -- just enable Event logging (in the Logging tab), operate the keypresses and view the Log file to see what controls it used. You'll find both a control number and a name. Alternatively use the list of FSX controls installed for you in the FSX Modules folder. It lists names and numbers, in order of both. You can send any FS controls (and almost all FSUIPC-added controls) via offset 3110. You only need those numbers. Regards Pete

Are you sure it accepts positional data in NMEA form, replacing its own antenna input? Most Garmins I know of don't, except the Aviation ones, and they need "Aviation 400" format (also supported by the GPSout facility). USB ports look like serial ports but have strange names, not COMn. Please refer to the GPSout notes in the documentation. In order for any program other than your Garmin Synch program to actually get to that port, however, you will probably have to terminate it, otherwise it will grab the port exclusively. Pete

Ah, so it isn't the graphics you are saying show anything wrong, but only the results? I didn't understand that from your original post. The actual look-up tables for the slopes are generated once, when the program first loads, then used by the index. Maybe the indexing for the -ve numbers is wrong. I'll check it out here. If it is wrong it has been wrong for about 8 years. I suspect no one before you has ever wanted to make the response more severe than default. Most folks want more precision, for delicate adjustments and precise flying, near the centre, so the usual curves are those with flattened centres. One more question before I go checking this myself. You DO have the null zone, in FS, set to minimum, don't you? Otherwise the middle part of the curve, the bit you are talking about, isn't really having any effect in any case, and it's the shape of the tops and tails which you are experiencing. That will be quite misleading. For all FSUIPC calibrating operations, if you are assigning in FS, you need minimum dead zone and maximum sensitivity, else it is mostly a waste of time. ;-) Regards Pete

You cannot, unless you delete your FSUIPC registration (the FSUIPC.KEY file, in the FS Modules folder). The point of the name and email address (or any address, really) is to identify YOU, uniquely. Both WideFS and FSUIPC, used on the same installation of FS, need to be registered to the same person, and different names or addresses defeat this objective. It does explain this in the FSUIPC documentation. If you have purchased WideFS using a different email address to the one used to purchase FSUIPC then you should raise this as a problem with SimMarket (a "problem ticket", and they will issue you with a new key for one or the other. You may then need to delete the FSUIPC.KEY file and register both. Regards Pete

Not an option, no. FSUIPC uses the same control as you are using, so it can't do more. I suspect that it is restricted because of the projection problems this would give. There's a lot of distortion already at 0.31. Maybe the computations or approximations MS use in working out the views break down at some point, so they restrict it specifically to avoid this? Regards Pete

If you want to send view commands, why not send view commands? Why send keystrokes? Oh dear. What has WideFS got to do with it? If you are writing a program to interface to FSUIPC, it will interface to FSUIPC if you run it on the FS PC. If you want an FSUIPC interface on a Network you need to buy and register WideFS in any case -- that is absolutely nothing to do with programming, but is required to use WideFS in the first place! You need to know how to program a Windows program. Then look up the Windows message WM_KEYDOWN and WM_KEYUP in the normal Windows programming references, where all these things are explained. Sending keystrokes via FSUIPC is must easier if you use the FSUIPC controls supplied for the purpose. See the Advanced Users guide. You can all FS controls, and almost all FSUIPC controls, via offset 3110. For most purposes, FS supplies controls to do what you want. Keystrokes get translated inside FS into FS controls in any case, so why not use the controls in the first place? Also users can re-assign keystrokes, so you may not get the result you expect, whereas FS controls are designed to control FS (oddly enough! ;-) ). Pete

Actually, there's no similarities, but it is indeed quite possible that this Ariane gauge, or some other component of the aircraft you are using, has a bug which is resulting in memory being corrupted. the end results of that will vary enormously depending on the particular configuration you are running at the time. When checking for an error in a particular program it is best to narrow it down by only using defaults first. If ASA + FSUIPC doesn't cause any problem with a default aircraft loaded, but does with that Ariane one, then it is more likely to be a problem with the aircraft than either ASA or FSUIPC. No, this log shows you were using ... no sign of any different aircraft being loaded. Give up on add-on aircraft for a few tests, use only defaults. I cannot believe, at present, that this is anything to do with either ASA or FSUIPC. If you supply any more data for FSUIPC please be sure to use the latest increment as I requested, not 3.85. Regards Pete

Why are numbers bothering you? Use the slider on the right and view the fraphic, not the number! Slide it up and down. At 15 (with the slider at minimum, lowest position) you have the FLATTEST centre response. i.e very slow centre response. As you slide up the curve flattens, at 0 is it straight -- a 45% slope from one corner to the other, a perfectly linear response. The negative values then make the centre stepper and steeper, nearer vertical as it gets to the top of the slider at -15. At that setting the central response is to fast and the response at the extremes slow. The -ve values are almost the exact inverse of the +ve values. for a control with no centre, like the single throttle, only the upper half of the S-curve is used, but the principle is the same -- the steepness is at the low end, from idle. Please, try to understand it by the shape of the curve rather than by a nominal and otherwise meaningless reference number! Pete

For FS9, runway surface type is available in offset 31E8, and condition (normal, wet, icy, snow) in offset 31EC. The former should also be working in FSX (but isn't tested), but the latter definitely doesn't work. Check Thomas Richter's work on his "Autobrake" program. http://www.technical-service-richter.com/ Regards Pete

Hi Bill, Okay, almost there. I've just about completed an update to FSUIPC4 to implement "control profiles", for Keys, Buttons, Axes and Calibrations. It will be carried back to FSUIPC3 as well, after some more testing. I tend to implement new stuff on FSUIPC4 first as the code, being much more recent, is cleaner and I can see how to implement it tidily there. Only when it works in FSUIPC4 do I apply the same (sort of) changes back on FSUIPC3 (which of course is code grown up from the original FSUIPC1, dating back over nine years now! Are you using FSX + FSUIPC4? If so I could supply you with an interim update to help my testing, probably on Monday. If you are only on FS9 I'll try to transpose the code but it would probably be later in the week. Let me know, please. Regards Pete

Okay. I think I understand all that. I hope you succeed. The pictures are looking good, I agree. Regards Pete

I've now installed ASA on my FS9 test PC and have had it running on a flight for some time without any problems. This is with FSUIPC 3.858. I have no FSUIPC options selected in Winds, Visibility or Clouds, and I've not touched any options in ASA. Maybe it needs some combination of options in one or the other of FSUIPC and ASA, so I am desperately in need of more information from you -- all of the options (your FSUIPC.INI file would help -- just the [General] section) and a note of anything you've changed in ASA. I'm sure HiFi Simulations would have tested ASA with FSUIPC and FS9 quite thoroughly before the released it, so it is going to take some help from you to narrow this down and determine the cause. Regards Pete

You too? Sorry to read that. My impairment is Retinitis Pigmentosa (RP), but it is the type which progressively kills all my peripheral vision but leaves me my central detail (severe tunnel vision), so I can still work on a computer and read books, but fall over things, bang my head all the time, and can't go anywhere without crashing into people and shop displays! No driving of course, nor real flying. But i suppose that's reveals the "good" side -- it was because I couldn't get my medical certificate for flying (it was on that test I discovered my impediment, which wasn't so bad back then) that I got so deeply involved in simulation instead. ;-) Regards Pete

What says FS doesn't use it? Of course it "uses" it. It is an essential part of all aircraft and always has been fully supported in FS for as long as I can remember! Regards Pete

That's okay. You quoted the version number, -- the leading 4 denotes it as FSUIPC4. Are you able to post to Captain Sim support to ask / suggest that they contact me with more details so this can be resolved? I don't like having third party problems being blamed on my software and will be glad to help them resolve it. It won't get resolved by burying heads in sand! Regards Pete

That's the "Kollsman window", named after the German company that first started making altimeters with the viewable QNH adjustment window. Microsoft misspelled this as "Kohlsman" in their control names. If you download the FSUIPC SDK, which is what you need if you are playing with offsets, you'll find a "Programmers Guide" (or for FSX an "Offsets Status") document, which lists all of the offsets set by FSUIPC. A search for "altimeter pressure" in that would have immediately found it at offset 0330. Please do use the documentation supplied. It would be rather quicker than making fancy pictures! ;-) Regards Pete

Not exactly random if they always have the same details! ;-) Registration shouldn't have anything to do with it. This is the first report of any such problem, so I'd need details. 1. Is this only with ASA running? 2. How long does it take, after starting ASA, before a crash, typically? 3. Do you have any weather options set in FSUIPC? Maybe there's some sort of conflict with something ASA is doing? Try temporarily removing your FSUIPC.KEY file from the FS Modules folder, so that it runs unregistered and so with no weather options active. Let me know. Finally, could you try it with the current interim Beta version, 3.858, available in the "Other Downloads" announcement above, and let me know. Please include the same sort of details, which might change a little. Regards Pete

There should not be any difference, and if these is it most certainly needs fixing, not running away from. No one from "Captain Sim" has ever asked me about this, and unless I get enough details to enable me to fix it, it won't get fixed. Obviously. :shock: Surely this add-on aircraft doesn't use FSUIPC? If it does no one has asked me for a license. :twisted: Pete