Reach M+ RTK Correction thru Radio on USB port.(connected to UART on NAVIO2)

Hello,

I have 2 Reach M+ RTK units.

First off - I have both units working when connected to send Connections over TCP - All good.
Problem is trying to make it work over Radio.

*One is base - Transmitting on Radio Corrections on Radio.
*Second one is attached to Rover like below
Reach m+ - S1 port -> Navio2 UART (is this correct? )
USB port -> USB-OTG -> Connected to radio have a standard telemetry radio for recieving corrections.

According to this diagram (https://docs.emlid.com/reachm-plus/img/reachm-plus/ardupilot-integration/navio2-reachm.png) it says S2 should be connected (but none of the connectors in the package when shipped will connect to S2 - this S2 connector has 1 pin more than S1) .

how do i make this work ? Screen shot below.

Hi @sundru,

Let’s continue our conversation here.

Yes, Reach M+ should be connected to Navio2 UART over S1 port. Thanks for the report, we’ll fix it in our docs!

Your setup looks correct.

May I ask you to share the screenshot of ReachView Status tab while you’re trying to get corrections? Do you get fix solution with this setup?

Could you please make sure position is transmitted to Navio2 UART? You can do it using screen /dev/ttyAMA0/ 38400

Thanks you , am configured and all set. My current issue is that i have a high degree of interference on raspberry pis from the Reach M+ unit . is there any way to disable Wifi completely after setup on the reach M+ ? maybe thru usb or other mechanism ?

Hi @sundru,

I don’t recommend to disable Wi-Fi completely. Have you tried to cover Reach M+ with foil? Please also share your hardware setup photo.

Below is my setup , Will be trying to shield it with EM shielding cloth, but would still like to know how to disable WIFI/reenable. I also know its going to increase the heat generated on Reach M+ once you wrap with shielding cloth, which is already warm to the touch (and summer here can reach upto 100F with humidity.

Hi @sundru,

There is no way to turn off Wi-Fi in ReachView app. Is it possible for you to change the setup and move Reach M+ away from RPi?

Hey Tatiana,

Hoping you can help with this. I’ve started doing all kinds of EMI shielding and still saw no difference in what was happening.
But one symptom is clear the loss of data only happens when ReachM+ is connected to Navio2. If I unplug ReachM+ from UART Navio2 is very stable.

Second Symptom Navio2 is reading RC input channel and publishing them on /mavros/rc/in node @10hz, connecting the ReachM+ you start seeing pauses in the rc channel published data ex: rostopic echo /mavros/rc/in

What i now think is happening - Navio2 is choking on the serial data input @baud rate of (38400 , however if you see screenshot it shows 115200 - FCU GPS1 - ublox) from ReachM+ (or) suffering degradation of serial reads (or) having cpu cycle contention problems with sampling rc input (sbus) at same time. I also saw below error when the fcu completely stopped responding.
At this point the entire RPI also stop responding (WIFI networking)

Setup :
ROVER HW Setup -> RPI + (sbus rc channels read) Navio2 (uart ) -> (S1 port) Reach M+ (Usb) -> Radio Telem (915Mhz)
BASE HW Setup -> Reach M+ (S1 port) -> Radio Telem (915Mhz)

Screen streaming /dev/ttyAMA0 @38400
image

Hi @sundru,

The GPS 1 from the screenshot is built-in Navio2 GNSS module. So 115200 isn’t Reach M+ baud rate.

May I ask you if you use Ardupilot? Could you post here its configuration file?

In your setup, is there another radio connected to RPi?

Please also clarify your power supply scheme.

heres a rough diagram on rover. Also ardurover config below.

cat /etc/default/ardurover

Default settings for ArduPilot for Linux.

The file is sourced by systemd from ardurover.service

TELEM1="-A udp:127.0.0.1:14650"
TELEM2="-E /dev/ttyAMA0"

Options to pass to ArduPilot

ARDUPILOT_OPTS="$TELEM1 $TELEM2"

Only thing connected to RPI is Power and Ethernet.
One another question the telemetry link between the radios what baud should this be set to ? currently gave it @57600, should this match to 38400 (which is whats set between reach m+ and navio2)?

Hi @sundru,

There is no need to use the same baud rate for both telemetry and UART.

Have you tried to connect Reach without radio? If the issue persists?

May I ask you to describe more precisely how Reach influences to RPi?

Also please try to supply Navio not over RPi micro USB, but over Navio power port.

May I ask you to describe more precisely how Reach influences to RPi?

Once ardurover initlializes with ReachM+ enabled.
* Responsiveness of the RPI over wifi or physical networking decreases over a matter of minutes.
after few mins it completely stops responding, now only option to power cycle Navio2/RPI.

  • Data being published from ardupilot starts sputtering or become intermittent, with pauses. After sometime I see the heartbeat failure (screenshot above) from FCU and the whole rpi stops responding.

Have you tried to connect Reach without radio? If the issue persists?

Yes same problem i unhooked telem radio and the degradation happens same way. I also noticed the RC channel messages being published starts dropping as this starts happening in a matter of a minute(brief pauses start happening) after ardupilot comes up.

(Just Navio2 without ReachM+ connected is very stable)

After a couple of days of pulling hair finally fixed it. Seems simple now. :slightly_smiling_face:
The correction data coming from ReachM+ on the serial port has characters that mean something to the kernel and sysrq when serial login console shells are enabled on the RPI.

Hopefully this helps folks running into similar problem

Uploaded this video :
https://www.youtube.com/watch?v=y-bTAMc8-IQ note when the Getty service stops.

Solution :
**Disable the Serial Console option ** on raspberry pi.

$sudo raspi-config
navigate ->
interfacing options
Disable Serial console login shell ----- THIS IS THE KEY
Enable Serial hardware.
Save and reboot.

1 Like

It’s great that you resolved it! Thanks for sharing the solution. :slightly_smiling_face:

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.