Re: Decode RTCM3 messages

[Gary E. Miller]

Yo Xavier!

On Mon, 4 Oct 2021 21:59:02 +0200
Xavier Ruiz <xavier.ruiz@earthrover.farm> wrote:

> Thanks for your quick reply Gary.
> 
> We have a Base Station that is sending observations in RTCM3 format
> through 2 streams: radio and ntrip. This is really important since
> our system strongly relies on RTK fix quality.

Common, but 99% of the time you jjust pass the RTCM message from
the base to the rover and never care what is inside.  So you do you care
what is inside?  Some intermediate processing?

> The Base Station sends the observation messages 1006,1008, 1033, 1230
> and MSM5 (1075, 1085, 1095 and 1125).

One of many typical message sets.  Considered obsolete now.

> However, our GNSS receiver module can only handle one stream of data.

Common on the cheaper receivers.  Consider a receiver upgrade.

> The radio looses packages but is faster while the ntrip is slower but
> more robust. When the receiver module receives an observation with a
> new tow it will ignore any incoming obs with an older tow.

If messages are out of order, you got problems.

> This is
> problematic since we will loose a lot of information if a new radio
> package arrives before completing all the ntrip obs from the previous
> tow.

Yup.  File a bug with whoever wrote that software/firmware.  Clearly broken.
NTRIP data is good for way longer than one second.

> In order to address that we are trying to receive the observations in
> an onboard computer (We use rtklib's str2str serial for the radio and
> str2str as well as the ntrip client).  We want to arbitrate the two
> channels and group both ntrip and radio obs by their time of week.
> Once we receive all msgs from specific tow, we send them to the
> module and then wait for the next tow and repeat.

But now the module is also on to the next tow.  You can't win.

> For that we need to decide the rtcm3 messages to group them by their
> tow. And then once grouped, decode them to send them to the receiver
> module.

I'd be very suprised if they came out of order.

> If you have any suggestions to solve this differently, I am open.

Too soon for me to open my mouth, beyond saying you need to do better.

> Also, what MSM number gpsd is able to decode?

You can look in drivers/driver_rtcm3.c, starting at line 114, to see
which messages gpsd presently decodes.  MSMs are only part of the RTCM3
stream.

New u-blox need the newer MSM7 type messages, so no one cares about the
older MSMs anymore.

gpsd only decodes what RTCMs that it does out of curiosity, no one has
figured a use for them yet.

> We can configure the
> base station to send the legacy, MSM4 or MSM5. Not sure if there is
> any advantage to use any of them compared to the others.

Newer MSMs are more precise, and handle more/different constellations.
But since newer u-blox only handle MSM7, the differences are academic.

If you look in drivers/driver_rtcm3.c you can see that adding a new
RTCM3 message is not hard, but there are a lot of them, and you need to
actually care.

Feel free to add more decodes.  Each decode is less than 20 new lines of
C.

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

pgptkNdtcd48z.pgp
Description: OpenPGP digital signature