Re: ublox F9P - rover: no RTK fix with default gpsd ublox initialisation

[Gary E. Miller]

Yo Michael!

On Wed, 12 Oct 2022 00:34:39 +0200
Michael Haberler <haberlerm@gmail.com> wrote:

> >> I will provide
> >> logs etc for these failures, and will happily switch to the builtin
> >> ntrip client once I get it working  
> > 
> > Why bother to get str2str working if you are just going to drop it?
> >   
> 
> fair enough - switched to the builtin ntrip client
> below I'm using an rtk2go nearby station which doesnt require an
> account 

I assume that otherwise the results are the same?

> I remove the previous logfiles for obvious reasons

Uh, not obvious to me, unless you mean no longer needed and awaste of
space?

> > If you are going to use --passive, then you need to manually
> > configure the receiver, which you are not doing.  
> 
> I wish I knew how to do this given the F9P's mere 1100 parameters ;) 

You will have to learn some of them.  But ubxtool makes it eassier.

From your "gpspipe -R" you mention below, it looks like gpsd is
configuring the device in a good basic configuration.  So configuration
may not be required, except to optimize for your use case.

> in theory:  one would do that via the /etc/gpsd/device-hook and issue
> a sequence of ubxtool commands, correct?

Many ways to skin that cat.  That is one way.  Another is just have the
script that starts gpsd wait 30 seconds, then initialize the receiver.

> > /dev/ublox-zed-f9p is USB native, and has no speed, so your --speed
> > is a NOP.  
> 
> done, thanks - I wasnt sure about this and occasionally got
> 'gpsd:WARN: NMEA0183: TXT: Error: txbuf alloc' suggesting port speed
> too low; a failed attempt

Which suggests you were flooding your UART1.  Much harder to flood the
USB port.

> > Why do you have Magic Hat enabled on a non-raspberry pi?
> > 
> >    # Magic Hat enabled.  
> 
> I followed https://gpsd.io/building.html
> <https://gpsd.io/building.html#_check_your_build_prerequisites> and
> scons picked up MAGIC_HAT_ENABLE by default. I tried on a different
> x86 box and it did not. 

Odd.  I can look at that if you send a full build log.

> I can investigate, but for now, rebuilt with 'scons magic_hat=no' .

Not really a problem, just odd.

> > What is this next thing?
> > 
> >    602 ?        S<sl  13:10 /usr/bin/readsb --device 0
> > --device-type rtlsdr --gain -10 --ppm 0 --net-connector
> > localhost,2947,gpsd_in --max-range 450 --write-json-every 1
> > --db-file-lt --write-binCraft-old --net --net-heartbeat 60
> > --net-ro-size 1250 --net-ro-interval 0.05 --net-ri-port 30001
> > --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104
> > --net-bo-port 30005 --json-location-accuracy 2
> > --range-outline-hours 24 --net-json-port=30012 --write-json
> > /run/readsb --quiet  
> 
> that's a gpsd client which reconnected -
> https://github.com/wiedehopf/readsb.git disabled that for now

Interesting.  Likely not a problem if it is just a gpsd client.

> > What is this next thing?
> > 
> > Oct 11 16:45:18 oe-sox gpsd[24955]: gpsd:WARN: NMEA0183: TXT:
> > Warning: PFEC inv format Oct 11 16:45:18 oe-sox gpsd[24955]:
> > gpsd:WARN: NMEA0183: TXT: Warning: PTNL inv format Oct 11 16:45:19
> > oe-sox gpsd[24955]: gpsd:WARN: NMEA0183: TXT: Warning: PFEC inv
> > format Oct 11 16:45:19 oe-sox gpsd[24955]: gpsd:WARN: NMEA0183:
> > TXT: Warning: PASH inv format Oct 11 16:45:19 oe-sox gpsd[24955]:
> > gpsd:WARN: NMEA0183: TXT: Warning: PMTK inv format  
> 
> probably a consequence of the passive mode and missing setup

I have seen them before, never tracked it down.

I think it is the u-blox comlaining about being sent an Ashtech probe:

    gpsctl:PROG: => Probing for Ashtech
    gpsctl:IO: => GPS: $PASHQ,RID*28\x0d\x0a
    gpsctl:IO: <= GPS: $GNTXT,01,01,01,PFEC inv format*32

