[gpsd-users] NMEA being discarded

[Ed Simmons]

Hi everyone,

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.

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. I'm 
using scons shm_export=yes to configure the build.

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.

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. Here is a lump of output from gpsd/gpsfake 
(running from a log that was captured yesterday from the boat) - sorry 
for the noise.

gpsd:RAW: /dev/pts/9 is known to be Generic NMEA
gpsd:SPIN: select() {3 4 5 7} -> { 7 } at 1347787368.436488 (errno 0)
gpsd:UNK: polling 7
gpsd:UNK: Read 40 chars to buffer offset 0 (total 40): 
$ECVTG,000.0,T,002.0,M,0.0,N,0.0,K,A*30\x0aA,A*7F\x0a
gpsd:SPIN: packet_get() fd 7 -> 40 (0)
gpsd:UNK: Packet type 1 accepted 40 = 
$ECVTG,000.0,T,002.0,M,0.0,N,0.0,K,A*30\x0a
gpsd:UNK: Packet discard of 40, chars remaining is 0 = 
$ECVTG,000.0,T,002.0,M,0.0,N,0.0,K,A*30\x0aA,A*7F\x0a
gpsd:RAW: /dev/pts/9 is known to be Generic NMEA
gpsd:RAW: packet sniff on /dev/pts/9 finds type 1
gpsd:RAW: raw packet of type 1, 
40:$ECVTG,000.0,T,002.0,M,0.0,N,0.0,K,A*30\x0a
gpsd:IO: <= GPS: $ECVTG,000.0,T,002.0,M,0.0,N,0.0,K,A*30
gpsd:PROG: ECVTG extends the reporting cycle.
gpsd:PROG: ECVTG ends a reporting cycle.
gpsd:DATA: packet from /dev/pts/9 with {ONLINE|PACKET|REPORT}
gpsd:SPIN: packet_get() fd 7 -> 0 (11)
gpsd:RAW: /dev/pts/9 is known to be Generic NMEA
gpsd:SPIN: select() {3 4 5 7} -> { 7 } at 1347787368.936486 (errno 0)
gpsd:UNK: polling 7
gpsd:UNK: Read 33 chars to buffer offset 0 (total 33): 
$ECZDA,133836.88,15,09,2012,,*77\x0aK,A*30\x0aA,A*7F\x0a
gpsd:SPIN: packet_get() fd 7 -> 33 (0)
gpsd:UNK: Packet type 1 accepted 33 = $ECZDA,133836.88,15,09,2012,,*77\x0a
gpsd:UNK: Packet discard of 33, chars remaining is 0 = 
$ECZDA,133836.88,15,09,2012,,*77\x0aK,A*30\x0aA,A*7F\x0a
gpsd:RAW: /dev/pts/9 is known to be Generic NMEA
gpsd:RAW: packet sniff on /dev/pts/9 finds type 1
gpsd:RAW: raw packet of type 1, 33:$ECZDA,133836.88,15,09,2012,,*77\x0a
gpsd:IO: <= GPS: $ECZDA,133836.88,15,09,2012,,*77
gpsd:DATA: ECZDA time is 1347716316.880000 = 2012-09-15T13:38:36.88Z
gpsd:PROG: ECZDA extends the reporting cycle.
gpsd:PROG: ECZDA ends a reporting cycle.
gpsd:DATA: packet from /dev/pts/9 with {ONLINE|TIME|PACKET|REPORT}
gpsd:SPIN: packet_get() fd 7 -> 0 (11)
gpsd:RAW: /dev/pts/9 is known to be Generic NMEA

And here is an excerpt of the log that it's using for GPSFAKE:

$SDDBT,9.8,f,2.9,M,1.6,F*0B
$SDDPT,2.9,*72
$VWMTW,22.30,C*21
$VWVHW,265.5,T,267.5,M,0.00,N,0.0,K*66
$ECGLL,5107.128,N,00118.568,E,133836.88,A,A*7F
$ECVTG,000.0,T,002.0,M,0.0,N,0.0,K,A*30
$ECZDA,133836.88,15,09,2012,,*77
$ECMWV,261.5,R,4.7,N,A*38
$SDDBT,9.5,f,2.9,M,1.6,F*06
$SDDPT,2.9,*72
$VWMTW,22.30,C*21
$VWVHW,265.5,T,267.5,M,0.00,N,0.0,K*66
$ECGLL,5107.128,N,00118.568,E,133838.89,A,A*70
$ECVTG,000.0,T,002.0,M,0.0,N,0.0,K,A*30
$ECZDA,133838.89,15,09,2012,,*78
$ECMWV,277.0,R,7.0,N,A*3E
$SDDBT,9.5,f,2.9,M,1.6,F*06

(I've manually removed the extra line breaks between the lines in the 
log...)

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.

Does anyone have any helpful pointers that they could share to help in 
debugging this? It appears there is less of an issue (evidence of less 
data discarded) when I slow down the speed of running through the log 
using GPSfake, but obviously this isn't an available option for us in 
the system on the boat.

I can provide a longer log of the C120's NMEA output if it's helpful, 
and I'm happy to share my modified GPSD source. There's little that's 
changed over the original download from catb.org, which, by the way, 
keeps taking me on interesting digressions... :-) thanks Eric!

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. 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!

Thanks in advance,

Best

Ed