GPS time accuracy (SIM808 or similar) - process between NMEA sentences and AT command response

Question

In an SIM808 chip or similar you can get the GPS information with this AT command:

AT+CGNSINF
+CGNSINF:1,1,20150327014838.000,31.221783,121.354528,114.600,0.28,0.0,1,,1.9,22,1.0,,8,4,,,42,,

the UTC time is in the third data field as: yyyyMMddhhmmss.sss

However in the manual the function of AT+CGNSSEQ is described as: Define the last NMEA sentence that parsed.

My question is in general:

• how accurate is this time when I receive it from the serial interface of the chip?

Sub questions:

• Should I assume that the time between the AT command answer and the last NMEA message that was received by the GPS unit is variable?
• Can I compensate for delays in the systems and how?

Delays I expect:

• Difference between NMEA sentence coming in and AT command?

• Time to process NMEA sentence

• Time to read AT command and prepare response

• Serial communication time

Answer 1

The message reporting the time issued by a GPS receiver generally comes out a few hundred milliseconds after the actual time stated inside the message itself. That reported time is actually the beginning of the current measurement cycle — and if the receiver has a 1PPS output, it would correspond to the leading edge of that pulse.

Unless you take special care, the polling you do with your AT commands runs asynchronously with respect to GPS time — and the times at which the messages are issued by the receiver. Therefore, you'll always have an uncertainty that's equal to your polling period added to whatever other communication delays are in the system.

Therefore, if you're polling once a second, the time you eventually see in the message is going to be "stale" by anywhere from about 0.1 second to 1.1 second. You can reduce the upper bound by polling more often and paying attention to when the time value changes from one result to the next.

Answer 2

The SIM808 has a 1 pps output on pad 37, so for higher accuracy you could capture this in an interrupt and use it to discipline your MCU's internal sense of time.

Based on Dave's suggestion that the serial time information is "stale" it seems like you might want to do something like to take that value, prune the fraction, add 1 second, and cache it so that the next interrupt will know which second is being marked.

Or if you can configure an MCU hardware timer to reset on external input from the PPS signal and count up otherwise, you may be able to do a query and replace the fractional seconds in the result with a conversion to fractional seconds of the timer's current count.

In either case you probably want to take care if your issue one of these queries near the end of a second, where it could be ambiguous if the reply you get is reporting the old whole seconds or the new. Saving the internal sense of time from when the query is issued might work - if the reply you calculate is "earlier" than the time you asked, you probably need to add a second to fix it.