Add Spektrum satellite serial protocol

[dkorkmazturk]

Introduction:

This PR intends to add support for a serial protocol used by some Spektrum satellite receivers to ExpressLRS receivers. Also this is my first contribution to this project and I am pretty new to the entire ExpressLRS ecosystem. So, please let me know if there are details that I overlooked.

PR content:

This PR allows ExpressLRS receivers to communicate with flight controllers using a protocol used by some Spektrum satellite receivers, such as SPM9745. The details of the protocol is defined here: https://www.spektrumrc.com/ProdInfo/Files/Remote%20Receiver%20Interfacing%20Rev%20A.pdf

An entry called "Spektrum Satellite" is added to the serial protocol options of the receivers to allow users to choose this protocol. This protocol has different versions that vary with data resolution (10-bit or 12-bit) and channel update duration (22 ms and 11 ms). Users can choose the version of the protocol they want their receivers to operate in using an option menu added in this PR. Currently, it is missing the necessary Web UI changes but the LUA script could be used for changing these settings.

Since the channels used in Spektrum systems and ExpressLRS systems do not map one-to-one, this PR implements a simple, static channel mapping within the protocol implementation. For example, this implementation maps the 3rd channel (seems to be used for throttle by default) of the ExpressLRS to the 1st channel (throttle) of the Spektrum satellite protocol. I am actually not sure if this is necessary since the channel input sources seem to be highly configurable in EdgeTX with TX16S radio. So, for example, users may want to assign the throttle stick as the input source for the first channel in their radio instead of using this mapping. Unfortunately, I do not know if the other radios in the ecosystem give a similar flexibility. However, this mapping is necessary for the 5th channel since it does not have a special meaning in Spektrum systems. This implementation maps it to the last available channel (12) in the satellite protocol to allow users to use a wider range of values in channel 5. Channel 5 is usually used in flight controllers for various things like changing the flight modes, setting gyro gains etc.

Example use cases:

If a flight controller does not support the Crossfire protocol to communicate with a receiver, but it supports the Spektrum satellite protocol, the ExpressLRS receiver can be connected to the port that would have been used for a Spektrum satellite receiver and the ExpressLRS receiver could use the protocol implemented in this PR to communicate with the flight controller. The flight controller used in GooSky S2 would be a good example for such flight controllers.

[Krizon4]

Skookum SK 720 is I believe another example.

[dkorkmazturk]

I believe my changes are mostly ready for review. There are two things that I especially would like to hear your opinions about.

1. Channel mapping: As I indicated in my first comment, I use a static mapping table to map various channels. For example, by default, TX16S uses channel 3 for throttle while Spektrum systems use the channel 1 for throttle. TX16S seems to allow changing input sources of these channels so the throttle stick could be set as the source of channel 1 in the radio. However I am not sure if the other radios in the ecosystem give this flexibility. Also, the 5th channel usually needs to be mapped somewhere else since it does not have a special meaning in Spektrum systems, and FCs use it for all kinds of stuff. I am not the biggest fan of the mapping table I used in this implementation. I believe another solution could be giving users various settings for channel mapping. For example, one setting could apply a static mapping to the first 4 channels associated with the sticks for the radios that do not let users change the input sources of these channels while another setting could allow users to swap the 5th channel with any other aux channel. I am just not sure if it would create some confusion. We may need to document it well with some examples.

2. Naming: I believe the official name of the type of receivers that use this protocol is "Spektrum remote receiver", however, I found it easier to call them "satellite" (as they are unofficially known) while naming variables, classes etc. I believe we could advertise this protocol as "Spektrum remote receiver" in the WebUI and LUA script while internally referring it as "satellite". I just wasn't sure about creating a distinction between how we refer to this protocol in the code and how we advertise it on the UIs that interact with the users.

[pkendall64]

All EdgeTX/OpenTX based radios allow the remapping of the channels. I'm not a big fan of providing a hard-coded mapping like that. I think we need to provide the ability to remap the channels in the receiver as this will help with other protocols like SBUS where there are certain gyro stabilisers that insist on having the channels in a particular order as well.

For the naming I'm not too fussed, as long as the users know what it means I'm ok with it.

I'll get around to doing an actual review soon.

[JyeSmith]

