Re: [gpsd-users] GPSD 3.5 has shipped

[Eric S. Raymond]

Ed W <address@hidden>:
> Would you be willing to accept patches to take a very large amount
> of NMEA 0183 sentences and decode them so they are emitted as json?
> I'm thinking of something like the coverage from OpenCPN which
> decodes quite a substantial number of sentences for wind speed,
> heading, depth, etc?

Maybe. You'll find the problem with adding such decodings is not at the driver
level but in (a) defining structures to unpack them into, and (b) getting
the client bindings right.  

One relatively minor issue is that we're using 32 type bits in the
gps_mask_t type. To add more data-item types to the master union 
we'll have to actually use the fact that the mask type is defined 
as uint64_t.  We could trip over toolchain issues here so this will
take careful port testing.  But at least this is a cost we'll only
pay once.

The more significant problem is that for each new sentence we want to 
support, the following steps need to happen:

(a) We define a new C struct to unpack the sentence data into.
(b) We define a JSON serialization of that C struct for the daemon to 
    to ship to clients.
(c) The JSON serialization must be documented for the gpsd_json.8 page.
(d) On the client-library side, we need deserialization code to
    read the content of the JSON from the daemon into a client-side copy 
    of the struct.
(e) We need test loads containing the sentence.

Go right ahead and add all the sentences you want.  But I won't take a
patch that doesn't do the *whole* job for each one - and that means not
just the fun, easy part at the NMEA driver level but the hard part,
the JSON marshalling and unmarshalling for the clients.  And the 
documentation.

> I'm not sure that I yet understand how NMEA2K will fit into all of
> this - do you have some sketch outlines of what you are looking at?
> What kind of interface hardware? Quite interested to see how this
> progresses!!

Support for reading CAN frames from a controller card has been accepted
into the Linux kernel.  We get to assume we can read CAN frames from a
special socket, leaving us with the job of recognizing and unpacking NMEA2000
frames. At that point it's almost like handling a new type of binary GPS.

I said "almost" because the CAN frames aren't self-describing.  This means we
won't be able to use the normal data flow through the packet sniffer.  Instead
there'll need to be special-case code that associates the NMEA2000 driver
with the special kernel socket.  Feeding it test loads is going to be something
of a pain in the ass.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>