Pete Dowson

The used fields are more or less as I said in my last message. Here's what i have, with units: Bank (degrees x 10), Pitch (degrees x 10), ? not set (-999), ? not set (-999), ? not set (-999), altitude (feet), IAS (knots x 10), VS (fpm), ? not set (-999), ? not set (-999), localiser needle, +250 left to -250 right, glideslope needle +250 up to -250 down, mag heading (degrees x 10) ? not set (-999), ? not set (-999), The AV400 format has altitude, latitude, longitude, magnetic track, ground speed and mag.variation. Doesn't sound like what you want. For NMEA formats Google NMEA 0183. Regards Pete

Sorry. Maybe I misinterpreted. But please do go read what I've posted in the release notes for FSUIPC 4.294. It's just that I'm just not sure what help there can be. I spent most of last week putting together some special logging, in a way which doesn't interfere with the timing as normal logging would, and examining the results of FSUIPC's turbulence emulation on the actual wind values, and they all show just what was intended, very small (fractions of a knot or degree) changes varying up and down at a suitable frequency, based on the frame rate (but not exceeding 25/sec), to assorted targets slightly off the main wind values (for example +/-1.5 degrees or knots for moderate turbulence, which is one away from the realistically unmanageable "severe" setting) with a pretty reasonable approximation of a normal distribution of those targets. You can enable the logging yourself, as soon as you spot an A/P problem (or slightly before, better) and see the values for yourself. If you do think they aren't as realistic or mild as I say, let me see them please. In order to enable/disable this logging just put "Debug=Please" in the [General] section of the FSUIPC4.INI file, then change the "Extras" number on the Logging tab when needed, as mentioned in the Release notes. Regards Pete

What's a UAV? All such information and a lot more is available through the programmable interface. FSUIPC is an interface, not a recording or logging utility. To do what you require may need a program asking for and receiving the information through that interface. This is all described in the SDK for FSUIPC, also provided at www.schiratti.com/dowson. And no purchase is necessary for use of the interface -- the purchase gives you access to many user facilties for filtering the weather and configuring your joysticks and buttons, as described in the User Guide. Yes, of course. You either need to write a program to extract the data you need and log it appropriately, or see if there is one already available. However, I do not see the relationship between all this and some controller on board a flying aircraft. FSUIPC provides information from within FS, not from a real aircraft. There may be programs already available which will record information from FSUIPC. Check out "FlightKeeper" for instance. There is also the "GPSout" facility in FSUIPC4 (for which you do need the purchase, so maybe it is appropriate). This outputs a variety of NMEA 0183 and/or Aviation 400 specification data records and special formats, some of which may contain some of the things you need. For example the "RPY" output includes these in a CSV (comm separated value) format, suitable for Excel: Bank, pitch, altitude, indicated air speed, vertical speed, localiser deviation, glideslope deviation and heading which sounds much like what you are asking about. The GPSout option is designed to send its output via a Serial Port, for connection to a moving map program or whatever, but it could be to a program to capture the data to a file instead. You could use a pair of virtual serial ports (a free virtual port driver is available -- see the Downloads announcements above) to send the input to any program you can write or find which will accept input from a serial port. Regards Pete

So you have a mixture of some axes using SimConnect intensely and others now bypassing it? 4 is "Assigned in FSUIPC, using the FS control option, calibrated in FSUIPC". Why wouldn't it be possible? That was actually the "norm" for some time -- the direct to FSUIPC calibration option was a much more efficient method I devised after I realised it was a bit stupid catching the axis in FSUIPC, converting it to the appropriate FS axis control, sending it to FS, intercepting it again then modifying its parameter for calibration and sending it on its way again. Effectively in FSX that's three SimConnect exchanges for every twitch of the axis! Why did you ever think it wasn't possible to calibrate an FS axis when this has been the mainstay of all the joystick facilities in FSUIPC for years? And why, having read of the improvements and efficiency in the "direct to calibration" facility would you prefer to do it indirectly with three times as much simConnect traffic? Really the only reasons I can see of ever doing that are: (a) for use with some add-ons which intercept the FS axis controls themselves for special treatment -- e.g. possibly some airbus implementations. (b) to use one of the FS controls which aren't subject of FSUIPC calibration and which are therefore not listed in the "direct" drop-down. Why is the flaps axis operating as well as controls sent in specific zones? I don't see any point in that whatsoever. Surely they'll fight each other? The option to send controls during parts of an axis range was to allow for things like Airbus throttle modes, or operating the Gear using an analogue lever rather than a toggle switch or button. The flaps operation is surely well provided for by the notch calibration facilities in the flaps calibration section? Well, something must be way too clear in the manual if you've used such complex and rarely used facilities and almost got them working. I'm amazed really. Yes, because I still don't know how you are seeing, for example, the trims all reset to one extreme. Maybe the flaps problem is because of the conflict of the dual controls fighting, but that doesn't seem to apply to the trims which are, after all normal axes. Regards, Pete

