Re: how to forward RTCM data to gpsd?

[Gary E. Miller]

Yo Kristoff!

On Sat, 12 Dec 2020 00:55:10 +0100
Kristoff <kristoff@skypro.be> wrote:

> I decided to have a good fresh look at the code of ifgps.c the next 
> morning. It turns out that it is actually a lot easier then what I
> first thought.
> The format is actually very simple: every byte starts with 2 bits
> '01', followed by 6 bits of data in *reverse* in order. That's it.

If you can make that into the form of a comment to isgps.c then I'll add
it to the code.  As RTCM3 gets more common, the isgps.c code, which is
RTCM2, will get used less.

> I created a small python application that functions as TCP-server so
> I could pipe the received dgps signals into 'nc ... | gpsdecode' or
> gpsd. I managed to get dgps data from my receiver -just the signals
> as received over the air without any processing- into gpsdecode and
> gpsd, ... most of the time! Quite often, both gpsdecode and gpsd
> seams to lose synchronisation with the incoming dgps signals
> (Although my own dgps-decoding python code I had running at the same
> time did not have any issues). (*)

You can turn up the debug level and see if gpsdecode provides any helpful
error message.

> Gpsd does forward the received dgps messages to the ublox-8 as
> expected. The net-result is that the receiver switches from the mode
> "3 constellation (gps, glonass, Galileo) + egnos" to "only gps +
> dgps". Stopping the rtcm messages from reaching the gnss receiver
> made it switch back to 3 constellation + egnos. (**)

Good.

> So, unless I am completely wrong, this means that the rtcm messages
> do are received and processed by the ublox gnss receiver.
> (Somebody correct me if I am wrong)

Seems right to me.

> A note concerning the accuracy:
> In the tests I conducted, GPS + dgps resulted in the roughly the same 
> accuracy as GPS + Galileo + glonass + egnos.

As expected.  That result is why not a lot of effort has gone into
improving that code.

RTCM3 can perform better.

> My gnss receiver has about a 180 degree view of the sky (as it is 
> located on my side of my house), and the error of the position as 
> reported by the two tests -using google-maps as a reference- was
> roughly the same in both cases: a 4 meter error in the test using
> dgps, 3 meter in the other test.
> This test was done based on a DGPS station roughly 2 km from here.

The best test is to run gpsprof for several hours.  With and without
corrections.  The larger GNSS errors seem to slowly come and go.

> An interesting test - I think- would be to compare GPS + EGNOS with
> GPS 
> + DGPS.

EGNOS is also basically RTCM2, so the limitations of the protocol
are similar.  One would think local corrections are better than area
corrections, but the real limitation is the receiver itself.

> (*) Small sidenote: gpsd 3.17 (which is the standard version on
> rasbian / debian 10) crashed when receiving the first RTCM messages.
> I compiled gpsd 3.22, which did work correctly.

Please complain to Raspbian for your fellow users.

> (**) Something strange:
> When not using dgps (so all three 3 + sbas enabled), xgps did say "3D 
> FIX DGPS", but all three egnos satellites where marked as "used: no".

GPS sats orbit a lot lower than SBAS ones.  The accuracy of their
signals is also lower.  Thus they are only used in a fix when there
are not enough GPS in sight.  Some modern (u-blox 9) dont even bother
listening to SBAS at all.

> So what 'DGPS' does xgps refer to when all the egnos/sbas satellites  
> are marked as 'not in use'?

Every chip/firmware is different.  Broadly DGPS means some corrections
have been used.  The RTCM2 from a SBAS may be used to improve the fix
even when ranging from the SBAS is not.

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

pgpj8V3lfBt6g.pgp
Description: OpenPGP digital signature