Fix results accuracy

I am using a pair of Reach RS+ in base rover configuration. Both rovers are using the latist firmware and I am using V2.224 of the app on an Android tablet. I have been attempting to get a solid fix with the system for several weeks and finally came up with a configuration that looked good in the field. (Fix with an AR ratio of 999.9). I have a site that has been surveyed by my coworkers with a Leica and have been comparing my data to “ground truth” our equipment. One day the data matches within 1.5 cm and another day it has several points that are off by 0.4 meters. Same settings different day. I am having an interruption during collection that happened on both days I will be walking from one point to another and I will lose fix and it will not return with out rebooting the emlid app and the rover. It come back after 10-15 min and then I can complete my survey.

How do you set up your base? Or do you use NTRIP?

Could you do a postprocess with rtklib and check the positions? uses the ubx data from the base and the rover and the csv file, so we can draw some conclusions.

1 Like

No NTRIP is available, I am using a survey tripod with a visual tribrach and a 1ft adapter. I use a ridged engineers ruler to measure to the top of the tripod from the pk nail(two sides average measurements if necessary) then I measure the tribrach from the top of the tripod to the bottom of the ReachRS+. I add the tripod to the tribrach and add the internal plane measurement and then convert to meters. This is the same set up I was taught for running a robotic topcon and an Leica base/rover.

I’m a new user and cant upload. Can a mod let me?

@NMgeologist Are you on fix and hold mode ? I notice more “false fixed position” in this mode than “continuous”. So you can have less % of fix along a kinematic PPK doing that, but I found the continuous fixes more reliable.

1 Like

I will try that again.

It would verify first that the coordinates of the base have been entered correctly, in continuous it will give you much more security due to false fixes. If you can share the ubx rtcm3 and csv files it might help you a bit more. How many times are you observing per point? 12 seconds minimum!

I’m trying to share files but I am not allowed to. Observing 40 seconds at 5hz = 200 points

raw_202004291431_UBX.zip (4.5 MB) raw_202004291530_UBX.zip (2.6 MB) raw_202004301831_UBX.zip (2.0 MB) raw_202004301938_UBX.zip (3.9 MB)

Thanks Dmitriy!

These are rover raw files, please let me know if you need anything else.

In the Rover , download rtcm3 file and csv file

base_202004291431_RTCM3.zip (189.7 KB) base_202004291530_RTCM3.zip (107.6 KB) base_202004301831_RTCM3.zip (89.0 KB) base_202004301938_RTCM3.zip (162.0 KB)

rtcm3 files

Naz 4292020.zip (623 Bytes) Naz 4302020.zip (606 Bytes)

CSV files

Thanks agrimgalina !

There is no common time data between the files to be able to do the processing

Sorry Im not sure what you mean. The survey was interrupted both days so there are two UBX and two RTCM3 files per day.

What do I need to do ?

The coordinates issued by the base are correct for the different days, but there is an interruption in the files

that’s what was recorded, maybe the interruption is my problem?

So I am slowly churning through the rtklib to process the logs.
EDIT. I jumped the gun on analysis and deleted comment

4.29.2020 tracks show some float on the southern points that data was still good
4.30.2020 tracks show eastern points which are fix however the data is 0.4 meters off

4.30.2020 points H,G, and F are my horrible points