In the FSUIPC SDK. There's not much info needed, but it is all there. There's also a set of #defines for the error numbers which are self-explanatory -- otherwise look at the source code, which is commented. Pete

What problem? If you mean the autopilot cannot cope with the new facility for emulated turbulence then why not simply turn it off? Why run FSX without FSUIPC? On the other hand, if you are not using FSUIPC for anything, why is it installed in the first place? All of the evidence so far proves that the turbulence emulation in FSUIPC 4.294 is working as intended. It is more realistic than FSX's own, but evidently some non-FSX autopilot programming is not designed to cope with such. Since the only reason I added it was to provide realistic turbulence to those using FSUIPC's Wind Smoothing option (which, as it has always done in previous versions of FS, stops all turbulence, gusts and so on), the two ways around the "problem" are (a) disable wind and cloud turbulence in the FSUIPC options, and simply not have any such effects, as before, or (b) disable wind smoothing so allowing the FS turbulence effects to operate. There are parameters provided in the INI file through which you can tone down the turbulence to less than its current realistic levels, though some report that this has little effect on the A/P which presumably simply cannot handle any small but frequent wind changes. Regards Pete

Well, there are several reasons for this. The interface from an external program uses "SendMessageTimeout" to request FSUIPC.DLL to examine the common data area and process the new commands. The action of sending a message between two processes causes a "Process Switch", which will take a variable amount of time and could be negligible on a multi-core processor but possibly several milliseconds if your program and the main thread of FS are using the same core. It will also depend on what other processes you have running on your PC and their relative priorities. The message is placed into the normal queue of messages waiting to be processed in FS -- every process only has one message queue from which they are distributed to each component as the message loop gets to them. This is where the main element of variability comes in, as when FS's main thread is engaged in something time-consuming it is not always processing messages. Then, once FSUIPC finally sees the request, the action it has to do varies considerably from one offset to another. Once upon a time, in FS98 and before, all these offsets were just that -- displacements from a base address in GLOBALS.DLL, and almost everything in FS was controlled by these global values -- so writes were effective simply by writing to the memory and reads always gave the results needed because that's where they were. Since then FS has been gradually but ultimately entirely re-written to use private data, encapsulated within C++ class structures, using complex heirarchical ownerships and so on, spread over several DLLs. FSUIPC has to access these in a variety of different ways, some involving a series of calls to procedures in several parts of FS -- a further reason for varying times in dealing with things. In FSX the new SimConnect interface is used by FSUIPC almost to the exclusion of all these methods (but not entirely at present). But this in itself is also variable in time taken, as the SimConnect interface is asynchronous and involves things like named pipes or TCP/IP communication, even internally from FSUIPC.DLL via SimConnect.DLL. However, whilst the latency might be greater due to this, I think the timing is more consistent, only depending on FSX's other tasks. If you have a need for consistent timing you must split off the requests to FSUIPC from your timing part (maybe using separate threads), and accept that sometimes, between whatever events you are trying to regulate, there may be more than one exchange with FSUIPC and sometimes none. If your FS frame rates are not consistently steady, then you will never get anywhere near steady rates from FSUIPC in any case, because the whole processing system varies with frame rates. One way of increasing the probability of getting a regulated service is to ensure that you set the Frame Rate limiter in FS to some value which is then always attained, so that FS's frame rate stays regular. Regards Pete

