Pete Dowson

I'm not yet sure why the old one behaved exactly as it did, but there are certainly worrying things wrong with it, here: [Axes] 0=0R,R1,D,21,0,0,0 1=0V,R1,D,27,0,0,0 2=0S,R1,F,66732,0,0,0 3=0T,R1,F,65760,0,0,0 4=0T,B,400,512,65595,0 5=0T,B,250,350,65597,0 6=0T,B,125,225,65599,0 7=0T,B,-512,-400,65603,0 8=1R,1,F,65696,0,0,0 9=1V,1,F,66387,0,0,0 10=1T,1,F,66388,0,0,0 11=2X,1,F,65695,0,0,0 12=2Y,1,D,2,0,0,0 13=2Y,B,16224,16383,65752,0 14=2Z,1,D,4,0,0,0 15=2U,1,D,5,0,0,0 16=2V,1,D,6,0,0,0 I've emboldened all the questionable settings. First, using RAW mode for all of the Joystick 0 axes is really bad. As it says in the documentation, RAW mode is only useful for software-controlled axes (like those from an EPIC or other program-controlled USB board), and is then useful for directly setting things like radio frequencies, MCP registers and bug positions, values which have to be precise. That is also the only time where a Delta of '1' comes in, to send every minute change through. All of your uses are for analogue values, where such precision is a nonsense and all you are doing in causing a hundred or more times more messages flying about in FS and between FSUIPC and SimConnect and FS. Terribly inefficient and really quite prone to things going wrong. To make things worse you have an odd mixture of some axes going direct to FSUIPC (and therefore avoiding SimConnect altogether) and others routed via FS controls, so using SimConnect three times per single change (as I explained before). It would be far more sensible to be consistent, and the most efficient by far would be to route everything direct with the only exceptions being (a) when you want to use a control not covered by FSUIPC's calibrations, or (b) when you are using an Add-On which needs to see and intercept the relevant FS control. Finally, you have in two instances, Flaps and Elevator, not only assigned an axis control to an axis but also FS controls based on Ranges. This is fine for non-conflicting uses, but having the same axis send a FLAPS_SET control to FS and, in certain ranges, also send FLAPS_UP, FLAPS_! etc controls is rather flabbergasting. Why on Earth try to make FS do two things at once with the same lever? What were you thinking? It just makes no sense and I cannot imagine your line of thought there. I'm not surprised you got conflicts. The other use of sending a control by an axis value is on the elevator: 12=2Y,1,D,2,0,0,0 13=2Y,B,16224,16383,65752,0 The control is "PARKING BRAKE". Why would you want to operate the parking brake with an extreme twist (16224-16383) of the elevator? Anyway, enough of that. On to your new settings: [Axes] 1=0V,32,F,66731,0,0,0 2=0S,32,F,66732,0,0,0 3=0T,1 4=0T,B,-16384,-16384,65595,0 5=0T,B,-10648,-10613,65597,0 6=0T,B,-5976,-5942,65599,0 7=0T,B,16383,16383,65603,0 8=1R,128,F,65764,0,0,0 9=1V,128,F,66387,0,0,0 10=1T,128,F,66388,0,0,0 11=2X,128,F,65763,0,0,0 12=2Y,128,F,65762,0,0,0 13=2Y,B,16288,16383,65752,0 14=2Z,128,F,65765,0,0,0 15=2U,128,F,66291,0,0,0 16=2V,128,F,66292,0,0,0 0=0R,32,F,65766,0,0,0 First, I still don’t understand why you don’t use the FSUIPC flaps notch calibration facility for your generic flaps, instead of the controls mapped to axis values, but at least you aren’t sending the Flaps axis value at the same time, so it is better. Second, why are you using such a low delta, like 32, for your aileron and rudder trims? This implies you have hardware axes capable of 1024 different positions, which would in turn imply they are extremely high precision and very very expensive. No commercial axis system I know of it capable of more than a resolution of something like 200 positions, and usually much less, less than 100 and most around 40 or 50. The default Delta of 250 allows 128 positions, but even that can be too low if there's any sign of jitter on the axes. By setting a delta too low you are simply wasting your PC's time with many spurious values which have either no effect or (because of jitter) an unwanted effect. Third, you still have extreme elevator values toggling the parking brake. I find that fascinating. Care to explain? Last, but probably not least, you are now using FS controls to the exclusion of any directness. Therefore every operation here involves lots of SimConnect activity (3 exchanges per axis change), so you are really gaining nothing by using FSUIPC assignments and certainly you are not benefitting at all from any of the improvements I made recently. I'm not sure why you've done this -- it is perfectly legitimate, just a bit mystifying. This is because, in order to calibrate axes coming from FS, as all yours are (because you directed them back to FS), FSUIPC has to place SimConnect intercepts on them. But it must only do this on the ones which are in use -- otherwise it risks wrecking things for add-ons like LevelD 767 and PMDG aircraft. Each time you load a new aircraft it clears down all the intercepts and waits for axes to be used again, so that it doesn't keep intercepting axes it shouldn't. How an axis behaves BEFORE the intercept is in place is in accordance with what FS makes of its value, without the benefit of any FSUIPC calibration or Reversal or Mapping, etc. FSUIPC's intercept will occur after the one reading, so it doesn't persist -- unless of course a second reading doesn't arrive (you don't move the axis and there's no jitter), in which case you might have a problem. This can be solved in one of two ways, one better than the other. The best way is to use Direct to FSUIPC calibration mode for every axis, all of them. This way there's no worries about interception, because they don't need intercepting, and, with the recent changes, SimConnect is not even used once, let alone three times per axis change as you have at present. On changes of aircraft you may still need to move a lever to get a reading set though, unless you take great care to save a starting Flight for each aircraft with things set normally, and load the aircraft by loading the flight rather than by selecting an aircraft. I think this can apply no matter how you use your axes. The other way is to tell FSUIPC to intercept axes regardless. If you are not using any add-ons which this would adversely affect, then this will work too. It doesn't make anything more efficient though. To do this use this parameter, documented in the Advanced users guide: AxisIntercepts can be set to ‘Yes’ to force the intercepting and forwarding of axis controls by FSUIPC4, even if this action is not needed for FSUIPC4 calibration (where it will be done automatically in any case). This action will be needed for some “fly-by-wire” aircraft only. Regards Pete

