[Top][All Lists]

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

Re: [gpsd-users] GPSD 3.5 has shipped

From: Ed W
Subject: Re: [gpsd-users] GPSD 3.5 has shipped
Date: Tue, 17 Apr 2012 17:54:42 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1


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 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?;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?


Ed W

reply via email to

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