[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: Wed, 16 Jan 2013 23:38:37 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2

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
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,

reply via email to

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