Reading and writing joystick axis values

[Simon853]

I want to write a program that reads a joystick axis, modifies it using a bit of external logic and then writes it back so that I can add extra moments of inertia during certain flight conditions.

So as not to confuse the sim, I thought I should assign my joystick to normally unused input channels, (i.e. engine 2 throttle on a single engined aircraft), read the values, mod them, then write them back into the proper (i.e. engine 1) channels.

But it seems these are all read only values in FSUIPC4. Is there another way of doing it? i.e. remapping and reading and writing joystick inputs to FSUIPC rather than the FSX axis settings?

Thanks,

Simon

[Simon853]

I think I may have found enough hints to keep me going in this thread:

viewtopic.php?f=54&t=64333&p=399411&hilit=writing+joystick+axis#p399411

Simon

[Pete Dowson]

I want to write a program that reads a joystick axis, modifies it using a bit of external logic and then writes it back so that I can add extra moments of inertia during certain flight conditions.

The same technique is used for Fly-by-Wire.

So as not to confuse the sim, I thought I should assign my joystick to normally unused input channels, (i.e. engine 2 throttle on a single engined aircraft), read the values, mod them, then write them back into the proper (i.e. engine 1) channels.

No, that makes it more complicated as you have to stop the other (real) control axes being used.

But it seems these are all read only values in FSUIPC4.

Er, where are you reading this? I think you are looking in the wrong place!

Please take note of offset 310A, which will enable you to disconnect the main flight controls. You can then read them in one place (3328 ff) and write them to FS in another (0BB2 elevator, 0BB6 aileron, 0BBA rudder). What you do in-between in up to you.

Regards

Pete

[Simon853]

Thank you Pete. Much appreciated.

(And yes, I was looking in the wrong place!)

Si

[Simon853]

Pete,

With reference to this thread: viewtopic.php?f=54&t=64333&p=399411&hilit=writing+joystick+axis#p399411

Do you know if you still have any outstanding issues regarding the 310A axis ignore flags and subsequent inconsistent values from the 332x registers?

My program's been working well all day and then suddenly started behaving oddly. (A earlier build's exe which was ok is now playing up too.) It appears that often reading from the 332x addresses gives me inconsistent readings when I'm blocking the axes (using bit mask 0F to set 310A.)

I find that if I reboot the PC and restart FSX it'll all work fine. And then suddenly at some unspecified point I'll run my program and it'll stop working again. And once it fails it never seems to run properly again. This sounds awfully familiar to the problem highlighted in the thread referenced above.

I'm rewriting the 310A mask regularly. (Once a second.)

FSUIPC version is 4.16, registered.

Regards,

Si

[Pete Dowson]

With reference to this thread: viewtopic.php?f=54&t=64333&p=399411&hilit=writing+joystick+axis#p399411

Do you know if you still have any outstanding issues regarding the 310A axis ignore flags and subsequent inconsistent values from the 332x registers?

No, that was all resolved.

My program's been working well all day and then suddenly started behaving oddly. (A earlier build's exe which was ok is now playing up too.) It appears that often reading from the 332x addresses gives me inconsistent readings when I'm blocking the axes (using bit mask 0F to set 310A.)

I find that if I reboot the PC and restart FSX it'll all work fine. And then suddenly at some unspecified point I'll run my program and it'll stop working again. And once it fails it never seems to run properly again. This sounds awfully familiar to the problem highlighted in the thread referenced above.

Well, it certainly doesn't sound similar to me! There was certainly no element of things "deteriorating" in those earlier problems. It was simply a matter of a routine not being called at all with one of several possible configurations (the direct to FS calibration assignments in fact). That plain didn't work because of the missing routine.

Your problem sounds much more like something is clobbering the SimConnect interface.

Please check the FSUIPC4.LOG file. In fact, go further than that -- use the Logging to check exactly what is going on. That is what it is for! You can monitor values and log the axes. Do both.

If it looks like a SimConnect problem you should get a SimConnect log too -- see the FSX Help announcement for how to do that.

If you have other SimConnect client programs running, get rid of those first.

I'm rewriting the 310A mask regularly. (Once a second.)

Once every few seconds, provided the writes get to FSUIPC within about 10-12 seconds, would be more appropriate. Even on a WideFS networked PC a 5 second refresh should be plenty enough.

FSUIPC version is 4.16, registered.

Please, when any problems are suspected, ALWAYS update to the latest interim version if there is one. There have been about 11 interim update versions since 4.16 was released. I doubt it this aspect is changed at all but I would only want to see current version logs in any case. See the FSX Downloads announcement above.

