Adding Support for RTCM experiential messages in RTKLIB

[DavidKelleySCSC]

In 2015 the RTCM SC104 committee decided to add some message IDs for experimental uses, with the general goal was that all new messages would be developed using these ID would in time be given a final (permanent) ID numbers once they were mature as adopted into the standard. The range assigned for this is 1~100 inclusive. Background: The range 101~999 remain unused and more or less will not be used. Proprietary message range from 4000 to 4095. This all refers to RTCM rev3 work, i.e. RTCM 10403.1

That has caused a problem for us when using the RTK method of dividing messages into two ranges by subtracting an offset value of 1000. We are working to extend RTKLIB to decode some of these message and need to overcome this issue.

In the all purpose structure of RTKLIB rtcmt there are two arrays used to hold counts of messages in both the RTCM2.x and the RTCM3.x standards as follows: unsigned int nmsg2[100]; /* message count of RTCM 2 (1-99:1-99,0:other) / unsigned int nmsg3[300]; /_ message count of RTCM 3 (1-299:1001-1299,0:other) */

These are mapped over the index range to support the "normal" RTCM3 message as such, this line was taken from rtcm3.c, but other similar fragments can be found.

if (ret>=0) { type-=1000; if (1<=type&&type<=299) rtcm->nmsg3[type]++; else rtcm->nmsg3[0]++; }

In this posting I would like to see if this is a concern for other using RTLKLIB, and if that is the case if the below proposed ranges would serve as a better solutions. And if Takasu-san has already considered this problem, what the preferred solution would be.

We have fours ranges to consider:

0; currently used to count any unknown message type
1~100; The experimental range
1000~XXX; std messages, where in theory this is 3999, but in practice 1300 is used in RTKLIB.
4000~4095; the Proprietary ones, where at present there are about 24 of the 95 used.

I propose that RTKLIB remap the current numbering system to include these to be:

0;    mapped to 0; currently used to count any unknown message type
1~100;     mapped to 1~100; The experimental range
4000~4095;     mapped to 101~196; the Proprietary ones,
1000~XXX;     mapped to 200~500; std messages. 

This increases the current array "nmsg3" by 200 values, and leaves the RTCM assignment range at the end to provide for further growth if ever 300+ messages were to be needed.

[DavidKelleySCSC]

Bump. Just want to raise this issue again and see it Tomoji Takasu has any advice on how to best proceed or would be inclined to address this at all.

[DavidKelleySCSC]

[Bump] Last month tomojitakasu marked this as an enhancement, but otherwise there has been not further discussion of this. In our firm's SNIP, "simple NTRIP" Caster product we now need to add decoding support for some more proprietary and temporary RTCM messages, so the need to implement this is now more urgent at our end.

My question is simple; does anyone see an negative issues with implementing this (the places to change in the code are less then ten). If defines are used, then those that do not need the extra 200 unsigned int values in memory this will cost can disable it, but that would somewhat complicate the indexing logic for them. Because of this I am tempted to hard code the ranges as the current code does. Any reason not move ahead with this?