Erratic behaviour of all axis with FSX

[kakugo]

Hello,

I recently bought FSUIPC and started configuring it for FSX SP2. I disabled all controllers in FSX, unassigned all axis, assigned the axis of my Saitek Yoke and Quadrant to the usual controls using raw mode and sent them directly to FSUIPC and finally calibrated them in FSUIPC.

What happens is that, inside FSX, sometimes the controls seem to get crazy values (for example, the yoke appears as completely turned to one side), and moving the controls on the real yoke has no effect. The problem disappears when I open the FSUIPC panel and close it, but reappears randomly.

On the other hand, looking at the Controllers status in the Windows control panel and the values returned by the controls in the FSUIPC panel, the axis values look perfectly normal, and the yoke works just perfectly with FSX without FSUIPC or X-Plane.

By the way, I had put STICK_SENSITIVITY=0 in fsx.cfg but I don't think it is relevant. I didn't fiddle with the .INI file, so it should still be very close to its pristine form.

Did anybody experience anything similar? Could it be due to some interaction with other software? Ah, of course I am not using the Saitek Programming software at the same time as FSUIPC.

Thanks in advance!

[Pete Dowson]

... assigned the axis of my Saitek Yoke and Quadrant to the usual controls using raw mode and sent them directly to FSUIPC and finally calibrated them in FSUIPC.

Why on Earth are you using raw mode? As described, this is specifically provided for axes which are being software controlled (eg. by a programmable control like an EPIC) to do things like set radio frequencies, or headings etc -- applications where you certainly do not want any calibration ruining the actual values! In a normal control axis case, the use of raw mode will, through scaling, get wildly changing values. It is totally incompatible with any normal axis application.

Please, change all joystick axes to normal, default, not RAW, mode and recalibrate them all. By all means play around and experiment with all of the assorted options FSUIPC has to offer, but in the end follow the instructions for what you want to do, rather than create problems for yourself you then don't understand.

Regards

Pete

[kakugo]

Hi Pete,

indeed I tried again without using the raw mode and everything works perfectly. However, I should point out that it was not so obvious from the User Guide that raw mode is so strongly discouraged for normal controls. I didn't find any mention of the fact that it would produce wildly changing values, and I was rather led to believe that it was at least as good as the calibrated mode by the sentence "FSUIPC can use either. You’ll usually find that raw values are more honest in showing the true resolution of your device" and the possibility to skip a software layer seemed good. I think it could only help to make what you told me even more explicit in the guide.

Anyway, sorry for not having experimented a bit more before posting to the forum... also considering that I solved the problem before reading your reply. :(

[Pete Dowson]

Hi Pete,

indeed I tried again without using the raw mode and everything works perfectly. However, I should point out that it was not so obvious from the User Guide that raw mode is so strongly discouraged for normal controls. I didn't find any mention of the fact that it would produce wildly changing values, and I was rather led to believe that it was at least as good as the calibrated mode by the sentence "FSUIPC can use either. You’ll usually find that raw values are more honest in showing the true resolution of your device" and the possibility to skip a software layer seemed good.

Hmm. Not sure about "skipping" a layer -- that doesn't happen. You move the scaling from one place to another, is all.

I'm sorry you found the documentation wanting in this regard. I do try to improve it based on feedback, and in fact this is the very first time, in the 8 years this facility has been available, that anyone has done what you have done. So, whilst I'll will certainly look at the wording and see how it can be improved, you will understand my surprise after all this time.

I think it could only help to make what you told me even more explicit in the guide.

Yes, I will do that. Here's the relevant passage as it is at present:

FSUIPC can use either. You’ll usually find that raw values are more honest in showing the true resolution of your device. Where calibrated values will seem to vary enormously between large numbers like –32767 and +32767, the raw values are often just 0 to 255, or even 0 to 127. There are higher resolution devices about which may provide larger ranges, but not many. The main exception is the EPIC card which can, via its “soft” (programmed) axis facilities provide full 16 bit values.

The main use of the Raw input facilities is when you are using an axis to set a precise value, such as a heading, altitude, speed, or even a radio frequency. For this you will almost inevitably be using a precise programmable input device, such as EPIC as previously mentioned. For all ‘normal’ analogue input needs, you may as well leave the setting to the default and calibrate in Game Controllers.

I think that the main change since I wrote that, probably 8 years ago, is that many modern joystick devices now supply values already in the higher ranges, i.e anything from +/-6000 to the full +/-32767. When used for analogue control axes in FS, FSUIPC scales the raw values from their 8-bit assumed values to the normal 16bit values. It is this which causes the grossly erratic behaviour when the input values are already over 8 bits.

I shall therefore change the wording to read:

FSUIPC can use either. Whilst you will usually find that raw values are more honest in showing the true resolution of your device, you need to consider their end use. Where calibrated values will seem to vary enormously between large numbers like –32767 and +32767, the raw values are often just 0 to 255, or even 0 to 127. There are some higher resolution devices about which provide larger ranges, but not many. The main exception is the EPIC card which can, via its “soft” (programmed) axis facilities provide full 16 bit values.

When FSUIPC is asked to apply RAW input to a normal analogue control, it scales it by a factor of 256 or 512 to bring it up from its 7 or 8 bit range to a full 16 bit value. However, a problem can then arise. Many USB devices, especially those which come with their own specific drivers, supply values in the higher ranges even though their true resolution is really no more than those with the smaller numbers. Whether it is the hardware or the software which is doing this pre-scaling is unclear, and it probably varies in any case.

Unless you are sure (and, in fact, see) that the values from your device never exceed 255, the only real use of the Raw input facilities is when you are using an axis to set a precise value, such as a heading, altitude, speed, or even a radio frequency. For this you will almost inevitably be using a precise programmable input device, such as EPIC as previously mentioned. For all ‘normal’ analogue input needs, you should avoid "RAW" mode, so leave the setting to its default, and do a preliminary calibration in Game Controllers.

However, revised documentation is only released when new versions of FS are released. It is most unfortunate that this clarification just missed the recent releases of 3.93 and 4.53. It may be another six months now ...

thanks

Pete