gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gpsd-dev] Implementing support for additional message in u-blox driver


From: Michael Pratt
Subject: [gpsd-dev] Implementing support for additional message in u-blox driver
Date: Fri, 11 May 2018 11:18:52 -0400

Hello all,

I have been working with gpsd and a u-blox M8T receiver, and I have some questions about the u-blox driver implementation and the messages that are supported. 

1) gpsd supports the NAV-TIMEGPS message, which "reports the precise GPS time of the most recent navigation solution ...". Some u-blox protocols also implement similar messages for GLONASS, Galileo, and BeiDou (NAV-TIMEGLO, NAV-TIMEGAL, and NAV-TIMEBDS, respectively), but these are not supported by gpsd. Would there be any advantage to supporting these messages? The NAV-PVT message already reports UTC time, so is there any need to parse additional timing messages? In a scenario in which only non-GPS constellations are available, would the NAV-PVT message provide sufficient timing information, or would the constellation-specific message provide better information?

2) u-blox also implements a NAV-TIMEUTC message which reports a "UTC Time Solution", which is also not supported by gpsd. However, the NAV-PVT message already reports UTC time. Would implementing support for the NAV-TIMEUTC message be redundant?

3) Why are NAV_SVINFO messages required to have a payload of at least 152 bytes? This means at least 12 channels are required to be present in the message, or else the entire message is discarded. Is there a reason for this requirement? It seems to me that the minimum valid payload size is 8 bytes, and that information about any number of channels would be useful.


Thanks very much for your time and any help with these questions.

Best regards,

Michael Pratt

reply via email to

[Prev in Thread] Current Thread [Next in Thread]