Sorry, don't know how to do that. Scenery / Graphics has never been an area I've hacked into. I had to look into the traffic stuff in order to provide TCAS information, and that was made easier by MS providing traffic Explorer. Regards Pete

I've just looked for you. The only sentences it has in common with GPSout are RMC and GGA, but these should be adequate (they have been for most every GPS and moving map program so far). Looking at its code for parsing GGA it should work fine. I suspect you've not tried the correct combination in GPSout.INI -- RMC and GGA. Pete

Sorry, 3.75 is very much out of date and not supported. Also you need to state the version of GPSout. If it isn't the current version (see the Current Versions announcement above), please update that too. The altitude is only provided in certain sentences (by definition). If you've tried them all it is likely that this XCSoar program needs one not supported by GPSout. You need to find out what XCSoar needs and see if GPSout can provide it. Every provision in GPSout has been made to fulfill needs of programs, and so far it has fulfilled every one. It seems unlikely the XCSoar is so very different, but you never know. If there's no or inadequate documentation for XCSoar, and it is "open source" why not look at that source and see what sentences it needs? Well they would blame someone else's code, wouldn't they, even though it's been proven good over a period of nearly 11 years! Also GPSout is freeware, not commercial, so they are probably wrong twice. Please don't come back until you are up to date, using supported versions. Pete

I need to see the FSUIPC4.LOG and PFCFSX.LOG files. Also it might help to enable SimConnect logging (see the FSX Help announcement above for instructions) and show me the first page or three from that. There's an update for PFCFSX (to 4.305) in the FSX Downloads announcemetn and also version 4.294 of FSUIPC4. It might be a good idea to install those first. Pete

This phenomenon is actually described in the documentation and is caused by the Server timing out later than the Client, so when the Client decides the connection has failed and re-connects, for a time the Server thinks there's another client, and so on. To find out what is going on you need to look at the Logs. That is what they are for. There will be a Server log and a Client log. if you don't understand them, show them to me. Pete

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