SDK reading controller values

[aburley]

Hi guys,

 

I would like to write a small external utility that can read the FSUIPC output from a given axis, namely the Saitek Trim wheel.

I would also like to read the current FS value of the trim setting.

 

As we know, there is a problem with the Saitek wheel hereby it remembers its current position and throws that back to FSX when coming out of autpilot, causing a sudden pitch change.

 

The reason i would like to read the two values is this: While AP is switched on the values of the wheel and the FSX trim differ as the autopilot changes the trim. If i could see the values in my application, i could match the wheel value with that of FSX, so the wheel is synced (albeit manually) when exiting AP.

 

Probably not the cleanest way of doing it, but would be interesting to give it a stab.

 

I read with interest this thread, but the wheel just doesnt feel right unfortunately.

 

I know C# pretty well, and have the necessary .dll registered in Visual Studio. If i can get some pointers as to what offsets to read for an axis value and the FS value, etc., that would be very welcome. These are the only areas im getting lost on! :)

 

Thank you for your help.

 

-A

 

[Pete Dowson]

I would like to write a small external utility that can read the FSUIPC output from a given axis, namely the Saitek Trim wheel.

I would also like to read the current FS value of the trim setting.

 

 

Okay. They are both available in offsets, assuming the trim wheel is assigned in FSUIPC.

 

As we know, there is a problem with the Saitek wheel hereby it remembers its current position and throws that back to FSX when coming out of autpilot, causing a sudden pitch change.

 

I doubt that this is a special case of memory -- all positions of axes are "remembered" in the sense they don't change unless the lever or wheel moves -- excepting that is, for jitter. FSX, like FSUIPC, ignores static values, so the only possible cause of your "memory" effect is that the input value actually jitters slightly. I know from other reports that Saitek devices seem to have a little interaction between their different axes, so that moving one makes another twitch.

 

The reason i would like to read the two values is this: While AP is switched on the values of the wheel and the FSX trim differ as the autopilot changes the trim. If i could see the values in my application, i could match the wheel value with that of FSX, so the wheel is synced (albeit manually) when exiting AP.

 

 

So you disconnect the axis input from the FS trim action and from then on maintain a fictional value? How then are you going to relate that to user changes on the real trim wheel? If you maintain a constant difference then you could eventually run out of user trim capability at one end or the other of its movement. The only thing I can think of it to slowly adjust the difference until you can again allow the real value through -- i.e. "reconnect".

 

I know C# pretty well, and have the necessary .dll registered in Visual Studio. If i can get some pointers as to what offsets to read for an axis value and the FS value, etc., that would be very welcome. These are the only areas im getting lost on! :)

 

Have you looked through the offsets list? These things are easy enough to find. Search on "elevator trim". You'll find both the FS control input  and the indicator output. That's one half.  Further searching gets you to the bit in 310A to disconnect the elevator trim axis (and read the note which says you need to refresh that every few seconds), and yet further searching will get you to the offset where the calibrated FSUIPC trim vale, from the axis, can be read.

 

How are you "getting lost"?

 

Regards

Pete

[aburley]

So you disconnect the axis input from the FS trim action and from then on maintain a fictional value? How then are you going to relate that to user changes on the real trim wheel?

 

Say my trim axis at 100, flying level. The FS value would be the same. I then engage AP and ascend 3000ft, possibly change my airspeed and the FS trim value changes to say, 300. My wheel would still be on 100, causing a pitch change when the AP is disengagd. So my application will constantly read the FS value as it changes. Just before i disconnect the AP, i wil move the wheel so it matches.

 

I found that moving the trim wheel does not affect the AP - some planes will disconnect the AP if it detects suffient input from an axis. Not so with the Carenado CT210, which is what i fly with. So i am not planning on using the trim disconnect option in FSUIPC when AP is engaged option in FSUIPC in this case.

 

Good thought about running out of range on the wheel - i didnt think of that. Mind you, if i switch on the AP when the plane id trimmed, i would have thought that the 'adjustment' i need to make would be minimal. When flying the CT210, i dont like to use the AP; its mainly for when i need to leave my desk for a short while. When i return, i switch the AP off. The whole reason for me doing this is for those ocassions where i change speed, altitude, etc. using the AP functions and the trim would change.

 

Like i say, its not a perfect solution to work around how they built the wheel - just as idea i was kicking around.

[Pete Dowson]