> > AppArmor and gpsd do not play nice together:
> > 
> > apparmor module is loaded.
> > 9 profiles are loaded.
> > 9 profiles are in enforce mode.
> >   /usr/bin/man
> >   /usr/sbin/chronyd
> >   /usr/sbin/gpsd  
> 
> turned off and disabled apparmor

It was looking for /usr/sbin/gpsd, not /usr/local/sbin/gpsd, so not
a current problem.  But it can create hard to track down problems.

> btw I'm unclear why gpsd is trying to use a PPS device

Because it always does.  Instead of forceing the user to request PPS,
gpsd just auto-probes for it.  Saving another configurtaion option.

> just noting I have chrony installed if that makes any difference

It will, if you tell chrony to use it.  But since you do not have PPS,
the time will not be very good.  Best to use exteranl chimers.


> >> anything else I can provide?  
> > 
> > See above.  
> 
> if I understand you correctly it only makes sense to concentrate on
> fixing the default scenario, short of coming up with an incantation
> via the hook

Another bad assumption.  The u-blox defaults fonot work well with RTK,
you will want to configure things better.

But something is going wrong with your gpsd configuring your u-blox.
For some reason it is leaving it in NMEA mode, and not chaning it to
ubx mode.


> ran as root sans sudo:
> 
> ./gpsd --debug 5 --listenany --nowait --foreground /dev/ublox-zed-f9p
> ntrip://rtk2go.com:2101/Gutsche 2>&1 |tee
> /home/mah/src/gpsd-debug/try2/default-gpsd-output.log
> 
> output:
> https://static.mah.priv.at/pub/gpsd-debug/default-gpsd-output.txt

Your tool chain is still broken:

    gpsd:WARN: __STDC_IEC_599__ is missing

This is something new with Ubuntu.  Other distros not showing it.
Breaking IEEE 754/C99 compliance is a bad thing.  Did you run that
"scons check"?

gpsd:PROG: KPPS:/dev/ublox-zed-f9p checking /sys/devices/virtual/pps/pps0/path, 
/dev/ttyACM0

It looks like /dev/ublox-zed-f9p is just a link to the real device:
/dev/ttyACM0.  Luckily gpsd recently added support for links...

Why would you HOTBOOT???

> 'ubxtool -p HOTBOOT 127.0.0.1:2947:/dev/ublox-zed-f9p'

> 'gpspipe -R -x 10' 

You can see what the ubx says:

$ ubxtool -f  default-raw.txt  -v 3

Here is the last fix message in the file:

UBX-NAV-PVT:
  iTOW 251395000 time 2022/10/11 21:49:37 valid x37
  tAcc 23 nano 355315 fixType 3 flags x43 flags2 xeb
  numSV 26 lon 152119860 lat 471290974 height 866825
  hMSL 824167 hAcc 14 vAcc 18
  velN -1 velE -9 velD 0 gSpeed 9 headMot 16772908
  sAcc 193 headAcc 18000000 pDOP 124 reserved1 4 16732 8527
  headVeh 2182977 magDec 0 magAcc 0
    valid (validDate ValidTime fullyResolved)
    fixType (3D)
    flags (gnssFixOK diffSoln)
    flags2 (confirmedAvai confirmedDate confirmedTime)
    psmState (Not Active)
    carrSoln (Floating)

That says you have a 3D fix, and it is RTK Float.

Which is prolly what you wanted.  Unless you wanted RTK Fix.

> this gives a 3D DGPS fix, but not RTK

Sure looks like 3D RTK Float in the raw.

> I did run the same command line with --passive added, and got an RTK
> fix suggesting the builtin ntrip client worked

No need to guess, the UBX-NAV-PVT clear;y shows it.  But RTK Float, not
RTK Fix.  Did the NMEA show RTK Fix?

I take that raw file, and decode it the way that gpsd would:

$ gpsdecode < default-raw.txt

Here is the last TPV in the file, from the last UBX-NAV-PVT:

{"class":"TPV","device":"stdin","status":2,"mode":3,
   "time":"2022-10-11T21:49:37. 000Z",[...]

So, mode is 3 (3D Fix), and status is 2 (STATUS_DGPS) but status should be
4 (RTK Float).

That sure looks like a bug.  Looks like a quick fix.  Thank you for
you patience providing the logs that pin this down.

Not many people use NTRIP with F9P's yet, so likely a few more bugs in there.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpnJh3qm1noP.pgp
Description: OpenPGP digital signature