Re: [gpsd-users] NMEA being discarded

[Ed Simmons]

Hi Eric,

Thanks for your reply!

On 16/01/13 15:57, Eric S. Raymond wrote:
> Ed Simmons <address@hidden>:
> > I've been using GPSD to build an automated voyage logging system on
> > a boat, we have onboard a huge collection of devices that all output
> > NMEA. Most of this data arrives at a Raymarine C120 chart plotter
> > (by way of NMEA, seatalk etc) and is output as nmea at 38400 baud.
> Apologies for the long delay in replying.  I got distracted from gpsd
> work by trying to rescue notification service after CIA crashed; ever since,
> the list and the bugtracker have been so quiet that I only just got around
> to excavating my back mail.
>   
> > I'm using ubuntu 11.04 (server and desktop releases, working on my
> > desktop and running it for real on the server) and a modified
> > version of GPSD, I have added extra NMEA sentence parsers to the
> > driver_nmea0183.c and expanded the attitude_t struct to hold the
> > extra data we need.
> 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?

> > I have the following observations:
> >
> > The auto baud detection of GPSD fails for the 38400 baud data unless
> > I increase the usleep duration from 200ms to 400-500ms in the baud
> > hunting code. This took some time to discover, but still doesn't
> > make the port detection 100% reliable.
> You may want to try the trick documented in the FAQ entry titled "Why
> is there no option to fix baud rate?".  I'm reluctant to increase the
> usleep duration because doing that dramatically slows down
> synchronization in the normal range of speeds (4800-19200), and many
> UART/driver combinations seem to handle 38400bps without difficulty
> (I've tested here, of course).

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 autobauding.
> > This may be related to the next point, which is that when running
> > GPSD/GPSFAKE with -D 8 it appears that a large number of sentences
> > are discarded despite the fact they look ok when viewing the serial
> > data directly, or logging it.
> > It looks like there's some junk being detected at the end of some
> > lines, but this is not visible in the log or when viewing the serial
> > data in a serial port terminal.
> That's disturbing. And makes me want to know at what level the
> data is being lost.  Do you see all the bytes coming through at -D8
> level?
I think that was just me not reading it properly ;)
> > Any help would be greatly appreciated, since as an experienced
> > programmer who's relatively new to GPSD's innards I'm finding
> > there's a ton of code to grok before I realise where I should be
> > looking.... this is an area where the documentation appears to fall
> > a little short of the mark - 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.
Thanks - there were a few gotchas if I recall - shame I can't remember 
the specifics. I should really dig up the code and see.
> >                                 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 !!

Let me know how to submit patches or whatever, I'd be glad to contribute 
to gpsd. Thanks for taking the time and effort to make gpsd, it's made 
light work of something that could have been a horrible task.

Thanks again, best regards,
Ed