Hi! We see you’re using an ad-blocker. We’re fine with that and won’t stop you visiting the site.
But as we’re losing ad-revenue from this then why not make a donation towards website running costs?. Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!
Joined: 24/06/2003 00:22:12 Posts: 2946 Location: Escaped to the Antipodies! 36.83°S 174.75°E
Posted: Mon Mar 27, 2006 1:41 pm Post subject:
nej wrote:
TomTom will always be a second or so behind. The TomTom receiver gets the signal and decodes it, but then has to transmit this to the PDA. NMEA messages are created once per second by the GPS Receiver, hence the 1 second delay.
I don't think this is correct. Lots of systems use the NMEA data from a GPS receiver to correct their clock and if I was subject to delays like you describe then it would be useless. _________________ Gone fishing!
Joined: Jun 16, 2004 Posts: 454 Location: London, Ingerlund
Posted: Mon Mar 27, 2006 3:55 pm Post subject:
As far as I know it is correct. NMEA sentances are definately created once per second (although it's possible that there are several "rolling" sentances, i.e if you were receiving 5 distinct sentances each distinct one should appear 0.2 seconds apart with each, say, GGA sentance appearing every second).
There is then a bit of transmission time, but even at 9600 baud for a NMEA sentance this is minimal. Plus, of course, the time for the receiving software to receive and decode the sentance and display it. Again, this is pretty minimal.
All this said, though, there is no reason to not deduct one second from the time in the program code if you really need it to be dead on.
On a hand-held GPS though, the receiver would usually be talking directly to the chip and may not have to go through the whole NMEA creation/transmitting stage. Hence the difference between the TomTom and GPSr times.
In any case, NMEA sentances are usually only accurate to 1 second (although I suppose it's possible that some high-end receivers have their own which are more accurate). Therefore they aren't ideally suited to mega-accuracy needs.
Joined: 24/06/2003 00:22:12 Posts: 2946 Location: Escaped to the Antipodies! 36.83°S 174.75°E
Posted: Mon Mar 27, 2006 5:44 pm Post subject:
nej wrote:
i.e if you were receiving 5 distinct sentances each distinct one should appear 0.2 seconds apart with each, say, GGA sentance appearing every second).
I can't see why it would space the sentances over a second. From what I have seen using my Holux SiRF II GPS receiver and Garmin GPS-V the output strings are produced in a lump every second.
nej wrote:
In any case, NMEA sentances are usually only accurate to 1 second
True, the resolution of the timestamp is 1 second, but my understanding is that it produces the GGA string EXACTLY on the second so there is no need for a fraction of a second resolution in the output data.
nej wrote:
There is then a bit of transmission time, but even at 9600 baud for a NMEA sentance this is minimal. Plus, of course, the time for the receiving software to receive and decode the sentance and display it. Again, this is pretty minimal.
Agreed. A typical GGA string is about 65 bytes which at 960 bytes / second (9600 bits/sec) would amount to 67 milliseconds of latency. It is fairly small but some applications expect better accuracy that this so I don't know if GPS receivers compensate for this of if the program is supposed to do it.
nej wrote:
All this said, though, there is no reason to not deduct one second from the time in the program code if you really need it to be dead on.
So from what you say, the GGA string outputs a time stamp which is 1 second behind UTC? I don't think so. Surely the GPS manufacturer would just add 1 second to the time so it reports the correct time?
Quote:
On a hand-held GPS though, the receiver would usually be talking directly to the chip and may not have to go through the whole NMEA creation/transmitting stage. Hence the difference between the TomTom and GPSr times.
If TomTom can't display the correct time then this is due to a bug in their software not a problem with the time reported by the GPS receiver. _________________ Gone fishing!
Joined: 24/06/2003 00:22:12 Posts: 2946 Location: Escaped to the Antipodies! 36.83°S 174.75°E
Posted: Tue Mar 28, 2006 1:32 pm Post subject:
nej wrote:
Good debate we've got going here!
Indeed!
That's an interesting site. It may be a bit out of date though, the GPS-III is about 5 years old now (I think) but it does indeed suggest that GPS receivers may display the wrong time (and Joe and Dale are fairly respected in the GPS world).
I understand about the leap second bit that they describe, I have see this happen after a hard reset.
I'm sure I have checked my Quest against the (GPS based) NTP time server we have in our lab and the times agreed, but I will try it again and see.
I did some more reading and it seems that some NMEA strings output the time with greater precision (seconds to two decimal places) but not all GPSr's will produce the strings.
Another interesting observation was that the timestamp indicated the time at the exact instant that the GPSr generated the NMEA string. So if the string was 65 bytes sent @ 9600 bps = 67 milliseconds of latency and you can add that to the timestamp to get a more accurate time.
Joined: Jun 16, 2004 Posts: 454 Location: London, Ingerlund
Posted: Tue Mar 28, 2006 5:21 pm Post subject:
'Tis indeed geeky! A couple of years ago, I was asked by work to run some tests to work out exactly how long (on average) it took for a message from one of our tracker units to leave the unit and display an updated position.
I though "ah, no problem" but it turned out to be quite tricky. That's when I first learnt about differences between GMT/UTC, leap-seconds etc etc. The first tricky question was "what's the time"... you simply can't answer that question. It was immediately apparant that I had to use GPS time as that's what the trackers use, so I ended up writing a little program to sync the PC clock with a GPS receiver I wired up to it. I had to assume that the 1 second or so delay (plus transmission time via RS232) I was going to get was the same as the processor inside the tracker was going to get from the GPS chip in there and so it could be discounted.
We needed to be accurate to about a second and it was really really hard to guarantee this was the right answer. In the end I just had auto-poll some units for updates every minute or so for a few days and take an average over a very large data-set. It turned out to be 7 seconds pretty much on the nose, which was my first reaction when first asked anyway! Shouldn't have bothered...
Posted: Today Post subject: Pocket GPS Advertising
We see you’re using an ad-blocker. We’re fine with that and won’t stop you visiting the site.
Have you considered making a donation towards website running costs?. Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!
Hi! We see you’re using an ad-blocker. We’re fine with that and won’t stop you visiting the site.
But as we’re losing ad-revenue from this then why not make a donation towards website running costs?. Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!
Forum FAQ
Search
Usergroups
Profile
Log in for private messages
Log in
