Support for non-UBlox GNSS modules?

[brocaar]

if I'm not mistaken, the only reason why the UBlox is required is the GPS time. Would it be an idea to provide an option to use "vanilla NMEA" and then calculate the GPS time using the UTC that can be retrieved from the NMEA messages?

This would mean we need a table with the known leap seconds (especially for leap seconds that might occur in the future, so these can be added in advance to the HAL without affecting the current time calculations).

I think this saves a lot of people troubles with non UBlox modules on their shields. The only downside is that the HAL must be updated before every new leap second. However, I believe these are usually announced well in advance.

Potentially it could be a fallback option for non UBlox modules?

Am I correct that the only reason for the UBlox module is the GPS time? And if so, does the above makes sense to add to the HAL, or would it be more appropriate to implement this outside the HAL?

[timcooijmans]

I thought that NMEA messages are not precise enough? default NMEA only contains 10ms resolution while UBX-NAV-TIMEGPS has 1ns resolution (with an error of-course).

[brocaar]

Thanks @timcooijmans, I wasn't aware about this. I thought the RMC sentence would always come at the exact second?

default NMEA only contains 10ms resolution

Do you have a source for this?

[timcooijmans]

Thanks @timcooijmans, I wasn't aware about this. I thought the RMC sentence would always come at the exact second?

I don't think that there's a guarantee. The Quectel L76 described a 465-485 ms latency between rise of the 1PPS and the beginning of the NMEA sequence.

default NMEA only contains 10ms resolution

Do you have a source for this?

It's ofcourse not the official source, but https://gpsd.gitlab.io/gpsd/NMEA.html#_rmc_recommended_minimum_navigation_information here's for example the RMC format description with ss.ss resolution. Also for example take a look at a Quectel L76 datasheet

[brocaar]

Thanks, I've learned something new :-) I was in the understanding that the ss.ss resolution did not matter if the message was sent at exactly the whole second (btw Quectel uses ss.sss), but you are correct that then latency between PPS and the NMEA message does matter. I wasn't aware that there could be such a high latency.

The diagram explains this well what you said.

---

To answer my own question, it can not be assumed that the time from the NMEA sentences is the accurate current time. Added to that, probably it also makes sense to use a binary protocol for the time messages, as less data == less time to send it over a serial port == lower latency between sending and processing.