[Top][All Lists]

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

Re: [gpsd-users] NMEA being discarded

From: Ed Simmons
Subject: Re: [gpsd-users] NMEA being discarded
Date: Thu, 17 Jan 2013 09:12:53 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2

On 17/01/13 00:51, Eric S. Raymond wrote:
Ed Simmons <address@hidden>:
Hm.  Can we have that code? I'm especially interested if the additional
sentences are stock NMEA.
Sure, I'd be glad to have it in the codebase - I've added things to
do with Raymarine sentences. For one reason or another GPSD was not
accepting some of the sentence headers as being valid. Once I
understood the output of the higher level of debug it became clear
that the parser was not happy with some of the prefixes. A couple of
additions to the packet sniffer cleared this up and I was happy to
see my parser code working.

How do I go about submitting these changes?
Make diffs of whatever files you changed against the base release you
forked from and mail them to to me.  The NMEA code has been pretty
stable for the last couple years; I don't anticipate a lot of
difficulty with the merge.

I'll also want a capture log from the boat's NMEA bus.  It doesn't
have to be huge, just a representative sample of the traffic.

No problem, it'll be a few days until I get to this, must clear the backlog of PCB designs etc. before getting back into this code...

It works flawlessly in other applications with less of the
proprietary raymarine stuff flying about. My somewhat crude solution
to this is to compile GPSD on the machine doing the logging with
only the two possible baud rates in the switch in autobauding. This
makes it rock solid, I didn't investigate further... also I think
this problem was exacerbated by the high proportion of the received
sentences it was discarding, that would probably not have helped
Ah, that makes complete sense actually.  I think your diagnosis is
correct and you did the right thing to cope with it.  Now I'm
wondering if maybe I ought to hack the configuration machinery to give
people building from source finer-grained choices about which baud rates
to support.  Maybe max_bps and min_bps switches?

                        for example I spent ages looking for
how to get shared memory export working. If it is publicly
documented, I couldn't find it.
Sorry, I didn't realize I hadn't done that yet.  I'll update the
manual page for the client-side libraries.
I looked and the shm stuff is actually pretty well documented in
recent releases. Look near the end of the Client HOWTO on the website.

Ok - thanks, I suspect I found it in the end as we now have working code that uses the SHM export, however I recall this being painful at the time.

                                Also, drawing people's attention to
the provided init scripts etc. would have saved me loads of time,
but damn am I glad I found it in the end!
Where would that pointer have been more useful?  In the FAQ, the
source-build instructions, the INSTALL file, or somewhere else?
Probably the source build instructions is the best place. It seems
logical to draw the attention of the user to the existence of the
scripts at the crucial moment just after you've run sudo scons
install !!
I in fact pushed a description to that exact spot about two hours
ago, before I got your second mail. :-)

Thanks Eric!

reply via email to

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