SRXL2 rc protocol

[ilNonn0]

Hi all,
I was looking for a receiver compatible with my radio (Spectrum DX8G2) and I found that Spectrum suggests (here) the following models for copter: SPM4650 and SPM4651T.
Both of them use the new SRXL2 serial protocol, but unfortunately, PX4 doesn't support it right now and the flight controllers don't have a dedicated port.
I would like to know if in the next releases there will room for the integration of the SRXL2 protocol or not.

I found here the open-source library developed by Spektrum, so the work should be a matter of integration, but honestly, I don’t know where to start.
Is there anybody interested in the topic?

[kristianmk]

Spektrum seems to discontinue products using the old protocol now. So this should be interesting for Spektrum users.

[teyrana]

I'm also interested in this -- the pinouts seems to match. I'm using:

• Transmitter: Spektrum DX6e
• Reciever: Spektrum 4651t
• FMU: Holybro Pixhawk 4 flight board
• wiring:
  https://drive.google.com/file/d/1WEVORPKYTBK2P2txbnXX7Qj2etqOS7VA/view?usp=sharing

    Pixhawk 4 FMU                                  Spektrum 4651 Receiver
    "DSM/SBUS RC" Port
------------------------+
        Pin     Signal  |                         +----------------
        1       VDD_5V  |-------\        /--------| 1 - Signal
        2       SBUS    |---------------/         | 2 -
        3       RSSI    |         \---------------| 3 - V+ (5VDC)
        4       VDD_3V3 |            /------------| 4 - GND
        5       GND     |-----------/             +----------------
------------------------+                         

[teyrana]