I'm afraid that tells me little or nothing. FSUIPC calibration can be used no matter how you route the axes. Are you saying you don't use FSUIPC at all for aileron and rudder? And is the elevator assigned in FS or in FSUIPC, and if in FSUIPC, is it using the "direct to FSUIPC calibration" or via FS? Sorry, by "direct to FS", do you mean assigned in FS? I really am gleaning nothing from this sort of description. There are these possibilities for each axis: 1. Assigned in FS, not calibrated in FSUIPC, FSUIPC has nothing to do with it 2. Assigned in FS, calibrated in FSUIPC 3. Assigned in FSUIPC, using the FS control option, not calibrated in FSUIPC 4. Assigned in FSUIPC, using the FS control option, calibrated in FSUIPC 5. Assigned in FSUIPC, using the direct to FSUIPC calibration option, calibrated in FSUIPC 6. Assigned in FSUIPC, no Axis control allocated, range facility used to send controls to FS If you mean you use the last for flaps, then there are no axis controls involved. If you are using a flaps axis AND sending controls then that is probably one of the problems, they may be conflicting. FSUIPC does provide, for flaps, a detente programming facility in the Calibration section. That works much better normally than trying to assign specific controls to specific regions. There's a restriction in the DirectInput and Windows joystick APIs which makes it necessary to either read axes on a joystick in RAW mode or in calibrated scaled mode. Once you have enabled RAW mode on any axis on a joystick then it must apply to all the others on the same joystick. To clear RAW mode settings you need to clear (delete) the settings for each axis on that joystick, then re-assign them. I'm wondering now how much this mix-up is contributing to the confusion. Unfortunately these descriptions are all rather ambiguous. When you say "directly to FS" that sounds like you don't use FSUIPC at all for those. And those "through FSUIPC" could be via any of about 3 or 4 of the methods I list above. Ah, does this mean when you say "directly to FS" you really mean "assigned in FSUIPC"? Because of all the confusion above I don't think I can even think about it until I see your INI file -- not just the [Axes] sections, looks like I'll need to look at the calibration sections too. ZIP the complete INI and send it to petedowson@btconnect.com please. Regards Pete

Why so mixed? Why not all the same route? And what about the actual flight controls - elevator, aileron and rudder. Where do they go? Are the flap detente ranges using the "send control" options on the right-hand side of the Axis Assignments Tab, or are you talking about the detentes in FSUIPC's calibration facilities? -16384 to +16384 is the scaled range, scaling is performed by Windows' drivers. The -512 to +495 sound like more realistic "raw" values, but for FSUIPC to see those you'd have to have the "RAW" option checked -- this sets a flag in the call to Windows to ask it to return Raw rather than Scaled values. No idea how you can get one then another without changing an option, unless it is some function of your drivers. Very strange too. Certainly things fully deflecting are most usually associated with bad connections or faulty hardware axes. Flaps not working could be the same of course- fully deflected for that axis would be the same as flaps fuly retracted. How are these axes connected relative to other axes? Maybe you should show me the [Axes} part of your FSUIPC4.INI file? Log axes (one of the options in the Logging tab), of course. It may show something that helps, but logging doesn't in itself sort things out. Regards Pete

Sorry, but none of that is anything whatsoever to do with FSUIPC. The axis names are used in FS too - in fact I thought you WERE talking about FS itself, not FSUIPC. Please DO NOT USE FSUIPC at all UNTIL you have got thing sorted out with FS. I have said this before and I cannot emphasise it enough. If you cannot sort things out in FS, you willl NEVER do it in FSUIPC, so you might as well give it up now! I'm not going to contribute any more to this thread until this gets back to be a sensible discourse. I do not like your accusations nor implications, none of which have any basis in truth. There is no programming nor programming knowledge required in any of this. If you'd simply followed the simple steps in the User guide you'd never get in such a stupid mess. If you've been messing about in FSUIPC I advise you to DELETE your FSUIPC INI file (from the modules folder) then go and sort things out in FS -- which is actually what I was talking about in my last reply, as everything you said seemed to be about FS, not FSUIPC! Pete

