Re: how to forward RTCM data to gpsd?

[Gary E. Miller]

Yo Kristoff!

On Wed, 9 Dec 2020 02:05:09 +0100
Kristoff <kristoff@skypro.be> wrote:

> I am new to the mailing-list, with just a quick question.
> Can somebody provide a quick overview of what gpsd expects RTCM
> messages should look like?

gpsd does not care.  gpsd just forwaards to the GNSS receiver.  The
receivers are very picky.

> As part of an exercise to learn Software Defined Radio and GNU Radio,
> I "build" a receiver in GNU Radio for the marine DGPS radio-stations
> in the mediumwave band, including some python-code to decode the RTCM 
> messages. (not yep posted online .. first code-clean-up :-) )

gpsd can also decode them.  Check out drivers/driver_rtcm[23].c

> So, as I now have that, I guess it would be fun to actually use this 
> RTCM data for something useful, e.g. feed it into gpsd so it gets 
> forward to my ublox GNSS-receiver.

Much variation in how u-blox chips handle RTCM.  Most can not handle it
at all.  Those that do are picky about the sentence mix.

> My plan is to write a small TCP-server in python and let dgps connect
> to it.

You will find little improvement in the accuracy of a recent receiver
unless the RTCM bas is very close (<0.5 km)

> Now, the question is, what is the format for RTCM messages should
> look like?

They should look exactly like RTCM messages.  The trick is what your
receiver wants.

> 1/ RTCM messages are 30 bits (i.e. they do not match the byte frames
> of TCP/IP).
> Am I correct to assume that I can just stuff the RTCM databits into a 
> non-structured stream -ignoring byte-boundaries- and that gpsd is
> able to take care of frame-synchronisation?

Nope.  gpsd does not frame them, just passes them on.

> 2/ The marine DGPS radio-service uses bit-inversion (i.e. all
> databits of the RTCM word are inverted if the bit proceeding that
> word is 1).

Whatever the spec says, so that.

gpsd has several samples:
    test/daemon/*rtcm*.log
        
> I do not know if this so for all RTCM messages. or if this is
> something specific for the marine DGPS service.

Dunno.  All gpsd does it take RTCM in and pass it on.

> But I did find a reference to bit-inversion in the source-code so I 
> guess that gpsd does expect the RTCM bits to be as received from the 
> radio (i.e. not bit-inversion corrected).
> Is this correct?

Unclear what other software/firmware does before sending to gpsd.

> 3/  is the data expected to be MSB or LSB first?

Stream order, as defined in the spec.  Look at the gpsd samples.

> On a more general point, what would be the best strategy when
> relaying DGPS/RTCM packets from a radio to gpsd?

nc (netcat) is common.  Just push the bits.

> Just stuff the bits as I receive them from the radio to gpsd?

Well, you wrote the radio part.  So write your radio so that is
the case.  Like everyone else did.

> Or first do some filtering / error-checking first myself, and only
> send "validated" data to gpsd?

Your choice.  The receiver will do that anyone.  So unless bandwidth is
a big deal to you, then it just adds latency.

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

pgpJ5ObHFNC_W.pgp
Description: OpenPGP digital signature