@kekiefer Was working on the first issue (#8650) . . .
Can we get anyone on the team to chime in on whether this is a good idea for anyone else to pick up and run with?

[kekiefer]

Oh yeah I forgot all about this... I got pretty far but then ran out of steam. Communication worked and I had some basic telemetry working going back, it was mostly a matter of cleaning stuff up to make it presentable for submission. If someone is interested in bringing life back into this, I can send my patches, but they're likely to be very stale at this point.

[teyrana]

Yea, if you upload a branch (or I could email you) I'll take a look and give it a try :)

[kekiefer]

I had three branches locally that I don't think were ever completed. I forget what the rssi branches were for, but they were likely prerequisite for the main changes on pr-spektrum-telemetry (bulk that that includes srxl support). I apologize for the archaeological expedition I've sent you on, but here it all is:

https://github.com/kekiefer/Firmware/tree/pr-spektrum-rssi
https://github.com/kekiefer/Firmware/tree/pr-px4io-rssi
https://github.com/kekiefer/Firmware/tree/pr-spektrum-telemetry

Take a look and let me know if I can help.

[LorenzMeier]

I just completed a test setup today for this, so also interested.

[kristianmk]

Nice. I can also help out with the testing part.

Do you prefer an implementation using the Spektrum repo as a git submodule, or an independent implementation? (Is the license ok for your project?)

[LorenzMeier]

I quickly looked at the code and it looks generally good. The Spektrum code is pretty complex and I would much prefer to work off the commits shared here than trying to pull the Spektrum implementation in.

[teyrana]

@LorenzMeier

I just completed a test setup today for this, so also interested.

Ahhh, would you please clarify? Do you mean you have some hardware you'd want to verify the patch against?
Or a software setup?

[teyrana]

@kekeifer
Hey, I've started look at that third branch (pr-spektrum-telemetry) and I have a few questions -- nothing crazy, but just some clarifications that would help me...

1. Quite a few of the rebase conflicts involve a board_supports_single_wire(RC_UXART_BASE) function (macro?) But I'm not seeing a definition for that. Do you remember where I should be looking?
   ( Is this just referring to the half-duplex SRXL setup spektrum uses? )
2. I'm reading the SRXL2 spec Which has the plentiful details about the half-duplex, master/secondary bus... is that all stuff px4 already has? Or did we start with a partial implementation (enough to get it working?)

Anyway, I got this branch rebased on master, but I'm still going through the process of finding out if it actually works. tbc.

I'm still getting up to speed on the codebase, so apologize if I ask any stupid questions...
-dan

[kekiefer]

@teyrana the board_supports_single_wire was defined in src/drivers/boards/common/board_common.h as

/************************************************************************************
 * Name: board_supports_single_wire
 *
 * Description:
 *   A board may provide serial ports that supports single wire.
 *   This interface will call into the board support code to determine
 *   if the interface is available at runtime, on this version of the
 *   hardware.
 *
 * Input Parameters:
 *   uxart_base - the base address of the UxART.
 *
 * Returned Value:
 *   true the hardware supports this interface.
 *   false if not.
 *
 ************************************************************************************/

px4fmu-v5 (which is what I was working with) simply returned true if the uxart_base was RC_UXART_BASE.

And yes, this is to use the half-duplex UART. When singlewire mode is enabled, the serial port was configured with ioctl(fd, TIOCSSINGLEWIRE, SER_SINGLEWIRE_ENABLED) when TIOCSSINGLEWIRE was defined. This half-duplex UART is handled by nuttx, not px4.

[LorenzMeier]

Ahhh, would you please clarify? Do you mean you have some hardware you'd want to verify the patch against?
Or a software setup?

I have the hardware setup to test, but I don't realistically have time on the HW front.

[teyrana]

@kekiefer
oooph. Uhhh, that explains it -- master no longer has that path. (it looks like it was moved to boards/... but it doesn't have a 'common' directory anymore. At least the analogous path is https://github.com/PX4/PX4-Autopilot/tree/master/boards/px4/fmu-v5 ? ) Anyway, this may take me a while to figure out.

@LorenzMeier Ah. Thank you for clarifying.

I'll post my progress image once I have something interesting working on my side.

[kekiefer]

Since you really require singlewire for this to work, it's not really any better to check the board first, you can just try and fail later if it doesn't work when you try to set it up. This is what frsky does in set_uart_single_wire.

[teyrana]

@kekiefer

Okay, I'll give that a try. I don't suppose there's another driver I could use as an example, is there?

---

Still working on learning the code base -- particularly how board-specific hardware is defined. Please bear with me :/

WIP Branch is at:
https://github.com/teyrana/PX4-Autopilot/tree/pr-spektrum-telemetry

[LorenzMeier]

The right example module is this one: https://github.com/PX4/PX4-Autopilot/tree/master/src/drivers/rc_input

You can see that two other telemetry systems have already been implemented. It also references this DSM parser implementation: https://github.com/PX4/PX4-Autopilot/tree/master/src/lib/rc

[teyrana]

okay, so this is getting complicated...

--cut--
(moved extended discussion to a topic at: https://discuss.px4.io/t/px4-architecture-question-how-are-the-radio-telemetry-modules-organized/21095 )

[teyrana]

@kekiefer

I noticed there's multiple reference locations for the dsm parsers... is there a particular reason not to merge this patch with the existing spektrum_rc module?

[kekiefer]

I'm not sure what you mean. IIRC the spectrum_rc task's job is to run the parser library that lives in src/lib/rc/dsm.cpp. This behavior wasn't changed, and the existing dsm parser was extended to support srxl for sending back telemetry.

[teyrana]

I have a development branch .... building. The debug port connects, and I can run 'rc_input', but the module doesn't seem to be producing output?

[srodgers070]

Hi all,

I am somewhat new to this so forgive me if I am missing anything obvious. I currently have a Holybro PX4, a Spektrum DX8e and a Spektrum SPM4650 receiver. I am able to successfully bind the receiver and transmitter, however QGC does not seem to recognize this.

I get the following error when attempting to calibrate my radio: "Detected 0 radio channels. To operate PX4, you need at least 5 channels."

Correct me if I am wrong but this is likely occurring due to the unsupported SRXL2 protocol right? I have seen that there is an unsupported workaround using ArduPilot and one of the telemetry ports. I would rather not do this, but that may be my only option (aside from purchasing a different receiver). Is there anything I can do to help you all with developing this?

Thanks for your help,
Spencer

[teyrana]

@srodgers070
Hi, thanks for the offer!

The things that would be helpful are (1) understanding of the development board hardware at a detailed level , (2) willingness to code, and (3) flight testing ...

Unfortunately, I have not been able to reproduce either the telemetry or the control functionality, even on the bench, but when it's ready for testing, I will definitely post here.

[teyrana]

Update: First bytes:

I've gotten the fmu to read traffic from the receiver:

>>> Configure for SRXL...
>>> Parse-SRXL: 14 bytes...
        ::Parsing: 14: [ A6 21 0E 10 70 0A 01 03 3B 4D 0B 1D 4D 5A]
        ::checksum:found:     4d5a:
        ::frame-type:  21:

If you're curious, the above is a handshake request frame from the receiver.

Unfortunately, the receiver won't do anything interesting until it receives a handshake reply... so I'll have to work on that before we see anything interesting.

[teyrana]

@kekiefer

1. Would you happen to remember which serial port you needed to use to write data back to the receiver?
2. Also, which process were you using to test this? (was it rc_input or spektrum_telemetry directly?)

[kekiefer]

Would you happen to remember which serial port you needed to use to write data back to the receiver?

I was using the DSM/SBUS RC port on the pixhawk 4. You'd have to look up what that is mapped to.

Also, which process were you using to test this? (was it rc_input or spektrum_telemetry directly?)

I'm pretty sure it was all going through rc input, based on the fact that I had changes there.

[teyrana]

Ah. Okay, that's about where I got, as well.
I've verified reading from the DSM/SBUS RC port, but I don't seem to be able to write to it.
(fwiw, rc_input seems to default to /dev/ttyS3)

I guess it's just too long ago, eh?

[LorenzMeier]

Did you open the port for read/write? What is the error you are seeing? No error message but no messages on the logic analyzer?

[LorenzMeier]

Have you put the port (the RX pin) into single wire mode? Do you know how to do that? Similar to this, but MAKE SURE that it is configured for the RX pin, as you will otherwise not receive anything after that because the TX pin is being used:

PX4-Autopilot/src/systemcmds/tests/test_hott_telemetry.c

Line 112 in 46f0388

ioctl(fd, TIOCSSINGLEWIRE, SER_SINGLEWIRE_ENABLED);

[teyrana]

Update: It seems to be working

By "working", I mean:

1. can receive messages, and recognize "handshake" frames
2. Can reply with a handshake-acknowledgement
3. Can then detect & monitor control frames
   • no heartbeat is detected; not sure if the receiver expects it or not.

The settings I'm currently using are:

1. Open UART as line read/write (pre-existing code)
   

   PX4-Autopilot/src/lib/rc/dsm.cpp

   Line 411 in 4eb758e

   dsm_fd = open(device, O_RDWR | O_NONBLOCK);

2. The single-wire configuration line. Copied from:
   

   PX4-Autopilot/src/drivers/telemetry/frsky_telemetry/frsky_telemetry.cpp

   Line 203 in 4eb758e

   if (ioctl(uart, TIOCSSINGLEWIRE, single_wire ? (SER_SINGLEWIRE_ENABLED | SER_SINGLEWIRE_PUSHPULL |

p.s. I don't have a logic analyzer.

---

Sample traffic:

1. [ A6 21 0E 10 71 0A 01 03 3B 4D 0B 1D 0A 89]
   • This is a well-formed handshake request
2. [ A6 21 0E 30 10 0A 00 00 12 34 56 78 0A 2C]
   • this is a handshake acknowledgement
3. [ A6 CD 0E 00 00 00 00 00 00 00 00 00 10 34]
   • this is a well-formed control-channel frame
   • this frame is currently empty -- i.e. it is communicating zero channels.

[teyrana]

@kekiefer
Thanks :)
I can confirm that running rc_input on the pixhawk4 mainboard works, and connects to the default port.

[teyrana]

For Discussion:

1. msg/input_rc.msg->channel_count
   This message lists channel_count as a count of all channels, but surrounding code also treats it like a max-channel count...
   (eg.

   PX4-Autopilot/src/drivers/rc_input/RCInput.cpp

   Line 185 in 1654205

   for (unsigned i = 0; i < _rc_in.channel_count; i++) {

   )

   This assumption doesn't hold for the SRXL protocol, which may transmit non-continguous channels... aka channels 1,2, 10,11.

   • Is this a new design "constraint"? Have you had discussions about this before?
   • Do downstream consumers know to ignore "invalid" values in that message?

2. Channel level units --
   The input_rc.msg file lists channel levels in units of PWM % (in usec, specifically... I think)
   

   PX4-Autopilot/msg/input_rc.msg

   Line 36 in 1654205

   uint16[18] values # measured pulse widths for each of the supported channels

Is the mapping between throttle percentage and pwm width explictily documented anywhere?

I don't have a sufficient physical hardware to test this (i.e. airframes) and I wouldn't want to base any implementation off one airframe, anyways....

[teyrana]

Example debug logs

(including control frames from the SRXL receiver)

>>> Parse:SRXL: 26: [ A6 CD 1A 00 00 64 00 00 76 04 00 00 00 80 E0 7F 40 D5 00 80 00 80 00 80 8B A4]
    >> Control Frame: 
        ::Reported-RSSI:     0064  (   100)
        ::Channel-Mask:  00000476  (  1142)
        ::Channels:
            [ 1]@12: 8000 => 0400
            [ 2]@14: 7fe0 => 03ff
            [ 4]@16: d540 => 06aa
            [ 5]@18: 8000 => 0400
            [ 6]@20: 8000 => 0400
            [10]@22: 8000 => 0400

[kekiefer]

@teyrana I rebased https://github.com/kekiefer/Firmware/tree/pr-spektrum-telemetry in the last couple days, and now baseline reception of RC data via SPM4649T is working again. Something is wrong with the way it plays with the telemetry task that I haven't looked into yet.

[teyrana]

@kekiefer
Okay, I was just trying to get RC Control to work first. (I've barely even looked at telemetry, yet. )

Do you have any advice for how to scale the channels?

[kekiefer]

The protocol for these receivers is handled with the same routines as for dsm -- dsm_decode takes care of decoding the received channel ID (up to 7 channels per frame, non-contiguous, in no particular order) to map them into the channels for rc input. Or maybe I don't understand what you're asking?

I'm curious if the code I sent will also work for your receiver. The telemetry task won't start by default, and so normal rc reception should work. In addition to fixing telemetry, the other thing that needs to be sorted is pairing the receiver. I left a routine dsm_bind_srxl that can be used, but there needs to be some way to call it.

[teyrana]

The protocol for these receivers is handled with the same routines as for dsm

I'm asking a more specific question -- what are the specifications, on the px4 side, for what the expected channel values are -- in a uorb "input_rc " msg? The units are completely different -- what percentage of the pulse-width maps to what percentage of throttle (+/-)? But the SRXL protocol seems to have different units than the "dsm" protocol? (percentage throttle vs usec of pwm signal at ..... ¿50hz?)

Furthermore, the existing code is.... not the best documented. It contains fields the SRXL spec doesn't -- SRXL spec, p14: "7.7 Control Data Packet" And also contains magic numbers which don't apply to SRXL.... or at the very least, aren't apparent -- the limits in the existing dsm.cpp are applied after several transformations which are also undocumented / uncited.

the other thing that needs to be sorted is pairing the receiver.
I don't get why that's a big deal? there's a button right on the receiver to set that up?

I mean, I have a pared-back branch that's working... I could just submit that, and let people start commenting on actual code... perhaps that would be more productive?

[teyrana]

A PR is available that implements basic SRXL2 support: see #17555 .
Moving further discussion there.

[mfry90]

Resolving this issue would be very helpful, since I'm not aware of Spektrum still selling SRXL (rather than SRXL2) receivers.

I hope this PR doesn't get abandoned, but would anyone else please post currently sold Spektrum receivers that can directly connect to the SBUS/DSM port without needing the SRXL2 feature?

[teyrana]

@mfry90
Would you believe that's what I was trying to do in the first place? :/

I suggest you ask in the slack -- you'll get many more eyes on it, than here.