Open ajanky opened 1 year ago
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.
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
Quectel L86 = Mediatek