About data-reading issues .

[longkimari]

Hi  Paul :

     I'm working on an app that reading data from p3d v3 and udp data to another app (writing with QT  ,PFD and MFD ).

     There are some issues :

     1、about longitude and latitude .  In your example ,  the code  likes this:

        private Offset<FsLongitude> playerLon = new Offset<FsLongitude>("PerSecond20times", 0x0568, 8);
        private Offset<FsLatitude> playerLat = new Offset<FsLatitude>("PerSecond20times", 0x0560, 8);

        And it's  result like this:
         W086° 29.87'
         But I wish the result likes simconnect in radian ,  how to do that ?

       2、about  Ele system ,  I wrote the code like :

        private Offset<ulong> EleBusMain = new Offset<ulong>("PerSecond1times", 0x2840);
        private Offset<ulong> EleBusAmps = new Offset<ulong>("PerSecond1times", 0x2848);
        private Offset<ulong> EleBattMain = new Offset<ulong>("PerSecond1times", 0x2870);
        private Offset<ulong> EleBattAmps = new Offset<ulong>("PerSecond1times", 0x2878);

       Cause those four data's size are 8 , so  I put those in "ulong" type , but  those appear wrong :

       

       All data are very huge numbers .

       3、I found that C# type char's lenth is 2(also string), but Qt  is  1,  so when I  copy struct  to bytes and 

              upd to my app ,   the data was wrong too .

      So far,   I found that the data getting from FSUIPC and  from simconnect  are so different even it's

       a  same data type ,  and some data can't found in FSUIPC , e.g kohlsmann .

  Thank you for your help.

  Best regards.

 

       

        

       

[longkimari]

I wanna whether if there has some documentation can guide me to know the FSUIPC offsets corresponding to simconnect's data.

[Paul Henty]

Quote

And it's  result like this:
         W086° 29.87'
         But I wish the result likes simconnect in radian ,  how to do that ?

That is the ToString() representation. You can get the Degrees in decimal by using:

playerLon.Value.DecimalDegrees

Degrees is easily converted to radians.

 

Quote

 2、about  Ele system ,     All data are very huge number

Cause those four data's size are 8 , so  I put those in "ulong" type , but  those appear wrong :

Yes, the documentation says 8 bytes and doesn't mention how the data is stored. Usually that would mean an 8 byte integer. Maybe these are actually 'double' types? Have you tried using

private Offset<double> EleBusMain = new Offset<double>("PerSecond1times", 0x2840);

The documentation here is unclear. If double doesn't give the expected results then please ask Pete Dowson about these offsets in the main support forum.

 

Quote

       3、I found that C# type char's lenth is 2(also string), but Qt  is  1,  so when I  copy struct  to bytes and 

              upd to my app ,   the data was wrong too .

You have two options:

1. Use the string converter library in .NET to convert the Unicode C# string to an array of ASCII bytes:

byte[] asciiBytes = ASCIIEncoding.ASCII.GetBytes("The C# String");

OR

2. Declare the offset as a byte array:

private Offset<byte[]> stringOffset = new Offset<byte[]>(0x3160, 24); 

The string is returned from FSUIPC in single-byte ASCII. So you can just use the raw byte array to send to your QT app.

 

Quote

    So far,   I found that the data getting from FSUIPC and  from simconnect  are so different even it's  a  same data type ,

FSUIPC gets its data from SimConnect. If you think some offsets are reporting the wrong values please ask Pete about that in the main support forum.

Quote

  and some data can't found in FSUIPC , e.g kohlsmann .

'kohlsmann' is at 0x0330, except it's spelled correctly as Kollsman in the FSUIPC documentation.

 

Quote

I wanna whether if there has some documentation can guide me to know the FSUIPC offsets corresponding to simconnect's data.

I don't know of any, but you could check with Pete.

Paul

Edited August 25, 2018 by Paul Henty

[Pete Dowson]

4 hours ago, Paul Henty said:

Yes, the documentation says 8 bytes and doesn't mention how the data is stored. Usually that would mean an 8 byte integer. Maybe these are actually 'double' types?

Sorry. Yes, all 8-byte types will be doubles (64-bit floating point) unless specifically mentioned as being integers.

Pete

 

[longkimari]

Thanks for  Paul and Pete .

Issues are fixed.