Thanks for addressing this, Egor. I wanted to follow up as well. Using one of Egor’s recommended configurations for the LoRa frequency and air data rate (in the Base Mode settings), I was able to achieve a reliable fix.
The frequency I used was 1002.0 MHz
The Air data rate I used was 9.11 kb/s
RTCM3 messages: 1 Hz for GPS and GLONASS, and 0.1. Hz for ARP station coordinates.
*Of course, on the rover, set the corrections input to these same values.
Other settings for the receiver acting as a base:
-I used positioning mode: Static.
-Disabled base correction and additional correction (though I don’t think that impacts anything…just wanted to be sure).
-Position output: Off
-Logging: Raw data, Position, Base Correction all turned On. Additional correction turned off.
With these settings, I reliably achieved a fix.
If I understand Egor’s post regarding the new 2.7.1 version of the firmware, the driver will not crash if the air data rate is higher, or the RTCM3 refresh rate is higher (e.g. 5 Hz). But I don’t know if that means it will achieve a fix with higher data rates or faster refresh values.
In short, it seems, to be safe, best to use 1 Hz RTCM 3 refresh and those frequency and correction output/input values.
Could you share with us how it is working with this configuration? (are you able to experience a continuos fix?) and exactly which configuration are you using currently.
I have been trying with the following settings that was tried by @BenLewis with latest ReachView version which includes new LoRa driver:
LoRa air data rate: 9.11 bk/s
1002 GPS L1 observations: 1 Hz
1006 ARP station coordinates: 0.1 Hz
1097 GALILEO: 0.5 Hz
And using GPS, Galileo, SBAS, QZSS on Spain (Europe) at 10Hz.
I was experiencing a continuos flickering between float and fix, which I imagine it was produced by Galileo corrections frequency (1 each 2 seconds). After setting 1Hz I was able to achieve a fix, but I’m not getting able to get an enough consistent fix.
I’m usually working with an unobstructed sky view with the rover mounted in the following vehicle:
I’m sorry for my late reply. I saw your message when you sent it through but I was busy at the time and forgot to reply.
To be honest I’ve hardly used my ReachRS since this issue was resolved. I’m planning on getting back to this project soon. So I will be able to provide more feedback then.
When I tested this fix I noticed a big improvement. That’s not to say that I achieve an RTK fix 100% of the time. But rather when I loose a fix it will now recover automatically without the need for a restart.
I expect to be using my ReachRS in about a week or so. When I do I will post the settings that are working best for me.
Please keep in mind that I’ve only been testing with a very short baseline so things may be different as the distance between the base and rover increases.
I find that when I loose a fix I can get it back quickly by setting the rover to “single” positioning mode and then switching it back to “kinematic”. If I don’t do this it can take a much longer time to return to a fix status.
What settings are working best for you? What proportion of the time do you have a fix status?
So even less messages than you, but it seems to work well… What worked badly for me was to set different frequencies to Galilo and GPS messages: it made the fix to flicker between single and fix.
Yesterday I was able to achieve a fix that last for let’s say one hour, but then it was lost and it didn’t return in the following hour (or if it returned, was for pretty small amount of time). I’m pretty sure that I would have get a fix pretty quickly if I would have restarted the rober (for example, by switching to “single” and then return back to “kinematic”).
The former makes me think that the policy “fix-and-hold” is the cause of that behavior: it works during some time, but at some point selected fix is not valid anymore but Reach keep trying with it. So I will try to use continuous mode to see how fix changes using that mode.
I have tried today with continuous mode and results are the same: fix is keep pretty well during some time, but once it is lost it doesn’t return well. Maybe sometimes a little bit, but not much. So using continuos mode doesn’t seems to solve the problem.
Just a little note, there is no profit in making your rtcm3 rate more than 1 hz. Also GPS and GLONASS observations should have same frequencies. Setting too much data to go through the LoRa radios will cause them to discard extra data and that will affect your solution quality in a negative way.
I have observed that a 2 Hz data rate has a much lower and more consistent AOD (this seems to translate into a more reliable fix, but I may be mistaken here). My application requires minimal lag in the system. Does the AOD create lag on the output data? For example, if I have an AOD of 4 sec does this mean that my current position output (NMEA) is 4 seconds old?
With regards to RTCM3 message data rates. I have been working on the assumption that the data rate of all GNSS messages (1010, 1097, 1107, 1117, 1127) need to match the data rate of GPS messages (1002). All other messages (1006, 1008, 1019, 1020) can be set independently (typically slower). Is this assumption correct? If not can you please list which messages need to have matching data rates (e.g. GPS and GLONASS) and which can be set independently?
I have noticed that the bandwidth requirement of Biedou messages is significantly higher that of other messages. Is there something special about Beidou messages that warrants this extra bandwidth?
I can answer the delay question.
No a big AOD does not mean your position solution has a lag, but it does mean the measurements provided for the RT part of the K have are getting on a bit. With the stored obs from GA their daily records have a 30 second update rate, so RTK can cope with latency in the corrections. The calculated position however is as up to date as it can be. (less than 0.2 sec if you have 5Hz output set. With conventional L1/L2 receivers I know I used to be able to cope with 15 sec delays in the correction input. Not sure what the ideal limit is with reach.
With 2 Hz AOD will obviously be less, because it is the difference between the rover’s last observation time and base’s last observation time. So, if you have 1 Hz coming in from the base and a stable link, the AOD will grow up to 1 second, then reset, then grow back to 1 second. If you have 2 Hz, AOD will grow up to 0.5 seconds.
Having 0.5 instead of 1 second will not change much in terms of RTK performance, but will definitely affect the quality of the link. In LoRa’s case that might be important.
Of course not. Rover always outputs solution in its own update rate. That only means that rover is working with outdated corrections and the solution will be slightly degraded. While rover is able to extrapolate data, big breaks in correction link might cause you to go back to float.
You needed to do this before, but that’s not an issue starting with v2.9.0. You can now set systems independently. In the release notes I mentioned using 1 Hz GPS and 0.5 Hz GLONASS and Galileo.
I am not sure about those, actually. Will try to do some logs during our next outdoor testing.
I’m also working to getting more stable fixes with LoRa.
Using recommend settings (18.23kb/s 1002 1Hz, 1006 0.1Hz, 1010 1Hz) often the AOD goes up to 2, 3, 4 sec. … often when this happens the AR stops increasing or drops…
It keeps happening even if I don’t send GLONASS messages.
Best results i get with GPS 1Hz, GLONASS & GALILEO at 0.5Hz.
The AOD increase happen even at very short baselines (few meters) with line of sight.
Under same conditions,sam messages, using TCP or NTRIP I get fixes faster and more stable, AOD stays around 1.1 s usually for NTRIP.
Some Noob questions:
I assume it’s best to keep the Antennas pointing vertical and not blocke dby metal in any direction?
Does it matter two which power output I set the Rover?
Does the Freq. matter? (Regulation wise, i have free choice here)
Wonder if you added a 1’ or 2’ extension to your tripods?
Maybe look at a rover pole also with a bipod attachment and a topo foot (dirt, terrain etc) for the rover pole so you can use a fixed antenna height on your rover instead of moving a tripod around all the time. Get a data collector mount that works with your phone or tablet also.
So much reading really helps when we get responses from the Emlid people… but really wish all the mysterious info only the Emlid team (and a few others) knew was in 1 easy spot… just seems so much TRIAL & ERROR just to get good fix to start working.
I wouldn’t imagine all these guys using Trimble, Topcon, Leica, etc equipment go through so much of this… they just wouldn’t get their work done? Yes, I know u get what u pay for. I guess my point is, takes quite a bit of time and trial to get up and working optimally. : /