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.