Seconds not reported correctly in SyncTime example with PPS and ZDA

[bamapookie]

I am testing with the SyncTime example, and I have noticed that the second does not increment until the first NMEA message of the second rolls in at 140 ms into the second in the example below.

I am testing using a ZDA message and an interrupt to catch a PPS signal. I am receiving the ZDA message 10 times a second (10Hz) and I have all other messages turned off. I have the PPS signal coming in on pin 4 and have an interrupt to catch it and set UTCsecondStart(micros()). Here is example output from the slightly modified SyncTime script:

19.950
19.960
19.970
19.980
19.990
19.000 // <----- Second did not increment
PPS // <---- Debug message when interrupt fires
19.010
19.020
19.030
19.040
$GNZDA,223119.990,23,06,2019,,*4F // <---- Debug echo of incoming NMEA data (delayed by ~50ms)
19.050
19.060
19.070
19.080
19.090
19.100
19.110
19.120
19.130
19.140
$GNZDA,223120.090,23,06,2019,,*4C // <---- First NMEA message of the new second
20.150 // <---- Second finally updates
20.160
20.170
20.180
20.190
20.200
20.210
20.220
20.230
20.240
$GNZDA,223120.190,23,06,2019,,*4D
20.250
20.260
20.270
20.280

I put the modified files in a gist here: https://gist.github.com/bamapookie/6cb23fd289c21d5ebafa86fc5efe6b12 I added a debug output for the NMEA message to NMEAGPS.cpp also.

Also, I noticed that the ZDA message was not included in the #if defined directive, so I added that as well.

[jaroslavas]

Have you found a workaround for this?

[bamapookie]

The workaround is to compare the seconds in the GNZDA message to the elapsed time since the PPS signal to calculate the message delay, then add the delay to the GNZDA value to get the correct time. It would be much better to handle this in the library, though.