We are currently reworking LoRa’s driver, so you might expect a fix in the near future. Unfortunately, at the moment only rebooting might help, so we’ll try to fix this as soon as possible.
2 Likes
Hi @egor.fedorov,
This is good news. Thanks for the update. If I can be of any help with testing I’m more than happy to help out.
Regards, Ben
1 Like
For what it’s worth, I have been having very similar problems with LoRa and achieving a fix. I will also tweek my refresh rate and bandwidth settings to see if there is any improvement. Ben, your thorough reports have been most helpful–I have been away in the field in Peru outside internet and this discussion is most helpful. An update to LoRa driver would be great.
Thanks for the report. The update is currently in the very final stages, should be out soon.
1 Like
Just released v2.7.1, addressing this. Should be all fixed. Remember, that having too much RTCM3 messages is still a bad thing for RTK, but the driver will not choke on them now.
Hi @egor.fedorov,
I tested the latest ReachView release briefly this morning. I can confirm that this problem appears to have been resolved. I will test more thoroughly next week.
Thank you for such a swift resolution to this problem. I’m impressed.
Regards, Ben
3 Likes
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.
3 Likes
Hi @BenLewis,
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:
Also wondering if vibrations or pendular movement could affect the fix.
Any help on how to proper configure two Reach RS with LoRa for getting good results on my case will be welcome 
Thanks!
Iván
4 Likes
Hi @Ivan_Prado,
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.
Regards, Ben
Where are your ntrip corrections coming from?
Self generated or from a remote site?
If remote site then the trees are the answer.
I’m using LoRa corrections not NTRIP (self generated).
The base and rover are only meters apart for testing purposes.
feel free to cal me on 0438 086 322 to chat about what may or may not work…
I’m still experimenting with the settings to improve the reliability of a fix. So this is just a progress update.
So far I’m getting the best results with minimal RTCM3 messages. This allows me to keep the age of differential low, which seems to be important.
Here is an example of base mode settings that are working well for me at the moment.
I tend to switch between Galileo and QZSS depending on which satellites are in view.
With this configuration I’m not making use of many satellites (which is counter intuitive) but so far it has given me the best results.
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?
Regards, Ben
1 Like
Hi @BenLewis,
Thank’s for sharing. I’m experiencing more or less the same results than you. Particularly, the configuration I’m using now is:
LoRa 9,1 kb/s
GPS L1 Observations: 0.5Hz
ARP station coordinates: 0.1Hz
Galileo: 0.5Hz
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.
Regards,
Iván
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.
Hi Egor (@egor.fedorov) ,
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?
Thanks for sharing your ongoing voyage of discovery Ivan. Helps us avoid some of those paths too!