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

[Michael Haberler]

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