I’m not sure if this is a bug, expected behavior or myself struggling to find a setting in ReachView. I have dual Reach RS+ receivers on a rover to provide accurate heading at low speeds. A 3rd receiver is used as a base station.
Yesterday I was tracking down a problem and the root cause was that one of the two Reach RS+ receivers was only sending NMEA data out the serial port at 1hz instead of the normal 5 hz.
This is a screenshot of ROS bag file showing that the nmea strings are being received at 1hz from the right receiver and 5hz from the left receiver.
First off is this configurable? If so, where?
If it isn’t configurable then what determines if the NMEA packets are sent at 1hz or 5hz?
I will add that due to an unrelated issue the base station wasn’t sending corrections so both receivers only had a solution status of single. Still not sure why one would send data at 5hz and the other at 1hz.
The receivers are currently running ReachView 2.22.3
It should be in the RTK Settings at the bottom called Update Rate. Are you running a standard base/rover setup? No NTRIP?
That is set to 5hz on both units.
Oh, ok. MI misread the beginning of the post. So 1 base and 2 rovers? One of the rovers is at 1hz? The update rate should be the poll of the receiver to the satellites. If you’re using LoRa the Air data Rate is the frequency at which the corrections are being sent and received. If these don’t match then you won’t get a fix.
Given corrections weren’t working on either receiver because the base wasn’t sending them I essentially had two receivers on the rover with single fixes, no RTK being used. 1 sent nmea at 1hz and the other at 5hz.
You’re not using LoRa? If not what protocol? Sounds like I may not be familiar with how you are configured. And are you logging as well for PPK?
When Lora isn’t working I’m not using it…that is correct…I was going to start another thread about that issue.
I’m not logging for PPK.
I’m asking what determines the NMEA output rate of the receiver in a stand alone configuration where corrections aren’t being used.
Darn, sorry I couldn’t help. So you’re essentially using DGPS? Serial, TCP or Bluetooth? I always use LoRa and/or PPK. I usually am able to get a fix by adjusting the LoRa frequency, Air Data Rate and/or the constellations being used. Different frequencies work better in specific conditions. I am interested to see how it turns out and learn more!
As Michael has pointed out, the position output rate should be the same as the update rate you specified in the RTK Settings.
May I ask you to update your receiver to the latest stable version v2.22.4 and test it? It’d be also great if you could share your NMEA log with us.
Meanwhile, I’ll try to reproduce this issue and will get back to you once there’s news.
When I tested yesterday afternoon everything was working correctly at 5hz. The 1hz seems like a fluke error but I need to understand what causes it so I can prevent it in the future. Our gps safety watchdog was being starved regularly.
I have all logging on the receivers disabled as it was suggested in the past on here that I do that for performance reasons. I can provide the NMEA strings from the ROS bag file if that is helpful.
I don’t have a detailed system report because the receiver had been powered down and the root cause was determined the next day after reviewing log files from the machine.
I will try to get the receivers updated today or tomorrow. I’m a little hesitant to update to the latest version given this isn’t a known problem that has been fixed. The receivers have been working well the past couple of weeks and I have to weigh the risk of a new bug causing other problems.
Thanks for you patience!
We have tested the NMEA position output from Reach RS+ with different update rates set in the RTK Settings. We can confirm that the frequency of the position output is the same as the one you establish in the RTK Settings. There are no issues with it.
Feel free to start a new thread if there are any questions or additional reports on it.