RS3 receive corrections but stay on single using external radio with UHF

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


  1. Jicb smart radio
    baud rate: 19200
    Protocol: Trimtalk T450
    Air data rate: 9600
    Frequency: 441,000 mhz
    Bandwidth: 25.0khz

  2. 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

1 Like

Hi Douglas,

Welcome to the forum!

  • Can you share a photo of your setup?
  • What is the baseline of your survey?
  • Can you get a Fix solution over LoRa radio?

Please also record the following logs for at least 10-15 minutes:

  • Rover log
  • Base correction log
  • Navigation files from both base and rover

You can send this information privately to us at

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!