Re: [gpsd-users] Using gpsd as a NTRIP Client

[Eric S. Raymond]

Pablo Rodriguez Monetti <address@hidden>:
> Eric, is there a known problem when the ntrip source is using a TCP output
> mode?
> 
> When ntripserver is running in UDP output mode, gpsd can connect well to
> the caster:
> 
> address@hidden:~# /usr/sbin/gpsd -n -P /var/run/gpsd-rtcm.pid -S 2948
> ntrip://rover:address@hidden:2101/VCON0 -N -D 3
> gpsd:INFO: launching (Version 3.7)
> gpsd:ERROR: can't create IPv6 socket
> gpsd:INFO: listening on port 2948
> gpsd:INFO: NTPD ntpd_link_activate: 1
> gpsd:INFO: stashing device ntrip://rover:address@hidden:2101/VCON0 at slot 0
> gpsd:INFO: gpsd_activate(): activated GPS (fd 6)
> gpsd:INFO: device ntrip://rover:address@hidden:2101/VCON0 activated
> gpsd:INFO: running with effective group ID 0
> gpsd:INFO: running with effective user ID 65534
> gpsd:INFO: startup at 2013-05-06T16:02:58.000Z (1367856178)
> gpsd:INFO: ntrip://rover:address@hidden:2101/VCON0 identified as type
> RTCM104V3 (1.835601 sec @ 0bps)
> gpsd:DATA: packet type 17 from ntrip://rover:address@hidden:2101/VCON0 with
> {ONLINE|RTCM3|PACKET|DRIVER}
> gpsd:ERROR: overlong RTCM packet (155 bytes)
> gpsd:DATA: packet type 17 from ntrip://rover:address@hidden:2101/VCON0 with
> {ONLINE|RTCM3|PACKET}
> gpsd:ERROR: overlong RTCM packet (155 bytes)
> gpsd:DATA: packet type 17 from ntrip://rover:address@hidden:2101/VCON0 with
> {ONLINE|RTCM3|PACKET}
> 
> However, when ntripserver is running in TCP mode gpsd cannot correctly get
> connected:
> 
> address@hidden:~# /usr/sbin/gpsd -n -P /var/run/gpsd-rtcm.pid -S 2948
> ntrip://rover:address@hidden:2101/VCON0 -N -D 3
> gpsd:INFO: launching (Version 3.7)
> gpsd:ERROR: can't create IPv6 socket
> gpsd:INFO: listening on port 2948
> gpsd:INFO: NTPD ntpd_link_activate: 1
> gpsd:INFO: stashing device ntrip://rover:address@hidden:2101/VCON0 at slot 0
> gpsd:INFO: gpsd_activate(): activated GPS (fd 6)
> gpsd:INFO: device ntrip://rover:address@hidden:2101/VCON0 activated
> gpsd:INFO: running with effective group ID 0
> gpsd:INFO: running with effective user ID 65534
> gpsd:INFO: startup at 2013-05-06T16:04:48.000Z (1367856288)
> gpsd:INFO: hunt on ntrip://rover:address@hidden:2101/VCON0 failed (0.837023
> sec since data)
> gpsd:WARN: device read of ntrip://rover:address@hidden:2101/VCON0 returned
> error or packet sniffer failed sync (flags {ERROR})
> gpsd:INFO: closing GPS=ntrip://rover:address@hidden:2101/VCON0 (6)
> 
> although the RTCM is correctly received from other clients.

I was baffled by this report for a long time.  The TCP and UDP code paths
are very similar, only differing in the mechanics of how the device is
opened.  I couldn't imagine circumstances that would break one but not the
other.

But.  In the process of fixing the bug described at

      https://savannah.nongnu.org/bugs/index.php?36409

I found a subtle failure mode of the packet getter that might explain it.
Before the fix, the packet getter would fail sync if it got a read that
contained the head of a valid packet but not the entire packet.

This bug didn't bite in the UDP case because UDP datagrams are both
sent and received as single atomic units; one NTRIP datagram turns
into the payload of one read from the socket.

It almost never manifested when talking to GPSes over serial
links because they too ship sentences as (in effect) datagrams - they
buffer them up and send them in one write operation with a payload
well below below Unix's minimum-atomic-write size, so GPSD gets
that payload in a single read.

Only in the TCP/IP case are read and write boundaries often not going
to coincide with packet boundaries.  I think that's what you were tripping
over, and a recent revision appears to fix it. Please try the repository
head version and tell me if NTRIP over TCP/IP works now.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>