Say my trim axis at 100, flying level. The FS value would be the same. I then engage AP and ascend 3000ft, possibly change my airspeed and the FS trim value changes to say, 300. My wheel would still be on 100, causing a pitch change when the AP is disengagd. So my application will constantly read the FS value as it changes. Just before i disconnect the AP, i wil move the wheel so it matches.

 

Ah! So you, the pilot, will manually move the wheel? You aren't using a program to match it as I thought from your post? So your program will simply display the two values so you can match it? (Of course, if you had a motor-controlled trim you'd be constantly operating the motor to match the AP trim in any case -- I'm lucky enough to be able to do that with my PFC 737NG cockpit).

 

I'm then a little confused by the rest of what you say.

 

Regards

Pete

[aburley]

Exactly. I will be adjusting the wheel myself to match the output from the wheel to the FSX trim.

 

In the FSUIPC for Programmers PDF, will 0BC0 be the one i need for the wheel (bearing in mind i have set a slight slope in calibration).

 

Im very sorry, but im not seeing the offset for the current FS (AP applied) offset. Maybe 0BC2?

 

Thanks for help, Pete.

[Pete Dowson]

In the FSUIPC for Programmers PDF, will 0BC0 be the one i need for the wheel (bearing in mind i have set a slight slope in calibration).

Im very sorry, but im not seeing the offset for the current FS (AP applied) offset. Maybe 0BC2?

 

0BC0 is the control input to the trim, no matter where from, and 0BC2 is the indicator. Both are exactly as described and will almost always read the same value. The autopilot is one control and the axis, when enabled, is the other. But the indicator is the one which you should match -- it is the one setting the needle position on the throttle quadrant or wherever.

 

Pete

[aburley]

So to summarise, 0BC0 is the hardware input, 0BC2 is the AP 'input'. Match 0BC0 with 0BC2, job done.

 

Excellent, thank you again, Pete!

[Pete Dowson]

So to summarise, 0BC0 is the hardware input, 0BC2 is the AP 'input'. Match 0BC0 with 0BC2, job done.

 

No no no. Sorry, but you have not been reading what I've been writing!

 

0BC0 is the CONTROL input, which when the A/P is in control is the A/P. FSX will pretty much always copy 0BC0 to 0BC2. I already said that they'll pretty much always be the same.

 

The calibrated JOYSTICK input value is found much later in the offsets. I told you to keep searching to find all the vlaues. FSUIPC will, however, only know the JOYSTICK input value if you assign in FSUIPC -- it won't be reading it otherwise.

 

Pete

[aburley]

I have been reading what you write. Obviously misunderstood what you meant, thats all. This kind thing is new to me, so im having trouble getting my head around it. Its not a straight forward subject as im sure you can appreciate.

 

From the documentation:

"Elevator trim control input: –16383 to +16383"

I understood that as 'the input from my controller [wheel] to the sim

 

From above post " ...will almost always read the same value"

I understood that as the AP trim when the AP is off would read the same as the control wheel input.

 

"and 0BC2 is the indicator"

As in what the AP is doing to the trim.

 

So... 0BC2 is the trim value that is applied to the plane, be that from the hardware or AP.

Offset 3338 seems to be the one for my wheel.

 

Thanks.

 

-A

[Pete Dowson]

From the documentation:

"Elevator trim control input: –16383 to +16383"

I understood that as 'the input from my controller [wheel] to the sim

 

I did actually say, way back "0BC0 is the control input to the trim, no matter where from, and 0BC2 is the indicator. Both are exactly as described and will almost always read the same value. The autopilot is one control and the axis, when enabled, is the other."

 

From above post " ...will almost always read the same value"

I understood that as the AP trim when the AP is off would read the same as the control wheel input.

 

 

Yes, if the AP is off the only control input is from either the keyboard controls (elec trim up and down controls0 or, more usually, from the assigned axis -- but the latter takes effect only when changed.

 

"and 0BC2 is the indicator"

As in what the AP is doing to the trim.

 

 

It indicates no matter what is changing the trim. Otherwise the cockpit indicator whould not show where the trim was in manual control.

 

So... 0BC2 is the trim value that is applied to the plane, be that from the hardware or AP.

 

Yes.

 

Offset 3338 seems to be the one for my wheel.

 

Without actually looking it up, yes, it sounds correct. And as I've said before, this is only if the axis is actually assigned in FSUIPC -- otherwise it isn't being read by FSUIPC so it cannot provide it.

 

Pete