Further to my earlier thread regarding certain RTCM3 message types 1007 and 1008 - I have been doing some more testing trying to use an RS2 base with existing/legacy third party RTK receivers.
Unfortunately the great stumbling block to successfully using an RS2 base in this situation appears to be that the vast majority of these existing receivers from the likes of Topcon, Trimble etc acting as rovers is that they are really only capable of receiving “classic” RTCM3 corrections - that is really RTCM 3.1 only and not the newer RTCM 3.2 (and 3.3) corrections which use the newer multi-constellation MSM message types like the RS2. This is especially true in Precision Ag where the “if it ain’t broke don’t fix it” mindset is prevalent and the refresh lifetime of some of these receiver models is anywhere from 5 to 10 years.
There are development plans from the SNIP caster team to support what they call “Create Classic from MSM Message” using their message translation function. This could be used to create RTCM3 message types 1001~1004 (GPS) and 1009~1012 (GLONASS) from MSM messages. Unfortunately this is a future feature, so again does not work right now. It would also necessitate another “box” or step.
I’d like to ask Emlid if they would consider supporting a “classic” RTCM 3.1 style output in ReachView that uses non-MSM4 correction output so that the existing fleet of legacy RTK rovers will be able to use the RS2 as a base. I know this may be seen as a somewhat retrograde step but it would increase the use, flexibility and appeal of the RS2 massively to the army of users out there with lots of other legacy receivers.
I posted RTCM3 MSM compatibility issues? last week about issues receiving the older MSM Type 3 messages (RTCM3.1?) from a VRS/NTRIP provider (Trimble network), so I think what @DirtyHarry is asking should be implemented for both Base and Rover functionality.
My company has existing Trimble GNSS equipment that is slowly aging out. One of my main goals is to assess the ability of the RS2 to replace these much more expensive GNSS. However I’m finding that the RS2 works excellent with itself, but not so much with other manufacturers. This is a big stumbling block in my mind. Adding RTCM3.1 compatibility would go a long way to overcome that hurdle. The result would be that my company not only uses the RS2 to replace the aging Trimble equipment, but also purchases additional RS2 GNSS (or other Emlid products) to vastly expand our GNSS use.
Currently we have a small fleet (~10) of high end GNSS, compared to need, because the cost of full expansion is prohibitive. The RS2 looks to be the solution to that, but it has to play nice with the main GNSS players to be fully effective.
For maximum compatibility with existing correction providers and individual base manufacturers, I would expect the RS2 as a rover receiver to happily receive any and all existing well formed/compliant RTCM 3.1 (classic) as well as RTCM 3.2 (MSM3 to 7) message types.
In base mode, it’s clear the RS2 designers have considered the “optimal” forward compatibility currently supporting ‘only’ the more modern MSM4 message output, as there is no need for the older GPS/GLO only “classic” message support if you’re just running an Emlid base with Emlid rovers.
The challenge here is if there is enough call for Emlid to alter ReachView to support “backward” compatibility with RTCM 3.1 to make it more useful in a mixed receiver environment.
There should be technically no reason why “classic” RTCM 3.1 output (perhaps with additional MT support for 1007/1008 messages as above) could not be achieved. Whether there is appetite for such support from Emlid they can only answer…
Thanks the prompt feedback - I appreciate the team there has many demands on their time for bug fixes and new feature requests.
Hopefully this one will make it into the roadmap and really open up the cross-compatibility of the RS2 with the existing universe of RTK rover receivers.
Now that we see, in your thread, the full list of input RTCM3 message types supported by the RS2 - it seems (at least to me) to make sense to support all the same MT’s on the output.
As a sort of “starter for ten” MSM4 only support is fine, however this definitely limits and precludes using the RS2 as a base in setting where just good old L1/L2 “classic” GPS+GLO correction is needed.
Furthermore the lack of MSM7 output is also somewhat limiting as it would appear that other more modern receivers (Trimble for example), at least, can get along fine with MSM7 message types as a correction input but won’t support MSM4.
The UBLOX chip supports all of these MT’s.
It would be really nice if they were made available to select as valid RS2 base RTCM message type outputs in Reachview too.
