Need for High Precision GPSout GPGGA NMEA string

[lidar532]

Hi Peter,

Would it be possible to adjust the precision of the lat/lon values output from "GPSout" from the current 4-digit fraction to 6-digits, and also fix the time-of-day to show fractional seconds of the day? As it is now, the fractional part of the seconds is always ".00". I've setup GPSout to operate at a 10Hz rate to match our actual gps receiver. The receiver is a "survey grade" GPS (Ashtech Z-Eurocard) and my navigation is a custom program I wrote a few years ago. It's designed for aerial survey applications and allows the pilot to fly within a few metres of the selected flightline. The high update rate (10Hz) is important for such precision flight. My program uses the lat/lon and time from the GGA string to compute the flight track, the ground speed in knots and metres/second and also the cross-track velocity. For the cross-track velocity and ground speed to function properly the time-of-day must be correctly paired with the lat/lon so delta-Time and the computed delta-distance can be determined. I hope fs2004 has enough internal precision to support more digits in the lat/lon values.

Best regards,

W. Wright

I've included some sample data from our actual Ashtech Z-Eurocard receiver below:

$GPGGA,210214.20,3913.903086,N,07524.167737,W,1,08,01.0,00355.056,M,-035.128,M,,*5A

$GPGGA,210214.30,3913.899989,N,07524.167553,W,1,08,01.0,00355.086,M,-035.128,M,,*52

$GPGGA,210214.40,3913.896892,N,07524.167369,W,1,08,01.0,00355.119,M,-035.128,M,,*59

$GPGGA,210214.50,3913.893794,N,07524.167183,W,1,08,01.0,00355.149,M,-035.128,M,,*57

$GPGGA,210214.60,3913.890698,N,07524.166995,W,1,08,01.0,00355.177,M,-035.128,M,,*59

$GPGGA,210214.70,3913.887602,N,07524.166806,W,1,08,01.0,00355.201,M,-035.128,M,,*54

$GPGGA,210214.80,3913.884505,N,07524.166615,W,1,08,01.0,00355.223,M,-035.128,M,,*50

$GPGGA,210214.90,3913.881409,N,07524.166422,W,1,08,01.0,00355.247,M,-035.128,M,,*5D

$GPGGA,210215.00,3913.878312,N,07524.166227,W,1,08,01.0,00355.259,M,-035.128,M,,*52

$GPGGA,210215.10,3913.875216,N,07524.166031,W,1,08,01.0,00355.260,M,-035.129,M,,*55

$GPGGA,210215.20,3913.872119,N,07524.165831,W,1,08,01.0,00355.248,M,-035.129,M,,*5C

$GPGGA,210215.40,3913.865924,N,07524.165422,W,1,08,01.0,00355.220,M,-035.129,M,,*5A

$GPGGA,210215.50,3913.862826,N,07524.165211,W,1,08,01.0,00355.199,M,-035.129,M,,*58

$GPGGA,210215.60,3913.859727,N,07524.164997,W,1,08,01.0,00355.179,M,-035.129,M,,*57

[Pete Dowson]

Would it be possible to adjust the precision of the lat/lon values output from "GPSout" from the current 4-digit fraction to 6-digits

The NMEA 0183 specs I read seem to specify 4 places explicitly. If I change that it may muck up some receiving programs. Is this a change in a later version of the specification?

Since the current "accuracy" of 1/10000th of a degree is, at worst, only 36 feet (and that, for longitudes, is at the equator). I'm not sure there's a lot of point in going further with FS as the timing of you receiving the data is going to vary far more significantly -- unless the thing you are tracking is very slow moving, like a boat?

If I could be sure that it would not upset any other receivers I could add two more digits though.

and also fix the time-of-day to show fractional seconds of the day? As it is now, the fractional part of the seconds is always ".00".

There's no fractions of a second in FS's time of day. If I "invented" them, what should they be? Just add something now and then? It would make little sense. I don't actually know the instant FS updates its second counter. Although there is a millisecond counter internally I think that carries on regardless of FS's simulation rates and so on.

I hope fs2004 has enough internal precision to support more digits in the lat/lon values.

It wouldn't be the precision of the Lat Long but the lack of any precision in the timing. Expecting your data to be precisely every 100 mSecs apart when it can take longer to do a process switch or suffer a delay through thread timings is possibly a little bit optimistic I'm afraid.

Regards,

Pete

[lidar532]

The NMEA 0183 specs I read seem to specify 4 places explicitly. If I change that it may muck up some receiving programs. Is this a change in a later version of the specification?

Hi Peter,

