FSUIPC V6.1 (registered) with P3D V5 GPSOut issue

[Oodi Menaker]

Hi,

The softwrae person in charge if this code in our application will check it tomorrow and then I will be able to answer.

In GNSS two units we use (Applanix and Novatel) there is a comma before the check sum so I assume we need it there.

Currently it looks like we are getting the angles but the marker that is calculated based on the roll is not correct. So I assume there is an issue on our side.

Will check and update. 

Thanks much for your fast support.

Best regards

Oodi Menaker

[Oodi Menaker]

Hi. We checked the data and came up with the following observations:

1. We are getting data in 5 hz even though in the definitions we put every 100 msec (supposed to be 10 hz).

2. The true heading updates once a second. It stays the same number 5 message (see attached log).PASHR-log.docx

3. The sign of roll is reversed. Right bank should be positive. Left bank should be negative. It is  reversed in the data we get.

4. The sign of pitch should be positive for nose above the horizon and negative for nose below the horizon. Currently looks reversed.

 

It will help us much if this points are corrected.

 

Thanks much

 

Best regards

 

Oodi Menaker

 

 

[John Dowson]

I will take a look and get back to you.

John

[John Dowson]

 

9 hours ago, Oodi Menaker said:

1. We are getting data in 5 hz even though in the definitions we put every 100 msec (supposed to be 10 hz).

Found this issue and should be fixed in the attached update. This is a long standing problem, I am surprised it hasn't been raised before...
Note also that the interval is the minimum interval, and you should generally expect to see the data at a slightly slower frequency than that specified.

9 hours ago, Oodi Menaker said:

2. The true heading updates once a second. It stays the same number 5 message (see attached log).PASHR-log.docx

This is strange and I cannot reproduce this here. If you still get this with this latest update, can you please add FSUIPC offset logging for offset 0x0580 as SA32 - this is the offset that the heading is calculated from. Also please keep the custom logging for the GPS out data that I showed you before.

9 hours ago, Oodi Menaker said:

3. The sign of roll is reversed. Right bank should be positive. Left bank should be negative. It is  reversed in the data we get.

4. The sign of pitch should be positive for nose above the horizon and negative for nose below the horizon. Currently looks reversed.

Ok - I took these values directly from the RPY sentence. I have reversed these values for PASHR in the attached update.

Did you check on the comma before the checksum? As no other sentences have this, I would rather not include this. However, if you need this, you can add
    PashrComma=Yes
to the [GPSout] and/or [GPSout2] section

So can you please try the attached. Any issues, please attach your FSUIPC6.log file, with the GPSOut data logged, and also with offset 0x0580 logged if the heading is still an issue.

Thanks,

John

FSUIPC6.dll

Edited June 7, 2023 by John Dowson
Update for PashrComma

[Oodi Menaker]

Hi,

Thanks for the update. will work on it next week and report the results.

BR

Oodi Menaker

[Oodi Menaker]

Hi

We get no messages in 5 herz. Roll and pitch are fine, thank you.

The track is still hanging see attached log (terraterm).

I put the entries into the ini and also to the log interface but I do not find where the log is.  Attached are the INI and the logs that are in the same directory.

FSUIPC6.JoyScan.csv WideServer0.log FSUIPC6.log FSUIPC6.ini WideServer.log teraterm4.log

[John Dowson]

There is a mismatch between the ini and log you posted: the ini file is from version 6.2.0d:
    UpdatedByVersion=6200d
but the log file from 6.2.0c and from 6th June:
    ********* FSUIPC6, Version 6.2.0c (5th June 2023) by Pete & John Dowson ********
    ...
    16 System time = 06/06/2023 10:24:04
 

1 hour ago, Oodi Menaker said:

I put the entries into the ini and also to the log interface but I do not find where the log is.  Attached are the INI and the logs that are in the same directory.

I do not understand this or why your log and ini files do not match, and why that log file is so old. Are you sure you are not running FSUIPC6 from another folder? You can check with the Open Folder button in FSUIPC's logging tab.

[Oodi Menaker]

WideServer.logFSUIPC6.logFSUIPC6.iniFSUIPC6.JoyScan.csvWideServer0.log

Hi 

These are new files from today. All of them generated today.

[Oodi Menaker]

the simulator does gets stuck every 5 or so seconds. It did not behave like this before. Does the logging put load on the system?  

[John Dowson]

17 hours ago, Oodi Menaker said:

These are new files from today. All of them generated today.

Well, at least you found the correct log file this time, but the log file stops after 57 seconds and was attached when FSUIPC6 was still running. Also no GPS data was sent:

Quote

    57469 13792 GPSout write failed: ERROR_IO_PENDING

