Hello
I have tested my two reach units in two configurations:
Case 1: 1 Base and 1 Rover.
Case 2: 2 Rovers.
In both cases the units are in kinematic mode and located 10-40m from each other (distance has been varied but they are static during a single test of both cases). Each case was tested for at least 30 min before switching to the other case. In case 2 I am using the wifi that is built into the Reach units. They are connected to the same router. The router is present in case 1 as well, for starting the measurement.
In both cases I download the raw data for post-processing. I use rtkconv and rtkpost in the same way for both cases. Case 1 produces mostly points that are marked as float while case 2 gives mostly points that are marked as fixed.
What could be the cause for the difference between the two cases in post-processing?
1 Like
Hello Sven!
There should be no difference. Can you upload the RINEX files and screenshots of the solutions that you are getting?
I have a similar issue. I think maybe that there is a difference between the rinex from the rtcm3 raw data (from the base streamed to the rover), and the ubx raw data (when the base is in rover mode).
Comparing the obs files, they look pretty different, more white-space in rtcm3 based files.
This is happening on the latest version, right?
yes. But I also convert the raw data on a PC.
RTCM3 data recorded on the rover might be different for two reasons: packets loss in the radio transmission and because RTCM3 only contains minimal data as it was designed for lowest bandwidth. If it affects post-processing quality this should be investigated.
When I wrote my initial post I did not think about updating the reach units.
After updating them I went out to see if the error could be reproduced. By running case 1 and 2 for 10 minutes each at fixed position I got almost all (>98%) positions reported as fixed. So it was either solved by the update or if I manged to change a setting by mistake.
Or it does not happen every time. I will perform some more test of this kind this weekend to see if I get the same error. But it did not occur in my last test.
After updating and performing more tests I had no problem with using the rover + base mode. The rtcm3 data worked well in post-processing.
Thank you for your assistance.
1 Like
Good to know and thanks for the heads up!
