ROVER: Forward RTCM 1005, 1006, 1007 to data collector with NMEA (configurable)

[tonycanike]

1. ROVER: Forward RTCM 1005, 1006, 1007 to data collector with NMEA (configurable)

EDIT: Updated to be more specific. See discussion in #431
Not actually sure if forwarding the RTCM 1005, etc., to the data collector will achieve the ultimate aim. I'd be willing to help test with my data collector if there was some way to stream a test data set to it and see how it responds.

#431 (comment)

Previously titled: Provide Base Location in Rover data stream and log

The "log" part of the original #405 I captured in #447.

---

Subject of the issue

The Rover knows the position of the Base. Enhance the data stream from the rover, and the rover log file, to contain the location of the base.

This would be useful for validating the coordinates of the base when processing the rover data. This would also connect the base coordinates to the rover data without needing paper, pencil, phone photos, .csv files on SD cards, etc. The base coordinates would be in the rover data, reducing potential misunderstandings of where the base was when the rover data was collected.

Initial capability could be to simply provide the ECEF of the base antenna phase center with a $GNTXT message in the Rover log and/or data stream. By the time the rover starts getting RTCM from the base, the base should have locked down it's location.

Potential future enhancements could include providing the coordinates in LLh, providing the id of the base mark (point#), base HI (ground-to-ARP), base antenna type, ARP->APC offset, etc., if this information can be obtained.

It appears that most surveyor-grade commercial GNSS receivers provide the base location to the data collector. That information can be recorded in the data collector log files. These receivers also appear to get the HI (ground to arp, height of instrument), the antenna type, and the antenna offsets from the base.

For example, the ".RAW" and ".RW5" files written by data collectors from multiple major survey data collector manufacturers contain a "BP" -- Base Point -- record that contains information about the base. The data collector software will write these records when connected to the base and also when connected to a rover.

Here's an example BP record written by SurvPC
BP,PNBP001,LA39.245469902207,LN-76.465103374896,EL111.7164,AG2.1000,PA0.0925,ATAPC,SRBASE,--

PN: point number BP001
LA, LN in ddmmss.sss
EL - ellipsoid height
AG - ARP above ground (HR)
PA - phase center to ARP distance

Your workbench

f/w 3.1

Expected behavior

RTCM 1005 contains the ECEF coordinates of the Base antenna phase center.
The rover knows where the base is, or at least where it thinks it is (survey-in or fixed setting).

Output the base coordinates in the NMEA data stream and/or the rover log.

Apparently there is a NMEA message for this, though I haven't been able to find it. The release notes for SurvPC v5.08 state
"The NMEA GPS driver now supports getting the base position."
https://web.carlsonsw.com/files/updates/updates05.php/?ss_email=&product=SurvCE&ss_email=&version=5.0&serial=&ss_email=

[tonycanike]

I've noticed that when SurvPC 6.16 is connected to a rover using SurvPC's "Generic NMEA" driver, it has a screen to display the location of the base and other info about the base. When connected to a Facet, the base info screen displays but is blank.

Unless there was some programming oversight, this is corroborating evidence that SurvPC can determine the base location from messages in a NMEA stream, or at least an extended NMEA stream from one receiver.

In general, SurvPC is very good about disabling screens particular drivers don't support.

[nseidle]

A fine idea but we've not decoded RTCM before. It's possible, will just take some time.

[tonycanike]

It has occurred to me that perhaps my data collector can decode the RTCM message types regarding the base (aka the reference station) if the rover would forward them from the base to the data collector in the NMEA data stream. Eg RTCM MTs 1005, 1006,1033, etc.

There is some logic to this; why invent some new rover-to-data collector base-info-protocol and write code for the rover to translate RTCM to such a new protocol, when instead the rover could more simply forward a few RTCM message types.

If I can figure out how to monitor that data stream from another GNSS receiver rover I have (which somehow does provide base info to my data collector) to my data collector perhaps I could test this theory.

It also might be simpler for the RTK product to include selected RTCM messages in the rover log to document

This is not yet a well-formed request but only some thoughts about how we might proceed.

[nseidle]

RTCM can come in from a few sources:

• BT from a datacollector software.
• WiFi from a caster
• Radio connection to a base

BT: In this case, the DC should already be aware of the RTCM stream as the DC is getting RTCM over NTRIP (over it's own connection cellular, WiFi, etc). I'd leave the RTCM decoding up to the DC.

WiFi: We could parse the incoming packets. This is still on my todo list.

Radio: The RTCM comes in over an unknown radio and is directly dumped into the ZED-F9P. I don't know of an immediate way to intercept these messages.

[tonycanike]

Thanks Nathan, agreed.

I am using the Radio case. I have a theory that other GNSS receivers do this (when acting as a rover, forward RTCM 1005, etc. from the base to the data collector) and that various data collector software uses the RTCM, but I am not sure.

I'd like to test that the data collector will actually properly use the RTCM 1005, etc. before anyone does a lot of work. If you have any pointers on how to create a test data set with NMEA (from a rover) and RTCM (from a base) messages, and play it back to my data collector at an appropriate rate, I'll run a test before we pursue further.

[tonycanike]

Hmmm what if a ZED rover was configured to send RTCM 1005 - would it just forward what it received?