Closed will127534 closed 6 years ago
Hmm, yeah they use the identifier "ubx7" in forwarder code and gps implementation in which an unsolicited packet called UBX-NAV-TIMEGPS is enabled which is explicitly parsed.
The use of ubx is not even nicely abstracted into the libloragw but is exposed all the way up to the forwarder which defines a gps_thread calling the ubx parse function explicitly, so the stack seems rather hardcoded to uBlox GNSS'es at the moment and not trivially interchangeable with another way to get the time. Can't seem to grasp why the standard NMEA RMC time indication is not enough, though.
A quick look at the datasheet of an M8-series uBlox that I've been testing it seem like it also supports the same TIMEGPS packet. But whether the details of parameters and data is the same as the 7-series I haven't studied. Found also this mention of someone using a 6-series GPS.
This UBX cmd should works on ubx6, ubx7 and ubx8 series chip, so variant of the module like Neo-6/7/8 Max-6/7/8 etc. should all works. I've choose Max-7 series for ver2.1 though, I've used it for my high altitude balloon before, and some modules left in the part box. Just tested ver2.1 with Max-7 and it works with the libloragw.
I thought that LoRa gateway support normal GPS with NEMA output, but it seems to support only uBlox module, because it is using uBlox's UBX protocol for time adjustment. So it might needs to change to uBlox module(MAX-7 series maybe) in the future.