Hello, we just received the RS3 and are testing the UHF radio with some external radios, we use two radios on this first test and with both of them the RS3 shows on the panel that it’s receiving, but stay on single solution. On the Emlid flow app shows that it’s not receiving corrections.
What could be the problem?
The configs are listed below:
Base: Emlid reach RS2+
Conection with radio: Serial RS232
Baud rate: 19200
Radios
Jicb smart radio
model:
baud rate: 19200
Protocol: Trimtalk T450
Air data rate: 9600
Frequency: 441,000 mhz
Bandwidth: 25.0khz
Pacific Crest
Model: PDL
Baud rate: 19200
Protocol: Trimtalk T450
Air data rate: 9600
Frequency: 441,00 mhz
Bandwidth: 25.0khz
Rover: Emlid Reach RS3
Input correction : UHF
Air data rate: 9600
Frequency: 441,00 mhz
Bandwidth: 25.0khz
I am having similar issues with RS3 and TRIMMARK3, unable to maintain a reliable corrections stream.
I get a number of 7 second bursts of Emlid Flow “receiving corrections” before they stop completely. Mostly the indication is Single, and occasionally a brief best of Float before corrections stop.
It makes no difference what other cable or air baud rate or power configuration changes are made and matched across the devices, RS3 base, TRIMMARK3, RS3 Rover, or short baseline. The only change that has any effect is stopping & restarting the incoming corrections within the Rover (or completely restarting it). After doing this it will briefly start up again in spasmodic bursts of “receiving corrections” until it stops again.
I have never used this TRIMMARK 3 before so I can’t confirm it is actually good even though outwardly all appears OK, the RS3 base is happy and the Rover is at least happy accepting some of the data.
However, when digging deeper the Rover radio logs do contain a lot of error and warning entries reflecting issues with it’s internal trimtalk450 processing, and the last captured exception in the exception log also happens to relate to trimtalk45. The timestamps of the log entries show the repeat crashing and restarting of the internal trimtalk450 processes match the “receiving corrections” on and off bursts I am seeing.
So even if my TRIMMARK3 does have a problem, and so a different situation to the original post, it would appear that at minimum the RS3 31.8 code is not elegantly handling that exception and would also need to be addressed.
I’ve forwarded all the logs through to support.
On the other hand switching across to LORA is quick and simple, works fine and is reliable. Love it.
I want to update everyone that we’re in contact with @Wombo regarding this. We’re currently investigating this, and I’ll post a summary once we fix the issue. Thank you!
