Help with FSUIPC SDK C# Altitude and Long/Lat

[vendetta]

Hi Peter Dawson, first let me say I cannot thank you enough for writing your FSUIPCSDK, it has become invaluable for writing addons.

Secondly, I am trying to create an addon in C# .net, that sends data to our webserver, so far I have the heading and speed working, and I tried to take the long and lat from the example program and they work, but what is an FS unit? How can i convert the FS units to normal decimal degrees?

Finally, my altitude is not working at all, I have tried to use this:

     int dwResult = -1;
     int token = -1;
           double alt;
            result = fsuipc.FSUIPC_Read(0x0570,8, ref token, ref dwResult);            
            result = fsuipc.FSUIPC_Process(ref dwResult);
            result = fsuipc.FSUIPC_Get(ref token, ref dwResult);
            alt = dwResult;
            //-1740701696 << That's the number i'm getting from memory, but it should be 3185125031936, as stated in the FSUIPCSDK program

            if (result)
            {                
                return alt.ToString();
            }
            else
            {
                return 0;
            }

Could you please tell me what I'm doing wrong, and how to convert the FS units to decimal degrees?

Thank you again for your SDK and help.

[Pete Dowson]

Hi Peter Dawson, first let me say I cannot thank you enough for writing your FSUIPCSDK, it has become invaluable for writing addons.

Thanks. Actually the name is "Dowson", but just use "Pete" please.

but what is an FS unit?

It's a unit devised by Bruce Artwick long long ago in the early days of FS, designed to represent a latitude or longitude (different units) as accurately as possible within a 32 or 64 bit fixed point number. At that time fixed point arithmetic was much much faster than floating point -- today, with the emphasis on floating point in modern processors, the reverse is probably true. Nevertheless, the units became established in all the file formats and so difficult to get out of without a clean break from the past, which never happened (well, not until now, with the closing of the MS FS team altogether).

How can i convert the FS units to normal decimal degrees?

As described in the documentation, and demonstrated in the FSInterrogate utility. Did you not refer to the Programmer's guide, the one which defines all of the FSUIPC offsets, in the FSUIPC SDK?

int token = -1;

...

result = fsuipc.FSUIPC_Read(0x0570,8, ref token, ref dwResult);

...

//-1740701696 << That's the number i'm getting from memory, but it should be 3185125031936, as stated in the FSUIPCSDK program

Well, I don't know C# at all I'm afraid, but it looks suspiciously like that "token" value you are reading 8 bytes (64 bits) into is only 32 bits long, unless you are using a 64-bit compiler? The large number you quote can never fit into a 32 bit value, don't you see that? I think the largest 32 bit value is around the 10 digit mark, which is what you are getting. The other 32 bits, the top end, are probably overwriting something else in your program you aren't aware of.

Doesn't C# have any debugging aids? I'm sure you'd be able to see what is going on if you used them. You could also even try the tools provided for you in FSUIPC, namely the IPC read logging, to see what you are reading.

Once you have the correct 64-bit fixed point number, use floating point arithmetic, as shown in the documentation, to get your degrees.

Regards

Pete

[Paul Henty]

Finally, my altitude is not working at all,

     int dwResult = -1;

The altitude is marked in the SDK documentation as being 8 bytes. The same goes for the Lon and Lat. You must read these offsets into a variable large enough (8 bytes). An int in c# (on a 32 bit OS) is 4 bytes. You need a Long.

     long dwResult = -1;

Obviously you can't then use the same dwResult variable for other offsets that are different lengths. You should really be defining specific variables to hold each bit of data you get back from FSUIPC, and typing them according to the specific FSUIPC offset.

If you're not too far into development you might want to look at my FSUIPC Client DLL for .NET. It's far easier to use and more suited to .NET programming patterns than the old C# SDK that you are currently using.

http://forums.simflight.com/viewtopic.php?f=54&t=53255

It also has good documentation explaining how to access different types of offsets and whhich C# (or VB) data types you need to use.

Paul

[Luke Kolin]

On this topic, assuming I've read the value in 0570 into a 32-bit integer, what factor do I multiple (or divide) it by to get the fractional component, which I will then add to the 32-bit integer I read from 0574?

Cheers!

Luke

[Pete Dowson]

On this topic, assuming I've read the value in 0570 into a 32-bit integer, what factor do I multiple (or divide) it by to get the fractional component, which I will then add to the 32-bit integer I read from 0574?

Obviously, all 64 bits make the one number, so no matter how many parts you divide it into, the conversion is the same! Both are therefore naturally subject to the same factor, except the fraction is divided by a further 2 to the power 32, as it is really the 32 bits to the right of the "binary point" (i.e. the division between integer and fraction).

Please please do read the notes on these offsets in the documentation. It is all explained there! Or just make things much easier on yourself and use a 64-bit recipient variable in the first place, as you've already been advised!

Pete

[Luke Kolin]

except the fraction is divided by a further 2 to the power 32, as it is really the 32 bits to the right of the "binary point" (i.e. the division between integer and fraction).

That's what I was missing. Thanks!

Please please do read the notes on these offsets in the documentation. It is all explained there! Or just make things much easier on yourself and use a 64-bit recipient variable in the first place, as you've already been advised!

I think you've confused me with someone else.

Cheers!

Luke

[Pete Dowson]

I think you've confused me with someone else.

Well possibly, as I see you are not the thread's originator. But if you've added to this thread you've presumably read it, else why add to it rather than start another? Whist it was originally about the 64-bit Latitude and Longitude values, Paul made the suggestion to use a 64-bit variable instead, and that applies equally to the altitude, another 64-bit fixed point number. Why wouldn't it?

Pete

[Luke Kolin]

Whist it was originally about the 64-bit Latitude and Longitude values, Paul made the suggestion to use a 64-bit variable instead, and that applies equally to the altitude, another 64-bit fixed point number. Why wouldn't it?

I fear that at times my understanding of low-level data exchange is not what it used to be. Dividing the whole 64-bit integer by 65536.0 makes perfect sense to me now, but didn't occur before.

Cheers!

Luke