SPM4651T serial connection to pixhawk issues

PX4 Autopilot
1

Hey everyone, I have a SPM4651T receiver that I am attempting to connect to a pixhawk CM4 baseboard with a pixhawk 6X FC. I have attempted to follow some various instructions and fourms without success. Summary as follows:

Problem: Cannot get receiver to communicate with pixhawk. Receiver is paired to radio, but Qgroundcontrol doesn’t recognize radio as on. Seems like pixhawk serial port isn’t configured correctly but not 100% sure.

Hardware:

  • SPM4651T receiver
  • Pixhawk CM4 baseboard
  • Pixhaws 6x FC

Software:

  • PX4 Pro stable release v1.15.4

Hardware hookups I have tried:

  • SPM4651T → UART4 & I2C
  • SPM4651T → TELEM1
  • SPM4651T → TELEM3 (Telem 2 is reserved for rpi connection on my board)
  • SPM4651T → GPS2

My steps:
I am following instructions on this page, as my receiver uses SRXL2 (Spektrum RC Systems — Plane documentation). Nick seems to have success with a similar setup in his first update here Spektrum SRXL2 connection problem (AR6610T + SPM4651T) - Plane 4.1 - ArduPilot Discourse.

When I open Qgroundcontrol to modify parameters, the only parameters that exist when searching for _PROTO are the following (similarly nothing useful for _OPTIONS or _TYPE):

  • GPS_1_PROTOCOL
  • MAV_PROTO_VER
  • RC_INPUT_PROTO (which I think is for the RC IN port?)

I thought i might be a config thing for the serial ports. Tried to follow this guide (Serial Port Configuration | PX4 Guide (main)), but only have these parameters:

  • GPS_1 and _2_CONFIG
  • MAV_0, 1, and 2_CONFIG
  • MSP_OSD_CONFIG
  • RC_PORT_CONFIG

For each port I tried, I changed RC_PORT_CONFIG to match this port. When doing this and restarting, no protocol parameters came up and no connection was established.
Went down the rabbit hole of firmware, and opened the default.px4board file for my board (fmu-v6x, attached picture), but its not clear to me what entries are needed for each serial port. There is a “CONFIG_BOARD_SERIAL” entry for GPS1/2, TEL1-3 and EXT2 (which I think is UART4?). But only a “CONFIG_DRIVERS” entry for GPS. Do I need config driver entries for the port I intend to use?

Help would be much appreciated!

default_px4board
default_px4board764×1444 24.3 KB

2

What does this talk? MAVLink, SBUS, something else?

3

It uses SLXR2, which I guess is what all newer Spektrum receivers use? So not DSM or DSM2

4

Hm, and your assumption is that this protocol is supported by PX4? I wouldn’t be so sure…

5

Yeah in the subsequent research I have been doing, I am coming to the same conclusion.

My ultimate goal is to get one of my spektrum receivers to communicate to my px4 autopilot.
I have 3 receivers (1 satellite and 2 main), 6610T, 4651T, 630.
From what I understand, the 6610T can output SLXR2 and XBUS, neither of which are supported by px4 on any port. Is this accurate?
The 4651T also outputs SLXR2, so same issue as 6610T. The 630 only has the normal 6 channels of PWM output.

Is the only solution then to get a PWM to PPM converter and connect each of the 6 channels of one of the receivers to the RCIN port?

6

The set of supported protocols is listed here: Radio Control Systems | PX4 Guide (main) (this was accurate as of last year).

There were changes/discussions (that I am not tracking) around RC but these are not so much about adding new protocols as breaking up the RC_input module so that we don’t have to carry protocols support for all receivers in one monolith. Not sure where that got to.

Note that the module seems to indicate that it supports CRSF, but I know that is supported in a different module that isn’t included by default - so who knows!

Upshot, yes, you will have to use one of the supported protocols, or write a driver to support the protocol you want.

7

Thanks Hamish!

I have both a PPM encoder (to use with spektrum receivers) as well as SBUS receivers on order, one of those should work.

Follow up questions as I am digging through the source code.

  • The RC_DSM_PRT_CFG seems to allow you to run the DSM driver on a serial port. How can I confirm that the DSM driver is running on the DSM port specifically? running “dsm_rc status” results in “false”, but I dont know if thats the dsm serial driver or also the dsm driver for the dsm port.
  • How can I monitor traffic on a specific non-serial port (like the DSM port)?
  • Any tips/tricks/helpful commands to use on the mavlink console to debug the firmware? I know “?” gives a list of commands and you can combine one of those commands with “status”. Any others that are useful?
