[Top][All Lists]

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

Re: [Question] gpsd, ntrip & C94-M8P (u-Blox)

From: Florian Kiera
Subject: Re: [Question] gpsd, ntrip & C94-M8P (u-Blox)
Date: Mon, 4 May 2020 09:46:29 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

Yo Gary and Greg!

Am 30.04.20 um 21:06 schrieb Gary E. Miller:
Yo Florian!

On Thu, 30 Apr 2020 12:49:14 +0200
Florian Kiera<address@hidden>  wrote:

Thanks to Greg I am now able again to use gpsd to receive the
correction data from my NTRIP Caster. (the NTRIP Caster stream is
good again!)
Good news.

To give a short explanation how I solved my issue before:
Greg gave me a huge hint to check out net_ntrip.c line 453. (You
might already know:) In this line it checks the "ICY 200 OK"
feedback. However, because my caster sends "ICY 200 OK\x0d\x0a" gpsd
counted it as error and closed the connection. I just changed
net_ntrip.c line 33 '#defineĀ  NTRIP_ICY "ICY 200 OK"' to "ICY 200
OK\x0d\x0a", installed it anew and now the "good stream" works again.
This make no sense.  The strstr() only checkes the leading part of
"ICY 200 OK", so any trailing data is ignored.

Why would strstr() match the longer string and not the shorter one?
Your patch broke a test that was broknn.  Two wrongs that made a right.

I broke net_ntrip.c in commit b8f88d70088df944ea122de7ecb04ac36ba1af8b
on April 12th of 2020.

I changed an == into a !=.

Fixed in git head.  Please test.
Solved in the latest git head! Thank you! :) It now starts without giving any errors back.
Later I will try to change it on the ntrip casters side to not run a
"custom ugly solved" gpsd.
Most people can not change their casters.  Many are run by universities
and governements that do not change quickly.  Best to make gpsd work
with more casters.
I run one I found as open source, (source of information to ntrip) and (the caster).
The receivers computer
seems to be the unstable thing here. After some time and odd outputs
in dmesg, it kicks and adds the receiver to a new port address
(ttyACM1 cause ttyACM0
Sadly this is a common USB failure.  Be sure you receiver is connected to
a UBS 2.0 port, not a USB 3.0 port, and has lots of spare power.
gpsd:ERROR: Write to RTCM sink failed, type u-blox
gpsd:ERROR: SER: device open of /dev/ttyACM0 failed: No such file or
directory - retrying read-only
Should be obvious why.
[10994.628969] usb usb3-port1: disabled by hub (EMI?), re-enabling...
Try a different hub.  I have yet to find a USB 3 hub that is reliable.
More than a few USB 2.0 are also falkey.  I have tried many.

I will try around and hope it will solve it. Thank you for the tip!

So it all didnt worked due to the odd output "ICY 200 OK\x0d\x0a"
(the hexadecimal "ok" is odd)
Not odd, that is just CR, LF.
Oh... OK, noted. My bad.
As always the solution must've been that simple... UGH. Thank you for
your patience and tips!
Sadly, we are not done yet.  This still doe snot smell quite right.
Actually thought it was a caster issue after all. However, you fixed it. Thank you!
P.S. I only used "gpsd -G ntrip://usr:pw@ip:port/STREAM" to test if
gpsd is able to open a stream to my caster. That gpsd lacks a
receiver here in this command is clear. It just had testing purpose
(learning gpsd in small steps) and didn't unnecessarily spammed me
with the receivers NMEA/TPV output.
fgrep is your friend.

Didn't knew what to grep for, so I just wanted to start with small steps and find it out.

Guess it works for now. I will need to watch out for the USB Hubs still, however gpsd does what it needs to do at that point.

Regards Florian

reply via email to

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