Atlantic Explorer GPS report

Julia Hummon

UHDAS Team

Dec 2019

The BIOS ship Atlantic Explorer runs UHDAS for ADCP data acquisition. UHDAS requires position for ADCP processing and records GPS positions from 3 GPS sources. One is specified as "primary" and is used for the ADCP processing. The rest are monitored for health.

All sources are serial (no UDP, for instance). Every GPGGA message gets a timestamp from the UHDAS computer. On all ships, we try to have the computer using an NTP time server. On Atlantic Explorer we are using a timeserver and it is working.

There are several types of plots we can make with the time data from one instrument. It is easiest if these are plotted in seconds:

  1. difference in time between UHDAS computer clock and GPGGA timestamps:

    If the computer is using an NTP server, and that NTP server is working, we would expect that this number would be around zero, but pretty constant, i.e. the computer time is very close to the GGA time.

    This would be true even if there are gaps in the data (due to 'stop recording').

    If the computer time is not synced to an ntp server, then it would have a slow drift compared to the GPGGA messages

  2. sequential difference in UHDAS computer timestamps (time span between messages):

    The sequential differences should be quite constant, but there might be isolated large gaps (eg. acquisition was halted for a period of time).

    If there are gaps of a few seconds and compensating smaller gaps, then there could be a buffering problem: all the messages are coming in but some are late, so others arrive as a cluster. We can't know from the computer time whether any messages were actually lost.

    If the number is negative, then the computer clock went backward.

  3. sequential differences in the GGA timestamps (time span between messages):

    During a period of continuous data recording,

    • there should not be any gaps
    • the time between messages should be absolutely constant

    If there are gaps not related to stop-start recording, then GPS lines are getting lost. That could be due to

    • missing at the source
    • bad checksum (so the message is not written)

    If the number is negative, then the GPS is broken in some way

    If the time between messages is not constant, this indicates a problem with the GPS timing -- one example is shown below.

All of the following figures have 3 rows, with the rows sharing the same time axis.

ADU800 timestamps for 1 day

This is what we hope to see in all cases:

This plot gives us confidence in the UHDAS computer timestamps, the ADU800 GPS timestamps, and NTP.

01_adu800-timestamps-zoomzoom

JRC timestamps for 1 day

This looks good except for the JRC timestamps, which are 5.8 seconds in the future compared to the UHDAS computer time:

02_JRC-timestamps-zoomzoom

GPS timestamps for the Simrad MX612; all days

In panel 1 we see the GPGGA timestamps going backwards, then forward. Panels 2 and 3 will be shown later, with more detail.

We can tell when it went backward, but UHDAS was not logging data when it went forward.

$GPGGA,225459.0,2630.6255,N,07223.3258,W,2,10,0.8,6.5,M,-44.0,M,5.0,0138*4D
$GPGGA,225500.0,2630.6258,N,07223.3256,W,2,10,0.8,5.0,M,-44.0,M,6.0,0138*46
$GPGGA,225501.0,2630.6265,N,07223.3256,W,2,10,0.8,4.4,M,-44.0,M,7.0,0138*4D
$GPGGA,225502.0,2630.6274,N,07223.3260,W,2,10,0.8,5.3,M,-44.0,M,7.0,0138*4D
$GPGGA,225503.0,2630.6282,N,07223.3264,W,2,10,0.8,6.9,M,-44.0,M,7.0,0138*48
$GPGGA,225504.0,2630.6287,N,07223.3264,W,2,10,0.8,7.6,M,-44.0,M,4.0,0138*47
$GPGGA,225505.0,2630.6289,N,07223.3262,W,2,10,0.8,7.9,M,-44.0,M,5.0,0138*40
$GPGGA,225506.0,2630.6292,N,07223.3263,W,2,10,0.8,7.8,M,-44.0,M,6.0,0138*4A  ## 11/23  22:55:07
$GPGGA,225323.0,2630.6298,N,07223.3265,W,2,10,0.8,7.0,M,-44.0,M,7.0,0138*4E  ## jumped back
$GPGGA,225324.0,2630.6306,N,07223.3266,W,2,10,0.8,6.0,M,-44.0,M,7.0,0138*4D
$GPGGA,225325.0,2630.6313,N,07223.3267,W,2,10,0.8,5.4,M,-44.0,M,7.0,0138*4E
$GPGGA,225326.0,2630.6318,N,07223.3270,W,2,10,0.8,5.8,M,-44.0,M,4.0,0138*4F
$GPGGA,225327.0,2630.6324,N,07223.3273,W,2,10,0.8,6.8,M,-44.0,M,5.0,0138*40
$GPGGA,225328.0,2630.6331,N,07223.3275,W,2,10,0.8,7.4,M,-44.0,M,6.0,0138*43
$GPGGA,225329.0,2630.6340,N,07223.3278,W,2,10,0.8,7.5,M,-44.0,M,7.0,0138*49
$GPGGA,225330.0,2630.6350,N,07223.3281,W,2,10,0.8,7.1,M,-44.0,M,7.0,0138*42
$GPGGA,225331.0,2630.6355,N,07223.3281,W,2,10,0.8,6.3,M,-44.0,M,7.0,0138*45
$GPGGA,225332.0,2630.6355,N,07223.3281,W,2,10,0.8,6.0,M,-44.0,M,4.0,0138*46
$GPGGA,225333.0,2630.6356,N,07223.3283,W,2,10,0.8,6.6,M,-44.0,M,5.0,0138*41
$GPGGA,225334.0,2630.6363,N,07223.3286,W,2,10,0.8,7.1,M,-44.0,M,6.0,0138*40
03_gpsnav-timestamps

GPS timestamps for the Simrad MX612; all days

Zooming in on the y-axis to look at the time differences we see

03_gpsnav-timestamps-zoom

GPS timestamps for the Simrad MX612; 15 hours

This is a zoom in on the adjustment period of the previous plot

03_gpsnav-timestamps-zoomzoom

GPS timestamps for the Simrad MX612; 180 sec

This is a zoom in on the adjustment period of the previous plot

03_gpsnav-timestamps-zoomzoomzoom

GPS timestamps for the Simrad MX612; tail end of the transition

This shows the actual $GPGGA messages (the timestamp part) and the messages corresponding to the jumps shown.

04_GPGGA