Strange value for 0C48 and 0C49

[javiercuellar]

Hi Pete.

Been playing with Nav variables I got some strange results.

Documentation says:

Offset: 0C48 size: 1 use: NAV1 Localiser Needle: –127 left to +127 right

Offset: 0C49 size: 1 use: NAV1 Glideslope Needle: –127 up to +127 down

Using my program to read them, and also FS-Interrogate to contrast results.

Situation

Near an ILS aproach (NAV1 code flags (0C4D): GS available bit 6 and This is a localiser bit 7 both to true).

a) low so GC should be +127 --> I recive +138 (the difference is 11)

b) high so GC should be -127 --> I recive -119 (the difference is 11 !!!!)

c) Right so Loc should be +127 -> I recive +130 (the difference is 3)

d) Left so Loc should be -127 -> I recive -127 (this is correct)

I thought that mayby my session had something strange, after restarting the PC, same results.

Only me?

[Pete Dowson]

Been playing with Nav variables I got some strange results.

They don't seem so "strange" to me. I think they are simply a measure. All FSUIPC does is copy what it gets from FS. The documentation of -127 to +127 as the (typical) range came from an original FS95 or FS98 document, written by folks who simply observed the range of values they got.

What is actually the problem? If you get a value slightly outside the range, treat it as the limit. I expect that's what the FS internal gauges do. If you think about comparisons with the real world equivalents, these are simply measurements of a signal strength or similar.

Before FSX and its SimConnect SDK was published we only had hacker's findings to go by. In the SimConnect SDK these are defined more explicitly:

0C48 is a copy of this:

NAV CDI:index CDI needle deflection (+/- 127)

0C49 is a copy of this:

NAV GSI:index Glideslope needle deflection (+/- 119). Note that this provides only 8 bit precision, whereas NAV GLIDE SLOPE ERROR provides 32 bit floating point precision.

Note that currently FSUIPC4 doesn't supply the "NAV GLIDE SLOPE ERROR", because no one ever asked for it.

It seems therefore that the documentation for offset 0C49 should say -119 to +119 instead of the 127 limits (though maybe that would upset you further because of the 138 you received?). Nevertheless I will at least update the FSUIPC4 offsets list to reflect the SimConnect dox. Thanks,

Regards

Pete

[javiercuellar]

Ok, thanks.

With more testing, things get even worst :?

One value received was 243!!! Taking away 256, gives -13 that is actualy the correct value (GS was almost cenered), and is the one FSInterrogate gives in the column Factored.

Tommorrow I'll keep testing to find a relation of when add/take away 256.

Regards

Javier

BTW. Do you know is there is a tool similar to F SInterrogate, but to observe all simconnect variables?

[javiercuellar]

Hi again.

Ok, now it's sorted. It works like this.

GS: When we are too high 0C49 (GS needle) shows +119. As we get closer to ground, the variable decrements its value. When aligned it becomes 0. After that, if going too low, the value jumps from 0 to 256 (basicly 0 and 256 its just the same) and decrements util +138. This is a two-complement variable.

Basicly to have a +119 / -119 we need to:

If ValueOf(0C49) > 119 then ValueOf(AuxGSVar) = ValueOf(0C49) - 256 else ValueOf(AuxGSVar) = ValueOf(0C49)

Same thing for Localizer,

If ValueOf(0C48) > 127 then AuxLocVar = ValueOf(0C49) - 256 else AuxLocVar = ValueOf(0C49)

[Pete Dowson]

With more testing, things get even worst :?

One value received was 243!!! Taking away 256, gives -13 that is actualy the correct value (GS was almost cenered), and is the one FSInterrogate gives in the column Factored.

Tommorrow I'll keep testing to find a relation of when add/take away 256.

There is no such value as 243 in a signed byte! You are treating it as unsigned, that is why it looks wrong! The range of values you can have in a signed byte is -128 to +127. A signed value of -1 will look like 255 if you treat it as unsigned -- the pattern of bits for both is the same, i.e. 11111111.

Please do think about the types of variables you are using. When reading a signed value declare the receiving variable as signed. If you read one byte into a 32 bit integer you will have to sign-extend it yourself, but in C or C++ you just declare the receiving variable as "signed BYTE" or "signed char".

Regards

Pete

[javiercuellar]

You are treating it as unsigned,

It's not my variable, that is the result of FsInterrogate.

I understant that a signed variable of 8 bits goes from -128 to +127. If its in an unsigned variable need to calculate the two-complement. This is equal to take away 256 when value is bigger than 127.

Regards

Javier

[Pete Dowson]

It's not my variable, that is the result of FsInterrogate.

No it isn't, as you certainly confirmed here:

that is actualy the correct value (GS was almost cenered), and is the one FSInterrogate gives in the column Factored.

FSInterrogate clearly classifies both of those offsets as "S8", meaning "signed 8 bit" == signed BYTE.

I understant that a signed variable of 8 bits goes from -128 to +127. If its in an unsigned variable need to calculate the two-complement. This is equal to take away 256 when value is bigger than 127.

It is never bigger than 127 because you can't have a signed byte bigger than 127. You wouldn't need to any manipulation if you read it as a signed byte in the first place, but maybe the language you are using doesn't allow that? Either way, you posted complaints in this thread as if the values are wrong, when in fact it is just your misinterpretation.

Regards

Pete

[Paul Henty]

Hi Javier,

If you declare the offset as a signed byte you won't need to do any conversions.

The base type for Signed bytes in .NET is System.SByte. The c# alias for this is 'sbyte', for VB it's 'SByte'.

Paul

[Pete Dowson]

The base type for Signed bytes in .NET is System.SByte. The c# alias for this is 'sbyte', for VB it's 'SByte'.

Thanks Paul. It is good to know these languages still allow such types! ;-)

Best Regards

Pete

[javiercuellar]

Pete,

Please do not misunderstand me. I'm not complaining at all. It was just strange (for me) to obtain those results, and as you said it's my misinterpretation.

Sorry for the confusion.

Paul,

Thanks for the advice.

Regards

Javier

[javiercuellar]

Paul:

Dim FSLocalizer As Offset(Of SByte) = New FSUIPC.Offset(Of SByte)("ILS", &HC48)

gives me:

Exception.InnerException: Tried to create an Offset with an invalid type.

So, for now, I need to keep the conversion procedure.

[Paul Henty]

Paul:

Exception.InnerException: Tried to create an Offset with an invalid type.

Oh dear. How embarrassing. My DLL doesn't support signed bytes!

I'll fix this tomorrow and PM you a new version.

Paul

:oops:

[javiercuellar]

. My DLL doesn't support signed bytes!

I'll fix this tomorrow and PM you a new version.

No problem. :wink:

Thanks a lot