From d427a7fec1c777cd733493356e84b1511ae3d497 Mon Sep 17 00:00:00 2001 From: pascallanger Date: Mon, 7 Oct 2019 23:31:03 +0200 Subject: [PATCH 1/4] DSM TH_KILL channel 14 --- Protocols_Details.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Protocols_Details.md b/Protocols_Details.md index 4ac7f5d..5f010c0 100644 --- a/Protocols_Details.md +++ b/Protocols_Details.md @@ -537,7 +537,7 @@ Notes: - RX output will match the Spektrum standard TAER independently of the input configuration AETR, RETA... - RX output will match the Spektrum standard throw (1500µs +/- 400µs -> 1100..1900µs) for a 100% input. This is true for both Serial and PPM input. For PPM, make sure the end points PPM_MIN_100 and PPM_MAX_100 in _config.h are matching your TX ouput. The maximum ouput is 1000..2000µs based on an input of 125%. - If you want to override the above and get maximum throw (old way) uncomment in _config.h the line #define DSM_MAX_THROW . In this mode to achieve standard throw use a channel weight of 84%. - - TH_KILL is a feature which is enabled on channel 14 by default (can be disabled/changed) in the _config.h file. Some models (X-Vert, Blade 230S...) require a special position to instant stop the motor(s). If the channel 15 is above -50% the throttle is untouched but if it is between -50% and -100%, the throttle output will be forced between -100% and -150%. For example, a value of -80% applied on channel 14 will instantly kill the motors on the X-Vert. + - TH_KILL is a feature which is enabled on channel 14 by default (can be disabled/changed) in the _config.h file. Some models (X-Vert, Blade 230S...) require a special position to instant stop the motor(s). If the channel 14 is above -50% the throttle is untouched but if it is between -50% and -100%, the throttle output will be forced between -100% and -150%. For example, a value of -80% applied on channel 14 will instantly kill the motors on the X-Vert. ### Sub_protocol DSM2_22 - *0* DSM2, Resolution 1024, refresh rate 22ms From 1623a007a4cb984ac59a2456c6dc232952cc9885 Mon Sep 17 00:00:00 2001 From: Ben Lye Date: Tue, 8 Oct 2019 20:42:49 +0100 Subject: [PATCH 2/4] Add Channel Order doc page (#281) * Create Channel_Order.md * Update Channel_Order.md * Update README.md --- README.md | 1 + docs/Channel_Order.md | 91 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 92 insertions(+) create mode 100644 docs/Channel_Order.md diff --git a/README.md b/README.md index b3a7265..286e984 100644 --- a/README.md +++ b/README.md @@ -40,6 +40,7 @@ Current Multiprotocol boards check status: [![Travis Build Status for Multi Boar * [STM32 Multiprotocol Module](docs/Compiling_STM32.md) * [OrangeRX Module](docs/Compiling_OrangeTx.md) 1. [Transmitter Setup](docs/Transmitters.md) + * [Channel Order](docs/Channel_Order.md) 1. [How to for popular models](docs/Models.md) 1. [Troubleshooting](docs/Troubleshooting.md) 2. [Advanced Topics (not for the fainthearted!)](docs/Advanced_Topics.md) diff --git a/docs/Channel_Order.md b/docs/Channel_Order.md new file mode 100644 index 0000000..cb730b6 --- /dev/null +++ b/docs/Channel_Order.md @@ -0,0 +1,91 @@ +# Channel Order + +Channel ordering is extremely important to the Multiprotocol Module. It is vital that the module receives channel data from the radio in the order which it expects so that it can reorder the data sent over the air into the order which the receiver requires/expects. + +## Background +The Multiprotocol Module supports dozens of different protocols, many of which require channel data to be sent in a specific order (especially ones for models with integrated receiver/flight controllers). + +The Multiprotocol Module was designed to: +* Enable users to control many different models or receivers using a single transmitter system +* Work with radios where the input channels could not be reassigned +* Make it simple to configure models without having to think about the channel order they require + +To address these considerations the Multiprotocol Module will internally reorder the radio's output channels to the order required by the selected protocol before transmitting the data to the receiver. + +The Multiprotocol Module also has functionality which depends on knowing which input channel is the throttle: +* 'Bind on Channel' requires the throttle to be at -100% before the bind can be initiated (so that bind cannot be initiated while flying) +* 'Throttle Kill' needs to know which channel to apply the throttle reduction to + +**So, the Multiprotocol Module must know what order the channel data from the radio is in. However, because the radio does not tell the module which input is assigned to each channel, the order is fixed in the Multiprotocol Module's firmware. This is the _expected channel order_.** + +## Expected Channel Order +The expected channel order is the order in which the Multiprotocol Module expects to receive channel data from the radio. It associates the four primary radio inputs (aileron, elevator,throttle, and rudder) to the four output channels CH1, CH2, CH3, and CH4. In AETR, **A**ileron is on CH1, **E**levator is on CH2, **T**hrottle is on CH3, and **R**udder is on CH4. + +**The default expected channel order is AETR.** + +The Multiprotocol Module uses the expected channel order to reorder channels into the order required by the selected protocol, and to apply channel-specific features such as 'Throttle Kill'. + +If you are using firmware which has an expected channel order of AETR (the default), and you are using a protocol which has a fixed channel order†, you must create your radio models with a channel order of AETR, regardless of the channel order the receiver requires. **The Multiprotocol Module will do the conversion from AETR to the required order for you.** + +For example, Spektrum / DSM receivers expect **TAER**. When you configure the model in the radio you set it up in **AETR** order, the Multiprotocol Module reorders the channels before transmission, the receiver receives **TAER**, everything works as expected: + +Radio CH | Radio Input/Output | Module Reordering | Receiver Receives | +| --- | --- | --- | --- | +| 1 | Ail | 3 -> 1 | Thr | +| 2 | Ele | 1 -> 2 | Ail | +| 3 | Thr | 2 -> 3 | Ele | +| 4 | Rud | 4 -> 4 | Rud | + +If the radio channel order is not in the expected order (AETR) the channel reordering will be broken. + +For example, if the radio is configured with TAER, but the Multiprotocol module expects AETR, this will happen: + +Radio CH | Radio Input/Output | Module Reordering | Receiver Receives | +| --- | --- | --- | --- | +| 1 | Thr | 3 -> 1 | Ele | +| 2 | Ail | 1 -> 2 | Thr | +| 3 | Ele | 2 -> 3 | Ail | +| 4 | Rud | 4 -> 4 | Rud | + +With potentially dangerous or disasterous consequences. + +At best, you won't be able to arm your model because the throttle value is too high (because the receiver sees the elevator output, which is at 50%, where it expects throttle to be). At worst the throttle will go to 50% as soon as the model binds with the radio. + +**†** Not all protocols have a fixed channel order, see [Protocols Without a Fixed Channel Order](#protocols-without-a-fixed-channel-order). + +## Setting the Expected Channel Order +You can change the expected channel order by compiling or downloading firmware with a different channel order and flashing it to your Multiprotocol Module. + +1. If you compile your own firmware, modify the channel order line in the `_Config.h` file to match your preference +2. If you flash the pre-compiled firmware from the Releases page, download the order-specific firmware image which matches your preference + +**After updating the Multiprotocol Module you must still ensure your radio setup matches the module's expected order.** + +## Changing the Channel Order on the radio +**Your radio is not aware of the channel order expected by the Multiprotocol Module, and the module is not aware of the default channel order on your radio.** + +Once you have settled on a preferred channel order, and flashed your Multiprotocol Module with firmware which expects that order, you should: + +1. Change the Default Channel Order setting on your radio to match the Multiprotocol Module +1. Ensure that any models which you control with the Multiprotocol Module are configured with the channel order which the Module expects + +**Changing the Default Channel Order only affects new models - you must manually edit existing models.** + +## Protocols Without a Fixed Channel Order +The Multiprotocol Module also supports protocols which _do not_ have a specific channel order. For these protocols the channel order _is not_ changed and will be transmitted as received from the radio. + +Examples of protocols which are not reordered: Corona, FrSkyD, FrSkyX, FrSkyV, Hitec, and WFly. + +The full list of supported protocols, including the output channel order for each of them, is available [here](Protocols_Details.md). + +Where the channel table looks like this, with an input assigned to each channel, the output **is** being reordered: + +CH1|CH2|CH3|CH4 +---|---|---|--- +A|E|T|R + +Where the channel table looks like this, the output **is not** being reordered: + +CH1|CH2|CH3|CH4|CH5|CH6|CH7|CH8 +---|---|---|---|---|---|---|--- +CH1|CH2|CH3|CH4|CH5|CH6|CH7|CH8 From d4d0dc3dbc344e68119d928c91db94d5295f367f Mon Sep 17 00:00:00 2001 From: pascallanger Date: Thu, 10 Oct 2019 16:18:15 +0200 Subject: [PATCH 3/4] Update Compiling_STM32.md --- docs/Compiling_STM32.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/Compiling_STM32.md b/docs/Compiling_STM32.md index 5b2c4eb..716f35b 100644 --- a/docs/Compiling_STM32.md +++ b/docs/Compiling_STM32.md @@ -37,7 +37,7 @@ You are still unsure if your module can be flashed without tools or opening it? Your multi module is not USB upgradable ready, here is what you need: -| **3.3V USB-TTL Adapter** | **4-pin 2.54mm Serial Programming Header** | **4-pin 1mm Serial Programming header + cable** | **5-pin 1.5mm cable** | +| **3.3V USB-TTL Adapter** | **4-pin 2.54mm Serial Programming Header** | **4-pin 1mm Serial Programming header + cable** | **5-pin 1.25mm cable** | |:---:|:---:|:---:|:---:| | All modules | DIY, Banggood 4-in-1, iRangeX IRX4/IRX4+/IRX4Lite, Jumper 4in1 1st gen | Vantac lite, URUAV lite | T16 internal module | | | | | | From edb7729b35dc15ed0cc0dc791aa6a47f5c5b113f Mon Sep 17 00:00:00 2001 From: Ben Lye Date: Fri, 11 Oct 2019 08:46:19 +0100 Subject: [PATCH 4/4] Update README.md --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 286e984..1eb9995 100644 --- a/README.md +++ b/README.md @@ -19,9 +19,9 @@ If you like this project and want to support further development please consider ## Development status -Current Multiprotocol code check status: [![Travis Build Status for Multi](https://api.travis-ci.org/pascallanger/DIY-Multiprotocol-TX-Module.svg)](https://travis-ci.org/pascallanger/DIY-Multiprotocol-TX-Module) +Current Multiprotocol code check status: [![Travis Build Status for Multi](https://api.travis-ci.org/pascallanger/DIY-Multiprotocol-TX-Module.svg?branch=master)](https://travis-ci.org/pascallanger/DIY-Multiprotocol-TX-Module) -Current Multiprotocol boards check status: [![Travis Build Status for Multi Boards](https://api.travis-ci.org/pascallanger/DIY-Multiprotocol-TX-Module-Boards.svg)](https://travis-ci.org/pascallanger/DIY-Multiprotocol-TX-Module-Boards) +Current Multiprotocol boards check status: [![Travis Build Status for Multi Boards](https://api.travis-ci.org/pascallanger/DIY-Multiprotocol-TX-Module-Boards.svg?branch=master)](https://travis-ci.org/pascallanger/DIY-Multiprotocol-TX-Module-Boards) ## Quicklinks