I though you were receiving the GPS data, but obviously nothing was sent in the 57 seconds of this short run. Can you please try and generate a log file that shows your issue,, i.e. data at 5hz instead of 10hz and track hanging. I need to see the FSUIPC6.log file from when this occcurs, and please exit FSUIPC before attaching log files.

Also, just stick to sending PASHR strings for these tests.

17 hours ago, Oodi Menaker said:

the simulator does gets stuck every 5 or so seconds. It did not behave like this before. Does the logging put load on the system?  

No, additional logging would not do this. try removing it - do you get the same issue?

[John Dowson]

I would like to close this issue asap as I need to release the next version of FSUIPC shortly, probably next week. I can release with this included or not...I will probably release with this included, and can address any issues afterwards.

Note I will be away for the next few days, back on Monday.

John

[Oodi Menaker]

Hi, Apologize for the delay as I was out of the office.

The following are the logs. 

In the Terratem log you may see that the heading updates every one second.

FSUIPC6.logteraterm26-6-23.logFSUIPC6.ini

WideServer.log FSUIPC6.JoyScan.csv

[John Dowson]

If you look at your FSUIPC6.log file, you can see when the plane heading is changing from these lines:

Quote

   497000 12712 Monitor IPC:0580 (SA32) = -6.21689161
   497000 12712 SimRead: 0580="PLANE HEADING DEGREES TRUE"
            FLT64: 353.783108364

The GPS tracking info is calculated and logged here:

Quote

   497062 10744 dTrkT calculated: 353.754609
   497062 10744 dTrkT Override: 354.972011

The track 'override' value is being used instead of the actual plane heeding value. This is used as the ambient wind velocity (held in offset 0xE090) is > 2, and so the GPS ground track value is used instead, which is the value held in offset 0x6040 (GPS GROUND MAGNETIC TRACK) adjusted for the magnetic variation.

So, as 0x6040 is being used, and not 0x0580, please try logging that value instead (or as well). I have attached another dll you can use which has additional logging in calculating the track value used.

4 hours ago, Oodi Menaker said:

In the Terratem log you may see that the heading updates every one second.

It is the FSUIPC6.log you need to check, as this is what is being sent. If it is only changing/updating every second, then this is because that is what FSUIPC is seeing.

FSUIPC6.dll

[Oodi Menaker]

Hello

This is a log with the new version and with offset 0x6040 (GPS GROUND MAGNETIC TRACK)FSUIPC6.log

[Oodi Menaker]

And, although the NMEA description for PASHR specifies Heading, we do not mind to put there ground track - if it updates faster then the heading (the heading updates every on second which is not enough).

Thanks much

[John Dowson]

On 6/27/2023 at 9:53 AM, Oodi Menaker said:

And, although the NMEA description for PASHR specifies Heading, we do not mind to put there ground track - if it updates faster then the heading (the heading updates every on second which is not enough).

The way the tracking for GPS strings is calculated (i.e. ground tracking used with excessive winds) has been stable for 15+ years - I am not going to change this.

Offset 0x0580 is requested at  sim frame rate, and offset 0x6040 is requested at visual frame rate. If the offset (and therefore tracking) is being updated at a lower rate, then this is because the associated simvars are being updated at this lower rate. There is nothing I can do about this, sorry.

I really don't understand why you are seeing such low rates without excessive wind. This is what I see:

Quote

   611312 54412 GPSout data sent:
$PASHR,100210.11,264.45,T,019.69,012.73,,0.010,0.010,0.001,1,1,*10

   611422 54412 GPSout data sent:
$PASHR,100210.22,265.22,T,019.99,012.96,,0.010,0.010,0.001,1,1,*14

   611531 54412 GPSout data sent:
$PASHR,100210.33,266.01,T,020.30,013.19,,0.010,0.010,0.001,1,1,*19

    611734 54412 GPSout data sent:
$PASHR,100210.53,267.51,T,020.87,013.59,,0.010,0.010,0.001,1,1,*13

    611843 54412 GPSout data sent:
$PASHR,100210.64,268.27,T,021.16,013.78,,0.010,0.010,0.001,1,1,*13

    611953 54412 GPSout data sent:
$PASHR,100210.75,268.95,T,021.42,013.93,,0.010,0.010,0.001,1,1,*1E

    612062 54412 GPSout data sent:
$PASHR,100210.86,269.91,T,021.78,014.14,,0.010,0.010,0.001,1,1,*16
 

With excessive wind, when offset 6040 is used, I see similar results to you, with the tracking updated every second or so.
This must be because the sim is only updating the simvar GPS GROUND MAGNETIC TRACK  every second.

I have also tried changing the request frequency for this simvar to frame rate, and the result is the same,

Therefore the tracking update rate in strong winds will only be every second or so, and I cannot do anything about this.

[John Dowson]

Note that I have now released v6.2.0 which includes this update.