Would it be possible to set the number of digitis to the right of the decimal in the INI file for GPSout? Then it couldn't foul up any thing that relied on exactly 4 dights. The data I sent in the original post was captured from an actual "survey grade" GPS receiver. I've seen the number if digits vary from 4 to 5 and 6 depending on the quality of the given GPS receiver. I've never had any problem feeding our high precision GPGGA data to lots of different programs.

Since the current "accuracy" of 1/10000th of a degree is, at worst, only 36 feet (and that, for longitudes, is at the equator). I'm not sure there's a lot of point in going further with FS as the timing of you receiving the data is going to vary far more significantly -- unless the thing you are tracking is very slow moving, like a boat?

In real life, I'm using the system on an aircraft, a Cessna 310 twin, which is being operated at ~55 meters/second or roughly 110 mph. At 55 meters/second the plane only moves 5.5 meters between 10Hz GPS samples or 18.04 feet forward. The actual GPS receiver we use easliy gives us a stable noise free "ground track" with a precision on the order of 0.05 degrees in the computed graound track.

The digits define the precision, or granularity, of the lat/lon data. The smaller the steps, the higher the precision and the smoother things operate. INternally fs2004 much be pretty precise because one doesn't get the feeling that it's moving in steps of several feet at a time.

If I could be sure that it would not upset any other receivers I could add two more digits though.

Hopefully letting the user specify the precision would do the trick.

There's no fractions of a second in FS's time of day. If I "invented" them, what should they be? Just add something now and then? It would make little sense. I don't actually know the instant FS updates its second counter. Although there is a millisecond counter internally I think that carries on regardless of FS's simulation rates and so on.

I hope fs2004 has enough internal precision to support more digits in the lat/lon values.

That's too bad... Maybe just setting the time field of the NMEA time from the computer system clock would be jitter-free enough. My software doesn't like NMEA GGA records that have exactly the same time value in them. It drives the computations that depend on delta-time crazy.

On Linux one can call "fime" and get mililsecond time and I'm certain windoze has virtually the same call. There are many functions to format the time as well and I know they exist in the MS win world as well.

Hopefullly when Fs2004 called GPSout, GPSout could then grab the time from the system and patch it into the output record. It would certainly have plenty of jitter, bu thats' not a problem at all because the "delta-time" from the last measurement would probably be more reasonable. It would certainly be a different time for each record.

I've seen some recent low end GPS receivers that actually don't try to deliver NMEA records exactly on the second. The Holux units are good examples. The measurement time drifts all over the place, but the delta-time is good enough.

GPSout is really a nice program and thanks for providing it. I was about to try to use the "netpipe" stuff to grab the data and generate the NMEA string, but your program is much nicer than what I would have written.

Best regards,

Wayne

It wouldn't be the precision of the Lat Long but the lack of any precision in the timing. Expecting your data to be precisely every 100 mSecs apart when it can take longer to do a process switch or suffer a delay through thread timings is possibly a little bit optimistic I'm afraid.

Regards,

Pete

[Pete Dowson]

Would it be possible to set the number of digitis to the right of the decimal in the INI file for GPSout? Then it couldn't foul up any thing that relied on exactly 4 dights.

Yes, I can do that. Just more work, is all. ;-)

The digits define the precision, or granularity, of the lat/lon data. The smaller the steps, the higher the precision and the smoother things operate.

I understand all that, but with FS the only smooth thing is inside FS itself. Once you bring in other threads trying to multiprocess, and operations via asynchronous serial links, I don't see how such precision is anywhere near attainable. Check it wourself -- are your 100 mSec intervals working out at even close to 100 mSecs?

If your main processor and video cards are underloaded, and you don't have very detailed scenery or complex panels in FS, then maybe it will be regular enough.

INternally fs2004 much be pretty precise because one doesn't get the feeling that it's moving in steps of several feet at a time.

Of course, but it is because that's where the priority lies that other activities don't necessarily get time when they would otherwise want it.

My software doesn't like NMEA GGA records that have exactly the same time value in them. It drives the computations that depend on delta-time crazy.

Well, I think the best I can do is, when I see the FS second value change, reset a millisecond timer, and adjust subsequent times in the sentences accordingly. This would essentially be a fictitious time because I don't actually know WHEN FS changed its seconds value.

On Linux one can call "fime" and get mililsecond time and I'm certain windoze has virtually the same call. There are many functions to format the time as well and I know they exist in the MS win world as well.

Of course. That wasn't the problem -- you misunderstood what I said. I can "invent" the fractional seconds in the way I just described. They just won't necessarily be related to FS's actual time correctly.

Regards,

Pete

[Pete Dowson]

