Hello gpsd devs,
I am currently working on a project using a U-Blox M8L module. I would like to add attitude support for the M8L and M8U "dead-reckoning" modules to gpsd. Since the attitude features are only supported with new firmware versions, I would like to add protocol version and feature support information to the driver. This way we can check if a given message type is supported before enabling it (for example attitude reports for M8L and M8U from protocol version >= 19).
Question 1: Is this something that would fit with the gpsd project philosophically? I figure as long as we enable the attitude features automatically for the dead-reckoning receivers, it doesn't go against the "no invocation options" rule. And the inclusion of the attitude message type in the protocol makes it seems like gpsd would like to support this information when possible.
If this idea is okay philosophically, then we can move to the technical aspects.
There are multiple calls to UBX_MON_VER in the driver right now (once on init, once during the configuration call, and once after receiving an SVINFO message if there is no SW version present.) It looks like the UBX_MON_VER parser simply packs as much information into the subtype string as will fit and then leaves it at that.The response to this request is unfortunately too much data save in the subtype string. To make matters worse, it seems that the UBX_MON_VER information format was changed in protocol version 18.
Question 2: Both the protocol version and the feature support information are available in the UBX_MON_VER response and it should be straightforward to parse the information, where should I store that data when it is available? There doesn't seem to be a place where the data fits in the session state and it is expressly forbidden to add any static variables to a driver.
The three ideas I have come up with so far are:
1. Create a known and easily parsable format for the subtype string and then reparse that information if I need access to the flags internally (ie when the features are enabled/disabled)
2. Add new fields to gps_type_t for storing this information
3. Packing the information into the flags fields in gps_type_t and have a special UBX mode parser macros for the information.
I am not particularly jazzed about any of these options.
Question 3: What is the suggestion for timing/control flow in this situation? Right now it seems like we just dump a bunch of configuration data on the device when we do the mode-switch, and asynchronously receive the UBX_MON_VER response whenever it is sent. This, however, means that I wouldn't be able to enable to the attitude messages inline with the mode-switch as I wouldn't receive support information until some later point in time.
Is there some mechanism for handling situations like this? the evenk_hook function seems like it might be useful in the situation, but I haven't grokked it yet.
TLDR: I would like to add attitude support for new U-Blox dead-reckoning modules (M8L & M8U), but I am unsure about how to ensure backward compatibility for modules that don't support those features.
Thanks for your help!
Regards,
Elliot Morrison-Reed