I’m using Reach M modules since some years now with satisfaction!
I’have a BASE on the roof of my office and a rover on a tractor (see picture below in the zip).
Running version 28.4 on both modules, with Tallysman multi-GNSS antenna 3742 .
Since version 28.4, i cannot have a fix anymore.
The solution is moving from single to float most of the time, some time ,getting a fix for a few minutes then coming back to floadf/single.
the BASE sends the correction by TCP over internet. I have a mobile wifi-hotspot on the rover in order to connect to internet.
The rover can connect easily to the base station correction by this means.
I used this system since 2-3years whitout any problem (up to 10km far form the base) and i got the fix between 2-5 minutes.
The base has a static IP address (redirection using duckdns.org). I’m using this feature since 2-3 years withoiut any issue.
I think that the rover receives the correction by this TCP mechanism, because:
As i said, the rover solution is bouncing from single to float and sometimes get a fix for a moment.
Moreover, when i used the reachviewer (android application), i can see in the Status bar graph the correction satellite grey bars.
I can also see the “age of correction differential” which is around 0.5 second.
The AR validation ratio status is around 1-2 and sometimes getting a bit more than 3 which gives a Fix.
By the way, i already included in the zip the log file coming from the ROVER “ROVER_reach_base_202208311226_RTCM3.zip”
So these clues seem to say that the rover do receive RTCM3 corrections.Am I wrong?
Is there a way to analyse the ROVER_reach_base_202208311226_RTCM3 and check if the received correction are correct?
Float solutions mean that the rover receives corrections from the base. I also took the base correction RTCM3 log converted into the RINEX with Emlid Studio, the rover UBX log converted into the RINEX as well, and post-processed them in Emlid Studio. I managed to achieve 100% of FIX solutions, look at the screenshot below:
RTCM3 correction log looks good and doesn’t have any traces indirectly showing there’s some intermittency. I also checked reports from the base and the rover, and haven’t noted any suspicious there.
I suggest you to check the base coordinates that are inputted manually in the base mode. How are they obtained? Please try to average base position in SINGLE, if you don’t need an absolute accuracy. Incorrect base coordinates inputted manually may affect calculating solution from the rover’s side.
I’d also recommend you set elevation mask to 10 degrees and set SNR mask to 30 on both receivers. It allows them to track more satellites and take them into account, so it may improve the result a bit.
I just downloaded emlid studio and process these files. And indeed most of the time (>989%), we reach fix solution.
So my wondering is: emlid studio and reach 28.4 (on Reach RS) do use the same RTK parameters/configs/version?
What could explain such a difference between the Emlid studio resulkts and the Reach RS results?
Some days ago, I already made some test using a lower elevation and/or lower snr mask; no better success
The base position was acquired by “average single” and has not be updated since months.
Furthermore, even if the base position is not at the exact accurate position, it does not explain why i cannot reach a fix solution.
If you can reach a fix solution using the same set of data, does it means that the calculations performed on the fly by Reach RS are not correct?
As i already said i’m using this system since 2-3 years and the fix solution was almost reach in a few minutes.
Bouncing between single to float prevent the tractor autosteering system to operate properly.
Is there a way to come back to a previous version of the system?
I will set the elevation to 10 and snr to 30 to both receivers, and make another test tomorrow.
I’ve analyzed RTCM3 correction log again and found out a possible reason for such behavior. Take a look at two screenshots showing number of satellites in converted log:
The number of satellites significantly fluctuates each second. However, the base log doesn’t behave that way. So, it means that something’s wrong when the base sends RTCM3 messages to the rover.
I’d suggest you restoring initial settings on both receivers and check the behavior. You can find it in the Troubleshooting tab in ReachView 3 and in Control Panel if you use Reach Panel. There it’s called Reset settings to default.
We have different PPK and RTK algorithms in our devices. Moreover, PPK lets you play with settings and achieve better result than in RTK. And if you take instead of base UBX log RTCM3 correction log, you’ll get worse result similar to RTK.
We haven’t changed anything in calculating RTK in 28.4 version, so I assume the issue related to the settings. I believe we can solve it by restoring initial ones.
i think i found the issue.
the max vertical acceleration was set to 0m/s2 and horizontal to 0.5m/s2.
Setting vertical at 1m/s2 and horizontal to 2m/s2 now give a fix within 2-5minutes, and this fix is kept during hours
What are the “standard” values for these vertical/horizontal acceleratin for a rovers like car or an agricultural tractor?
The default values are 1 m/s2 in vertical and horizontal axes. Max acceleration is your estimation on how the rover will move. So, the faster the rover moves, the higher acceleration is needed to be set.