8

OK, so Pixhawk 6X configuration includes the CONFIG_DRIVERS_RC_INPUT=y but not CONFIG_COMMON_RC=y. What that means is that the individual drivers configured by RC_DSM_PRT_CFG are not present by default in this build.

So you’ll be using the RC input module, which should be already running on the RC port of your device - you can check its param, and also RC_PORT_CONFIG try getting its status.

When I run dsm_rc status on 6x I get a command not present. I don’t know what false means in this case.

On FmuV5 all the modules are present and initially when I run that same command I get:

NuttShell (NSH) NuttX-11.0.0
nsh> dsm_rc status
INFO  [dsm_rc] not running

If I enable RC_DSM_PRT_CFG then the same command gives:

nsh> dsm_rc status
INFO  [dsm_rc] Max update rate: 250 Hz
INFO  [dsm_rc] UART device: /dev/ttyS3
INFO  [dsm_rc] UART RX bytes: 0
INFO  [dsm_rc] RC state: searching for signal
dsm_rc: cycle time: 9108 events, 156787us elapsed, 17.21us avg, min 8us max 4273us 85.808us rms
dsm_rc: publish interval: 0 events, 0.00us avg, min 0us max 0us 0.000us rms

With respect to the ports, you do need to make sure nothing else you are targeting is using the port, so make sure RC_PORT_CONFIG is enabled and pointing to the RC port. Then all should be good by default.

With respect to your other questions, it is important to remember that I do the docs - I am not a developer. So most of my experience is theoretical.

  • How can I monitor traffic on a specific non-serial port (like the DSM port)?

All ports are serial ports except for PWM/dshot etc. DSM is a serial protocol running on a UART.

I don’t know how you monitor it as I have never had to.

Any tips/tricks/helpful commands to use on the mavlink console to debug the firmware? I know “?” gives a list of commands and you can combine one of those commands with “status”. Any others that are useful?

Only what is in the docs - such as uorb top - see PX4 Consoles/Shells | PX4 Guide (main)

Note that at some point you’ll probably end up having to use hardware and print statements. There are good docs on that - search for GDB.

9

Okay cool! Further debugging here, with ultimate goal of ensuring the DSM port is configured and running the right driver. Before my last post I modified the firmware to set CONFIG_COMMON_RC=y, which is why I have RC_DSM_PRT_CFG as a modifiable parameter.

  • I modified RC_DSM_PRT_CFG to target EXT2 port (no idea if this is the RC or DSM port, but its /dev/ttyS3), and am getting the same output as you when running “dsm_rc status”. So thats good.
  • I also changed RC_PORT_CONFIG to EXT2 as well (as you instructed). When I ran “rc_input status”, it says not running. I then did “rc_input start -d /dev/ttyS3”, and its searching for signal, but is rotating through all the protocols. RC_INPUT_PROTO is not a parameter I see for some reason.

Should RC_PORT_CONFIG be searching different protocols, given I have RC_DSM_PRT_CFG set to the same serial port (EXT2)? What is EXT2 exactly, is that the DSM port or the RC port? By board has a 3-pin DSM port with a JST ZH connector and a 3-pin RC IN port for a dupont connector.

10

FYI, I’m trying to get broad answers here: [Docs] [Bug] Radio Control docs don't reflect new architecture · Issue #24857 · PX4/PX4-Autopilot · GitHub

  1. I did not mean set RC_PORT_CONFIG - I meant “check it to see that it is NOT set”. This is the old rc_input param - you want to disable it so that it isn’t trying to use the same port as your new dsm module.
  2. I think RC_INPUT_PROTO is a replacement for RC_PORT_CONFIG - i.e. because rc_input is going the param is removed it has a new name in some builds to make it less likely to be used. I could be wrong. But if I’m right perhaps you aren’t using current main.
  3. If you were using rc_input, yes, it should scan the port. With the new approach you don’t have one module that does everything, scans the port, and choose the right protocol. You just enable the right protocol.
  4. No idea what EXT2 is, but you never want two modules writing to the same serial port. You want to find the port that is marked DSM on your board.
  5. I’m chatting about the bigger picture here Discord - it would be reasonable to join in because you are not the only one having problems.
11

Thanks for digging into this so thoroughly, Hamish!! Glad im not the only one confused.

I ended up using a PPM encoder to get it working, I will find some time to try it using the DSM port at some point here. In the meantime I will hop in the discord convo and close this thread.

Interesting point is that I dont see any serial port option for my DSM port. Not sure if I need to configure that in firmware. But if it does need to be configured in firmware, documentation should be updated.