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

[Pablo Rodriguez Monetti]

Hi all!

As you could read in the output I have posted, I have to connect to a
NTRIP Caster of type RTCM104V3.

Is the dumping of this kind of messages completely supported now? I could read at http://catb.org/gpsd/gpsd_json.html that it is not, but maybe that web page was not updated.

I wrote a simple program, based on test_gpsmm (the test for libgpsmm that comes with the gpsd distribution), that uses a gpsd client in order to extract the RTCM information. I added a line of code to print the client buffer content (after checking that the PACKET_SET mask bit
is on) and, when running the program, I could continually get JSON objects like the following:

{"class":"RTCM3","device":"ntrip://rover:address@hidden:2101/VCON0","type":1004,"length":212,"station_id":333,"tow":164576000,"sync":"false","smoothing":"false","interval":"0","satellites":[{"ident":30,"L1":{"ind":0,"prange":85884.06,"delta":11.4575,"lockt":255,"amb":71,"CNR":47.00}"L2":{"ind":2,"prange":    7.98,"delta":24.7790,"lockt":255,"CNR":47.00}},{"ident":16,"L1":{"ind":0,"prange":253583.08,"delta":6.6055,"lockt":255,"amb":75,"CNR":42.00}"L2":{"ind":2,"prange":    7.70,"delta":8.3875,"lockt":255,"CNR":44.00}},{"ident":21,"L1":{"ind":0,"prange":275693.92,"delta":17.1535,"lockt":255,"amb":66,"CNR":47.00}"L2":{"ind":2,"prange":    6.08,"delta":34.7255,"lockt":255,"CNR":47.00}},{"ident":3,"L1":{"ind":0,"prange":107130.64,"delta":0.2000,"lockt":1,"amb":85,"CNR":36.00}"L2":{"ind":2,"prange":   16.62,"delta":17.3080,"lockt":1,"CNR":0.00}},{"ident":18,"L1":{"ind":0,"prange":207614.22,"delta":15.3885,"lockt":255,"amb":69,"CNR":47.00}"L2":{"ind":2,"prange":    6.80,"delta":16.5355,"lockt":255,"CNR":47.00}},{"ident":6,"L1":{"ind":0,"prange":248414.30,"delta":8.5470,"lockt":228,"amb":78,"CNR":39.00}"L2":{"ind":2,"prange":   12.18,"delta":16.6070,"lockt":228,"CNR":44.00}},{"ident":22,"L1":{"ind":0,"prange":135834.16,"delta":28.0685,"lockt":255,"amb":77,"CNR":44.00}"L2":{"ind":2,"prange":    8.52,"delta":42.3780,"lockt":255,"CNR":46.00}},{"ident":15,"L1":{"ind":0,"prange":157090.04,"delta":7.5165,"lockt":217,"amb":83,"CNR":39.00}"L2":{"ind":2,"prange":    8.98,"delta":-10.5435,"lockt":217,"CNR":44.00}},{"ident":31,"L1":{"ind":0,"prange":206118.76,"delta":-16.0270,"lockt":255,"amb":80,"CNR":37.00}"L2":{"ind":2,"prange":   15.28,"delta":-12.4720,"lockt":255,"CNR":44.00}},{"ident":29,"L1":{"ind":0,"prange":290123.46,"delta":2.3750,"lockt":255,"amb":72,"CNR":44.00}"L2":{"ind":2,"prange":    8.62,"delta":10.5710,"lockt":255,"CNR":47.00}},{"ident":53,"L1":{"ind":0,"prange":157685.16,"delta":2.1870,"lockt":255,"amb":127,"CNR":41.00}"L2":{"ind":2,"prange":  163.84,"delta":-262.1440,"lockt":255,"CNR":0.00}},{"ident":58,"L1":{"ind":0,"prange":160616.10,"delta":4.3800,"lockt":255,"amb":129,"CNR":43.00}"L2":{"ind":2,"prange":  163.84,"delta":-262.1440,"lockt":255,"CNR":0.00}},{"ident":55,"L1":{"ind":0,"prange":233466.36,"delta":-4.4345,"lockt":255,"amb":136,"CNR":38.00}"L2":{"ind":2,"prange":  163.84,"delta":-262.1440,"lockt":255,"CNR":0.00}}]}

However, against my expectations, the RTCM3_SET mask bit is never turned on.  It should be considered that gpsd is reporting:

gpsd:DATA: packet type 17 from ntrip://rover:address@hidden:2101/VCON0 with {ONLINE|RTCM3|PACKET}

I would like to extract the RTCM data from the gps_data_t structure instead of parsing the JSON object.

Any suggestion?

Cheers,

Pablo

On Mon, Feb 4, 2013 at 2:27 PM, Pablo Rodriguez Monetti <address@hidden> wrote:

Hi all again!

I think I could solve the problem (*).

Cheers,

Pablo

(*)