I attach GPSout 2.584. Try it.

I've taken your word for it that receiving programs shouldn't be upset by the 6 decimal places for Lat/Lon, but I've added a parameter as well -- "PosTo6Decimal", which should be set to "No" to make GPSout revert to 4 places. Currently it will default to 6.

The fractional seconds are being set to the number of hundredths of a second since I last saw a change in the Seconds value. This is being done just before sending the data out, so it's the most accurate I can make it.

Let me know how you get on with it.

Regards,

Pete

GPSout2584.zip

[lidar532]

I've taken your word for it that receiving programs shouldn't be upset by the 6 decimal places for Lat/Lon, but I've added a parameter as well -- "PosTo6Decimal", which should be set to "No" to make GPSout revert to 4 places. Currently it will default to 6.

Hi Pete,

Thanks for making the change! I'll give it a try and see how much difference it makes.

The fractional seconds are being set to the number of hundredths of a second since I last saw a change in the Seconds value. This is being done just before sending the data out, so it's the most accurate I can make it.

That sounds excellent. With the original version I could see that the actual delta-time was not a specific interval and did not agree with the delta-distance because my computed cross-track velocity jumped around quite a bit which means either the time and/or distance was inaccurate. I'm hoping that the added precision in lat/lon and the added time estimates will reduce the cross track velocity and ground speed jitter. If it does, then the simulator will be a valuable tool for refining the nav software.

Let me know how you get on with it.

I will let you know and I'll include some screen shots. Thanks so much for making the changes.

Best regards,

Wayne

[Pete Dowson]

With the original version I could see that the actual delta-time was not a specific interval and did not agree with the delta-distance because my computed cross-track velocity jumped around quite a bit which means either the time and/or distance was inaccurate. I'm hoping that the added precision in lat/lon and the added time estimates will reduce the cross track velocity and ground speed jitter. If it does, then the simulator will be a valuable tool for refining the nav software.

AhI don't think the actual intervals will be more accurate. As I said, I cannot tell when FS increments its seconds counter. The only accurate intervals will be from the readout with zero fractional seconds to each subsequent one in that second -- the interval from the last fractional value to the next whole second will be inaccurate because the latter is just when I see it as changed.

Furthermore, I can only time it when I deliver it to the Windows buffered file system for the attention of the serial port driver. I suspect the time between then and it actually going out could vary by more than the interval iyself.

Regards,

Pete

[lidar532]

AhI don't think the actual intervals will be more accurate. As I said, I cannot tell when FS increments its seconds counter. The only accurate intervals will be from the readout with zero fractional seconds to each subsequent one in that second -- the interval from the last fractional value to the next whole second will be inaccurate because the latter is just when I see it as changed.

Hi Peter,

I just found the following documentation regarding the fs2004 timing in the netpipes document:

Each timestamp for each frame section immediately follows the header and is of the form:

Signed 64 bit Integer—TimeStamp

DWORD—FrameNumber

DWord—TickCount

TimeStamp—simulated time. This number is in 1/256th of seconds since some moment in history. This information is really useful only when compared to the previous frame section timestamp, and it represents the simulated time that has passed since the last frame. If Flight Simulator is paused or in Slew mode this number does not change.

Perhaps it will help.

Best regards,

Wayne

[Pete Dowson]

Perhaps it will help.

Help what?

I can easily get the number of miliseconds count. I use it all the time -- see any FSUIPC Log, for example.

But that is NOT the same as FS time. FS time is simulated time, it isn't necessarily closely related to the real elapsed time at all. The GPS data output is supposed to be the simulated time of the simulated position, not any real time.

Pete

[Pete Dowson]

Perhaps it will help.

Help what?

I can easily get the number of miliseconds count. I use it all the time -- see any FSUIPC Log, for example.

But that is NOT the same as FS time. FS time is simulated time, it isn't necessarily closely related to the real elapsed time at all. The GPS data output is supposed to be the simulated time of the simulated position, not any real time.

I don't know where the NetPipes gets its time "between frames", but I also do not know when a "frame" occurs, so even if I knew it, what would it mean? So how do you propose using this NetPipes idea?

You seem to have misunderstood my previous explanations. The milliseconds I am using to fill in the fractional seconds IS accurate, at the time I stamp it. It is just that is it the time from an arbitrary zero fractional moment which I cannot pinpoint since I cannot detect exactly when the second count increased.

The other inaccuracy from the receiver end is the unpredictable delay from when I stamp it to when you receive it.

If you think Netpipes has the answer why not write your own GPSout program using NetPipes and see if that gives you more accuracy? From what I've heard about that FS facility it is anything but.

Pete