I lost fix one on of my rovers and am not sure why. This is the first time using RTKLib Plot so if I can provide additional information let me know. I post processed the base and rovers files so I believe this is PP an not live data. I might be mistaken as the age of differential goes high which I’m assuming can’t happen with PP.
Logs
Keep in mind that a loss of fix can be attributed to the LoRa connection as well. I have seen High-Voltage transmission lines cut radio reception distance from 2 miles down to 500ft which is independent of how many usable satellites you have.
I might be missing something but with having post processed the base and rover logs doesn’t that eliminate Lora as the problem? I’ll admit I struggle a little bit to understand which plots are from the raw data and which plots are from the post processed signal so if what I’m saying doesn’t make sense that is likely why.
Nope, you’re right. I wasn’t paying attention. 
Does the Age of Differential apply to PP or just live with Lora?
The same things occurred on the other receiver. I apologize for not realizing this sooner. The issue was miss reported to me.
The second receiver had lost fix previously so it was rebooted in an attempt to bring it back. My initial understanding was that only one receiver was having problems.
Here are the logs from the second receiver.
Hi @kylelanman,
I’ve looked through your data. It seems like the base stopped recording and transmitting the data at 22:00 UTC. Could you please describe what happened?
You can see on the screenshot below, that the base have no data records from 22:00 UTC. So the rover doesn’t have enough data to calculate Fix solution after this period of time.
Age of differential is used in RTK so you can debug connectivity issues during the survey. This parameter indicates the latency between the time of receiving the current and previous correction.
Could you please describe the workflow you follow with the setup that you shared on the photo? Where do you place the base and rover?
Unfortunately, I can’t access the data from this link. Would you mind opening it?
The machine was traveling along and the signal degraded to Float and then Single. We stop if it degrades from Fix. Nothing noticeable happened at the base.
Any clue why it would have stopped logging and sending out corrections over Lora?
The rovers are used for guidance on an ag tractor. 2 rovers for precise heading connected over RS232. All communicating over Lora to a base at the middle of the field. Base is permanently powered.
I can check the base and make sure the log didn’t roll over and it is in the next one. Does rolling over from 1 log to another take time and cause the receiver to stop sending corrections? I thought I grabbed the log from the base that included this time frame but I may have been off by one. I will check tomorrow morning.
It is rare but occasionally the base isn’t sending anything over Lora and I have to reboot it or change the corrections to another output, apply, change back to Lora, and apply in order to get it to send data over Lora again. Not sure if this might be related to that or not.
Link should be public now.
Okay. So it appears it was just the end of the log. I’ve since learned how to merge and convert multiple UBX files…
Rover 1
Rover 2
Rover 1 experienced a drop in satellites. Is that just the number of used satellites for RTK or visible satellites? The sat visible plot doesn’t appear to corroborate the lack of satellites. Note it was rebooted to try and fix the problem.
Base
Once again I might not understand what I’m looking at so any guidance is appreciated.
Hi @kylelanman,
At the moment, the data we have seems rather fragmented so it’s difficult to see the cause of the issue here. I’m afraid I might have missed some information. To structure this, I’d ask you to provide the additional information to me:
.obs file on the last screenshot goes from 18:00 to 02:00, but the base log that you provided ends on 22:00Could you please specify the installed firmware version on all the receivers? Also, please describe the hardware setup of the base.
All of this information will help me to examine what causes these issues.
The logging does not affect the satellite reception. Once you stop logging, the base should still be able to transmit corrections as these processes are not connected directly.
The screenshot shows the number of valid satellites observed by the receiver during the PPK survey. As you have mentioned, you merged two logs so that this drop can be a cause of the log absence on this time interval.
Here is a link to all the ubx, llh, and base correction files.
The base is running 2.18.1. I’ve tried to update it but it hangs. I likely need to flash it manually but it isn’t easily physically accessible because it is up on a pole. It is about 8 feet above everything else in the area and is permanently powered.
The rovers are both 2.22.4.
Hi @kylelanman,
Thanks for the shared data.
Let me sum up several points about the issue regarding the RTK and PPK separately.
RTK
RTK solution from Rover 2 seems to be just fine. However, Rover 1 has some difficulties with obtaining a fix. You can see it on the screenshots down below.
Please, update your receivers to the latest stable v2.22.7. It contains a lot of important improvements that enhanced overall stability with solution obtaining.
PPK
There are some conclusions that I’ve come up with after looking through your logs:
there is no Fix solution for the Rover 1 between 22:08:14 and 22:09.21 as there are no base corrections for this time period
as Rover 2 happens to have a Fix all of that time, we can conclude that the base didn’t stop sending the corrections
Rover 1 doesn’t have the base correction log, raw data log, and position log between 22:08:14 and 22:09.21. It might indicate that all the logs were manually switched off
For achieving the successful PPK results, there is a need to guarantee that the receiver records the logs during the whole time period. The best way is to monitor it in ReachView during the survey.
Yes…is there anything from the logs that indicates why? I’m interested in understanding the root cause or a specific bug that was fixed. While I can upgrade it doesn’t help identify the root cause unless a specific bug was fixed that was causing the problem. Upgrading simply kicks the can down the road until I’m able to reproduce it.
I believe this is when the Rover 1 was being rebooted to try and get it to re obtain the fix.
Hi @kylelanman,
At this point, it’s quite tricky to determine what has led to these RTK results. We recommend updating the firmware to the last stable as to eliminate the issues with the future surveying. As I’ve mentioned earlier, this update brings improvements in overall stability and fixed issues with Fix re-obtaining.
Also, please check that the receiver is placed according to the requirements. Tall buildings or electrical lines nearby might cause the worsening of the observational data. You can check this guide on recommended Reach RS+ placement.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.