Regards

Pete

[Simon853]

No, I didn't mean that it deteriorates when running. Rather that sometimes the application works many times in a row, (i.e. application restarted and connected to FSX which is left running), typically during debug development, and then all of a sudden stops.

Rather like what they said here:

"At times the throttle offset (0x088c) and joystick offsets (0x310A, 0x3328, 0x332A, 0x332c, 0x332e) do not work at all. Whether these offsets will work or not, is known at startup time. Once they come up in working order, they appear to stay in working order. But it is a wild card at startup."

This is what I see. In that it either works or it doesn't. Once it doesn't work, a reboot of the PC sorts it out. (Simply restarting FSX doesn't.)

Note that all the other reads I'm performing continue to work, like Sim On Ground, True Airspeed, Engine Torque, etc. i.e. it's only the blocked axes in the 332x range that respond with spurious values.

Anyway, I shall do as you request and get the interim version and check logs when I return home later. (I will also test it with FS9 and FSUIPC3 to see if that behaves any differently.)

Thanks,

Si

[Pete Dowson]

This is what I see. In that it either works or it doesn't. Once it doesn't work, a reboot of the PC sorts it out. (Simply restarting FSX doesn't.)

Okay. I really don't know of anything else that would do that at present. I will need to be able to reproduce it (which presumably means using your program?), or otherwise at least get some information.

Note that all the other reads I'm performing continue to work, like Sim On Ground, True Airspeed, Engine Torque, etc. i.e. it's only the blocked axes in the 332x range that respond with spurious values.

Okay, so it suggests SimConnect is not getting kludged. However, the FSUIPC Log is still the very first place to look when you get problems, because if FSUIPC knows about them (and it might), they will be logged.

And even if FSUIPC is unaware of any problems, there are plenty of tools provided in FSUIPC, via the Logging page, for you to get enough information to tell both of us what might be happening. Even the values of these "spurious values" may be a vital clue.

As it stands, I do not even know how your axis values are arriving in FSUIPC. Are you assigning in FS, calibrating in FSUIPC, or assigning in FSUIPC. If the latter are you assigning direct, or via FS? Have you tried all three possible methods and do the problems occur with all of them or only one?

There are lots of things to do to narrow it down. I cannot help at present because I have no information from you and no way of seeing what you are seeing.

Anyway, I shall do as you request and get the interim version and check logs when I return home later. (I will also test it with FS9 and FSUIPC3 to see if that behaves any differently.)

Thank you.

Regards

Pete

[Pete Dowson]

I shall do as you request and get the interim version and check logs when I return home later.

When you try to reproduce it, please do remember to switch some appropriate logging on, so that you get relevant information. In fact, wait till I upload version 4.172 (just preparing it now), as I've added some extra logging to give me information on axis masking.

Before running FSX add this line to the [General] section of the FSUIPC4.INI file:

Debug=Please.

The sorts of things which it would be most obvious to log are:

1. Axis values -- the check box on the left-hand side of the Logging tab.

2. The values you are disputing in offsets 332x. Do this by choosing up to 4 offsets and entering them in the table on the right-hand side of the Logging tab. They'll be type S16, not hex. You can monitor them to the screen for your own interest, but check the "normal log" option so we can see them in the log and relate them to the axis values.

3. On the left-hand side you will see an "Extras" edit box, probably with 0 in it. Change that to 64. That enables the new debug logging of the axis masking.

After setting all this it would be best to close FSX and restart it, as you have said that on each load of FSX it either works or doesn't. It would therefore be important to see the start of each log.

We will need to compare the log of a successful session with that from an unsuccessful one. Try to keep the sessions as short as possible, just long enough to be sure, else there will be a lot of data to plough through.

Additionally you should really do this using each of the three different axis assignment routes -- FS assignment, FSUIPC assignment via FS, and FSUIPC assignment direct. Considering there are so many combinations, if you think you can reproduce it by selecting just ONE axis, then please do so. There's no point in ploughing through data for all four of those you are intercepting if this isn't needed.

If you send me logs please be sure to Zip them, along with your FSUIPC4.INI file please. If you have something I can use to reproduce the problem, please send that to. All to petedowson@btconnect.com.

Regards

Pete

[Simon853]

Pete,

I made a lot of changes and optimisations to my code last night and the program seemed to perform properly the whole time. So whether the problem is still there and didn't raise it's ugly head, or I inadvertently fixed a bug in my code that was causing it, I'm not sure. Anyway, considering this one resolved unless I add to the thread in the future.

Thanks as always for your help,

Simon