M0184 ELRS no CRSF data after SDK 1.6.4 upgrade

[chiu pk]

Hi ModalAI team,

I am troubleshooting an ELRS/CRSF issue on a Starling 2 with the
original M0184 ELRS receiver.

IMPORTANT:
The M0184 ELRS was working normally with VOXL SDK 1.6.3.
This problem started after upgrading from SDK 1.6.3 to SDK 1.6.4.

After the upgrade, the receiver still powers on and can enter binding
mode, but PX4 never receives any CRSF frames.

Hardware:

• Drone: ModalAI Starling 2 (D0014)
• VOXL2: M0054
• SKU: MRB-D0014-4-V1-C26-T8-M36-X0
• tx config: 8 (elrs_m0184)
• ELRS receiver: M0184

Software version:

• Previous SDK: 1.6.3 (ELRS working)
• Current SDK / voxl-suite: 1.6.4
• system-image: 1.8.08-M0054-14.1a-perf
• voxl-px4: 1.14.0-2.0.142
• voxl-elrs: 1.1.6
• libfc-sensor: 1.0.12
• modalai-slpi: 1.2.3

Full voxl-version output is attached below.

Configuration / services:
After the SDK upgrade I ran voxl-configure-mpa.

The detected hardware configuration is correct:

family code:   MRB-D0014 (starling-2 (D0014))
compute board: 4 (voxl2)
cam config:    26
modem config:  36 (Bots Unlimited WiFi (M0213))
tx config:      8 (elrs_m0184)
SKU: MRB-D0014-4-V1-C26-T8-M36-X0

During voxl-configure-mpa, the ELRS configuration failed:

executing: voxl-elrs configure
elrs: px4 running but no crsf data
Error: initialize ELRS: communication channel closed

FAILED TO EXECUTE:
voxl-elrs configure

PX4 was correctly configured as:

GPS=AUTODETECT
RC=CRSF_RAW

I then fully power-cycled the Starling 2.

What I am trying to do:
Restore the M0184 ELRS functionality that was working before the
SDK 1.6.3 -> 1.6.4 upgrade.

What actually happens:
After a full power cycle, PX4 starts the CRSF driver normally:

RC: CRSF_RAW
Starting CRSF RC driver
crsf_rc start -d 7
[crsf_rc] Crsf serial opened successfully
[crsf_bridge] Created pipe 'crsf_raw' on channel 3 with control pipe enabled

However:

voxl-elrs ping

returns:

elrs: px4 running but no crsf data
Error: initialize ELRS: communication channel closed

And px4-listener input_rc always shows:

timestamp_last_signal: 0
rc_total_frame_count: 0
rc_failsafe: True
rc_lost: True
link_quality: -1

Therefore, the QUP7/CRSF driver appears to open successfully, but PX4
does not receive even a single valid CRSF frame.

Troubleshooting already performed:

1. Original configuration:
   M0184 -> QUP7

   crsf_rc start -d 7 opens successfully, but no CRSF frames are received.

2. To rule out QUP7, I temporarily disabled GPS and moved the M0184
   UART signals from QUP7 to QUP6:

   J19 Pin 10 (QUP7 TX) -> Pin 2 (QUP6 TX)
   J19 Pin 11 (QUP7 RX) -> Pin 3 (QUP6 RX)
   

   Power and GND were unchanged.

3. I started:

   px4-qshell crsf_rc start -d 6
   

   Again:

   Crsf serial opened successfully
   

   but input_rc remained:

   timestamp_last_signal: 0
   rc_total_frame_count: 0
   rc_lost: True
   

4. I restored the original wiring:

   • GPS -> QUP6
   • M0184 -> QUP7

   GPS communication on QUP6 works normally after restoration.

5. I ran voxl-configure-mpa, performed a full power cycle, and tested
   again. The ELRS behavior remains unchanged.

Questions:

1. Since the M0184 was working with SDK 1.6.3 and stopped working after
   upgrading to SDK 1.6.4, are there any known M0184 / CRSF / SLPI
   compatibility or configuration changes between these SDK versions?