I dont know if Im a huge fan of an extra rx lua option just for this. We could add each option to luaSerialProtocol the same way we have sbus and inverted sbus?

How common are all 4 protocols?

[dkorkmazturk]

I do not know much about SBUS but I believe "SBUS" and "Inverted SBUS" are two incompatible protocols. For example, if the FC expects "SBUS" but we choose "Inverted SBUS", it won't work. The main difference is, all these options are compatible (maybe with the exception of DSM2 22MS, I believe Betaflight separates these as Spektrum1024 and Spektrum2048, the former for DSM2 22MS and the latter for the rest). So if you choose "DSMX 11MS" or "DSMX 22MS", it is still the same protocol and expected the work the same, just with a longer update duration.

The most commons are DSMX ones while the least common ones are DSM2 ones. However, as far as I see, all DSMX Spektrum satellites are backwards compatible with DSM2.

[JyeSmith]

If we remove the luaSatelliteSystem lua option and add these to luaSerialProtocol, it means we can later use the 2 extra bits in the Config to expand serialProtocol from 16 to 64. I think this be better long term.

Is there any harm in just having the 11ms option e.g. some hardware currently in use that does not accept 11ms? 22ms is painfully slow for ELRS.

[dkorkmazturk]

Having only DSMX 11MS would be fine probably. I just wanted to give users the freedom to emulate any valid configuration available out there, especially since it basically just takes a couple of if-statements once we have the base implementation. Also, I think 50Hz option is not too much faster than 22ms, doesn't change the fact that it is painfully slow though.

[ot0tot]

If a flight controller does not support the Crossfire protocol to communicate with a receiver, but it supports the Spektrum satellite protocol, the ExpressLRS receiver can be connected to the port that would have been used for a Spektrum satellite receiver and the ExpressLRS receiver could use the protocol implemented in this PR to communicate with the flight controller. The flight controller used in GooSky S2 would be a good example for such flight controllers.

Don't these FCs/gyros also support SBUS and/or PWM input? Both of which are already supported by ELRS.

[mmosca]

If a flight controller does not support the Crossfire protocol to communicate with a receiver, but it supports the Spektrum satellite protocol, the ExpressLRS receiver can be connected to the port that would have been used for a Spektrum satellite receiver and the ExpressLRS receiver could use the protocol implemented in this PR to communicate with the flight controller. The flight controller used in GooSky S2 would be a good example for such flight controllers.

Don't these FCs/gyros also support SBUS and/or PWM input? Both of which are already supported by ELRS.

Yes, they both do.

The SK720 needed an adapter for sbus, that was probably just a hardware inverter.

[mmosca]

Why is channel 5 mapped to 11?

[dkorkmazturk]

Many FCs that use satellite receivers use the 5th channel for various things like flight mode selection, pitch for helicopters etc. A 2 position switch in channel 5 may not be enough for many users, especially when it is tied to arming. I mapped channel 5 to 11 at the output to give users as many general purpose outputs as possible at the lower channels. However, as I indicated in my very first message, I am open to suggestions related to mapping, since as @pkendall64 pointed out, mapping would be useful for SBUS too.

[dkorkmazturk]

I rebased the changes, removed the channel mapping as I believe it requires a more generic and flexible solution, and renamed the protocol to its official name in the configuration UIs.

[froqstar]

Maybe dumb question: this is not SRXL protocol but something else they just use for communication between satellite and main receiver?

[dkorkmazturk]

Yes, this is not SRXL. If you are familiar with Betaflight, these changes implement the SPEKTRUM1024 and SPEKTRUM2048 protocols. These "satellite" receivers could be connected to the flight controllers directly or could be connected to receivers that have PWM outputs (Like Spektrum AR8000). I believe the protocol is obsolete for Spektrum, however, any flight controller I've seen out there has support for it because of its simplicity.

[ajjjjjjjj]

Are you aware that on BW screens only about 12 characters will be seen so maybe "Spektrum RR"? also as mentioned previously (AFAIRC) why not just move all DSM~ entries here, like it is with CRSF, SBUS?

[dkorkmazturk]

I was finally able to get back to this. As suggested multiple times, I moved the DSM* entries with the other protocols instead of having an extra rx lua option and rebased my changes.

[dkorkmazturk]

Updated the changes with the new signature of the sendRCFrame function.