But how big these RTCM3 messages really are?

Reach Module / M+ / M2 Hardware integration
1

I’m working on a project that consists of 3-4 small moving robots which need to accurately know their position and also be able to comunicate together.

Since I need cm accuracy, I’m planning to have one Reach m+ on each robot/rover and a base station (also Reach m+ based) located at most 3-4 km from the rovers and always in line-of-sight.

As far as radiolink is concerned, my choice is on Lora both to broadcast the RTK corrections from the base and also to manage the 'inter-robots/rovers comunication.

In order to avoid collisions between the rtk corrections and the other messages (inter robots) circulating on the radio link, I was thinking of using the 1Hz rtk corrections to synchronize the radio network. So basically each robot would have a pre-defined time slot available to talk after each RTK correction broadcast.
Put it in a different way, Robot1 will able to talk after RTKCorrection #n has been broadcasted, Robot2 would be able to talk after RTKCorrection #n+1 has been broadcasted, and so on for Robot3 and Robot 4.

Since Lora datarate is quite limited, I’m trying to understand what’s the actual size of the RTCM3 messages so that I can find out the duration of the remaining time slot length for the inter robot comunication.

To do so, I connected my PC to 3DR/sik radio that was receiving RTCM3 messages from a Reach m+ module configured as a base station.

I logged the RTCM3 file that the PC was receiving during 1 minute with the following messages enabled at 1Hz, except for 1006/ARP at 0.5Hz. I picked-up 4 different configurations:

a) 1002, 1006, 1010, 1097 (GPS, ARP, GLO, GAL)
b) 1002, 1006, 1010 (GPS, ARP, GLO)
c) 1002, 1006, 1097 (GPS, ARP, GAL)
d) 1002, 1006 (GPS, ARP)

I repeated the log of each configuration three times and divided the size of the log files by 60 to get an estimation of the number of bits/sec each configuration would require. Here is what I got:

Config a) 2.3 kb/sec
Config b) 1.6 kb/sec
Config c) 1.7 kb/sec
Config d) 1 kb/sec

I was expecting to find values similar to what’s in Emlid doc but that’s not the case

image

Am I missing something? Why are my values much bigger?

Does the size of the RTCM3 message depends on the satellites that are actually visible?

Any experience with sharing a lora radio link between RTK corrections and other messages?

Thank you!

1 Like
2

This is off-topic to your question, but worth mentioning:

Were you thinking to use the Emlid LoRa modules? I think they are only configured for simplex (one-way) communication like an FM radio station. For duplex (two-way) communication you would need to look for some different radios.

edit: nevermind, I just noticed you are using 3DR/sik radios. Please disregard my comment.

Then to add to your question, I think that with altitude the RTCM3 message size will probably get bigger because more satellites will be in view. So if that is the case, then the actual data rate of a particular RTCM3 message stream will be variable depending on satellite geometry and visibility.

3

Hi Bide

Thanks for helping. Yes, I’m currently using 3DR/sik radios (point 2 point) but I’m planning to use Lora radio in future. As you noticed, I need a 2 ways communication so Emlid-Lora set-up is unfortunately not an option for my application.

Back to RTCM message size, I get your point and your hypothesis (message size depends on the number of visible satellite) can somehow match the measurement I made.

-> But then what’s this ‘156 bps’ that’s stated in Emlid doc for GPS L1 observations? Is it for 1 satellite only?

If that’s the case, then what about the needed bps for msgs 1010 and 1097? Should the numbers present in Emlid doc be multiplied by the number of visible satellites of the corresponding constellation?

@Emlid: please clarify, thank you!

4

Here’s a thread from a few years ago. It has some information on RTCM3 data rates to compare with:

You could also measure for yourself what the data rate for each message is. For example, enable one message on your Reach M+. Then with a Linux box, connect to M+ and measure the output using the netcat and pipeviewer programs.

Example:
nc 192.168.2.15 9000 | pv -trai 0.1 > /dev/null

The options -trai 0.1 make the output like this: Total data, elapsed time, instantaneous bit rate, average bit rate.

There are different netcat (nc) versions. Yours may require different options. Substitute 192.168.2.15 with the IP address of your M+. For this test, the M+ base mode should be configured to output RTCM3 as a TCP server on port 9000.

6

Hi @julien.buros,

Quite an interesting research :slight_smile:
I’ll do some tests this week to check your statements from the 1st post and provide you with a detailed response.

1 Like
9

Hi @julien.buros,

Yes, it is. As the size is depending on satellite number, it’s impossible to compare my test result with your values.
However, I can agree that it’s hard to understand how to count messages size by using values from the table.

So, after some tests, I’d like to share the updated table.

RTCM3 messages Size in bytes/sec (1 satellite, 1Hz)
1002 10.385
1006 27
1010 11.3
1097 21.5
1107 37.5
1117 42
1127 17,779

We’ll also rework the table in the docs.

Thanks for the review.
Hope, now you’ll get the size you expect.

Andrew

4 Likes
10

Hello Andrew, that makes more sense and these values also seems consistent with what I’m observing (with a bit of margin to account for the inaccuracy of my measurements)
Thanks!
Julien

12

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.