No idea about that, except that possibly Microsoft C LIB files aren't compatible with Borland. But that should be no worry for you -- the source of the LIB is provided as well. Why not build your own with borland? Incidentally, I just looked in side the FSUIPC SDK and I see there's an example package for Borland in any case. Did you ever bother to look at that? It is listed in the READ ME as follows: UIPC_SDK_BCB5.zip This is a version of the C example code revised and compiled with Borland C++ Builder 5: supplied by Alan Dyer. No DLL. It seems it is Borland which is wrong, really. But everything is supplied, you aren't missing anything. The tools are there, you simply need to use them. Pete

If you cannot get any sort of consistency at all from your controls, either they, or their connection to your PC are faulty. How do you mean, "created automatically"? The nomenclature X, Y and Z refer to the actual names of your axes in Windows. They'll be fixed, you don't "assign" an axis to "X", the "X" axis is defined by how it is wired and numbered in the innards of its hardware and its driver software. For a yoke X is usually the airleron and Y is usually the elevator, with Z often being the throttle. But they don't have to be. These letters, X Y Z R U V etc are just references to YOUR axes, they don't in themselves signify any particular action, and they most certainly are NOT "created", automatically or otherwise, they are there, operated by you, moving them with your hands! I cannot understand why you are remotely concerned or worried about Xs Ys and Zs. Just take it for granted than whether you move an axis or not, it has a name! The names X, Y Z and so on are just that, names. They mean nothing whatsoever. How would YOU describe them? Maybe "the one on the left with the black knob"? That's all very well, but the PC cannot see your kit, and different controllers look different! No, you can use any for anything. But it would be a bit strange using the yoke for throttle control and vice versa. Usually you select functions resembling those in a real aircraft, in similar positions and with similar colouring, maybe. But you don't have to. If you want to operate your rudder with the right-most "throttle" lever thingy, that's entirely up to you. That would be crazy. If two throttles did exactly the same thing, why have two -- you could never use them separately! This is all up to you. If you want to use only one throttle for all engines, assign it to the generic throttle. If you want separate throttles for each engine, assign one each to the individual engine throttles. Surely all this is obvious? You seem to be making it extremely complicated for yourself. Why? I've no idea what would be "normal" for you. You evidently have too much flexibility! Maybe you should sell the kit you have and just get a simple joystick or gamepad? :roll: :roll: The whole point of the flexibility of the sort of kit you have is .. its flexibility. But getting yourself totally confused because you don't know what you want each lever to do is just not worth the hassle. When will you ever fly? Pete

I just select custom weather, advanced, set up the layers, and, there they are -- turbulence to order. I do set it for all weather stations (i.e. globally), not just a selected one. Maybe you have FSX's weather change slider set to "fast" (or at least not "slow") and by the time you've reached the relevant layer its changed? I speed things up by slewing up to the layer I've enabled turbulence in, but it certainly hangs around for a long time. If you have FSUIPC's random turbulence option set (and the option checked for altering FS's own weather), then this is just as likely to stop the turbulence as start it. Also, in any case, the FSUIPC random turbulence won't have any effect when using ASX in the recent versions of FSUIPC because it no longer tries to change FS's own weather when it is set to "custom", which will happen when ASX runs. Well if you set it "per station", unless you set it for al the stations in the vicinity you may not see it -- FSX like FS2004 interpolates weather from three stations, but determining which three is not possible. The surest way is to clear all weather first, then set global weather. Pete

All you can get is a precise latitude and longitude. The rest you have to look up in a database formed from a complete scan f the user's scenery files. I do provide a freeware program called "MakeRunways" (derived from its original function which was just to make a runway database). This will do such a scan and it produces a number of records in both binary and CSV (comma separated value) format. Please see the Downloads announcements above, or go to www.schiratti.com/dowson. Regards Pete

I really fail to see how allowing FSX to use multiple cores is causing CTDs unless there's a real hardware problem on your machine. I am using FSX on an 8 core system (2 x QX9775 processors) and have no such problems, and it has been running since it came out, something like two years ago (including Betas) on two Core 2 systems I have and never once has there been a CTD I could even think of ascribing to any affinity setting. If I were you I'd be rather concerned about the stability of my motherboard. Regards, Pete

Are you talking about multiplayer? FSUIPC cannot provide any information about multiplayer aircraft, only FS AI traffic. There is a program called AIBridge by Jose Oliveira which does deal with multiplayer traffic, by injecting data into FSUIPC's AI traffic tables. On-line (internet) ATC Programs using multiplayer to show other fliers aircraft either use AIBridge or do the same injection themselves. Regards Pete

That sounds exactly like you have them set somewhere (in their driver?) for "digital" operation instead of analogue. Most game pads, for instance, operate in "digital" mode, where each position is full on or full off, nothing in-between. Check the drivers -- and certainly seek support from the makers. It seems one of the Saitek units were faulty when first released (the yoke I think). There is a thread about it here somewhere. If you check the FSUIPC "History" document you'll find this, in the notes for release 3.80 (FSUIPC3) or 4.25 (FSUIPC4): However, having axes that only signal full on or full off is no good anyway. That looks to be the first thing you need to sort out. Saitek's certainly your first port of call if these units are giving the sort of trouble you are describing. Which values are you talking about? I assume "T" is for "Throttle"? The "IN" values are those it reads from your device -- it sounds like those are only something like +16384 and -16384, with nothing in-between, from what you are saying? Or some other two extreme values? I can't do anything about that -- FSUIPC is simply reporting what your device, or its driver, are giving it. The output (OUT) values are the calibrated values, and they depend on YOU, on how you set the min/centre/max values, following the simple steps given in the User Guide. I thought that was obvious. That's up to you. Why do you think otherwise? You can assign them in FS or in FSUIPC. You assign whatever axis you want for whichever purpose you want. There's nothing pre-defined (though FS will certainly make some initial assumptions, especially if it recognises your device's name). Just be sure not to assign the same axis in both FS and in FSUIPC's "Axes" tab. You only want to use one or the other or they will conflict. Pete

