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

[Gary E. Miller]

Yo Michael!

Glad to hear you are running well now.

On Thu, 13 Oct 2022 09:09:02 +0200
Michael Haberler <haberlerm@gmail.com> wrote:

> Hi Gary,
> 
> > Am 13.10.2022 um 02:21 schrieb Gary E. Miller <gem@rellim.com>:
> > 
> > Yo Michael!
> > 
> > I just pushed a patch that fixes gpsd reporting of RTK status
> > from ubx messages.  Please test.  
> 
> done
> 
> RTK Float fix comes up right away with the command line
> 
>       gpsd --debug 1 --listenany --nowait /dev/ublox-zed-f9p
> ntrip://rtk2go.com:2101/Gutsche
> 
> so fix detection works, internal ntrip client works, no more external
> str2str correction feeder - wonderful! track + speed values being
> reported as well - great, so my use case will work just fine
> 
> thanks a lot!
> 
> 
> 
> I'm under water for a few days
> 
> then I will test with an M8P receiver and report - this one:
> https://gnss.store/neo-m8p-gnss-modules/90-elt0078.html
> 
> also, will try out the other ntrip casters including my own based on
> https://github.com/Stefal/rtkbase
> 
> also, I'll connect a second M7N USB gps and report - I record that as
> well for comparison (json lands in influxdb for ex-post staring at
> plots)
> 
> I note the 'Oct 13 08:44:29 oe-sox gpsd[115746]: gpsd:WARN: NMEA0183:
> TXT: Error: txbuf alloc' message is still around although all USB
> connections, happy to help nail that one if you are interested
> 
> 
> btw my funny device name  /dev/ublox-zed-f9p comes from an udev rule
> for stable device names - if you plug/unplug a lot, relying on
> something like /dev/ttyACM0 is asking for trouble as the device name
> might change to say /dev/ttyACM2 or somesuch
> 
> with this udev rule the name /dev/ublox-zed-f9p the underlying device
> name may change and gpsd still gets the right path to work with: #
> Ublox ZED-F9P 1546:01a9 SUBSYSTEM=="tty", ATTRS{idVendor}=="1546",
> ATTRS{idProduct}=="01a9", SYMLINK+="ublox-zed-f9p", TAG+="systemd",
> ENV{SYSTEMD_WANTS}="gpsdctl@%k.service"
> 
> 
> 
> a question regarding the built-in ntrip client:
> 
> There's the SOURCETABLE mechanism for listing what stations are
> available so far I've used ntrip URI's only with an explicit mount
> point like the one above
> 
> should a client able to fetch the SOURCETABLE and select the closest
> matching station? or is that a whacky idea?
> 
> best regards
> 
> Michael
> 
> 
> 
> 
> 
> 
> 
> > 
> > On Thu, 13 Oct 2022 00:38:06 +0200
> > Michael Haberler <haberlerm@gmail.com> wrote:
> >   
> >> you mentioned an issue with floating point arithmetic suggesting a
> >> toolchain issue:  
> > 
> > Yup.
> >   
> >>> Am 12.10.2022 um 03:44 schrieb Gary E. Miller <gem@rellim.com>:
> >>>   
> >> ...  
> >>> 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"?    
> >> 
> >> yes - I even installed a pristine Debian to exclude a past blunder
> >> - no change  
> > 
> > Here is what C99 says:
> > 
> >   6.10.8 Predefined macro names
> > 
> >   The following macro names are conditionally defined by the
> >   implementation: _ _STDC_IEC_559_ _ The integer constant 1,
> > intended to indicate conformance to the specifications in annex F
> > (IEC 60559 floating-point arithmetic).
> > 
> > So you are right, the proper macro is 559, not 599.  Simple fix,
> > pushed now.
> > 
> > Thanks for digging on that.
> > 
> > But that is just a warning to run "scons check".  When "scons check"
> > runs OK, then there should not be any IEEE 754 issues.  Your check
> > runs fine, so you don't have a float problem.
> > 
> > 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  
> 




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

pgpcd6xHzD8_z.pgp
Description: OpenPGP digital signature