All the comm parameters are matching in the base & rover. Status even shows that rover is “Receiving Corrections” but still no Fix Solution
1 Like
Presumably because your base hasn’t fixed it’s own position - as shown in your second screen-cap.
If the base hasn’t resolved own position, then your rover can’t do any better accuracy than Single.
How did you provide your base with it’s position? Did you Average-Single it, manually enter it, or feed it an external NTRIP source?
1 Like
No. Coordinates of base point are known- they have already been acquired by NTRIP caster.
Both screen grabs are from the Rover status.
I have used this procedure numerous times but sometimes I get this anomaly.
Notice the status of the Corrections - Receiving Corrections. I wait & wait but the status doesn’t change to "Fix’
I’ve edited the images to highlight the inconsistencies
1 Like
Your base has no cordinates
1 Like
No.
The rover apparently was not able to read the base coordinates hence the null entry. Base coordinates was selected from a point previously saved in the project.
Issue still unresolved
Hi Adrian,
I see the base position has already been covered. Which receiver are you using as a base?
Let’s take a closer look. Could you please update your RS3 to the firmware version 33 Beta 1? It adds signal strength indicators for the radio, which might give us a clearer picture of this issue.
Also, it’d be helpful if you could log some data while the rover is receiving corrections via UHF for 10–15 minutes. Here’s what I’d need:
- UBX raw data log (with raw data debug enabled)
- Base correction log in RTCM3
- Position log in LLH format
Once it’s done, download all the logs and generate a Full System report. You can email everything to support@emlid.com, and I’ll check it out.
1 Like
Okay. I will need some time later to get all that data collected.
In the meantime - The base is RS2 and the rover is RS3.
I usually perform some RTK gymnastics to get the Fix jolted. So for instance, I toggle the corrections source for the Rover to another available source. Sometimes that seems to do the trick. When it doesn’t, things become frustrating.
At other times I will restart the rover.
At the time of the post, I restarted both base & rover, then got a Fix solution.
Sure thing, take your time!
Do you mean switching between UHF and LoRa, or are you using an NTRIP?
1 Like
Both - switching between UHF and LoRa or between UHF & NTRIP.
The latter seems to be more effective.
Hi Adrian,
Thanks for clarifying! Have you had a chance to run the new tests with UHF yet?
You may be experiencing what I was here:
Internal RS3 trimtalk450 parser getting tangled into knots, switching from UHF and back again resets it until it falls over again.
If you are experiencing the same thing, in the RS2 base you could try limiting constellations in the corrections to reduce the volume of data and hopefully stop the RS3 choking.
The workaround I use in my Trimble base is a little more flexible and allows me to fine tune the bandwidth to maximize the stream to just under the problem amount:
Inkar, I sent a lot of background detail on this to Ruth so you may want to check with her.
Given it’s now over 12 months it would be good to get a progress update?
3 Likes
Hi Wombo,
Thanks for sharing this and for the details! I checked with the team, and there aren’t any updates on this yet. We know how important radio compatibility is, and we’re working on some updates to improve that. These changes are planned for one of the beta releases. I’ll keep an eye on things and let you know if there’s any news.
2 Likes