no centisecond with Quectel/Mediatek GPS chips

[ajanky]

I'm using a GPS tracker with u-blox and Quectel GPS modules, sending NMEA data with 4Hz = 250ms rate decoded with TinyGPS++
However, the Quectel data time stamp has always "00" centisecond, whereas the u-blox delivers the expected 00, 25, 50, 75 centiseconds.
The data sheet and practical test shows, that u-blox sends time as HHMMSS.xx and Quectel as HHMMSS.xxx
TinyGPS++ truncates the Quectel centiseconds.

Regardless of standards compliance, would be great to read both formats ;-)

here some sample data strings from the chips

BN220 = u-blox

$GNGGA,115939.75,5__6.07193,N,01__9.70883,E,1,12,1.06,82.1,M,42.3,M,,*7D (anonymized)
$GNRMC,115940.25,A,5__6.07194,N,01__9.70883,E,0.024,,190423,,,A*6B ### 

Quectel L86 = Mediatek

$GPGGA,141453.250,5__6.0556,N,01__9.7033,E,1,11,1.06,33.1,M,44.9,M,,*5A (anonymized)
$GNRMC,141452.750,A,5__6.0556,N,01__9.7033,E,0.00,166.46,190423,,,A,V*09

[TD-er]

The BN220 (running with the default settings) does send the NMEA sentences in bulk at the start of a second. Well at least when it has a fix.
So when receiving the messages, the offset in centiseconds (when present) doesn't really make sense.
What I do in my project is to keep track of the first bit I receive from such a bulk and consider that to be the exact start of the second.
This does work pretty well.
As soon as I fetch the sentence from the serial buffer, I also check how many bytes are there in the buffer and then I know when the first byte of that sentence was transferred.