Also looks good, processing wise, quite a lot fewer cycle-slips, but I wouldn’t necessarily attribute that to the switch of units, as the route seem to be very different:
Ok try this RTCM file:
https://drive.google.com/drive/folders/1YXZSD8pX0-NmaNC6sMJRAmfI_CAzAj4c?usp=sharing
Hmm… that doesn’t convert good… missing signals in especially glonass…
That would support the theory that LoRa for you is fishy.
In the Status tab in ReachView, what number does “Age of correction” display, when you are the job-site?
I have to check in the field later, but from memory I think it can be several seconds at times.
With your distance and line of sight, it should never be above 1-2 seconds.
Ok so I think that is the problem, but I have to recreate the issue in the field later and then look at it. But if that is the problem it could be as simple as a bad antenna on one of the units maybe, yes? …or a bad wire from the antenna to the circuit board internally maybe.
It could be, but probably unlikely. The Reach Units are pretty sturdy and doesn’t usually fail on hardware.
One other thing that can be causing an increasing number of seconds is sending too much data, which causes the stream to saturate and thus have too high latency. However, when that happens, you would usually see the Age of Correction value go up and up and up.
That does happen also sometimes. So… …frequency down to 1 hz… and what else
With your short baseline, you can also up the transmit data rate to 18 kb/s. That takes out a little of your range, nothing you should be able to feel at 300 meters.
1 Like
ok, so,
1 hz
18 kb/s (if possible, from memory only I thought max was 9.8 kb/s or something but I will check later)
1 Like
It is possible 
You know a data overload is making sense because what has been happening is I get frustrated and go reboot the base and the rover and change frequencies, and it seems to work for a little while after that… this is before the data overloads maybe… and then after not too long I can’t get a fix again… which is the data saturation building up and correction time just gets longer and longer.
Another question… if I do get a slip, is there anything I need to do at the rover to get it to reset, or just wait? Because at times I will have to drive in a vehicle and can lose satellites temporarily.
It is not always that a cycle will make the unit lose fix. And if it does, the unit should, pr default, regain fix within 2-5 minutes usually…
If you want to force a reset, you just change a parameter in the RTK setting. I.e going from Kinematic to Static, and back.
Ok, I have some things to try. Thanks much.
1 Like
So, changed to 1 hz.
Changed to 18 kb/s.
No luck.
Still starts out fine initially, but the base signal-to-noise ratios as seen on the rover bounce around a lot (grey bars go down to zero repeatedly). Age of correction usually 1 or 2 seconds, but frequently jumps up to 4 to 6 seconds. AR initially works it’s way up to 999, but after 5 to 10 minutes drops to about 2, then 1.5 and stays there. If I come back to within 6 meters from the base, I’m still at an AR of 1 to 2, with the base satellites (grey bars) jumping. No fix.
Here are the logs:
https://drive.google.com/drive/folders/1uLYzv_eiZoGiRm2uWRXFv-6HqXtgaTQh?usp=sharing
This sounds a lot like my issues. The dropping grey bars are probably the Glonass system. I turned those sats off and saw some of my problems go away. However after an hour or so I loose fix using gps/sbas and have to reboot the rover…
2 Likes
Hi Brian,
What’s the ReachView version installed on both your devices? Is it v2.22.4?
Brian,
I’ve checked your RTCM3 data and it seems to me that you more likely work on not the latest stable firmware. I’d recommend updating both your devices to the v2.22.4 stable update. In this firmware version, we released some important improvements in RTK performance that should resolve your difficulties.
1 Like
Ok, moving from v2.22.3 to 2.22.4 made age-of-correction better, and the base satellite signal doesn’t jump around as much. When the rover loses the base radio signal briefly, I have to reboot the rover to get the AR ratio up— the AR ratio does not recover on its own without rebooting the rover. Each reboot means waiting to pick up satellites to get AR up again. This takes about 7 minutes-- in my application the base and rover will get connected often as I drive around the mine and pick up one point at a time. So maybe for this application I just need to use PPK. I want to try it again at an open mine site before we change anything else. I’ll report back after I do that.
1 Like
Hi Brian,
That’s not normal behavior. Could you clarify if the Age of Differential starts to increase at this moment?
May I ask you to share raw data, RTCM3 log, and position log from the rover and raw data log from the base recorded during this test?
Thanks.
1 Like