Jump to content
The simFlight Network Forums

About data-reading issues .


Recommended Posts

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 :

       image.png.74fc6f7fcc383b58c41e8f92fa608495.png

       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.

 

       

        

       

Link to comment
Share on other sites

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 by Paul Henty
Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.