# Home The **MULTI-Module** is a 2.4GHz transmitter module incorporating four different RF components, enabling almost any RC transmitter to control many different receivers and models, including most standard RC protocols, and a large (and ever-increasing) number of popular helicopters, planes, quad-copters, and mini-quads. The MULTI-Module is a non-profit open-source project, by hobbyists, for hobbyists. ![](/files/-LydPZR-cMVwVCXti73K) ## About the Project The MULTI-module started as a DIY build and many people still use their own custom-built modules. Nowadays several different RC manufacturers now sell off-the-shelf MULTI-Modules. Although there are a few differences in the hardware, the DIY and off-the-shelf modules all run the same firmware, which is developed and maintained by the MULTI-Module developers, and made available under an open source license. The documentation on this site is written (and kept updated) for the latest version of the MULTI-Module firmware, and applies to all versions of MULTI-Module hardware. ## Terms and Conditions While every effort has been made to ensure that the information in this documentation is correct, no warranty is given, and no liability is accepted for any inaccuracies. Any trademarked names mentioned in this documentation are the property of their owners. Any links to products, re-sellers or retailers are for convenience or reference only and are not an endorsement. # Module Hardware Originally only available as a 'DIY' project, several manufacturers now produce the MULTI-module. Modules are available to fit in the standard 'JR' style module bay found on most radio systems, or 'Lite' modules available for the smaller module bay of 'Lite' radios. Some radios are available with internal MULTI-module boards. Internal modules work in exactly the same was as external modules. All currently-available MULTI-Modules are based on an STM32 micro-processor. ## External Modules Examples of currently available MULTI-Modules: * iRangeX [IRX4](https://www.banggood.com/IRangeX-IRX4-2_4G-CC2500-NRF24L01-A7105-CTRF6936-4-IN-1-Multiprotocol-STM32-TX-Module-With-Case-p-1197130.html) / [IRX4 Plus](https://www.banggood.com/IRangeX-IRX4-Plus-2_4G-CC2500-NRF24L01-A7105-CYRF6936-4-IN-1-Multiprotocol-STM32-TX-Module-With-Case-p-1225080.html) / [IRX4 Lite](https://www.banggood.com/IRangeX-IRX4-LITE-CC2500-NRF24L01-A7105-CYRF6936-4-IN-1-Multiprotocol-TX-Module-for-Frsky-X-lite-p-1346927.html) * Jumper [JP4IN1 / JP4IN1-SE](https://www.jumper-rc.com/products/modules/multi-protocol-module/) * Hobby Porter [JP4IN1](https://www.hobbyporter.com/hobby-porter-jp4-in-1-jp4in1-multi-protocal-radio-transmitter-module_p0254.html) {% hint style="danger" %} **Vantac MPM Lite, URUAV TMX5, and URUAV TMX5 Lite modules are not supported by the MULTI-Module project.** These modules have been found to be be using the incorrect MCU (processor), which does not have the correct amount of flash memory. If you have one of these modules you should contact the vendor or manufacturer for support and firmware updates. See [here](https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/issues/393) for more information. {% endhint %} All product links are for convenience/reference only, not an endorsement for a brand or vendor. ![iRangeX IRX4 Plus MULTI-Module](/files/-Lws1u2YUz7JfxKXUe5w) #### Module Hardware Differences As well as the different JR and Lite modules, there are other differences in different manufacturer's MULTI-modules: * Most modules have two LEDs, some have none * Some modules have a 16-position selector dial and a button, some do not * Most modules have a USB port, some do not {% hint style="success" %} When purchasing a MULTI-Module, one with LEDs and a USB port is recommended for ease of troubleshooting and updating. {% endhint %} ## Radios with Internal Modules Radios with internal MULTI-Modules include: * Jumper T12 Pro Hall * Jumper T16 Pro / Pro Hall / Pro Hall V2 * Jumper T18 * RadioMaster TX12 * RadioMaster TX12 MKII (CC2500 Version) * RadioMaster TX16S * RadioMaster TX16S SE * RasioMaster TX16S MKII (4-in-1 Version) * RadioMaster Zorro (4-in-1 or CC2500 Version) ![Jumper T16 Internal MULTI-Module](/files/-Lws4j3xXzsozfpZGJbo) {% hint style="info" %} Some radios have a limited internal module which only includes the CC2500 RF component, limiting them to the protocols which are implemented on this module. To be able to use the full set of 100+ protocols, choose a radio with 4-in1 module rather than the CC2500 version. {% endhint %} # Unsupported Modules Unfortunately some MULTI-Module manufacturers have not followed the published open source schematic when designing and manufacturing their modules. The most serious problem is where some manufacturers have used the incorrect microprocessor (MCU) in the module (even though they may advertise it as having the correct one). {% hint style="info" %} If you flash firmware v1.3.1.65 or newer to a MULTI-Module with the incorrect MCU, the red LED will blink the 'SOS' pattern (three short, three long, three short) and the module will not function. The radio will display **NO MULTI TELEMETRY** in place of the MULTI-Module firmware version. {% endhint %} Modules which are known to be fitted with the incorrect MCU: * URUAV TMX5 * URUAV TMX5 Lite * Vantac MPM Lite * Some Jumper T16 Pro internal modules {% hint style="warning" %} These modules, and any others fitted with incorrect components, **are not supported** by the MULTI-Module project when running firmware which was compiled for the 128KB MCU. {% endhint %} Modules with the incorrect MCU have been unreliable and have experienced erratic and unpredictable behavior. ## **More Information** The correct MCU part is an STM32F103CBT6. This version of the STM32F103 has 128KB of flash memory. The incorrect part which is fitted to the modules mentioned above is an STM32F103C8T6. The C8 part officially has only 64KB of flash memory. It is known that some STM32F103C8T6 chips actually do have 128KB of flash, but it is not guaranteed and cannot be relied upon. {% hint style="info" %} The full release of the MULTI-Module firmware requires 128KB of flash in order to have all the available protocols. Fewer than half the protocols fit in 64KB of flash. {% endhint %} Because all protocols do not fit on a 64KB module, firmware for them must be compiled with only the required protocols selected. For this reason firmware downloads are not provided for 64KB modules. ### Identifying the STM32 MCU The reference pictures below can be used to identify which MCU is fitted. ![Correct MCU - STM32F103CBT6](/files/-MInnDXc9p8XIFvaowO_) ![Incorrect MCU - STM32F103C8T6](/files/-MM0ECZZdsJ6efXjQI9M) ## What you can do ### Option 1 - Replace the Module The easiest option is to replace the module with one which has the correct MCU. You should complain to the manufacturer or vendor of your original module and ask for a refund as they have not followed the specification. For most people, this is the recommended option. ### Option 2 - Replace the MCU If you have the tools and skills you can replace the MCU on your module. You will need to de-solder the existing MCU and replace it with a genuine STM32F103CBT6. Although it is not easy, several people have done it successfully. This option is only recommended if you have the right tools and soldering skills. ### Option 3 - Compile your own firmware You can download the MULTI-Module firmware source from Github, modify the configuration to remove the protocols you don't need, compile the firmware, then flash it to your module. {% hint style="warning" %} You must select the STM32F103C8 MULTI-Module board when compiling as this will ensure that the firmware will operate on the 64KB MCU. **You will need to reduce the included protocols in order to make the firmware fit in the reduced flash space.** {% endhint %} Instructions for downloading and compiling the firmware are available [on the Github repository](https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/docs/Compiling_STM32.md). ### Option 4 - Use firmware v1.3.1.59 or older {% hint style="danger" %} **This is not recommended and not supported.** MULTI-Module firmware v1.3.1.59 or older will run on 64KB MCUs but this is strongly discouraged and not supported due to the risk of unreliable or unpredictable operation. {% endhint %} # Radio Compatibility The MULTI-Module is compatible with a wide range of radios but works especially well in those which support serial communication with an external module. Radios which do not support serial mode can operate the MULTI-Module in PPM mode, which is an industry standard available on all radios with a module bay or trainer port. {% hint style="success" %} Using the MULTI-Module in Serial Mode is strongly recommended, if your radio supports it. {% endhint %} ### Serial Radios Most modern radios support serial communication with the MULTI-Module. This includes: * FrSky Taranis X9D, X9D+, 9XE * FrSky Taranis Q X7 * FrSky Taranis X-Lite * FrSky Horus X10, X10S * FlySky TH9X * Turnigy 9X family * Jumper T12 * Jumper T16 * Jumper T18 * RadioMaster TX12, TX12 MK II * RadioMaster TX16S, TX16SE, TX16 MK II * RadioMaster Zorro ### PPM Radios PPM mode offers the same core functionality as serial mode, but it is harder to configure the module, and typically requires custom-compiled firmware. {% hint style="danger" %} A MULTI-Module with a 16-position rotary selector and a bind button is required to use PPM mode. {% endhint %} For more information about using the MULTI-Module in PPM Mode, see the PPM Mode page. {% content-ref url="/pages/-LxqFDhIsVhe0g1BHOQx" %} [PPM Mode](/using-the-module/ppm-mode) {% endcontent-ref %} ### Radio Firmware Radios running [erSkyTX](http://www.er9x.com/), [OpenTX](http://www.open-tx.org/), and [EdgeTX ](http://edgetx.org/)support the MULTI-Module. The latest version of the radio firmware is always recommended. # Supported Protocols The MULTI-Module supports dozens of different protocols, with many having several sub-protocols. The list of supported protocols is below. Details of individual protocols can be found by clicking on the protocol name. {% hint style="warning" %} Most protocols work exactly like they do on original equipment. Newly-added protocols may require testing and feedback from end users before they are perfected. Where this is the case it is usually mentioned in the [Protocol Details](/using-the-module/protocol-details) pages. Feedback can be provided on [RC Groups](https://www.rcgroups.com/forums/showthread.php?2165676-DIY-Multiprotocol-TX-Module) or [GitHub](https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/issues). {% endhint %} ## Transmitter Protocols | Name | Number | Sub 0 | Sub 1 | Sub 2 | Sub 3 | Sub 4 | Sub 5 | Sub 6 | Sub 7 | | ------------------------------------------------------------------- | ------ | ---------- | --------- | ------------ | ------------ | ----------- | ------------ | --------- | ------ | | [Assan](/using-the-module/protocol-details/assan) | 24 | ASSAN | | | | | | | | | [Bayang](/using-the-module/protocol-details/bayang) | 14 | Bayang | H8S3D | X16\_AH | IRDRONE | DHD\_D4 | QX100 | | | | [Bugs](/using-the-module/protocol-details/bugs) | 41 | BUGS | | | | | | | | | [BugsMini](/using-the-module/protocol-details/bugs-mini) | 42 | BUGSMINI | BUGS3H | | | | | | | | [Cabell](/using-the-module/protocol-details/cabell) | 34 | Cabell\_V3 | C\_TELEM | - | - | - | - | F\_SAFE | UNBIND | | [CFlie](/using-the-module/protocol-details/cflie) | 38 | CFlie | | | | | | | | | [CG023](/using-the-module/protocol-details/cg023) | 13 | CG023 | YD829 | | | | | | | | [Corona](/using-the-module/protocol-details/corona) | 37 | COR\_V1 | COR\_V2 | FD\_V3 | | | | | | | [CX10](/using-the-module/protocol-details/cx10) | 12 | GREEN | BLUE | DM007 | - | J3015\_1 | J3015\_2 | MK33041 | | | [Devo](/using-the-module/protocol-details/devo) | 7 | Devo | 8CH | 10CH | 12CH | 6CH | 7CH | | | | [DM002](/using-the-module/protocol-details/dm002) | 33 | DM002 | | | | | | | | | [DSM](/using-the-module/protocol-details/dsm) | 6 | DSM2\_1F | DSM2\_2F | DSMX\_1F | DSMX\_2F | AUTO | | | | | [E010 R5](/using-the-module/protocol-details/e010-r5) | | | | | | | | | | | [E016H v2](/using-the-module/protocol-details/e016h-v2) | | | | | | | | | | | [E01X](/using-the-module/protocol-details/e01x) | 45 | E012 | E015 | E016H | | | | | | | [E129](/using-the-module/protocol-details/e129) | | | | | | | | | | | [ESky](/using-the-module/protocol-details/esky-150) | 16 | ESky | ET4 | | | | | | | | [ESky150](/using-the-module/protocol-details/esky-150) | 35 | ESKY150 | | | | | | | | | [ESky150V2](/using-the-module/protocol-details/esky-150-v2) | 69 | | | | | | | | | | [Flysky](/using-the-module/protocol-details/flysky) | 1 | Flysky | V9x9 | V6x6 | V912 | CX20 | | | | | [Flysky AFHDS2A](/using-the-module/protocol-details/flysky-afhds2a) | 28 | PWM\_IBUS | PPM\_IBUS | PWM\_SBUS | PPM\_SBUS | PWM\_IBUS16 | PPM\_IBUS16 | | | | [FQ777](/using-the-module/protocol-details/fq777) | 23 | FQ777 | | | | | | | | | [FrSkyD](/using-the-module/protocol-details/frsky-d) | 3 | D8 | Cloned | | | | | | | | [FrSkyL](/using-the-module/protocol-details/frsky-l) | 67 | LR12 | LR12\_6CH | | | | | | | | [FrSkyR9](/using-the-module/protocol-details/frsky-r9) | 65 | R9\_915 | R9\_868 | R9\_915\_8CH | R9\_868\_8CH | R9\_FCC | R9\_FCC\_8CH | | | | [FrSkyV](/using-the-module/protocol-details/frsky-v) | 25 | FrskyV | | | | | | | | | [FrSkyX](/using-the-module/protocol-details/frsky-x) | 15 | CH\_16 | CH\_8 | EU\_16 | EU\_8 | Cloned | Cloned\_8 | | | | [FrSkyX2](/using-the-module/protocol-details/frsky-x2) | 64 | CH\_16 | CH\_8 | EU\_16 | EU\_8 | Cloned | Cloned\_8 | | | | [FX816](/using-the-module/protocol-details/fx816) | 28 | FX816 | P38 | | | | | | | | [FY326](/using-the-module/protocol-details/fy326) | 20 | FY326 | FY319 | | | | | | | | [GD00X](/using-the-module/protocol-details/gd00x) | 47 | GD\_V1\* | GD\_V2\* | | | | | | | | [GW008](/using-the-module/protocol-details/gw008) | 32 | GW008 | | | | | | | | | [H8\_3D](/using-the-module/protocol-details/h8-3d) | 36 | H8\_3D | H20H | H20Mini | H30Mini | | | | | | [Height](/using-the-module/protocol-details/flyzone) | 53 | 5CH | 8CH | | | | | | | | [Hisky](/using-the-module/protocol-details/hisky) | 4 | Hisky | HK310 | | | | | | | | [Hitec](/using-the-module/protocol-details/hitec) | 39 | OPT\_FW | OPT\_HUB | MINIMA | | | | | | | [Hontai](/using-the-module/protocol-details/hontai) | 26 | HONTAI | JJRCX1 | X5C1 | FQ777\_951 | | | | | | [HoTT](/using-the-module/protocol-details/hott) | 57 | Sync | No\_Sync | | | | | | | | [Hubsan](/using-the-module/protocol-details/hubsan) | 2 | H107 | H301 | H501 | | | | | | | [J6Pro](/using-the-module/protocol-details/j6-pro) | 22 | J6PRO | | | | | | | | | [JJRC345](/using-the-module/protocol-details/jjrc345) | 71 | JJRC345 | | | | | | | | | [KF606](/using-the-module/protocol-details/kf606) | 49 | KF606\* | | | | | | | | | [KN](/using-the-module/protocol-details/kn) | 9 | WLTOYS | FEILUN | | | | | | | | [Kyosho](/using-the-module/protocol-details/kyosho) | 73 | FHSS | | | | | | | | | [LOLI](/using-the-module/protocol-details/loli) | | | | | | | | | | | [M-LINK](/using-the-module/protocol-details/m-link) | 78 | | | | | | | | | | [MJXq](/using-the-module/protocol-details/mjxq) | 18 | WLH08 | X600 | X800 | H26D | E010\* | H26WH | PHOENIX\* | | | [MT99xx](/using-the-module/protocol-details/mt99xx) | 17 | MT | H7 | YZ | LS | FY805 | | | | | [NCC1701](/using-the-module/protocol-details/ncc1701) | 44 | NCC1701 | | | | | | | | | [OMP](/using-the-module/protocol-details/omp) | 77 | | | | | | | | | | [OpenLRS](/using-the-module/protocol-details/openlrs) | 27 | | | | | | | | | | [Pelikan](/using-the-module/protocol-details/pelikan) | 60 | | | | | | | | | | [Potensic](/using-the-module/protocol-details/potensic) | 51 | A20 | | | | | | | | | [Propel](/using-the-module/protocol-details/propel) | 66 | 74-Z | | | | | | | | | [Q2X2](/using-the-module/protocol-details/q2x2) | 29 | Q222 | Q242 | Q282 | | | | | | | [Q303](/using-the-module/protocol-details/q303) | 31 | Q303 | CX35 | CX10D | CX10WD | | | | | | [Q90C](/using-the-module/protocol-details/q90c) | 72 | | | | | | | | | | [RadioLink](/using-the-module/protocol-details/radiolink) | 74 | Surface | Air | | | | | | | | [Realacc](/using-the-module/protocol-details/realacc) | 76 | R11 | | | | | | | | | [Redpine](/using-the-module/protocol-details/redpine) | 50 | FAST | SLOW | | | | | | | | [Futaba/SFHSS](/using-the-module/protocol-details/sfhss) | 21 | SFHSS | | | | | | | | | [Shenqi](/using-the-module/protocol-details/shenqi) | 19 | Shenqi | | | | | | | | | [Skyartec](/using-the-module/protocol-details/skyartec) | 68 | Skyartec | | | | | | | | | [SLT](/using-the-module/protocol-details/slt) | 11 | SLT\_V1 | SLT\_V2 | Q100 | Q200 | MR100 | | | | | [SymaX](/using-the-module/protocol-details/symax) | 10 | SYMAX | SYMAX5C | | | | | | | | [Tiger](/using-the-module/protocol-details/tiger) | 61 | Tiger | | | | | | | | | [Traxxas](/using-the-module/protocol-details/traxxas) | 43 | RX6519 | | | | | | | | | [V2x2](/using-the-module/protocol-details/v2x2) | 5 | V2x2 | JXD506 | | | | | | | | [V761](/using-the-module/protocol-details/v761) | 48 | 3CH | 4CH | | | | | | | | [V911S](/using-the-module/protocol-details/v911s) | 46 | V911S\* | E119\* | | | | | | | | [WFly](/using-the-module/protocol-details/wfly) | 40 | WFLY | | | | | | | | | [WK2x01](/using-the-module/protocol-details/wk2x01) | 30 | WK2801 | WK2401 | W6\_5\_1 | W6\_6\_1 | W6\_HEL | W6\_HEL\_I | | | | [XK](/using-the-module/protocol-details/xk) | 62 | X450 | X420 | | | | | | | | [YD717](/using-the-module/protocol-details/yd717) | 8 | YD717 | SKYWLKR | SYMAX4 | XINXUN | NIHUI | | | | | [ZSX](/using-the-module/protocol-details/zsx) | 52 | 280 | | | | | | | | ## Receiver Protocols Receiver (RX) protocols are used to emulate a receiver using the MULTI-Module. These protocols allow a radio with two modules to be used as a wireless trainer by receiving a transmission from the student radio on the MULTI-Module then re-transmitting it from another module. | Name | Number | Sub 0 | Sub 1 | Sub 2 | Sub 3 | Sub 4 | | -------------------------------------------------------------------------- | ------ | ----- | ------- | ----- | ----- | ----- | | [Bayang RX](/using-the-module/protocol-details/bayang-rx) | 59 | RX | | | | | | [Flysky AFHDS2A RX](/using-the-module/protocol-details/flysky-afhds-2a-rx) | 56 | RX | | | | | | [FrSkyX RX](/using-the-module/protocol-details/frsky-rx) | 55 | RX | CloneTX | | | | | [DSM RX](/using-the-module/protocol-details/dsm-rx) | 70 | RX | | | | | {% hint style="info" %} For more information about using Receiver Protocols, see the Wireless Trainer page. {% endhint %} {% content-ref url="/pages/-LxLIKwcjZhLeU-YFKbM" %} [Wireless Trainer](/using-the-module/wireless-trainer) {% endcontent-ref %} # Where to Buy The MULTI-Module project has no affiliation with any particular manufacturer, re-seller, or retailer. MULTI-Modules can be purchased from many RC equipment retailers. The [forum on RC Groups](https://www.rcgroups.com/forums/showthread.php?2165676-DIY-Multiprotocol-TX-Module) is a good place to ask other other people for their recommendations, as they have first-hand experience with a range of online or local retailers. If you cannot find a local vendor, [Banggood ](https://www.banggood.com/search/cyrf6936-cc2500-a7105-nrf24l01.html)carries a number of different MULTI-Modules at reasonable prices, as do several sellers on [Aliexpress](https://www.aliexpress.com/wholesale?SearchText=cyrf6936+cc2500+a7105+nrf24l01). # Getting Started ## Install the Module **Step 1:** Make sure the radio is turned off. **Step 2:** Insert the MULTI-Module into the module bay of your radio, taking care that the pins line up correctly. ![JP4IN1-SE installed in a T16](/files/-LxlKty33fo8CmnaynRJ) ## Configure a Model Once the MULTI-Module is installed in the radio you need to configure a model to use it. Serial Mode and PPM Mode are configured differently. ### Serial Mode In Serial Mode the radio's user interface is used to select the protocol and configure any protocol settings. {% hint style="success" %} If your MULTI-Module has a 16-position rotary selector, ensure the module is in Serial Mode by setting the selector is set to **0**. {% endhint %} ![JP4IN1 set to Serial Mode](/files/-Lxm4YN6YHYkBLeTz_Ei) **Step 1:** Set the rotary switch to **0** and turn the radio on . **Step 2:** Select an existing model or create a new one. **Step 3:** On the Model Setup page scroll to **External RF** (or **Internal RF**, if using an internal MULTI-Module) and set the **Mode** to **MULTI**. ![External RF Mode set to MULTI](/files/-LxlLRODQMzEnzDRRYjk) {% hint style="info" %} The **Module Status** line should update to show the module's firmware version within a few seconds of the Mode being set to MULTI. If it doesn't, check that the module is installed correctly. {% endhint %} **Step 4:** Select a protocol by clicking on the field to the right of 'MULTI' ('FlySky' in the image above) and scrolling through the list to find the desired protocol. **Step 5:** Select the sub-protocol, if needed, by clicking on the sub-protocol field ('Std' in the image above) and scrolling through the options. Not all protocols have sub-protocols. **Step 6:** Configure the additional protocol settings, as needed. * **RF Freq. Tuning** specifies the frequency fine tuning value * **Receiver No.** enables Receiver Match * **Bind on Channel** enables initiating bind use a channel input and disables bind at power on * **Disable Telemetry** disables telemetry for this model * **Disable Ch. map** prevents the MULTI-Module re-mapping channels to match the protocol * **Low power mode** reduces the RF output to approximately 1/10th normal power All the protocol options are explained in the next section, Protocol Options, with more information in each protocol-specific page. Frequency Tuning is explained on the [Frequency Tuning page](/using-the-module/frequency-tuning). {% hint style="danger" %} If **RF Freq. Tuning** is an available setting, the [Frequency Tuning](/using-the-module/frequency-tuning) process **must** be completed for this protocol. {% endhint %} **Step 7:** Bind the MULTI-Module to the model. See the Binding page for more information. {% content-ref url="/pages/-Lx2Jm01XBMvjxKbb8PN" %} [Binding](/using-the-module/binding) {% endcontent-ref %} ### PPM Mode In PPM Mode the 16-position rotary selector is used to select the protocol. {% hint style="danger" %} The radio must be off when the protocol is selected or changed. {% endhint %} **Step 1:** With the radio off, select the desired protocol by setting the 16-position selector to the corresponding value. {% hint style="info" %} If protocol banks are enabled, the desired bank must also be selected. See the[ PPM Mode page](/using-the-module/ppm-mode#protocol-bank-selection) for more details. {% endhint %} **Step 2:** Turn the radio on. **Step 3:** Select an existing model or create a new one. **Step 4:** On the Model Setup page scroll to **External RF** and set the **Mode** to **PPM**. ![External RF set to PPM Mode](/files/-Lxm7Ag5vkW4Gfp-K9oC) **Step 5:** Bind the MULTI-Module to the model. See the Binding page for more information. {% content-ref url="/pages/-Lx2Jm01XBMvjxKbb8PN" %} [Binding](/using-the-module/binding) {% endcontent-ref %} # Protocol Options Different protocols support different features. The details page of each protocol gives information specific to that protocol and its sub-protocols, including supported features, channel assignments, and any extra information. Below are brief explanations of the features which protocols may have. ## Protocol Features ### Autobind Auto-bind protocols bind automatically when the radio and receiver (or model) are powered on. In OpenTX, enabling the **Bind on Channel** option in Model Setup disables binding at power-on, and instead requires an input to be configured to initiate binding. {% hint style="info" %} See the [Binding page](/using-the-module/binding) for more information about auto bind protocols and Bind on Channel. {% endhint %} ### Channel Re-mapping Channel re-mapping automatically re-maps channels to the order required by the protocol - it assumes that the order specified in the Mixer or Outputs matches the expected channel order of the MULTI-Module. Channel re-mapping is enabled by default for protocols which support it. {% hint style="info" %} As of MULTI-Module firmware v1.3.0.45 and OpenTX 2.3.3, channel re-mapping can be disabled for a model by checking the **Disable Ch. Map** box in Model Setup. {% endhint %} {% hint style="warning" %} Unless channel re-mapping is disabled in Model Setup, the channel order on the radio **must** match the expected channel order of the MULTI-Module (AETR, by default). {% endhint %} See the Channel Order page for more details. {% content-ref url="/pages/-Lwo96pS37IT3R-TtU7R" %} [Channel Order](/using-the-module/channel-order) {% endcontent-ref %} ### Extended Limits With normal limits, the range of all outputs is -100% to +100%. Enabling Extended Limits increases this range to -150% to +150%. ![Extended Limits Enabled](/files/-MFeMyZDDbiFTtx0r8la) ![CH3 Extended to -125% to +125%](/files/-MFeN538nhn5hIbCOeha) ### Failsafe Failsafe settings determine what the receiver will do if radio communication is lost. The receiver is configured using settings sent from the radio as part of the radio transmission. Configuring failsafe settings ensures that the receiver behaves in an expected way if radio communications between the radio and receiver are lost, for example by reducing throttle to -100%, or activating a return-to-home (RTH or RTL) function in the flight controller. {% hint style="danger" %} When configuring and testing failsafe, do so with the propellers removed, in case the motor(s) inadvertently start. {% endhint %} Protocols which support failsafe: * [AFHDS 2A](/using-the-module/protocol-details/flysky-afhds2a) * [Devo](/using-the-module/protocol-details/devo) * [FrSkyX (D16)](/using-the-module/protocol-details/frsky-x) * [Hisky HK310](/using-the-module/protocol-details/hisky) * [Hott](/using-the-module/protocol-details/hott) * [SFHSS](/using-the-module/protocol-details/sfhss) * [WK2x01](/using-the-module/protocol-details/wk2x01) | Failsafe Mode | Receiver Behaviour | | ------------- | ---------------------------------------------------------------------------------------- | | **Not Set** | Failsafe not configured. | | **Hold** | Hold the last values received before radio communication was lost. | | **Custom** | Use the radio to configure specific values for the receiver to use. | | **No Pulses** | All channels go to their minimum values. | | **Receiver** | Use values configured on the receiver using the receiver's configured failsafe settings. | {% hint style="info" %} OpenTX will warn if the failsafe option has not been selected for a protocol which supports it. {% endhint %} ### Receiver Match If a protocol supports Receiver Match, it is enabled by specifying a unique Receiver Number (RX Num) for each model in the Model Setup page, before binding the receiver. If the Receiver Number is changed the receiver will need to be re-bound to the radio. Receiver Match can be disabled by assigning the same Receiver Number to all models. Receiver Number 0 is typically used for this purpose. See the Receiver Match page for more information. {% content-ref url="/pages/-LxBf-VD8YQds7-7yIl0" %} [Receiver Match](/using-the-module/receiver-match) {% endcontent-ref %} ### Telemetry Telemetry enables the model or receiver to send information back to the radio,. Common uses are sending signal strength (RSSI) or flight battery voltage data so that it can be displayed on the radio. {% hint style="info" %} Telemetry information is dependent on the protocol, model, receiver, or flight controller, and even if the protocol supports telemetry, the model may not be capable of sending it. {% endhint %} Telemetry is also used to send information about the MULTI-Module (such as firmware version and channel order) to the radio. All MULTI-Module telemetry, including sending module version and channel order information to the radio, can be disabled by checking the **Disable Telemetry** box in **Model Setup**. {% hint style="warning" %} Do not check the **Disable Telemetry** box in **Model Setup** to eliminate telemetry warnings when using DSM receivers with short-range 'fly-by' telemetry. Check **Disable telemetry alarms** on the **Telemetry** page instead. {% endhint %} The **Disable Telemetry** setting is intended for use in FrSky radios where it is necessary to disable MULTI-Module telemetry from an external MULTI-Module in order to allow telemetry from the internal module. ### Option Value The Option Value may be used differently by each protocol. The use of Option Value is documented in each protocol's details page. {% hint style="info" %} For a protocol where Option Value has defined use, OpenTX will typically display it as a named field, such as **RF Fine Tuning**. {% endhint %} ### Low Power Mode Low Power Mode reduces the transmission output power of the MULTI-Module to approximately 1/10th of normal output. It can be useful for: * Short-range testing (the power output is similar to the **Range Test** option) * Operating in an environment where reduced RF output is needed * Operating 'toy grade' models which normally use a low power transmitter and do not cope well with full power signals {% hint style="danger" %} Low Power Mode significantly reduces the range of the MULTI-Module {% endhint %} {% hint style="info" %} OpenTX will warn when a model is selected which has Low Power Mode enabled. {% endhint %} # Binding The process of connecting the radio and MULTI-Module to a receiver or model is called 'binding'. The binding process varies between protocols, but there are generally two types: * **Auto Binding Protocols** are protocols which bind every time the receiver and radio are powered on. These protocols are typically used on smaller 'toy' models. * **Manual Binding Protocols** are protocols which require binding once, typically with a button pressed or jumper installed on the receiver to put it in bind mode. The bind is then stored in the radio and the receiver. These protocols are typically used on hobby-grade receivers and models. {% hint style="info" %} Check the [Protocol Details](/using-the-module/protocol-details) page for the protocol you are trying to bind for information and any extra notes or hints relating to binding. {% endhint %} ## Auto Binding Protocols Auto binding protocols will normally bind as soon as the radio and receiver (or model) are turned on or, if the radio is already on, when a model using an auto-binding protocol is selected. {% hint style="warning" %} For safety, **Bind on Channel** is strongly recommend for auto-bind protocols. {% endhint %} ### Binding at Power On By default models configured with auto-binding protocols will attempt to bind either at radio power-on (assuming the last-selected model used an auto-bind protocol), or as soon as the model is selected. For the radio to initiate binding at power-on or model selection, **Bind on Channel** must be disabled in Model Setup. ![Bind on Channel Disabled](/files/-Lx2khGUqLHGFJUHqFkv) To bind the radio and model: **Step 1:** Connect the model's battery **Step 2:** Switch on the radio or select the model {% hint style="info" %} Subsequent binds, for example after changing the model's battery, can be initiated by switching the radio off then on, or using the **Bind** action in the Model Setup menu. {% endhint %} ### Bind on Channel The easiest and safest way to use an auto-binding protocol is to use the **Bind on Channel** feature of the MULTI-Module. {% hint style="info" %} With **Bind on Channel** enabled the radio will not automatically bind at power on or model selection, and binding must be manually initiated. {% endhint %} Using Bind on Channel, the MULTI-Module will initiate a bind if channel 16 goes from -100% to +100%. The recommended way to do this is to configure a logical switch. This is to ensure that binding is only initiated if the throttle is at -100%. {% hint style="info" %} The default bind channel is **CH16**, but this can be changed to any channel between 5 and 16 by compiling your own MULTI-Module firmware. {% endhint %} ### Configuring Bind on Channel **Step 1**: In the RF setup of the **Model Setup** page, enable **Bind on channel** by checking the box. ![Enable 'Bind on channel' in Model Setup](/files/-Lx2fodxsSluxCyyNr0O) **Step 2:** Configure a logical switch which requires the throttle to be -100% while the momentary switch (SH in this example) is activated, optionally with a brief delay so that the momentary switch has to be held on for the bind to occur. ![Bind on Channel Logical Switch with 0.5s Delay](/files/-Lx2TnntRNAAQfnpbYum) **Step 3**: Assign the logical switch to CH16 in the mixer. ![Logical Switch assigned to CH16](/files/-Ly36Z-R1bjV4D1Bc4NE) You can now bind your model by activating the momentary switch for at least 0.5s while the throttle is at -100%. ## Manual Binding Protocols {% hint style="success" %} To bind your MULTI-Module to a manual-bind' receiver you should follow the receiver manufacturer's instructions, but be sure to also check the [Protocol Details page](/using-the-module/protocol-details). {% endhint %} The process will vary from receiver to receiver, but will typically be similar to this: 1. Power on the radio 2. Hold down the receiver's bind button, or place the bind jumper on the receiver 3. Connect power to the receiver 4. Initiate binding on the radio * Serial Mode - Use the **Bind** action in the Model Setup menu on the radio * PPM Mode - press the bind button on the module Once bound, the receiver and radio will re-establish a connection as soon as both are powered on (and the model is selected). If the receiver does not bind, and the **RF Freq. fine tune** option is available for the protocol, change the **RF Freq. fine tune** value to either **-40** or **40** and try to bind again. If binding is still unsuccessful, continue to try higher and lower values in steps of plus or minus 40 until the bind succeeds. ![RF Freq. fine tune set to 40](/files/-Lx5qyxilQ5-5k5fomnk) {% hint style="info" %} Refer to the Frequency Tuning documentation for more information about fine tuning, and to complete the Fine Tuning procedure. {% endhint %} {% content-ref url="/pages/-Lwo9As8U5JlITxw7hYk" %} [Frequency Tuning](/using-the-module/frequency-tuning) {% endcontent-ref %} {% hint style="success" %} If desired, binding for manual-binding protocols can also be initiated using '[Bind on Channel](/using-the-module/binding#bind-on-channel)'. {% endhint %} # Channel Order Many protocols, especially auto-binding Bind-n-Fly (BNF) protocols for small toys, require inputs on specific channels. For convenience, and to support older radios which cannot change their output channel order, the MULTI-Module will automatically re-map channels 1-4 into the order required by the protocol, provided the channel order configured in the radio's mixer or outputs matches the MULTI-Module's Expected Channel Order. This allows you to configure your all models using your preferred channel order, without having to worry about the actual channel order required by the model or protocol. {% hint style="success" %} The channel order required for each protocol and sub-protocol is shown in each protocol's details page. {% endhint %} {% hint style="danger" %} Channel order is particularly important for **DSM** receivers, which require channels in **TAER** order. If you use DSM, continue reading to learn how to correctly configure your model. {% endhint %} ## Expected Channel Order In order for channel re-mapping to work, the MULTI-Module must receive channel data in a known order. This is the Expected Channel Order. The Expected Channel Order is set in the MULTI-Module firmware when it is compiled. {% hint style="info" %} The default MULTI-Module Expected Channel Order is **AETR**. {% endhint %} With OpenTX v2.3.4 or newer, and MULTI-Module firmware v1.3.0.45 or newer, the MULTI-Module's Expected Channel Order is displayed on the **Module Status** line in the Model Setup screen. ![Module Status showing Channel Order](/files/-LxjwliC9eqUtWpR1L14) {% hint style="info" %} You should update your MULTI-Module's firmware if the Expected Channel Order is not displayed in the Module Status line. Updating the firmware will ensure that you know the Expected Channel Order. {% endhint %} When configuring a model, the channel order in the Mixer should be the same as the Expected Channel Order. ![Mixer with inputs assigned in AETR order](/files/-LxjsepTV7UO06OwUCTU) When the MULTI-Module transmits to the example model configured above, configured for **AETR** using the **DSM** protocol, the module will re-map the channels to **TAER** order prior to transmission. ### Channel Re-Mapping Examples #### Example 1 * The MULTI-Module is using the default Expected Channel Order **AETR** * The protocol is **DSM**, which requires channel data in **TAER** order at the receiver * The model is configured in the radio with channels in **AETR** order in the mixer/outputs * Servos and motors are plugged into the labelled outputs on the receiver, in **TAER** order In this case the MULTI-Module re-maps the channels before transmission, the receiver receives **TAER**, and everything works as expected: | Radio CH | Radio Mixer | Module Re-mapping | Receiver Receives | | -------- | ----------- | ----------------- | ----------------- | | 1 | Aileron | 1 -> 2 | Throttle | | 2 | Elevator | 2 -> 3 | Aileron | | 3 | Throttle | 3 -> 1 | Elevator | | 4 | Rud | 4 -> 4 | Rudder | #### Example 2 * The MULTI-Module has been updated to use the Expected Channel Order **TAER** * The protocol is **DSM**, which requires channel data in **TAER** order at the receiver * The model is configured in the radio with channels in **TAER** order in the mixer/outputs * Servos and motors are plugged into the labelled outputs on the receiver, in **TAER** order In this case the MULTI-Module does not need to perform channel re-mapping and everything works as expected: | Radio CH | Radio Mixer | Module Re-mapping | Receiver Receives | | -------- | ----------- | ----------------- | ----------------- | | 1 | Throttle | 1 -> 1 | Throttle | | 2 | Aileron | 2 -> 2 | Aileron | | 3 | Elevator | 3 -> 3 | Elevator | | 4 | Rudder | 4 -> 4 | Rudder | #### Example 3 * The MULTI-Module is using the default Expected Channel Order **AETR** * The protocol is **DSM**, which requires channel data in **TAER** order at the receiver * The model is configured in the radio with channels in **TAER** order in the mixer/outputs * Servos and motors are plugged into the labelled outputs on the receiver, in **TAER** order In this case the MULTI-Module re-maps the channels, but because the input order is not as expected, the output order is incorrect and the model does not work: | Radio CH | Radio Mixer | Module Re-mapping | Receiver Receives | | -------- | ----------- | ----------------- | ----------------- | | 1 | Throttle | 1 -> 2 | Elevator | | 2 | Aileron | 2 -> 3 | Throttle | | 3 | Elevator | 3 -> 1 | Aileron | | 4 | Rudder | 4 -> 4 | Rudder | {% hint style="danger" %} **Mismatching the radio channel order and the MULTI-Module's Expected Channel Order can have potentially disastrous or dangerous consequences!** {% endhint %} The scenario in Example 3 can be avoided by: * Changing the model's channel order in the mixer/outputs to match the MULTI-Module's Expected Channel Order * Changing the MULTI-Module's firmware to expect TAER instead of AETR * Disabling Channel Re-Mapping in Model Setup ## Changing the Expected Channel Order If you prefer to configure your models with a different channel order, you can change the Expected Channel Order by flashing different firmware to your MULTI-Module. You can compile your own firmware, or download a firmware image with a different Expected Channel Order from the [GitHub releases page](https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/releases). {% hint style="info" %} MULTI-Module firmware downloads are available for **AETR**, **TAER**, and **RETA** channel orders, see the [Firmware Files page](/using-the-module/firmware-updates/firmware-files#channel-order). {% endhint %} ## Changing the Radio's Default Channel Order Once you have settled on a preferred channel order, and flashed your MULTI-Module with firmware which expects that order, you should: 1. Change the **Default channel order** setting on your radio to match the MULTI-Module's expected order 2. Ensure that any models which you control with the MULTI-Module are configured with the channel order which the MULTI-Module expects ![Radio Default Channel Order set to AETR](/files/-LxNDFwNmR8cc2JEhkEg) {% hint style="warning" %} Changing the radio's **Default channel order** only affects new models - you must manually edit any existing models. {% endhint %} {% hint style="danger" %} The **Mode** setting reflects the hardware setup of the radio's sticks. Do not change the **Mode** unless you physically change the sticks, e.g. switching the throttle from the left to the right stick. {% endhint %} ## Disabling Channel Re-Mapping As of MULTI-Module firmware v1.3.0.45 and OpenTX 2.3.3, channel re-mapping can be disabled for a model by checking the **Disable Ch. map** box in Model Setup. You can disable channel re-mapping If you prefer to configure the channel order yourself, or if channel re-mapping is causing problems due to a mismatch between the order in the model and the MULTI-Module's expected channel order. ![Channel Mapping Disabled](/files/-LxNDzlNVntO5ThXMria) When channel re-mapping is disabled the channel data will be transmitted to the receiver in the exact order it is configured in the radio's mixer or outputs. # Channel Naming The **MULTI Channel Namer** LUA script can be used to automatically name the channels of any model which is configured with a MULTI-Module protocol. The script uses the configured protocol, a database containing the channel assignments for each protocol, and the module's configured [Expected Channel Order](/using-the-module/channel-order#expected-channel-order) to name all the channels according to their specified use. The script makes it extremely easy to assign the correct inputs to each channel by matching inputs to the named outputs. {% hint style="success" %} The **MULTI Channel Namer** script is included in OpenTX 2.3.8. OpenTX 2.3.8 or newer is required to use the script. {% endhint %} ## Using the Script 1\. Select or configure a model which uses a MULTI-Module protocol\ 2\. Ensure that the correct MULTI-Module protocols is selected in the model ![Model configured with the MJXq / E010 protocol](/files/-MBQBjHgyEW09dtsXQ2d) 3\. Press the **SYS** button\ 4\. From the **Tools** menu, launch the **Multi chan namer** script ![Multi Chan Namer Script](/files/-MBQCHnjGBm4zHsLRv4M) 5\. Check that the output looks sane ![E010 Channel Names](/files/-MBQCSljhjAkLVcMb78d) 6\. Press **Enter** to save the channel names In the Outputs screen the channels will now be named according to their designated use: ![E010 Named Channels](/files/-MBQCmywtPZwIXXX_Jnw) ## Script Updates {% hint style="success" %} The latest version of the Multi Channel Namer script can be download from . {% endhint %} 1. Download the **MultiLuaScripts.zip** file from the latest release 2. Unzip the file 3. Connect your radio or SD card to your computer 4. Copy **MultiChannelsUpdate.lua** and **MultiChan.txt** to the **TOOLS\SCRIPTS** folder on the radio's SD card (replace the existing files with the same names) ## Video You can see a demonstration of the script in this video: {% embed url="" %} # Frequency Tuning Certain protocols require tuning for optimal performance. In some cases tuning is required in order for the protocol to bind. Frequency Tuning is specific to each MULTI-Module, and is due to very small variations in the RF components. {% hint style="info" %} Frequency Tuning typically only needs to be performed once per protocol, as there is usually only a small variance between the values found for multiple receivers of the same type. Once known, the same value can usually be used for all receivers which use the protocol. {% endhint %} Protocols which require frequency tuning are: * **FrSkyD** (e.g. FrSky D4R and D8R, DIY RX-F801 and RX-F802 receivers) * **FrSkyV** (e.g. FrSky V8R4, V8R7 and V8FR receivers) * **FrSkyX** (e.g. FrSky X4R, X6R, X8R, XM+ and XSR receivers) * **S-FHSS** (e.g. Futaba S-FHSS receivers) * **Corona** (e.g. Corona V1 FSS, Corona V2 DSSS CR8D/CR6D/CR4D and FlyDream IS-4R/IS-4R0 receivers) * **Hitec** (e.g. Optima, Minima, Micro and RED receivers) * **HoTT** (e.g. Graupner receivers) * Any protocol which can use the CC2500 RF module to emulate XN297. This will be noted on the protocol details page, e.g [E010](/using-the-module/protocol-details/mjxq#4-e010), [V911S](/using-the-module/protocol-details/v911s#0-v-911-s), and others. {% hint style="success" %} The general rules is that if the **RF Freq. fine tune** option appears in the protocol menu, frequency tuning is required and should be performed. {% endhint %} ![RF Freq. fine tune option](/files/-MMCCUm6sifuvaYLbGJA) Frequency Tuning is always recommended, but especially when: * It is difficult to bind to the receiver, or the connection is weak or intermittent * Control range is very short * Telemetry data is not received or (for telemetry-enabled receivers only) {% hint style="success" %} Completing the Frequency Tuning Procedure ensures that the radio and receiver will have the strongest possible connection. {% endhint %} {% hint style="warning" %} If you change the frequency tuning value it is best to re-bind the receiver(s). {% endhint %} ## Frequency Tuning Procedure The procedure can be performed in serial or PPM mode. It is easier in serial mode because the effect can be observed in real-time. {% hint style="warning" %} For best results, the fine-tuning procedure should be carried out with a genuine FrSky, Futaba, Corona, Hitec, or HoTT receiver. {% endhint %} ### Preparation If the receiver does not bind, and the **RF Freq. fine tune** option is available for the protocol, change the **RF Freq. fine tune** value to either **-40** or **40** and try to bind again. If binding is still unsuccessful, continue to try higher and lower values in steps of plus or minus 40 until the bind succeeds. ![RF Freq. fine tune](/files/-MMCCUm6sifuvaYLbGJA) {% hint style="success" %} Make sure you try the whole range of **RF Freq. fine tune** values, **-127** to **+127**. {% endhint %} See the [Binding](/using-the-module/binding) documentation page for more details instructions on completing the bind process. Once the receiver is bound you can proceed with Fine Tuning. ### Serial Mode Fine Tuning {% hint style="info" %} If you have telemetry configured and a voice-capable radio, you can enable a voice alarm for telemetry loss so that you receive an immediate alert when the receiver connection is lost. {% endhint %} With the radio is bound to the receiver: 1. Return to the **RF Freq. fine tune** option 2. Lower the value until the radio loses the connection with the receiver. Record the value (`TUNE_MIN`). 3. Raise the value so that the connection is restored, then continue to raise it until the radio loses the connection with the receiver again. Record the value (`TUNE_MAX`). 4. Calculate the median between the two values `(TUNE_MIN + TUNE_MAX) / 2 = TUNE_MEDIAN` 5. Set **RF Freq. fine tune** to the median value **Example** Connection is lost at -73 and +35; the median is -19: $$ (-73 + 35) \div 2 = -19 $$ Once the Fine Tuning value is known, it can be used for all models which use the same protocol. {% hint style="success" %} If you compile your own firmware build you can set the Fine Tuning value in the firmware, removing the need to configure it on each model. {% endhint %} ### PPM Mode Fine Tuning Fine Tuning in PPM Mode requires configuring multiple switch positions with the same protocol, but with different fine tuning values, then compiling and uploading the firmware and testing each value. The compile-upload-test process will need to be repeated several times to get an accurate fine tuning value. You will need to be familiar with configuring and compiling the MULTI-Module source code. See the Compiling the Firmware page for more information. {% content-ref url="/pages/-Lwo9ctmColHToxvGRef" %} [Compiling the Firmware](/advanced-topics/compiling-the-firmware) {% endcontent-ref %} ## Advanced Users Users who compile their own MULTI-Module firmware can specify pre-set frequency fine tuning values in the firmware, so that they automatically apply to a given protocol. When configuring the firmware source, locate and edit this section in \_Config.h: ``` /*******************************/ /*** CC2500 FREQUENCY TUNING ***/ /*******************************/ //For optimal performance the CC2500 RF module used by the FrSkyD, FrSkyV, FrSkyX, SFHSS, CORONA and Hitec protocols needs to be tuned for each protocol. //Initial tuning should be done via the radio menu with a genuine FrSky/Futaba/CORONA/Hitec receiver. //Once a good tuning value is found it can be set here and will override the radio's 'option' setting for all existing and new models which use that protocol. //Valid range is -127 to +127 //Uncomment the lines below (remove the "//") and set an appropriate value (replace the "0") to enable. //#define FORCE_FRSKYD_TUNING 0 //#define FORCE_FRSKYV_TUNING 0 //#define FORCE_FRSKYX_TUNING 0 //#define FORCE_SFHSS_TUNING 0 //#define FORCE_CORONA_TUNING 0 //#define FORCE_HITEC_TUNING 0 //#define FORCE_HOTT_TUNING 0 ``` {% hint style="info" %} If a fine tuning value is set in the firmware, the **RF Freq. tuning** value from the radio is ignored. {% endhint %} # Radio Cloning The MULTI-Module can be used to clone (copy) the unique identifier of a radio transmitting one of the supported FrSky protocols. Cloning a radio allows the MULTI-Module to communicate with any receiver which was bound to the original radio without having to re-bind the receivers. There are three memory 'slots' available for cloning: * 1 slot for D8 cloning * 1 slot for FrSkyX (D16v1) cloning * 1 slot for FrSkyX2 (D16v2.1.0) cloning {% hint style="info" %} The same transmitter or different transmitters can be cloned into each slot, but only one transmitter ID is stored per slot. {% endhint %} If you use the Cloning Procedure with a radio transmitting the D8 protocol, it will be saved in the D8 slot. Likewise for D16v1 and D16v2.1 . Once a transmitter ID is cloned you can use the cloned ID for any model by using the FrSkyD/X/X2 'Cloned' sub-protocol option. This way you can have models working with the original MULTI-Module identifier and models which are shared by both the cloned TX and MPM. {% hint style="success" %} OpenTX 2.3.8 or later is required to use cloned transmitter IDs with the MULTI-Module. {% endhint %} ### Cloning Procedure 1. On the radio to receive the cloned ID, configure a new model with the **FrSky RX** protocol, sub-protocol **CloneTX** 2. On the radio to be cloned, select (or configure) a model which uses the protocol you want to clone the ID from (FrSkyD/D8, FrSkyX/D16, etc.) 3. Place both radios in Bind mode 4. Wait for the bind to complete #### Using the Cloned ID 1. Select or create a model where you want to use the cloned ID 2. Select the protocol which was cloned (FrSkyD/D8, FrSkyX/D16, etc.) 3. Select the sub-protocol **Cloned** #### Notes: * **FrSkyD/D8** - the Receiver Number which was used during the the cloning procedure is used. Changing the Receiver Number has no effect * **FrSkyX/D16** - the Receiver Number must be set to match the value on the original transmitter ### Video {% embed url="" %} Radio Cloning Video by Painless360 {% endembed %} # Receiver Match Receiver Match enables multiple models or receivers which use the same protocol to be bound to the radio using unique radio models, and prevents accidentally operating the wrong model. For example, if you have several aircraft which have the same type of receiver, and each aircraft has a different model configured in the radio, you can ensure that a given aircraft will only be controlled by the matching radio model by configuring Receiver Match. ## Enabling Receiver Match Receiver Match is configured by specifying a unique **Receiver Number** (RX Num) for each model in the Model Setup page, before binding the receiver. If the Receiver Number is changed the receiver will need to be re-bound to the radio. {% hint style="success" %} Up to 64 different receiver numbers (0 to 63) are supported when using Receiver Match. {% endhint %} {% hint style="info" %} OpenTX will automatically assign an unused Receiver Number to a new model when the model is created. {% endhint %} ## Disabling Receiver Match Receiver Match can be disabled by assigning the same Receiver Number to all models. {% hint style="info" %} To avoid warnings in OpenTX Companion, use Receiver Number **0** for models where Receiver Match is not required. {% endhint %} # Spectrum Analyzer A radio running EdgeTX or OpenTX 2.3.0 or higher can use an internal or external MULTI-Module as a 2.4GHz spectrum analyzer. The spectrum analyzer will show the strength of signals in the 2.4GHz band. ![2.4GHz Spectrum Analyzer](/files/-MGYcaGktfOUxhTtnthw) ### Using the Spectrum Analyzer 1. Long-press the **SYS** button to access the **TOOLS** menu 2. Scroll down and highlight the appropriate **Spectrum** option in the menu 1. Choose **Spectrum (INT)** for radios with an internal MULTI-module 2. Choose **Spectrum (EXT)** for radios with an external MULTI-Module 3. Press **ENT** to start the Spectrum Analyzer ![Spectrum Analyzer in the TOOLS Menu](/files/-MGYcgClUJIv8kwPs22S) {% hint style="success" %} **Spectrum (EXT)** only appears in the menu if a model which uses the external MULTI-Module is selected. {% endhint %} {% hint style="warning" %} A bug in OpenTX 2.3.9 and earlier prevents the spectrum analyzer from starting when a recently-added MULTI-Module protocol (e.g. FrSkyX2) is configured in the currently-selected model. As a workaround, select a model which uses an older protocol (e.g. DSM, FrSky, or Flysky) before starting the spectrum analyzer. {% endhint %} ### Spectrum Analyzer Display ![Spectrum Analyzer Display](/files/-MGYcaGktfOUxhTtnthw) The display shows frequencies on the 2.4GHz spectrum, from 2400MHz to 2480MHz. The X (horizontal) axis shows the frequency in MHz and the Y (vertical) axis shows relative signal strength. **F:** Frequency at the center of the plot (fixed at 2440MHz)\ **S:** Bandwidth of the plot (fixed at 80MHz)\ **T:** Position of the cursor (vertical line) Pressing **ENT** and scrolling left and right allows the **T** value to be changed, which will move the vertical line to highlight a specific frequency. {% hint style="info" %} In a future firmware release the **F** and **S** values will be adjustable, allowing the analyzer to be focused on a particular part of the spectrum. {% endhint %} # Wireless Trainer Wireless Trainer allows a radio with two modules - at least one being a MULTI-Module - to be used as a trainer, without the need for a wired connection to the student radio. On the Trainer radio, the MULTI-Module is configured with a receiver protocol and the other module (which may also be a MULTI-Module) is bound to the model, and the Student radio is bound to the Trainer's MULTI-Module. {% hint style="info" %} For a list of protocols supported for Wireless Trainer, see the Receiver Protocols section of the Supported Protocols page. {% endhint %} {% hint style="warning" %} Wireless Trainer cannot be used on current FrSky radios due to a hardware limitation - they do not allow telemetry on the external module while the internal module is in use. {% endhint %} {% content-ref url="/pages/-Lwr-pqDAO67lah36rf0" %} [Supported Protocols](/basics/supported-protocols) {% endcontent-ref %} ## Trainer Radio Setup Configuring a full student/trainer setup is beyond the scope of this documentation. You should be familiar with general trainer configuration before attempting to configure wireless trainer. **Step 1:** In Model Setup set the **Trainer Mode** to **Master/Multi** ![Trainer Mode Set to Master/Multi](/files/-Ly66XpOcqZm-cMCCLLY) **Step 2:** Configure your MULTI-Module with one of the Receiver Protocols ![FrSkyRX Protocol Selected](/files/-Ly67j3Mmh6QHj69qK6n) {% hint style="success" %} Telemetry must be enabled on the Trainer Radio. Wireless Trainer will not work if **Disable Telemetry** is checked. {% endhint %} ## Student Radio Setup **Step 1:** Configure your radio to use the TX version of the Receiver Protocol which was configured on the Trainer Radio. ![FrSky TX Protocol Selected](/files/-Ly69HGor2SflBJDWAI_) ## Binding Once the models are configured on both radios, they need to bind. Binding is logically the same as any transmitter/receiver combination. {% hint style="success" %} Any other RF modules should be disabled when binding the trainer and student radios. {% endhint %} **Step 1:** On the Trainer Radio, initiate binding on the RF module which is configured with the Receiver Protocol **Step 2:** Initiate binding on the Student Radio # PPM Mode Supporting PPM Mode enables the MULTI-Module to work in a wide range of radios. {% hint style="warning" %} Due to the more complex nature of configuring and using PPM Mode, it should only be used if the radio does not support Serial Mode. {% endhint %} In PPM Mode the protocol is selected using the 16-position rotary selector on the MULTI-Module. The MULTI-Module supports up to five different 'banks' of protocols but by default only one bank is configured. To take full advantage of the MULTI-Module in a PPM Mode radio the firmware should be compiled from source, with the protocol banks configured to include the desired protocol options. ![JP4IN1 Module with Rotary Selector and Bind Button](/files/-Lxm4YN6YHYkBLeTz_Ei) {% hint style="info" %} A MULTI-Module with a 16-position rotary selector and a bind button is required to use PPM mode. {% endhint %} ## Default Protocol Table Switch position 0 is reserved for enabling Serial Mode, and position 15 is reserved for switching to alternate protocol banks, leaving fourteen positions (1-14) available for protocols. By utilizing all five banks, up to 70 different protocol combinations can be configured. The default protocol assignments for the standard MULTI-Module firmware are shown below. {% hint style="warning" %} MULTI-Module manufacturers often ship modules with a different set of PPM protocols. If you are using the manufacturer's firmware you should consult the documentation which came with your module. {% endhint %} | Position | Protocol | Sub Protocol | RX Number | Autobind | Option Value | | -------- | --------------- | ------------ | --------- | -------- | ------------ | | 1 | FlySky | FlySky | 0 | No | 0 | | 2 | FlySky AFHDS 2A | PWM IBUS | 0 | No | 0 | | 3 | FlySky AFHDS 2A | PWM IBUS | 1 | No | 0 | | 4 | FlySky AFHDS 2A | PWM IBUS | 2 | No | 0 | | 5 | FlySky AFHDS 2A | PWM IBUS | 3 | No | 0 | | 6 | FlySky AFHDS 2A | PWM IBUS | 2 | No | 0 | | 7 | FlySky AFHDS 2A | PWM IBUS | 3 | No | 0 | | 8 | SFHSS | H107 | 0 | No | 0 | | 9 | FrSky V | | 0 | No | 40 | | 10 | FrSky D | | 0 | No | 40 | | 11 | FrSky X | D16 | 0 | No | 40 | | 12 | FrSky X | D16 EU (LBT) | 0 | No | 40 | | 13 | Devo | | 0 | No | 0 | | 14 | WK2x01 | WK2801 | 0 | No | 0 | ## Customizing the Protocols To modify the protocols, or to increase the number of banks, the MULTI-Module firmware must be compiled from source. More information about compiling the firmware is available on the Compiling the Firmware page. {% content-ref url="/pages/-Lwo9ctmColHToxvGRef" %} [Compiling the Firmware](/advanced-topics/compiling-the-firmware) {% endcontent-ref %} ## Protocol Bank Selection {% hint style="warning" %} Some manufacturers ship MULTI-Modules with modified firmware, with an alternate method for selecting Protocol Banks. The method described here will not apply to them until they are updated to the latest official MULTI-Module firmware. {% endhint %} To select a protocol bank (when multiple banks are enabled): **Step 1:** Turn the radio off. **Step 2:** Set the rotary selector to position 15. **Step 3:** Turn the radio on - the MULTI-Module indicates the current bank by flashing the LED one to five times. **Step 4:** Press the bind button - the red LED lights for one second to indicate that the bank has been changed. **Step 5:** Repeat Step 4 until you have reached the bank you want. **Step 6:** Turn the radio off. **Step 7:** Set the rotary selector to the desired position (1-14). **Step 8:** Turn the radio on. # Protocol Details # Assan ## Details **Protocol Number:** 24\ **Autobind:** No\ **Channel Re-mapping:** No\ **Extended Limits:** Yes\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes The radio must be close to the receiver when binding. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | --- | --- | --- | --- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | # Bayang ## Details **Protocol Number:** 14\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** Yes - with alternative model firmware\ **Option Value:** Model firmware selection ## Notes ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | ---- | --- | ------- | ----- | | A | E | T | R | Flip | RTH | Picture | Video | | CH9 | CH10 | CH11 | - | - | CH14 | CH15 | | -------- | -------- | ---- | - | - | ------------ | ------------ | | Headless | Inverted | Rate | - | - | Analog AUX 1 | Analog AUX 2 | **Rate:** -100% (default) =>higher rates by enabling dynamic trims (except for Headless), 100%=>disable dynamic trims **Channels 14 and 15:** Analog AUX 1 and 2 are only available with analog aux channel option, indicated below. ## Sub Protocols ### 0 - Bayang **Models:** Eachine H8(C) Mini, BayangToys X6/X7/X9, JJRC JJ850, Floureon H101, Syma X5 clones, ... | Option Value | Effect | | ------------ | ------------------------------------------------------ | | 0 | Normal Bayang protocol | | 1 | Enable telemetry for Silverxxx firmware | | 2 | Enable analog AUX channels for NFE Silverware firmware | | 3 | Enable Silverware telemetry and analog AUX channels | ### 1 - H8S3D **Models:** H8S 3D ### 2 - X16\_AH **Models:** X16 AH\ **Channels:** CH12 = Take Off ### 3 - IRDRONE **Models:** IrDrone\ **Channels:** CH12 = Take Off; CH13 = Emergency Stop ### 4 - DHD\_D4 **Models:** DHD D4\ **Channels:** CH12 = Take Off; CH13 = Emergency Stop ### 5 - QX100 **Models:** Revell QX100 # Bayang RX ## Details **Protocol Number:** 59\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** N/A\ **Option Value:** N/A ## Notes Uses the MULTI-Module as a Bayang receiver instead of a transmitter. Compatible with any radio transmitting a Bayang protocol. Enables two radios to be linked in a trainer/trainee partnership. See the Wireless Trainer page for more information. {% content-ref url="/pages/-LxLIKwcjZhLeU-YFKbM" %} [Wireless Trainer](/using-the-module/wireless-trainer) {% endcontent-ref %} ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | | --- | --- | --- | --- | ------------ | ------------ | ---- | --- | ------- | ----- | | A | E | T | R | Analog AUX 1 | Analog AUX 2 | Flip | RTH | Picture | Video | {% hint style="info" %} See the [Bayang protocol](/using-the-module/protocol-details/bayang) for information about activating the Analog AUX channels. {% endhint %} # Bugs ## Details **Protocol Number:** 41\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** Yes - RX & TX RSSI, battery voltage good/bad\ **Option Value:** N/A ## Notes **Models:** MJX Bugs 3, 6 and 8 {% hint style="warning" %} You **must** use a different **Receiver Number** for each Bugs model you bind. Re-using numbers will remove the binding for the previous model. {% endhint %} {% hint style="info" %} A maximum of 16 Bugs models can be bound to the MULTI-Module. {% endhint %} ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | | --- | --- | --- | --- | --- | ----- | ---- | ------- | ----- | ---- | | A | E | T | R | ARM | ANGLE | FLIP | PICTURE | VIDEO | LED | ANGLE: -100% = Acro mode; +100% = Angle mode # Bugs Mini ## Details **Protocol Number:** 42\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** Yes\ **Telemetry:** Yes - RX RSSI, battery voltage good/bad\ **Option Value:** N/A ## Notes **Models:** MJX Bugs 3 Mini and 3H {% hint style="warning" %} You **must** use a different **Receiver Number** for each Bugs Mini model you bind. Re-using numbers will remove the binding for the previous model. {% endhint %} {% hint style="info" %} A maximum of 16 Bugs Mini models can be bound to the MULTI-Module. {% endhint %} ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | | --- | --- | --- | --- | --- | ----- | ---- | ------- | ----- | ---- | | A | E | T | R | ARM | ANGLE | FLIP | PICTURE | VIDEO | LED | ANGLE: -100% = Acro mode; +100% = Angle mode ## Sub Protocols ### 0 - BUGSMINI **Models:** Bugs 3 Mini ### 1 - BUGS3H **Models:** Bugs 3H\ **Channels:** CH11 = Altitude Hold # Cabell ## Details **Protocol Number:** 34\ **Autobind:** No\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** Yes\ **Receiver Match:** No\ **Telemetry:** Yes (telemetry sub-protocol only)\ **Option Value:** N/A ## Notes Homegrown protocol with variable number of channels (4-16) and telemetry (RSSI, V1, V2). It is a FHSS protocol developed by Dennis Cabell (KE8FZX) using the NRF24L01+ 2.4 GHz transceiver. 45 channels are used frequency hop from 2.403 through 2.447 GHz. The reason for using 45 channels is to keep operation within the overlap area between the 2.4 GHz ISM band (governed in the USA by FCC part 15) and the HAM portion of the band (governed in the USA by FCC part 97). This allows part 15 compliant use of the protocol, while allowing licensed amateur radio operators to operate under the less restrictive part 97 rules if desired. Additional details about configuring and using the protocol are available at the project page on GitHub:\ ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | | --- | --- | --- | --- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ----- | | A | E | T | R | AUX1 | AUX2 | AUX3 | AUX4 | AUX5 | AUX6 | AUX7 | AUX8 | AUX9 | AUX10 | ## Sub Protocols ### 0 - CABELL\_V3 4 to 16 channels, without telemetry ### 1 - CABELL\_V3\_TELEMETRY 4 to 16 channels with telemetry (RSSI, V1, V2). V1 & V2 can be used to return any analog voltage between 0 and 5 volts, so can be used for battery voltage or any other sensor that provides an analog voltage. ### 2 - CABELL\_SET\_FAIL\_SAFE Stores failsafe values in the receiver. {% hint style="info" %} The channel values are set when the sub-protocol is changed to 6, so hold sticks in place as the sub-protocol is changed. {% endhint %} ### 7 - CABELL\_UNBIND The receiver bound to the model is un-bound. {% hint style="warning" %} Un-binding happens immediately when the sub-protocol is set to 7. {% endhint %} ### # CFlie ## Details **Protocol Number:** 38\ **Autobind:** No\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes **Models:** CrazyFlie nano quad ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | | --- | --- | --- | --- | | A | E | T | R | # CG023 ## Details **Protocol Number:** 13\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes None ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | | --- | --- | --- | --- | ---- | ----- | ------- | ----- | -------- | | A | E | T | R | Flip | Light | Picture | Video | Headless | ## Sub Protocols ### 0 - CG023 **Models:** Eachine CG023/CG031/3D X4 ### 1 - YD829 **Models:** Attop YD-822/YD-829/YD-829C ...\ **Channels:** CH6 = Not used # Corona ## Details **Protocol Number:** 37\ **Autobind:** No\ **Channel Re-mapping:** No\ **Extended Limits:** Yes\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** Frequency fine tuning {% hint style="danger" %} Frequency tuning is required for this protocol. See the [Frequency Tuning](/using-the-module/frequency-tuning) page for more details. {% endhint %} ## Notes **Models:** Corona 2.4GHz FSS and DSSS receivers. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | --- | --- | --- | --- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | ## Sub Protocols ### 0 - COR\_V1 **Models:** Corona FSS V1 receivers ### 1 - COR\_V2 **Models:** Corona DSSS V2 receivers - CR8D, CR6D and CR4D To bind V2 receivers, you must follow this procedure: * Press the bind button and power on the receiver * Launch a bind from the radio - the receiver's LED will blink 2 times * Turn off the receiver **and** the radio * Turn on the receiver **first** * Turn on the radio **second** * Wait for the bind to complete - the receiver's LED will flash, stop and finally fix * Wait some time (at least 30 sec) before turning off the receiver * Turn off/on the receiver and test that it can reconnect instantly. If not, repeat the bind procedure. ### 3 - FD\_V3 **Models:** FlyDream receivers - IS-4R and IS-4R0, etc, Avionic receivers - RX8, etc. # CX10 ## Details **Protocol Number:** 12\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes None ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | | --- | --- | --- | --- | ---- | ---- | | A | E | T | R | Flip | Rate | **Rate:** -100% = rate 1; 0% = rate 2; +100% = rate 3 ## Sub Protocols ### 0 - GREEN **Models:** Cheerson CX-10\ **Channels:** As above. ### 1 - BLUE **Models:** Cheerson CX-10 blue PCB and some newer red PCB, CX-10A, CX-10C, CX11, CX12, Floureon FX10, JJRC DHD D1 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | ---- | ---- | ------- | ----- | | A | E | T | R | Flip | Rate | Picture | Video | **Rate:** -100% = rate 1, 0% = rate 2, +100% = rate 3, or headless for CX-10A ### 2 - DM007 **Models:** DM007 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | | --- | --- | --- | --- | ---- | ---- | ------- | ----- | -------- | | A | E | T | R | Flip | Mode | Picture | Video | Headless | ### 4 - JC3015\_1 **Models:** JC3015 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | ---- | ---- | ------- | ----- | | A | E | T | R | Flip | Mode | Picture | Video | ### 5 - JC3015\_2 **Models:** JC3015-2 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | ---- | ---- | --- | ----- | | A | E | T | R | Flip | Mode | LED | DFlip | ### 6 - MK33041 **Models:** MK 33041 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | | --- | --- | --- | --- | ---- | ---- | ------- | ----- | -------- | ---- | | A | E | T | R | Flip | Mode | Picture | Video | Headless | RTH | # Devo ## Details **Protocol Number: 7**\ **Autobind:** No\ **Channel Re-mapping:** Yes\ **Extended Limits:** Yes\ **Failsafe Support:** Yes\ **Receiver Match:** Yes\ **Telemetry:** No\ **Option Value:** N/A ## Notes #### Serial Mode Binding * With the TX off, put the binding plug in and power on the RX (RX LED slow blink), then power it down and remove the binding plug. Receiver should now be in autobind mode. * Turn on the TX, set protocol = Devo with option=0, turn off the TX (TX is now in autobind mode). * Turn on RX (RX LED fast blink). * Turn on TX (RX LED solid, TX LED fast blink). * Wait for bind on the TX to complete (TX LED solid). * Make sure to set a uniq RX\_Num value for model match. * Change option to 1 to use the global ID. * Do not touch option/RX\_Num anymore. #### PPM Mode Binding * With the TX off, put the binding plug in and power on the RX (RX LED slow blink), then power it down and remove the binding plug. Receiver should now be in autobind mode. * Turn on RX (RX LED fast blink). * Turn the dial to the model number running protocol DEVO on the module. * Press the bind button and turn on the TX. TX is now in autobind mode. * Release bind button after 1 second: RX LED solid, TX LED fast blink. * Wait for bind on the TX to complete (TX LED solid). * Press the bind button for 1 second. TX/RX is now in fixed ID mode. * To verify that the TX is in fixed mode: power cycle the TX, the module LED should be solid ON (no blink). * Note: Autobind/fixed ID mode is linked to the RX\_Num number. Which means that you can have multiple dial numbers set to the same protocol DEVO with different RX\_Num and have different bind modes at the same time. It enables PPM users to get model match under DEVO. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---- | ---- | ---- | | A | E | T | R | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | ## Sub Protocols ### 0 - 8CH ### 1 - 10CH ### 2 - 12CH ### 3 - 6CH ### 4 - 7CH # DM002 ## Details **Protocol Number: 33**\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes Only three transmitter IDs are available for this protocol. Change the **Receiver Num** value to cycle through them. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | | --- | --- | --- | --- | ---- | --- | -------- | -------- | -------- | ---- | -------- | | A | E | T | R | Flip | LED | Camera 1 | Camera 2 | Headless | RTH | Low Rate | # DSM ## Details **Protocol Number: 6**\ **Autobind:** No\ **Channel Re-mapping:** Yes\ **Extended Limits:** Yes\ **Failsafe Support:** No\ **Receiver Match:** Yes\ **Telemetry:** Yes - for TSSI and plugins\ **Option Value:** Number of channels (3 to 12) ## Notes **Models:** Spektrum DSM2 and DSMX compatible receivers {% hint style="danger" %} Unless **Channel Re-mapping** is disabled, the radio model's channel order must match the Expected Channel Order of the MULTI-Module, which is **AETR** by default. See the[ Channel Order page](/using-the-module/channel-order) for more details. {% endhint %} ### Autodetect Format **Autodetect Format** (a.k.a. the **Auto** sub-protocol) allows the radio to negotiate the correct protocol (DSM2 or DSMX), the correct number of channels, and the optimal data rate with the receiver. Auto-detection relies on telemetry working between the radio and the receiver. {% hint style="success" %} When binding, **Autodetect Format** is strongly recommended to ensure that the optimal configuration for the receiver is used. {% endhint %} If autodetection isn't working properly with your receiver (for example the number of channels is set incorrectly), you can un-check **Autodetect Format** and manually select the sub-protocol and number of channels. ### Binding For best results, set the sub-protocol to **Auto** for binding. During the bind process the receiver will inform the radio of the optimal configuration for sub-protocol, number of channels and refresh rate. When the bind ends the sub-protocol should have changed to one of the four DSM2 or DSMX options. {% hint style="info" %} If binding using the **Auto** sub-protocol fails, and the sub-protocol remains on **Auto**, the radio was not able to negotiate the settings with the receiver. Try moving the radio closer or farther away from the receiver and trying again. {% endhint %} If you are unable to bind in Auto mode you can try all four sub-protocols manually. {% hint style="warning" %} When manually selecting the sub-protocol, your receiver may work correctly with more than one of them, or it may work correctly with one and erratically or not at all with others. **Take care when testing sub-protocols and ensure your model is safe (e.g. propellers off).** {% endhint %} ### Channel Order Channel order is very important for DSM, and a common source of problems if not configured correctly. By default the MULTI-Module will expect channels in the module's Expected Channel Order, and will convert them into TAER order automatically. {% hint style="danger" %} The model's channel order must match the Expected Channel Order of the MULTI-Module, which is **AETR** by default. See the[ Channel Order page](/using-the-module/channel-order) for more details. {% endhint %} Unless you change the firmware on your MULTI-Module, your model should be configured with the channels assigned in **AETR** order, because this is the default Expected Channel Order. ![Channels in AETR Order](/files/-LxjsepTV7UO06OwUCTU) If you change the firmware to expect a different channel order you must change the radio's default channel order and manually update any existing models. See the [Channel Order page](/using-the-module/channel-order) for more details, including how to disable channel order remapping. ### Option Value Sets the number of channels for the receiver (3-12). The value is set automatically when using **Autodetect Format** or the **Auto** sub-protocol during binding. ### Receiver Output Range {% hint style="info" %} By default the MULTI-Module will scale receiver output to match the Spektrum standard throw, 1100µs to 1900µs. {% endhint %} Either one of the methods below can be used to increase the output range. Usually one method is sufficient, but both methods can be combined to give even greater ranges or more customization if required. #### Method 1 - Enable Max Throw The easiest way to increase output ranges is by checking **Enable max. throw** in the model setup. This will increase the output range of all channels to 1024µs to 1976µs. ![Enable max. throw](/files/-MFdXFNDrymQEZUS_DVM) With **Enable max. throw** checked: * The default weight of 100% will now give an output range of 1024µs to 1976µs * A weight of 84% will give the Spektrum standard range of 1100µs to 1900µs #### Method 2 - Extended Limits Alternatively, output range can be increased by enabling **Extended Limits** in the model setup and configuring minimum and maximum output percentages for each channel in the **Outputs**. This method allows each channel's range to be configured independently, and allows larger ranges than **Enable Max Throw**. ![Extended Limits Enabled](/files/-MFeMyZDDbiFTtx0r8la) With **Extended Limits** enabled: * A range of -100% to 100% will give an output range of 1100µs to 1900µs * A range of -125% to 125% will give an output range of 1000µs to 2000µs * A range of -130% to 130% will give an output range of 980µs to 2020µs ![CH3 Output Range Extended to +/- 125%](/files/-MFeN538nhn5hIbCOeha) If you are using [PPM Mode](/using-the-module/ppm-mode), ensure that the `PPM_MIN_100` and `PPM_MAX_100` settings in \_Config.h match your radio's output. ### SAFE Select To allow SAFE to be ON with a switch assignment you must remove the bind plug after powering up the RX but before turning on the TX to bind. If you use Autodetect Format during binding the MULTI-Module will choose DSMX 11ms and Channels 1-7 (change channels to 1-9 if you wish to assign switch above channel 7). In order to use the manuals diagram of both sticks 'Down-Inside' to set a SAFE Select Switch Designation, you must have **Throttle and Elevator** channels set to **Normal** direction but the **Aileron and Rudder** set to **Reverse** direction. If setting up a new model with all channels set to Normal you can hold both sticks 'Down-**Outside**' to assign the switch with 5x flips. This has been tested on a Mode 2 radio. ### Servo Refresh Rate Servo refresh rate is 22ms unless 11ms is selected. The option to select the refresh rate when binding will be available in OpenTX 2.3.10+. ### Telemetry Range Some DSM receivers and many bind-and-fly (BNF) models with DSM receivers (e.g. E-flite UMX models) have 'fly-by' telemetry which has very limited range (less than 100' or 30m). {% hint style="info" %} Short-range telemetry is not a problem with the MULTI-Module or radio, it is a limitation of the receiver. {% endhint %} To avoid unnecessary 'telemetry lost' warnings when using a short-range-telemetry receiver, disable the telemetry warnings by checking the **Disable telemetry alarms** checkbox in the model's **Telemetry** configuration. ![Telemetry Alarms Disabled](/files/-MF68KNCKzFedFscqrHv) {% hint style="info" %} For protocols other than DSM, checking Disable telemetry alarms will generate a warning when the model is activated. This warning is not shown when the MULTI-Module protocol is DSM. {% endhint %} {% hint style="success" %} Always perform a manual Range Check to ensure that control range will be sufficient for your needs. {% endhint %} ### Throttle Kill **Throttle Kill** is available on **CH14** for models which need it (X-Vert, Blade 230S, etc.). The output value in is derived from the weight applied to CH14, which must be between -50% and -100% * A weight of -50% gives 1100µs output * A weight of -80% gives 980µs output * A weight of -100% gives 904µs output {% hint style="success" %} An output weight of **-80%** on **CH14** will instantly stop the motors on an X-Vert by setting the throttle channel to **980µs** (equivalent to **-130%** on a Spektrum radio)**.** {% endhint %} For example, **CH14** is configured with a weight of -80%, switch **SF** as the source, and **SF↓** as the switch ![X-Vert -130% Throttle Kill on CH14 using switch SF](/files/-M15op_7kbJkv5OlyQPM) * When switch **SF** is off, **CH14** is at 0% * When switch **SF** is on, the MULTI-Module sends 980µs on the throttle channel, killing the motors ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---- | ---- | ---- | ---- | ------------- | | A | E | T | R | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | - | Throttle Kill | {% hint style="info" %} The Channel Assignment table assumes the MULTI-Module's default Expected Channel Order, **AETR**, is being used on the radio. If you have changed the MULTI-Module's Expected Channel Order to something other than AETR you need to adjust CH1 to CH4 accordingly. See the[ Channel Order page](/using-the-module/channel-order) for more details. {% endhint %} ## Sub Protocols ### 0 - DSM2 1F DSM2, resolution 1024, servo refresh rate can only be 22ms. **Note:** 'DSM2 1F' was previously labelled as 'DSM 2 22ms'. ### 1 - DSM2 2F DSM2, resolution 2048, servo refresh rate can be 22ms or 11ms. All servo outputs will be 22ms when more than seven channels are configured. **Note:** 'DSM2 2F' was previously labelled as 'DSM 2 11ms'. ### 2 - DSMX 1F DSMX, resolution 2048, servo refresh rate can only be 22ms. **Note:** 'DSMX 1F' was previously labelled as 'DSM X 22ms'. ### 3 - DSMX 2F DSMX, resolution 2048, refresh rate 22ms or 11ms. All servo outputs will be 22ms when more than seven channels are configured. **Note:** 'DSMX 2F' was previously labelled as 'DSM X 11ms'. ### 4 - Auto The **Auto** sub-protocol enables the radio to negotiate the correct settings for the receiver. Auto-negotiation is supported on OpenTX, erSkyTx, and er9x. In OpenTX, **Auto** can be enabled by checking the **Autodetect format** box or selecting the **Auto** sub-protocol. You must have telemetry enabled and working, and on erSkyTx you need to set the telemetry **Usr proto** to **DSMx**. # DSM RX ## Details **Protocol Number:** 70\ **Autobind:** No\ **Channel Re-mapping:** Yes\ **Extended Limits:** Yes\ **Failsafe Support:** No\ **Receiver Match:** Yes\ **Telemetry:** N/A\ **Option Value:** N/A ## Notes Uses the MULTI-Module as a DSM receiver instead of a transmitter. Compatible with any radio transmitting DSM 2/X 11/22ms 1024/2048res. Enables two radios to be linked in a trainer/trainee partnership. See the Wireless Trainer page for more information. {% content-ref url="/pages/-LxLIKwcjZhLeU-YFKbM" %} [Wireless Trainer](/using-the-module/wireless-trainer) {% endcontent-ref %} {% hint style="danger" %} Unless **Channel Re-mapping** is disabled, the radio model's channel order must match the Expected Channel Order of the MULTI-Module, which is **AETR** by default. See the[ Channel Order page](/using-the-module/channel-order) for more details. {% endhint %} The DSM protocol configuration used on the transmitting radio is detected and matched automatically at bind time. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---- | ---- | ---- | | A | E | T | R | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | {% hint style="info" %} The Channel Assignment table assumes the MULTI-Module's default Expected Channel Order, **AETR**, is being used on the radio. If you have changed the MULTI-Module's Expected Channel Order to something other than AETR you need to adjust CH1 to CH4 accordingly. See the[ Channel Order page](/using-the-module/channel-order) for more details. {% endhint %} ## Sub Protocols ### 0 - Multi Use the MULTI-module telemetry pin to send the trainer information to the radio. ### 1 - CPPM Sending trainer channels to FrSky radios through telemetry does not work since the telemetry lines of the internal and external modules are shared (hardware limitation). On an STM32 module, and with a simple hardware modification, you can go around this limitation using CPPM to send the trainer information to the radio. For more information check the [CCPM Hardware Modification](https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/docs/CPPM_HW_Mod.md) page on GitHub. Once your **setup** is **complete,** and before enabling the internal module, you **must check the "Disable Telemetry" box** to stop the Multi module from sending any data to the radio and therrfore freeing up the line for the internal module. # E010 R5 ## Details **Protocol Number: 81**\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** Transmitter ID selection\ **Firmware Version:** v1.3.2.6 ## Notes **Models:** E010 R5 red boards, JJRC H36, H36F and H36S ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | | --- | --- | --- | --- | ---- | --- | ----------- | -------- | --- | ----- | | A | E | T | R | Flip | LED | Calibration | Headless | RTH | Glide | # E016H v2 ## Details **Protocol Number: 80**\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** Frequency fine tuning\ **Firmware Version:** v1.3.1.92 {% hint style="danger" %} Frequency tuning is required for this protocol. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. {% endhint %} ## Notes **Models:** Eachine E016H v2 ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | | --- | --- | --- | --- | --------------- | --------- | ---- | ----------- | -------- | ---- | | A | E | T | R | Takeoff/Landing | Emergency | Flip | Calibration | Headless | RTH | **Takeoff/Landing:** This is a momentary switch to arm the motors or land the quad. This switch is not really needed as you can start the quad with throttle low then increase throttle until the motor arms, move throttle to mid-stick and then increase it quickly to lift off; To land just bring throttle all the way down, the quad will just stops when touching the ground. **Emergency:** Can be used along with the throttle cut switch: Throttle cut=set throttle at -100% and set EMERGENCY to 100% # E01X ## Details **Protocol Number: 45**\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** Timing adjustment ## Notes Problems have been reported with the E012 and E015 sub-protocols. The **Option Value** can be used to adjust the timing. Try all values between -127 and +127. If it works, please report the value you have used by posting in the RC Groups forum. ## Sub Protocols ### 0 - E012 **Models:** Eachine E012 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | | --- | --- | --- | --- | --- | ---- | --- | -------- | --- | | A | E | T | R | | Flip | | Headless | RTH | ### 1 - E015 **Models:** Eachine E015 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | | --- | --- | --- | --- | --- | ---- | --- | -------- | --- | | A | E | T | R | Arm | Flip | LED | Headless | RTH | ### 2 - E016H **Models:** Eachine E016H | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | | --- | --- | --- | --- | ---- | ---- | --- | -------- | --- | | A | E | T | R | Stop | Flip | - | Headless | RTH | # E129 ## Details **Protocol Number: 83**\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A\ **Firmware Version:** v1.3.2.6 ## Notes **Models:** Eachine E129/E130 and Twister Ninja 250 Trims can be done to some extent on the AETR channels directly but if you push them too far you won't be able to arm. In this case use the associated trim TrimA/E/R instead. Take off with a non-spring throttle is easier by putting both sticks down outwards (like on the original radio) in Mode 1/2, not sure about other modes. Calibration is the same as the original radio with both sticks down and to the left in Mode 1/2, not sure about other modes. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | | --- | --- | --- | --- | ------------ | --------- | ------ | ------ | ------ | | A | E | T | R | Takeoff/Land | Emergency | Trim A | Trim E | Trim R | # ESky ## Details **Protocol Number: 16**\ **Autobind:** No\ **Channel Re-mapping:** Yes\ **Extended Limits:** Yes\ **Failsafe Support:** No\ **Receiver Match:** Yes\ **Telemetry:** No\ **Option Value:** N/A ## Notes None ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | | --- | --- | --- | --- | ---- | ----- | | A | E | T | R | Gyro | Pitch | ## Sub Protocols ### 0 - Std ### 1 - ET4 **Models:** Model compatible with the ET4 transmitter, such as ESky Big Lama. {% hint style="warning" %} Multiple IDs are available but only one frequency. {% endhint %} # ESky 150 ## Details **Protocol Number:** 35\ **Autobind:** No\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** Yes\ **Telemetry:** No\ **Option Value:** N/A ## Notes Protocol for small ESky models since 2014 (150, 300, 150X, ...) ## Sub Protocols ### 0 - 4CH | CH1 | CH2 | CH3 | CH4 | | --- | --- | --- | --- | | A | E | T | R | ### 1 - 7CH | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | | --- | --- | --- | --- | ----------- | ----- | ----- | | A | E | T | R | Flight mode | AUX 6 | AUX 7 | Flight Mode and AUX 7 have four positions: * -100% to -50% => 0 * -50% to 5% => 1 * 5% to 50% => 2 * 50%..100% => 3 ### # ESky 150 V2 ## Details **Protocol Number:** 69\ **Autobind:** No\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** Yes\ **Telemetry:** No\ **Option Value:** N/A\ **Firmware Version:** v1.3.0.95 ## Notes **Models:** Small ESky models such as 150 V2, F150Fv, Blade 70s {% hint style="info" %} To run this protocol you need both CC2500 and NRF24L01 RF modules to be enabled. Only the CC2500 is used for RF transmission. {% endhint %} ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | | A | E | T | R | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | **F150 V2:** Rate is assigned to CH5 - 100% = Low; +100% = High # FlySky ## Details **Protocol Number:** 1\ **Autobind:** No\ **Channel Re-mapping:** Yes\ **Extended Limits:** Yes\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes {% hint style="warning" %} This protocol is for older FlySky receivers only. Newer receivers, such as the FS-iA6B, use the [FlySky ADHDS 2A](/using-the-module/protocol-details/flysky-afhds2a) protocol. {% endhint %} ## Sub Protocols ### 0 - Flysky | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | --- | --- | --- | --- | | A | E | T | R | CH5 | CH6 | CH7 | CH8 | ### 1- V9X9 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | ---- | ----- | ------- | ----- | | A | E | T | R | Flip | Light | Picture | Video | ### 2 - V6X6 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | | --- | --- | --- | --- | ---- | ----- | ------- | ----- | -------- | ---- | ----- | ----- | | A | E | T | R | Flip | Light | Picture | Video | Headless | RTH | X Cal | Y Cal | ### 3 - V912 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | | --- | --- | --- | --- | ------------- | ---------- | | A | E | T | R | Bottom Button | Top Button | ### 4 - CX20 **Models:** Cheerson CX-20 / Quanum Nova\ **Autobind:** Yes | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | | --- | --- | --- | --- | ----------- | --- | --- | | A | E | T | R | Flight Mode | CH6 | CH7 | # FlySky AFHDS 2A ## Details **Protocol Number:** 28\ **Autobind:** No\ **Channel Re-mapping:** Yes\ **Extended Limits:** Yes\ **Failsafe Support:** Yes\ **Receiver Match:** Yes\ **Telemetry:** Yes\ **Option Value:** Servo refresh rate. A value of 0 gives 50Hz (min), 70 gives 400Hz (max). Specific refresh rate value can be calculated as $$option=(refreshrate-50) \div 5$$ ## Notes **Models:** FS-iA6B, FS-iA10B, etc. {% hint style="success" %} FlySky AFHDS 2A is labelled **FlSky 2A** in OpenTX. {% endhint %} {% hint style="warning" %} You **must** use a different **Receiver Number** for each different AFHDS 2A receiver you bind. Re-using numbers will remove the binding for the previous receiver. {% endhint %} {% hint style="info" %} A maximum of 64 AFHDS 2A receivers can be bound to the MULTI-Module. {% endhint %} ### Telemetry If telemetry data is incomplete (for example, missing receiver RSSI) you need to upgrade your RX firmware to version 1.6 or later. You can do it from an original FlySky radio, or using an ST-Link programmer, as explained in [this tutorial](https://www.rcgroups.com/forums/showthread.php?2677694-How-to-upgrade-Flysky-Turnigy-iA6B-RX-to-firmware-1-6-with-a-ST-Link). Suggested OpenTX RSSI alarm threshold settings: | OpenTX Version | Low Threshold | Critical Threshold | | --------------- | ------------- | ------------------ | | Prior to 2.3.0 | 15 | 12 | | 2.3.0 and later | 70 | 50 | ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---- | ---- | ---- | ---- | ---- | | A | E | T | R | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | ## Sub Protocols ### 0 - PWM\_IBUS ### 1 - PPM\_IBUS ### 2 - PWM\_SBUS ### 3 - PPM\_SBUS ### 4 - PWM\_IBUS16 3 additional channels. Need recent or updated RXs. | CH15 | CH16 | CH17 | | ---- | ---- | ---- | | CH15 | CH16 | LQI | **LQI:** Link Quality Indicator ### 5 - PPM\_IBUS16 3 additional channels. Need recent or updated RXs. | CH15 | CH16 | CH17 | | ---- | ---- | ---- | | CH15 | CH16 | LQI | **LQI:** Link Quality Indicator # FlySky AFHDS 2A RX ## Details **Protocol Number:** 56\ **Autobind:** No\ **Channel Re-mapping:** Yes\ **Extended Limits:** Yes\ **Failsafe Support:** No\ **Receiver Match:** Yes\ **Telemetry:** N/A\ **Option Value:** N/A ## Notes Uses the MULTI-Module as a DSM receiver instead of a transmitter. Compatible with any radio transmitting AFHDS 2A. Enables two radios to be linked in a trainer/trainee partnership. See the Wireless Trainer page for more information. {% content-ref url="/pages/-LxLIKwcjZhLeU-YFKbM" %} [Wireless Trainer](/using-the-module/wireless-trainer) {% endcontent-ref %} # FQ777 ## Details **Protocol Number:** 23\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes **Models:** FQ777-124 (with SV7241A) ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | ---- | --- | -------- | ------ | | A | E | T | R | Flip | RTH | Headless | Expert | # FrSky D (D8) ## Details **Protocol Number:** 3\ **Autobind:** No\ **Channel Re-mapping:** No\ **Extended Limits:** Yes\ **Failsafe Support:** No\ **Receiver Match:** Yes\ **Telemetry:** Yes\ **Option Value:** Frequency fine tuning {% hint style="danger" %} Frequency tuning is required for this protocol. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. {% endhint %} ## Notes **Models:** FrSky receivers D4R and D8R. DIY RX-F801 and RX-F802 receivers. D8 compatible receivers. Telemetry enabled for A0, A1, RSSI, TX\_RSSI, TX\_LQI and Hub. Lower TX\_LQI indicates a better quality link and is a good indicator of how well the module is tuned. {% hint style="success" %} In OpenTX the FrSky D protocol is accessed as **FrSky**, with subprotocol **D8**. The **FrSky** protocol also has subprotocols for [FrSky V](/using-the-module/protocol-details/frsky-v) receivers, [FrSky X (D16)](/using-the-module/protocol-details/frsky-x) receivers in FCC and EU/LBT modes and D16 receivers operating in 8 channel mode. {% endhint %} ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | --- | --- | --- | --- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | ## Sub Protocols ### 0 - D8 FrSky D8 protocol, using the MULTI-Module's own unique ID. ### 1 - Cloned Use the identifier learnt from another FrSky radio when binding with the [FrSky RX protocol in CloneTX mode](/using-the-module/protocol-details/frsky-rx#1-clonetx). {% hint style="warning" %} When using the Cloned sub-protocol, the **Receiver Number** cannot be used any more and is ignored. {% endhint %} # FrSky L ## Details **Protocol Number:** 67\ **Autobind:** No\ **Channel Re-mapping:** No\ **Extended Limits:** Yes\ **Failsafe Support:** No\ **Receiver Match:** Yes\ **Telemetry:** No\ **Option Value:** Frequency fine tuning\ **Firmware Version:** v1.3.0.87 {% hint style="danger" %} Frequency tuning is required for this protocol. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. {% endhint %} ## Notes **Models:** FrSky L9R receivers. Also known as LR12 ## Sub Protocols ### 0 - LR12 **Refresh Rate:** 36ms | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---- | ---- | ---- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | ### 1 - LR12\_6CH **Refresh Rate:** 18ms | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | | --- | --- | --- | --- | --- | --- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | ### # FrSky R9 ## Details **Protocol Number:** 65\ **Autobind:** No\ **Channel Re-mapping:** No\ **Extended Limits:** Yes\ **Failsafe Support:** Yes\ **Receiver Match:** Yes\ **Telemetry:** Yes\ **Option Value:** N/A ## Notes **Models:** FrSky R9 receivers {% hint style="danger" %} R9 receivers must be running ACCST Flex firmware {% endhint %} {% hint style="info" %} Only supported on MULTI-Modules which have an **SX1276 RF** module, e.g. the Jumper T18 Pro Internal 5-in-1 module. {% endhint %} ### Binding #### OpenTX <= 2.3.9 During binding the receiver will be configured to output channels 1-8 on the PWM pins, with telemetry on. #### OpenTX >= 2.3.10 When binding an R9 receiver the radio will prompt you to choose the bind configuration. This prompt allows you to configure the receiver outputs, in the same way that it can be configured with physical jumpers placed on the PWM output pins during bind. ![R9 Binding](/files/-MCHUAD-lQV7Cbpucrue) The selection you make determines which channels will be output on the PWM pins of the receiver, and whether telemetry is on or off. The remaining channels will be output on the SBUS port. #### For Example: `Ch1-8 Telem ON` will output the radio channels 1-8 on the receiver's PWM pins and channels 9-16 on the SBUS port, with telemetry enabled. This configuration could typically be used on a model with servos connected directly to the receiver. `Ch9-16 Telem ON` will output the radio channels 1-8 on the SBUS port and 9-16 on the receiver's PWM pins, with telemetry enabled. This configuration could typically be used on a model with a flight controller connected to the SBUS port and accessories (such as a camera gimbal) connected to the PWM pins. Refer to your receiver documentation for more information. ## Sub Protocols ### 0 - R9\_915 915MHz, 16 channels. | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | ### 1 - R9\_868 868MHz, 16 channels. | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | ### 2 - R9\_915\_8CH 915MHz, 8 channels. | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | --- | --- | --- | --- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | ### 3 - R9\_868\_8CH 868MHz, 8 channels. | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | --- | --- | --- | --- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | ### 4 - R9\_FCC FCC, 16 channels. | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | ### 6 - R9\_FCC\_8CH FCC, 8 channels. | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | --- | --- | --- | --- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | # FrSky V ## Details **Protocol Number:** 25\ **Autobind:** No\ **Channel Re-mapping:** No\ **Extended Limits:** Yes\ **Failsafe Support:** No\ **Receiver Match:** Yes\ **Telemetry:** Yes\ **Option Value:** Frequency fine tuning {% hint style="danger" %} Frequency tuning is required for this protocol. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. {% endhint %} ## Notes **Models:** FrSky receivers V8R4, V8R7 and V8FR. {% hint style="success" %} In OpenTX the FrSky V protocol is accessed as **FrSky**, with subprotocol **V8**. The **FrSky** protocol also has subprotocols for [FrSky D (D8)](/using-the-module/protocol-details/frsky-d) receivers, [FrSky X (D16)](/using-the-module/protocol-details/frsky-x) receivers in FCC and EU/LBT modes and D16 receivers operating in 8 channel mode. {% endhint %} ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | | --- | --- | --- | --- | | CH1 | CH2 | CH3 | CH4 | # FrSky X (D16) ## Details **Protocol Number:** 15\ **Autobind:** No\ **Channel Re-mapping:** No\ **Extended Limits:** Yes\ **Failsafe Support:** Yes\ **Receiver Match:** Yes\ **Telemetry:** Yes\ **Option Value:** Frequency fine tuning {% hint style="danger" %} Frequency tuning is required for this protocol. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. {% endhint %} ## Notes **Models:** FrSky D16 receivers, including X4R, X6R, X8R, XSR, XM+, and SxR, running **ACCST v1 firmware**. D16 compatible receivers. {% hint style="danger" %} FrSky receivers running ACCST v2 firmware should use the [**FrSkyX2** protocol](/using-the-module/protocol-details/frsky-x2) - they are not supported by this protocol. {% endhint %} Full telemetry is supported, including bi-directional capabilities, enabling LUA scripts to be used to configure SxR receivers and Betaflight parameters (for example). Listen Before Talk (LBT) is supported. Use the EU/LBT sub-protocols for receivers running EU / LBT firmware. {% hint style="success" %} In OpenTX the FrSky X protocol is accessed as **FrSky**, with subprotocol **D16**. The **FrSky** protocol also has subprotocols for ACCST v1 D16 receivers in FCC and EU/LBT modes and D16 8 channel mode, as well as [FrSky V](/using-the-module/protocol-details/frsky-v) receivers and [FrSky D (D8)](/using-the-module/protocol-details/frsky-d) receivers. {% endhint %} ### Binding When binding a D16 receiver the radio will prompt you to choose the bind configuration. This prompt allows you to configure the receiver outputs, in the same way that it can be configured with physical jumpers placed on the PWM output pins during bind. ![D16 Binding Options](/files/-MBImAuKtKnd7pSmoDip) The selection you make determines which channels will be output on the PWM pins of the receiver, and whether telemetry is on or off. The remaining channels will be output on the SBUS port. #### For Example: `Ch1-8 Telem ON` will output the radio channels 1-8 on the receiver's PWM pins and channels 9-16 on the SBUS port, with telemetry enabled. This configuration could typically be used on a model with servos connected directly to the receiver. `Ch9-16 Telem ON` will output the radio channels 1-8 on the SBUS port and 9-16 on the receiver's PWM pins, with telemetry enabled. This configuration could typically be used on a model with a flight controller connected to the SBUS port and accessories (such as a camera gimbal) connected to the PWM pins. Refer to your receiver documentation for more information. ## Sub Protocols ### 0 - CH\_16 FCC protocol, 16 channels @18ms. | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | ### 1 - CH\_8 FCC protocol, 8 channels @9ms. | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | --- | --- | --- | --- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | ### 2 - EU\_16 EU-LBT (listen before talk) protocol, 16 channels @18ms. | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | ### 3 - EU\_8 EU-LBT (listen before talk) protocol, 8 channels @9ms. | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | --- | --- | --- | --- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | ### 4 - Cloned Uses the identifier learnt from another FrSky radio using the FrSkyRX/CloneTX mode.\ 16 Channels ### 5 - Cloned\_8 Uses the identifier learnt from another FrSky radio using the FrSkyRX/CloneTX mode.\ 8 Channels # FrSky X2 (D16) ## Details **Protocol Number:** 64\ **Autobind:** No\ **Channel Re-mapping:** No\ **Extended Limits:** Yes\ **Failsafe Support:** Yes\ **Receiver Match:** Yes\ **Telemetry:** Yes\ **Option Value:** Frequency fine tuning {% hint style="danger" %} Frequency tuning is required for this protocol. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. {% endhint %} ## Notes **Models:** FrSky D16 receivers, including X4R, X6R, X8R, XSR, XM+, and SxR, running **ACCST v2 firmware**. {% hint style="danger" %} FrSky receivers running ACCST v1 firmware should use the [**FrSkyX** protocol](/using-the-module/protocol-details/frsky-x) - they are not supported by this protocol. {% endhint %} Full telemetry is supported, including bi-directional capabilities, enabling LUA scripts to be used to configure SxR receivers and Betaflight parameters (for example). {% hint style="info" %} Listen Before Talk (LBT) is supported. Use the EU/LBT sub-protocols for receivers running EU / LBT firmware. {% endhint %} ### Binding When binding a D16 receiver the radio will prompt you to choose the bind configuration. This prompt allows you to configure the receiver outputs, in the same way that it can be configured with physical jumpers placed on the PWM output pins during bind. ![D16 Binding Options](/files/-MBImAuKtKnd7pSmoDip) The selection you make determines which channels will be output on the PWM pins of the receiver, and whether telemetry is on or off. The remaining channels will be output on the SBUS port. #### For Example: `Ch1-8 Telem ON` will output the radio channels 1-8 on the receiver's PWM pins and channels 9-16 on the SBUS port, with telemetry enabled. This configuration could typically be used on a model with servos connected directly to the receiver. `Ch9-16 Telem ON` will output the radio channels 1-8 on the SBUS port and 9-16 on the receiver's PWM pins, with telemetry enabled. This configuration could typically be used on a model with a flight controller connected to the SBUS port and accessories (such as a camera gimbal) connected to the PWM pins. Refer to your receiver documentation for more information. ## Sub Protocols ### 0 - CH\_16 FCC protocol, 16 channels @18ms. | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | ### 1 - CH\_8 FCC protocol, 8 channels @9ms. | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | --- | --- | --- | --- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | ### 2 - EU\_16 EU-LBT (listen before talk) protocol, 16 channels @18ms. | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | ### 3 - EU\_8 EU-LBT (listen before talk) protocol, 8 channels @9ms. | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | --- | --- | --- | --- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | ### 4 - Cloned Uses the identifier learnt from another FrSky radio using the FrSkyRX/CloneTX mode.\ 16 Channels ### 5 - Cloned\_8 Uses the identifier learnt from another FrSky radio using the FrSkyRX/CloneTX mode.\ 8 Channels # FrSky RX ## Details **Protocol Number:** 55\ **Autobind:** No\ **Channel Re-mapping:** No\ **Extended Limits:** Yes\ **Failsafe Support:** Yes\ **Receiver Match:** Yes\ **Telemetry:** Yes\ **Option Value:** Frequency fine tuning ## Notes Uses the MULTI-Module as a receiver instead of a transmitter. Compatible with any radio transmitting one of the following protocols: * FrSkyD/D8 * FrSkyX/D16 v1.xxx (FCC or LBT) * FrSkyX/D16 v2.1.0 (FCC or LBT) ## Sub Protocols ### 0 - RX Enables two radios to be linked in a trainer/trainee partnership. See the Wireless Trainer page for more information. {% content-ref url="/pages/-LxLIKwcjZhLeU-YFKbM" %} [Wireless Trainer](/using-the-module/wireless-trainer) {% endcontent-ref %} The FrSky protocol used on the transmitting radio is detected automatically at bind time. {% hint style="warning" %} The same **Receiver Number** must be used on the trainer and trainee radios. {% endhint %} {% hint style="danger" %} Frequency tuning is required for this protocol. If the RF Fine Tune value is 0 the receiver protocol will fine-tune itself, any other value will be used as set. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. {% endhint %} ### 1 - CloneTX This subprotocol makes a clone of a the unique identifier of a radio transmitting one of the supported FrSky protocols. There are three memory 'slots' available for cloning: * 1 slot for D8 cloning * 1 slot for FrSkyX (D16v1) cloning * 1 slot for FrSkyX2 (D16v2.1.0) cloning {% hint style="info" %} The same transmitter or different transmitters can be cloned into each slot, but only one transmitter ID is stored per slot. {% endhint %} If you use the Cloning Procedure with a radio transmitting the D8 protocol, it will be saved in the D8 slot. Likewise for D16v1 and D16v2.1 . Once a transmitter ID is cloned you can use the cloned ID for any model by using the FrSkyD/X/X2 'Cloned' sub-protocol option. This way you can have models working with the original MULTI-Module identifier and models which are shared by both the cloned TX and MPM. {% hint style="success" %} OpenTX 2.3.8 or later is required to use cloned transmitter IDs with the MULTI-Module. {% endhint %} #### Cloning Procedure 1. On the radio to receive the cloned ID, configure a new model with the **FrSky RX** protocol, sub-protocol **CloneTX** 2. On the radio to be cloned, select (or configure) a model which uses the protocol you want to clone the ID from (FrSkyD/D8, FrSkyX/D16, etc.) 3. Place both radios in Bind mode 4. Wait for the bind to complete #### Using the Cloned ID 1. Select or create a model where you want to use the cloned ID 2. Select the protocol which was cloned (FrSkyD/D8, FrSkyX/D16, etc.) 3. Select the sub-protocol **Cloned** #### Notes: * **FrSkyD/D8** - the Receiver Number which was used during the the cloning procedure is used. Changing the Receiver Number has no effect * **FrSkyX/D16** - the Receiver Number must be set to match the value on the original transmitter # Futaba / SFHSS ## Details **Protocol Number:** 21\ **Autobind:** No\ **Channel Re-mapping:** Yes\ **Extended Limits:** Yes\ **Failsafe Support:** Yes\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** Frequency fine tuning {% hint style="danger" %} Frequency tuning is required for this protocol. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. {% endhint %} ## Notes **Models:** Futaba receivers and various XK models. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | --- | --- | --- | --- | | A | E | T | R | CH5 | CH6 | CH7 | CH8 | {% hint style="info" %} The Channel Assignment table assumes the MULTI-Module's default Expected Channel Order, **AETR**, is being used on the radio. If you have changed the MULTI-Module's Expected Channel Order to something other than AETR you need to adjust CH1 to CH4 accordingly. See the[ Channel Order page](/using-the-module/channel-order) for more details. {% endhint %} # FX816 ## Details **Protocol Number:** 58\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes **Model:** Fei Xiong FX816 P38 Only eight transmitter IDs are available. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | | --- | --- | --- | --- | | A | - | T | - | # FY326 ## Details **Protocol Number:** 20\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes **Models:** FY326 Q7 Quadcopter, X6 FY319 Quadcopter ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | | --- | --- | --- | --- | ---- | --- | -------- | ------ | --------- | | A | E | T | R | Flip | RTH | Headless | Expert | Calibrate | ## Sub Protocols ### 0 - FY326 **Model:** FY326 Q7 Quadcopter ### 1 - FY319 **Model:** X6 FY319 Quadcopter {% hint style="warning" %} Protocols is untested. Please confirm if it works correctly if you use it. {% endhint %} # GD00X ## Details **Protocol Number:** 47\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** Frequency fine tuning ## Notes **Models:** GD005 C-17 Transport, GD006 DA62 and ZC-Z50 {% hint style="warning" %} This protocol is known to be problematic. This is due to the emulation of the original radio's RF component. {% endhint %} If the model does not respond well to inputs, or is hard to bind, you can try to switch the emulation mode by using an option value (RF Freq. tuning) other than 0. Once the value is not set to 0 it is used for frequency fine tuning. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | | --- | --- | --- | --- | ---- | --- | ---- | | A | - | T | - | Trim | LED | Rate | **Trim:** Either use this channel for trim only, or add a mixer with aileron to increase the roll rate\ **Rate:** -100% = high rate; +100% = low rate ## Sub Protocols ### 0 - GD\_V1 **Models:** First generation of GD models, ZC-Z50 ### 1 - GD\_V2 **Models:** New generation of GD models # GW008 ## Details **Protocol Number:** 32\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes **Model:** Global Drone GW008 from Banggood There are three versions of this small quad, this protocol is for the one with a XNS104 IC in the stock transmitter and PAN159CY IC in the quad. The XN297 version is compatible with the [CX10 protocol (green pcb)](/using-the-module/protocol-details/cx10#0-green). The LT8910 version is not supported yet. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | | --- | --- | --- | --- | ---- | | A | E | T | R | Flip | # H8 3D ## Details **Protocol Number:** 36\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes None ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | | --- | --- | --- | --- | | A | E | T | R | ## Sub Protocols ### 0 - H8\_3D **Models:** Eachine H8 mini 3D, JJRC H20/H22/H11D | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | | --- | --- | --- | --- | ---- | ----- | ------- | ----- | ---- | ---- | ---- | ---- | ------ | | A | E | T | R | Flip | Light | Picture | Video | OPT1 | OPT2 | CAL1 | CAL2 | Gimbal | **H8 3D Channels** * OPT1 = RTH, then press a direction to enter headless mode (like stock transmitter), * OPT2 = switch 180/360° flip mode * CAL1 = accelerometer calibration **JJRC H20 Channels** * OPT1 = Headless * OPT2 = RTH * CAL1 = H20/H20H - headless calibration * CAL2 = accelerometer calibration **JJRC H22 Channels:** * OPT1 = RTH * OPT2 = 180/360° flip mode ### **1 - H20H** **Models:** JJRC H20H\ **Channels:** CH6 = Motors on/off ### **2 - H20 Mini** **Models:** JJRC H20 Mini\ **Notes:** Only three transmitter IDs are available. Change **Receiver Num** value to cycle through them. ### **3 - H30 Mini** **Models:** JJRC H30 Mini\ **Notes:** Only three transmitter IDs are available. Change **Receiver Num** value to cycle through them. # Height ## Details **Protocol Number:** 53\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes Previously known as 'Flyzone'. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | | --- | --- | --- | --- | | A | E | T | R | ## Sub Protocols ### 0 - 5CH **Models:** Models from Height, Flyzone, Rage R/C, eRC and the old ARES (prior to Hitec RED). | CH1 | CH2 | CH3 | CH4 | CH5 | | --- | --- | --- | --- | ---- | | A | E | T | R | Gear | ### 1 - 8CH **Models:** Models from Height and Rage R/C. | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | ---- | ---- | ---- | ----- | | A | E | T | R | Gear | Gyro | Flap | Light | # HiSky ## Details **Protocol Number:** 4\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** HK310 sub-protocol only\ **Option Value:** N/A ## Notes None ## Sub Protocols ### 0 - HiSky | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | ---- | ----- | ---- | --- | | A | E | T | R | Gear | Pitch | Gyro | CH8 | **Gyro:** -100% = 6G; +100% = 3G ### 1 - HK310 **Models:** RX HK-3000, HK3100 and XY3000 (TX are HK-300, HK-310 and TL-3C)\ **Failsafe Support:** Yes | CH1 | CH2 | CH3 | CH4 | CH5 | | --- | --- | --- | --- | --- | | - | - | T | R | AUX | # Hitec ## Details **Protocol Number:** 39\ **Autobind:** No\ **Channel Re-mapping:** No\ **Extended Limits:** Yes\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** Yes\ **Option Value:** Frequency fine tuning {% hint style="danger" %} Frequency tuning is required for this protocol. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. {% endhint %} ## Notes {% hint style="success" %} The radio must be close to the receiver for binding to complete successfully. {% endhint %} ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | ## Sub Protocols ### 0 - OPT\_FW **Models:** Optima receivers Full telemetry available on OpenTX 2.3.3+; still in progress for erskyTx. Lower TX\_LQI values indicate better link quality. TX\_LQI is a good indicator of how well the module is tuned. ### 1 - OPT\_HUB **Models:** Optima receivers Basic telemetry using FrSky Hub on er9x, erskyTX, OpenTX and any radio with FrSky telemetry support. * Receiver voltage * VOLT2 voltage * TX\_RSSI * TX\_LQI Lower TX\_LQI values indicate better link quality. TX\_LQI is a good indicator of how well the module is tuned. ### 2 - Minima **Models:** Minima, Micro and Red receivers # Hontai ## Details **Protocol Number:** 26\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes None. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | | --- | --- | --- | --- | ---- | --- | ------- | ----- | -------- | ---- | ---- | | A | E | T | R | Flip | LED | Picture | Video | Headless | RTH | Cal | ## Sub Protocols #### 0 - HONTAI #### 1 - JJRCX1 **Model:** JJRC X1\ **Channels:** CH6 = Arm ### 2 - X5C1 Clone **Model:** Bayang X5 C-1 Clone ### 3 - FQ777\_951 **Model:** FQ777-951 # HoTT ## Details **Protocol Number:** 57\ **Autobind:** No\ **Channel Re-mapping:** No\ **Extended Limits:** Yes\ **Failsafe Support:** Yes\ **Receiver Match:** Yes\ **Telemetry:** Yes\ **Option Value:** Frequency fine tuning {% hint style="danger" %} Frequency tuning is required for this protocol. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. {% endhint %} ## Notes **Models:** Graupner HoTT receivers (tested on GR-12, GR-12L, GR-16, and Vector) Receiver feature configuration can be performed using the OpenTX script **Graupner HoTT.lua**. Basic telemetry is available on OpenTX 2.3.3+ with receiver voltage, receiver temperature, RXRSSI, RX LQI, TX RSSI and TX LQI. Lower TX LQI values indicate better link quality. TX LQI is a good indicator of how well the module is tuned. {% hint style="warning" %} You must use a different Receiver Number for each receiver. A maximum of 64 Hott receivers are supported. {% endhint %} {% hint style="danger" %} Failsafe **must** be configured once with the desired channel values (hold or position) while the receiver is up (wait 10+ seconds for the receiver to learn the config) and then failsafe **must** be set to RX/Receiver otherwise the servos will jitter! {% endhint %} ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---- | ---- | ---- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | ## Sub Protocols ### 0 - Sync Recommended for best telemetry performance. ### 1 - No\_Sync Telemetry compatibility mode which can be used when Sync does not work due to an old firmware on the RX. {% hint style="warning" %} You should upgrade your receivers/sensors to the latest firmware versions: {% endhint %} # Hubsan ## Details **Protocol Number:** 2\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** Yes - battery voltage and TX RSSI\ **Option Value:** H107D vTX frequency; 5645 - 5900 MHz ## Notes None. ## Sub Protocols ### 0 - H107 **Models:** Hubsan H102D, H107/L/C/D and H107P/C+/D+ | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | | --- | --- | --- | --- | ---- | ----- | ------- | ----- | -------- | | A | E | T | R | FLIP | LIGHT | PICTURE | VIDEO | HEADLESS | ### 1 - H301 **Models:** Hubsan H301 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | --- | ----- | ---- | ----- | | A | E | T | R | RTH | LIGHT | STAB | VIDEO | ### 2 - H501 **Models:** Hubsan H501S, H122D, H123D | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | | --- | --- | --- | --- | --- | ----- | ------- | ----- | -------- | --------- | --------- | ---- | ------ | | A | E | T | R | RTH | LIGHT | PICTURE | VIDEO | HEADLESS | GPS\_HOLD | ALT\_HOLD | FLIP | FMODES | H122D: FLIP H123D: FMODES -> -100%=Sport mode 1, 0%=Sport mode 2, +100%=Acro mode # J6 Pro ## Details **Protocol Number:** 22\ **Autobind:** No\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes None ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---- | ---- | ---- | | A | E | T | R | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | # JJRC345 ## Details **Protocol Number:** 71\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A\ **Firmware Version:** v1.3.1.1 (v1.3.1.77 for SkyTmblr sub protocol) ## Notes None ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | | --- | --- | --- | --- | ---- | -------- | --- | --- | --- | ---- | ---- | | A | E | T | R | Flip | Headless | RTH | LED | UNK | UNK | UNK | ## Sub Protocols ### 0 - JJRC345 **Models:** JJRC345\ **Firmware Version:** v1.3.1.1 ### 1 - SkyTmblr **Models:** DF-Models SkyTumbler\ **Firmware Version:** v1.3.1.77 RTH not supported. # KF606 ## Details **Protocol Number:** 49\ **Autobind:** No\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** Frequency fine tuning (see notes) ## Notes **Models:** KF606 {% hint style="warning" %} This protocol is known to be problematic. This is due to the emulation of the original radio's RF component. {% endhint %} If the model does not respond well to inputs, or is hard to bind, you can try to switch the emulation mode by using an option value (RF Freq. tuning) other than 0. Once the value is not set to 0 it is used for frequency fine tuning. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | | --- | --- | --- | --- | ---- | | A | | T | | TRIM | # KN ## Details **Protocol Number:** 9\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes None ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | | --- | --- | --- | --- | --------- | ------------- | ------- | ---- | -------- | -------- | -------- | | A | E | T | R | Dual Rate | Throttle Hold | Idle Up | Gyro | Thr Trim | Ail Trim | Ele Trim | **Dual Rate:** +100% = Full Range\ **Throttle Hold:** +100% = Hold\ **Idle Up:** +100% = 3D\ **Gyro:** -100% = 6G; +100% = 3G ## Sub Protocols ### 0 - WLTOYS ### 1 - Feilun # Kyosho ## Details **Protocol Number: 73**\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A\ **Firmware Version:** v1.3.1.49 (v1.3.1.77 for Hype sub-protocol) ## Notes **None** ## Sub Protocols ### 0 - FHSS **Models:** KT-531P, KT-431PT, Flysky Noble NB4 (fw>2.0.67)\ **Firmware Version:** v1.3.1.49 Surface protocol called FHSS introduced in 2017. | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | | -------- | -------- | --- | --- | --- | --- | --- | --- | --- | ---- | ---- | ---- | ---- | ---- | | Steering | Throttle | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | ### 1 - Hype **Transmitters:** ST6DF, HK6S, Flightsport\ **Receivers:** ST6DF, HK6DF\ **Firmware Version:** v1.3.1.77 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | | --- | --- | --- | --- | --- | --- | | A | E | T | R | CH5 | CH6 | RX output will match the Hype standard AETR independently of the input configuration AETR, RETA... unless on OpenTX 2.3.3+ you use the "Disable channel mapping" feature on the GUI. # LOLI ## Details **Protocol Number: 82**\ **Autobind:** No\ **Channel Re-mapping:** No\ **Extended Limits:** Yes\ **Failsafe Support:** Yes\ **Receiver Match:** Yes\ **Telemetry:** Yes\ **Option Value:** N/A\ **Firmware Version:** v1.3.2.6 ## Notes **Models:** LOLI3 receivers: Telemetry supported: RX RSSI, TX LQI (percentage of received telemetry packets), A1 and A2 with a Ratio=25.5 and Offset=0. Once failsafe values for the 8 channels have been configured in Custom mode, wait for the RX to learn them, then set Failsafe to Receiver. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | --- | --- | --- | --- | | CH1 | CH3 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | ### Features | Config on | For channel | Switch | Servo | PPM | SBUS | PWM | | --------- | ----------- | ------ | ----- | ---- | ---- | ----- | | CH9 | CH1 | -100% | 0% | +50% | - | +100% | | CH10 | CH2 | -100% | 0% | - | - | +100% | | CH11 | CH3 | -100% | 0% | - | - | - | | CH12 | CH4 | -100% | 0% | - | - | - | | CH13 | CH5 | -100% | 0% | - | +50% | - | | CH14 | CH6 | -100% | 0% | | - | - | | CH15 | CH7 | -100% | 0% | - | - | +100% | | CH16 | CH8 | -100% | 0% | - | - | - | # M-LINK ## Details **Protocol Number:** 78\ **Autobind:** No\ **Channel Re-mapping:** No\ **Extended Limits:** Yes\ **Failsafe Support:** Yes\ **Receiver Match:** Yes\ **Telemetry:** Yes\ **Option Value:** N/A\ **Firmware Version:** v1.3.2.30 ## Notes {% hint style="warning" %} Failsafe **MUST** be configured once with the desired channel values (hold or no pulses are not supported) while the RX is up (wait 10+ sec for the RX to learn the config) and then failsafe **MUST** be set to RX/Receiver otherwise the servos will jitter. {% endhint %} Telemetry: the 2 RXs I have are sending different information in different format * RX-5: RX\_RSSI=RSSI=sort of RSSI or link quality, RX\_LQI=number of connection lost, TX\_RSSI=RSSI from the TX perspective, TX\_LQI=percentage of received telemetry packets * RX-9-DR: A1=RX Batt (Ratio=12.7), **RX\_RSSI=TX\_LQI**=percentage of received telemetry packets **from the TX** perspective **not RX**, TX\_RSSI=RSSI from the TX perspective, TX\_LQI=percentage of received telemetry packets ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | # MJXq ## Details **Protocol Number:** 18\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** E010 emulation mode and frequency fine tuning (see notes) ## Notes None. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | | --- | --- | --- | --- | ---- | --- | ------- | ----- | -------- | ---- | -------- | ---- | ---- | ---- | | A | E | T | R | Flip | LED | Picture | Video | Headless | RTH | Autoflip | Pan | Tilt | Rate | **Rate:** * -100% (default) = higher rates by enabling dynamic trims (except for Headless) * +100% = disable dynamic trims ## Sub Protocols ### 0 - WLH08 **Models:** MJX WLH-08 and JJRC H13C ### 1 - X600 **Model:** MJX X600 {% hint style="danger" %} Only three transmitter IDs are available for this protocol - take care that another MULTI-Module using the same protocol and ID is not in range at the same time. {% endhint %} Change the **Receiver Num** value to cycle through the the different transmitter IDs. ### 2 - X800 **Model:** MJX X800 {% hint style="danger" %} Only three transmitter IDs are available for this protocol - take care that another MULTI-Module using the same protocol and ID is not in range at the same time. {% endhint %} Change the **Receiver Num** value to cycle through the the different transmitter IDs. ### 3 - H26D **Model:** JJRC H26D {% hint style="danger" %} Only three transmitter IDs are available for this protocol - take care that another MULTI-Module using the same protocol and ID is not in range at the same time. {% endhint %} Change the **Receiver Num** value to cycle through the the different transmitter IDs. ### 4 - E010 **Models:** Eachine E010, JJRC H36 Fifteen transmitter IDs are available for this protocol. Change the **Receiver Num** value to cycle through them. {% hint style="warning" %} This sub-protocol is known to be problematic. This is due to the emulation of the original radio's RF component. {% endhint %} If the model does not respond well to inputs, or is hard to bind, you can try to switch the emulation mode by using an option value (RF Freq. tuning) other than 0. Once the value is not set to 0 it is used for frequency fine tuning. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. # MT99XX ## Details **Protocol Number:** 17\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** YZ emulation mode and frequency fine tuning (see YZ sub-protocol notes) ## Notes None. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | | --- | --- | --- | --- | ---- | --- | ------- | ----- | -------- | | A | E | T | R | Flip | LED | Picture | Video | Headless | ## Sub Protocols ## 0 - MT99 **Models:** MT99xx ### 1 - H7 **Models:** Eachine H7, Cheerson CX023 ### 2 - YZ **Model:** Yi Zhan i6S {% hint style="danger" %} Only one transmitter ID is currently available for this protocol - take care that another MULTI-Module using the same protocol is not in range at the same time. {% endhint %} {% hint style="warning" %} This sub-protocol is known to be problematic. This is due to the emulation of the original radio's RF component. {% endhint %} If the model does not respond well to inputs, or is hard to bind, you can try to switch the emulation mode by using an option value (RF Freq. tuning) other than 0. Once the value is not set to 0 it is used for frequency fine tuning. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. ### 3 - LS **Models:** LS114, 124, 215 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | | --- | --- | --- | --- | ---- | ------ | ------- | ----- | -------- | | A | E | T | R | Flip | Invert | Picture | Video | Headless | ### 4 - FY805 **Model:** FY805 {% hint style="danger" %} Only one transmitter ID is currently available for this protocol - take care that another MULTI-Module using the same protocol is not in range at the same time. {% endhint %} | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | | --- | --- | --- | --- | ---- | --- | --- | --- | -------- | | A | E | T | R | Flip | | | | Headless | # NCC1701 ## Details **Protocol Number:** 44\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** Yes - see notes\ **Option Value:** N/A ## Notes **Model:** Air Hogs Star Trek USS Enterprise NCC-1701-A **Telemetry:** * RSSI is a dummy value. * A1 voltage is dummy but used for crash detection In case of a crash event A1 is >0V. You can assign a sound to be played on the radio in that case (siren on the original transmitter). ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH4 | | --- | --- | --- | --- | ---- | | A | E | T | R | Warp | # OMP ## Details **Protocol Number:** 77\ **Autobind:** No\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** Yes\ **Telemetry:** No\ **Option Value:** Emulation mode and frequency fine tuning (see notes)\ **Firmware Version:** v1.3.1.59 ## Notes {% hint style="warning" %} This protocol is known to be problematic. This is due to the emulation of the original radio's RF component. {% endhint %} If the model does not respond well to inputs, or is hard to bind, you can try to switch the emulation mode by using an option value (RF Freq. tuning) other than 0. Once the value is not set to 0 it is used for frequency fine tuning. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. Telemetry is supported only if a NRF24L01 RF component is installed: * A1 = battery voltage including "recovered" battery voltage from corrupted telemetry packets * A2 = battery voltage from only good telemetry packets * RX\_RSSI = TQly = percentage of received telemetry packets (good and corrupted) from the model which has nothing to do with how well the RX is receiving the TX How to calculate accurately the OpenTX Ratio and Offset: * Set the Ratio to 12.7 and Offset to 0 * Plug in two batteries with extreme voltage values * Write down the values Batt1=12.5V & Telem1=12.2V, Batt2=7V & Telem2=6.6V * Ratio=12.7\*\[(12.5-7)/(12.2-6.6)]=12.47 => 12.5 * Offset=12.5-12.2\*\[(12.5-7)/(12.2-6.6)]=0.517 => 0.5 **Models:** OMP HobbyM1 & M2 Helicopters, T720 RC Glider ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | | --- | --- | ---------- | --- | --------- | ---- | ---- | | A | E | Thr. Pitch | R | Thr. Hold | Idle | Mode | **Idle:** -100% = Beginner Mode; 0% = Idle 1; +100% = Idle 2\ **Mode:** -100% Attitude(?); 0% Attitude; +100% 3D\ **M2 Mode:** -100% 6G; 0% 3D; +100% 3D # OpenLRS ## Details **Protocol Number:** 27 ## Notes This is a reservation for OpenLRSng which is using the MULTI-Module's serial protocol for their modules. See for more information. There is no MULTI-Module protocol associated with protocol number 27, so it is ignored. # Pelikan ## Details **Protocol Number:** 60\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes **Models:** TX: CADET PRO V4, RX: RX-602 V4 {% hint style="danger" %} Only one transmitter ID is currently available for this protocol - take care that another MULTI-Module using the same protocol is not in range at the same time. {% endhint %} ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | --- | --- | --- | --- | | A | E | T | R | CH5 | CH6 | CH7 | CH8 | # Potensic ## Details **Protocol Number:** 51\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes **Models:** Potensic A20 ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | ------------------ | --------- | ---- | -------- | | A | E | T | R | Take off / Landing | Emergency | Mode | Headless | **Take off / Landing:** Momentary switch -100% -> +100%\ **Emergency:** +100% = Stop\ **Mode:** -100% = Beginner; 0% = Medium; +100% = Advanced\ **Headless:** -100% = Off; +100% = On # Propel ## Details **Protocol Number:** 66\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** Yes - see notes\ **Option Value:** N/A ## Notes **Model:** Propel 74-Z Speeder Bike **Telemetry:** * RSSI is equal to TX\_LQI which indicates how well the TX receives the RX (0-100%). * A1 voltage should indicate the numbers of life remaining (not tested) * A2 is the model status using a bit mask: * 0x80 = flying * 0x08 = taking off * 0x04 = landing * 0x00 = landed/crashed ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | | --- | --- | --- | --- | ---- | ---- | ------- | -------- | ---- | ------- | ------ | --------- | -------- | ---- | -------- | | A | E | T | R | Warp | LEDs | Roll CW | Roll CCW | Fire | Weapons | Calib. | Alt. Hold | Take Off | Land | Training | # Q2x2 ## Details **Protocol Number:** 29\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes None. ## Sub Protocols ### 0 - Q222 **Models:** Q222 v1 and V686 v2 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | | --- | --- | --- | --- | ---- | --- | ------- | ------- | -------- | ---- | ---- | ---- | | A | E | T | R | Flip | LED | Module2 | Module1 | Headless | RTH | XCal | YCal | ### 1 - Q242 **Models:** Q242 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | | --- | --- | --- | --- | ---- | --- | ------- | ----- | -------- | ---- | ---- | ---- | | A | E | T | R | Flip | LED | Picture | Video | Headless | RTH | XCal | YCal | ### 2 - Q282 **Models:** Q282 and JXD 509 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | | --- | --- | --- | --- | ---- | --- | ------- | ----- | -------- | ---- | ---- | ---- | | A | E | T | R | Flip | LED | Picture | Video | Headless | RTH | XCal | YCal | **JXD 509:** CH12 = Motor start stop # Q303 ## Details **Protocol Number:** 31\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** Q303 emulation mode and frequency fine tuning (see notes) ## Notes None. ## Sub Protocols ### 0 - Q303 **Model:** WLtoys Q303 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | | --- | --- | --- | --- | -------- | ---- | ------- | ----- | -------- | ---- | ------ | | A | E | T | R | Alt Hold | Flip | Picture | Video | Headless | RTH | Gimbal | **Gimbal:** Three position switch - 100%; 0%; +100% {% hint style="warning" %} This sub-protocol is known to be problematic. This is due to the emulation of the original radio's RF component. {% endhint %} If the model does not respond well to inputs, or is hard to bind, you can try to switch the emulation mode by using an option value (RF Freq. tuning) other than 0. Once the value is not set to 0 it is used for frequency fine tuning. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. ### 1 - CX35 **Model:** Cheeron CX-35 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | | --- | --- | --- | --- | --- | --- | ------- | ----- | --- | ---- | ------ | | A | E | T | R | Arm | VTX | Picture | Video | | RTH | Gimbal | **Arm:** Two position switch - land / take off\ **VTX:** Each toggle of VTX increments the channel\ **Gimbal:** Three position switch - 100%; 0%; +100% ### 2 - CX10D **Model:** Cheeron CX-10D | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH8 | | --- | --- | --- | --- | --- | --- | ----- | | A | E | T | R | Arm | VTX | Video | **Arm:** -100% = Land; 0% = Manual; +100% = Take Off ### 3 - CX10WD **Model:** Cheeron CX-10WD | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH8 | | --- | --- | --- | --- | --- | --- | ----- | | A | E | T | R | Arm | VTX | Video | **Arm:** -100% = Land; 0% = Manual; +100% = Take Off # Q90C ## Details **Protocol Number:** 72\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** Emulation mode and frequency fine tuning (see notes)\ **Firmware Version:** v1.3.1.9 ## Notes {% hint style="warning" %} This sub-protocol is known to be problematic. This is due to the emulation of the original radio's RF component. {% endhint %} If the model does not respond well to inputs, or is hard to bind, you can try to switch the emulation mode by using an option value (RF Freq. tuning) other than 0. Once the value is not set to 0 it is used for frequency fine tuning. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | | --- | --- | --- | --- | ----------- | ---- | | A | E | T | R | Flight Mode | VTX+ | **Flight Mode:** Three position switch - 100% = Angle; 0% = Horizon; +100% = Acro **VTX+:** Momentary switch, -100% -> +100% = VTX Channel + # RadioLink ## Details **Protocol Number:** 74\ **Autobind:** No\ **Channel Re-mapping:** No\ **Extended Limits:** Yes\ **Failsafe Support:** Yes\ **Receiver Match:** Yes\ **Telemetry:** Yes\ **Option Value:** Frequency fine tuning\ **Firmware Version:** v1.3.1.49 (v1.3.1.89 for DumboRC sub-protocol) {% hint style="danger" %} Frequency tuning is required for this protocol. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. {% endhint %} ## Notes **Models:** Radiolink air and surface receivers. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | CH14 | CH15 | CH16 | | | --- | --- | --- | --- | --- | --- | --- | --- | ------- | ------- | ------- | ------- | ------- | ------- | ------- | ------- | - | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | FS\_CH1 | FS\_CH2 | FS\_CH3 | FS\_CH4 | FS\_CH5 | FS\_CH6 | FS\_CH7 | FS\_CH8 | | **FS:** Failsafe ## Sub Protocols ### 0 - Surface **Transmitters:** RC4GS, RC6GS\ **Compatible Receivers:** R7FG (Std), R6FG, R6F, R8EF, R8FM, R8F, R4FGM, R4F\ **Firmware Version:** v1.3.1.49 * CH1 = Steering * CH2 = Throttle * CH8 = Gyro gain **Telemetry:** RX\_RSSI (for the original value add -256), TX\_RSSI, TX\_QLY (0..100%), A1=RX\_Batt, A2=Batt/2 (adjust the ratio) ### 1 - Air **Transmitters:** T8FB, T8S \ **Compatible Receivers:** R8EF, R8FM, R8SM, R4FG, R4F\ **Firmware Version:** v1.3.1.49 **Telemetry:** RX\_RSSI (for the original value add -256), TX\_RSSI, TX\_QLY (0..100%) ### 2 - DumboRC **Compatible Receivers:** X6, X6F, X6FG\ **Firmware Version:** v1.3.1.89 # Realacc ## Details **Protocol Number:** 76\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A\ **Firmware Version:** v1.3.1.59 ## Notes {% hint style="warning" %} Protocol is untested. Please provide feedback on the [forum](https://www.rcgroups.com/forums/showthread.php?2165676-DIY-Multiprotocol-TX-Module). {% endhint %} **Model:** Realacc R11 ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | | --- | --- | --- | --- | ---- | ----- | ------ | -------- | --- | ------- | | A | E | T | R | Flip | Light | Calib. | Headless | RTH | Unknown | # Redpine ## Details **Protocol Number:** 50 ## Notes More information in the [RC Groups forum](https://www.rcgroups.com/forums/showthread.php?3236043-Redpine-Lowest-latency-RC-protocol). # Shenqi ## Details **Protocol Number:** 19\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes **Model:** Shenqiwei 1/20 Mini Motorcycle ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | | --- | --- | --- | --- | | - | E | - | R | **Throttle:** +100% = full forward; 0% = stop; -100% = full backward # Skyartec ## Details **Protocol Number:** 68\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** Frequency fine tuning\ **Firmware Version:** v1.3.0.91 {% hint style="danger" %} Frequency tuning is required for this protocol. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. {% endhint %} ## Notes None. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | --- | --- | --- | --- | | A | E | T | R | CH5 | CH6 | CH7 | CH8 | # SLT ## Details **Protocol Number:** 11\ **Autobind:** No\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** Emulation mode and frequency fine tuning (see notes) ## Notes {% hint style="warning" %} This sub-protocol is known to be problematic. This is due to the emulation of the original radio's RF component. {% endhint %} If the model does not respond well to inputs, or is hard to bind, you can try to switch the emulation mode by using an option value (RF Freq. tuning) other than 0. Once the value is not set to 0 it is used for frequency fine tuning. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. ## Sub Protocols ### 0 - V1 **Models:** Tactic SLT version 1 receivers | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | | --- | --- | --- | --- | ---- | ----- | | A | E | T | R | Gear | Pitch | ### 1 - V2 **Models:** Tactic SLT version 2 receivers | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | --- | --- | --- | --- | | A | E | T | R | CH5 | CH6 | CH7 | CH8 | ### 2 - Q100 **Models:** Dromida Ominus UAV | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | | --- | --- | --- | --- | ----- | --- | --- | --- | ---- | ---- | ---- | ---- | --------- | | A | E | T | R | Rates | - | CH7 | CH8 | Mode | Flip | - | - | Calibrate | **Rates:** -50% = min rates; 0% = mid rates (stock setting); +50% = max rates\ **CH7 and CH8:** No visible effect\ **Mode:** -100% level; +100% acro\ **Flip:** Toggle -100% to +100% or +100% to -100% to enable flip mode for \~5sec. Rear red LED goes out while active.\ **Calibrate:** -100% = normal mode; +100% = gyro calibration ### 3 - Q200 **Models:** Dromida Ominus Quadcopter FPV, the Nine Eagles - FENG FPV and may be others Dromida Ominus FPV channel mapping: | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | | --- | --- | --- | --- | ----- | --- | --- | --- | ---- | ---- | -------- | --------- | --------- | | A | E | T | R | Rates | - | CH7 | CH8 | Mode | Flip | Video on | Video off | Calibrate | FENG FPV channel mapping: | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | CH13 | | --- | --- | --- | --- | ----- | --- | --- | --- | ---- | ---- | -------- | --------- | --------- | | A | E | T | R | Rates | - | CH7 | CH8 | Flip | Mode | Video on | Video off | Calibrate | **Rates:** -50% = min rates; 0% = mid rates (stock setting); +50% = max rates\ **CH7 and CH8:** No visible effect\ **Mode:** -100% level; +100% acro\ **Flip:** Toggle -100% to +100% or +100% to -100% to enable flip mode for \~5sec. Rear red LED goes out while active.\ **Calibrate:** -100% = normal mode; +100% = gyro calibration ### 4 - MR100 **Models:** Vista UAV, FPV, FPV v2 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | CH12 | | --- | --- | --- | --- | ----- | --- | --- | --- | ---- | ---- | ----- | ------- | | A | E | T | R | RATES | - | CH7 | CH8 | MODE | FLIP | VIDEO | PICTURE | **Rates:** -50% = min rates; 0% = mid rates (stock setting); +50% = max rates\ **CH7 and CH8:** No visible effect\ **Mode:** -100% level; +100% acro\ **Flip:** Toggle -100% to +100% or +100% to -100% to enable flip mode for \~5sec. Rear red LED goes out while active.\ **Calibrate:** -100% = normal mode; +100% = gyro calibration # SymaX ## Details **Protocol Number:** 10\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes None. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | | --- | --- | --- | --- | ---- | ---- | ------- | ----- | -------- | | A | E | T | R | Flip | Rate | Picture | Video | Headless | **Rate:** * -100% (default) = disable dynamic trims, * +100% = higher rates by enabling dynamic trims (except for Headless) ## Sub Protocols ### 0 - SYMAX **Models:** Syma X5C-1; Syma X11; Syma X11C; Syma X12 ### 1 - SYMAX5C **Models:** Syma X5C (original) and Syma X2 # Tiger ## Details **Protocol Number:** 61\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes {% hint style="danger" %} Only one transmitter ID is currently available for this protocol - take care that another MULTI-Module using the same protocol is not in range at the same time. {% endhint %} ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | | --- | --- | --- | --- | ---- | ----- | | A | E | T | R | Flip | Light | # Traxxas ## Details **Protocol Number:** 43\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes **Model:** Receiver 6519 ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | | ----- | ----- | -------- | -------- | | Aux 3 | Aux 4 | Throttle | Steering | # V2x2 ## Details **Protocol Number:** 5\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes None. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | CH11 | | --- | --- | --- | --- | ---- | ----- | ------- | ----- | -------- | ----------- | ----------- | | A | E | T | R | Flip | Light | Picture | Video | Headless | Mag. Cal. X | Mag. Cal. Y | ## Sub Protocols ### 0 - V2x2 **Models:** WLToys V202/252/272, JXD 385/388, JJRC H6C, Yizhan Tarantula X6 ... **Picture:** Also automatic Missile Launcher and Hoist in one direction\ **Video:** Also Sprayer, Bubbler, Missile Launcher(1), and Hoist in the other direction ### 1 - JXD506 **Model:** JXD 506\ **Channels:** * **CH10** = Start / Stop * **CH11** = Emergency * **CH12** = Camera up / down # V761 ## Details **Protocol Number:** 48\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes **Models:** Volantex V761, Eachine Mini P51D, Eachine Mini F4U, ... **Gyro: -**100% = Beginner Mode (Gyro on, yaw and pitch rate limited); 0% = Mid Mode (Gyro on no rate limits); +100% = Expert Mode (Gyro off) **Calibration:** Momentary switch; Calibration initiated when channel goes from -100% to +100% **Flip:** Momentary switch; Hold flip (+100%), indicate flip direction with Ele or Ail, release flip (-100%) **RTN\_ACT and RTN:** -100% = Disable; +100% = Enable ## Sub Protocols ### 0 - 3CH **Models:** Volantex V761-1, V761-3, and maybe others | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | | --- | --- | --- | --- | ---- | ----------- | ---- | -------- | --- | | - | E | T | R | Gyro | Calibration | Flip | RTN\_ACT | RTN | ### 1 - 4CH **Models:** Volantex V761-4+ and Eachine P51-D, F4U, F22 and maybe others | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | | --- | --- | --- | --- | ---- | ----------- | ---- | -------- | --- | | A | E | T | R | Gyro | Calibration | Flip | RTN\_ACT | RTN | # V911S ## Details **Protocol Number:** 46\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** Emulation mode and frequency fine tuning (see notes) ## Notes {% hint style="warning" %} This protocol is known to be problematic. This is due to the emulation of the original radio's RF component. {% endhint %} If the model does not respond well to inputs, or is hard to bind, you can try to switch the emulation mode by using an option value (RF Freq. tuning) other than 0. Once the value is not set to 0 it is used for frequency fine tuning. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | | --- | --- | --- | --- | --------- | | A | E | T | R | Calibrate | ## Sub Protocols ### 0 - **V911S** **Models:** WLtoys V911S; XK A110 ### 1 - E119 **Model:** Eachine E119
# WFly ## Details **Protocol Number:** 40\ **Autobind:** No\ **Channel Re-mapping:** No\ **Extended Limits:** Yes\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** Number of channels, from four to nine. An invalid option will send nine channels. ## Notes **Models:** WFly receiver models WFR04S, WFR07S, WFR09S ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | # WFly 2 ## Details **Protocol Number:** 79\ **Autobind:** No\ **Channel Re-mapping:** No\ **Extended Limits:** Yes\ **Failsafe Support:** Yes\ **Receiver Match:** Yes\ **Telemetry:** Yes\ **Option Value:** 0 = WBUS; 1 = PPM\ **Firmware Version:** v1.3.1.92 ## Notes **Models:** WFly receiver models RF201S, RF206S, RF207S, RF209S Failsafe fully supported (value, hold and no pulse). Telemetry enabled for A1=RX\_Batt (Ratio 12.7), A2=Ext\_Batt (Ratio 12.7), RX RSSI, TX RSSI, TX LQI (100=all telem packets received...0=no telem packets). ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | # WK2x01 ## Details **Protocol Number:** 30\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** Yes\ **Failsafe Support:** Yes - WK2801 sub-protocol\ **Receiver Match:** Yes\ **Telemetry:** No\ **Option Value:** N/A ## Notes Sub-protocol choice roughly corresponds to the number of channels supported by the receiver, but many of the newer 6-channel receivers actually support the WK2801 protocol. It is recommended to try the WK2801 sub-protocol first when working with older Walkera models, before attempting the WK2601 or WK2401 mode, as the WK2801 is a superior protocol. The WK2801 protocol supports up to 8 channels. ## Sub Protocols ### 0 - WK2801 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | | --- | --- | --- | --- | --- | --- | --- | --- | | A | E | T | R | CH5 | CH6 | CH7 | CH8 | #### Serial Mode Binding * With the TX off, put the binding plug in and power on the RX (RX LED slow blink), then power it down and remove the binding plug. Receiver should now be in autobind mode. * Turn on the TX, set protocol = WK2X01, sub\_protocol = WK2801 with option=0, turn off the TX (TX is now in autobind mode). * Turn on RX (RX LED fast blink). * Turn on TX (RX LED solid, TX LED fast blink). * Wait for bind on the TX to complete (TX LED solid). * Make sure to set a uniq RX\_Num value for model match. * Change option to 1 to use the global ID. * Do not touch option/RX\_Num anymore. #### **PPM Mode Binding** * With the TX off, put the binding plug in and power on the RX (RX LED slow blink), then power it down and remove the binding plug. Receiver should now be in autobind mode. * Turn on RX (RX LED fast blink). * Turn the dial to the model number running protocol protocol WK2X01 and sub\_protocol WK2801 on the module. * Press the bind button and turn on the TX. TX is now in autobind mode. * Release bind button after 1 second: RX LED solid, TX LED fast blink. * Wait for bind on the TX to complete (TX LED solid). * Press the bind button for 1 second. TX/RX is now in fixed ID mode. * To verify that the TX is in fixed mode: power cycle the TX, the module LED should be solid ON (no blink). * Note: Autobind/fixed ID mode is linked to the RX\_Num number. Which means that you can have multiple dial numbers set to the same protocol with different RX\_Num and have different bind modes at the same time. It enables PPM users to get model match. ### 1 - WK2401 **Models:** WK2401 is used with older Walkera models. | CH1 | CH2 | CH3 | CH4 | | --- | --- | --- | --- | | A | E | T | R | ### 2 - W6\_5\_1 **Models:** WK2601 - 5+1 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | | --- | --- | --- | --- | ---- | -------- | ---- | | A | E | T | R | Gear | Disabled | Gyro | * Aileron, Elevator, Throttle, Rudder, and Gyro (CH7) are proportional * Gear (CH5) is binary * CH6 is disabled ### 3 - W6\_6\_1 **Models:** WK2601 6+1 {% hint style="danger" %} **This mode is highly experimental!** {% endhint %} | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | | --- | --- | --- | --- | ---- | ---------- | ---- | | A | E | T | R | Geal | Collective | Gyro | * Aileron, Elevator, Throttle, Rudder, Collective (CH6), and Gyro (CH7) are proportional * Gear (CH5) is binary ### 4 - W6\_HEL **Models:** WK2601 Heli | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | | --- | --- | --- | --- | ---- | ---------- | ---- | | A | E | T | R | Gear | Collective | Gyro | * Aileron, Elevator, Throttle, Rudder, and Gyro (CH7) are proportional * Gear (CH5) is binary * Collective (CH6) is linked to Throttle * If CH6 >= 0 the receiver will apply a 3D curve to the Throttle * If Ch6 < 0, the receiver will apply normal curves to the Throttle * The value of CH6 defines the ratio of Collective to Throttle * Option Value = maximum range of Collective servo ### 5 - W6HEL\_I Same as W6\_HEL, but with Collective inverted. # XK ## Details **Protocol Number:** 62\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** X450 emulation mode and frequency fine tuning (see sub-protocol notes) ## Notes **Models:** XK X450 (TX=X8) and X420/X520 (TX=X4) ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | CH10 | | --- | --- | --- | --- | ------------------------- | --------------------- | --------------------------- | ----- | ------- | ----- | | A | E | T | R |