2. Could the SDK 1.6.4 upgrade or voxl-elrs configure have changed or
   updated the firmware/configuration on the M0184?

3. Does rc_total_frame_count: 0 in this situation indicate that no
   UART data is being received from the M0184, or could this also be
   caused by a CRSF protocol/baud/configuration mismatch?

4. Is there a recommended way to test the M0184 UART independently of
   QUP6/QUP7?

   For example, can I connect a 3.3V USB-UART adapter to the VOXL2 USB
   host and run:

   voxl-elrs -p /dev/ttyUSB0 -b 420000 ping
   

   with:

   M0184 TX -> USB-UART RX
   M0184 RX <- USB-UART TX
   GND      -> GND
   M0184 powered separately from 5V
   

5. If the above USB-UART test is supported, is 420000 baud / 3.3V UART
   the correct electrical and serial configuration for the M0184?

Thanks.

[Ben Linne]

@chiu-pk

Can you report back the LED status? If the red LED is performing a triple blink then it's a teamrace/model mismatch issue.

If you try to stop px4 with systemctl stop voxl-px4, does voxl-elrs ping work?
Is the issue strictly with PX4 not getting the RC data?

1. I believe both SDK's should work
2. Yes the FW updated ELRS to 3.5.3.23
   https://docs.modalai.com/sdk-1.6-release-notes/#sdk-164-full-changelog-from-sdk-163
3. I think if it's not bound, but the most reliable method is to use voxl-elrs ping
4. Yes, but you need a USB-UART adapter that supports 420000 baud, the FT232R is what I typically use
5. 3.3V is the correct UART voltage

[chiu pk]

@Ben-Linne

Hi Ben,

Thanks for the information.

1. The red LED is NOT triple blinking. It is double blinking repeatedly:

   blink-blink -> pause -> blink-blink -> pause

   This appears to be the normal ExpressLRS waiting-for-binding pattern,
   rather than the triple-blink teamrace/model mismatch indication.

2. I stopped PX4 completely and tested voxl-elrs directly:

   $ systemctl status voxl-px4
   Active: inactive (dead)

   $ voxl-elrs ping
   elrs: auto-detection: voxl-px4 crsf_rc is not running, using qup7
   Sending library name request: libslpi_qrb5165_io.so
   Sending initialization request
   Error: get device info: no response from device (is it connected and powered?)

So the issue does not appear to be limited to PX4 receiving RC data.
voxl-elrs also cannot communicate with the M0184 directly over QUP7
when PX4 is stopped.

The M0184 is powered and its red LED shows the double-blink
waiting-for-binding pattern.

Since this started immediately after upgrading from SDK 1.6.3 to 1.6.4,
and you mentioned that the upgrade updates the ELRS firmware to 3.5.3.23:

• Could the M0184 firmware update have caused the receiver to lose its
  previous binding/configuration?
• Is it expected that voxl-elrs ping gets no response while the receiver
  is waiting for binding?
• Is there a recommended recovery/reflash or reconfiguration procedure
  for the M0184 in this situation?

Thanks.

[Ben Linne]

@chiu-pk

The LED status is good, this receiver should be recoverable assuming the wiring is correct.

• Could the M0184 firmware update have caused the receiver to lose its previous binding/configuration?

Yes some updates will unbind the receiver. If you want to put the receiver back in bind mode and voxl-elrs doesn't work, hold the button for 5 seconds and it should enter bind mode indicated by the led status rapid double blink

• Is it expected that voxl-elrs ping gets no response while the receiver is waiting for binding?

voxl-elrs ping should work in both cases, but to be sure try to bind and see if it works

• Is there a recommended recovery/reflash or reconfiguration procedure for the M0184 in this situation?

Try to get voxl-elrs working if possible, if not then using the expresslrs configurator pointed to our custom fork of ELRS with a USB serial adapter that supports 420000 baud will allow you to update
https://docs.modalai.com/elrs-configurator/