Re: [gpsd-users] GPSD 3.5 has shipped

[Ed W]

Hi

> Um.  Sorry, no. Theoretically elegant, but not practical for us.
> The problem with doing that is that we'd basically have to throw away
> eight years of hard-won knowledge about NMEA quirks of specific devices.

Can you clarify exactly why?  I don't think I follow your argument? (I 
didn't see that the rest of the email was particularly relevant, so 
probably you are meaning something too obvious for me to see?).  Just to 
be clear - I don't want to rewrite anything, nor throw away 8 years of 
anything?

Note that disregarding GPS devices, the rest of the NMEA products are a 
considerably smaller market and you don't have anything like the same 
range of devices, nor in general the complexity of inter-related 
sentences.  Therefore there is some hope that the range of 
implementations is smaller given the vastly fewer sensors available.

Note also that OpenCPN is quite widely used and whilst they don't aim 
for perfection they would appear to be satisfactorily covering a large 
proportion of devices?


> Code generation from declarative specs is a beautiful technique - in fact,
> GPSD uses it heavily, look at how jsongen.py works or the structures used
> to drive the client-side JSON parser.  But in order for it to work, the
> domain you're generating code for needs to have regularity properties that
> NMEA does not.

What "regualarity properties" are missing?  Seems that bar the 
implementation bugs, it's just a case of splitting on the comma and 
counting fields?


> For an example of the ways declarative specification can leave you *really*
> screwed, consider these comments:

I'm not sure why this is inconsistent with a simple parser for where it 
works?  If some of the code needs spaghetti then so be it - just to be 
clear I'm not recommending to rewrite any of the existing GPSD, simply 
adding existing NMEA parsers on top of what we have.  If the bulk of 
those parsers can be done easily written then so much the better


> By the time you've finished adding furbelows to your spec language to
> handle cases like these, the spec will be as complex as equivalent
> naive C code, and the interpreter/compiler for the spec language will
> be a hairball, and you've got a two-layer maintainance nightmare worse
> than if you'd just written the naive C.

Note a quick inspection shows OpenCPN have to handle the odd deviation 
from the standards.  I disagree that the code is hard to read though?

    
http://opencpn.git.sourceforge.net/git/gitweb.cgi?p=opencpn/opencpn;a=blob;f=plugins/dashboard_pi/src/nmea0183/gll.cpp;h=f779953b57e773b353c36c82e6ddb19b9f3da3c4;hb=HEAD

I'm sure you will tell me there is a chunk of stuff way more complex in 
gpsd, but can I repeat that I don't intend to rewrite gpsd?

> I love the kind of techniques OpenCPN is using, but I know their
> limitations, too.  What they're doing is trading away robustness in the
> face of slightly broken devices.  And now you know why driver_nmea0183.c
> looks the way it does.

Do you really anticipate that if we exclude GPS and AIS, that the rest 
of the relatively simple NMEA sentences are going to have the same level 
of hairballs?  I don't mean that as a challenge - genuine question?

Just to wind back to the beginning - I'm interested in using gpsd as an 
NMEA muxer.  To that extent I can build my own parser easily enough and 
be happy with 99% market coverage, but it seems interesting to expand 
gpsd if it's straightforward.  Can we not consider whether there is some 
low hanging fruit here which can be easily grabbed?



> > Depends on your long term goal, but this will be *EXTREMELY* hard to
> > get NMEA2K certification this way.
> My answer is: We'll make the code work.  What end-users and system
> integrators do with it, and how they seek certification for their
> binary images, is not our problem to solve.

You raise two points here:

1) Given that low cost, certified interfacing products appear to exist, 
are you saying that you refuse to use them at all, or that you want to 
support both them and direct integration?

2) NMEA2K isn't quite like NMEA 0183.  You now have two way talkers and 
a much expanded spec on cabling, termination and devices.  It's not 
quite standard CAN, even though the signalling is CAN.  I don't see any 
issue with hackers plugging in, but I think it's a dead end from the 
point of view of any kind of integrator wanting to sell it as "NMEA2K".

You have presumably poked around a bit with the CAN stuff already?

Regards

Ed W