I meant that, when programming your Hat positions, as separate buttons in FSUIPC, to simply program the "Press" action and not the "Release" action. If you do not program any action for "Release", then no action will occur when you release the hat. See? Surely this simple English sentence makes sense to you? I cannot see what is so difficult to understand. Maybe if you looked at the Buttons tab in FSUIPC options whilst you read it it would be clearer to you? Or even simply look at the pictures in the User Guide? Sorry, I don't know CH Manager at all. I thought you wanted advice about doing things in FSUIPC. If you aren't using FSUIPC for your buttons then please ignore everything I've said and refer to CH Manager documentation instead. Regards Pete

The ones before were preceded, in the SimConnect log, with data corruption in the Axis events being sent. In 4.291 and after there are no Axis Events being sent for axes sent "Direct to FSUIPC calibration", and there cannot be corruption in data which doesn't exist. So to investigate further, to see if it was Simconnect related, I'd need to see the SimConnect log. It does actually sound as if your crash is not the one others have been suffering at all, and is therefore probably not related to axis assignments at all. There's is no way in FSUIPC itself that any such cross-interference could occur. That sounds very much like FSX has picked up its own assignments (again). This can happen quite easily if you ever unplug and re-plug in any controllers. And fully-deflected axes tend to arise from a bad connections, which can look to the Windows drivers like a fully deflected lever. This used to be a common occurrence in the Game Port days. Regards Pete

I wouldn't use keystrokes if I were you -- they are inefficient and less reliable, as they are assigned in FS (keyboard assignments) and have to go through a table lookup to convert them to the relevant FS controls. Why not simply assign the controls you want in the first place? No, you should make it send VIEW RIGHT instead. I'm sure I already said this earlier in the thread? I said "controls", remember? So, simply do NOT program the release to do a VIEW RESET. I already told you that too! If the release sends nothing to FS it won't change views again! It won't even know you released it! Didn't you bother to read my original reply at all?? :-( Groan. :-( Simply DO NOT USE KEYSTROKES!! Then the Num Lock is totally irrelevant! There's no control to go directly to spot view, only the controls to cycle through them. Sorry. Pete

