Difference in base log, RTCM in RTKconv vs Rinex from M2

Hi,

I am using the new feature fw28 where base corrections can be logged in both RTCM as received and also in Rinex, ready to use.

When downloading both logs and comparing, there is however a large difference in number of obs-types.

This is Rinex Obs-header from RTCM converted using RTKconv on the computer:
G 9 C1C L1C S1C C2W L2W S2W C5Q L5Q S5Q SYS / # / OBS TYPES
R 6 C1P L1P S1P C2P L2P S2P SYS / # / OBS TYPES
E 12 C1X L1X S1X C7X L7X S7X C5X L5X S5X C6X L6X S6X SYS / # / OBS TYPES
C 9 C2I L2I S2I C7I L7I S7I C6I L6I S6I SYS / # / OBS TYPES

This the respective from the M2 unit, as downloaded.
G 20 C1C L1C D1C S1C C1W L1W D1W S1W C2W L2W D2W S2W C2X SYS / # / OBS TYPES
L2X D2X S2X C5X L5X D5X S5X SYS / # / OBS TYPES
R 16 C1C L1C D1C S1C C1P L1P D1P S1P C2C L2C D2C S2C C2P SYS / # / OBS TYPES
L2P D2P S2P SYS / # / OBS TYPES
E 16 C1C L1C D1C S1C C1X L1X D1X S1X C5X L5X D5X S5X C7X SYS / # / OBS TYPES
L7X D7X S7X SYS / # / OBS TYPES
J 12 C1C L1C D1C S1C C2X L2X D2X S2X C5X L5X D5X S5X SYS / # / OBS TYPES
S 8 C1C L1C D1C S1C C5X L5X D5X S5X SYS / # / OBS TYPES
C 8 C2I L2I D2I S2I C7I L7I D7I S7I SYS / # / OBS TYPES

Many more obs-types, even some that shouldn’t be sent by the Base Receiver (like the Doppler obs-types, as the receiver is only sending RTCM MSM4).

Further, it seems that the Emlid conversion replaces the Receiver name:
From RTCM via RTKconv:
21413171 HEMI_DF5a 6.0Aa04a REC # / TYPE / VERS
From RTCM via Emlid M2 onboard conversion:
EMLID REACH M2 REC # / TYPE / VERS

@svetlana.nikolenko
Can I have your sharp eyes on this one?

Hi Christian,

Sure, I can! However, I have nothing to say right away. Would you give me some time to test if it’s reproducible with our office devices? It doesn’t look right, so I’ll report it to devs if I catch the same behavior.

1 Like

Hi Christian,

I’ve reproduced and already reported it to devs. Thanks for noticing! We’ll fix that.

Awesome news, thank you!

Hi Christian,

The “replaced” receiver name issue is fixed in 29 Beta 1 :tada:

But I’ve discussed with devs why there are so many observations types and realized it’s not an issue. The direct quote: “We are writing a real-time log and don’t know what data it may consist of. So we assume that almost all the observations can be there not to lose any of them.”

I didn’t think about it at first, but it sounds fair enough, right?

From a technical stand-point, sure, but from Rinex-standard standpoint, I don’t think this is a compliant Rinex file?
This also means that post-processing softwares, that applies a strict interpretation of the Rinex standard will get in trouble when using these files.
But it is interesting that it is a realtime file. From the time it take to save, I was under the impression that it was a ubx-file being internally converted with RTKconv (or the command-line util that is)?

UBX format is used for raw data only. For base corrections, we use the RTCM3 format.

In case of any issues, you can convert RTCM3 to RINEX in Emlid Studio. Or even RINEX to RINEX. Only really recorded observation types will be left in the Header.

Replying with a fever is never a good ide :smiley:
Meant indeed the RTCM stream, in the same way that it does in RTKconv, where it first parses the file, then creates it.

Get well, Christian!

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