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

[Florian Kiera]

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, retig.eu/rtk/ (source of information 
to ntrip) and https://github.com/thpe/ntripcaster (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.
Yes!
> > [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