Glideslope Offset

[VOZzer]

Hi Pete,

I am trying to get Offset 2AB0 to work.

According to the FSUIPC SDK, it should range from -127 to +127 with a length of 4.

Unfortunately, when moving the glideslope needle in FSX, I get all sorts of erranous results (numbers that are in the tens-of-thousands).

Even when I defined it as having a length of 4, which is wrong I know, I received slightly more sensible readouts. However, they still did not make sense eg:

138, 125, 130, 137.. etc

I am asking what the correctly length of this offset is, and if it is working correctly or not.

Regards,

Jack

[Pete Dowson]

I am asking what the correctly length of this offset is, and if it is working correctly or not.

Yes, it is length 4, it is a FLOAT32 -- i.e. a standard 32-bit floating point variable. In C you define the type as "float" (64-bit floats are called "double".

If you read it as an integer you will get ridiculous results, as you've found. It is clearly documented as a float.

If you don't need such accuracy, using the single signed byte integer value at offset 0C49.

BTW why not try using the Logging facilities, or even FSInterrogate, to check your work?

Pete

[VOZzer]

Yes, it is length 4, it is a FLOAT32 -- i.e. a standard 32-bit floating point variable. In C you define the type as "float" (64-bit floats are called "double".

If you read it as an integer you will get ridiculous results, as you've found. It is clearly documented as a float.

Sorry Pete, double dutch to me!

Does this mean that it cannot be used with programs like SIOC or do I have to handle it differently (please explain slowly, I am not an expert at all on this programming business).

Jack

[Pete Dowson]

Sorry Pete, double dutch to me!

You aren't a programmer then? Sorry, you didn't explain any context. I have to assume that someone using offsets is a programmer unless they say otherwise!

Does this mean that it cannot be used with programs like SIOC

I have no idea, sorry. I do not know SIOC at all. Doesn't it come with any documentation or support?

If it can't handle floating point values then, no, it cannot handle that value.

Most users of the glideslope variable find the 255 graduations provided by the single byte (i.e. length 1) value at offset 0C49 to be sufficient for their needs -- it is what all Fs gauges use to regulate the GS needle, after all. The main use of the floating point value you seem to be keen on using is for autopilot programs using the glideslope feedback with utmost precision (32-bit precision -- so over a million possible values) for better feedback control.

Pete

[VOZzer]

Hi Pete,

I cannot seem to get Offset 049C to work, that is why I used the other one.

The SDK says it should range from -119 to + 119. However, when using the Beech Barob, get this:

- 138 (TOP)

- 254 (MIDDLE)

- 0 (JUST below MIDDLE)

- 119 (BOTTOM)

So it seems to range from 138 to 254, and then resets to 0 and counts up to 119. Certainly not -119 to + 119.

Jack

[Pete Dowson]

I cannot seem to get Offset 049C to work, that is why I used the other one.

The SDK says it should range from -119 to + 119. However, when using the Beech Barob, get this:

It's 0C49, not 049C, and the documentation says -127 to +127. I don't know what you are reading.

- 138 (TOP)

- 254 (MIDDLE)

- 0 (JUST below MIDDLE)

- 119 (BOTTOM)

So it seems to range from 138 to 254, and then resets to 0 and counts up to 119. Certainly not -119 to + 119.

There's no possible value "254", or even 138, in a signed byte -- there are only 8 bits in a byte, and when it is signed it only has 7 bits for the value. that's why it runs from -127 to +127. You are treating it as an unsigned value, running from 0 to 255. You cannot expect to get a negative number in an unsigned value! It's the sign which tells you whether it is negative or positive!

If whatever system you are using cannot treat numbers as signed when they are, just subtract 256 from the value you do get when it is 128 or greater. You'll notice your "254" is really -2.

Pete