My tests today were with weather set up with moderate turbulence via the Weather dialogues in FSX. I have previously run the PMDG 747X with ASX, but not with your latest update (SP3). It was okay (well, the same as with user-specified weather). Scanning through the reports earlier in this thread I really find only one thing in SP3 which one user found affected things, to quote: "are you using the new Wind stabilization (not smoothign) feature in ASX SP3? My first flight with ASX SP3, I had that enabled, and the PMDG 747x went all over the place when crossing a wind layer. The wind vector was twitching like crazy. I disable the wind satbilization feature, and have now completed 3 long flights with no problems." However, this whole thread is strewn with inconsistencies, so I would necessarily take any of it on faith. For instance one chap is absolutely sure it is only "cloud turbulence" in FSUIPC, not "wind turbulence" which cases a problem -- yet there is only one turbulence emulation provided, so that makes no sense. The difference between cloud and wind is which weather record the "turbulence" instruction comes from, that's all. Another inconsistency is folks absolutely sure that it was all okay in 4.26 and not in 4.28, yet I've compared the code and there is absolutely no difference -- the turbulence is identical in both. And this is borne out by examining the actual wind fluctuations. From the sounds of those particular reports it seemed as if the FSUIPC turbulence emulation was actually turned off (by having smoothing off too0 when they were using 4.26, as the type of turbulence they reported was exactly FSX's own, which cannot happen when smoothing is in operation (the whole reason for the emulation in the first place). I have spent a lot of time examining exactly what my own turbulence emulation code does, and it is now doing exactly what was intended and what was agreed with PMDG as realistic. I've had to make one change, and that is to remove a dependency on the FSX internal frame rates to regulate the wind fluctuations. I suspect that the instability on some systems may have been due to them "running away" a bit -- and that might also vary due to other things, even different versions of ASX or FSUIPC. I also found that, because my hooks in FSX have to operate on two routes (VisualFX to SIM1 and Weather to SIM1) there were on average about 8 occasions per second where two increments were applied at almost the same time. This could also have made too much of a "jerk" in the wind. The regulation I've included now seems to sort all that out and, as I say, the results look good. Let's see what sort of feedback I get from folks using 4.294 (or later). I'll also be installing ASX SP3 this week and will do some more tests with that. Best Regards Pete

Oh, right. Okay. Thanks. Pete

Do you mean this? I'm not at all familiar with the Delphi section, it is supplied as I received it. Is the are place for it in there? Best Regards Pete

Oh, are you new to C/C++? If so, might not Visual Basic be a better place to start? You will at least need to read up a bit more I think. If you are including Windef.h, how are you getting it undefined in the first place? Just delete your inclusion of Gauges.h. I wasn't suggesting you included the gauges header wholesale -- after all 99% is no use to you. i was only suggesting that if you didn't know what something like DWORD meant you could easily find out by just looking! These header files are TEXT files you know, you can read them, take bits out, make your own header, as you please. This is all part of what is known as "programming". ;-) In the end, if you didn't want to use DWORD you could use "unsigned int" as I suggested, or #define DWORD for yourself. You seem to be making a real meal out of a tiny snack! :-( Pete

I've released 4.294 in the FSX downloads announcement above. Please read the notes. I tested this with the PMDG 747X version 2.00.031 and found that, with moderate turbulence, flying with 20-40 knot winds at 13000 feet or so, the autopilot, though wavering about, never got more than 10-20 degrees off the intended course. I think this is excessive, and you can actually see it turning the wrong way (i.e. turning left slightly even though the heading bug is to the right). I have no idea why, but no other autopilot i've seen behaves like this so I'm afraid it is a question for PMDG. I updated to version 2.10.0040 of the PMDG 747X and this seems better, never getting more than 10 degrees off, and usually only 1-2 at most. At least, this is how it behaves once it is on course -- it seems to have a lot more difficulty actually getting TO the right course, often apparently turning the wrong way for a little while. I cannot explain the odd A/P behaviour, but I have examined the detailed logs of the turbulent wind details, and they are always exactly as indented, with small increments and the speed and direction changing smoothly up and down over the intended periods. To tone them down any I think would make them unrealistic, though you can experiment with the Turbulence parameters, as documented. In the end I'm afraid that, for the PMDG aircraft, if you still have problems, you have two choices -- either contact PMDG and supply them with the logged wind data and a description of what went wrong with the A/P, or simply set the FSUIPC4 options to prevent the turbulence emulation. The latter would merely make wind smoothing in FSUIPC act like it did in FS2004, so it isn't such a loss, relatively speaking. Regards Pete