Adjust base location of RTK points when raw rover log is missing

I often record points in locations where there is no known reference point for the base station. My typical workflow is to set up my base on site (over an unknown point) and collect points with my rover in RTK with a FIX. I download RINEX logs from a local CORS station and process the base RINEX using Emlid Studio’s Static processing workflow to get the accurate base location. I then use the Stop and Go workflow to process the Rover RINEX, base RINEX, and corrected base location, to get the absolute positions of the measured points.

Unfortunately, the rover RINEX file is mysteriously missing from a recent survey. I have the base correction file (RTCM3), and a small snippet of the LLH file, but no raw data from the rover (it is particularly strange because I have all of the rover data from surveys collected later in the day at other locations). I do have raw data from the base, and the csv file from the survey.

My questions:

  1. Can I get the absolute positions of the RTK points with simple arithmetic (details below)?
  2. If not, why not?
  3. Any ideas what might have happened to my missing logs?

As I understand it, points collected in RTK have high relative accuracy. This means that we know the distances between the points and the base with a high degree of accuracy, but we do not know their exact coordinates, unless we have a known base location. If the base is not placed on a known point, it will record satellite signals for 2 minutes (depending on settings) to estimate its position. The accuracy of this base position estimate is +/- a few meters (SINGLE). I would like to calculate the distance between the estimated base location (used during data collection) and the corrected base location, and adjust the measured points by the same amount to get their absolute positions. Does this work?

Example with made up coordinates (x, y):

estimated base position: (0, 1)
corrected base position: (2, 3)
point A originally measured location: (5, 4)

Distance between estimated base and point A:
5-0 = 5 units in the x direction, 4-1 = 3 units in the y direction

Corrected location for point A = corrected base location + distance between point A and estimated base position:
corrected point A = (2+5, 3+3) = (7, 6)

OR
Distance between estimated base and corrected base:
2-0 = 2 units in the x direction, 3-1 = 2 units in the y direction

Corrected point A = original point A + distance between estimated and corrected base locations:
corrected point A = (5+2, 4+2) = (7, 6)

Details about my set up:
Base: RS+
Rover: M+ mounted on a survey pole
Emlid Studio Version: 1.9

Hi Christy,

Welcome back! Sorry it’s been quiet here.

You’re on the right track with your second approach. Since the rover points are relative to the base position, you can shift them by the difference between its original and corrected coordinates. Just one thing to keep in mind — both sets of coordinates should be in the same system before making the shift. We have a support tip on this topic.

Before diving deeper into that, let’s address the issue with your missing RINEX file. This isn’t how things should work. Could you check the firmware version your M+ is currently using? It sounds similar to an issue we resolved in firmware version 32.2.

Unfortunately, we aren’t able to restore logs from previous instances, so they would need to be collected again. However, if your rover is already on version 32.2 and you’re still facing this issue, we’d definitely need to investigate further. To help me look into it, please share a Full System Report along with the date and time of the specific log. It’s safer to email it to support@emlid.com.

Thank you for your response! The support tip is exactly what I was looking for, but I failed to find the right search terms.

It looks like I am a couple versions behind of firmware, so that probably explains the missing logs. I will send the full system report via email.

Thanks for sharing the report! I’ve checked it and see that the firmware version is 31.8. This is likely why the log is missing. As much as I’d like to help, it’s not possible to restore it. I suggest updating to firmware 32.2. With this version, you shouldn’t have this issue with the new logs going forward.

As for this CSV file, I’ve already sent you the details on how to correct it via email. I’d be glad to help with it, so feel free to continue the conversation there.

1 Like