Re: [gpsd-dev] Adding Protocol Version and Support Information to the UBX Driver

[Gary E. Miller]

Yo Elliot!

On Sat, 22 Apr 2017 23:50:21 +0200
Elliot Morrison-Reed <address@hidden> wrote:

> 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.

Cool, people have done this manually with gpsd, but automation is better.

> I would like to add
> protocol version and feature support information to the driver.

Some drivers already do this.  But usually gpsd just checks for feature
presence directly.  Just the u-blox model to feature map is quite 
large.

> *Question 1:* Is this something that would fit with the gpsd project
> philosophically?

Sure, detect and present to the user.

> 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.

Well, gpsd often sets features of the GPS it is connected to.  But
dead reckoning it not one that should be set without explicit user
request.  Usually that is done with gpsctl.


>  And the inclusion of the attitude
> message type in the protocol makes it seems like gpsd would like to
> support this information when possible.

Yes, if gpsd gets an attitude message, deconding and giving to the user
is nice.

> The response to
> this request is unfortunately too much data save in the subtype
> string.

So we make that string bigger, or if the info can be parsed, add more
places to store the new data.

> To make matters worse, it seems that the UBX_MON_VER
> information format was changed in protocol version 18.

Well, there are 18 versions.  Then you have the u-blox knockoffs.  And
consider u-blox is a SiRF knockoff.  Now you see how gpsd got so big.


> *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.

Yeah, static variables are bad, because gpsd can control more than
one GPS at a time.

Look at struct gps_device_t  in gpsd.h

> 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)

Put the data in gpd_device_t

> 2. Add new fields to gps_type_t for storing this information

gps_type is a dispatch table, not relevant.

> *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.

Yes.  Plus gpsctl.

> 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.

Well, yeah, you don't get until after you ask.  So you ask once at
startup, let it send you when it updates.


> 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.

Nope, configure on startup, wait for data.

> *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.

Easy, just send the setup message, the old GPS ignore it.  The new GPS
send the extra messages.  gpsd just decodes what it gets.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

pgpdtSAfG4AGi.pgp
Description: OpenPGP digital signature