Reading Current Aircraft Heading (offset 0x0580,0x02A0) - Not working

[activex]

Hi,

When I read (using current version of FSUIPC7) aircraft heading values using offsets (0x0580 {32-bit int}, 0x02A0 {16-bit, short}) I get wrong values. I know the values are wrong because I can compare them with the values displayed in the interrogate tool. Interestingly, in the interrogate tool, the values are correct.

I am using C# and FSUIPCClient SDK which is a wrapper around FSUIPC. Reading other offsets works btw.

Ex of code snippet I am using:

FSUIPCConnection.Open();

var aircrafthdg = new Offset<int>(0x0580);
FSUIPCConnection.Process();
var aircrafthdgVal = aircrafthdg.Value;

FSUIPCConnection.Close();

 

What am I doing wrong?

Thanks in advance.

[activex]

I'd like to answer my own question. I discovered that the cause of the problem was the fact that I was using "int" instead of "uint" for 0x0580, same goes for the 0x02A0 dataref, I was using short instead of ushort. I wish the documentation would tell me whether the dataref is signed or not. Yuck, you have to figure this out for yourself.

Consider this issue solved.

[Pete Dowson]

1 hour ago, activex said:

I discovered that the cause of the problem was the fact that I was using "int" instead of "uint" for 0x0580, same goes for the 0x02A0 dataref, I was using short instead of ushort. I wish the documentation would tell me whether the dataref is signed or not. Yuck, you have to figure this out for yourself.

The documentation is clear. for 0x2A0 is shows:

Magnetic  variation  (signed,  –ve  =  West).

For 0x580 it says

Heading, *360/(65536*65536) for degrees TRUE.

with no need to say signed or unsigned because if you want 0-359 as normal you KNOW to read it unsigned.  However, if you are correcting it for Mag Var using 0x2A0 you have to correct the value so calculated to be in the range 0-360 or else you can end up with a negative number, or one greater than 360.

Since I assume you must be doing that in any case, it doesn't matter if you read 0x580 as signed or unsigned. As an example, here's a Lua plug-in to show the value obtained both ways:

Uhdg = ipc.readUD(0x580)
Shdg = ipc.readSD(0x580)

ipc.log("Unsigned heading = " .. (Uhdg * 360 / (65536 * 65536)))
ipc.log("Signed heading = " .. (Shdg * 360 / (65536 * 65536)))

Here are the log entries i got for a single reading:
  1038578 LUA.5: Unsigned heading = 194.55367097631
  1038594 LUA.5: Signed heading = -165.44632902369
Now the second one is identical to the first when normalised to a 0-359 range because
194.55367097631 =  360 - 165.44632902369

Pete

 

[activex]

I missed it on the  (0x2A0) simply because it is mixed with the rest of the information. That's on me.  On the other hand for offset 0x580 I understand that the range is 0-359 that doesn't make the data type automatically unsigned. I've been using many APIs for long time and typically engineers use just a "signed" int for storing all sorts of unsigned values because ints are fast/efficient on current CPU/memory architecture. I think, a better explanation would be the fact that 65,536 can only be stored in unsigned short but even so you sometimes can miss that. I am always for explicit/clear documentation since there's no assumptions and everyone comes from different programming backgrounds.

I decided to use 0x2B00 offset since I don't have to do any calculations.

Thanks for your reply. I will continue testing FSUIPC7, it is coming along quite nicely.

[Pete Dowson]

27 minutes ago, activex said:

I understand that the range is 0-359 that doesn't make the data type automatically unsigned.

Agreed, but come on, -5 is the same heading as +355. Are you not correcting the TRUE heading to get MAGNETIC? If the heading is +2 and the MagVar is +6 ypu'd end up with -4. 

All you need to do to achieve a range of 0-359 is add 360 if the end result is negative, subtract 360 if it is greater than 360. 

That offset has existed with the same description since FS98,  22 years ago. You are the first to say it is confusing. Quite honestly, there's so much else that needs to be sorted out and  clarified in relation to MSFS that this is really trivial. The signed / unsigned nature of most entries is obvious because of what it is conveying. It only takes common sense, surely?

Pete

 

[activex]

Quote

That offset has existed with the same description since FS98,  22 years ago. You are the first to say it is confusing.

I am new to FSUIPC, just giving you feedback, the documentation needs improvement - Coming from a software engineer that's been working in the industry for almost 20 years.

Quote

 Are you not correcting the TRUE heading to get MAGNETIC

I decided to use completely different offset (0x2B00 - Gyro compass heading (magnetic)) that doesn't require corrections as stated previously.

Quote

Quite honestly, there's so much else that needs to be sorted out and  clarified in relation to MSFS that this is really trivial.

Absolutely, ... like using BCDs to store data. Tbh, if this would be my product, I would put a façade overtop of these binary values so that offset reads only return either ints or floats (wherever possible) which represent logical values in the sim (I would also default to an adopted units, ex feet vs meters). If you worry about backwards compatibility then create a new range of pseudo offsets for commonly used offsets. Everything would be consistent and easy to work with. Xplane SDK is a good example of this.

On another note, we'll need offsets for 8.33kHz radios for MSFS2020, I'll create a separate post. Hopefully, this will not be a BCD number.

[Pete Dowson]

7 hours ago, activex said:

if this would be my product, I would put a façade overtop of these binary values so that offset reads only return either ints or floats (wherever possible) which represent logical values in the sim (I would also default to an adopted units, ex feet vs meters). If you worry about backwards compatibility then create a new range of pseudo offsets for commonly used offsets. Everything would be consistent and easy to work with. Xplane SDK is a good example of this.

I think you should be using SimConnect directly. It does exactly as you wish.  You misunderstand what FSUIPC is for. For applications it is just a conversion interface or layer on top of SimConnect with the sole purpose of providing compatibility. The offset units and format were established initially by Microsoft and many of the ones in FSUIPC follow the layout used in FS98, especially those lower offsets where FSUIPC does conversions from the mostly double or float values provided by SimConnect into the forms used in FSUIPC over FS98, FS2000, FS2002, FS2004, FSX, FSX-SE and the P3D range.

8 hours ago, activex said:

On another note, we'll need offsets for 8.33kHz radios for MSFS2020,

They already exist and work fine with P3Dv5, but Asobo as yet has not provided the facilities in SimConnect to handle them.

Pete

 

[activex]

Quote

I think you should be using SimConnect directly. It does exactly as you wish.  You misunderstand what FSUIPC is for. 

I understand, ... ,- I chose it because it was easier to get started with it ... it is also very easy to send FS controls using FSUIPCClient library. SimConnect is probably what I will be using in the near future since the docs/examples probably improved (now that the Asobo SDK team is quite large).