Flight

modes

|

Take

off

|

Emergency

stop

| 3D/6G | Picture | Video | Flight modes: -100%=M-Mode, 0%=6G-Mode, +100%=V-Mode CH6-CH10 are momentary switches ## Sub Protocols ### 0 - X450 **Models:** XK X450 (TX=X8) {% hint style="warning" %} This sub-protocol is known to be problematic. This is due to the emulation of the original radio's RF component. {% endhint %} If the model does not respond well to inputs, or is hard to bind, you can try to switch the emulation mode by using an option value (RF Freq. tuning) other than 0. Once the value is not set to 0 it is used for frequency fine tuning. See the [Frequency Tuning page](/using-the-module/frequency-tuning) for more details. ### 1 - X420 (TX=X4) **Models:** XK X420/X520 **Models:** X420 & X520 # YD717 ## Details **Protocol Number:** 8\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes None. ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7 | CH8 | CH9 | | --- | --- | --- | --- | ---- | ----- | ------- | ----- | -------- | | A | E | T | R | Flip | Light | Picture | Video | Headless | ## Sub Protocols ### 0 - YD717 ### 1 - SKYWLKR ### 2 - SYMAX4 ### 3 - XINXUN ### 4 - NIHUI # ZSX ## Details **Protocol Number:** 52\ **Autobind:** Yes\ **Channel Re-mapping:** Yes\ **Extended Limits:** No\ **Failsafe Support:** No\ **Receiver Match:** No\ **Telemetry:** No\ **Option Value:** N/A ## Notes **Model:** JJRC ZSX-280 ## Channel Assignment | CH1 | CH2 | CH3 | CH4 | | --- | -------- | -------- | ----- | | - | Throttle | Steering | Light | # Firmware Updates MULTI-Module firmware is not the same as the radio firmware, and must be updated separately. MULTI-Module firmware updates are released regularly and updating the MULTI-Module firmware is quite straightforward. The latest firmware can be found on the MULTI-Module Downloads site: {% embed url="" %} ## Checking the Version The MULTI-Module firmware version can be checked by looking at the **Module Status** line in the Model Setup menu on the radio. ![Module Status showing V1.3.0.46](/files/-LxlLRODQMzEnzDRRYjk) {% hint style="info" %} After an OpenTX radio firmware update, the radio may tell you that there is newer MULTI-Module firmware available by flashing **Module update recommended** alternately with the version number in the Module Status. {% endhint %} Keeping your MULTI-Module firmware up to date is strongly recommended, as updates frequently add new features and address issues. ## Update Process In order to update your MULTI-Module you will need to download the appropriate firmware file and use one of three available methods to write the file to the module. {% hint style="success" %} Updating the MULTI-Module firmware will not affect receiver bindings - any receivers which are bound to the MULTI-Module will remain bound after the update. {% endhint %} **Step 1:** Download the appropriate firmware file for your MULTI-Module In every release there are many different firmware files, each built for slightly different radio or module configurations. See the [Firmware Files](/using-the-module/firmware-updates/firmware-files) page if you need help knowing which file to download. {% content-ref url="/pages/-LxNM9L5b-8gNAOTB5cO" %} [Firmware Files](/using-the-module/firmware-updates/firmware-files) {% endcontent-ref %} **Step 2:** Choose an update method to flash (write) the firmware file to your MULTI-Module There are three ways to update the firmware on your MULTI-Module. See the dedicated [Update Methods](/using-the-module/firmware-updates/update-methods) page to choose the right one for you. {% content-ref url="/pages/-LxNLqCLQ4614YC2KVBR" %} [Update Methods](/using-the-module/firmware-updates/update-methods) {% endcontent-ref %} ### # Firmware Files A number of firmware image files are compiled for every new MULTI-Module firmware release. Use the MULTI-Module Firmware Download site to download the correct file for your module: {% embed url="" %} ## Standard File Naming The standard firmware file names follow this pattern: `mm-[module type]-[sub type]-[channel order]-[firmware version].bin` The parts of the file name are explained below. ### Module Type Determines the type of MCU the firmware was built for: * avr - for older MULTI-Modules with an ATmega328p MCU * stm - for MULTI-Modules with an STM32 MCU * orangerx - for OrangeRX modules running MULTI-Module firmware * t18int - Jumper T18 radios with a 5-in-1 module * tlite5in1 - Jumper T-Lite radios with a 5-in-1 module {% hint style="info" %} If you don't know what module type you have, it is probably **stm**. {% endhint %} ### Sub Type For STM modules, the type of module or radio: * serial - standard firmware for OpenTX, EdgeTX, erSky, or other serial radios * 5in1 - DIY 5-in-1 modules * cc2500 - radios/modules which only have the CC2500 RF component * ppm - radios which use PPM Mode For AVR modules, the flash method used to update the firmware: * txflash - update from the radio * usbasp - update using the Arduino IDE and a USBasp ### Channel Order The Expected Channel Order for the firmware image. * aetr - expects to receive channel data in AETR order * reta - expects to receive channel data in RETA order * taer - expects to receive channel data in TAER order {% hint style="info" %} The default Expected Channel Order is **AETR**. {% endhint %} ### Firmware Version The version number of the firmware. ## Firmware File Examples Some examples to help select the correct firmware file: | Module Type | Radio Type | Channel Order | Firmware File | | ------------------------- | ------------------- | ------------- | ---------------------------------- | | Jumper JP4IN1-SE | OpenTX/EdgeTX/erSky | AETR | `mm-stm-serial-aetr-[version].bin` | | RaioMaster TX16S Internal | OpenTX/EdgeTX/erSky | TAER | `mm-stm-serial-taer-[version].bin` | | Jumper T18 | OpenTX/EdgeTX/erSky | AETR | `mm-stm-t18int-aetr-[version].bin` | ## Other Firmware Files A small number of files are compiled for debugging or development purposes. These files are only produced with AETR channel order. {% hint style="danger" %} These firmware files are not for general use and should only be used when testing. {% endhint %} ### Protocol Dumping Protocol Dumping firmware enables the radio to capture and decoding RF transmissions from other RC transmitters which use the common XN297 RF module. This can be used to reverse-engineer unknown protocols so that they can be added to the MULTI-Module. Captured data is displayed via serial output. Protocol Dumping firmware is named in this pattern: `mm-stm-xn297dump-[debugging type]-[firmware version].bin` {% hint style="info" %} Protocol Dumping firmware only includes the XN297L dumping protocol and cannot be used with any models or receivers. {% endhint %} See the Protocol Dumping page for more information: {% content-ref url="/pages/-Lwo9ryp\_\_pbT7w7emGT" %} [Protocol Dumping](/advanced-topics/protocol-dumping) {% endcontent-ref %} --- [Next Page](/llms-full.txt/1)