address@hidden:~# /usr/sbin/gpsd -n -S 2947 -G ntrip://rover:address@hidden:2101/VCON0 -D 4 -N
gpsd:INFO: launching (Version 3.7)
gpsd:ERROR: can't create IPv6 socket
gpsd:INFO: listening on port 2947
gpsd:PROG: NTPD shmat(32769,0,0) succeeded, segment 0
gpsd:PROG: NTPD shmat(65538,0,0) succeeded, segment 1
gpsd:PROG: NTPD shmat(98307,0,0) succeeded, segment 2
gpsd:PROG: NTPD shmat(131076,0,0) succeeded, segment 3
gpsd:PROG: PPS thread launched
gpsd:INFO: NTPD ntpd_link_activate: 1
gpsd:INFO: stashing device ntrip://rover:address@hidden:2101/VCON0 at slot 0
gpsd:PROG: no etc/gpsd/device-hook present, skipped running ACTIVATE hook
gpsd:PROG: PPS Create Thread gpsd_ppsmonitor
gpsd:PROG: PPS thread awaiting device activation
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-02-04T16:59:15.000Z (1359997155)
gpsd:PROG: PPS thread deactivationde. Not RS-232 or USB device.
gpsd:PROG: no etc/gpsd/device-hook present, skipped running DEACTIVATE hook
gpsd:INFO: hunt on ntrip://rover:address@hidden:2101/VCON0 failed (1.576436 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)
gpsd:PROG: no etc/gpsd/device-hook present, skipped running DEACTIVATE hook
gpsd:INFO: reconnection attempt on device 0
gpsd:PROG: no etc/gpsd/device-hook present, skipped running ACTIVATE hook
gpsd:INFO: gpsd_activate(): activated GPS (fd 7)
gpsd:PROG: checking client(0)
gpsd:PROG: device 0 (fd=7, path ntrip://rover:address@hidden:2101/VCON0) already active.
gpsd:PROG: switch_driver(RTCM104V3) called...
gpsd:PROG: selecting RTCM104V3 driver...
gpsd:INFO: ntrip://rover:address@hidden:2101/VCON0 identified as type RTCM104V3 (1.587642 sec @ 0bps)
gpsd:DATA: packet type 17 from ntrip://rover:address@hidden:2101/VCON0 with {ONLINE|RTCM3|PACKET|DRIVER}
gpsd:PROG: device 0 (fd=7, path ntrip://rover:address@hidden:2101/VCON0) already active.
gpsd:ERROR: overlong RTCM packet (171 bytes)
gpsd:PROG: Changed mask: {ONLINE|RTCM3|PACKET|DRIVER} with reliable cycle detection
gpsd:DATA: packet type 17 from ntrip://rover:address@hidden:2101/VCON0 with {ONLINE|RTCM3|PACKET}
gpsd:ERROR: overlong RTCM packet (171 bytes)
gpsd:PROG: Changed mask: {ONLINE|RTCM3|PACKET} with reliable cycle detection
gpsd:DATA: packet type 17 from ntrip://rover:address@hidden:2101/VCON0 with {ONLINE|RTCM3|PACKET}
gpsd:ERROR: overlong RTCM packet (171 bytes)
gpsd:PROG: Changed mask: {ONLINE|RTCM3|PACKET} with reliable cycle detection
gpsd:DATA: packet type 17 from ntrip://rover:address@hidden:2101/VCON0 with {ONLINE|RTCM3|PACKET}
gpsd:ERROR: overlong RTCM packet (171 bytes)
gpsd:PROG: Changed mask: {ONLINE|RTCM3|PACKET} with reliable cycle detection
gpsd:DATA: packet type 17 from ntrip://rover:address@hidden:2101/VCON0 with {ONLINE|RTCM3|PACKET}
gpsd:ERROR: overlong RTCM packet (171 bytes)
gpsd:PROG: Changed mask: {ONLINE|RTCM3|PACKET} with reliable cycle detection
gpsd:DATA: packet type 17 from ntrip://rover:address@hidden:2101/VCON0 with {ONLINE|RTCM3|PACKET}
gpsd:PROG: Changed mask: {ONLINE|RTCM3|PACKET} with reliable cycle detection
gpsd:DATA: packet type 17 from ntrip://rover:address@hidden:2101/VCON0 with {ONLINE|RTCM3|PACKET}
gpsd:ERROR: overlong RTCM packet (171 bytes)
gpsd:PROG: Changed mask: {ONLINE|RTCM3|PACKET} with reliable cycle detection
gpsd:DATA: packet type 17 from ntrip://rover:address@hidden:2101/VCON0 with {ONLINE|RTCM3|PACKET}
gpsd:ERROR: overlong RTCM packet (171 bytes)

On Mon, Feb 4, 2013 at 11:44 AM, Pablo Rodriguez Monetti <address@hidden> wrote:

Hi all !

I would like to know if there is a way of using gpsd (together with a gpsd client) to check whether a (locar or remote) NTRIP caster is emitting corrections or not. Also, I would like to know if it is possible to access the RTCM data through the gps_data_t structure, independently of the GPS receivers connected to gpsd? In other words, is there a way of perform this without redirecting RTCM from the NTRIP Caster to the GPS receivers (*)?

Cheers,

Pablo

(*) As indicated in http://www.catb.org/gpsd/gpsd.html:  "Ntrip caster. A URI with the prefix "ntrip://" followed by the name of an Ntrip caster (Ntrip is a protocol for broadcasting differential-GPS fixes over the net). For Ntrip services that require authentication, a prefix of the form "username:password@" can be added before the name of the Ntrip broadcaster. For Ntrip service, you must specify which stream to use; the stream is given in the form "/streamname". An example DGPSIP URI could be "dgpsip://dgpsip.example.com" and a Ntrip URI could be "ntrip://foo:address@hidden:80/example-stream". Corrections from the caster will be send to each attached GPS with the capability to accept them."