Reach RS Base and Rover units. Probably mostly using LoRa. Is there any particular connection that is the fastest?
I know there are lots of variables and posts scattered about in the forum about getting the best possible FIX.
Is there a one stop go to for these “ideal” settings? The Quick setup got me going, but obviously all the exact settings are not explained enough to tweak to the max.
Or at least an explanation of what to set to get a FAST and CONSISTENT FIX (not so much FLOAT back and forth) that also has the lowest latency possible? I.e. fast tracking / update of rover movement, versus too much sitting and waiting.
I may be wishing for too much here, but at least I’d know that I have set everything the best as possible.
There are a lot of factors that can affect to the speed of getting fix. Satellites quantity and the quality of a signal, a distance between Base and Rover and so on.
For fast and consistent fix it’s important to have a good skyview (read more in docs) and have right RTK settings. With the latest updates, ReachView is already preconfigured with recommended settings. For faster tracking, you can change Update rate in RTK Settings tab in ReachView.
It would seem that I cannot set the Update Rate to 10 or 14Hz unless I unselect GLONASS. What is the reason for that? Controlling my rover properly requires 10Hz or better.
apparently some satellite constellations (or variations of them) are only capable of certain frequencies? So you’d have to UNSELECT them all, and systematically choose which settings offer the higher frequency you need and use that combination.
You may need to look into a ROBOTIC TOTAL STATION with a PRISM also for that kind of update speed. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
@timd1971 is right in that if you need a particular sample rate, then you will have to work with the satellite constellations that can be enabled at that rate.
I believe you are coming up against a processing limitation of the hardware. More satellite constellations enabled = more load. Faster sample rate = more load. You can have the maximum of one or the other, or a some of each.
To be clear, I am talking about the processing load that is internal to the GNSS receiver chip. This has nothing to do with Reach’s CPU.
I guess I expected your answer, except that, without good reason, I assumed it was a limitation of the CPU, I didn’t think of the processing the GNSS chip does. Mostly I want what the original post asked for, a steady fix with low latency plus a high update rate. I want to understand the effect each setting has on that overall goal. It is curious to me that even if I turn off every system except GLONASS, I am still limited to 5 Hz. Does the GLONASS system require that much more computation? If I turn on every system except GLONASS and Beidou it will update at 14 Hz. What is different about those systems? The Emlid docs are good but the explanation of each RTK parameter assumes the reader knows a fair bit about the GNNS systems and the lingo. I am getting there but there is a lot to learn and understand.
I cannot remember, and I do not have my RS units and ReachView with me, but I think if your using LoRa, the Air data rate also determines which UPDATE RATE you can use? Or was it Output power?
I think the lower this air rate, for longer distances between LoRa? and lets you get a higher update rate?
Tradeoffs here…and depends what satellite constellations are also available in your region. Best to have the MOST satellites available though for best FIX etc.
Thank you Igor, When I get time, I’ll have to look at my settings again…there seemed to be some other setting/variable (besides the satellites selection) that came into play when trying to get a higher UPDATE rate. One setting affected another.
The thing is in order to get a higher update rate such as 10 Hz or 14 Hz, a sacrifice has to be made such as disabling GLONASS, which to me makes getting a FIX terrible.
I am experiencing slow updates using MicroSurvey FieldGenius 9 using bluetooth NMEA from rover on a Trimble Nomad 900G. While staking points in FG9 seems to take 5-10 seconds each time for the GNSS triangle icon to move around and “catch up”. I assume this is because my update rate is 5 Hz, but I need more satellites for a better fix and no float.
I wonder if anyone else experiences this latency problem using Topcon Magnet Layout or Carlson SurvCE or SurvPC? Or is your current GNSS location fluid and keep up? Wonder if I use a Windows 10 tablet instead would be faster rate? The Nomad is older Windows Mobile 6.1. Or is it just the way it is at 5Hz? But in ReachView status it’s pretty instant when moving around with a fix???
If this works ok in ReachView, the problem likely isn’t the Reach RS’ fault.
The problem is more likely to be located between the Bluetooth link, the Trimble device and the software used.
Why use 5 hz for non-kinematic flows btw? If anything, having more data would worsen the latency, and if you are static on the point (or close to it) then 5 hz is just overkill?
It could be the bluetooth link etc which I will have to look into.
I need RTK, for “real time” movement feedback, not PPK. My work requires non post processing using a RS on a rover rod, not a drone etc.
Not sure I follow you about the 5 Hz overkill? From what I understand, the higher the update the better, such as 10 Hz or 14Hz, but removing GLONASS just makes getting a normal fix if at all worse. I also just have the 2 minimum messages enabled also as suggested in the DOCS.
As I understood it more systems are better, and the update rate is about movement resolution. So if static, the best you can do is enable all systems and put update rate to 1 hz, same in lora (as much as bandwidth can pull, and not all 1 hz).
When you say systems, you mean satellite constellations, correct? I understand that also from Igor stating that. The more the better obviously.
As far as the “messages”, I know there are 2 minimum required (1002 & 1006). But if I am not doing ay PPK at all, do I need ANY of these enabled? Should I just use the minimum required to keep the laod on the system at the absolute lowest to get better latency?
If I understand you correctly, 1Hz would provide a more realtime feedback than 10Hz or 14Hz? I have always been under the intention the other way around?
When I get time, I am going to try the external serial cable connection of the RS and see how that does. Seems like Bluetooth should work fine though unless some other problem contributing. I may have to get a windows 10 tablet and try the USB cable method also.
Re. LoRa then it is my impression that you should match your constellation settings in the RTK tab with the messages for LoRa. So if you are recieving Galileo, but not sending it forward, there’s no point in receiving, if talking RTk application.
1 hz vs i.e. 14 hz will only give you better resolution within the 1 second. As I said, if you’re static anyway, then you have little use for more resolution.
ok, so messages needed even if RTK (real time feedback). (not just for PPK) i.e. using GPS, GLONASS, Galileo and SBAS here in the central USA. Currently set at 5Hz with (2) min, required messages at 1Hz (1002) and 0.1Hz (1006). LoRa highest air rate and power. Kinematic, fix and hold, GLONASS AR ON for both BASE and ROVER.
I think I am real confused on the Hz rates. As far as the message Hz rates, so lower Hz rates would be less load, and maybe better real time feedback? Same for the Update Rate in RTK settings for the set of constellations chosen above? 1Hz rather than 5Hz.
I will try different settings to see what I get when I get some more time soon.
