Spektrum Smart ESCs and SRXL2

I have been doing some experimentation with the use of Spektrum SRXL2 based recievers with Ardupilot. After some initial struggles with getting the FC to Rx data from an AR637T (hint to anyone struggling, make sure that the signal wire is going to the Tx pin of the UART port on the FC) that is all working flawlessly.

My next challenge is ESCs. I have access to a Spektrum Avian Smart ESC, connected to a Spektrum Smart LiPo. My understanding is that the ESC communicates via SRXL2 (https://www.spektrumrc.com/on/demandware.static/-/Sites-horizon-master/default/dwbbc4f00a/Manuals/SPM-Firma-Avian-ESC-Chart-Update.pdf) which is a half duplex databus at 115200 baud (mostly) which expects to have multiple devices including recievers, flight controllers, servos, VTXs, and ESCs on it.

In my head this means that I could modify the signal wire I already have to include a connection to the ESC, this should allow the AR637T to get battery and ESC data, however I have done a lot of digging and I am not sure that Ardupilot will support controlling a Spektrum Smart ESC or process the data recieved from the ESC.

Does anyone know if my understanding is correct? It would be really lovely to have the full telemetry capability of the ESC and the ability to allow Ardupilot to control via this channel. Thanks to anyone who has input.

I don’t know the answer to you question but I do have this response from someone at Spektrum from a long time ago about something similar:

“But I will say that if they want to use redundant RF via a remote, I’d recommend connecting the remote to the 4-pin port, and connect the Pixhawk to port 1 (throttle), not the Bind/Prog/Srxl2 port. This is assuming that Ardupilot supports talking first to the AR6610T to initiate the handshake process, which it sounded like you were planning to add. That configuration puts the 4651T on its own dedicated SRXL2 bus, and puts the pixhawk on the AR6610T’s other SRXL2 bus. The dual receiver configuration works best when the AR6610T can aggregate the data from the remote and send it out to the pixhawk on a separate port, and the throttle port functions as SRXL2 as long as it is sent an SRXL2 packet within 250ms of startup, or before RF is connected (i.e. before the transmitter is turned on). I don’t suspect the latest firmware updates would even be required for this solution, unless they have really old receivers.”

What I suggest you do is post in one of the rcgroups forums which I know the spektrum devs monitor and see if you can get them to confirm what the setup should look like and then we can figure out how to make this work with AP. Might be easy or hard - not sure at this point.

Thankyou that is a good suggestion and I shall certainly try asking.

I am pretty confident that my read of the SRXL2 spec is correct, it seems to expect a bus architecture with multiple talkers and listners on the same wire, hence the address bits. My big concern though is what having a Reciever and a Flight Controller on the same bus with an ESC would do. I think that the Reciever will probably send a packet addressed to the ESC with a response command, maybe the FC is expected to intercept and reply sending its own commands. In any case a question for the OEM.

I will also have a few experiments with the setup of the connection, so far I have used the dedicated SRXL2 port on the AR637T rather than the throttle port.

We use the SRXL2 library - GitHub - SpektrumRC/SRXL2: Library code and documentation for the Spektrum SRXL2 bi-directional serial protocol - I did have a quick scan to see if it catered to your use case, but it was not obvious to me.

Yeah I have had a glance through the header files and the spec and I am pretty sure that sending the control signals requires the SRXL_MASTER sections enabled, such that the SRXL_CMD_CHANNEL packets can be sent.

I suspect what that means is that to do what i would like to do involves having the FC act as a middleman with 2 SRXL buses, one of which it acts as master on. The FC would then pass telemetry from the bus on which it is master (plus its own data) to the bus on which it is slave, it would also recieve control packes from the slave side, process them and transmit them on the master side. Then the rules in section 6.2 of the spec would be adhered to.