Good day all
New to the board and relatively new to the exciting world of RTK
I have been using the REACH RS2 receivers since June 2020 and I am quite pleased with them so far.
Today I encountered an unusual situation. I set up as I usually do. I was able to acquire a Fix solution which eventually began to vary between Float & Single.
When I checked the Reachview app status - it appears the base was only receiving 7-12 sats. Base was set with clear, open view of the sky and undisturbed on a stable tripod.
The Rover was in less ideal locations at times but yet was receiving upwards of 30 sats with decent signal. Base and rover were never greater than 550 metres apart.
I am using ReachView version v2.24.0
I have attached my raw data from the session.
This has never happened before and recurred consistently throughout the entire day.
Please help - I have attached the raw data files from the receivers
Could you also attach the raw data log and the position log from the rover? They will help us see the observational quality of the rover and the solution status during the survey.
Just a quick recap of all the logging available on Reach receivers:
raw data log contains GNSS observations from the receiver without calculation of accurate coordinates
base correction log contains the received data from the base in RTCM3 format; this is what you attached to the master post
position log contains a corrected position of the unit during the whole survey including the solution status
All of these logs can be enabled through the Logging tab. If you started log recording before the survey, the data will be available for downloading in the same Logging tab. In more details the downloading process is described in this guide.
We need to see all of the logs to understand the possible issues with the solution calculation. They will allow us to asses the observational quality of both base and rover, to see if all the data is transmitted correctly between the base and the rover, how the solution status is changed over the survey.
I can see that Fix solution is frequently lost on your rover. The main reason for it is rather bad observational quality on the rover: only a few satellites’ signals have SNR above 40 and all of the signals suffer from the immense amount of cycle slips. Cycle slips indicate the loss of the signal that is usually caused by the inappropriate placement of the unit.
From the survey on 15/02/2020 at 14-49 UTC you can see that the loss of the Fix signal corresponds to the concentrate appearance of cycle clips in the rover’s log at around 15:05 UTC.
To avoid such worsening of the signal, please, check that your Reach RS2 receiver is placed correctly according to our Placement guide and the hardware setup doesn’t hinder the satellite reception of the unit. Please use the latest stable firmware version v2.24.2 on both devices to ensure that the latest improvements of the calculations are included.
Also, I noticed that the RTK link with the base unit is frequently broken: there are severe gaps in the received data on the rover. This means that the LoRa radio link is frequently blocked by something. Please note that the LoRa radio requires the line of sight between the units so when the environment blocks it, it’s not possible to transfer the corrections.
If you’re working in complicated environments, I’d recommend considering other ways of transmitting corrections. For example, you can work with other more powerful external radios as Reach RS2 supports communication over Serial. Also, if the areas have good mobile coverage, you can use our NTRIP caster to transfer corrections between the base and the rover.
Wow Polina.
Thanks for your impressive presentation.
I use FieldGenius Android routinely. When I observed that the RTK fix solution was broken I switched to Reachview app to analyze the observational quality.
I noticed that during these times the SVs available by the base was significantly reduced (sometimes as low as 7) whereas the rover was reporting 30 available SVs.
On the “map” page it appeared that software had not confused the 2 based on their relative positions. (Which would suggest improper position of the base - however base was placed with say 85% clear view of sky within 15 degrees of horizon)
When I improved the location of the rover (Just in case base/rover identification was mixed up) this did not result in any improvement. Improvement came only after patiently waiting for several minutes (15-30?). I decided to call it a day after much frustration.
Is there anything in the data that corroborates or explains my experience?
BTW I have since updated the firmware on the receivers and they have been performing quite well.
Do you mean that you saw only 7 satellites available in the Status tab on the base unit? Or were only 7 satellites available the Base satellites on the rover’s Status tab?
From the base correction logs you’ve sent, I can’t see any time period where the base satellites count dropped to only 7. However, there are parts when there were no corrections at all.
I’m afraid I can’t see any significant improvements in the observational quality on the logs you’ve shared. It looks like such wait could be provoked by missing data from the base - even if the rover started seeing more satellites with better quality, the base link was broken and the corrections were not coming fully. That prevented the unit from calculating the Fix solution.
If you use LoRa radio as the correction transmitting way, I’d recommend checking that there are no obstacles between the base and the rover as it requires a line of sight.
Great to hear it! In case of any issues, don’t hesitate to contact us here or via support@emlid.com email
Thanks again for your in depth analysis and explanations.
I see where I need more practice in using the receivers.
It seems my main weakness is the lora radio link and obstructions between the base & rover
