Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update readme and protocol detals with surface/air info #1034

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update readme and protocol detals with surface/air info #1034

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions Protocols_Details.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,7 @@ Here are detailed descriptions of every supported protocols (sorted by RF module
The Deviation project (on which this project was based) have a useful list of models and protocols [here](http://www.deviationtx.com/wiki/supported_models).

## Useful notes and definitions
- **Surface and air protocols** - As the list of supported protocols grows even the STM32 ARM microcontroller cannot hold all of the protocols. Firmware available from the [Multi-Module](https://downloads.multi-module.org) website has been split into two groups, surfae and air. You can check which protocols are included in each of these groups in the [Validate.h](Multiprotocol/Validate.h) source file.
- **Channel Order** - The channel order assumed in all the documentation is AETR. You can change this in the compilation settings or by using a precompiled firmware. The module will take whatever input channel order you have choosen and will rearrange them to match the output channel order required by the selected protocol.
- **Channel ranges** - A radio output of -100%..0%..+100% will match on the selected protocol -100%,0%,+100%. No convertion needs to be done.
- **Extended limits supported** - A channel range of -125%..+125% will be transmitted. Otherwise it will be truncated to -100%..+100%.
Expand Down
4 changes: 2 additions & 2 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -100,9 +100,9 @@ For example, if you have no interest in binding your Tx to an model with and FrS

## **Choice 3:** Which protocols to upload to the MULTI-Module

In the case of the ATmega328, the memory required by all the possible protocols exceeds the 32KB flash limit considerably. This means that you will need to make a choice of which protocols you will compile into your firmware. Fortunately, the process of selecting and compiling is not too difficult and it is fully documented on the [Compiling and Programming](docs/Compiling.md) page.
As the list of supported protocols grows even the STM32 ARM microcontroller cannot hold all of the protocols. You can select the protocols you need and complie your own firmware. Fortunately, the process of selecting and compiling is not too difficult and it is fully documented on the [Compiling and Programming](docs/Compiling.md) page. You can also download firmware from the [Multi-Module](https://downloads.multi-module.org) website. These firmware files have been split into two groups, surfae and air. You can check which protocols are included in each of these groups in the [Validate.h](Multiprotocol/Validate.h) source file.

An alternative is to use a STM32 ARM microcontroller based module which can hold all the protocols.
In the case of the ATmega328, the memory required by all the possible protocols exceeds the 32KB flash limit considerably. This means that you will need to make a choice of which protocols you will compile into your firmware.

## **Choice 4:** Choosing the type of interface between the MULTI-Module and your radio (PPM or Serial)

Expand Down