I attempted to find out what the latency is by analyzing the GPS output files from Streams5. They have the following format:

$GPGGA,164025.64,0000.000000,N,00000.000000,E,1,00,0.0,000.00,M,_TIME:000000127766328256436208 $GPGGA,164025.74,0000.000000,N,00000.000000,E,1,00,0.0,000.00,M,_TIME:000000127766328257436256

Apparently, the string following $GPGGA is the GPS time and the _TIME string is the UTC time of when the measurement came in added by Streams5.

Running a modified version of Scott's time conversion code on the file this is what I saw:

$GPS time is 16:40:45.84 GPS _TIME is 16:40:45.843 2005.11.16

$GPS time is 16:40:45.94 GPS _TIME is 16:40:45.943 2005.11.16

Practically, there is no detectable latency. So I decided to manually poll the GPS and output both the GPS-generated string and the time that it came in to a file. This is what I got:

$GPGGA,164907.00,4223.690454,N,07231.644266,W,1,09,0.8,89.03,M,-33.75,M,,*61 System Time is 16:49:11.78 2005.11.21

$GPGGA,164908.00,4223.690454,N,07231.644266,W,1,09,0.8,89.03,M,-33.75,M,,*6E System Time is 16:49:12.78 2005.11.21

and so on. So the GPS receiver updates its signal at 1Hz and exactly on the second, but I found out that the system time from GetSystemTime(&systemTime); is ahead of the GPS time by several seconds. I also discovered, that if I let my program run for 10 minutes, polling the receiver every second, the system time would skip ahead a little. For the same run as above, the last two lines are:

$GPGGA,165905.00,4223.690446,N,07231.644269,W,1,09,0.8,89.03,M,-33.75,M,,*6E System Time is 16:59:9.93 2005.11.21

$GPGGA,165906.00,4223.690446,N,07231.644269,W,1,09,0.8,89.03,M,-33.75,M,,*6D System Time is 16:59:10.93 2005.11.21

So in 10 minutes the poll time went from .78 of a second to .93 and I'm not sure whether this is an anomaly or I was doing something incorrectly, but I don't know what to make of this.

–Andrey