gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pablo Rodriguez Monetti
Subject: Re: [gpsd-users] Using gpsd as a NTRIP Client
Date: Mon, 4 Feb 2013 14:27:05 -0300

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


reply via email to

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