Mirror/betaflight
1
0
Fork 0
mirror of https://github.com/betaflight/betaflight.git synced 2025-07-13 03:20:00 +03:00
Code Issues Wiki Activity

Remove docs and fix links (#12222)

Browse source
This commit is contained in:
Mark Haslinghuis 2023-01-25 09:34:17 +01:00 • committed by GitHub
parent b1433123c5
commit 2634c3ab37
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
509 changed files with 6 additions and 16389 deletions
Download patch file Download diff file Expand all files Collapse all files

2
CONTRIBUTING.md
View file

@ -10,4 +10,4 @@ Please search for existing issues *before* creating new ones.
# Developers
Please refer to the development section in the [this folder](https://github.com/betaflight/betaflight/tree/master/docs/development).
Please refer to the development section in the [this folder](https://betaflight.com/docs/development).

10
README.md
View file

@ -19,11 +19,11 @@ This fork differs from Baseflight and Cleanflight in that it focuses on flight p
The following new requirements for pull requests adding new targets or modifying existing targets are put in place from now on:
1. Read the [hardware specification](https://github.com/betaflight/betaflight/blob/master/docs/Manufacturer%20Design%20Guidelines.md)
1. Read the [hardware specification](https://betaflight.com/docs/manufacturer/Manufacturer%20Design%20Guidelines)
2. No new F3 based targets will be accepted;
3. For any new target that is to be added, only a Unified Target config into https://github.com/betaflight/unified-targets/tree/master/configs/default needs to be submitted. See the [instructions](https://github.com/betaflight/betaflight/blob/master/docs/TargetMaintenance/CreatingAUnifiedTarget.md) for how to create a Unified Target configuration. If there is no Unified Target for the MCU type of the new target (see instructions above), then a 'legacy' format target definition into `src/main/target/` has to be submitted as well;
3. For any new target that is to be added, only a Unified Target config into https://github.com/betaflight/unified-targets/tree/master/configs/default needs to be submitted. See the [instructions](https://betaflight.com/docs/manufacturer/Creating%20An%20Unified%20Target) for how to create a Unified Target configuration. If there is no Unified Target for the MCU type of the new target (see instructions above), then a 'legacy' format target definition into `src/main/target/` has to be submitted as well;
4. For changes to existing targets, the change needs to be applied to the Unified Target config in https://github.com/betaflight/unified-targets/tree/master/configs/default. If no Unified Target configuration for the target exists, a new Unified Target configuration will have to be created and submitted. If there is no Unified Target for the MCU type of the new target (see instructions above), then an update to the 'legacy' format target definition in `src/main/target/` has to be submitted alongside the update to the Unified Target configuration.
@ -50,7 +50,7 @@ Betaflight has the following features:
## Installation & Documentation
See: https://github.com/betaflight/betaflight/wiki
See: https://betaflight.com/docs/wiki
## Support and Developers Channel
@ -81,7 +81,7 @@ Contributions are welcome and encouraged. You can contribute in many ways:
* new feature ideas & suggestions;
* provide a new translation for configurator, or help us maintain the existing ones (see [below](#Translators)).
The best place to start is the Betaflight Slack (registration [here](https://slack.betaflight.com/)). Next place is the github issue tracker:
The best place to start is the Betaflight Discord (registration [here](https://discord.gg/n4E6ak4u3c)). Next place is the github issue tracker:
https://github.com/betaflight/betaflight/issues
https://github.com/betaflight/betaflight-configurator/issues
@ -95,7 +95,7 @@ If you want to contribute financially on an ongoing basis, you should consider b
## Developers
Contribution of bugfixes and new features is encouraged. Please be aware that we have a thorough review process for pull requests, and be prepared to explain what you want to achieve with your pull request.
Before starting to write code, please read our [development guidelines](docs/development/Development.md ) and [coding style definition](docs/development/CodingStyle.md).
Before starting to write code, please read our [development guidelines](https://betaflight.com/docs/development/development) and [coding style definition](https://betaflight.com/docs/development/development/CodingStyle).
GitHub actions are used to run automatic builds

60
build_docs.sh
View file

@ -1,60 +0,0 @@
#!/bin/bash
filename=Manual
doc_files=(
'Introduction.md'
'Getting Started.md'
'Safety.md'
'Installation.md'
'Configuration.md'
'Cli.md'
'Serial.md'
'Rx.md'
'Spektrum bind.md'
'Failsafe.md'
'Battery.md'
'Gps.md'
'Rssi.md'
'Telemetry.md'
'LedStrip.md'
'Display.md'
'Buzzer.md'
'Sonar.md'
'Profiles.md'
'Modes.md'
'Inflight Adjustments.md'
'Controls.md'
'Autotune.md'
'Blackbox.md'
'Migrating from baseflight.md'
'Boards.md'
'Board - AlienFlight.md'
'Board - CC3D.md'
'Board - CJMCU.md'
'Board - Naze32.md'
'Board - Sparky.md'
'Board - Olimexino.md'
'Board - ChebuzzF3.md'
)
if which gimli >/dev/null; then
echo "Building ${filename}.pdf"
pushd . >/dev/null
cd docs
rm -f ${filename}.md
for i in "${doc_files[@]}"
do
cat "$i" >> ${filename}.md
done
rm -f ${filename}.pdf
gimli -f ${filename}.md -stylesheet override.css \
-w '--toc --title "Cleanflight Manual" --footer-right "[page]" --toc-depth 1'
rm ${filename}.md
popd >/dev/null
else
echo -e "\nFAILED"
echo "Install Gimli to build the PDF documentation"
echo -e "https://github.com/walle/gimli\n"
exit 1
fi

163
docs/API/BusDrivers.md
View file

@ -1,163 +0,0 @@
# Bus and External Device Drivers
Betaflight makes a distinction between external devices and the bus on which they reside. For example each type of gyro will have a device driver which understands the register map of the gyro, and accesses to those registers will be made via a bus driver, either I2C or SPI. A device instance is represented by a `extDevice_t` structure which references a `busDevice_t` structure corresponding to the bus instance via which the device is accesses.
## Bus Agnostic Device Access Routines
There are a common set of device access functions which are bus agnostic. In each case the device instance handle `dev` is passed to indicate the device to access, and from this the appropriate bus instance is selected.
### Access routines where the register is accessed directly
These write routines do not mask the value in `reg`.
```
bool busRawWriteRegister(const extDevice_t *dev, uint8_t reg, uint8_t data);
```
Write the value `data` to the register offset `reg`.
```
bool busRawWriteRegisterStart(const extDevice_t *dev, uint8_t reg, uint8_t data);
```
Write the value `data` to the register offset `reg`. If the device is on an I2C bus this call is non-blocking and merely starts the access, hence the name suffix, but care should be taken not to call this a second time before the first access has completed.
```
bool busRawReadRegisterBuffer(const extDevice_t *dev, uint8_t reg, uint8_t *data, uint8_t length);
```
Read `length` bytes into the buffer at `*data` from the register offset `reg`.
```
bool busRawReadRegisterBufferStart(const extDevice_t *dev, uint8_t reg, uint8_t *data, uint8_t length);
```
Read `length` bytes into the buffer at `*data` from the register offset `reg`. If the device is on an I2C bus this call is non-blocking and merely starts the access, hence the name suffix.
### Write routines where the register number is masked with `0x7f`
It is common to indicate a read from an SPI register by setting but 7 (`0x80`) of the register number. There are therefore a number of routines which clear this bit to indicate a write. I2C register addresses are only 7 bits with an explicit read/write bit.
```
bool busWriteRegister(const extDevice_t *dev, uint8_t reg, uint8_t data);
```
Write the value `data` to the register offset `reg` logically anded with `0x7f`.
```
bool busWriteRegisterStart(const extDevice_t *dev, uint8_t reg, uint8_t data);
```
Write the value `data` to the register offset `reg` logically anded with `0x7f`. If the device is on an I2C bus this call is non-blocking and merely starts the access, hence the name suffix.
### Read routines where the register is ORed with `0x80`
It is common to indicate a read from an SPI register by setting but 7 (`0x80`) of the register number. There are therefore a number of routines which set this bit to indicate a read. I2C register addresses are only 7 bits with an explicit read/write bit.
```
uint8_t busReadRegister(const extDevice_t *dev, uint8_t reg);
```
Read a single byte from the register offset `reg` logically anded with `0x80`.
```
bool busReadRegisterBuffer(const extDevice_t *dev, uint8_t reg, uint8_t *data, uint8_t length);
```
Read `length` bytes into the buffer at `*data` from the register offset `reg` logically anded with `0x80`.
```
bool busReadRegisterBufferStart(const extDevice_t *dev, uint8_t reg, uint8_t *data, uint8_t length);
```
Read `length` bytes into the buffer at `*data` from the register offset `reg` logically anded with `0x80`. If the device is on an I2C bus this call is non-blocking and merely starts the access, hence the name suffix.
## I2C Specific Access
I2C bus accesses are slow and therefore, except during startup device initialisation, the use of blocking accesses should be avoided. Therefore the `bus...Start()` routines should be used which use interrupts to handle the transfer in the background. The barometer driver is a good example of how I2C devices accesses should be performed, with a state machine used so that accesses are started in one state, and the processing of the result of a read, or launching the next write waits until the next state.
It is necessary to register a device as being on an I2C bus in order that it can be accessed.
```
bool i2cBusSetInstance(const extDevice_t *dev, uint32_t device);
```
This registers the external device `dev` with an I2C bus device instance `device`.
```
void i2cBusDeviceRegister(const extDevice_t *dev);
```
A call to `i2cBusDeviceRegister` simply increments a count of the number of I2C devices in use.
## SPI Specific Access
SPI attached devices are accessed at higher speed and therefore may be accessed using blocking read/writes, however longer transfers or accesses requiring multiple transfers are better performed using DMA transfers under interrupt control.
There are a number of SPI specific bus access routines to facilitate such optimisation.
As with I2C it is possible to have multiple devices share a common SPI bus.
It is necessary to register a device as being on an SPI bus in order that it can be accessed.
```
bool spiSetBusInstance(extDevice_t *dev, uint32_t device);
```
This registers the external device `dev` with an SPI bus device instance `device`.
```
void spiSetClkDivisor(const extDevice_t *dev, uint16_t divider);
```
Each device on an SPI bus can use a different SPI bus clock speed and this sets the clock divisor to be used for accesses by the given device.
Two utility routines are provided to determine the `divider` value to use in order to achieve a max SPI clock speed, and to return the actual clock speed corresponding to that divisor.
```
// Determine the divisor to use for a given bus frequency
uint16_t spiCalculateDivider(uint32_t freq);
// Return the SPI clock based on the given divisor
uint32_t spiCalculateClock(uint16_t spiClkDivisor);
```
Access to SPI devices requires that the clock phase/polarity be set appropriately. See [https://en.wikipedia.org/wiki/Serial_Peripheral_Interface](https://en.wikipedia.org/wiki/Serial_Peripheral_Interface).
```
void spiSetClkPhasePolarity(const extDevice_t *dev, bool leadingEdge);
```
If `leadingEdge` is set to true, the default, then data will be clocked on the first rising edge of the clock, or if false, on the second falling edge.
```
void spiDmaEnable(const extDevice_t *dev, bool enable);
```
Certain devices, such as the CC2500 cannot handle the timing of sequential accesses which are being DMAed, so this enables DMA to be enabled (default) or disabled on a per device basis.
In order to support efficient use of SPI it is possible to perform not only single accesses as described above, but also to define a sequence of transfers using an array of `busSegment_t` elements which then comprise a complete transaction. These may be complex, support polling bus status for example before performing a write.
Each `busSegment_t` element passes a union of either a pair of buffer pointers for write/read respectively, a null link structure used to terminate the list. Following is the number of bytes in the transfer, a boolean, `negateCS`, indicating if the SPI CS line should be negated at the end of the segment, and an optional callback routine.
A good example of this is in `m25p16_readBytes()` where a segment list is defined thus:
```
busSegment_t segments[] = {
{.u.buffers = {readStatus, readyStatus}, sizeof(readStatus), true, m25p16_callbackReady},
{.u.buffers = {readBytes, NULL}, fdevice->isLargeFlash ? 5 : 4, false, NULL},
{.u.buffers = {NULL, buffer}, length, true, NULL},
{.u.link = {NULL, NULL}, 0, true, NULL},
};
```
In the above example the busy status of the FLASH memory is polled in the first element and then `m25p16_callbackReady()` is called which checks the read status. If the device is busy the value `BUS_BUSY` is returned and the element will be repeated under interrupt/DMA control. If the device is ready to accept a new command then `BUS_READY` is returned and the next element is processed. `BUS_ABORT` may also be returned in abort the whole transaction, although this is not currently used.
It can be faster to perform short transfers using polled access rather than setting up DMAs and the rules are as follows to determine if DMA should be use.
1. DMA is enabled on the bus and device
2. All transmit/receive buffers are in memory supporting DMAs
3. One of the following:
1. There are are at least `SPI_DMA_THRESHOLD` bytes to transfer
2. There is more than a single element in the segment list
3. The `negateCS` boolean is set to `false` in the terminating entry of the list.
The ELRS driver in `rx_sx1280.c` is an example of 3.3 where the terminating link has `negateCS` set to `false`. This then ensures that all accesses run in the background without blocking.
```
void spiSequence(const extDevice_t *dev, busSegment_t *segments);
```
This routine queues the given segment list for processing. If the device's bus is already busy then this segment list will be linked to the preceeding one in the queue so that the accesses will automatically proceed one after the other as quickly as possible.
```
void spiWait(const extDevice_t *dev);
```
Block, waiting for completion of the indicated device's bus activity.
```
bool spiIsBusy(const extDevice_t *dev);
```
Return true if the device's bus is busy.

142
docs/API/DisplayPort.md
View file

@ -1,142 +0,0 @@
# DisplayPort MSP Extensions
Betaflight supports what is sometimes referred to as Canvas Mode whereby the OSD can send arbitrary character strings to be displayed at given screen coordinates.
## DisplayPort MSP commands
### MSP\_SET\_OSD\_CANVAS
The MSP\_SET\_OSD\_CANVAS command is sent by the VTX, or display device, to the FC to indicate the size of the canvas available to the DisplayPort rendering when in HD mode. HD mode, as is indicated by `vcd_video_system = HD` is automatically set on reception of this command.
| Command | Msg Id | Direction | Notes |
|---------|--------|-----------|-------|
| MSP\_SET\_OSD\_CANVAS | 188 | to FC | Sets the canvas size|
| Data | Type | Notes |
|------|------|-------|
| canvas_cols | uint8 | The number of columns |
| canvas_rows | uint8 | The number of rows |
```mermaid
sequenceDiagram
participant FC
participant VTX
FC->>VTX: MSP_DP_HEARTBEAT sent and detected
VTX->>FC: MSP_SET_OSD_CANVAS set rows/columns
FC->>VTX: MSP request success
```
### MSP\_OSD\_CANVAS
The MSP\_OSD\_CANVAS command is sent by the configurator to the FC to determine the size of the canvas available to the DisplayPort rendering when in HD mode. This is then used on the OSD tab to show the correct number of rows/columns when editing the OSD element positions.
| Command | Msg Id | Direction | Notes |
|---------|--------|-----------|-------|
| MSP\_OSD\_CANVAS | 189 | to FC | Gets the canvas size|
Response is two bytes.
| Data | Type | Notes |
|------|------|-------|
| canvas_cols | uint8 | The number of columns |
| canvas_rows | uint8 | The number of rows |
```mermaid
sequenceDiagram
participant FC
participant Configurator
participant Preview
Configurator->>FC: Configurator connects to FC
Configurator->>FC: MSP_OSD_CANVAS get rows/columns
Configurator->>Preview: OSD Preview pane resized
```
### MSP\_DISPLAYPORT
The MSP\_DISPLAYPORT command is sent by the FC to the display device/VTX to perform a DisplayPort operation.
| Command | Msg Id | Direction | Notes |
|---------|--------|-----------|-------|
| MSP\_DISPLAYPORT | 182 | from FC | DisplayPort specific commands follow |
One of the following sub-commands will then follow.
## DisplayPort sub-commands
#### MSP\_DP\_HEARTBEAT
| Command | Msg Id | Notes |
|---------|--------|-------|
| MSP\_DP\_HEARTBEAT | 0 | Prevent OSD Slave boards from displaying a 'disconnected' status |
#### MSP\_DP\_RELEASE
| Command | Msg Id | Notes |
|---------|--------|-------|
| MSP\_DP\_RELEASE | 1 | Clears the display and allows local rendering on the display device based on telemetry informtation etc. |
#### MSP\_DP\_CLEAR\_SCREEN
| Command | Msg Id | Notes |
|---------|--------|-------|
| MSP\_DP\_CLEAR\_SCREEN | 2 | Clear the display |
#### MSP\_DP\_WRITE\_STRING
| Command | Msg Id | Notes |
|---------|--------|-------|
| MSP\_DP\_WRITE\_STRING | 3 | Write a string |
| Data | Type | Notes |
|------|------|-------|
| row | uint8 | Row on which to position the first character of the string |
| column | uint8 | Column on which to position the first character of the string |
| attribute | uint8 | Byte indicating the font to use and if the text should flash |
| string | uint8 x n | NULL terminated string of up to 30 characters in length |
The `attribute` parameter is encoded thus.
| Field | Bits | Comment |
| ----- | ---- | ------- |
| Version | 7 | Must be 0 |
| DISPLAYPORT\_MSP\_ATTR\_BLINK | 6 | Set to have the display device automatically blink the string |
| Reserved | 2 - 5 | Must be 0 |
| Font number | 0 - 1 | Selects one of four fonts, each of 256 8 bit characters |
#### MSP\_DP\_DRAW\_SCREEN
| Command | Msg Id | Notes |
|---------|--------|-------|
| MSP\_DP\_DRAW\_SCREEN | 4 | Triggers the display of a frame after it has been cleared/rendered |
#### MSP\_DP\_OPTIONS
| Command | Msg Id | Notes |
|---------|--------|-------|
| MSP\_DP\_OPTIONS | 5 | Not used by Betaflight. Used by INAV and Ardupilot to set display resolution. |
#### MSP\_DP\_SYS
| Command | Msg Id | Notes |
|---------|--------|-------|
| MSP\_DP\_SYS | 6 | Display system element displayportSystemElement_e at given coordinates |
| Data | Type | Notes |
|------|------|-------|
| row | uint8 | Row on which to position the first character of the string |
| column | uint8 | Column on which to position the first character of the string |
| system_element | uint8 | System element to be rendered by the VTX/goggle/display device |
`system_element` will be one of the following as defined by `displayPortSystemElement_e `. Once one MSP\_DP\_SYS sub-command has been received by the VTX/goggle/display device then the default system elements should no longer be displayed in their default locations, but only explicitly as directed by this command. In this way, the default behaviour is as before, but as soon as any system element is explicitly positioned these OSD elements behave just like any other and can be called up is specific locations by any given OSD profile.
```
// System elements rendered by VTX or Goggles
typedef enum {
DISPLAYPORT_SYS_GOGGLE_VOLTAGE = 0,
DISPLAYPORT_SYS_VTX_VOLTAGE = 1,
DISPLAYPORT_SYS_BITRATE = 2,
DISPLAYPORT_SYS_DELAY = 3,
DISPLAYPORT_SYS_DISTANCE = 4,
DISPLAYPORT_SYS_LQ = 5,
DISPLAYPORT_SYS_GOGGLE_DVR = 6,
DISPLAYPORT_SYS_VTX_DVR = 7,
DISPLAYPORT_SYS_WARNINGS = 8,
DISPLAYPORT_SYS_VTX_TEMP = 9,
DISPLAYPORT_SYS_FAN_SPEED = 10,
DISPLAYPORT_SYS_COUNT,
} displayPortSystemElement_e;
```

186
docs/API/MSP_extensions.md
View file

@ -1,186 +0,0 @@
# MSP Extensions
Cleanflight includes a number of extensions to the MultiWii Serial Protocol (MSP). This document describes
those extensions in order that 3rd party tools may identify cleanflight firmware and react appropriately.
Issue the MSP_API_VERSION command to find out if the firmware supports them.
## Mode Ranges
### MSP\_MODE\_RANGES
The MSP\_MODE\_RANGES returns the current auxiliary mode settings from the flight controller. It should be invoked
before any modification is made to the configuration.
The message returns a group of 4 unsigned bytes for each 'slot' available in the flight controller. The number of
slots should be calculated from the size of the returned message.
| Command | Msg Id | Direction | Notes |
|---------|--------|-----------|-------|
| MSP\_MODE\_RANGES | 34 | to FC | Following this command, the FC returns a block of 4 bytes for each auxiliary mode 'slot'|
Unassigned slots have rangeStartStep == rangeEndStep. Each element contains the following fields.
| Data | Type | Notes |
|------|------|-------|
| permanentId | uint8 | See Modes.md for a definition of the permanent ids |
| auxChannelIndex | uint8 | The Aux switch number (indexed from 0) |
| rangeStartStep | uint8 | The start value for this element in 'blocks' of 25 where 0 == 900 and 48 == 2100 |
| rangeEndStep | uint8 | The end value for this element in 'blocks' of 25 where 0 == 900 and 48 == 2100 |
Thus, for a cleanflight firmware with 40 slots 160 bytes would be returned in response to MSP\_MODE\_RANGES.
### MSP\_MODE\_RANGES\_EXTRA
The MSP\_MODE\_RANGES\_EXTRA returns the extra mode setting parameters from the flight controller. It should be invoked
in conjunction with MSP\_MODE\_RANGES before any modification is made to the configuration.
The message returns the number of extra elements followed by a group of bytes for each 'slot' available in the flight
controller. The number of slots should be the same as for MSP\_MODE\_RANGES, calculated from the size of the returned
message and the number of bytes per group.
| Command | Msg Id | Direction | Notes |
|---------|--------|-----------|-------|
| MSP\_MODE\_RANGES\_EXTRA | 238 | to FC | Following this command, the FC returns a block of bytes for each auxiliary mode 'slot'|
The return message is prepended with the number of bytes per element (3 bytes). Each element contains the
following fields:
| Data | Type | Notes |
|------|------|-------|
| permanentId | uint8 | See Modes.md for a definition of the permanent ids |
| modeLogic | uint8 | 0 = Logic AND; 1 = Logic OR |
| linkedTo | uint8 | Permanent id to which this mode is linked. |
Thus, for a cleanflight firmware with 20 slots, 61 bytes (including prepended size) would be returned in response to
MSP\_MODE\_RANGES\_EXTRA.
### MSP\_SET\_MODE\_RANGE
The MSP\_SET\_MODE\_RANGE is used to inform the flight controller of
auxiliary mode settings. The client *must* return all auxiliary
elements, including those that have been disabled or are undefined, by
sending this message for all auxiliary slots.
| Command | Msg Id | Direction |
|---------|--------|-----------|
| MSP\_SET\_MODE\_RANGE | 35 | to FC |
| Data | Type | Notes |
|------|------|-------|
| sequence id | uint8 | A monotonically increasing ID, from 0 to the number of slots -1 |
| permanentId | uint8 | See Modes.md for a definition of the permanent ids |
| auxChannelIndex | uint8 | The Aux channel number (indexed from 0) |
| rangeStartStep | uint8 | The start value for this element in 'blocks' of 25 where 0 == 900 and 48 == 2100 |
| rangeEndStep | uint8 | The end value for this element in 'blocks' of 25 where 0 == 900 and 48 == 2100 |
### Implementation Notes
* The client should make no assumptions about the number of slots available. Rather, the number should be computed
from the size of the MSP\_MODE\_RANGES message divided by the size of the returned data element (4 bytes);
* The client should ensure that all changed items are returned to the flight controller, including those where a
switch or range has been disabled;
* A 'null' return, with all values other than the sequence id set to 0, must be made for all unused slots, up to
the maximum number of slots calculated from the initial message.
## Adjustment Ranges
### MSP\_ADJUSTMENT\_RANGES
The MSP\_ADJUSTMENT\_RANGES returns the current adjustment range settings from
the flight controller. It should be invoked before any modification is
made to the configuration.
The message returns a group of 6 unsigned bytes for each 'slot'
available in the flight controller. The number of slots should be
calculated from the size of the returned message.
| Command | Msg Id | Direction | Notes |
|---------|--------|-----------|-------|
| MSP\_ADJUSTMENT\_RANGES | 52 | to FC | Following this command, the FC returns a block of 6 bytes for each adjustment range 'slot'|
Unassigned slots have rangeStartStep == rangeEndStep. Each element contains the following fields.
| Data | Type | Notes |
|------|------|-------|
| adjustmentStateIndex | uint8 | See below |
| auxChannelIndex | uint8 | The Aux channel number (indexed from 0) used to activate the adjustment |
| rangeStartStep | uint8 | The start value for this element in 'blocks' of 25 where 0 == 900 and 48 == 2100 |
| rangeEndStep | uint8 | The end value for this element in 'blocks' of 25 where 0 == 900 and 48 == 2100 |
| adjustmentFunction | uint8 | See below |
| auxSwitchChannelIndex | uint8 | The Aux channel number used to perform the function (indexed from 0) |
Thus, for a cleanflight firmware with 12 slots 72 bytes would be returned in response to MSP\_ADJUSTMENT\_RANGES,
### MSP\_SET\_ADJUSTMENT\_RANGE
The MSP\_SET\_ADJUSTMENT\_RANGE is used to inform the flight controller of
adjustment range settings. The client *must* return all adjustment range
elements, including those that have been disabled or are undefined, by
sending this message for all adjustment range slots.
| Command | Msg Id | Direction |
|---------|--------|-----------|
| MSP\_SET\_ADJUSTMENT\_RANGE | 53 | to FC |
| Data | Type | Notes |
|------|------|-------|
| sequence id | uint8 | A monotonically increasing ID, from 0 to the number of slots -1 |
| adjustmentStateIndex | uint8 | See below |
| auxChannelIndex | uint8 | The Aux channel number (indexed from 0) |
| rangeStartStep | uint8 | The start value for this element in 'blocks' of 25 where 0 == 900 and 48 == 2100 |
| rangeEndStep | uint8 | The end value for this element in 'blocks' of 25 where 0 == 900 and 48 == 2100 |
| adjustmentFunction | uint8 | See below |
| auxSwitchChannelIndex | uint8 | The Aux channel number used to perform the function (indexed from 0) |
### MSP\_SET\_1WIRE
The MSP\_SET\_1WIRE is used to enable serial1wire passthrough
note: it would be ideal to disable this when armed
| Command | Msg Id | Direction |
|---------|--------|-----------|
| MSP\_SET\_1WIRE | 243 | to FC |
| Data | Type | Notes |
|------|------|-------|
| esc id | uint8 | A monotonically increasing ID, from 0 to the number of escs -1 |
#### AdjustmentIndex
The FC maintains internal state for each adjustmentStateIndex, currently 4 simultaneous adjustment states are maintained. Multiple adjustment ranges
can be configured to use the same state but care should be taken not to send multiple adjustment ranges that when active would confict.
e.g. Configuring two identical adjustment ranges using the same slot would conflict, but configuring two adjustment ranges that used
only one half of the possible channel range each but used the same adjustmentStateIndex would not conflict.
The FC does NOT check for conflicts.
#### AdjustmentFunction
There are many adjustments that can be made, the numbers of them and their use is found in the documentation of the cli `adjrange` command in the 'Inflight Adjustents' section.
### Implementation Notes
* The client should make no assumptions about the number of slots available. Rather, the number should be computed
from the size of the MSP\_ADJUSTMENT\_RANGES message divided by the size of the returned data element (6 bytes);
* The client should ensure that all changed items are returned to the flight controller, including those where a
switch or range has been disabled;
* A 'null' return, with all values except for the sequence id set to 0, must be made for all unused slots,
up to the maximum number of slots calculated from the initial message.
## Deprecated MSP
The following MSP commands are replaced by the MSP\_MODE\_RANGES and
MSP\_SET\_MODE\_RANGE extensions, and are not recognised by
cleanflight.
* MSP\_BOX
* MSP\_SET\_BOX
See also
--------
[Modes.md](../Modes.md) describes the user visible implementation for the cleanflight
modes extension.

226
docs/Battery.md
View file

@ -1,226 +0,0 @@
# Battery Monitoring
Betaflight has a battery monitoring feature. The voltage of the main battery can be measured by the system and used to trigger a low-battery warning [buzzer](Buzzer.md), on-board status LED flashing and LED strip patterns.
Low battery warnings can:
* Help ensure you have time to safely land the aircraft
* Help maintain the life and safety of your LiPo/LiFe batteries, which should not be discharged below manufacturer recommendations
Minimum and maximum cell voltages can be set, and these voltages are used to auto-detect the number of cells in the battery when it is first connected.
Per-cell monitoring is not supported, as we only use one ADC to read the battery voltage.
## Supported targets
All targets support battery voltage monitoring unless status.
## Connections
When dealing with batteries **ALWAYS CHECK POLARITY!**
Measure expected voltages **first** and then connect to the flight controller. Powering the flight controller with
incorrect voltage or reversed polarity will likely fry your flight controller. Ensure your flight controller
has a voltage divider capable of measuring your particular battery voltage.
### Naze32
The Naze32 has an on-board battery divider circuit; just connect your main battery to the VBAT connector.
**CAUTION:** When installing the connection from main battery to the VBAT connector, be sure to first disconnect the main battery from the frame/power distribution board. Check the wiring very carefully before connecting battery again. Incorrect connections can immediately and completely destroy the flight controller and connected peripherals (ESC, GPS, Receiver etc.).
### CC3D
The CC3D has no battery divider. To use voltage monitoring, you must create a divider that gives a 3.3v
MAXIMUM output when the main battery is fully charged. Connect the divider output to S5_IN/PA0/RC5.
Notes:
* S5_IN/PA0/RC5 is Pin 7 on the 8 pin connector, second to last pin, on the opposite end from the
GND/+5/PPM signal input.
* When battery monitoring is enabled on the CC3D, RC5 can no-longer be used for PWM input.
### Sparky
See the [Sparky board chapter](boards/Board%20-%20Sparky.md).
## Configuration
Enable the `VBAT` feature.
Configure min/max cell voltages using the following CLI setting:
`vbat_scale` - Adjust this to match actual measured battery voltage to reported value (which may be displayed via the `status` command)
`vbat_max_cell_voltage` - Maximum voltage per cell, used for auto-detecting battery voltage in 0.01V units, i.e. 430 = 4.3V
`vbat_min_cell_voltage` - Minimum voltage per cell; this triggers battery-critical alarms, in 0.01V units, i.e. 330 = 3.3V
`vbat_warning_cell_voltage` - Warning voltage per cell; this triggers battery-warning alarms, in 0.01V units, i.e. 340 = 3.4V
`vbat_hysteresis` - Sets the hysteresis value for low-battery alarms, in 0.01V units, i.e. 10 = 0.10V
`vbat_duration_for_warning` - Period voltage has to sustain before the battery state is set to battery-warning, in 0.1 s, i.e. 60 = 6.0 seconds
`vbat_duration_for_critical` - Period voltage has to sustain before the battery state is set to battery-critical, in 0.1 s, i.e. 21 = 2.1 seconds
e.g.
```
set vbat_scale = 110
set vbat_max_cell_voltage = 430
set vbat_min_cell_voltage = 330
set vbat_warning_cell_voltage = 340
set vbat_hysteresis = 1
set vbat_duration_for_warning = 60
set vbat_duration_for_critical = 20
```
# Current Monitoring
Current monitoring (amperage) is supported by connecting a current meter to the appropriate current meter ADC input (see the documentation for your particular board).
When enabled, the following values calculated and used by the telemetry and OLED display subsystems:
* Amps
* mAh used
* Capacity remaining
## Configuration
Enable current monitoring using the CLI command:
```
feature CURRENT_METER
```
Configure the current meter type using the `amperage_meter_type` settings here:
| Value | Sensor Type |
| ------- | ---------------------- |
| NONE | None |
| ADC | ADC/hardware sensor |
| VIRTUAL | Virtual sensor |
Configure capacity using the `bat_capacity` setting, in mAh units.
If you're using an OSD that expects the multiwii current meter output value, then set `multiwii_amperage_meter_output` to `ON` (this multiplies amperage sent to MSP by 10 and truncates negative values)).
### ADC Sensor
The current meter needs to be configured so the value read at the Analog to Digital Converter (ADC) input matches actual current draw. Just like you need a voltmeter to correctly calibrate your voltage reading you also need an ammeter to calibrate the current sensor.
Unlike voltage sensing which is usually quite good from the factory, current sensing varies significantly from board to board and should be calibrated.
It is recommended to set `multiwii_amperage_meter_output` to `OFF` when calibrating ADC current sensor.
To measure the current a linear response device is used that converts the current traveling through it to a voltage to be read by the ADC on your flight controller.
The maximum voltage that the flight controller can read is 3.3V (3300 mV), this is usually the limiting factor on the maximum measurable current.
Most sensors use a shunt resistor to measure current however there are a few that use hall effect sensors.
The flight controller uses the following equation to convert the measured ADC voltage to a current.
```
Current(Amps) = ADC (mV) / amperage_meter_scale * 10 + amperage_meter_offset / 1000
```
Where the calibrations are:
| Setting | Description |
| ----------------------------- | -------------------------------------------------------- |
| `amperage_meter_scale` | The scaling factor in mV/10A |
| `amperage_meter_offset` | The offset in mA |
This is in the mathematical form of y = x/m + b and with a few measurements along this line you can calibrate any combination of sensor and flight controller to a high accuracy.
#### Calibrate using an ammeter
**!!Important: Always take off your props before doing any testing!!**
To calibrate your flight controller with a current meter follow these steps.
1. Make a copy of [this google sheet](https://docs.google.com/spreadsheets/d/1lkL-X_FT9x2oqrwQEctDsEUhgdY19upNGc78M6FfJXY/). It will do all the math for you.
2. Hook your ammeter up in series with your drone and a charged battery. I suggest an XT60 extender with one lead cut. Now your ammeter will be displaying the true current draw of your system.
3. Connect to your flight controller through the configurator and check your current calibrations. Change them in the google sheet if needed.
4. Use the motor tab to increase the throttle and change the current draw of the drone to around 1 A on the ammeter (it does not matter if it is not exact).
5. Switch back to the power and battery tab and record current from the ammeter in the measured current column and the current reported by Betaflight in the flight controller current column (both in amps, to 2 decimal places).
6. Repeat this measurement (steps 4 and 5) 3 or more times at various currents from 0 to 5 Amps (make sure not to go over your ammeter rated current).
7. Once this is done make sure the results are linear on the graph and that the regression value is green. You can now update to the new calibration values and enjoy accurate battery usage information.
The same method can be applied to both hall effect sensors and shunt resistors. Shunt resistors will usually have an offset of less than +/- 1000 mA however hall effect sensors offsets will be much higher.
Note that while your calibration may be correct there is still a maximum current measure that you may exceed at maximum throttle, this will cause the current recorded by the flight controller to ceiling at this value even if the actual current is higher.
As a result the reported mAh used may be less than is actually used, always keep an eye on the battery voltage as well.
If you do not want to use google sheets then simply use some other tool that preforms a linear regression on the dataset. Multiply `amperage_meter_scale` used in testing by the slope and subtract the intercept in mA from `amperage_meter_offset` to get the corrected calibration values.
### Virtual Sensor
The virtual sensor uses the throttle position to calculate an estimated current value. This is useful when a real sensor is not available. The following settings adjust the virtual sensor calibration:
| Setting | Description |
| ----------------------------- | -------------------------------------------------------- |
| `amperage_meter_scale` | The throttle scaling factor [centiamps, i.e. 1/100th A] |
| `amperage_meter_offset` | The current at zero throttle (while disarmed) [centiamps, i.e. 1/100th A] |
There are two simple methods to tune these parameters: one uses a battery charger and another depends on actual current measurements.
#### Tuning Using Actual Current Measurements
If you know your craft's current draw (in Amperes) while disarmed (Imin) and at maximum throttle while armed (Imax), calculate the scaling factors as follows:
```
amperage_meter_scale = (Imax - Imin) * 100000 / (Tmax + (Tmax * Tmax / 50))
amperage_meter_offset = Imin * 100
```
Note: Tmax is maximum throttle offset (i.e. for `max_throttle` = 1850, Tmax = 1850 - 1000 = 850)
For example, assuming a maximum current of 34.2A, a minimum current of 2.8A, and a Tmax `max_throttle` = 1850:
```
amperage_meter_scale = (Imax - Imin) * 100000 / (Tmax + (Tmax * Tmax / 50))
= (34.2 - 2.8) * 100000 / (850 + (850 * 850 / 50))
= 205
amperage_meter_offset = Imin * 100 = 280
```
Measuring Imax requires a battery and an ESC that can both deliver and support max current for the duration of the measurement, so it's prone to big inaccuracies. Alternatively, current can be measured at a much lower throttle position and be taken into account in the calculations.
Following the previous example, if we measured an Ibench current of 6A at 30% of throttle (1255 in the motors tab because (0.3*(max_throttle-1000))+1000))
```
Tbench = Tmax * bench_throttle = 850 * 0.3 = 255
amperage_meter_scale = (Ibench - Imin) * 100000 / (Tbench + (Tbench * Tbench / 50))
= (6 - 2.8) * 100000 / (255 + (255 * 255 / 50))
= 205
amperage_meter_offset = Imin * 100 = 280
```
#### Tuning Using Battery Charger Measurement
If you cannot measure current draw directly, you can approximate it indirectly using your battery charger.
However, note it may be difficult to adjust `amperage_meter_offset` using this method unless you can
measure the actual current draw with the craft disarmed.
Note:
+ This method depends on the accuracy of your battery charger; results may vary.
+ If you add or replace equipment that changes the in-flight current draw (e.g. video transmitter,
camera, gimbal, motors, prop pitch/sizes, ESCs, etc.), you should recalibrate.
The general method is:
1. Fully charge your flight battery
2. Fly your craft, using >50% of your battery pack capacity (estimated)
3. Note Cleanflight's reported mAh drawn
4. Fully charge your flight battery again, noting the amount of mAh recharged
5. Adjust `amperage_meter_scale` to according to the formula given below
6. Repeat and test
Given (a) the mAh recharged and (b) the cleanflight reported mAh drawn, calculate a new `amperage_meter_scale` value as follows:
```
amperage_meter_scale = old_amperage_meter_scale * (mAh_recharged / cleanflight_reported_mAh_drawn)
```
For example, assuming:
+ An amount recharged of 1500 mAh
+ A Cleanflight reported current drawn of 2000 mAh
+ An existing `amperage_meter_scale` value of 400 (the default)
Then the updated `amperage_meter_scale` is:
```
amperage_meter_scale = old_amperage_meter_scale * (mAh_recharged / cleanflight_reported_mAh_drawn)
= 400 * (1500 / 2000)
= 300
```

322
docs/Blackbox.md
View file

@ -1,322 +0,0 @@
# Blackbox flight data recorder
![Rendered flight log frame](Screenshots/blackbox-screenshot-1.jpg)
## Introduction
This feature transmits your flight data information on every control loop iteration over a serial port to an external
logging device like an OpenLog to be recorded, to an onboard dataflash chip which is present on some flight controllers,
or to an onboard SD card socket.
After your flight, you can view the resulting logs using the interactive log viewer:
https://github.com/cleanflight/blackbox-log-viewer
You can also use the `blackbox_decode` tool to turn the logs into CSV files for analysis, or render your flight log as a
video using the `blackbox_render` tool. Those tools can be found in this repository:
https://github.com/cleanflight/blackbox-tools
## Logged data
The blackbox records flight data on every iteration of the flight control loop. It records the current time in
microseconds, P, I and D corrections for each axis, your RC command stick positions (after applying expo curves),
gyroscope data, accelerometer data (after your configured low-pass filtering), barometer and sonar readings, 3-axis
magnetometer readings, raw VBAT and current measurements, RSSI, and the command being sent to each motor speed
controller. This is all stored without any approximation or loss of precision, so even quite subtle problems should be
detectable from the fight data log.
GPS data is logged whenever new GPS data is available. Although the CSV decoder will decode this data, the video
renderer does not yet show any of the GPS information (this will be added later).
## Supported configurations
The maximum data rate that can be recorded to the flight log is fairly restricted, so anything that increases the load
can cause the flight log to drop frames and contain errors.
The Blackbox is typically used on tricopters and quadcopters. Although it will work on hexacopters and octocopters,
because these craft have more motors to record, they must transmit more data to the flight log. This can increase the
number of dropped frames. Although the browser-based log viewer supports hexacopters and octocopters, the command-line
`blackbox_render` tool currently only supports tri- and quadcopters.
Cleanflight's `looptime` setting decides how frequently an update is saved to the flight log. The default looptime on
Cleanflight is 3500. If you're using a looptime smaller than about 2400, you may experience some dropped frames due to
the high required data rate. In that case you will need to reduce the sampling rate in the Blackbox settings, or
increase your logger's baudrate to 250000. See the later section on configuring the Blackbox feature for details.
## Setting up logging
First, you must enable the Blackbox feature. In the [Cleanflight Configurator][] enter the Configuration tab,
tick the "BLACKBOX" feature at the bottom of the page, and click "Save and reboot"
Now you must decide which device to store your flight logs on. You can either transmit the log data over a serial port
to an external logging device like the [OpenLog serial data logger][] to be recorded to a microSDHC card, or if you have
a compatible flight controller you can store the logs on the onboard dataflash storage instead.
### OpenLog serial data logger
The OpenLog is a small logging device which attaches to your flight controller using a serial port and logs your
flights to a MicroSD card.
The OpenLog ships from SparkFun with standard "OpenLog 3" firmware installed. Although this original OpenLog firmware
will work with the Blackbox, in order to reduce the number of dropped frames it should be reflashed with the
higher performance [OpenLog Blackbox firmware][]. The special Blackbox variant of the OpenLog firmware also ensures that
the OpenLog is using Cleanflight compatible settings, and defaults to 115200 baud.
You can find the Blackbox version of the OpenLog firmware [here](https://github.com/cleanflight/blackbox-firmware),
along with instructions for installing it onto your OpenLog.
[OpenLog serial data logger]: https://www.sparkfun.com/products/9530
[OpenLog Blackbox firmware]: https://github.com/cleanflight/blackbox-firmware
#### microSDHC
Your choice of microSDHC card is very important to the performance of the system. The OpenLog relies on being able to
make many small writes to the card with minimal delay, which not every card is good at. A faster SD-card speed rating is
not a guarantee of better performance.
##### microSDHC cards known to have poor performance
- Generic 4GB Class 4 microSDHC card - the rate of missing frames is about 1%, and is concentrated around the most
interesting parts of the log!
- Sandisk Ultra 32GB (unlike the smaller 16GB version, this version has poor write latency)
##### microSDHC cards known to have good performance
- Transcend 16GB Class 10 UHS-I microSDHC (typical error rate < 0.1%)
- Sandisk Extreme 16GB Class 10 UHS-I microSDHC (typical error rate < 0.1%)
- Sandisk Ultra 16GB (it performs only half as well as the Extreme in theory, but still very good)
You should format any card you use with the [SD Association's special formatting tool][] , as it will give the OpenLog
the best chance of writing at high speed. You must format it with either FAT, or with FAT32 (recommended).
[SD Association's special formatting tool]: https://www.sdcard.org/downloads/formatter_4/
### Choosing a serial port for the OpenLog
First, tell the Blackbox to log using a serial port (rather than to an onboard dataflash chip). Go to the
Configurator's CLI tab, enter `set blackbox_device=SERIAL` to switch logging to serial, and
save.
You need to let Cleanflight know which of [your serial ports][] you connect your OpenLog to (i.e. the Blackbox port),
which you can do on the Configurator's Ports tab.
You should use a hardware serial port (such as UART1 on the Naze32, the two-pin Tx/Rx header in the center of the
board). SoftSerial ports can be used for the Blackbox. However, because they are limited to 19200 baud, your logging
rate will need to be severely reduced to compensate. Therefore the use of SoftSerial is not recommended.
When using a hardware serial port, Blackbox should be set to at least 115200 baud on that port. When using fast
looptimes (<2500), a baud rate of 250000 should be used instead in order to reduce dropped frames.
The serial port used for Blackbox cannot be shared with any other function (e.g. GPS, telemetry) except the MSP
protocol. If MSP is used on the same port as Blackbox, then MSP will be active when the board is disarmed, and Blackbox
will be active when the board is armed. This will mean that you can't use the Configurator or any other function that
requires MSP, such as an OSD or a Bluetooth wireless configuration app, while the board is armed.
Connect the "TX" pin of the serial port you've chosen to the OpenLog's "RXI" pin. Don't connect the serial port's RX
pin to the OpenLog, as this will cause the OpenLog to interfere with any shared functions on the serial port while
disarmed.
#### Naze32 serial port choices
On the Naze32, the TX/RX pins on top of the board are connected to UART1, and are shared with the USB connector.
Therefore, MSP must be enabled on UART1 in order to use the Configurator over USB. If Blackbox is connected to the pins
on top of the Naze32, the Configurator will stop working once the board is armed. This configuration is usually a good
choice if you don't already have an OSD installed which is using those pins while armed, and aren't using the FrSky
telemetry pins.
Pin RC3 on the side of the board is UART2's Tx pin. If Blackbox is configured on UART2, MSP can still be used on UART1
when the board is armed, which means that the Configurator will continue to work simultaneously with Blackbox logging.
Note that in `PARALLEL_PWM` mode this leaves the board with 6 input channels as RC3 and RC4 pins are used by UART2 as Tx and Rx. Cleanflight automatically shifts logical channel mapping for you when UART2 is enabled in `Ports` tab so you'll have to shift receiver pins that are connected to Naze32 pins 3 to 6 by two.
The OpenLog tolerates a power supply of between 3.3V and 12V. If you are powering your Naze32 with a standard 5V BEC,
then you can use a spare motor header's +5V and GND pins to power the OpenLog with.
#### Other flight controller hardware
Boards other than the Naze32 may have more accessible hardware serial devices, in which case refer to their
documentation to decide how to wire up the logger. The key criteria are:
* Should be a hardware serial port rather than SoftSerial.
* Cannot be shared with any other function (GPS, telemetry) except MSP.
* If MSP is used on the same UART, MSP will stop working when the board is armed.
#### OpenLog configuration
Power up the OpenLog with a microSD card inside, wait 10 seconds or so, then power it down and plug the microSD card
into your computer. You should find a "CONFIG.TXT" file on the card, open it up in a text editor. You should see the
baud rate that the OpenLog has been configured for (usually 115200 or 9600 from the factory). Set the baud rate to match
the rate you entered for the Blackbox in the Configurator's Port tab (typically 115200 or 250000).
Save the file and put the card back into your OpenLog, it will use those settings from now on.
If your OpenLog didn't write a CONFIG.TXT file, create a CONFIG.TXT file with these contents and store it in the root
of the MicroSD card:
```
115200
baud
```
If you are using the original OpenLog firmware, use this configuration instead:
```
115200,26,0,0,1,0,1
baud,escape,esc#,mode,verb,echo,ignoreRX
```
#### OpenLog protection
The OpenLog can be wrapped in black electrical tape or heat-shrink in order to insulate it from conductive frames (like
carbon fiber), but this makes its status LEDs impossible to see. I recommend wrapping it with some clear heatshrink
tubing instead.
![OpenLog installed](Wiring/blackbox-installation-1.jpg "OpenLog installed with double-sided tape, SDCard slot pointing outward")
### Onboard dataflash storage
Some flight controllers have an onboard SPI NOR dataflash chip which can be used to store flight logs instead of using
an OpenLog.
The full version of the Naze32 and the CC3D have an onboard "m25p16" 2 megabyte dataflash storage chip. This is a small
chip with 8 fat legs, which can be found at the base of the Naze32's direction arrow. This chip is not present on the
"Acro" version of the Naze32.
The SPRacingF3 has a larger 8 megabyte dataflash chip onboard which allows for longer recording times.
These chips are also supported:
* Micron/ST M25P16 - 16 Mbit / 2 MByte ([datasheet](http://www.micron.com/~/media/Documents/Products/Data%20Sheet/NOR%20Flash/Serial%20NOR/M25P/M25P16.pdf))
* Micron/ST N25Q064 - 64 Mbit / 8 MByte ([datasheet](http://www.micron.com/~/media/documents/products/data-sheet/nor-flash/serial-nor/n25q/n25q_64a_3v_65nm.pdf))
* Winbond W25Q64 - 64 Mbit / 8 MByte ([datasheet](http://www.winbond.com/resource-files/w25q64fv_revl1_100713.pdf))
* Macronix MX25L64 - 64 Mbit / 8 MByte ([datasheet](http://media.digikey.com/pdf/Data%20Sheets/Macronix/MX25L6406E.pdf))
* Micron/ST N25Q128 - 128 Mbit / 16 MByte ([datasheet](http://www.micron.com/~/media/Documents/Products/Data%20Sheet/NOR%20Flash/Serial%20NOR/N25Q/n25q_128mb_3v_65nm.pdf))
* Winbond W25Q128 - 128 Mbit / 16 MByte ([datasheet](http://www.winbond.com/resource-files/w25q128fv_revhh1_100913_website1.pdf))
#### Enable recording to dataflash
On the Configurator's CLI tab, you must enter `set blackbox_device=SPIFLASH` to switch to logging to an onboard dataflash chip,
then save.
[your serial ports]: https://github.com/cleanflight/cleanflight/blob/master/docs/Serial.md
[Cleanflight Configurator]: https://chrome.google.com/webstore/detail/cleanflight-configurator/enacoimjcgeinfnnnpajinjgmkahmfgb?hl=en
### Onboard SD card socket
Some flight controllers have an SD or Micro SD card socket on their circuit boards. This allows for very high speed
logging (1KHz or faster, which is a looptime of 1000 or lower) on suitable cards.
The card can be either Standard (SDSC) or High capacity (SDHC), and must be formatted with the FAT16 or FAT32
filesystems. This covers a range of card capacities from 1 to 32GB. Extended capacity cards (SDXC) are not supported.
The first time you power up Cleanflight with a new card inserted, the flight controller will spend a few seconds
scanning the disk for free space and collecting this space together into a file called "FREESPAC.E". During flight,
Cleanflight will carve chunks from this file to create new log files. You must not edit this file on your computer (i.e.
open it in a program and save changes) because this may cause it to become fragmented. Don't run any defragmentation
tools on the card either.
You can delete the FREESPAC.E file if you want to free up space on the card to fit non-Blackbox files (Cleanflight will
recreate the FREESPAC.E file next time it starts, using whatever free space was left over).
The maximum size of the FREESPAC.E file is currently 4GB. Once 4GB worth of logs have been recorded, the FREESPAC.E
file will be nearly empty and no more logs will be able to be recorded. At this point you should either delete the
FREESPAC.E file (and any logs left on the card to free up space), or just reformat the card. A new FREESPAC.E file
will be created by Cleanflight on its next boot.
#### Enable recording to SD card
On the Configurator's CLI tab, you must enter `set blackbox_device=SDCARD` to switch to logging to an onboard SD card,
then save.
## Configuring the Blackbox
The Blackbox currently provides two settings (`blackbox_rate_num` and `blackbox_rate_denom`) that allow you to control
the rate at which data is logged. These two together form a fraction (`blackbox_rate_num / blackbox_rate_denom`) which
decides what portion of the flight controller's control loop iterations should be logged. The default is 1/1 which logs
every iteration.
If you're using a slower MicroSD card, you may need to reduce your logging rate to reduce the number of corrupted
logged frames that `blackbox_decode` complains about. A rate of 1/2 is likely to work for most craft.
You can change the logging rate settings by entering the CLI tab in the [Cleanflight Configurator][] and using the `set`
command, like so:
```
set blackbox_rate_num = 1
set blackbox_rate_denom = 2
```
The data rate for my quadcopter using a looptime of 2400 and a rate of 1/1 is about 10.25kB/s. This allows about 18
days of flight logs to fit on my OpenLog's 16GB MicroSD card, which ought to be enough for anybody :).
If you are logging using SoftSerial, you will almost certainly need to reduce your logging rate to 1/32. Even at that
logging rate, looptimes faster than about 1000 cannot be successfully logged.
If you're logging to an onboard dataflash chip instead of an OpenLog, be aware that the 2MB of storage space it offers
is pretty small. At the default 1/1 logging rate, and a 2400 looptime, this is only enough for about 3 minutes of
flight. This could be long enough for you to investigate some flying problem with your craft, but you may want to reduce
the logging rate in order to extend your recording time.
To maximize your recording time, you could drop the rate all the way down to 1/32 (the smallest possible rate) which
would result in a logging rate of about 10-20Hz and about 650 bytes/second of data. At that logging rate, a 2MB
dataflash chip can store around 50 minutes of flight data, though the level of detail is severely reduced and you could
not diagnose flight problems like vibration or PID setting issues.
## Usage
The Blackbox starts recording data as soon as you arm your craft, and stops when you disarm.
If your craft has a buzzer attached, you can use Cleanflight's arming beep to synchronize your Blackbox log with your
flight video. Cleanflight's arming beep is a "long, short" pattern. The beginning of the first long beep will be shown
as a blue line in the flight data log, which you can sync against your recorded audio track.
You should wait a few seconds after disarming your craft to allow the Blackbox to finish saving its data.
### Usage - OpenLog
Each time the OpenLog is power-cycled, it begins a fresh new log file. If you arm and disarm several times without
cycling the power (recording several flights), those logs will be combined together into one file. The command line
tools will ask you to pick which one of these flights you want to display/decode.
Don't insert or remove the SD card while the OpenLog is powered up.
### Usage - Dataflash chip
After your flights, you can use the [Cleanflight Configurator][] to download the contents of the dataflash to your
computer. Go to the "dataflash" tab and click the "save flash to file..." button. Saving the log can take 2 or 3
minutes.
![Dataflash tab in Configurator](Screenshots/blackbox-dataflash.png)
After downloading the log, be sure to erase the chip to make it ready for reuse by clicking the "erase flash" button.
If you try to start recording a new flight when the dataflash is already full, Blackbox logging will be disabled and
nothing will be recorded.
### Usage - Onboard SD card socket
You must insert your SD card before powering on your flight controller. You can remove the SD card while the board is
powered up, but you must wait 5 seconds after disarming before you do so in order to give Cleanflight a chance to finish
saving your log (otherwise the filesystem may become corrupted).
Cleanflight will create a new log file in the "LOG" directory each time the craft is armed. If you are using a Blackbox
logging switch and you keep it paused for the entire flight, the resulting empty log file will be deleted after disarming.
To read your logs, you must remove the SD card and insert it into a card reader on your computer (Cleanflight doesn't
support reading these logs directly through the Configurator).
### Usage - Logging switch
If you're recording to an onboard flash chip, you probably want to disable Blackbox recording when not required in order
to save storage space. To do this, you can add a Blackbox flight mode to one of your AUX channels on the Configurator's
modes tab. Once you've added a mode, Blackbox will only log flight data when the mode is active.
A log header will always be recorded at arming time, even if logging is paused. You can freely pause and resume logging
while in flight.
## Viewing recorded logs
After your flights, you'll have a series of flight log files with a .TXT extension.
You can view these .TXT flight log files interactively using your web browser with the Cleanflight Blackbox Explorer:
https://github.com/cleanflight/blackbox-log-viewer
This allows you to scroll around a graphed version of your log and examine your log in detail. You can also export a
video of your log to share it with others!
You can decode your logs with the `blackbox_decode` tool to create CSV (comma-separated values) files for analysis,
or render them into a series of PNG frames with `blackbox_render` tool, which you could then convert into a video using
another software package.
You'll find those tools along with instructions for using them in this repository:
https://github.com/cleanflight/blackbox-tools

43
docs/Boards.md
View file

@ -1,43 +0,0 @@
# Flight controller hardware
The current focus is geared towards flight controller hardware that use the STM32F303 and legacy STM32F103 series processors. The core logic is separated from the hardware drivers, porting to other processors is possible.
If you want a fully featured version of Cleanflight then the recommendation for new purchases is an STM32 F3 based board with 256KB of flash memory. The F3 processor is faster, has built in USB support and supports more hardware without the need for additional adaptors and cables.
The core set of recommended boards are:
* [Seriously Pro SPRacingF3Mini](boards/Board%20-%20SPRacingF3MINI.md)
* [Seriously Pro SPRacingF3](boards/Board%20-%20SPRacingF3.md)
* [Seriously Pro SPRacingF3EVO](boards/Board%20-%20SPRacingF3EVO.md)
* [TBS Colibri Race](boards/Board%20-%20ColibriRace.md)
* [AlienFlightF3](boards/Board%20-%20AlienFlight.md)
* [TauLabs Sparky](boards/Board%20-%20Sparky.md)
The core set of legacy boards are:
* [AlienFlightF1](boards/Board%20-%20AlienFlight.md)
* [OpenPilot CC3D](boards/Board%20-%20CC3D.md)
* [CJMCU](boards/Board%20-%20CJMCU.md)
* Flip32+
* [AbuseMark Naze32](boards/Board%20-%20Naze32.md)
* [RMRC Dodo](boards/Board%20-%20RMDO.md)
Cleanflight also runs on the following developer boards:
* STM32F3Discovery - Recommended for developers.
* Port103R - Recommended for F1 developers.
There is also limited support for the following boards which may be removed due to lack of users or commercial availability.
* STM32F3Discovery with Chebuzz F3 shield.
NOTE: Users are advised against purhasing boards that have CPUs with less than 256KB of EEPROM space - available features may be limited.
NOTE: Hardware developers should not design new boards that have CPUs with less than 256KB EEPROM space.
Each board has it's pros and cons, before purchasing hardware the main thing to check is if the board offers enough serial ports and input/output pins for the hardware you want to use with it and that you can use them at the same time. On some boards some features are mutually exclusive.
Please see the board-specific chapters in the manual for wiring details.
There are off-shoots (forks) of the project that support the STM32F4 processors as found on the Revo and Quanton boards.
Where applicable the chapters also provide links to other hardware that is known to work with Cleanflight, such as receivers, buzzers, etc.

75
docs/Buzzer.md
View file

@ -1,75 +0,0 @@
# Buzzer
Cleanflight supports a buzzer which is used for the following purposes:
* Low and critical battery alarms (when battery monitoring enabled)
* Arm/disarm tones (and warning beeps while armed)
* Notification of calibration complete status
* TX-AUX operated beeping - useful for locating your aircraft after a crash
* Failsafe status
* Flight mode change
* Rate profile change (via TX-AUX switch)
If the arm/disarm is via the control stick, holding the stick in the disarm position will sound a repeating tone. This can be used as a lost-model locator.
Three beeps immediately after powering the board means that the gyroscope calibration has completed successfully. Cleanflight calibrates the gyro automatically upon every power-up. It is important that the copter stay still on the ground until the three beeps sound, so that gyro calibration isn't thrown off. If you move the copter significantly during calibration, Cleanflight will detect this, and will automatically re-start the calibration once the copter is still again. This will delay the "three beeps" tone. If you move the copter just a little bit, the gyro calibration may be incorrect, and the copter may not fly correctly. In this case, the gyro calibration can be performed manually via [stick command](Controls.md), or you may simply power cycle the board.
There is a special arming tone used if a GPS fix has been attained, and there's a "ready" tone sounded after a GPS fix has been attained (only happens once). The tone sounded via the TX-AUX-switch will count out the number of satellites (if GPS fix).
The CLI command `play_sound` is useful for demonstrating the buzzer tones. Repeatedly entering the command will play the various tones in turn. Entering the command with a numeric-index parameter (see below) will play the associated tone.
Buzzer is enabled by default on platforms that have buzzer connections.
## Tone sequences
Buzzer tone sequences (square wave generation) are made so that : 1st, 3rd, 5th, .. are the delays how long the beeper is on and 2nd, 4th, 6th, .. are the delays how long beeper is off. Delays are in milliseconds/10 (i.e., 5 => 50ms).
Sequences available in Cleanflight v1.9 and above are :
0 GYRO_CALIBRATED 20, 10, 20, 10, 20, 10 Gyro is calibrated
1 RX_LOST_LANDING 10, 10, 10, 10, 10, 40, 40, 10, 40, 10, 40, 40, 10, 10, 10, 10, 10, 70 SOS morse code
2 RX_LOST 50, 50 TX off or signal lost (repeats until TX is okay)
3 DISARMING 15, 5, 15, 5 Disarming the board
4 ARMING 30, 5, 5, 5 Arming the board
5 ARMING_GPS_FIX 5, 5, 15, 5, 5, 5, 15, 30 Arming and GPS has fix
6 BAT_CRIT_LOW 50, 2 Battery is critically low (repeats)
7 BAT_LOW 25, 50 Battery is getting low (repeats)
8 NULL multi beeps GPS status (sat count)
9 RX_SET 10, 10 RX is set (when aux channel is set for beep or beep sequence how many satellites has found if GPS enabled)
10 ACC_CALIBRATION 5, 5, 5, 5 ACC inflight calibration completed
11 ACC_CALIBRATION_FAIL 20, 15, 35, 5 ACC inflight calibration failed
12 READY_BEEP 4, 5, 4, 5, 8, 5, 15, 5, 8, 5, 4, 5, 4, 5 GPS locked and copter ready
13 NULL multi beeps Variable # of beeps (confirmation, GPS sat count, etc)
14 DISARM_REPEAT 0, 100, 10 Stick held in disarm position (after pause)
15 ARMED 0, 245, 10, 5 Board is armed (after pause ; repeats until board is disarmed or throttle is increased)
## Types of buzzer supported
The buzzers are enabled/disabled by simply enabling or disabling a GPIO output pin on the board.
This means the buzzer must be able to generate its own tone simply by having power applied to it.
Buzzers that need an analog or PWM signal do not work and will make clicking noises or no sound at all.
Examples of a known-working buzzers.
* [Hcm1205x Miniature Buzzer 5v](http://www.rapidonline.com/Audio-Visual/Hcm1205x-Miniature-Buzzer-5v-35-0055)
* [5V Electromagnetic Active Buzzer Continuous Beep](http://www.banggood.com/10Pcs-5V-Electromagnetic-Active-Buzzer-Continuous-Beep-Continuously-p-943524.html)
* [Radio Shack Model: 273-074 PC-BOARD 12VDC (3-16v) 70DB PIEZO BUZZER](http://www.radioshack.com/pc-board-12vdc-70db-piezo-buzzer/2730074.html#.VIAtpzHF_Si)
* [MultiComp MCKPX-G1205A-3700 TRANSDUCER, THRU-HOLE, 4V, 30MA](http://uk.farnell.com/multicomp/mckpx-g1205a-3700/transducer-thru-hole-4v-30ma/dp/2135914?CMP=i-bf9f-00001000)
* [3-24V Piezo Electronic Tone Buzzer Alarm 95DB](http://www.banggood.com/3-24V-Piezo-Electronic-Tone-Buzzer-Alarm-95DB-Continuous-Sound-p-919348.html)
## Connections
### Naze32
Connect a supported buzzer directly to the BUZZ pins. Observe polarity. Also if you are working with flight controller outside of a craft, on a bench for example, you need to supply 5 volts and ground to one of the ESC connections or the buzzer will not function.
### CC3D
Buzzer support on the CC3D requires that a buzzer circuit be created to which the input is PA15.
PA15 is unused and not connected according to the CC3D Revision A schematic.
Connecting to PA15 requires careful soldering.
See the [CC3D - buzzer circuit.pdf](Wiring/CC3D%20-%20buzzer%20circuit.pdf) for details.

36
docs/CLI/gyro_offset_yaw.md
View file

@ -1,36 +0,0 @@
# CLI parameter <gyro_offset_yaw>
## Introduction
This parameter allows to manually compensate YAW gyro drift over time.
## Audience
This parameter is intended for LOS flyers who use the HEADFREE feature of betaflight.
It reduces the usage of on sight realignment HEADADJ
from 3-6 times to 0-1 during a flight.
## Warnings
Users with exotic board alignment configurations !!! this feature may not work as intended for your purpose !!!
The gyro drift depends on many factors, so the results of manual calibration have a big variance
Factors:
* gyro (mpu6000 ICM260X ...)
* sampling rate
* temperature
* LiPo (3S ... 5S)
* Flight style
* Flight time
* and many more ...
## Setup
The basic setup can be done on the bench without LiPo, USB powered
power on, do not move the quad for 10 minutes
on CW drift 70° --> gyro_offset_yaw = 70
on CCW drift 70° --> gyro_offset_yaw = -70
This is only a coarse adjustment.
Fine tuning requires real flights and some fingertip.
Basically you have to measure the drift at the end of the flight,
and modify the parameter accordingly.
## Wishes
Happy flight !

286
docs/Cli.md
View file

@ -1,286 +0,0 @@
# Command Line Interface (CLI)
Cleanflight has a command line interface (CLI) that can be used to change settings and configure the FC.
## Accessing the CLI.
The CLI can be accessed via the GUI tool or via a terminal emulator connected to the CLI serial port.
1. Connect your terminal emulator to the CLI serial port (which, by default, is the same as the MSP serial port)
2. Use the baudrate specified by msp_baudrate (115200 by default).
3. Send a `#` character.
To save your settings type in 'save', saving will reboot the flight controller.
To exit the CLI without saving power off the flight controller or type in 'exit'.
To see a list of other commands type in 'help' and press return.
To dump your configuration (including the current profile), use the 'dump' command.
See the other documentation sections for details of the cli commands and settings that are available.
## Backup via CLI
Disconnect main power, connect to cli via USB/FTDI.
dump using cli
```
rateprofile 0
profile 0
dump
```
dump profiles using cli if you use them
```
profile 1
dump profile
profile 2
dump profile
```
dump rate profiles using cli if you use them
```
rateprofile 1
dump rates
rateprofile 2
dump rates
```
copy screen output to a file and save it.
## Restore via CLI.
Use the cli `defaults` command first.
When restoring from a backup it is a good idea to do a dump of the latest defaults so you know what has changed - if you do this each time a firmware release is created you will be able to see the cli changes between firmware versions. For instance, in December 2014 the default GPS navigation PIDs changed. If you blindly restore your backup you would not benefit from these new defaults.
Use the CLI and send all the output from the saved backup commands.
Do not send the file too fast, if you do the FC might not be able to keep up when using USART adapters (including built in ones) since there is no hardware serial flow control.
You may find you have to copy/paste a few lines at a time.
Repeat the backup process again!
Compare the two backups to make sure you are happy with your restored settings.
Re-apply any new defaults as desired.
## CLI Command Reference
Click on a command to jump to the relevant documentation page.
| `Command` | Description |
|-----------------------------------------|------------------------------------------------|
| `1wire <esc>` | passthrough 1wire to the specified ESC |
| [`adjrange`](Inflight%20Adjustments.md) | show/set adjustment ranges settings |
| [`aux`](Modes.md) | show/set aux settings |
| [`mmix`](Mixer.md) | design custom motor mixer |
| [`smix`](Mixer.md) | design custom servo mixer |
| [`color`](LedStrip.md) | configure colors |
| `defaults` | reset to defaults and reboot |
| `dump` | print configurable settings in a pastable form |
| `dma` | configure direct memory access channel |
| `exit` | |
| `feature` | list or -val or val |
| `get` | get variable value |
| [`gpspassthrough`](Gps.md) | passthrough GPS to serial |
| `help` | |
| [`led`](LedStrip.md) | configure leds |
| [`map`](Rx.md) | mapping of RC channel order |
| [`mixer`](Mixer.md) | mixer name or list |
| [`mode_color`](LedStrip.md) | configure mode colors |
| `motor` | get/set motor output value |
| [`play_sound`](Buzzer.md) | index, or none for next |
| [`profile`](Profiles.md) | index (0 to 2) |
| [`rateprofile`](Profiles.md) | index (0 to 2) |
| [`rxrange`](Rx.md) | configure rx channel ranges (end-points) |
| [`rxfail`](Rx.md) | show/set rx failsafe settings |
| `save` | save and reboot |
| `serialpassthrough` | serial passthrough mode, reset board to exit |
| `set` | name=value or blank or * for list |
| `status` | show system status |
| `timer` | configure timer |
| `version` | show version |
| [`serial`](Serial.md) | configure serial ports |
| [`servo`](Mixer.md) | configure servos |
| `sd_info` | sdcard info |
| `tasks` | show task stats |
## CLI Variable Reference
Click on a variable to jump to the relevant documentation page.
| `Variable` | Description/Units | Min | Max | Default | Type | Datatype |
|-----------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------|--------|------------------|--------------|----------|
| `looptime` | This is the main loop time (in us). Changing this affects PID effect with some PID controllers (see PID section for details). Default of 3500us/285Hz should work for everyone. Setting it to zero does not limit loop time, so it will go as fast as possible. | 0 | 9000 | 3500 | Master | UINT16 |
| `emf_avoidance` | Default value is OFF for 72MHz processor speed. Setting this to ON increases the processor speed, to move the 6th harmonic away from 432MHz. | OFF | ON | OFF | Master | UINT8 |
| `i2c_highspeed` | Enabling this feature speeds up IMU speed significantly and faster looptimes are possible. | OFF | ON | ON | Master | UINT8 |
| [`gyro_sync`](Pid%20tuning.md) | This option enables gyro_sync feature. In this case the loop will be synced to gyro refresh rate. Loop will always wait for the newest gyro measurement. Use gyro_lpf and gyro_sync_denom determine the gyro refresh rate. Note that different targets have different limits. Setting too high refresh rate can mean that FC cannot keep up with the gyro and higher gyro_sync_denom is needed. | OFF | ON | ON | Master | UINT8 |
| [`mid_rc`](Rx.md) | This is an important number to set in order to avoid trimming receiver/transmitter. Most standard receivers will have this at 1500, however Futaba transmitters will need this set to 1520. A way to find out if this needs to be changed, is to clear all trim/subtrim on transmitter, and connect to GUI. Note the value most channels idle at - this should be the number to choose. Once midrc is set, use subtrim on transmitter to make sure all channels (except throttle of course) are centered at midrc value. | 1200 | 1700 | 1500 | Master | UINT16 |
| [`min_check`](Controls.md) | These are min/max values (in us) which, when a channel is smaller (min) or larger (max) than the value will activate various RC commands, such as arming, or stick configuration. Normally, every RC channel should be set so that min = 1000us, max = 2000us. On most transmitters this usually means 125% endpoints. Default check values are 100us above/below this value. | 0 | 2000 | 1100 | Master | UINT16 |
| [`max_check`](Controls.md) | These are min/max values (in us) which, when a channel is smaller (min) or larger (max) than the value will activate various RC commands, such as arming, or stick configuration. Normally, every RC channel should be set so that min = 1000us, max = 2000us. On most transmitters this usually means 125% endpoints. Default check values are 100us above/below this value. | 0 | 2000 | 1900 | Master | UINT16 |
| [`rssi_channel`](Rssi.md) | RX channel containing the RSSI signal | 0 | 18 | 0 | Master | INT8 |
| [`rssi_scale`](Rssi.md) | When using ADC RSSI, the raw ADC value will be divided by rssi_scale in order to get the RSSI percentage. RSSI scale is therefore the ADC raw value for 100% RSSI. | 1 | 255 | 30 | Master | UINT8 |
| [`rssi_invert`](Rssi.md) | When using PWM RSSI or ADC RSSI, determines if the signal is inverted (Futaba, FrSKY) | OFF | ON | ON | Master | INT8 |
| `rc_smoothing` | Interpolation of Rc data during looptimes when there are no new updates. This gives smoother RC input to PID controller and cleaner PIDsum | OFF | ON | ON | Master | INT8 |
| [`rx_min_usec`](Rx.md) | Defines the shortest pulse width value used when ensuring the channel value is valid. If the receiver gives a pulse value lower than this value then the channel will be marked as bad and will default to the value of `mid_rc`. | 750 | 2250 | 885 | Master | UINT16 |
| [`rx_max_usec`](Rx.md) | Defines the longest pulse width value used when ensuring the channel value is valid. If the receiver gives a pulse value higher than this value then the channel will be marked as bad and will default to the value of `mid_rc`. | 750 | 2250 | 2115 | Master | UINT16 |
| [`serialrx_provider`](Rx.md) | When feature SERIALRX is enabled, this allows connection to several receivers which output data via digital interface resembling serial. Possible values: SPEK1024, SPEK2048, SBUS, SUMD, XB-B, XB-B-RJ01, IBUS | | | SPEK1024 | Master | UINT8 |
| [`sbus_inversion`](Rx.md) | Standard SBUS (Futaba, FrSKY) uses an inverted signal. Some OpenLRS receivers produce a non-inverted SBUS signal. This setting is to support this type of receivers (including modified FrSKY). This only works on supported hardware (mainly F3 based flight controllers). | OFF | ON | ON | Master | UINT8 |
| [`spektrum_sat_bind`](Spektrum%20bind.md) | 0 = disabled. Used to bind the spektrum satellite to RX | 0 | 10 | 0 | Master | UINT8 |
| [`input_filtering_mode`](Rx.md) | Filter out noise from OpenLRS Telemetry RX | OFF | ON | ON | Master | INT8 |
| [`min_throttle`](Controls.md) | These are min/max values (in us) that are sent to ESC when armed. Defaults of 1150/1850 are OK for everyone, for use with AfroESC, they could be set to 1064/1864. | 0 | 2000 | 1150 | Master | UINT16 |
| [`max_throttle`](Controls.md) | These are min/max values (in us) that are sent to ESC when armed. Defaults of 1150/1850 are OK for everyone, for use with AfroESC, they could be set to 1064/1864. If you have brushed motors, the value should be set to 2000. | 0 | 2000 | 1850 | Master | UINT16 |
| [`min_command`](Controls.md) | This is the PWM value sent to ESCs when they are not armed. If ESCs beep slowly when powered up, try decreasing this value. It can also be used for calibrating all ESCs at once. | 0 | 2000 | 1000 | Master | UINT16 |
| `servo_center_pulse` | Servo midpoint | 0 | 2000 | 1500 | Master | UINT16 |
| `motor_pwm_rate` | Output frequency (in Hz) for motor pins. Defaults are 400Hz for motor. If setting above 500Hz, will switch to brushed (direct drive) motors mode. For example, setting to 8000 will use brushed mode at 8kHz switching frequency. Up to 32kHz is supported. Default is 16000 for boards with brushed motors. Note, that in brushed mode, minthrottle is offset to zero. For brushed mode, set ```max_throttle``` to 2000. | 50 | 32000 | 400 | Master | UINT16 |
| `servo_pwm_rate` | Output frequency (in Hz) servo pins. Default is 50Hz. When using tricopters or gimbal with digital servo, this rate can be increased. Max of 498Hz (for 500Hz pwm period), and min of 50Hz. Most digital servos will support for example 330Hz. | 50 | 498 | 50 | Master | UINT16 |
| `3d_deadband_low` | Low value of throttle deadband for 3D mode (when stick is in the 3d_deadband_throttle range, the fixed values of 3d_deadband_low / _high are used instead) | 0 | 2000 | 1406 | Master | UINT16 |
| `3d_deadband_high` | High value of throttle deadband for 3D mode (when stick is in the deadband range, the value in 3d_neutral is used instead) | 0 | 2000 | 1514 | Master | UINT16 |
| `3d_neutral` | Neutral (stop) throttle value for 3D mode | 0 | 2000 | 1460 | Master | UINT16 |
| `retarded_arm` | Disabled by default, enabling (setting to 1) allows disarming by throttle low + roll. This could be useful for mode-1 users and non-acro tricopters, where default arming by yaw could move tail servo too much. | OFF | ON | OFF | Master | UINT8 |
| `disarm_kill_switch` | Enabled by default. Disarms the motors independently of throttle value. Setting to 0 reverts to the old behaviour of disarming only when the throttle is low. Only applies when arming and disarming with an AUX channel. | OFF | ON | ON | Master | UINT8 |
| `auto_disarm_delay` | Delay before automatic disarming | 0 | 60 | 5 | Master | UINT8 |
| `max_arm_angle` | Maximum horizontal angle before arming is disabled | 0 | 180 | 25 | Master | UINT8 |
| `small_angle` | If the copter tilt angle exceed this value the copter will refuse to arm. default is 25°. | 0 | 180 | 25 | Master | UINT8 |
| `fixedwing_althold_dir` | Used for fixed-wing aircrafts. Determines of the correction value applied to throttle in alititude hold mode should be inverted. | -1 | 1 | 1 | Master | INT8 |
| `reboot_character` | Special character used to trigger reboot | 48 | 126 | 82 | Master | UINT8 |
| [`gps_provider`](Gps.md) | GPS standard. Possible values: NMEA, UBLOX | | | NMEA | Master | UINT8 |
| [`gps_sbas_mode`](Gps.md) | Ground assistance type. Possible values: AUTO, EGNOS, WAAS, MSAS, GAGAN | | | AUTO | Master | UINT8 |
| [`gps_auto_config`](Gps.md) | Enable automatic configuration of UBlox GPS receivers. | OFF | ON | ON | Master | UINT8 |
| `gps_auto_baud` | Enable automatic detection of GPS baudrate. | OFF | ON | OFF | Master | UINT8 |
| `gps_pos_p` | GPS Position hold: P parameter | 0 | 200 | 15 | Profile | UINT8 |
| `gps_pos_i` | GPS Position hold: I parameter | 0 | 200 | 0 | Profile | UINT8 |
| `gps_pos_d` | GPS Position hold: D parameter | 0 | 200 | 0 | Profile | UINT8 |
| `gps_posr_p` | GPS Position hold rate: P parameter | 0 | 200 | 34 | Profile | UINT8 |
| `gps_posr_i` | GPS Position hold rate: I parameter | 0 | 200 | 14 | Profile | UINT8 |
| `gps_posr_d` | GPS Position hold rate: D parameter | 0 | 200 | 53 | Profile | UINT8 |
| `gps_nav_p` | GPS Navigation: P parameter | 0 | 200 | 25 | Profile | UINT8 |
| `gps_nav_i` | GPS Navigation: I parameter | 0 | 200 | 33 | Profile | UINT8 |
| `gps_nav_d` | GPS Navigation: D parameter | 0 | 200 | 83 | Profile | UINT8 |
| `gps_wp_radius` | GPS Navigation: waypoint radius | 0 | 2000 | 200 | Profile | UINT16 |
| `nav_controls_heading` | GPS Navigation: should the craft's heading follow the flying direction. | OFF | ON | ON | Profile | UINT8 |
| `nav_speed_min` | GPS Navigation: minimum moving speed | 10 | 2000 | 100 | Profile | UINT16 |
| `nav_speed_max` | GPS Navigation: maximum moving speed | 10 | 2000 | 300 | Profile | UINT16 |
| `nav_slew_rate` | GPS Navigation: maximum angle correction value. Lower slew rate stops the craft from rotating too quickly. | 0 | 100 | 30 | Profile | UINT8 |
| `telemetry_switch` | When an AUX channel is used to change serial output & baud rate (MSP / Telemetry). OFF: Telemetry is activated when armed. ON: Telemetry is activated by the AUX channel. | OFF | ON | OFF | Master | UINT8 |
| [`report_cell_voltage`](Telemetry.md) | Determines if the voltage reported is Vbatt or calculated average cell voltage. | OFF | ON | OFF | Master | UINT8 |
| [`telemetry_inversion`](Telemetry.md) | Determines if the telemetry signal is inverted (Futaba, FrSKY) | OFF | ON | OFF | Master | UINT8 |
| `telemetry_send_cells` | Emulates FrSky FLVSS individual cell voltages telemetry | OFF | ON | OFF | Master | UINT8 |
| `frsky_default_lattitude` | OpenTX needs a valid set of coordinates to show compass value. A fake value defined in this setting is sent while no fix is acquired. | -90 | 90 | 0 | Master | FLOAT |
| `frsky_default_longitude` | OpenTX needs a valid set of coordinates to show compass value. A fake value defined in this setting is sent while no fix is acquired. | -180 | 180 | 0 | Master | FLOAT |
| `frsky_coordinates_format` | FRSKY_FORMAT_DMS (default), FRSKY_FORMAT_NMEA | | | FRSKY_FORMAT_DMS | Master | UINT8 |
| `frsky_unit` | IMPERIAL (default), METRIC | | | IMPERIAL | Master | UINT8 |
| [`frsky_vfas_precision`](Telemetry.md) | Set to 1 to send raw VBat value in 0.1V resolution for receivers that can handle it, or 0 (default) to use the standard method | 0 | 1 | 0 | Master | UINT8 |
| `hott_alarm_sound_interval` | Battery alarm delay in seconds for Hott telemetry | 0 | 120 | 5 | Master | UINT8 |
| [`bat_capacity`](Battery.md) | Battery capacity in mAH. This value is used in conjunction with the current meter to determine remaining battery capacity. | 0 | 20000 | 0 | Master | UINT16 |
| [`vbat_scale`](Battery.md) | Result is Vbatt in 0.1V steps. 3.3V = ADC Vref, 4095 = 12bit adc, 110 = 11:1 voltage divider (10k:1k) x 10 for 0.1V. Adjust this slightly if reported pack voltage is different from multimeter reading. You can get current voltage by typing "status" in cli. | 0 | 255 | 110 | Master | UINT8 |
| [`vbat_max_cell_voltage`](Battery.md) | Maximum voltage per cell, used for auto-detecting battery voltage in 0.01V units, default is 430 (4.3V) | 100 | 500 | 430 | Master | UINT16 |
| [`vbat_min_cell_voltage`](Battery.md) | Minimum voltage per cell, this triggers battery-critical alarms, in 0.01V units, default is 330 (3.3V) | 100 | 500 | 330 | Master | UINT16 |
| [`vbat_warning_cell_voltage`](Battery.md) | Warning voltage per cell, this triggers battery-warning alarms, in 0.01V units, default is 350 (3.5V) | 100 | 500 | 350 | Master | UINT16 |
| [`vbat_hysteresis`](Battery.md) | Sets the hysteresis value for low-battery alarms, in 0.01V units, default is 1 (0.01V) | 10 | 250 | 1 | Master | UINT8 |
| [`current_meter_scale`](Battery.md) | This sets the output voltage to current scaling for the current sensor in 0.1 mV/A steps. 400 is 40mV/A such as the ACS756 sensor outputs. 183 is the setting for the uberdistro with a 0.25mOhm shunt. | -10000 | 10000 | 400 | Master | INT16 |
| [`current_meter_offset`](Battery.md) | This sets the output offset voltage of the current sensor in millivolts. | 0 | 3300 | 0 | Master | UINT16 |
| [`multiwii_current_meter_output`](Battery.md) | Default current output via MSP is in 0.01A steps. Setting this to 1 causes output in default multiwii scaling (1mA steps). | OFF | ON | OFF | Master | UINT8 |
| [`current_meter_type`](Battery.md) | ADC (default), VIRTUAL, NONE. The virtual current sensor, once calibrated, estimates the current value from throttle position. | | | ADC | Master | UINT8 |
| `align_gyro` | When running on non-default hardware or adding support for new sensors/sensor boards, these values are used for sensor orientation. When carefully understood, these values can also be used to rotate (in 90deg steps) or flip the board. Possible values are: DEFAULT, CW0, CW90, CW180, CW270, CW0FLIP, CW90FLIP, CW180FLIP, CW270FLIP. | | | DEFAULT | Master | UINT8 |
| `align_acc` | When running on non-default hardware or adding support for new sensors/sensor boards, these values are used for sensor orientation. When carefully understood, these values can also be used to rotate (in 90deg steps) or flip the board. Possible values are: DEFAULT, CW0, CW90, CW180, CW270, CW0FLIP, CW90FLIP, CW180FLIP, CW270FLIP. | | | DEFAULT | Master | UINT8 |
| `align_mag` | When running on non-default hardware or adding support for new sensors/sensor boards, these values are used for sensor orientation. When carefully understood, these values can also be used to rotate (in 90deg steps) or flip the board. Possible values are: DEFAULT, CW0, CW90, CW180, CW270, CW0FLIP, CW90FLIP, CW180FLIP, CW270FLIP. | | | DEFAULT | Master | UINT8 |
| `align_board_roll` | Arbitrary board rotation in degrees, to allow mounting it sideways / upside down / rotated etc | -180 | 360 | 0 | Master | INT16 |
| `align_board_pitch` | Arbitrary board rotation in degrees, to allow mounting it sideways / upside down / rotated etc | -180 | 360 | 0 | Master | INT16 |
| `align_board_yaw` | Arbitrary board rotation in degrees, to allow mounting it sideways / upside down / rotated etc | -180 | 360 | 0 | Master | INT16 |
| `max_angle_inclination` | This setting controls max inclination (tilt) allowed in angle (level) mode. default 500 (50 degrees). | 100 | 900 | 500 | Master | UINT16 |
| [`gyro_lpf`](PID%20tuning.md) | Hardware lowpass filter cutoff frequency for gyro. Allowed values depend on the driver - For example MPU6050 allows 10HZ,20HZ,42HZ,98HZ,188HZ. If you have to set gyro lpf below 42Hz generally means the frame is vibrating too much, and that should be fixed first. | 10HZ | 188HZ | 42HZ | Master | UINT16 |
| `gyro_soft_lpf` | Software lowpass filter cutoff frequency for gyro. Default is 60Hz. Set to 0 to disable. | 0 | 500 | 60 | Master | UINT16 |
| `moron_threshold` | When powering up, gyro bias is calculated. If the model is shaking/moving during this initial calibration, offsets are calculated incorrectly, and could lead to poor flying performance. This threshold (default of 32) means how much average gyro reading could differ before re-calibration is triggered. | 0 | 128 | 32 | Master | UINT8 |
| `imu_dcm_kp` | Inertial Measurement Unit KP Gain | 0 | 20000 | 2500 | Master | UINT16 |
| `imu_dcm_ki` | Inertial Measurement Unit KI Gain | 0 | 20000 | 0 | Master | UINT16 |
| `alt_hold_deadband` | Altitude will be held when throttle is centered with an error margin defined in this parameter. | 1 | 250 | 40 | Profile | UINT8 |
| `alt_hold_fast_change` | Authorise fast altitude changes. Should be disabled when slow changes are preferred, for example for aerial photography. | OFF | ON | ON | Profile | UINT8 |
| [`deadband`](Controls.md) | These are values (in us) by how much RC input can be different before it's considered valid for roll and pitch axis. For transmitters with jitter on outputs, this value can be increased. Defaults are zero, but can be increased up to 10 or so if rc inputs twitch while idle. This value is applied either side of the centrepoint. | 0 | 32 | 0 | Profile | UINT8 |
| [`yaw_deadband`](Controls.md) | These are values (in us) by how much RC input can be different before it's considered valid for the yaw axis. For transmitters with jitter on outputs, this value can be increased. Defaults are zero, but can be increased up to 10 or so if rc inputs twitch while idle. This value is applied either side of the centrepoint. | 0 | 100 | 0 | Profile | UINT8 |
| `yaw_control_direction` | Use if you need to inverse yaw control direction. | -1 | 1 | 1 | Profile | INT8 |
| `3d_deadband_throttle` | Throttle signal will be held to a fixed value when throttle is centered with an error margin defined in this parameter. | 0 | 2000 | 50 | Profile | UINT16 |
| `throttle_correction_value` | The throttle_correction_value will be added to the throttle input. It will be maximal at the throttle_correction_angle and over, null when the copter is leveled and proportional in bewteen. The angle is set with 0.1 deg steps from 1 to 900, i.e. : 300 = 30.0 deg, 225 = 22.5 deg. | 0 | 150 | 0 | Profile | UINT8 |
| `throttle_correction_angle` | The throttle_correction_value will be added to the throttle input. It will be maximal at the throttle_correction_angle and over, null when the copter is leveled and proportional in bewteen. The angle is set with 0.1 deg steps from 1 to 900, i.e. : 300 = 30.0 deg, 225 = 22.5 deg. | 1 | 900 | 800 | Profile | UINT16 |
| `pid_at_min_throttle` | If enabled, the copter will process the PID algorithm at minimum throttle. Cannot be used when `retarded_arm` is enabled. | OFF | ON | ON | Master | UINT8 |
| `yaw_motor_direction` | Use if you need to inverse yaw motor direction. | -1 | 1 | 1 | Master | INT8 |
| `yaw_jump_prevention_limit` | Prevent yaw jumps during yaw stops and rapid YAW input. To disable set to 500. Adjust this if your aircraft 'skids out'. Higher values increases YAW authority but can cause roll/pitch instability in case of underpowered UAVs. Lower values makes yaw adjustments more gentle but can cause UAV unable to keep heading | 80 | 500 | 200 | Master | UINT16 |
| [`tri_unarmed_servo`](Controls.md) | On tricopter mix only, if this is set to 1, servo will always be correcting regardless of armed state. to disable this, set it to 0. | OFF | ON | ON | Master | INT8 |
| [`servo_lowpass_freq`](Mixer.md) | Selects the servo PWM output cutoff frequency. Valid values range from 10 to 400. This is a fraction of the loop frequency in 1/1000ths. For example, `40` means `0.040`. The cutoff frequency can be determined by the following formula: `Frequency = 1000 * servo_lowpass_freq / looptime` | 10 | 400 | 400 | Master | FLOAT |
| [`servo_lowpass_enable`](Mixer.md) | Disabled by default. | OFF | ON | OFF | Master | INT8 |
| [`default_rate_profile`](Profiles.md) | Default = profile number | 0 | 2 | 0 | Profile | UINT8 |
| [`rc_rate`](Profiles.md) | Rate value for all RC directions | 0 | 250 | 90 | Rate Profile | UINT8 |
| [`rc_expo`](Profiles.md) | Exposition value for all RC directions | 0 | 100 | 65 | Rate Profile | UINT8 |
| `rc_yaw_expo` | Yaw exposition value | 0 | 100 | 0 | Rate Profile | UINT8 |
| [`thr_mid`](Profiles.md) | Throttle value when the stick is set to mid-position. Used in the throttle curve calculation. | 0 | 100 | 50 | Rate Profile | UINT8 |
| [`thr_expo`](Profiles.md) | Throttle exposition value | 0 | 100 | 0 | Rate Profile | UINT8 |
| `roll_rate` | Roll rate value | | 100 | 40 | Rate Profile | UINT8 |
| [`pitch_rate`](Profiles.md) | Pitch rate value | | 100 | 40 | Rate Profile | UINT8 |
| [`yaw_rate`](Profiles.md) | Yaw rate value | 0 | 255 | 0 | Rate Profile | UINT8 |
| [`tpa_rate`](Profiles.md) | Throttle PID attenuation reduces influence of P on ROLL and PITCH as throttle increases. For every 1% throttle after the TPA breakpoint, P is reduced by the TPA rate. | 0 | 100 | 0 | Rate Profile | UINT8 |
| [`tpa_breakpoint`](Profiles.md) | See tpa_rate. | 1000 | 2000 | 1500 | Rate Profile | UINT16 |
| [`failsafe_delay`](Failsafe.md) | Time in deciseconds to wait before activating failsafe when signal is lost. See [Failsafe documentation](Failsafe.md#failsafe_delay). | 0 | 200 | 10 | Master | UINT8 |
| [`failsafe_off_delay`](Failsafe.md) | Time in deciseconds to wait before turning off motors when failsafe is activated. See [Failsafe documentation](Failsafe.md#failsafe_off_delay). | 0 | 200 | 200 | Master | UINT8 |
| [`failsafe_throttle`](Failsafe.md) | Throttle level used for landing when failsafe is enabled. See [Failsafe documentation](Failsafe.md#failsafe_throttle). | 1000 | 2000 | 1000 | Master | UINT16 |
| [`failsafe_kill_switch`](Failsafe.md) | Set to ON to use an AUX channel as a faisafe kill switch. | OFF | ON | OFF | Master | UINT8 |
| [`failsafe_throttle_low_delay`](Failsafe.md) | Activate failsafe when throttle is low and no RX data has been received since this value, in 10th of seconds | 0 | 300 | 100 | Master | UINT16 |
| [`failsafe_procedure`](Failsafe.md) | 0 = Autolanding (default). 1 = Drop. | 0 | 1 | 0 | Master | UINT8 |
| `gimbal_mode` | When feature SERVO_TILT is enabled, this can be either NORMAL or MIXTILT | | | NORMAL | Profile | UINT8 |
| `acc_hardware` | This is used to suggest which accelerometer driver should load, or to force no accelerometer in case gyro-only flight is needed. Default (0) will attempt to auto-detect among enabled drivers. Otherwise, to force a particular device, set it to 2 for ADXL345, 3 for MPU6050 integrated accelerometer, 4 for MMA8452, 5 for BMA280, 6 for LSM303DLHC, 7 for MPU6000, 8 for MPU6500 or 1 to disable accelerometer alltogether - resulting in gyro-only operation. | 0 | 9 | 0 | Master | UINT8 |
| `accz_lpf_cutoff` | Cutoff frequency used in the low-pass filtering of accelerometer measurements. | 1 | 20 | 5 | Profile | FLOAT |
| `acc_trim_pitch` | Accelerometer trim (Pitch) | -300 | 300 | 0 | Profile | INT16 |
| `acc_trim_roll` | Accelerometer trim (Roll) | -300 | 300 | 0 | Profile | INT16 |
| `baro_tab_size` | Pressure sensor sample count. | 0 | 48 | 21 | Profile | UINT8 |
| `baro_noise_lpf` | barometer low-pass filter cut-off frequency in Hz. Ranges from 0 to 1 ; default 0.6 | 0 | 1 | 0.6 | Profile | FLOAT |
| `baro_cf_vel` | Velocity sensor mix in altitude hold. Determines the influence accelerometer and barometer sensors have in the velocity estimation. Values from 0 to 1; 1 for pure accelerometer altitude, 0 for pure barometer altitude. | 0 | 1 | 0.985 | Profile | FLOAT |
| `baro_cf_alt` | Altitude sensor mix in altitude hold. Determines the influence accelerometer and barometer sensors have in the altitude estimation. Values from 0 to 1; 1 for pure accelerometer altitude, 0 for pure barometer altitude. | 0 | 1 | 0.965 | Profile | FLOAT |
| `baro_hardware` | 0 = Default, use whatever mag hardware is defined for your board type ; 1 = None, 2 = BMP085, 3 = MS5611, 4 = BMP280 | 0 | 4 | 0 | Master | UINT8 |
| `mag_hardware` | 0 = Default, use whatever mag hardware is defined for your board type ; 1 = None, disable mag ; 2 = HMC5883 ; 3 = AK8975 ; 4 = AK8963 (for versions <= 1.7.1: 1 = HMC5883 ; 2 = AK8975 ; 3 = None, disable mag) | 0 | 4 | 0 | Master | UINT8 |
| `mag_declination` | Current location magnetic declination in dddmm format. For example, -6deg 37min = -637 for Japan. Leading zeros not required. Get your local magnetic declination here: http://magnetic-declination.com/ | -18000 | 18000 | 0 | Profile | INT16 |
| [`p_pitch`](PID%20tuning.md) | Pitch P parameter | 0 | 200 | 40 | Profile | UINT8 |
| [`i_pitch`](PID%20tuning.md) | Pitch I parameter | 0 | 200 | 30 | Profile | UINT8 |
| [`d_pitch`](PID%20tuning.md) | Pitch D parameter | 0 | 200 | 23 | Profile | UINT8 |
| [`p_roll` ](PID%20tuning.md) | Roll P parameter | 0 | 200 | 40 | Profile | UINT8 |
| [`i_roll` ](PID%20tuning.md) | Roll I parameter | 0 | 200 | 30 | Profile | UINT8 |
| [`d_roll` ](PID%20tuning.md) | Roll D parameter | 0 | 200 | 23 | Profile | UINT8 |
| [`p_yaw`](PID%20tuning.md) | Yaw P parameter | 0 | 200 | 85 | Profile | UINT8 |
| [`i_yaw`](PID%20tuning.md) | Yaw I parameter | 0 | 200 | 45 | Profile | UINT8 |
| [`d_yaw`](PID%20tuning.md) | Yaw D parameter | 0 | 200 | 0 | Profile | UINT8 |
| [`p_alt`](PID%20tuning.md) | Altitude P parameter (Baro / Sonar altitude hold) | 0 | 200 | 50 | Profile | UINT8 |
| [`i_alt`](PID%20tuning.md) | Altitude I parameter (Baro / Sonar altitude hold) | 0 | 200 | 0 | Profile | UINT8 |
| [`d_alt`](PID%20tuning.md) | Altitude D parameter (Baro / Sonar altitude hold) | 0 | 200 | 0 | Profile | UINT8 |
| [`p_level`](PID%20tuning.md) | Level P parameter (Angle / horizon modes) | 0 | 200 | 20 | Profile | UINT8 |
| [`i_level`](PID%20tuning.md) | Level I parameter (Angle / horizon modes) | 0 | 200 | 10 | Profile | UINT8 |
| [`d_level`](PID%20tuning.md) | Level D parameter (Angle / horizon modes) | 0 | 200 | 100 | Profile | UINT8 |
| [`p_vel`](PID%20tuning.md) | Velocity P parameter (Baro / Sonar altitude hold) | 0 | 200 | 120 | Profile | UINT8 |
| [`i_vel`](PID%20tuning.md) | Velocity I parameter (Baro / Sonar altitude hold) | 0 | 200 | 45 | Profile | UINT8 |
| [`d_vel`](PID%20tuning.md) | Velocity D parameter (Baro / Sonar altitude hold) | 0 | 200 | 1 | Profile | UINT8 |
| `yaw_p_limit` | Limiter for yaw P term. This parameter is only affecting PID controller MW23. To disable set to 500 (actual default). | 100 | 500 | 500 | Profile | UINT16 |
| [`dterm_cut_hz`](PID%20tuning.md) | Lowpass cutoff filter for Dterm for all PID controllers | 0 | 500 | 0 | Profile | UINT16 |
| [`gtune_loP_rll`](Gtune.md) | GTune: Low Roll P limit | 10 | 200 | 10 | Profile | UINT8 |
| [`gtune_loP_ptch`](Gtune.md) | GTune: Low Pitch P limit | 10 | 200 | 10 | Profile | UINT8 |
| [`gtune_loP_yw`](Gtune.md) | GTune: Low Yaw P limit | 10 | 200 | 10 | Profile | UINT8 |
| [`gtune_hiP_rll`](Gtune.md) | GTune: High Roll P limit | 0 | 200 | 100 | Profile | UINT8 |
| [`gtune_hiP_ptch`](Gtune.md) | GTune: High Pitch P limit | 0 | 200 | 100 | Profile | UINT8 |
| [`gtune_hiP_yw`](Gtune.md) | GTune: High Yaw P limit | 0 | 200 | 100 | Profile | UINT8 |
| [`gtune_pwr`](Gtune.md) | Strength of each Gtune adjustment | 0 | 10 | 0 | Profile | UINT8 |
| [`gtune_settle_time`](Gtune.md) | GTune settling time in milliseconds | 200 | | 450 | Profile | UINT16 |
| [`gtune_average_cycles`](Gtune.md) | Looptime cycles for gyro average calculation. Default = 16. | 8 | 128 | 16 | Profile | UINT8 |
| [`blackbox_rate_num`](Blackbox.md) | Blackbox logging rate numerator. Use num/denom settings to decide if a frame should be logged, allowing control of the portion of logged loop iterations | 1 | 32 | 1 | Master | UINT8 |
| [`blackbox_rate_denom`](Blackbox.md) | Blackbox logging rate denominator. See blackbox_rate_num. | 1 | 32 | 1 | Master | UINT8 |
| [`blackbox_device`](Blackbox.md) | SERIAL, SPIFLASH, SDCARD (default) | | | SDCARD | Master | UINT8 |
| `magzero_x` | Magnetometer calibration X offset | -32768 | 32767 | 0 | Master | INT16 |
| `magzero_y` | Magnetometer calibration Y offset | -32768 | 32767 | 0 | Master | INT16 |
| `magzero_z` | Magnetometer calibration Z offset | -32768 | 32767 | 0 | Master | INT16 |
| `vtx_band` | Configure the VTX band. Set to zero to use `vtx_freq`. Bands: 1: A, 2: B, 3: E, 4: F, 5: Race. | 0 | 5 | 4 | Master | UINT8 |
| `vtx_channel` | Channel to use within the configured `vtx_band`. Valid values are [1, 8]. | 1 | 8 | 1 | Master | UINT8 |
| `vtx_freq` | Set the VTX frequency using raw MHz. This parameter is ignored unless `vtx_band` is 0. | 0 | 5900 | 5740 | Master | UINT16 |
| `vtx_halfduplex` | Use half duplex UART to communicate with the VTX, using only a TX pin in the FC. | OFF | ON | ON | Master | UINT8 |
| `vtx_low_power_disarm` | When the craft is disarmed, set the VTX to its lowest power. `ON` will set the power to its minimum value on startup, increase it to `vtx_power` when arming and change it back to its lowest setting after disarming. `UNTIL_FIRST_ARM` will start with minimum power, but once the craft is armed it will increase to `vtx_power` and it will never decrease until the craft is power cycled. | | | OFF | Master | UINT8 |
| `vtx_pit_mode_freq` | Frequency to use (in MHz) when the VTX is in pit mode. | 0 | 5900 | 0 | Master | UINT16 |
| `vtx_power` | VTX RF power level to use. The exact number of mw depends on the VTX hardware. | 0 | 3 | 1 | Master | UINT8 |

83
docs/Cloud build API.md
View file

@ -1,83 +0,0 @@
# Betaflight 4.4 cloud build API
## API
Avoiding EOL on 512K targets we have introduced a cloud build API saving around 25% of firmware flash usage.
Unified targets define hardware drivers to be included in the firmware as described in the [Hardware specification](https://github.com/betaflight/betaflight/blob/master/docs/Manufacturer%20Design%20Guidelines.md#42-definitions-for-unified-targets)
The build log has information about the build in case of failure.
## Usage
For optimal use please select ONLY the appropiate hardware for the flight controller after selecting the right target (using auto-detect button).
### Radio Protocols
CRSF
FPORT
GHOST
IBUS
JETIEXBUS
PPM
SBUS
SPECTRUM
SRXL2
SUMD
SUMH
XBUS
### Telemetry Protocols
FRSKY_HUB
GHOST
HOTT
IBUS_EXTENDED
JETIEXBUS
LTM
MAVLINK
SMARTPORT
SRXL
Note: telemetry for CRSF, ELRS, FPORT and GHST are included during the build.
### Other Options
AKK (SA FIX)
FLASH
GPS
LED
LED64
MAG
OSD
OSD (HD)
PINIO
VTX
### Motor Protocols
BRUSHED
DSHOT
MULTISHOT
ONESHOT
PROSHOT
PWM
### Custom Defines
BATTERY_CONTINUE
DASHBOARD
EMFAT_AUTORUN
EMFAT_ICON
ESCSERIAL_SIMONK
GPS
GPS_PLUS_CODES
LED_STRIP
SERIAL_4WAY_SK_BOOTLOADER

35
docs/Configuration.md
View file

@ -1,35 +0,0 @@
# Configuration
Cleanflight is configured primarily using the Cleanflight Configurator GUI.
Both the command line interface and GUI are accessible by connecting to a serial port on the target,
be it a USB virtual serial port, physical hardware UART port or a SoftSerial port.
See the Serial section for more information and see the Board specific sections for details of the serial ports available on the board you are using.
The GUI cannot currently configure all aspects of the system, the CLI must be used to enable or configure
some features and settings.
__Due to ongoing development, the fact that the GUI cannot yet backup all your settings and automatic chrome updates of the GUI app it is highly advisable to backup your settings (using the CLI) so that when a new version of the configurator or firmware is released you can re-apply your settings.__
## GUI
![Cleanflight Gui](Screenshots/cleanflight-gui.png)
The GUI tool is the preferred way of configuration. The GUI tool also includes a terminal which
can be used to interact with the CLI.
[Cleanflight Configurator on Chrome store](https://chrome.google.com/webstore/detail/cleanflight-configurator/enacoimjcgeinfnnnpajinjgmkahmfgb)
If you cannot use the latest version of the GUI to access the FC due to firmware compatibility issues you can still access the FC via the CLI to backup your settings, or you can install an old version of the configurator.
Old versions of the configurator can be downloaded from the configurator releases page: https://github.com/cleanflight/cleanflight-configurator/releases
See the README file that comes with the configurator for installation instructions.
## CLI
Cleanflight can also be configured by a command line interface.
See the [CLI section](Cli.md) of the documentation for more details.

133
docs/Controls.md
View file

@ -1,133 +0,0 @@
# Controls
## Arming
When armed, the aircraft is ready to fly and the motors will spin when throttle is applied. The motors will
spin at a slow speed when armed (this feature may be disabled by setting MOTOR_STOP, but for safety reasons,
that is not recommended).
By default, arming and disarming is done using stick positions. (NOTE: this feature is disabled when using a
switch to arm.)
Some conditions will disable arming. In this case the Warning LED on the board will flash a certain number of times, indicating what the condition is:
| Reason for disabled Arming | LED Flashes |
|------------------------------------------|-------------|
| CLI is active in the configurator | 2 |
| Failsafe mode is active | 3 |
| The aircraft has landed in failsafe mode | 3 |
| Maximum arming angle is exceeded | 4 |
| Calibration is active | 5 |
| The system is overloaded | 6 |
## Stick Positions
The three stick positions are:
|Position | Approx. Channel Input|
|----------------|----------------------|
|LOW | 1000 |
|CENTER | 1500 |
|HIGH | 2000 |
The stick positions are combined to activate different functions:
| Function | Throttle | Yaw | Pitch | Roll |
| ----------------------------- | -------- | ------- | ------ | ------ |
| ARM | LOW | HIGH | CENTER | CENTER |
| DISARM | LOW | LOW | CENTER | CENTER |
| Profile 1 | LOW | LOW | CENTER | LOW |
| Profile 2 | LOW | LOW | HIGH | CENTER |
| Profile 3 | LOW | LOW | CENTER | HIGH |
| Calibrate Gyro | LOW | LOW | LOW | CENTER |
| Calibrate Acc | HIGH | LOW | LOW | CENTER |
| Calibrate Mag/Compass | HIGH | HIGH | LOW | CENTER |
| Inflight calibration controls | LOW | LOW | HIGH | HIGH |
| Trim Acc Left | HIGH | CENTER | CENTER | LOW |
| Trim Acc Right | HIGH | CENTER | CENTER | HIGH |
| Trim Acc Forwards | HIGH | CENTER | HIGH | CENTER |
| Trim Acc Backwards | HIGH | CENTER | LOW | CENTER |
| Disable LCD Page Cycling | LOW | CENTER | HIGH | LOW |
| Enable LCD Page Cycling | LOW | CENTER | HIGH | HIGH |
| Save setting | LOW | LOW | LOW | HIGH |
![Stick Positions](assets/images/StickPositions.png)
### History
Intial stick commands, came from MultiWII but the original code no-longer has direct links.
The original documents as listed below can be found here https://code.google.com/archive/p/multiwii/source/default/source
* `svn/branches/Hamburger/MultiWii-StickConfiguration-23_v0-5772156649.pdf`
* `multiwii/branches/Hamburger/MultiWii-StickConfiguration-23_v0-5772156649.odp`
## Yaw control
While arming/disarming with sticks, your yaw stick will be moving to extreme values. In order to prevent your craft
from trying to yaw during arming/disarming while on the ground, your yaw input will not cause the craft to yaw when the
throttle is LOW (i.e. below the `min_check` setting).
For tricopters, you may want to retain the ability to yaw while on the ground, so that you can verify that your tail
servo is working correctly before takeoff. You can do this by setting `tri_unarmed_servo` to `ON` on the CLI (this is the
default). If you are having issues with your tail rotor contacting the ground during arm/disarm, you can set this to
`0` instead. Check this table to decide which setting will suit you:
<table>
<tr>
<th colspan="5">Is yaw control of the tricopter allowed?</th>
</tr>
<tr>
<th></th><th colspan="2">Disarmed</th><th colspan="2">Armed</th>
</tr>
<tr>
<th></th><th>Throttle low</th><th>Throttle normal</th><th>Throttle low</th><th>Throttle normal</th>
</tr>
<tr>
<td rowspan="2">tri_unarmed_servo = OFF</td><td>No</td><td>No</td><td>No</td><td>Yes</td>
</tr>
<tr>
<td>No</td><td>No</td><td>No</td><td>Yes</td>
</tr>
<tr>
<td rowspan="2">tri_unarmed_servo = ON</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td>
</tr>
<tr>
<td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td>
</tr>
</table>
## Throttle settings and their interaction
`min_command` -
With motor stop enabled this is the command sent to the esc's when the throttle is below min_check or disarmed. With motor stop disabled, this is the command sent only when the copter is disarmed. This must be set well below motors spinning for safety.
`min_check` -
With switch arming mode is in use, lowering your throttle below min_check will result in motors spinning at min_throttle. When using the default stick arming, lowering your throttle below min_check will result in motors spinning at min_throttle and yaw being disabled so that you may arm/disarm. With motor stop enabled, lowering your throttle below min_check will also result in motors off and the esc's being sent min_command. Min_check must be set to a level that is 100% reliably met by the throttle throw. A setting too low may result in a dangerous condition where the copter can’t be disarmed. It is ok to set this below min_throttle because the FC will automaticly scale the output to the esc's
`min_throttle` -
Typically set to just above reliable spin up of all motors. Sometimes this is set slightly higher for prop stall prevention during advanced maneuvers or sometimes considerably higher to produce a desired result. When armed with motor stop off, your motors will spin at this command so keep that in mind from a safety stand point.
`max_check` -
Throttle positions above this level will send max_command to the esc's.
`max_throttle` -
This is the max command to the esc's from the flight controller.
In depth videos explaining these terms are available from Joshua Bardwell here:
https://www.youtube.com/watch?v=WFU3VewGbbA
https://www.youtube.com/watch?v=YNRl0OTKRGA
## Deadband
If yaw, roll or pitch sticks do not reliably return to centre or the radio has a lot of jitter around the centrepoint, deadband can be applied. The whole deadband value is applied *either side* of the center point rather than half the value above and half the value below. The deadband value will have an effect on stick endpoint values as the axis value will be reduced by the amount of deadband applied.
`deadband` -
Applied to roll, pitch.
`yaw_deadband`
Only applied to yaw.

16
docs/Custom Board Configuration.md
View file

@ -1,16 +0,0 @@
## Custom Board Configuration Using CLI
Warning: This section covers beyond the normal use-case for Betaflight. It's recommended that you use a pre-made target configuration for a flight controller that has been thoroughly tested before. Those configurations can be found in the [unified targets list](https://github.com/betaflight/unified-targets/tree/master/configs/default).
However, Betaflight can provide support for custom-made flight controllers, assuming it contains supported hardware. Before using Betaflight at all, it's highly recommended that you, first, check to make sure your MCU and your peripherals are supported. Checking the [Supported Sensors](https://github.com/betaflight/betaflight/wiki/Supported-Sensors) and [Hardware Reference](https://github.com/betaflight/betaflight/wiki/Hardware-Reference) wiki pages are good places to look. Betaflight is supported across many STM32 processors. Second, thoroughly test the functionality of your hardware by programming your board in an IDE (i.e. STMCube) or using any other hardware debugging methods/tools.
Assuming your hardware is supported and you've thoroughly tested your peripherals, flash generic firmware into your board. It's recommended to flash betaflight firmware using the configurator and [USB Flashing](https://github.com/betaflight/betaflight/blob/master/docs/USB%20Flashing.md).
To create your own configuration, you must first use the `resource` command in the command line interface to map your peripheral pins on your controller. Use the CLI documentation linked above and other wiki pages for command reference. Then, you use the `set` command to set the bus type, i2c address, lowpass filter frequency/type, baro_hardware, gyro_hardware, etc. This will mainly be dependent on your hardware and will involve a lot of trial and error. Use the `save` command to save your configuration and reboot the controller. If your hardware is not detected, then you need to modify or create more settings in the CLI to accurately describe your hardware to Betaflight to detect it. Use your custom board's and respective peripherals' datasheets and schematics to help you.
Alongside `resource` and `set` commands, there are `timer` and `dma` commands. For certain functions, such as battery voltage monitoring and motor output, you need to associate a timer and/or a Direct Memory Access (DMA) channel to those pins for those to work.
- `# timer`
- `timer <pin> AF(x) [1-3]`
- `# dma`
- `dma [SPI_TX|ADC|pin] [index|pin] [0|1]`
For custom configuration like this outside the normal use-case, it's recommended that you use the pre-made [configs](https://github.com/betaflight/unified-targets/tree/master/configs/default) as a source of reference.

170
docs/Customized Version.md
View file

@ -1,170 +0,0 @@
# Create a Customized Version
The flight controllers have some limitations in space and computing capacity. The developers must decide what features enable and what others disable to create a firmware file that can be used for the major part or users.
For example, the official firmware published to users include support for a lot of brands of transmitters and receivers, but habitually you will use only one. This is necessary for a public version, but the protocols not used are spending space that can be used for other features.
This document gives a little guide of how-to start creating your own version, activating and deactivating features, especially if your flight controller is an older one with not too much space.
Keep in mind that when you create your own firmware you're using a piece of software created by you and can have some bugs that are not present in official version. **You use it at your own risk**.
## Build the firmware
This document is aimed to people who has some knowledge about programming skills and can build its own firmware. You can find information about this process in the [`development`](development/) documentation page.
Once you are able to compile your own firmware, you can continue to the next section of this document.
When you compile the firmware, the `make` process ends with an info summary of the firmware created, something like this:
```
text data bss dec hex filename
126312 1444 18260 146016 23a60 ./obj/main/cleanflight_NAZE.elf
```
The 'text + data' gives you the flash size, and the 'data + bss' is the (static) ram usage. It's recommended to keep the customized version under the values of the unmodified version.
## Commons features for all Flight Controllers
The first file where the developers specify the features that are activated or not for a flight controller, is the `target/common_pre.h`.
This file specifies the features enabled/disabled depending on the memory flash size of the flight controller, or other conditions.
The first interesting part is where it specifies the features activated for all flight controllers. In the actual version, for example:
```
#define USE_CLI
#define USE_RX_PPM
#define USE_RX_PWM
#define USE_SERIALRX
#define USE_SERIALRX_CRSF // Team Black Sheep Crossfire protocol
#define USE_SERIALRX_IBUS // FlySky and Turnigy receivers
#define USE_SERIALRX_SBUS // Frsky and Futaba receivers
#define USE_SERIALRX_SPEKTRUM // SRXL, DSM2 and DSMX protocol
#define USE_SERIALRX_SUMD // Graupner Hott protocol
#define USE_SERIALRX_SUMH // Graupner legacy protocol
#define USE_SERIALRX_XBUS // JR
```
The next part are features enabled if your memory flash size is bigger than 64 megabits.
```
#if (FLASH_SIZE > 64)
#define BLACKBOX
#define LED_STRIP
#define TELEMETRY
#define TELEMETRY_FRSKY
#define TELEMETRY_HOTT
#define TELEMETRY_LTM
#define TELEMETRY_SMARTPORT
#define USE_RESOURCE_MGMT
#define USE_SERVOS
#endif
```
And bigger than 128 megabits:
```
#if (FLASH_SIZE > 128)
#define GPS
#define CMS
#define TELEMETRY_CRSF
#define TELEMETRY_IBUS
#define TELEMETRY_JETIEXBUS
#define TELEMETRY_MAVLINK
#define TELEMETRY_SRXL
#define USE_DASHBOARD
#define USE_MSP_DISPLAYPORT
#define USE_RX_MSP
#define USE_SERIALRX_JETIEXBUS
#define USE_SENSOR_NAMES
#define VTX_COMMON
#define VTX_CONTROL
#define VTX_SMARTAUDIO
#define VTX_TRAMP
#endif
```
Another interesting thing of this file, are others features deactivated by the computing capacity of the flight controller, or the model of the processor. For example:
```
#if (__FPU_PRESENT == 1) && (__FPU_USED == 1)
#define DEFAULT_AUX_CHANNEL_COUNT MAX_AUX_CHANNEL_COUNT
#else
#define DEFAULT_AUX_CHANNEL_COUNT 6
#endif
```
If the flight controller hasn't a FPU (F1 processors for example) you can use only 6 auxiliary channels of the receiver.
After looking carefully to this file, you must know what features you want to disable or enable in your customized build.
*NOTE: It is better to not change this file, but it's useful to see what features you can activate or deactivate in your custom build.*
## Specific features for each Flight Controller
Each flight controller has its own file to specify what features are enabled or disabled only for it. Sometimes they have been disabled by space limitations, but other times it's for limited computing capacity or a bug, so enable them at your own risk.
This file is located in `target/[FLIGHT_CONTROLLER_NAME]/target.h` and it's loaded **after** the `target/common_pre.h`. Any changes in this file will overwrite the default settings, so this file is the place where you must touch to create your custom firmware.
The first thing to do is to *#undef* all the features that we want to disable from the *common_pre.h*.
For example, in a NAZE32, if we're using Serial RX, with a FlySky receiver (that uses de iBus protocol) and we don't have a led strip we will add all this *#undef* to the file.
```
#undef USE_RX_PPM
#undef USE_RX_PWM
#undef USE_SERIALRX_CRSF // Team Black Sheep Crossfire protocol
#undef USE_SERIALRX_SBUS // Frsky and Futaba receivers
#undef USE_SERIALRX_SPEKTRUM // SRXL, DSM2 and DSMX protocol
#undef USE_SERIALRX_SUMD // Graupner Hott protocol
#undef USE_SERIALRX_SUMH // Graupner legacy protocol
#undef USE_SERIALRX_XBUS // JR
#undef LED_STRIP
#undef TELEMETRY_FRSKY
#undef TELEMETRY_HOTT
#undef TELEMETRY_LTM
#undef TELEMETRY_SMARTPORT
#undef USE_SERVOS
```
With this change, we have won space to add some missing features. With this space, we will add GPS and telemetry by iBus too, adding some *#define* that are only activated by default for flight controllers with more than 128 megabits:
```
#define GPS
#define TELEMETRY_IBUS
```
Be careful, some features are dependent, for example, the `TELEMETRY_IBUS` needs the `TELEMETRY` enabled.
To customize more if needed, this file defines all the hardware supported by different versions of the flight controller, for example, in the `NAZE` file:
```
#define GYRO
#define USE_GYRO_MPU3050
#define USE_GYRO_MPU6050
#define USE_GYRO_MPU6500
#define USE_GYRO_SPI_MPU6500
#define ACC
#define USE_ACC_ADXL345
#define USE_ACC_BMA280
#define USE_ACC_MMA8452
#define USE_ACC_MPU6050
#define USE_ACC_MPU6500
#define USE_ACC_SPI_MPU6500
#define BARO
#define USE_BARO_MS5611 // needed for Flip32 board
#define USE_BARO_BMP280
```
Here you have different gyroscopes, accelerometers and barometers defined, to support all the variants of the flight controller. You can comment all the models that you're sure that your flight controller is not using and you will get some free space.
You can find too some features disabled for this flight controller, in this case, for example:
```
/*
#define MAG
#define USE_MAG_HMC5883
#define MAG_HMC5883_ALIGN CW180_DEG
*/
```
The magnetometer is commented. If you uncomment it, then it will be activated and you can use it in the NAZE flight controller.
After modifying this file, you only need to build your firmware again and you will have your own customized version with all and only the features that you need.
## Final considerations
As has been said several times in this document, when you activate a feature disabled by the developers, you can overcharge the processor, or include a bug in your firmware version. **So be careful and do it at your own risk**.

72
docs/Display.md
View file

@ -1,72 +0,0 @@
# Display
Cleanflight supports displays to provide information to you about your aircraft and cleanflight state.
When the aircraft is armed the display does not update so flight is not affected. When disarmed the display cycles between various pages.
There is currently no way to change the information on the pages, the list of pages or the time between pages - Code submissions via pull-requests are welcomed!
## Supported Hardware
At this time no other displays are supported other than the SSD1306 / UG-2864HSWEG01.
## Configuration
From the CLI enable the `DISPLAY` feature
```
feature DISPLAY
```
### SSD1306 OLED displays
The SSD1306 display is a 128x64 OLED display that is visible in full sunlight, small and consumes very little current.
This makes it ideal for aircraft use.
There are various models of SSD1306 boards out there, they are not all equal and some require addtional modifications
before they work. Choose wisely!
Links to displays:
* [banggood.com](http://www.banggood.com/0_96-Inch-4Pin-White-IIC-I2C-OLED-Display-Module-12864-LED-For-Arduino-p-958196.html) 0.96 Inch 4Pin White IIC I2C OLED Display Module 12864 LED For Arduino
* [banggood.com](http://www.banggood.com/0_96-Inch-4Pin-IIC-I2C-Blue-OLED-Display-Module-For-Arduino-p-969147.html) 0.96 Inch 4Pin IIC I2C Blue OLED Display Module For Arduino
* [wide.hk](http://www.wide.hk/products.php?product=I2C-0.96%22-OLED-display-module-%28-compatible-Arduino-%29) I2C 0.96" OLED display module
* [witespyquad.gostorego.com](http://witespyquad.gostorego.com/accessories/readytofly-1-oled-128x64-pid-tuning-display-i2c.html) ReadyToFlyQuads 1" OLED Display
* [multiwiicopter.com](http://www.multiwiicopter.com/products/1-oled) PARIS 1" OLED 128x64 PID tuning screen AIR
The banggood.com display is the cheapest at the time fo writing and will correctly send I2C ACK signals.
#### Crius CO-16
This display is best avoided but will work if you modify it.
Step 1
As supplied the I2C ack signal is not sent because the manufacturer did not bridge D1 and D2 together. To fix this solder
the two pins together as they enter the screen. Failure to do this will result is a screen that doesn't display anything.
Step 2
Pin 14 must be disconnected from the main board using a scalpel. Then connect a 10nF or 100nF capacitor between pins 30 and the
lifted pin 14.
Step 3
Connect a 100K resistor between Pin 9 and the lifted Pin 14.
Failure to perform steps 2 and 3 will result in a display that only works on power up some of the time any may display random dots
or other display corruption.
More can be read about this procedure here: http://www.multiwii.com/forum/viewtopic.php?f=6&t=2705&start=10
![Crius CO-16 Diagram](Wiring/Crius%20CO-16%20OLED%20diagram.png)
![Crius CO-16 Modification](Wiring/Crius%20CO-16%20OLED%20modifications.jpg)
## Connections
Connect +5v, Ground, I2C SDA and I2C SCL from the flight controller to the display.
On Naze32 rev 5 boards the SDA and SCL pads are underneath the board.

107
docs/EXST bootloader.md
View file

@ -1,107 +0,0 @@
# EXST bootloader
The EXST (External Storage) system requires that the targets' CPU has a small program, called a bootloader, that provides functionality to load firmware from an external storage into the CPU's RAM so that the firmware can be executed.
Example external storage systems include:
* External Flash using Firmware Partition
* File on an SD card.
EXST targets also have the requirement of providing a mechansim to load and save configuration ('eeprom'). options for this include:
* CPU Embedded flash page.
* External Flash using Config Partition
* File on an SD card.
Since external storage systems can become corrupted, and communication errors can occur, Bootloaders should verify correct loading of the firmware from an external storage system, or after transferring via a debugger. An hash is provided for this purpose.
Bootloaders are not limited to just one storage system.
Bootloaders may offer additional functionality, such as:
* a means to update the firmware on an external storage medium (e.g. via DFU)
* update one external storage system from another (i.e. update external flash from file on SD card)
* backup, select, swap or erase firmware
* backup, select, swap or erase configuration.
Users should consult the manual that came with their EXST bootloader-equipped flight controller for details on how to use any such features.
The build system provides a way to build files suitable for transferring onto an external storage medium via the standard 'bin'/'hex' make goals.
```
make TARGET=<targetname>
```
This results in the usual `*.bin` and `*.hex` files and also a `*_EXST.elf` file which have been patched to contain information required for bootloader operation.
The `.bin` file is a binary file which should be transferred to the storage medium and is suitable for distribution.
The `.hex` file is a hex file which can be used by tools for uploading to a bootloader and is suitable for distribution.
For developers there is a `_EXST.elf` file which is a standard `.elf` file that has had one section replaced, this file is suitable for uploading to targets using a debugger such as GDB.
For details on the memory sections used refer to the linker files.
## EXST format
The format for EXST targets is as follows:
* Firmware.
* Bootloader block.
The bootloader block is 64 bytes.
For example a 448K EXST `.bin` file is comprised as follows:
| Start Address | End address | Usage |
| ------------- | ----------- | ---------------- |
| 0x00000 | 0x6FFBF | Firmware section |
| 0x6FFC0 | 0x6FFFF | Bootloader block |
## EXST bootloader block
The bootloader block is comprised as follows:
| Start Address | End address | Usage |
| ------------- | ----------- | ---------------- |
| 0x00 | 0x00 | Block Format |
| 0x01 | 0x3F | Block Content |
Block Formats
| Value | Meaning |
| ----- | ----------------- |
| 0x00 | Block format 0x00 |
### Block Format 0x00 Content
Note: addresses relative to start of bootloader block
| Start Address | End address | Usage |
| ------------- | ----------- | ---------------- |
| 0x01 | 0x01 | Checksum/Hash method |
| 0x02 | 0x2F | Reserved, fill with 0x00 |
| 0x30 | 0x3F | Checksum value, pad with trailing 0x00 |
Checksum Hash methods
| Value | Meaning |
| ----- | ---------------- |
| 0x00 | No checksum. |
| 0x01 | MD5. |
Checksum locations:
| Start Address | End address | Usage |
| ------------- | ----------- | ---------------- |
| 0x30 | 0x3F | MD5 hash of firmware section |
The bootloader should make no attempt to use any reserved area otherwise this prevents it's future use by the firmware.
The bootloader should ensure this block is in RAM when the firmware is loaded. i.e. copy the entire EXST image.
As the reserved area is under control of the build system, not the bootloader, additional information can stored there for use by the firmware or future bootloaders. Extreme care must be taken not to break the bootloaders ability to load firmware. Consultation with the developers for any changes to this area is required.
### Example possible future enhancements for the EXST bootloader block
* Hardware layout identification - to allow the firmware to identify the hardware, such that IO pins and peripherals can be reserved/initialised.
* Alternative hashes/CRCs.

289
docs/Failsafe.md
View file

@ -1,289 +0,0 @@
# Failsafe
If the radio link is lost, or the receiver fails or becomes disconnected, the pilot will have no control over their aircraft.
Betaflight provides a failsafe system to safely manage this potential hazard.
**_It is vitally important to check that your failsafe system is working properly before flying!_**
There are two types of failsafe:
1. Receiver based failsafe
2. Flight controller based failsafe
__Receiver based failsafe__ is where your transmitter configures the receiver to output specific signals on specific channels if your receiver loses signal. The receiver sends 'normal-looking' data packets to the flight controller, containing the exact values that you configured, in the radio, for throttle and other channels. Normally these are configured so that the aircraft either cuts motors and falls, or descends in a controlled manner. See your receiver's documentation for this method. The flight controller will be unaware that anything bad is happening, and you will not see anything in the OSD.
__Flight controller based failsafe__ is where the flight controller attempts to detect signal loss by analysing the received data packets, then responding according to failsafe settings made in the Configurator, and provides some indication of what is going on in the OSD and in the logs. There are three phases:
- signal validation
- failsafe stage 1
- failsafe stage 2
After basic signal validation fails, the flight controller holds the last known good values for 300ms. It then enters __Failsafe Stage 1__, the 'Guard' period, and applies your specified __Channel Fallback Settings__ for the `failsafe_delay` period (1.5s by default) counted from the time of the last valid packet. If any valid data arrives while in Stage 1, the flight controller will respond to it immediately, and the failsafe process stops.
If the failsafe duration exceeds the __Failsafe Stage 1__ or "Guard" period, the flight controller enters __Failsafe Stage 2__. This either immediately disarms and drops, or enters a customisable Landing Mode or a GPS Rescue Mode. After Stage 2 Failsafe, the signal must be consistently good for a period of time before control is returned to the pilot.
Flight controller based failsafe relies, for its triggering signal, on the absence of valid data from the radio receiver. If the receiver is configured to keep sending 'normal' packets on signal loss, the flight controller will never enter 'flight controller failsafe'. Hence, it is essential that the receiver is configured to send __nothing__ (no packets at all) on signal loss.
Flight controller failsafe will work if your receiver signal wires come loose, break, or your receiver malfunctions in a way the receiver itself cannot detect.
A transmitter switch may be configured to immediately activate failsafe. This is useful for field testing the failsafe system and as a **_`PANIC`_** switch when you lose orientation.
## Flight controller failsafe system
This system continuously monitors the integrity of the radio link, and has two stages that apply sequentially after signal loss is confirmed.
### Signal Loss
__Signal loss__ means:
- __no incoming data packets__, or __failsafe mode__ or __frame dropped__ packets for more than 100ms, or
- __*invalid pulse length*__ data on any flight channel for more than 300ms.
Once signal loss is detected, the values on the bad channels, or on all channels for total packet loss, will be held at their last received value for 300ms from the last known good data, or until signal returns.
`RXLOSS` should be displayed in the warnings field of the OSD 100ms after the last valid packet. This is an 'early warning' of significant packet loss - an indicator that the link is in a bad way.
When failsafe is initiated by a failsafe switch that has been configured to to enter Stage 1, the flight channels (Roll, Pitch, Yaw and Throttle), but not the auxiliary channels, are immediately set to Stage 1 values, without any delay.
### Stage 1 Failsafe
__Stage 1__ applies fixed values after confirmed signal loss.
__The default Stage 1 duration__ is one second, with a minimum of 200ms. The timer for initiation of stage 1 is activated when 100ms has elapsed since the last good packet, or 300ms after any persistently bad flight channel, but it starts timing down to failsafe from the time of the last good packet. The Stage 1 duration may be customised via the "Guard time for stage 2 activation" parameter in Configurator (`failsafe_delay` in the CLI). It starts at the time of the last good packet. The units are tenths of a second.
__During Stage 1 failsafe__, all stick positions are set to the fixed 'fallback' values as specified in the 'Channel fallback settings' panel in Configurator, after the 300ms 'hold last good values' period expires. When initiated by a switch, the aux channels remain active, and there is no hold period - the effect is immediate Default behaviour is to center the sticks, set throttle stick to zero (causing the motors to idle), and hold the existing switch positions. These values may be be customised in Configurator or with the CLI command `rxfail` (see [rxfail](Rx.md#rx-loss-configuration) section in rx documentation) or v.
The pilot may choose to active Level mode, using an Aux channel, so that it becomes active soon as Stage 1 commences.
The flight mode field in the OSD does *not* show failsafe with `!FS!` during stage 1, but `RXLOSS` will show in the warnings section after the 100ms basic signal validation period, to provide early warning of a bad link or impending failsafe.
__If signal returns during either the hold or Stage 1 period__, control is immediately returned to the pilot, the failsafe system resets. `RXLOSS` should immediately disappear from the OSD.
> Note: the PID system remains active in Stage 1.
__Stage 1 can also be activated by a transmitter switch__. The switch should be configured (using Modes) to enable failsafe, and the `failsafe_switch_mode` should be set to `STAGE1`.
The switch emulates a signal loss, but there are some differences.
The main difference is that channels go immediately to Stage 1 values without waiting for any hold or signal evaluation periods.
While in Stage 1, returning the switch to the OFF position will restore normal control immediately, just like re-gaining signal during Stage 1.
Note that if the switch is held ON for longer than the `failsafe_delay` period, the flight controller will enter Stage 2 (see below), and, depending on how Stage 2 is configured, may immediately drop and disarm, from which recovery will not be immediate.
With switch-initiated failsafe, the auxiliary channels must remain responsive so that the pilot can exit failsafe with the switch Hence they are not set 'Channel fallback settings' to the Aux channels. This is different from a true 'signal lost' type failsafe, where the Aux channels are fixed, according to the Guard period settings.
### Stage 2 Failsafe
__Stage 2 Failsafe__ is entered when your craft is __armed__ and __stage 1__ persists longer then the configured Stage 1, or 'guard' time (`failsafe_delay`), or, by switch.
During Stage 2, all channels will remain at the fallback settings, unless overruled by the chosen Stage 2 procedure (the settings of the `failsafe_procedure`).
> During Stage 2,`!FS!` will be shown in the Flight Mode field of the OSD.
Entering Stage 2 is not possible until 5 seconds after the flight controller boots up. This is to prevent unwanted activation, as in the case of TX/RX gear with long bind procedures, before the RX sends out valid data.
Stage 2 Failsafe can be activated directly, and immediately, with a transmitter failsafe switch where the switch behaviour is set to `STAGE2` (`failsafe_switch_mode` in the CLI).
Stage 2 will also be activated if the switch is set to Stage 1 and it is held for longer than the Stage 1 time (the Stage 2 'guard time').
When the flight contoller enters Stage 2, it implements one of three (actually, four) possible Stage 2 failsafe procedures::
* __Drop__, the default, causing immediate disarm and motor stop.
* __Landing Mode__, where the sticks are centered, throttle is held at a defined value, and the aux channels are set as configured for Stage 1 (which could include configuring an aux channel to enable Level mode). These settings will apply for the Landing Time (`failsafe_off_delay` period), which defaults to 1 second, but can be longer. Landing mode can be hazardous, since the motors and PIDs are active, but you cannot control where the quad goes, and there is no way to make the motors stop if you crash. If the machine crashes and the props get stuck, they can burn out.
* __GPS Rescue__, where an appropriately configured machine will transfer stick and throttle control to the GPS controller, so that the quad should try to fly towards its starting point.
* __Just Disarm__, a 'fourth' internal mode, which applies if the throttle has been held low for at least 10 seconds before entering Stage 2 (unless the mode is set to GPS Return). This can sometimes cause confusion when testing failsafe - always test with throttle up at some point before the test. Its primary purpose is to force a disarm if the user powers down their radio after landing, but has forgotten to remove the lipo. This prevents the quad entering landing mode, for example, and spinning the props up by itself
At the end of the stage 2 procedure, the flight controller will disarm. The word `FAILSAFE` will alternate with `RXLOSS` in the warnings field. Arming will be blocked until the signal from the receiver is restored for more than the `failsafe_recovery_delay` period. This period is the same regardless of the Stage 2 mode.
Control will be returned to the pilot:
* in Landing mode, when the RC signal has recovered for longer than the `failsafe_recovery_delay` period, or
* in GPS Rescue mode, when the link has returned for `failsafe_recovery_delay` and the pilot has moved the sticks more than 30 degrees out from centre.
* a transmitter failsafe Stage 2 switch that was set to ON is turned OFF (unless the `failsafe_switch_mode` is _not_ set to `KILL`).
__There is no way to instantly recover from a Drop or Just Disarm outcome__. The quad will disarm and fall with zero motor power. The pilot must re-arm, after the `failsafe_recovery_delay` period, to regain control. The usual arming checks apply; arming switches must be off, throttle must be zero, and if the accelerometer is enabled, the quad must be within the 'small_ _angle' range.
### The default Drop mode
The default signal loss behaviour with one second of stage 1 'guard time' is:
- 300ms holding last values
- the next 1200ms at idle throttle with sticks centred (the default fallback settings)
- followed by disarm and drop at 1s.
Recovery within the Stage 1 time is immediate, but if Stage 2 completes to disarm, the defaultRecovery time of one second will block arming for one full second.
The defaults are typically used by racers and park fliers.
The `failsafe_delay`, or guard time, should be long enough that a brief Rx loss will be tolerated without leading to a disarm. It should reflect the reliability of your link, vs how long it typically takes before you hit the ground. If you crash within the guard time, the PIDs may cook your motors.
Shorter guard times will stop the motors more quickly when signal is lost. In practice the minimum is 200ms. Any shorter and you are vulnerable to false failsafes from brief signal loss.
The default of 1.5s is a good guard time.
The `failsafe_recovery_delay` is how long the signal must be 'good' for before you're allowed to re-arm after being disarmed by the Drop. By default this is one second. For many setups this time can be a lot shorter. However, some radio links can be erratic when they recover, so don't make it too short without first checking that the quad doesn't go bezerk when the signal recovers.
### Landing mode
This can be used to apply, after the Stage 1 or Guard period expires. a defined set of Aux switch settings and stick values for a set period of time.
Historically, this was used to enable Level mode, and apply sufficient throttle for a gradual fall from a typical flight altitude. It had a role when people would hover at a consistent altitude and not do much else, potentially minimising the damage from a crash from altitude.
However, it is s a potentially hazardous thing to do, and not generally recommended, because the quad will fall with active PIDs and will drift with the breeze, potentially landing almost anywhere. The motors may be active when it hits the ground, and could burn them out, and the quad could land on top of people with throttle on and fully active PIDs.
We do not recommend this anymore.
You will regain normal flight control during landing mode after signal restores for more than the `failsafe_recovery_delay` period.
You will regain the ability to re-arm after landing mode terminates and disarms, after the signal has been restored for more than the `failsafe_recovery_delay` period.
__Configuring Landing Mode.__
1. Enable Landing Mode as opposed to Drop as the failsafe procedure
2. Set `failsafe_off_delay` to an appropriate value based on how high you fly (how long you think it will take to land at the set throttle value).
3. Set `failsafe_throttle` to a value that allows the aircraft to descend at approximately one meter per second (default is 1000 which should be throttle off).
The behaviour with default one second of stage 1 'guard time' and a 10s Landing time is:
- 300ms holding last values
- the next 1,200ms at idle throttle with sticks centred (the default fallback settings)
- 10s of landing throttle
- your Stage 1 Aux switch values applied
### GPS Return mode
The full details of GPS return are covered in the wiki, and elsewhere.
You will regain during GPS Return mode only after signal restores for more than the `failsafe_recovery_delay` period AND you move the sticks more than 30 degrees out from centre.
You will regain the ability to re-arm after GPS Return terminates and disarms, after the signal has been restored for more than the `failsafe_recovery_delay` period.
### "Just Drop" mode
This is an 'invisible' mode that is always present.
It is intended to 'catch' the possibility that the pilot has landed, forgotten to disarm, and powered off their transmitter. This would result in a failsafe, and if landing mode was active, the motors could spin up.
"Just Drop" looks at the throttle position, and if it has been down for 10s before turning the transmitter off, the failsafe system will immediately disarm the quad, and not enter landing mode. This protects the pilot, so long as they have throttle low for 10s before switching the radio off.
### General Stage 2 SAFETY Considerations
* The failsafe system will activate and de-activate without regard to the current throttle or stick position. When the failsafe intervention is aborted (RC signal restored/failsafe switch set to OFF) the current throttle and stick positions will be applied to the craft!
* If you land and turn your transmitter off before powering down your quad, it could be on the ground with motors stopped, and those motors and props could spin again. Take care when using `Landing Mode`, particularly with the `MOTOR_STOP` feature. **The props may spin up without warning**, when failsafe activates in Landing mode!
* In 4.3 re-arming is possible, after a failsafe, without needing to power cycle the quad, so that if you crash after failsafe in an inaccessible area, you can perhaps get close enough to regain signal and fly out.
## Failsafe Settings
Failsafe delays are configured in 0.1 second steps.
1 step = 0.1sec
1 second = 10 steps
### `failsafe_delay`
Guard time, or Failsafe Stage 1 period; the time before for failsafe Stage 2 activation after a lost signal. This is the amount of time the flight controller waits, after a signal loss, before activating Stage 2 failsafe.
### `failsafe_off_delay`
The time from when Landing Mode activates to when the motors finally turn off. Throttle will be at 'failsafe_throttle' for this period of time. If you fly at higher altitudes you may need more time to descend safely.
### `failsafe_throttle`
Throttle level used for landing. Specify a value that causes the aircraft to descend at about 1M/sec (relatively slowly). Default is set to 1000 which should correspond to throttle off.
### `failsafe_switch_mode`
Configure the RC switched failsafe action. It can be one of:
* `STAGE1` - activates Stage 1 failsafe. RC controls are applied as configured for Stage 1 and the `failsafe_delay` guard time will have to elapse before Stage 2 is activated. This is useful if you want to simulate signal loss failsafe behavior. Note that there are some differences. There is no 300ms 'hold' time; the flight channels (RPY&T) go directly to Stage 1 settings the moment the switch goes ON. Also, the Auxiliary channels remain active, and are not set to the Stage 1 values. Recovery of signal immediately restores full pilot control.
* `STAGE2` - skips Stage 1 and immediately activates the selected Stage 2 procedure. Useful if you want to assign instant auto-landing, GPS Return, or Drop, to a switch.
* `KILL` - immediately disarms the quad with no delay. Your craft will crash. Note that a single glitch on the failsafe channel will immediately crash the quad. Re-arming is blocked for 1 second after signal is restored. A similar, but safer effect can be achieved by:
* setting `failsafe_switch_mode` to `STAGE2`, `failsafe_procedure` to `DROP`, and `failsafe delay` to 2. This gives a 200ms delay signal validation period, the shortest allowed, so that transient glitches on the failsafe channel will not falsely trigger a disarm. Drop recovery can be made faster than Kill by configuring a short `failsafe_recovery_delay` time (which can be as short as 200ms).
* using the arm switch. This does not introduce re-arming locking.
### `failsafe_throttle_low_delay`
Time throttle level must have been below 'min_throttle' to _only disarm_ instead of _full failsafe procedure_.
Use standard RX μs values. See [Rx documentation](Rx.md).
### `failsafe_procedure`
* `DROP`: Just kill the motors and disarm (crash the craft). Re-arming is locked until RC link is available for at least 3 seconds and the arm switch (if used) is in the OFF position.
* `AUTO-LAND`: Enable an auto-level mode, center the flight sticks and set the throttle to a predefined value (`failsafe_throttle`) for a predefined time (`failsafe_off_delay`). This should allow the craft to come to a safer landing. Re-arming is locked until RC link is available for at least 30 seconds and the arm switch (if used) is in the OFF position.
### `failsafe_recovery_delay`
Time for a recovered signal to be considered valid. In Failsafe Landing Mode, signal must be 'good' for at least this time for control to be returned to the pilot. In GPS Return mode, this time is required before the stick inputs will be assessed for the restoration of control.
### `failsafe_stick_threshold`
For GPS Return, the angle in degrees that the sticks must be away from centre in order to return control to the pilot, assuming the signal has already recovered.
The idea is that as the quad flies home, the pilot leaves the sticks centred. Once they get video back, and see that Rx signal has returned, moving the sticks allows the pilot to regain control at a time that suits them, rather than just immediately signal returns.
### `rx_min_usec`
The lowest channel value considered valid. e.g. PWM/PPM pulse length
### `rx_max_usec`
The highest channel value considered valid. e.g. PWM/PPM pulse length
The `rx_min_usec` and `rx_max_usec` settings helps detect when your RX stops sending any data, enters failsafe mode or when the RX looses signal.
With a Graupner GR-24 configured for PWM output with failsafe on channels 1-4 set to OFF in the receiver settings then this setting, at its default value, will allow failsafe to be activated.
## Testing failsafe
**Bench test of Stage 1 - _remove the props!_.**
1. Set the Guard, or stage 1 time, to 10s (100)
1. Set the Stage 2 procedure to Drop
1. Arm the craft and throttle up briefly
1. While wiggling the sticks, listen to the motors, and throttle off
1. Confirm that motors hold RPM for 300ms, then drop to idle and stay there
1. Note that RXLOSS appears in the OSD immediately the link is lost
1. Power up the transmitter, wiggle the pitch/roll stick while it re-establishes the link
1. Confirm that the motors start responding about 1s after the link is re-established
**Bench test the failsafe system before flying - _remove props while doing so_.**
1. Configure failsafe
1. Arm the craft and throttle up briefly
1. Either turn the transmitter off, or unplug the RX.
1. Observe motors spin at configured throttle setting for configured duration.
1. Observe motors turn off after configured duration.
1. Power cycle the FC.
1. Arm the craft.
1. Configure a long Stage 2 Landing Time (eg 200 or 20s) and enable Landing mode
1. Turn off transmitter or unplug RX.
1. Observe motors spin at configured Landing throttle setting.
1. Turn on TX or reconnect RX before Landing times out
1. Ensure that your switch positions don't now cause the craft to disarm (otherwise it would fall out of the sky on regained signal).
1. Observe that normal flight behavior is resumed.
1. Disarm.
**Field test of Landing Mode.**
1. Perform bench testing first!
1. On a calm day go to an unpopulated area away from buildings or test indoors in a safe controlled environment - e.g. inside a big net.
1. Arm the craft.
1. Hover over something soft (long grass, ferns, heather, foam, etc.).
1. Descend the craft and observe throttle position and record throttle value from your TX channel monitor. Ideally 1500 should be hover. So your value should be less than 1500.
1. Stop, disarm.
1. Set failsafe throttle to the recorded value.
1. Arm, hover over something soft again.
1. Turn off TX (!)
1. Observe craft descends and motors continue to spin for the configured duration.
1. Observe FC disarms after the configured duration.
1. Remove flight battery.
If craft descends too quickly then increase failsafe throttle setting.
Ensure that the duration is long enough for your craft to land from the altitudes you normally fly at.
Using a configured transmitter switch to activate failsafe mode, instead of switching off your TX, is good primary testing method in addition to the above procedure.

162
docs/Failsafe_before_4.3.md
View file

@ -1,162 +0,0 @@
# Failsafe
There are two types of failsafe:
1. Receiver based failsafe
2. Flight controller based failsafe
Receiver based failsafe is where you, from your transmitter and receiver, configure channels to output desired signals if your receiver detects signal loss and goes to the __failsafe mode__. The idea is that you set throttle and other controls so the aircraft descends in a controlled manner. See your receiver's documentation for this method.
Flight controller based failsafe is where the flight controller attempts to detect signal loss and/or the __failsafe mode__ of your receiver and upon detection goes to __failsafe stage 1__. The idea is that the flight controller starts using __fallback settings__ for all controls, which are set by you, using the CLI command `rxfail` (see [rxfail](Rx.md#rx-loss-configuration) section in rx documentation) or the cleanflight-configurator GUI.
It is possible to use both types at the same time, which may be desirable. Flight controller failsafe can even help if your receiver signal wires come loose, get damaged or your receiver malfunctions in a way the receiver itself cannot detect.
Alternatively you may configure a transmitter switch to activate failsafe mode. This is useful for fieldtesting the failsafe system and as a **_`PANIC`_** switch when you lose orientation.
## Flight controller failsafe system
This system has two stages.
__Stage 1__ is entered when __a flightchannel__ has an __*invalid pulse length*__, the receiver reports __*failsafe mode*__ or there is __*no signal*__ from the receiver. Fallback settings are applied to __*all channels*__ and a short amount of time is provided to allow for recovery.
__Note:__ Prior to entering __stage 1__, fallback settings are also applied to __*individual AUX channels*__ that have invalid pulses.
__Stage 1__ can also directly be activated when a transmitter switch that is configured to control the failsafe mode is switched ON and `failsafe_switch_mode` is set to `STAGE1`. Stage 1 will be aborted if the switch is moved to the OFF position before Stage 2 is engaged (see next).
__Stage 2__ is entered when your craft is __armed__ and __stage 1__ persists longer then the configured guard time (`failsafe_delay`). All channels will remain at the applied fallback setting unless overruled by the chosen stage 2 procedure (`failsafe_procedure`).
__Stage 2__ is not activated until 5 seconds after the flight controller boots up. This is to prevent unwanted activation, as in the case of TX/RX gear with long bind procedures, before the RX sends out valid data.
__Stage 2__ can also directly be activated when a transmitter switch that is configured to control the failsafe mode is switched ON and `failsafe_switch_mode` is set to `STAGE2`.
__Stage 2__ will be aborted when it was due to:
* a lost RC signal and the RC signal has recovered.
* a transmitter failsafe switch was set to ON position and the switch is set to OFF position (and `failsafe_switch_mode` is _not_ set to `KILL`).
Note that:
* At the end of the stage 2 procedure, the flight controller will be disarmed and re-arming will be locked until the signal from the receiver is restored for specific amount of time depending on the procedure (see below) AND the arming switch is in the OFF position (when an arm switch is in use).
* Prior to starting a stage 2 intervention it is checked if the throttle position was below `min_throttle` level for the last `failsafe_throttle_low_delay` seconds. If it was, the craft is assumed to be on the ground and is only disarmed. It may be re-armed without a power cycle.
Some notes about **SAFETY**:
* The failsafe system will be activated regardless of current throttle position. So when the failsafe intervention is aborted (RC signal restored/failsafe switch set to OFF) the current stick position will direct the craft !
* The craft may already be on the ground with motors stopped and that motors and props could spin again - the software does not currently detect if the craft is on the ground. Take care when using `MOTOR_STOP` feature. **Props will spin up without warning**, when armed with `MOTOR_STOP` feature ON (props are not spinning) **_and_** failsafe is activated !
## Configuration
When configuring the flight controller failsafe, use the following steps:
1. Configure your receiver to do one of the following:
* Upon signal loss, send no signal/pulses over the channels
* Send an invalid signal over the channels (for example, send values lower than `rx_min_usec`)
and
* Ensure your receiver does not send out channel data that would cause a disarm by switch or sticks to be registered by the FC. This is especially important for those using a switch to arm.
See your receiver's documentation for direction on how to accomplish one of these.
* Configure one of the transmitter switches to activate the failsafe mode.
2. Set `failsafe_off_delay` to an appropriate value based on how high you fly
3. Set `failsafe_throttle` to a value that allows the aircraft to descend at approximately one meter per second (default is 1000 which should be throttle off).
These are the basic steps for flight controller failsafe configuration; see Failsafe Settings below for additional settings that may be changed.
## Failsafe Settings
Failsafe delays are configured in 0.1 second steps.
1 step = 0.1sec
1 second = 10 steps
### `failsafe_delay`
Guard time for failsafe activation after signal lost. This is the amount of time the flight controller waits to see if it begins receiving a valid signal again before activating failsafe.
### `failsafe_off_delay`
Delay after failsafe activates before motors finally turn off. This is the amount of time 'failsafe_throttle' is active. If you fly at higher altitudes you may need more time to descend safely.
### `failsafe_throttle`
Throttle level used for landing. Specify a value that causes the aircraft to descend at about 1M/sec. Default is set to 1000 which should correspond to throttle off.
### `failsafe_switch_mode`
Configure the RC switched failsafe action. It can be one of:
* `STAGE1` - activates Stage 1 failsafe. RC controls are applied as configured for Stage 1 and the `failsafe_delay` guard time will have to elapse before Stage 2 is activated. This is useful if you want to simulate with a switch the exact signal loss failsafe behavior.
* `STAGE2` - skips Stage 1 and activates the Stage 2 procedure immediately (see `failsafe_procedure`). Useful if you want to assign instant auto-landing to a switch.
* `KILL` - disarms instantly (your craft will crash). Re-arming is locked for 1 second AND until the arming switch (if used) is moved to the OFF position. Similar effect can be achieved by:
* setting `failsafe_switch_mode` to `STAGE2` and `failsafe_procedure` to `DROP`. The difference is that `DROP` locks re-arming for 3 seconds instead of 1.
* setting `failsafe_switch_mode` to `STAGE2`, `failsafe_procedure` to `AUTO-LAND`, setting `failsafe_throttle` to 1000 and `failsafe_off_delay` to 0 (basically initiates an auto-landing but cuts it short immediately). This is not preferred method, since the reaction is slower and re-arming will be locked for 30 seconds.
* using arm switch. This does not introduce re-arming locking.
### `failsafe_throttle_low_delay`
Time throttle level must have been below 'min_throttle' to _only disarm_ instead of _full failsafe procedure_.
Use standard RX μs values. See [Rx documentation](Rx.md).
### `failsafe_procedure`
* `DROP`: Just kill the motors and disarm (crash the craft). Re-arming is locked until RC link is available for at least 3 seconds and the arm switch (if used) is in the OFF position.
* `AUTO-LAND`: Enable an auto-level mode, center the flight sticks and set the throttle to a predefined value (`failsafe_throttle`) for a predefined time (`failsafe_off_delay`). This should allow the craft to come to a safer landing. Re-arming is locked until RC link is available for at least 30 seconds and the arm switch (if used) is in the OFF position.
### `rx_min_usec`
The lowest channel value considered valid. e.g. PWM/PPM pulse length
### `rx_max_usec`
The highest channel value considered valid. e.g. PWM/PPM pulse length
The `rx_min_usec` and `rx_max_usec` settings helps detect when your RX stops sending any data, enters failsafe mode or when the RX looses signal.
With a Graupner GR-24 configured for PWM output with failsafe on channels 1-4 set to OFF in the receiver settings then this setting, at its default value, will allow failsafe to be activated.
## Testing
**Bench test the failsafe system before flying - _remove props while doing so_.**
1. Arm the craft.
1. Turn off transmitter or unplug RX.
1. Observe motors spin at configured throttle setting for configured duration.
1. Observe motors turn off after configured duration.
1. Ensure that when you turn on your TX again or reconnect the RX that you cannot re-arm once the motors have stopped.
1. Power cycle the FC.
1. Arm the craft.
1. Turn off transmitter or unplug RX.
1. Observe motors spin at configured throttle setting for configured duration.
1. Turn on TX or reconnect RX.
1. Ensure that your switch positions don't now cause the craft to disarm (otherwise it would fall out of the sky on regained signal).
1. Observe that normal flight behavior is resumed.
1. Disarm.
**Field test the failsafe system.**
1. Perform bench testing first!
1. On a calm day go to an unpopulated area away from buildings or test indoors in a safe controlled environment - e.g. inside a big net.
1. Arm the craft.
1. Hover over something soft (long grass, ferns, heather, foam, etc.).
1. Descend the craft and observe throttle position and record throttle value from your TX channel monitor. Ideally 1500 should be hover. So your value should be less than 1500.
1. Stop, disarm.
1. Set failsafe throttle to the recorded value.
1. Arm, hover over something soft again.
1. Turn off TX (!)
1. Observe craft descends and motors continue to spin for the configured duration.
1. Observe FC disarms after the configured duration.
1. Remove flight battery.
If craft descends too quickly then increase failsafe throttle setting.
Ensure that the duration is long enough for your craft to land at the altitudes you normally fly at.
Using a configured transmitter switch to activate failsafe mode, instead of switching off your TX, is good primary testing method in addition to the above procedure.

90
docs/FrSky SPI RX.md
View file

@ -1,90 +0,0 @@
# The FrSky SPI RX
## Basics
'SPI RX' in Betaflight is a framework that allows for radio chips to be connected directly to the flight controller's MCU, and to be controlled by the firmware. This allows for the implementation of the functionality that controls the radio chip, and translates the received signals into RC control signals as part of the firmware.
This has a number of advantages:
- the RX can be directly added to the flight controller board, allowing for smaller builds (after all, not many people want to use a flight controller _without_ an RX);
- it does not require one or more extra UARTs on the flight controller, and there is no risk of problems caused by a wrong UART configuration;
- it does not require an extra MCU to control the radio chip, and can therefore be produced / sold cheaper;
- since the RX 'firmware' is part of the flight controller firmware, fixes and updates will be applied as part of flight controller firmware updates, eliminating the need for (often cumbersome) RX firmware updates.
But there are also disadvantages:
- a flight controller board will only have one radio chip, and will only be able to support the RC protocols that are using this chip. Changing to a different protocol is often not possible.
## The FrSky SPI RX
This driver uses the SPI RX framework in Betaflight to provide support for the FrSky 2.4 GHz RC protocols, based on a CC2500 radio chip, with additional support for a PA/LNA (power amplifier / low noise amplifier) chip with antenna diversity, in order to provide sufficient power / sensitivity for outdoor flying.
The supported protocols are:
### FrSky D
- 8 channels / 9 ms frame spacing;
- called 'D8' in OpenTX;
- integrated FrSky hub telemetry.
### FrSky X
- 8 channels / 9 ms frame spacing **or** 16 channels / 18 ms frame spacing;
- called 'D16' in OpenTX;
- integrated FrSky SmartPort telemetry (including support for MSP over Smartport / lua scripts in OpenTX);
### FrSky X LBT
- LBT protocol version compatible with EU;
- 8 channels / 9 ms frame spacing **or** 16 channels / 18 ms frame spacing;
- called 'D16' in OpenTX;
- integrated FrSky SmartPort telemetry (including support for MSP over Smartport / lua scripts in OpenTX);
## Configuration
1. in Betaflight configurator, go to the 'Configuration' tab, in 'Receiver' box, select 'SPI RX support' for 'Receiver mode':
![FrSky SPI RX mode selection](assets/images/frsky_spi_rx_mode.png)
2. in the 'SPI Bus Receiver Provider' drop down that appears, select 'FRSKY_D', 'FRSKY_X' or 'FRSKY_X_LBT' (depending on the desired protocol):
![FrSky SPI RX protocol selection](assets/images/frsky_spi_rx_protocol.png)
3. click 'Save & Reboot'. After the reboot, the RX LED will confirm that the FrSky RX is active by blinking slowly;
4. enter bind mode by either:
- pressing the 'Bind' button on the flight controller (if there is one and it's reachable);
- entering CLI, and typing 'bind_rx_spi[Enter]'.
5. the flight controller will indicate that bind mode is active by changing the RX LED to be permanently on. Now, on your TX, enter bind mode for the selected FrSky protocol (see screenshots for OpenTX):
FrSky D protocol:
![FrSky SPI RX FrSky D binding with OpenTX](assets/images/frsky_spi_rx_d_binding.png)
FrSky X and X_LBT protocol:
![FrSky SPI RX FrSky X binding with OpenTX](assets/images/frsky_spi_rx_x_binding.png)
6. Once binding has completed, the flight controller will indicate this by blinking the RX LED slowly. There's no indication on the CLI, but you can observe successful binding by quitting the bind mode on TX, and seeing if `status` doesn't list RXLOSS anymore in "Arming disable flags". A reboot of the flight controller is not required.
## Tips & Tricks
- the RX bind information is stored in the following CLI parameters: `frsky_spi_tx_id` (internal TX id), `frsky_spi_offset` (frequency offset), `frsky_spi_bind_hop_data` (frequency hop sequence), and `frsky_x_rx_num` (RX number; FrSky X only). These are printed as part of a CLI `diff` / `dump`, and will be restored after a firmware update, making it unnecessary to do another bind after the update;
- resetting the above parameters to defaults will 'erase' the binding information;
- the CLI parameter `frsky_spi_autobind` can be enabled to configure the FrSky SPI RX to attempt a bind on every power up. This is mostly useful for demonstration models that should bind to whatever TX is powered up in the vicinity.
## Acknowledgements
- midelic for reverse engineering and reimplementation of the FrSky protocols;
- Eric Freund (eric_fre@hotmail.com) for the design of the first prototype flight controller with FrSky SPI RX.
## Boards with FrSky SPI RX
- [Midelic F3](https://github.com/betaflight/betaflight/wiki/Board-Midelic-F3) (prototype only, not commercially available);
- [Matek F411-ONE](http://www.mateksys.com/?portfolio=f411-one);
- [CrazyBee F3 FR](boards/Board%20-%20CrazyBeeF3FR.md);
- [CrazyBee F4 FR Pro](boards/Board%20-%20CrazyBeeF4FRPro.md);
- [BetaFPV F4]
- more to come...

110
docs/Getting Started.md
View file

@ -1,110 +0,0 @@
# Getting Started
This is a step-by-step guide that can help a person that has never used Cleanflight before set up a flight controller and the aircraft around it for flight. Basic RC knowledge is required, though. A total beginner should first familiarize themselves with concepts and techniques of RC before using this (e.g. basic controls, soldering, transmitter operation etc). One could use [RCGroups](http://www.rcgroups.com/forums/index.php) and/or [the Youtube show FliteTest](https://www.youtube.com/user/flitetest) for this.
DISCLAIMER: This documents is a work in progress. We cannot guarantee the safety or success of your project. At this point the document is only meant to be a helping guide, not an authoritative checklist of everything you should do to be safe and successful. Always exercise common sense, critical thinking and caution.
Read the [Introduction](Introduction.md) chapter for an overview of Cleanflight and how the community works.
## Hardware
NOTE: Flight Controllers are typically equipped with accelerometers. These devices are sensitive to shocks. When the device is not yet installed to an aircraft, it has very little mass by itself. If you drop or bump the controller, a big force will be applied on its accelerometers, which could potentially damage them. Bottom line: Handle the board very carefully until it's installed on an aircraft!
For an overview of the hardware Cleanflight (hereby CF) can run on, see [Boards.md](Boards.md). For information about specific boards, see the board specific documentation.
* Assuming that you have a flight controller board (hereby FC) in hand, you should first read through the manual that it came with. You can skip the details about software setup, as we'll cover that here.
* Decide how you'll connect your receiver by reading the [receiver](Rx.md) chapter, and how many pins you need on the outputs (to connect ESCs and servos) by reading about [Mixers](Mixer.md).
* If you're interested in monitoring your flight battery with CF, see [Battery Monitoring](Battery.md).
* You may want audible feedback from your copter so skim through [Buzzer](Buzzer.md) and mark the pins that will be used.
* Do you want your RC Receiver's RSSI to be sent to the board? [The RSSI chapter](Rssi.md) explains how. You may or may not need to make an additional connection from your Receiver to the FC.
* Would you like to try using a GPS unit to get your aircraft to Loiter or Return-To-Launch? Take a look at the [GPS](Gps.md) and [GPS Tested Hardware](Gps_-_Tested_Hardware.md) chapters.
* You may also want to read the [Serial](Serial.md) chapter to determine what extra devices (such as Blackbox, OSD, Telemetry) you may want to use, and how they should be connected.
* Now that you know what features you are going to use, and which pins you need, you can go ahead and solder them to your board, if they are not soldered already. Soldering only the pins required for the application may save weight and contribute to a neater looking setup, but if you need to use a new feature later you may have to unmount the board from the craft and solder missing pins, so plan accordingly. Before soldering your FC please review a how-to-solder tutorial to avoid expensive mistakes, practice soldering on some scrap before soldering your FC.
* If you are going to use [Oneshot125](Oneshot.md), you may need to enable that on your ESCs using a jumper or flashing them with the latest stable firmware and enable Damped Light in their settings, if it's supported. Refer to the ESCs' documentation or online discussions to determine this.
## Software setup
Now that your board has pins on it, you are ready to connect it to your PC and flash it with CF. Install the Chromium browser or Google Chrome to your PC, if you don't have it already, add the [Cleanflight Configurator](https://chrome.google.com/webstore/detail/cleanflight-configurator/enacoimjcgeinfnnnpajinjgmkahmfgb) to it, and start it.
Then follow these instructions for [Installation](Installation.md) of the firmware to the FC.
## Cleanflight Configuration
Your FC should now be running CF, and you should be able to connect to it using the Configurator. If that is not the case, please go back to the previous sections and follow the steps carefully.
<!--- This next paragraph should probably contain less info, as this info already exists in Configuration.md -->
Now, there are two ways to [configure CF](Configuration.md); via the Configurator's tabs (in a "graphical" way, clicking through and selecting/changing values and tickboxes) and using the [Command Line Interface (CLI)](Cli.md). Some settings may only be configurable using the CLI and some settings are best configured using the GUI (particularly the ports settings, which aren't documented for the CLI as they're not human friendly).
* It is now a good time to setup your RC Receiver and Transmitter. Set the Tx so that it outputs at least 4 channels (Aileron, Elevator, Throttle, Rudder) but preferably more. E.g. you can set channels 5 and 6 to be controlled by 3-position switches, to be used later. Maybe set up EXPO on AIL/ELE/RUD, but you should know that it can also be done in CF's software later. If using RSSI over PPM or PWM, it's now time to configure your Rx to output it on a spare channel.
* Connect the Rx to the FC, and the FC to the PC. You may need to power the Rx through a BEC (its 5V rail - observe polarity!).
* On your PC, connect to the Configurator, and go to the first tab. Check that the board animation is moving properly when you move the actual board. Do an accelerometer calibration.
* Configuration tab: Select your aircraft configuration (e.g. Quad X), and go through each option in the tab to check if relevant for you.
* E.g. you may want to enable ONESHOT125 for Oneshot-capable ESCs.
* You may need RX_PPM if you're using an RC Receiver with PPM output etc.
* If planning to use the battery measurement feature of the FC, check VBAT under Battery Voltage.
* If using analog RSSI, enable that under RSSI. Do not enable this setting if using RSSI injected into the PPM stream.
* Motors will spin by default when the FC is armed. If you don't like this, enable MOTOR_STOP.
* Also, adjust the minimum, middle and maximum throttle according to these guidelines:
* Minimum Throttle - Set this to the minimum throttle level that enables all motors to start reliably. If this is too low, some motors may not start properly after spindowns, which can cause loss of stability and control. A typical value would be 1100.
* Middle Throttle - The throttle level for middle stick position. Many radios use 1500, but some (e.g. Futaba) may use 1520 or other values.
* Maximum Throttle - The maximum throttle level that the ESCs should receive. A typical value would be 2000.
* Minimum Command - This is the "idle" signal level that will be sent to the ESCs when the craft is disarmed, which should not cause the motors to spin. A typical value would be 1000.
* Finally, click Save and Reboot.
* Receiver tab:
* Check that the channel inputs move according to your Tx inputs.
* Check that the Channel map is correct along with the RSSI Channel, if you use that.
* Verify the range of each channel goes from ~1000 to ~2000. See also [controls](Controls.md). and `rx_min_usec` and `rx_max_usec`.
* You can also set EXPO here instead of your Tx.
* Click Save!
* Modes tab: Setup the desired modes. See the [modes](Modes.md) chapter for what each mode does, but for the beginning you mainly need HORIZON, if any.
* Before finishing this section, you should calibrate the ESCs, install the FC to the frame, and connect the RSSI cable, buzzer and battery if you have chosen to use those.
## Final testing and safety
It's important that you have configured CF properly, so that your aircraft does not fly away, or even worse fly into property and people! This is an important step that you should NOT postpone until after your maiden flight. Please do this now, before you head off to the flying field.
* First read the [safety](Safety.md) section.
* Next, learn how to arm your FC, and about other [controls](Controls.md).
* Next up, setup [Failsafe](Failsafe.md). Take your time, do it properly.
* Now, on the bench, without props, test that failsafe works properly, according to the above doc.
* Additionally, test the effect of AIL/ELE input of your Tx. Is the aircraft responding properly? Do the same for RUD input.
* Test the direction of AIL/ELE auto correction. Raise throttle at 30% (no blades!); when you tilt the aircraft, do the motors try to compensate momentarily? This should simulate random wind forces that the FC should counteract
* Test the direction of AIL/ELE auto correction in HORIZON mode. With throttle at 30%, if you tilt the aircraft so that one motor is lowered towards the ground, does it spin up and stay at high RPM until you level it off again? This tests the auto-leveling direction.
If one of these tests fail, do not attempt to fly, but go back to the configuration phase instead. Some channel may need reversing, or the direction of the board is wrong.
## Using it (AKA: Flying)
Go to the field, turn Tx on, place aircraft on the ground, connect flight battery and wait. Arm and fly. Good luck!
If the aircraft won't arm, count the red Warning LED flashes and find out the reason in [Controls](Controls.md).
## Advanced Matters
Some advanced configurations and features are documented in the following pages, but have not been touched-upon earlier:
* [Profiles](Profiles.md)
* [PID tuning](PID%20tuning.md)
* [In-flight Adjustments](Inflight%20Adjustments.md)
* [Blackbox logging](Blackbox.md)
* [Using a Sonar](Sonar.md)
* [Spektrum Bind](Spektrum%20bind.md)
* [Telemetry](Telemetry.md)
* [Using a Display](Display.md)
* [Using a LED strip](LedStrip.md)
* [Migrating from baseflight](Migrating%20from%20baseflight.md)

175
docs/Gps.md
View file

@ -1,175 +0,0 @@
# GPS
GPS features in Cleanflight are experimental. Please share your findings with the developers.
GPS works best if the GPS receiver is mounted above and away from other sources of interference.
The compass/mag sensor should be well away from sources of magnetic interference, e.g. keep it away from power wires, motors, ESCs.
Two GPS protocols are supported. NMEA text and UBLOX binary.
## Configuration
Enable the GPS from the CLI as follows:
1. [configure a serial port to use for GPS.](Serial.md)
1. set your GPS baud rate
1. enable the `feature GPS`
1. set the `gps_provider`
1. connect your GPS to the serial port configured for GPS.
1. save and reboot.
Note: GPS packet loss has been observed at 115200. Try using 57600 if you experience this.
For the connections step check the Board documentation for pins and port numbers.
### GPS Provider
Set the `gps_provider` appropriately, for example `set gps_provider=UBLOX`
| Value |
| -------- |
| NMEA |
| UBLOX |
### GPS Auto configuration
When using UBLOX it is a good idea to use GPS auto configuration so your FC gets the GPS messages it needs.
Enable GPS auto configuration as follows `set gps_auto_config=ON`.
If you are not using GPS auto configuration then ensure your GPS receiver sends out the correct messages at the right frequency. See below for manual UBlox settings.
### SBAS
When using a UBLOX GPS the SBAS mode can be configured using `gps_sbas_mode`.
The default is AUTO.
| Value | Region |
| -------- | ------------- |
| AUTO | Global |
| EGNOS | Europe |
| WAAS | North America |
| MSAS | Asia |
| GAGAN | India |
If you use a regional specific setting you may achieve a faster GPS lock than using AUTO.
This setting only works when `gps_auto_config=ON`
## GPS Receiver Configuration
UBlox GPS units can either be configured using the FC or manually.
### UBlox GPS manual configuration
Use UBox U-Center and connect your GPS to your computer. The CLI `gpspassthrough` command may be of use if you do not have a spare USART to USB adapter.
Note that many boards will not provide +5V from USB to the GPS module, such as the SPRacingF3; if you are using `gpspassthrough` you may need to connect a BEC to the controller if your board permits it, or use a standalone UART adapter. Check your board documentation to see if your GPS port is powered from USB.
Display the Packet Console (so you can see what messages your receiver is sending to your computer).
Display the Configation View.
Navigate to CFG (Configuration)
Select `Revert to default configuration`.
Click `Send`.
At this point you might need to disconnect and reconnect at the default baudrate - probably 9600 baud.
Navigate to PRT (Ports)
Set `Target` to `1 - Uart 1`
Set `Protocol In` to `0+1+2`
Set `Protocol Out` to `0+1`
Set `Buadrate` to `57600` `115200`
Press `Send`
This will immediatly "break" communication to the GPS. Since you haven't saved the new baudrate setting to the non-volatile memory you need to change the baudrate you communicate to the GPS without resetting the GPS. So `Disconnect`, Change baud rate to match, then `Connect`.
Click on `PRT` in the Configuration view again and inspect the packet console to make sure messages are being sent and acknowledged.
Next, to ensure the FC doesn't waste time processing unneeded messages, click on `MSG` and enable the following on UART1 alone with a rate of 1. When changing message target and rates remember to click `Send` after changing each message.:
NAV-POSLLH
NAV-DOP
NAV-SOL
NAV-VELNED
NAV-TIMEUTC
Enable the following on UART1 with a rate of 5, to reduce bandwidth and load on the FC.
NAV-SVINFO
All other message types should be disabled.
Next change the global update rate, click `Rate (Rates)` in the Configuration view.
Set `Measurement period` to `100` ms.
Set `Navigation rate` to `1`.
Click `Send`.
This will cause the GPS receive to send the require messages out 10 times a second. If your GPS receiver cannot be set to use `100`ms try `200`ms (5hz) - this is less precise.
Next change the mode, click `NAV5 (Navigation 5)` in the Configuration View.
Set to `Dynamic Model` to `Pedestrian` and click `Send`.
Next change the SBAS settings. Click `SBAS (SBAS Settings)` in the Configuration View.
Set `Subsystem` to `Enabled`.
Set `PRN Codes` to `Auto-Scan`.
Click `Send`.
Finally, we need to save the configuration.
Click `CFG (Configuration` in the Configuration View.
Select `Save current configuration` and click `Send`.
### UBlox Navigation model
Cleanflight will use `Pedestrian` when gps auto config is used.
From the UBlox documentation:
* Pedestrian - Applications with low acceleration and speed, e.g. how a pedestrian would move. Low acceleration assumed. MAX Altitude [m]: 9000, MAX Velocity [m/s]: 30, MAX Vertical, Velocity [m/s]: 20, Sanity check type: Altitude and Velocity, Max Position Deviation: Small.
* Portable - Applications with low acceleration, e.g. portable devices. Suitable for most situations. MAX Altitude [m]: 12000, MAX Velocity [m/s]: 310, MAX Vertical Velocity [m/s]: 50, Sanity check type: Altitude and Velocity, Max Position Deviation: Medium.
* Airborne < 1G - Used for applications with a higher dynamic range and vertical acceleration than a passenger car. No 2D position fixes supported. MAX Altitude [m]: 50000, MAX Velocity [m/s]: 100, MAX Vertical Velocity [m/s]: 100, Sanity check type: Altitude, Max Position Deviation: Large
## Hardware
There are many GPS receivers available on the market.
Below are some examples of user-tested hardware.
### Ublox
###U-Blox
#### NEO-M8
Module | Comments
-------|--------
U-blox Neo-M8N w/Compass | Pinout can be found in Pixfalcon manual. SDA and SCL can be attached to I2C bus for compass, TX and RX can be attached to UART for GPS. Power must be applied for either to function.
Reyax RY825AI | NEO-M8N, 18Hz UART USB interface GPS Glonass BeiDou QZSS antenna module flash. [eBay](http://www.ebay.com/itm/RY825AI-18Hz-UART-USB-interface-GPS-Glonass-BeiDou-QZSS-antenna-module-flash/181566850426)
mRo uGPS w/ LIS3MDL | Ultra compact and weights just 7.7 grams. Multiple constellation capabilities (GPS and GLONASS). Includes JST-GH pigtail. Available from [mRobotics](https://store.mrobotics.io/product-p/mro-ugps-samm8q-01.htm).
#### NEO-7
Module | Comments
-------|--------
U-blox Neo-7M w/Compass | [HobbyKing](http://www.hobbyking.com/hobbyking/store/__55558__Ublox_Neo_7M_GPS_with_Compass_and_Pedestal_Mount.html) You have to set align_mag in the CLI to get the magnetometer working correctly: `set align_mag = 8` and don't forget to `save`.
#### NEO-6
Module | Comments
-------|--------
Ublox NEO-6M GPS with Compass | [eBay](http://www.ebay.com/itm/111585855757)
### Serial NMEA
#### MediaTek
Module | Comments
-------|--------
MTK 3329 | Tested on hardware serial at 115200 baud (default) and on softserial at 19200 baud. The baudrate and refresh rate can be adjusted using the MiniGPS software (recommended if you lower the baudrate). The software will estimate the percentage of UART bandwidth used for your chosen baudrate and update rate.

71
docs/Gtune.md
View file

@ -1,71 +0,0 @@
# G-Tune instructions.
The algorithm has been originally developed by Mohammad Hefny (mohammad.hefny@gmail.com):
> http://technicaladventure.blogspot.com/2014/06/zero-pids-tuner-for-multirotors.html
> http://diydrones.com/profiles/blogs/zero-pid-tunes-for-multirotors-part-2
> http://www.multiwii.com/forum/viewtopic.php?f=8&t=5190
The G-Tune functionality for Cleanflight is ported from the Harakiri firmware.
## Safety preamble: _Use at your own risk_
The implementation you have here is quite different and just for adjusting the P values of ROLL/PITCH/YAW in Acro mode.
When flying in Acro mode (yaw tune in other modes possible as well - see below) you can activate G-Tune with an AUX box (switch) while the copter is armed.
It will start tuning the wanted / possible axis (see below) in a predefined range (see below).
After activation you will probably notice nothing! That means G-Tune will not start shaking your copter, you will have to do it (or simply fly and let it work).
The G-Tune is based on the gyro error so it is only active when you give no RC input (that would be an additional error). So if you just roll only pitch and yaw are tuned. If you stop rolling G-Tune will wait ca. 450ms to let the axis settle and then start tuning that axis again. All axis are treated independently.
The easiest way to tune all axis at once is to do some air-jumps with the copter in Acro (RC centered and G-Tune activated... of course..).
You can set a too high P for the axis as default in the GUI, when the copter starts shaking the wobbles will be detected and P tuned down (be careful with the strength setting though - see below).
Yaw tune is disabled in any copter with less than 4 motors (like tricopters).
G-Tune in Horizon or Level mode will just affect Yaw axis (if more than 3 motors...)
You will see the results in the GUI - the tuning results will only be saved if you enable G-Tune mode while the copter is disarmed and G-Tune was used before when armed. You also can save the configuration in an alternative way (like hitting save button in the GUI, casting an eepromwrite with trimming, acc calibration etc.)
TPA and G-Tune: It is not tested and will most likely not result into something good. However G-Tune might be able to replace TPA for you.
A typical use may go in this order:
1. Arm
2. Enable G-tune
3. Lift off slowly, avoid stick inputs (Roll, Pitch / Yaw).
4. Eventually the copter should fly well. Perhaps do a few throttle punch outs and fly around a bit. Take note if each punch out seems to become smoother with less oscillation and the overall flight performance.
5. Disable G-tune
6. Land
7. Disarm, but don’t power off.
8. If these are desired results then either a) Connect cleanflight configurator review and save the configuration. or b) Enable G-Tune again to save settings.
9. Power off.
If the results are not desired look into changing the parameters as shown below and try again.
Some other notes and instructions can be found here:
> http://www.rcgroups.com/forums/showpost.php?p=31321635&postcount=6160
> http://www.rcgroups.com/forums/showpost.php?p=31525114&postcount=7150
## Parameters and their function:
gtune_loP_rll = 10 [0..200] Lower limit of ROLL P during G-Tune. Note "10" means "1.0" in the GUI.
gtune_loP_ptch = 10 [0..200] Lower limit of PITCH P during G-Tune. Note "10" means "1.0" in the GUI.
gtune_loP_yw = 10 [0..200] Lower limit of YAW P during G-Tune. Note "10" means "1.0" in the GUI.
gtune_hiP_rll = 100 [0..200] Higher limit of ROLL P during G-Tune. 0 Disables tuning for that axis. Note "100" means "10.0" in the GUI.
gtune_hiP_ptch = 100 [0..200] Higher limit of PITCH P during G-Tune. 0 Disables tuning for that axis. Note "100" means "10.0" in the GUI.
gtune_hiP_yw = 100 [0..200] Higher limit of YAW P during G-Tune. 0 Disables tuning for that axis. Note "100" means "10.0" in the GUI.
gtune_pwr = 0 [0..10] Strength of adjustment
gtune_settle_time = 450 [200..1000] Settle time in ms
gtune_average_cycles = 16 [8..128] Number of looptime cycles used for gyro average calcullation
So you have lower and higher limits for each P for every axis. The preset range (GUI: 1.0 - 10.0) is quiet broad to represent most setups.
If you want tighter or more loose ranges change them here. gtune_loP_XXX can be configured lower than "10" that means a P of "1.0" in the GUI. So you can have "Zero P" but you may get sluggish initial control.
If you want to exclude one axis from the tuning you must set gtune_hiP_XXX to zero. Let's say you want to disable yaw tuning write in CLI `set gtune_hiP_yw = 0`. Note: The MultiWii Wiki advises you to trim the yaw axis on your transmitter. If you have done so (yaw not neutral on your RC) yaw tuning will be disabled.
You can adjust the strength of tuning by using `set gtune_pwr = N`. My small copter works fine with 0 and doesn't like a value of "3". My big copter likes "gtune_pwr = 5". It shifts the tuning to higher values and if too high can diminish the wobble blocking! So start with 0 (default). If you feel your resulting P is always too low for you, increase gtune_pwr. You will see it getting a little shaky if value is too high.

284
docs/Inflight Adjustments.md
View file

@ -1,284 +0,0 @@
# In-flight Adjustments
With Cleanflight it's possible to make adjustments to various settings by using AUX channels from your transmitter while the aircraft is flying.
## Warning
Changing settings during flight can make your aircraft unstable and crash if you are not careful.
## Recommendations
* Always make adjustments while flying in a large open area.
* Make small adjustments and fly carefully to test your adjustment.
* Give yourself enough flying space and time to adjust to how your changes affect the behaviour of the aircraft.
* Remember to set adjustment channel switches/pots to the center position before powering on your TX and your aircraft.
* If possible configure switch warnings on your transmitter for dedicated adjustment switches.
* A momentary 3 position switch is the best choice of switch for this - i.e. one that re-centers itself when you let go of it.
## Overview
There are two modes of operation. The first supports adjusting settings by incrementing/decrementing them through use of an aux channel, typically a three position switch, where the middle position makes no change, and the other positions either increment or decrement the selected setting.
The other mode is Absolute mode where a pot (knob/slider) may be directly mapped and changes the selected setting to a value based on a center value, corresponding to mid-postion on the pot and a range of ± adjustment at the min/max positions of the pot.
Both modes utilise two channels to make an adjustment.
| Channel | Use |
| ------- | --- |
| Range | This channel is used to enable an adjustment. When the channel is set to fall withing the specified range, then the corresponding adjustment is enabled. This is similar to mode setting where a given mode is enabled when a channel is within a lower and upper range. |
| Adjustment | This channel is used to control the change to the specified setting|
Settings are not saved automatically, connect a GUI, refresh and save or save using stick position when disarmed.
Powering off without saving will discard the adjustments.
Settings can be saved when disarmed using stick positions: Throttle Low, Yaw Left, Pitch Low, Roll Right.
### Increment/Decrement mode
Up to 4 RX channels can be used to make different adjustments at the same time.
The adjustment the Adjustment Channel makes is controlled by the Range Channel.
The available adjustments are listed in [this table](#adjustment-functions).
Example scenarios:
Up to 4 3-position switches or pots can be used to adjust 4 different settings at the same time.
A single 2/3/4/5/6/x position switch can be used to make one 3 position switch adjust one setting at a time.
Any combination of switches and pots can be used. So you could have 6 POS switch.
#### Adjustment switches
The Adjustment switch is associated with the Adjustment Channel. The switch can be a ON-OFF-ON, POT or momentary ON-OFF-ON switch. The latter is recommended.
When the switch is returned to the center position the value will not be increased/decreased.
Each time you can press the switch high/low and then return it to the middle the value will change at least once, you do not have to wait before pressing the switch again if you want to increase/decrease at a faster rate. While the adjustment switch held is high/low, the adjustment function applies and increases/decreases the value being adjusted twice a second and the flight controller will beep shorter/longer, respectively. The system works similar to how a keyboard repeat delay works.
Hint: With OpenTX transmitters you can combine two momentary OFF-ON switches to control a single channel. You could make it so that a momentary switch on the left of your transmitter decreases the value and a momentary switch on the right increases the value. Experiment with your mixer!
### Absolute mode
The adjustment is made where the Adjustment Channel is an Aux channel connected to a pot (knob/slider). This provides an easier approach than using the Increment/Decrement mode as it is easier to keep track of the setting.
Note that if the same pot is used as the Adjustment Channel to make multiple adjustments, there is a risk of a jump in values of the second setting when switching from the first if the pot is not centered. To avoid this it is recommended that if adjusting two different settings using the same pot, a three position switch be used for the Range Channel, with neither setting associated with the middle position.
## Configuration
The CLI command `adjrange` is used to configure adjustment ranges.
12 adjustment ranges can be defined.
Show the current ranges using:
`adjrange`
Configure a range using:
`adjrange <index> 0 <range channel> <range start> <range end> <adjustment function> <adjustment channel>`
| Argument | Value | Meaning |
| -------- | ----- |-------- |
| Index | 0 - 29 | Select the adjustment range to configure |
| 0 | 0 | Used as slot before Betaflight 4.1 |
| Range Channel | 0 based index, AUX1 = 0, AUX2 = 1 | The AUX channel to use to select an adjustment for a switch/pot |
| Range Start | 900 - 2100. Steps of 25, e.g. 900, 925, 950... | Start of range |
| Range End | 900 - 2100 | End of range |
| Adjustment function | | See [Adjustment functions table](#adjustment-functions) |
| Adjustment channel | 0 based index, AUX1 = 0, AUX2 = 1 | The channel that is controlled by a 3 Position switch/Pot |
| Center Value | If this is non-zero then Absolute Mode is used for this range otherwise Increment/Decrement Mode is used. In Absolute Mode this value is the value which will be assigned to the setting when the Adjustment Channel is set to mid-position. |
| Scale Value | This specifies the amount that will be subtracted/added to the center value when the Adjustment Channel is at min/max respectively. |
Range Start/End values should match the values sent by your receiver.
The Range Channel and the Adjustment Channel can be the same channel. This is useful when you want a single 3 Position switch to be dedicated
to a single adjustment function regardless of other switch positions.
The adjustment function is applied to the adjustment channel when range channel is between the range values.
The adjustment is made when the adjustment channel is in the high or low position. high = mid\_rc + 200, low = mid\_rc - 200. by default this is 1700 and 1300 respectively.
### Adjustment functions
| Value | Adjustment | Notes |
| ----- | ---------- |------ |
| 0 | None | |
| 1 | RC RATE | Step / absolute setting |
| 2 | RC\_EXPO | Step / absolute setting |
| 3 | THROTTLE\_EXPO | Step / absolute setting |
| 4 | PITCH\_ROLL\_RATE | Step / absolute setting |
| 5 | YAW\_RATE | Step / absolute setting |
| 6 | PITCH\_ROLL\_P | Step / absolute setting |
| 7 | PITCH\_ROLL\_I | Step / absolute setting |
| 8 | PITCH\_ROLL\_D | Step / absolute setting |
| 9 | YAW\_P | Step / absolute setting |
| 10 | YAW\_I | Step / absolute setting |
| 11 | YAW\_D | Step / absolute setting |
| 12 | RATE\_PROFILE | Switch between 3 or 6 rate profiles (uses `rate_6pos_switch` setting) |
| 13 | PITCH\_RATE | Step / absolute setting |
| 14 | ROLL\_RATE | Step / absolute setting |
| 15 | PITCH\_P | Step / absolute setting |
| 16 | PITCH\_I | Step / absolute setting |
| 17 | PITCH\_D | Step / absolute setting |
| 18 | ROLL\_P | Step / absolute setting |
| 19 | ROLL\_I | Step / absolute setting |
| 20 | ROLL\_D | Step / absolute setting |
| 21 | RC\_RATE\_YAW | Step / absolute setting |
| 22 | PITCH\_ROLL\_F | Step / absolute setting |
| 23 | FEEDFORWARD\_TRANSITION | Step / absolute setting |
| 24 | HORIZON\_STRENGTH | Select the horizon strength |
| 25 | PID\_AUDIO | Select the PID value to be turned into tones |
| 26 | PITCH\_F | Step / absolute setting |
| 27 | ROLL\_F | Step / absolute setting |
| 28 | YAW\_F | Step / absolute setting |
| 29 | OSD\_PROFILE | Switch between 3 OSD profiles |
| 30 | LED\_PROFILE | Switch between the RACE / BEACON / STATUS LED strip profiles |
## Examples
### Example 1 - 3 Position switch used to adjust pitch/roll rate
```
adjrange 0 0 3 900 2100 4 3 0 0
```
explained:
* configure adjrange 0 so that when aux4
(3) in the range 900-2100 then use adjustment 4 (pitch/roll rate) when aux 4 (3)
is in the appropriate position.
* note that Center/Scale values are both zero, so this range will use increment/decrement mode.
### Example 2 - 2 Position switch used to enable adjustment of RC rate via a 3 position switch
```
adjrange 1 0 0 900 1700 0 2 0 0
adjrange 2 0 0 1700 2100 1 2 0 0
```
explained:
* configure adjrange 1 so that when aux1
(0) in the range 900-1700 then do nothing (0) when aux 3 (2) is in any
position.
* configure adjrange 2 so that when aux1
(0) in the range 1700-2100 then use adjustment rc rate (1) when aux 3
(2) is in the appropriate position.
* note that Center/Scale values are both zero, so this range will use increment/decrement mode.
Without the entire range of aux1 being defined there is nothing that
would stop aux 3 adjusting the pitch/roll rate once aux 1 wasn't in the higher
range.
### Example 3 - 6 Position switch used to select PID tuning adjustments via a 3 position switch
```
adjrange 3 0 1 900 1150 6 3 0 0
adjrange 4 0 1 1150 1300 7 3 0 0
adjrange 5 0 1 1300 1500 8 3 0 0
adjrange 6 0 1 1500 1700 9 3 0 0
adjrange 7 0 1 1700 1850 10 3 0 0
adjrange 8 0 1 1850 2100 11 3 0 0
```
explained:
* configure adjrange 3 so that when aux2
(1) in the range 900-1150 then use adjustment Pitch/Roll P (6) when aux 4
(3) is in the appropriate position.
* configure adjrange 4 so that when aux2
(1) in the range 1150-1300 then use adjustment Pitch/Roll I (7) when aux 4
(3) is in the appropriate position.
* configure adjrange 5 so that when aux2
(1) in the range 1300-1500 then use adjustment Pitch/Roll D (8) when aux 4
(3) is in the appropriate position.
* configure adjrange 6 so that when aux2
(1) in the range 1500-1700 then use adjustment Yaw P (9) when aux 4
(3) is in the appropriate position.
* configure adjrange 7 so that when aux2
(1) in the range 1700-1850 then use adjustment Yaw I (10) when aux 4
(3) is in the appropriate position.
* configure adjrange 8 so that when aux2
(1) in the range 1850-2100 then use adjustment Yaw D (11) when aux 4
(3) is in the appropriate position.
* note that Center/Scale values are both zero, so this range will use increment/decrement mode.
### Example 4 - Use a single 3 position switch to change between 3 different rate profiles
```
adjrange 11 0 3 900 2100 12 3 0 0
```
explained:
* configure adjrange 11 so that when aux4
(3) in the range 900-2100 then use adjustment Rate Profile (12) when aux 4
(3) is in the appropriate position.
* note that Center/Scale values are both zero, so this range will use increment/decrement mode.
When the switch is low, rate profile 0 is selected.
When the switch is medium, rate profile 1 is selected.
When the switch is high, rate profile 2 is selected.
### Example 5 - Use a single switch to enable absolute setting of Roll/Pitch P terms from two pots
```
adjrange 0 0 4 1450 1550 18 0 40 10
adjrange 1 0 4 1450 1550 15 1 58 20
```
explained:
* note that Center value is non-zero, so this range will use absolute mode.
* configure adjrange 0 so that when aux5 (3) in the range 1450-1550 then use aux 1 (0) to adjust Roll P Adjustment (18) such that the value will be 40 with the pot centered and 30/50 at min/max.
* configure adjrange 1 so that when aux5 (3) in the range 1450-1550 then use aux 2 (0) to adjust Pitch P Adjustment (15) such that the value will be 58 with the pot centered and 38/78 at min/max.
### Example 6 - Use a single switch to enable absolute setting of Roll/Pitch P/I/D terms from three pots, selected using a single switch
```
adjrange 0 0 4 950 1050 18 0 40 20
adjrange 1 0 4 950 1050 19 1 107 53
adjrange 2 0 4 950 1050 20 2 76 38
adjrange 3 0 4 1950 2050 15 0 63 16
adjrange 4 0 4 1950 2050 16 1 138 69
adjrange 5 0 4 1950 2050 17 2 66 33
```
explained:
* note that Center value is non-zero, so this range will use absolute mode.
This assigns pots aux 1, aux 2, and aux 3 respectively to control P, I and D settings with the pots at mid-position giving the default P/I/D values and providing a range of adjustment of +/- 50%. When the aux 5 switch is in one end position then roll P/I/D will be adjusted and when the aux 5 switch is in the other end position, pitch P/I/D will be adjusted. In the aux 5 switch middle position nether will be adjusted. Thus one could center the pots, select roll on aux 5 and then adjust the P/I/D values in flight. Then land, move the aux 5 switch to center, center the pots, select pitch on the switch and then again adjust P/I/D in flight.
### Configurator examples
Note that the configurator does not currently support the Center/Scale values, however it may still be used to setup the ranges and then the CLI may be used to set the Center/Scale values.
The following 5 images show valid configurations. In all cases the entire usable range for the Range Channel is used.
![Configurator example 1](Screenshots/adjustments-rate-profile-selection-via-3pos.png)
---
![Configurator example 2](Screenshots/adjustments-pitch-and-roll-rate-adjustment-via-3pos.png)
---
![Configurator example 3](Screenshots/adjustments-pid-via-two-3pos.png)
---
![Configurator example 4](Screenshots/adjustments-pid-via-6pos-and-3pos.png)
---
![Configurator example 5](Screenshots/adjustments-rates-via-a-2pos-and-3pos.png)
The following examples shows __incorrect__ configurations - the entire usable range for the Range Channel is not used in both cases.
![Configurator example 6](Screenshots/adjustments-incorrect-config-1.png)
![Configurator example 7](Screenshots/adjustments-incorrect-config-2.png)
In the following example, the incorrect configuraton (above) has been corrected by adding a range that makes 'No changes'.
![Configurator example 7](Screenshots/adjustments-incorrect-config-2-corrected.png)

30
docs/Installation.md
View file

@ -1,30 +0,0 @@
# Installation
## Using the configurator
This is a generic procedure to flash a board using the configurator. The configurator does not yet support all boards, so please check the documentation corresponding to your board before proceeding.
Make sure you have the [Cleanflight Configurator](https://github.com/cleanflight/cleanflight-configurator) installed, then:
* Connect the flight controller to the PC.
* Start the Cleanflight Configurator.
* Click on "Disconnect" if the configurator connected to the board automatically.
* Click on the "Firmware Flasher" tab.
* Make sure you have internet connectivity and click on the "Load Firmware [Online]" button.
* Click on the "Choose a Firmware / Board" dropdown menu, and select the latest stable version for your flight controller.
* IMPORTANT: Read and understand the release notes that are displayed. When upgrading review all release notes since your current firmware.
* If this is the first time Cleanflight is flashed to the board, tick the "Full Chip Erase" checkbox.
* Connect the flight controller board to the PC. Ensure the correct serial port is selected.
* Click on the "Flash Firmware" button and hold still (do not breathe, too).
* When the progress bar becomes green and reads "Programming: SUCCESSFUL" you are done!
## Manually
See the board specific flashing instructions.
# Upgrading
When upgrading be sure to backup / dump your existing settings. Some firmware releases are not backwards compatible and default settings are restored when the FC detects an out of date configuration.
## Backup/Restore process
See the CLI section of the docs for details on how to backup and restore your configuration via the CLI.

38
docs/IntegratedYaw.md
View file

@ -1,38 +0,0 @@
# Integrated Yaw
## Overview
Integrated Yaw is a feature which corrects a fundamental issue with quad control: while the pitch and roll axis are controlled by the thrust differentials the props generate yaw is different. Yaw gyro changes happen primarily due to inertia when the RPM of the motors change. A constant acceleration of yaw requires a constant rate of increase/decrease in the RPM of the yaw motor pairs.
This means that on Yaw I has the effect of P and P the effect of D. FF is a control element that adds impetus based on the acceleration in setpoint rate.
This results in several issues on yaw. Typically yaw will react very fast initially, then fall back and catch up again over time.
Integrated Yaw fixes this by integrating the output of the yaw pid before applying them to the mixer. This normalizes the way the pids work. You can now tune as any other axis. It requires use of absolute control since no I is needed with Integrated Yaw.
## Setup
From Betaflight 4.1.0 / Betaflight configurator 10.6.0 on Integrated Yaw can be set up in configurator, in the 'PID Tuning' tab.
As a fallback, these are the CLI commands to enable it:
```
set use_integrated_yaw=on
set iterm_rotation=off
set abs_control_gain=10
set p_yaw=30
set d_yaw=20
set i_yaw=0
set f_yaw=60
```
The yaw pids serve as starting point and might need adjustment. Make sure I is low or zero since significant I leads to strong oscillations. Pitch and roll might require slight retuning - primarily reducing I a bit since absolute control acts similar to a second I term.
**To be noted:**
If `i_yaw` is not set to `0`, then the following additional command is needed:
```
set iterm_relax=RPY
```

35
docs/Introduction.md
View file

@ -1,35 +0,0 @@
# Cleanflight
![Cleanflight](assets/cleanflight/cleanflight-logo-light-wide-1-240px.jpg)
Welcome to CleanFlight!
Cleanflight is an community project which attempts to deliver flight controller firmware and related tools.
## Primary Goals
* Community driven.
* Friendly project atmosphere.
* Focus on the needs of users.
* Great flight performance.
* Understandable and maintainable code.
## Hardware
See the [flight controller hardware](Boards.md) chapter for details.
## Software
There are two primary components, the firmware and the configuration tool. The firmware is the code that runs on the flight controller board. The GUI configuration tool (configurator) is used to configure the flight controller, it runs on Windows, OSX and Linux.
## Feedback & Contributing
We welcome all feedback. If you love it we want to hear from you, if you have problems please tell us how we could improve things so we can make it better for everyone.
If you want to contribute please see the notes here:
https://github.com/cleanflight/cleanflight#contributing
Developers should read this:
https://github.com/cleanflight/cleanflight/blob/master/CONTRIBUTING.md

714
docs/LedStrip.md
View file

@ -1,714 +0,0 @@
# LED Strip
Betaflight supports the use of addressable LED strips. Addressable LED strips allow each LED in the strip to be programmed with a unique and independent color. This is far more advanced than the normal RGB strips which require that all the LEDs in the strip show the same color.
## LED Strip Profiles
The LED strip feature supports 3 LED strip profiles, STATUS, RACE and BEACON. The selected profile can be changed from the CLI, OSD LED strip menu or from an adjustment channel, i.e. switch on your radio. Take note that the adjustment channel from your radio overrides all other LED strip profile selection options.
### STATUS Profile
The STATUS profile is used to display all the information mentioned below, i.e. warning indications, Larson scanner etc.
Addressable LED strips can be used to show information from the flight controller system, the current implementation supports the following:
* Up to 32 LEDs. (Support for more than 32 LEDs is possible, it just requires additional development.)
* Indicators showing pitch/roll stick positions.
* Heading/Orientation lights.
* Flight mode specific color schemes.
* Low battery warning.
* AUX operated on/off switch.
* GPS state.
* RSSI level.
* Battery level.
### RACE Profile
The RACE profile is used to set ALL strip LEDs to the selected color for racing, i.e. to identify quads based on LED color. The LED color is fixed and no other information is displayed.
### BEACON Profile
The BEACON profile is used to find a lost quad, it flashes all LEDs white once per second. Again in this profile no other information is displayed on the LEDs.
### LED Profile Configuration
###### OPTION 1: Configure an adjustment range to change the LED strip profile from your radio
1. Turn on Expert mode - see top right of configurator screen "Enable Expert Mode".
2. The LED strip profile selection is performed using an adjustment configured via the Adjustments tab.
- Enable an adjustment. ("If enabled")
- Select the AUX channel to be used to change the LED strip profile. ("when channel")
- Set the range to cover the entire range of the selected AUX channel. ("is in ranges")
- For the action select "RC Rate Adjustment". ("then apply") This will be configured in the CLI since LED strip profiles is not supported by Configurator 10.4.0 and earlier. "RC Rate Adjustment" is only selected to make the configuration in the CLI a little easier below.
- Select the "via channel" to match the selected AUX channel of above. ("when channel").
- Save
3. Open the CLI and type ```adjrange``` followed by enter.
4. Copy the adjrange configured in step 2. above and paste it in the command window. Change the '1' following the range of the channel to '30' and press enter. Type ```save``` and press enter. The configured adjrange will now be saved and the FC will reboot.
5. Configure the AUX channel on your radio. When this channel is changed the selected LED strip profile will change between STATUS, RACE and BEACON, you should see the LED function change as you do this.
###### OPTION 2: Use the CLI to select the LED strip profile (i.e. not selecting the LED strip profile with your radio)
1. Open the CLI.
2. Type ```get ledstrip_profile``` followed by enter to display the currently selected LED strip profile.
3. Type ```set ledstrip_profile=x``` where x is the profile STATUS, RACE or BEACON and press enter.
4. Type ```save``` followed by enter to save the selected LED strip profile.
###### OPTION 3: By using the OSD
1. Open the OSD menu by yawing left and pitching forward on your radio.
2. Using the pitch stick, move down to the LED Strip menu and roll right to enter the menu.
3. The profile and race color can be configured using the left stick to go back and the right stick to navigate up/down and to change the selected value.
4. Use the left stick to go to the top level menu and select save & reboot to complete.
###### RACE COLOR: The Race color can be configured using the CLI:
1. Open the CLI.
2. Type ```get ledstrip_race_color``` followed by enter to display the currently selected race color number.
3. Type ```set ledstrip_race_color=x``` where x is the required color.
4. Type ```save``` followed by enter to save the race color to be used.
###### BRIGHTNESS: The brightness can be configured using the CLI:
1. Open the CLI.
2. Type ```get ledstrip_brightness``` followed by enter to display the current brightness.
3. Type ```set ledstrip_brightness=x``` where x is the brightness in percentage between 5 and 100.
4. Type ```save``` followed by enter to save the brightness level to be used.
## Supported hardware
Only strips of 32 WS2811/WS2812 LEDs are supported currently. If the strip is longer than 32 LEDs it does not matter, but only the first 32 are used.
WS2812 LEDs require an 800khz signal and precise timings and thus requires the use of a dedicated hardware timer.
Note: Not all WS2812 ICs use the same timings, some batches use different timings.
It could be possible to be able to specify the timings required via CLI if users request it.
### Tested Hardware
* [Adafruit NeoPixel Jewel 7](https://www.adafruit.com/products/2226) (preliminary testing)
* Measured current consumption in all white mode ~ 350 mA.
* Fits well under motors on mini 250 quads.
* [Adafruit NeoPixel Stick](https://www.adafruit.com/products/1426) (works well)
* Measured current consumption in all white mode ~ 350 mA.
* [Aliexpress SK6812 RBGWW strip](https://www.aliexpress.com/wholesale?SearchText=rgbw+sk6812) (works well)
* Alternative [Adafruit NeoPixel Stick RGBW](https://www.adafruit.com/product/2869)
### WS2811 vs WS2812
The [WS2811](https://cdn-shop.adafruit.com/datasheets/WS2811.pdf) is a LED driver IC which is connected to an RGB LED. It accepts data in the form of 8 bits each of Red-Green-Blue.
The [WS2812](https://cdn-shop.adafruit.com/datasheets/WS2812.pdf) is integrated into the package of a 50:50 LED rather than as a separate device. It accepts data in the form of 8 bits each of Green-Red-Blue.
With the [SK6812](https://cdn-shop.adafruit.com/product-files/1138/SK6812+LED+datasheet+.pdf) also GRBW variants are supported, which have a fourth (white) channel and such provide a much cleaner white color.
It is thus possible, depending on the LED board/strip being used that either Red-Green-Blue or Green-Red-Blue encoding may be required. This may be controlled by setting the following.
```
set ledstrip_grb_rgb = RGB
```
or
```
set ledstrip_grb_rgb = GRB
```
or
```
set ledstrip_grb_rgb = GRBW
```
Then confirm the required setting by simply setting an LED to be green. If it lights up red, you have the wrong setting.
Afterwards check if the second LED also lights up red - if not, you might have 4-color SK6812 LEDs and would have to select GRBW.
## Connections
WS2812 LED strips generally require a single data line, 5V and GND.
WS2812 LEDs on full brightness can consume quite a bit of current. It is recommended to verify the current draw and ensure your supply can cope with the load. On a multirotor that uses multiple BEC ESC's you can try use a different BEC to the one the FC uses. e.g. ESC1/BEC1 -> FC, ESC2/BEC2 -> LED strip. It's also possible to power one half of the strip from one BEC and the other half from another BEC. Just ensure that the GROUND is the same for all BEC outputs and LEDs.
| Target | Pin | LED Strip | Signal |
| --------------------- | ---- | --------- | -------|
| Naze | RC5 | Data In | PA6 |
| CC3D | RCO5 | Data In | PB4 |
| ChebuzzF3/F3Discovery | PB8 | Data In | PB8 |
| Sparky | PWM5 | Data In | PA6 |
Since RC5 is also used for SoftSerial on the Naze it means that you cannot use SoftSerial and led strips at the same time. Additionally, since RC5 is also used for Parallel PWM RC input on both the Naze, Chebuzz and STM32F3Discovery targets, led strips can not be used at the same time at Parallel PWM.
If you have LEDs that are intermittent, flicker or show the wrong colors then drop the VIN to less than 4.7v, e.g. by using an inline diode on the VIN to the LED strip. The problem occurs because of the difference in voltage between the data signal and the power signal. The WS2811 LED's require the data signal (Din) to be between 0.3 * Vin (Max) and 0.7 * VIN (Min) to register valid logic low/high signals. The LED pin on the CPU will always be between 0v to ~3.3v, so the Vin should be 4.7v (3.3v / 0.7 = 4.71v). Some LEDs are more tolerant of this than others.
The datasheet can be found here: http://www.adafruit.com/datasheets/WS2812.pdf
## Configuration
The led strip feature can be configured via the GUI.
GUI:
Enable the Led Strip feature via the GUI under setup.
Configure the LEDs from the Led Strip tab in the Betaflight GUI.
First setup how the LEDs are laid out so that you can visualize it later as you configure and so the flight controller knows how many LEDs there are available.
There is a step by step guide on how to use the GUI to configure the Led Strip feature using the GUI http://blog.oscarliang.net/setup-rgb-led-cleanflight/ which was published early 2015 by Oscar Liang which may or may not be up-to-date by the time you read this.
CLI:
Enable the `LED_STRIP` feature via the cli:
```
feature LED_STRIP
```
If you enable LED_STRIP feature and the feature is turned off again after a reboot then check your config does not conflict with other features, as above.
Configure the LEDs using the `led` command.
The `led` command takes either zero or two arguments - an zero-based led number and a sequence which indicates pair of coordinates, direction flags and mode flags and a color.
If used with zero arguments it prints out the led configuration which can be copied for future reference.
Each led is configured using the following template: `x,y:ddd:mmm:cc`
`x` and `y` are grid coordinates of a 0 based 16x16 grid, north west is 0,0, south east is 15,15
`ddd` specifies the directions, since an led can face in any direction it can have multiple directions. Directions are:
`N` - North
`E` - East
`S` - South
`W` - West
`U` - Up
`D` - Down
For instance, an LED that faces South-east at a 45 degree downwards angle could be configured as `SED`.
Note: It is perfectly possible to configure an LED to have all directions `NESWUD` but probably doesn't make sense.
`mmm` specifies the modes that should be applied an LED.
Each LED has one base function:
* `C` - `C`olor.
* `F` - `F`light mode & Orientation
* `A` - `A`rmed state.
* `R` - `R`ing thrust state.
* `G` - `G`PS state.
* `S` - R`S`SSI level.
* `L` - Battery `L`evel.
And each LED has overlays:
* `W` - `W`warnings.
* `I` - `I`ndicator.
* `T` - `T`hrust state.
* `B` - `B`link (flash twice) mode.
* `O` - Lars`O`n Scanner (Cylon Effect).
* `V` - `V`TX Frequency.
`cc` specifies the color number (0 based index).
Example:
```
led 0 0,15:SD:AWI:0
led 1 15,0:ND:AWI:0
led 2 0,0:ND:AWI:0
led 3 0,15:SD:AWI:0
led 4 7,7::C:1
led 5 8,8::C:2
led 6 8,9::B:1
```
To erase an led, and to mark the end of the chain, use `0,0::` as the second argument, like this:
```
led 4 0,0:::
```
It is best to erase all LEDs that you do not have connected.
### Modes
#### Warning
This mode simply uses the LEDs to flash when warnings occur.
| Warning | LED Pattern | Notes |
|---------|-------------|-------|
| Arm-lock enabled | flash between green and off | occurs during calibration or when unarmed and the aircraft is tilted too much |
| Low Battery | flash red and off | battery monitoring must be enabled. May trigger temporarily under high-throttle due to voltage drop |
| Failsafe | flash between light blue and yellow | Failsafe must be enabled |
Flash patterns appear in order, so that it's clear which warnings are enabled.
#### GPS state
This mode shows the GPS state and satellite count.
No fix = red LED
3D fix = green LED
The LEDs will blink as many times as the satellite count, then pause and start again.
#### RSSI level
This mode binds the LED color to RSSI level.
| Color | RSSI |
| ---------- | ---------|
| Green | 100% |
| Lime green | 80% |
| Yellow | 60% |
| Orange | 40% |
| Red | 20% |
| Deep pink | 0% |
When RSSI is below 50% is reached, LEDs will blink slowly, and they will blink fast when under 20%.
#### Battery level
This mode binds the LED color to remaining battery capacity.
| Color | Capacity |
| ---------- | ---------|
| Green | 100% |
| Lime green | 80% |
| Yellow | 60% |
| Orange | 40% |
| Red | 20% |
| Deep pink | 0% |
When Warning or Critical voltage is reached, LEDs will blink slowly or fast.
Note: this mode requires a current sensor. If you don't have the actual device you can set up a virtual current sensor (see [Battery](Battery.md)).
#### Blink
This mode blinks the current LED, alternatively from black to the current active color.
#### Larson Scanner (Cylon Effect)
The Larson Scanner replicates the scanning "eye" effect seen on the mechanical Cylons and on Kitt from Knight Rider.
This overlay dims all of the LEDs it is assigned to and brightens certain ones at certain times in accordance with the animation. The animation is active regardless of arm state.
#### VTX Frequency
This overlay makes the LED color dependent on the current channel of the VTX, in case it is equipped with SmartAudio or IRC Tramp.
The color is selected according to the following table:
Frequency range | Default color | Color index
--- | --- | ---
<= 5672 | White | 1
|> 5672 <= 5711 | Red | 2
|> 5711 <= 5750 | Orange | 3
|> 5750 <= 5789 | Yellow | 4
|> 5789 <= 5829 | Green | 6
|> 5829 <= 5867 | Blue | 10
|> 5867 <= 5906 | Dark violet | 11
|> 5906 | Deep pink | 13
The default color can be changed by double-clicking the color and moving the Hue slider or by using the color command in the CLI.
#### Flight Mode & Orientation
This mode shows the flight mode and orientation.
When flight modes are active then the LEDs are updated to show different colors depending on the mode, placement on the grid and direction.
LEDs are set in a specific order:
* LEDs that marked as facing up or down.
* LEDs that marked as facing west or east AND are on the west or east side of the grid.
* LEDs that marked as facing north or south AND are on the north or south side of the grid.
That is, south facing LEDs have priority.
The mapping between modes led placement and colors is currently fixed and cannot be changed.
#### Indicator
This mode flashes LEDs that correspond to roll and pitch stick positions. i.e. they indicate the direction the craft is going to turn.
| Mode | Direction | LED Color |
|------------|--------|---------------------|
|Orientation | North | WHITE |
|Orientation | East | DARK VIOLET |
|Orientation | South | RED |
|Orientation | West | DEEP PINK |
|Orientation | Up | BLUE |
|Orientation | Down | ORANGE |
| | | |
|Head Free | North | LIME GREEN |
|Head Free | East | DARK VIOLET |
|Head Free | South | ORANGE |
|Head Free | West | DEEP PINK |
|Head Free | Up | BLUE |
|Head Free | Down | ORANGE |
| | | |
|Horizon | North | BLUE |
|Horizon | East | DARK VIOLET |
|Horizon | South | YELLOW |
|Horizon | West | DEEP PINK |
|Horizon | Up | BLUE |
|Horizon | Down | ORANGE |
| | | |
|Angle | North | CYAN |
|Angle | East | DARK VIOLET |
|Angle | South | YELLOW |
|Angle | West | DEEP PINK |
|Angle | Up | BLUE |
|Angle | Down | ORANGE |
| | | |
|Mag | North | MINT GREEN |
|Mag | East | DARK VIOLET |
|Mag | South | ORANGE |
|Mag | West | DEEP PINK |
|Mag | Up | BLUE |
|Mag | Down | ORANGE |
| | | |
|Baro | North | LIGHT BLUE |
|Baro | East | DARK VIOLET |
|Baro | South | RED |
|Baro | West | DEEP PINK |
|Baro | Up | BLUE |
|Baro | Down | ORANGE |
#### Armed state
This mode toggles LEDs between green and blue when disarmed and armed, respectively.
Note: Armed State cannot be used with Flight Mode.
#### Thrust state
This mode fades the current LED color to the previous/next color in the HSB color space depending on throttle stick position. When the throttle is in the middle position the color is unaffected, thus it can be mixed with orientation colors to indicate orientation and throttle at the same time. Thrust should normally be combined with Color or Mode/Orientation.
#### Thrust ring state
This mode is allows you to use one or multiple led rings (e.g. NeoPixel ring) for an afterburner effect. LEDs with this mode will light up with their assigned color in a repeating sequence. Assigning the color black to an LED with the ring mode will prevent the LED from lighting up.
A better effect is achieved when LEDs configured for thrust ring have no other functions.
LED direction and X/Y positions are irrelevant for thrust ring LED state. The order of the LEDs that have the state determines how the LED behaves, and the throttle value determines the animation rate. The animation is only active while armed.
Each LED of the ring can be a different color. The color can be selected between the 16 colors available.
For example, led 0 is set as a `R`ing thrust state led in color 13 as follow.
```
led 0 2,2::R:13
```
LED strips and rings can be combined.
#### Solid Color
The mode allows you to set an LED to be permanently on and set to a specific color.
x,y position and directions are ignored when using this mode.
Other modes will override or combine with the color mode.
For example, to set led 0 to always use color 10 you would issue this command.
```
led 0 0,0::C:10
```
### Colors
Colors can be configured using the cli `color` command.
The `color` command takes either zero or two arguments - an zero-based color number and a sequence which indicates pair of hue, saturation and value (HSV).
See http://en.wikipedia.org/wiki/HSL_and_HSV
If used with zero arguments it prints out the color configuration which can be copied for future reference.
The default color configuration is as follows:
| Index | Color |
| ----- | ----------- |
| 0 | black |
| 1 | white |
| 2 | red |
| 3 | orange |
| 4 | yellow |
| 5 | lime green |
| 6 | green |
| 7 | mint green |
| 8 | cyan |
| 9 | light blue |
| 10 | blue |
| 11 | dark violet |
| 12 | magenta |
| 13 | deep pink |
| 14 | black |
| 15 | black |
```
color 0 0,0,0
color 1 0,255,255
color 2 0,0,255
color 3 30,0,255
color 4 60,0,255
color 5 90,0,255
color 6 120,0,255
color 7 150,0,255
color 8 180,0,255
color 9 210,0,255
color 10 240,0,255
color 11 270,0,255
color 12 300,0,255
color 13 330,0,255
color 14 0,0,0
color 15 0,0,0
```
### Mode Colors Assignement
Mode Colors can be configured using the cli `mode_color` command.
- No arguments: lists all mode colors
- arguments: mode, function, color
First 8 groups of ModeIndexes are :
| mode | name |
|------|-------------|
| 0 | orientation |
| 1 | headfree |
| 2 | horizon |
| 3 | angle |
| 4 | mag |
| 5 | baro |
| 6 | special |
| 7 | channel |
Modes 0 to 5 functions:
| function | name |
|----------|-------|
| 0 | north |
| 1 | east |
| 2 | south |
| 3 | west |
| 4 | up |
| 5 | down |
Mode 6 use these functions:
| function | name |
|----------|--------------------|
| 0 | disarmed |
| 1 | armed |
| 2 | animation |
| 3 | background |
| 4 | blink background |
| 5 | gps: no satellites |
| 6 | gps: no fix |
| 7 | gps: 3D fix |
The ColorIndex is picked from the colors array ("palette").
Mode 7 is used along with Thrust state to make the LED color dependent on a channel different from the throttle.
Examples (using the default colors):
- set armed color to red: ```mode_color 6 1 2```
- set disarmed color to yellow: ```mode_color 6 0 4```
- set Headfree mode 'south' to Cyan: ```mode_color 1 2 8```
- set color dependent on AUX 1 in Thrust state: ```mode_color 7 0 4```
## Positioning
Cut the strip into sections as per diagrams below. When the strips are cut ensure you reconnect each output to each input with cable where the break is made. e.g. connect 5V out to 5V in, GND to GND and Data Out to Data In.
Orientation is when viewed with the front of the aircraft facing away from you and viewed from above.
### Example 12 LED config
The default configuration is as follows
```
led 0 15,15:ES:IA:0
led 1 15,8:E:WF:0
led 2 15,7:E:WF:0
led 3 15,0:NE:IA:0
led 4 8,0:N:F:0
led 5 7,0:N:F:0
led 6 0,0:NW:IA:0
led 7 0,7:W:WF:0
led 8 0,8:W:WF:0
led 9 0,15:SW:IA:0
led 10 7,15:S:WF:0
led 11 8,15:S:WF:0
led 12 7,7:U:WF:0
led 13 8,7:U:WF:0
led 14 7,8:D:WF:0
led 15 8,8:D:WF:0
led 16 8,9::R:3
led 17 9,10::R:3
led 18 10,11::R:3
led 19 10,12::R:3
led 20 9,13::R:3
led 21 8,14::R:3
led 22 7,14::R:3
led 23 6,13::R:3
led 24 5,12::R:3
led 25 5,11::R:3
led 26 6,10::R:3
led 27 7,9::R:3
led 28 0,0:::0
led 29 0,0:::0
led 30 0,0:::0
led 31 0,0:::0
```
Which translates into the following positions:
```
6 3
\ /
\ 5-4 /
\ FRONT /
7,8 | 12-15 | 1,2
/ BACK \
/ 10,11 \
/ \
9 0
RING 16-27
```
LEDs 0,3,6 and 9 should be placed underneath the quad, facing downwards.
LEDs 1-2, 4-5, 7-8 and 10-11 should be positioned so the face east/north/west/south, respectively.
LEDs 12-13 should be placed facing down, in the middle
LEDs 14-15 should be placed facing up, in the middle
LEDs 16-27 should be placed in a ring and positioned at the rear facing south.
This is the default so that if you don't want to place LEDs top and bottom in the middle just connect the first 12 LEDs.
### Example 16 LED config
```
led 0 15,15:SD:IA:0
led 1 8,8:E:FW:0
led 2 8,7:E:FW:0
led 3 15,0:ND:IA:0
led 4 7,7:N:FW:0
led 5 8,7:N:FW:0
led 6 0,0:ND:IA:0
led 7 7,7:W:FW:0
led 8 7,8:W:FW:0
led 9 0,15:SD:IA:0
led 10 7,8:S:FW:0
led 11 8,8:S:FW:0
led 12 7,7:D:FW:0
led 13 8,7:D:FW:0
led 14 7,7:U:FW:0
led 15 8,7:U:FW:0
```
Which translates into the following positions:
```
6 3
\ /
\ 5-4 /
7 \ FRONT / 2
| 12-15 |
8 / BACK \ 1
/ 10-11 \
/ \
9 0
```
LEDs 0,3,6 and 9 should be placed underneath the quad, facing downwards.
LEDs 1-2, 4-5, 7-8 and 10-11 should be positioned so the face east/north/west/south, respectively.
LEDs 12-13 should be placed facing down, in the middle
LEDs 14-15 should be placed facing up, in the middle
### Example 28 LED config
```
#right rear cluster
led 0 9,9:S:FWT:0
led 1 10,10:S:FWT:0
led 2 11,11:S:IA:0
led 3 11,11:E:IA:0
led 4 10,10:E:AT:0
led 5 9,9:E:AT:0
# right front cluster
led 6 10,5:S:F:0
led 7 11,4:S:F:0
led 8 12,3:S:IA:0
led 9 12,2:N:IA:0
led 10 11,1:N:F:0
led 11 10,0:N:F:0
# center front cluster
led 12 7,0:N:FW:0
led 13 6,0:N:FW:0
led 14 5,0:N:FW:0
led 15 4,0:N:FW:0
# left front cluster
led 16 2,0:N:F:0
led 17 1,1:N:F:0
led 18 0,2:N:IA:0
led 19 0,3:W:IA:0
led 20 1,4:S:F:0
led 21 2,5:S:F:0
# left rear cluster
led 22 2,9:W:AT:0
led 23 1,10:W:AT:0
led 24 0,11:W:IA:0
led 25 0,11:S:IA:0
led 26 1,10:S:FWT:0
led 27 2,9:S:FWT:0
```
```
16-18 9-11
19-21 \ / 6-8
\ 12-15 /
\ FRONT /
/ BACK \
/ \
22-24 / \ 3-5
25-27 0-2
```
All LEDs should face outwards from the chassis in this configuration.
Note:
This configuration is specifically designed for the [Alien Spider AQ50D PRO 250mm frame](http://www.goodluckbuy.com/alien-spider-aq50d-pro-250mm-mini-quadcopter-carbon-fiber-micro-multicopter-frame.html).
## Troubleshooting
On initial power up the LEDs on the strip will be set to WHITE. This means you can attach a current meter to verify the current draw if your measurement equipment is fast enough. Most 5050 LEDs will draw 0.3 Watts a piece.
This also means that you can make sure that each R,G and B LED in each LED module on the strip is also functioning. After a short delay the LEDs will show the unarmed color sequence and or low-battery warning sequence.
Also check that the feature `LED_STRIP` was correctly enabled and that it does not conflict with other features, as above.
## Resource remapping
If your board does not have a physical LED_STRIP pin you still can use this feature but configuration is dependend on target resources.
An example for a Foxeer F745V3_AIO board using SERIAL_RX 1 as LED_STRIP:
resource SERIAL_RX 1 A10
resource SERIAL_RX 1 NONE
resource LED_STRIP 1 A10
timer show # show current timer list
timer A10 list # check available timers for next commmand
timer A10 AF1
dma show # show current dma list
dma pin A10 list # check available dma pins for next command
dma pin A10 0
feature LED_STRIP
save

468
docs/Manufacturer Design Guidelines.md
View file

@ -1,468 +0,0 @@
# Betaflight Flight Controller Manufacturer Design Guidelines
![Betaflight](assets/images/bf_logo.png)
Version Change Register
| Version # | Revision Date | Changes, Reasons, and Notes |
| :--- | :--- | :--- |
| Draft 0.1 | 14 May 2022 | Initial Draft Format |
| Draft 0.2 | 04 June 2022 | Revise format to Final Format |
| Draft 0.3 | 12 June 2022 | Update Visual Media and Tables |
| Draft 0.4 | 21 October 2022 | Update format, add information |
| Draft 0.5 | 24 October 2022 | Add additional information |
| Draft 0.6 | 06 November 2022 | Add cloud build information |
| Draft 0.7 | 17 November 2022 | Remove off-board hardware defines |
| Draft 0.8 | 01 January 2023 | Update BARO and CC2500 |
Thank you for considering or continuing your development of Betaflight capable flight control hardware.
Betaflight is an open source project that is free to use and does not incur a license cost, however for the most successful release of a new flight controller or complete ready-to-fly product that is using Betaflight, it remains immensely beneficial to provide representative production samples or pre-production testing units to the Betaflight development team for testing and development feedback.
In order to have hardware added to the Betaflight approved hardware list, hardware samples representative of the final configuration must be provided to designated members of the betaflight development team. It is strongly recommended that samples of development hardware or production-representative examples are evaluated positively before accepting pre-orders or releasing products. Many of the same benefits can be provided for inclusive hardware packages, including flight control stacks, or ready-to-fly craft.
Sharing schematics/layouts with the reviewers will also be beneficial and improve the quality of the review.
This provides the Betaflight team with an opportunity to ensure that the hardware and firmware behave 100% as expected in the representative configuration, as well as support verification of custom defaults required for firmware operation. After-sales support to customers from members of the Betaflight team are also made possible for reproducing end user issues.
Additional benefits are also present in the form of allowing experienced active pilots with backgrounds in engineering of these systems to assist with aspects of the development process particularly in respect to real world use the products will be subjected to.
Finally, we will offer a ’Betaflight approved’ product list on the Betaflight github to advise the userbase on electronics which both follow our ‘best practice’ guidance, and which have been tested by our development team. This will be available for flight controller hardware, as well as electronic speed controller stacks, AIOs, and ready-to-fly craft. This strategy is designed to help both developers optimise their hardware and our user base get directed to optimal hardware, and reduce support requests for the Betaflight team who serve a user base of over a hundred thousand users.
# 1 Important Terms and Conditions
## 1.1 Intent
The goal of achieving a certified hardware ecosystem for Betaflight Flight Controller hardware and firmware targets is to ensure that hardware design supports correct operation of Betaflight features and supports an improved user experience for ‘connecting’, flashing, programming, and flying.
The cutting edge flight performance achieved by Betaflight relies on proper hardware design, microcontroller resource allocation, and the ability of end users to correctly configure the software with Betaflight.
Achieving state of the art performance requires minimizing latency in craft response to perturbations and command inputs, efficient filtering to remove oscillations from flight control calculations, and leveraging the capabilities of peripheral components to enhance the flight experience. For example, features such as advanced RPM filtering, RPM Dynamic Idle and Multi-Dynamic Notch rely on achieving microsecond scale timing jitter for best performance while simultaneously communicating with electronic speed controllers using bidirectional DShot, determining craft attitude and calculating optimal mixer outputs, as well as operating the myriad of desired user peripherals. This symphony of delicately scheduled operations can be achieved reliably with proper flight controller design.
## 1.2 Important Terms and Glossary
| Term | Definition | Reference |
| :--- | :--- | :--- |
| ADC | Analog to Digital Converter |
| BEC | Battery Elimination Circuit | Electronic voltage regulator circuit that provides a specified voltage to a single output power rail |
| Bidirectional DSHOT | Two-Way DSHOT communication protocol to enable Electronic Speed Controller telemetry to be sent back to the flight controller | https://github.com/betaflight/betaflight/wiki/Bidirectional-DSHOT-and-RPM-Filter |
| Bit Bang | Bit-banging refers to any instance of utilizing GPIO functionality to digitally create signals in place of dedicated hardware. This can alleviate some specific data buffer timing requirements |
| DSHOT | Digital Shot Communication Protocol used for Flight Controller to Electronic Speed Controller | https://github.com/betaflight/betaflight/wiki/DSHOT-ESC-Protocol |
| ESC | Electronic Speed Controller | https://us.aspina-group.com/en/learning-zone/columns/what-is/021/ |
| FPV | First Person View | This can also refer to the complete avionics-telemetry supplied via a camera & video transmission system |
| GPIO | General Purpose Input/Output | Reconfigurable digital signal pin that can be selected from an MCU pin |
| IMU | Inertial Motion Unit | Inertial Navigation hardware systems using combined gyroscope and accelerometer unit intended to provide accurate estimates of angular rates, acceleration, and orientation. These can also incorporate magnetometers, barometers, and GPS signals |
| I2C | Inter-Integrated Circuit synchronous serial communication protocol used for connecting microcontroller CPU to peripheral devices |
| MCU | Micro Controller Unit | Single integrated circuit microprocessor with integrated processor, memory, and programmable input/output modules |
| SPI Bus | Serial Peripheral Interface that enables MCU to interface with ADC, DAC, registers, RAM storage, and GPIO | https://www.analog.com/en/analog-dialogue/articles/introduction-to-spi-interface.html |
| PCB | Printed Circuit Board | May also refer to a populated PCB with components
| PDB | Power Distribution Board | A PCB intended to provide power distribution to electronic speed controller, flight controller, and other peripheral elements |
| VDD | Voltage - Operating Voltage for a particular chip |
| VDD_IO | Voltage range permissible as I/O Supply voltage (Typically 3.3V or less) |
# 2 Engaging with the Betaflight Development Team
## 2.1 Hardware Approval Process - Example
- Manufacturer initiates contact with Betaflight developer(s) at hardware@betaflight.com
- Betaflight team will establish a closed Discord channel for ongoing private discussion between key members of the development team and manufacturer designees
Work in progress schematics, PCB renders, and similar documentation prior to initial production provides opportunities for early feedback
- Initial Submission
- This will require key information to be available, such as specific MCU arrangement (e.g. SPI Bus allocations) may be required in order to support complete feature sets.
- Desired Target name, MCU type, and which target architecture to be used required.
- Optionally, if any Official Betaflight Presets are to be requested with this hardware, what specific configurations will be used, and a rough plan of what complete system hardware will be provided to support these efforts.
- Initial PR for target implementation will need to also include a maintainer, with the intention of providing permission to make future edits on the target.
- Request for specific targets
- If the flight controller design is intended to have a dedicated Betaflight target, then a new target submission can accompany the process
- For additional information, see here: https://betaflight.com/news/new-target-requirements/
- Production Representative Samples
- To complete hardware certification, representative hardware samples of initial production run, or pre-production batches which are representative of the final release design must be furnished to designated Betaflight development team member(s) to conduct final validation and certification operations.
- This will indirectly provide access to the adjacent benefits of leveraging Betaflight developer expertise by using this hardware in complete systems, including flight testing as desired and comprehensive blackbox log analysis. For configurations requiring specific hardware to be tested (e.g. a Bind & Fly or Plug & Play UAS), providing complete representative hardware systems is best.
- Reporting of performance
- With sufficient test time using the final product, developers can agree to recommend products which meet our guidelines and performance expectations. Products will be noted on Betaflight Github.
- Submission
- Once hardware has been approved, it will be added to the list of Betaflight approved hardware
- If new target(s) and/or presets have been added, pull requests will be evaluated, completed, and merged for inclusion in subsequent Betaflight releases
- Target Maintenance
- After approval and release, the designated contact is expected to provide any continuing support that may be required in order to keep the approved hardware working well for end users
## 2.2 Adjacent Benefits and Opportunities
Betaflight developers are likely to provide significant indirect benefits for manufacturers adhering to this program. These benefits could include reviews of board designs, pad location recommendations, evaluation of EMI behaviors in builds, analysis of Blackbox logging outputs, and even insights into forward compatibility with other subsystems used in complete builds.
Improved customer experience with software interactions, development of presets for BNF multicopter configurations, and validation with specific FPV and RC segments of craft to ensure customer experience will be positive. The key integration aspects of supporting various remote control and video combinations can only be fully validated with testing hardware samples.
This thorough testing by expert team members, will help verify and then allow recommendation from the Betaflight development team. Betaflight official recommendation will be highly valuable promotion for the manufacturer so we urge manufacturers to take up this opportunity and work with us.
# 3.0 Flight Controller Design Guidelines
These guidelines provide best practices for physical, electrical, and documentation support of flight controllers. These recommendations are provided as guidelines, however deviating from these provided suggestions should only be undertaken through a collaborative effort with Betaflight developers during the design and prototyping process.
## 3.1 Best Practices for Flight Controller Design and Performance
When asked to review hardware our first action will be to review schematics/layouts against the application notes for the applicable data sheets. The specifics of how the hardware is interconnected is of course going to be driven by a number of constraints, such as recommended pinouts, as outlined below, but is it essential that good design practises are followed with respect to providing good quality power regulation, appropriate use of ground/power planes, decoupling component positioning etc.
### 3.1.1 Physical Configuration
Primary configurations that place the inertial motion unit and other EMI-sensitive components on the side of the PCB that should be mounted away from the electronic speed controller performs best in vertically stacked configurations. Similarly, physically larger components such as inverters in more protected locations from impacts or adjacent PCB boards in stacked build configurations is recommended.
The commonly accepted and used board layouts include 16x16mm for M2 hardware (perpendicularly aligned), 25.4x25.4mm for M2 hardware (typically diagonally aligned), 20x20mm for M2 or M3 hardware (perpendicularly aligned), and 30.5x30.5mm for M3 hardware (perpendicularly aligned). In the case of 20x20 boards, selecting a hardware mounting size should be informed by the ability to use threaded inserts and shock-absorbing grommets in oversized holes, while dedicated M2 mounting limits mounting options if hardware is capable of being used in larger craft that tend to utilize M3 mounting.
Boards with oversized holes (e.g. M4 holes and silicone inserts for M3 stack mounting) experience longer service life and experience fewer failures due to PCB deformation during impacts. For standalone flight controllers, integrated ‘AIO’ flight controllers, and even adjacent configurations provided as ‘stacks’ with additional PCBs, this architecture has been proven to be the most robust over time.
Board layouts should provide redundancy for all critical functions. For example, solder locations with identical pin arrangements to JST connector located adjacent to the JST header mounting is strongly recommended, providing end users significant added value and opportunities to produce more robust craft.
Castellations and use of mounting pads with through holes or edge continuity are also strongly recommended, especially with more compact flight controller designs.
For board layouts implementing transistor PINIO functionality for ‘pit switch’ or similar behaviors, solder bridge options are strongly recommended to enable users to select output voltage, or physically bypass the switching functionality by connecting to voltage sources. Particularly for video systems, it is strongly recommended to avoid performing this switching on the ground, due to interference concerns demonstrated with inconsistent ground planes.
If providing direct mounting support for receivers, the following specification should be followed: the pin sequence must be GND, 5V, UART RX, UART TX with a 2.54mm pin pitch, and permit receivers sized up to 12x20mm. This mirrors the standard mounting (Gnd/5V/Tx/Rx) of CRSF Nano and ELRS Nano receivers, with mirrored UART communication allowing for Tx and Rx to be paired to the same UART.
### 3.1.2 Inertial Measurement Unit (IMU) Selection
Selecting an appropriate IMU for flight controller operation is critical to the resulting flight performance of systems. Proven examples of hardware using single Invensense MPU-6000, single or dual ICM-20602, and also Bosch BMI-270 and BMI-180 units have been successfully demonstrated to operate with Betaflight, although the latter two examples have required significand development effort to bring performance of the IMU gyroscope and accelerometer sensing behaviors up to the standards required to maximize flight performance.
### 3.1.3 Future IMU Options and how to select preferred options
Future IMU selection should be carried out with close involvement of the Betaflight development group. In cases such as the ICM-42688-P, ICM-42688-V, or ICM-42605, early hardware validation samples should be explored in collaboration with Betaflight developers to determine the suitability of these IMU units in relevant environments.
The ability to customize IMU lowpass filtering and operate within the same GRMS/Shock environment allows for maximum portability of existing filtering and tune schemes, but this development must occur with complete hardware samples and flown in representative flight regimes in order to replicate the EMI environment end users will experience.
The IMU sensors, designed for applications outside of sUAS, are typically subjected to very harsh electromagnetic environments. Ensuring electromagnetic compatibility when using these immediately adjacent to ultrasonically switched power MOSFET devices, constantly operational radio frequency devices (such as remote control and FPV video systems), under thermal stresses of moving over 1kW through the complete flight stack, are a nontrivial operation. In order to minimize risks of flyaway and brownout behaviors which can be observed if IMU data filtering and power delivery are inadequate, proper circuit design and validation testing must be performed.
// Mention examples such as the ICM-42688-P and similar options that offer the same high precision and GRMS/Shock tolerances required.
// Also reiterate the importance of these sensors being able to operate in the sometimes harsh EMI environment of being mounted immediately adjacent to, or on the same PCB as a system that is pushing 1kW or more power via ultrasonic power MOSFET switching through lightweight flight control stacks.
### 3.1.4 Electrical Isolation for Sensor Components
Separate VDD from VDD_IO
Implement additional filtering on VDD if using a single 3v reg for MCU and Sensor
#### 3.1.4.1 Regulated Power and LDO Power Configurations
A key aspect of flight controller performance and longevity is design of the low powered rails that supply power to inertial motion units and the STM microcontroller. Providing robust low-ripple power to these devices provides the maximum performance potential and hardware longevity for operation in the challenging EMI environments present on these craft.
Similarly, 3.3V, 5V, and 9-12V BEC power needs to provide consistent power at the intended current draw. For example, 3.3V 500mA is a recommended minimum current. ‘4.5V’ (5V USB supplied power) should be capable of powering a receiver and GPS unit, which may require over 700mA.
Standard battery powered 5V rails should provide at least 1A, preferably 1.5A to 2A in order to provide higher current if anticipated to be used with a large number of peripherals (such as LED strips, 5V powered FPV Video Systems, or as source power to HD cameras).
Providing a 10V 2A BEC is also strongly recommended with flight controller designs, as this supports high definition video systems, and even enables better analog video system power options.
Each of these can be optionally connected to PINIO driven pit switches, and/or jumper pad setups that enable end users to select constant-on or transistor switched behavior, particularly if located to support video transmission systems.
Such 10V regulators should function at full rated current down to 10V input voltage to support the BEC output from some ESCs.
Again, providing robust low-ripple power to these devices provides the maximum performance potential and hardware longevity for operation in the challenging EMI environments present on these craft.
#### 3.1.4.2 ADC Circuitry (e.g. for Current Sensors)
Using ADC measurements on the flight controller to actively monitor current information from ESCs, or if using integral FC-PDB, minimizing noise on the circuit improves the accuracy and jitter of these signals. To reduce noise from current reading, instead of transfering voltage to FC, send current to FC then move RL Load resistor associated with INA31 onto FC with capacitor in parallel.
https://www.ti.com/lit/ds/symlink/ina139.pdf
Ideally there should be a pair of bridgeable pads on the ESC in series with the load resistor so that with legacy FCs one can bridge it to include the resistor. Correspondingly on FCs we should have a 82K resistor (and parallel 100nF cap), again with series bridging pads which would be left unbridged when paired with legacy ESCs.
When using an ESC/FC stack supporting the above bridging pads, one would leave the ESC pads open and short those on the FC for noise free current reading. In all other cases the ESC pads would be bridged or the FC’s left open to support the current configuration at the expense of higher noise.
Note that the above recommendation is based on the fact that if current if fed into one end of a wire, that same current will always flow out of the other end, whereas with a voltage there will be a voltage drop due to resistance in both that wire and the ground return, and the currents flowing through them. Converting the current to a voltage at the input of the ADC will result in significant noise reduction.
#### 3.1.4.3 Supporting Additional Features
Numerous standard features have become common with flight controller design, for example chips such as MAX7456 to enable monochrome On-Screen Display (OSD) functionality, including Barometers to supplement IMU functionality to provide more accurate altitude estimates, PINIO transistor switched output pads, LED pads, or additional PWM/Motor outputs.
In order to fully support these additional features, it remains strongly recommended that hardware manufacturers incorporate early developer feedback to ensure complete functionality.
#### 3.1.4.4 SWD Debug Support
In order to aid development of Betaflight firmware, and to debug FC specific issues, it is highly beneficial to have test points for the SWDIO/SWCLK lines together with 3V3 and ground connections to enable connection of a debugger such as a Segger JLink or ST-Link. This speeds up resolution of issues hugely, so if at all possible do not use those pins (PA13/PA14) for other purposes.
#### 3.1.4.5 Blackbox Support
Black box of at least 8mb should also be standard on all fcs as it’s literally impossible to problem solve a tune or flight issues with out black box.
## 3.2 Resource Selection Considerations
### 3.2.1 Assigning Resource by Priority
Good resource allocation ensures maximum flexibility in the selection of the modes available to users (for example with DSHOT) and also minimizes conflict in timer and DMA stream allocation.
Assign motor channels with highest priority …
#### 3.2.1.1 G4 and H7 Resource Selection
G4 and H7 have very flexible DMA controls, therefore we have no specific requirement for these processors.
#### 3.2.1.2 F7 Resource Selection
F7X2 MCUs provide greater flexibility and do not require inverters in order to support protocols such as SBUS, SmartPort, or F.Port. They also do not exhibit the SPI 1 DMA limitations of F4 processors.
Bitbang Dshot communcation protocol will always use Timer 1 and Timer 8 - Do NOT use these timers for any other functions
#### 3.2.1.3 F4 Resource Selection
Due to F4 MCU management of serial inversion, any pins that implement inversion should be clearly marked, and ideally not result in reduced capability of that UART when used with un-inverted peripheral connections.
For Betaflight 4.4 and later versions, the expected default configuration will take advantage of Bidirectional DShot, therefore default Looprates and DShot of 8k/4k/DShot-300 are anticipated to be the stock configuration. This does specifically require Motor Resource allocation to enable proper bidirectional DShot communication.
If using Bitbang DShot, when SPI Bus #1 is to be used for the gyro, care must be taken to ensure that motor pins are assigned to appropriate timers. This is because Bitbang DSHOT uses DMA2 to write to GPIO ports. If this is enabled, it is not possible to enable DMA on an SPI bus using DMA2.
Practically speaking this means that we can’t support DMA on SPI bus 1 (which uses DMA2) on F405 and F411 processors. It is better to put multiple devices on other SPI busses that use SPI bus 1, which is typically used for the gyro.
Bitbang Dshot communcation protocol will always use Timer 1 and Timer 8 - do NOT use these pins for any other functions.
Further reading: Section 2.1.10 of the errata at
https://www.st.com/resource/en/errata_sheet/dm00037591-stm32f405407xx-and-stm32f415417xx-device-limitations-stmicroelectronics.pdf
Corruption may occurs on DMA2 if AHB peripherals (e.g. GPIO ports) are accessed concurrently with APB peripherals (eg SPI busses).
Practically, this means that all pins should be on the same port, or at most two ports, so that only one (or two) DMA streams are required for bitbanged operation.
* Additional Recommendations:
Use A00 for LED Strip (diatone fury resources insert as example)
Use pins PA13 and 14 for debug options. Including test point pads (these can by tiny) as well as the necessary 3.3v/Ground pads is strongly recommended.
The DIAT-FURYF4OSD is a good example configuration for F405 boards, because it uses pins with timers that do not experience any conflicts. Motors are on port pins with associated timers and use neither TIM 1 nor N Channels.
As an additional reference design, see the Fenix F405: https://oshwlab.com/jyesmith/fenix-f405
## 3.3 Markings, version numbers, and documentation
It is highly recommended that the flight controller Manufacturer Name, Board Name, and Board Design Revision be marked clearly on the flight controller itself. Where possible, indicating the firmware target name, or selecting a firmware target name to minimize confusion reduces the likelihood of an end user attempting to configure the flight controller with an incorrect target.
### 3.3.1 Creating Design Revisions and Communicating Changes
Providing sufficient marking and documentation will be required for hardware approval. Screen printing on the flight controller critical information - pin identifiers, board name, revision, and manufacturer will be necessary, with sufficient detail to enable end users to properly connect devices to the flight controller.
When creating flight controller revisions and improvements, it is strongly recommended that indications and documentations are made available, particularly when pinout changes, output rating changes, or hardware bill of material changes. Any board configuration change requiring a user to change configuration behavior must have an accompanying change in marking to indicate (e.g. changing an IMU, or altering the pinout of solder pads).
Following standard marking practices (e.g. V, VCC, or VBAT for battery voltage, G or GND for ground, T for ESC Telemetry, C for Current Sensing ADC, etc.) is also strongly recommended. Similarly, providing consistent color selections for pin header JST wiring looms, and consistent marking on the PCB is always preferable for robust building and troubleshooting.
Providing a CLI dump file that enables users to reset their flight controller to stock configuration is needed if a dedicated target is not provided. This is particularly relevant if multiple versions of a board which share targets but have significant hardware changes are present, a CLI dump file for each flight controller revision must be made available to users.
### 3.3.2 Implementing Flight Controller Designs for Ready-To-Fly Craft
#### 3.3.2.1 General Recommendations and Documentation
// A good example of properly documenting and supporting ready-to-fly craft would be the way EMAX makes entire CLI dumps of every craft which enables users to revert systems to the as-shipped software configuration
#### 3.3.2.2 Leveraging the Betaflight Preset System
One of the most powerful tools for end users that can save significant time and reduce the likelihood of misconfiguration is the Preset system. Developing an Official Betaflight preset and generating a pull request with the assistance of the Betaflight development team allows for end users to quickly and easily configure their craft. The versatility of selectable options, RC Link presets, and even Tune & Filter presets allow for diverse configurations of RTF craft products to be supported.
Applying and using presets not only saves users significant time, but reduces the likelihood of data entry errors or incorrect configurations to be applied, which can be of particular importance for products aimed at less experienced users.
For manufacturers providing configuration presets for flight controllers (strongly recommended), providing documentation of suggested locations to connect peripheral devices, match the provided preset menu selections can greatly assist end users with proper configuration of their craft. These should include selecting appropriate PID loop rates, DShot data rates, IMU-specific Gyro Lowpass Filtering, Receiver installation (including options with the correct Port, protocol, SerialRX_Inversion, and SerialRX_HalfDuplex), HD FPV MSP port installation, VTX control (including protocol(s), port, and optional pit mode states), GPS (port and protocols), LEDs, and any PINIO type peripheral connections where applicable.
Working with the Betaflight development team provides opportunities to develop presets that can bring RTF craft back to stock configuration, enable users to rapidly configure ‘Plug & Play’ systems based on selected RC link hardware installed per documentation, and even permit Betaflight developers with extensive experience developing precise tunes for craft to generate a range of tunes for that specific product.
## 3.4 Electronic Speed Controller Compatibility
A significant amount of the added performance available in Betaflight 4.X and beyond is based on leveraging ESC RPM telemetry data in order to use RPM Notch Filters and Dynamic Idle features.
### 3.4.1 For 32 Bit ESCs (BLHeli_32 and AM32)
Betaflight supports all 32-bit ESCs currently available, with BLHeli_32 and AM32 configurations, as well as APD configurations being capable of supporting bidirectional DShot, and user-configured operation with bidirectional DShot disabled.
Additional DShot extended telemetry will be implemented over time as demonstrated stable, however current extended telemetry options will only be enabled by user selection.
Providing 32b ESCs with firmware prior to 32.66 will require end users to reflash ESCs. Craft will not arm due to the RPMFILTER error that will be present due to a lack of RPM Telemetry. The required solution will be disabling Bidirectional DShot (not recommended) or reflashing ESC (strongly recommended).
### 3.4.2 For 8 Bit ESCs (BLHeli_S)
Betaflight will continue to support all current 8-bit ESC configurations, however these will rely on bidirectional DShot enabled by default.
For Betaflight 4.4 and subsequent releases, the Betaflight team will NO LONGER support BLHeli_S as a default configuration. The enhanced flight performance made possible by operating with Bidirectional DShot features enabled will become the default behavior for all Betaflight craft..
8-bit ESCs can run **BlueJay**, **JESC**.
For hardware, such as AIO boards which incorporate ESC and FC, the expectation will be that hardware comes with installed firmware meeting these requirements. The preferred option in this case is **BlueJay**, due to the ability to adjust PWM frequencies and ease of end user support for other functionality across MCU layouts.
Failure to comply with this requirement will require end users to perform firmware reflash of ESCs, and without reflashing craft will not arm due to the RPMFILTER error that will be present due to a lack of RPM Telemetry.
The required solution will be disabling Bidirectional DShot (not recommended) or reflashing ESC (strongly recommended).
### 3.4.3 For Legacy ESCs
For legacy ESCs that are only capable of OneShot and Multishot utilization, end users will be required to disable DShot in order to continue with operations. This situation only applies to pre-BLHeli_S ESC architectures, and is not anticipated to be an issue for the vast majority of users. The lack of DShot capability has been part of Betaflight operation since 3.2 (in 2017), therefore legacy support for this obsolescent hardware will require additional end user configuration, however these are still indirectly supported and may exhibit improved performance with the most recent Betaflight versions despite being unable to take advantage of bidirectional DShot features.
# 4 Reference Tables
## 4.1 Rated Looptime and Performance
Rated Performance of specific MCU, IMU, and ESC DShot Protocol Combinations
These are the **strongly recommended** default configurations
For stock configurations, and implementations of ready-to-fly craft, the following configurations are the officially recommended configurations.
Importantly, although the Bidirectional DShot ENABLED may require lower PID Loop Rates for F411 and F405 flight controllers, the difference in loop time is 125us or 250us. These are microseconds. The improvements in filtering using RPM Notches alongside Sliding-DFT Multi-Dynamic notches can provide improvements on the scale of milliseconds for phase latency when processing IMU signals to post-filter information that can be used for PID/Mixer calculations. The flight performance of using bidirectional DShot is absolutely worth the PID Looptime Tradeoff, due to that order of magnitude improvement in cumulative signal pathway delay enabled with more targeted notch filtering schema.
Looptime and Performance Recommendation Table:
| MCU | IMU | Sampling Rate | Bidirectional DShot Status | PID Loop Rate | DShot Protocol |
| :--- | :--- | :--- | :--- | :--- | :--- |
| F7X2, H7XX, G4XX, and similar | MPU60X0, ICM2060X, ICM42688P | 8 kHz | Enabled or Disabled | 8 kHz | DShot 600 |
| | BMI-270 | 3.2 kHz | Enabled or Disabled | 3.2 kHz | DShot 300 |
| F405 | MPU6000, MPU6050, ICM20601, ICM42688P | 8 kHz | Enabled | 4 kHz | DShot 300 |
| | MPU6000, MPU6050, ICM20601, ICM42688P | 8 kHz | Disabled (not recommended) | 8 kHz | DShot 600 |
| | BMI-270 | 3.2 kHz | Enabled or Disabled | 3.2 kHz | DShot 300 |
| F411 UART Rx ** | MPU6000, MPU6050, ICM20601 | 8 kHz | Enabled | 4 kHz | DShot 300 |
| | MPU6000, MPU6050, ICM20601 | 8 kHz | Disabled (not recommended) | 8 kHz | DShot 600 |
| | BMI-270 | 3.2 kHz | Enabled | 3.2 kHz | DShot 300 |
| F411 SPI Rx *** | MPU6000, MPU6050, ICM20601 | 8 kHz | Enabled | 2 kHz | DShot 300 |
| | MPU6000, MPU6050, ICM20601 | 8 kHz | Disabled (not recommended) | 4 kHz | DShot 300 |
| | BMI-270 | 3.2 kHz | Enabled | 1.6 kHz | DShot 300 |
| | BMI-270 | 8 kHz | Disabled (not recommended) | 3.2 kHz | DShot 300 |
** For F411 UART Rx applications, using both available UARTs AND enabling SoftSerial, Accelerometer, large numbers of OSD elements, and using a larger number of filters, stability may require lowering looprate to 2kHz
*** There are no SPI Rx solutions that are strongly recommended for future development due to challenges in resource allocation and scheduler inconsistency that consistently emerge with SPI Rx designs.
Additionally, there are no RC ecosystems that are actively developing a supported SPI Rx solution (ExpressLRS 3.0 and later do not support SPI; FrSky does not support SPI Rx over any protocol, and other SPI Rx solutions have been fully deprecated).
Note that the use of gyros such as the BMI270 lowers the gyro loop rate from 8kHz to 3.2kHz and is therefore advantageous for F411 designs.
## 4.2 Definitions for targets
As reference please choose the defines for your target from this list as applicable for the target to select appropiate hardware for the cloud build.
### 4.2.1 Defines for GYRO and ACC
Define at least one gyro and one accelerometer.
#define USE_GYRO_SPI_MPU6000
#define USE_ACC_SPI_MPU6000
#define USE_GYRO_SPI_MPU6500
#define USE_ACC_SPI_MPU6500
#define USE_GYRO_SPI_ICM20689
#define USE_ACC_SPI_ICM20689
#define USE_ACCGYRO_BMI270
#define USE_GYRO_SPI_ICM42605
#define USE_ACC_SPI_ICM42605
#define USE_GYRO_SPI_ICM42688P
#define USE_ACC_SPI_ICM42688P
### 4.2.2 Defines for FLASH
Define correct flash driver(s) only if physical present on the board.
#define USE_FLASH_M25P16 // 16MB Micron M25P16 and others (https://github.com/betaflight/betaflight/blob/master/src/main/drivers/flash_m25p16.c#L68)
#define USE_FLASH_W25N01G // 1Gb NAND flash support
#define USE_FLASH_W25M // 16, 32, 64 or 128MB Winbond stacked die support
#define USE_FLASH_W25M512 // 512Kb (256Kb x 2 stacked) NOR flash support
#define USE_FLASH_W25M02G // 2Gb (1Gb x 2 stacked) NAND flash support
#define USE_FLASH_W25Q128FV // 16MB Winbond 25Q128 and the 8MB Winbond W25Q8 types
### 4.2.3 Defines for BARO
Define a barometer only if physical present on the board.
#define USE_BARO_MS5611
#define USE_BARO_SPI_MS5611
#define USE_BARO_BMP280
#define USE_BARO_SPI_BMP280
#define USE_BARO_BMP388
#define USE_BARO_SPI_BMP388
#define USE_BARO_LPS
#define USE_BARO_SPI_LPS
#define USE_BARO_QMP6988
#define USE_BARO_SPI_QMP6988
#define USE_BARO_DPS310
#define USE_BARO_SPI_DPS310
#define USE_BARO_2SMBP_02B
#define USE_BARO_SPI_2SMBP_02B
### 4.2.4 Defines for MAG
Define a magnetometer only if physical present of the board.
#define USE_MAG_DATA_READY_SIGNAL
#define USE_MAG_HMC5883
#define USE_MAG_SPI_HMC5883
#define USE_MAG_QMC5883
#define USE_MAG_LIS3MDL
#define USE_MAG_AK8963
#define USE_MAG_MPU925X_AK8963
#define USE_MAG_SPI_AK8963
#define USE_MAG_AK8975
### 4.2.5 Defines for SX1280
For SPI based SX1280 target designs add the following defines:
#define USE_RX_EXPRESSLRS
#define USE_RX_EXPRESSLRS_TELEMETRY
#define USE_RX_SX1280
#define RX_CHANNELS_AETR
### 4.2.6 Defines for OSD
#define USE_MAX7456
### 4.2.7 Defines for SDCARD
#define USE_SDCARD
### 4.2.8 Defines for CC2500
For SPI based CC2500 target designs add the following define:
#define USE_RX_CC2500
## 4.3 Usage of the cloud build API
See reference to [cloud build API](https://github.com/betaflight/betaflight/blob/master/docs/Cloud%20build%20API.md)
# 5 Information for Marketing Purposes
* Betaflight is an open source flight controller software (firmware) used to fly multi-rotor and fixed wing aircraft.
* Betaflight is a fork of Baseflight and Cleanflight, with an emphasis focused on flight performance, leading-edge feature additions, and wide target support. Combining cutting edge flight performance with diverse hardware support, Betaflight is the leading solution for high performance small unmanned aircraft.
* This project is operated and maintained by volunteers, with community support from pilots with a diverse range of flight goals.
* Pilots flying Betaflight have won every major FAI, MultiGP, and other major FPV multirotor racing event since 2019.

103
docs/Migrating from baseflight.md
View file

@ -1,103 +0,0 @@
# Migrating from baseflight
## Procedure
**First ensure your main flight battery is disconnected or your props are off!**
Before flashing with cleanflight, dump your configs for each profile via the CLI and save to a text file.
```
profile 0
dump
profile 1
dump
profile 2
dump
```
Then after flashing cleanflight paste the output from each dump command into the cli, switching profiles as you go.
You'll note that some commands are not recognised by cleanflight when you do this. For the commands that are not recognised look
up the new configuration options and choose appropriate values for the settings. See below for a list of differences.
Once you've done this for the first profile, save the config. Then verify your config is OK, e.g. features serial ports, etc.
When you've verified the first profile is OK repeat for the other profiles.
It's also advisable to take screenshots of your AUX settings from baseflight configurator and then after re-applying the settings
verify your aux config is correct - aux settings are not backwards compatible.
## CLI command differences from baseflight
In general all CLI commands use underscore characters to separate words for consistency. In baseflight the format of CLI commands is somewhat haphazard.
### gps_baudrate
reason: new serial port configuration.
See `serial` command.
### gps_type
reason: renamed to `gps_provider` for consistency
### serialrx_type
reason: renamed to `serialrx_provider` for consistency
### rssi_aux_channel
reason: renamed to `rssi_channel` for improved functionality
Cleanflight supports using any RX channel for rssi. Baseflight only supports AUX1 to 4.
In Cleanflight a value of 0 disables the feature, a higher value indicates the channel number to read RSSI information from.
Example: to use RSSI on AUX1 in Cleanflight use `set rssi_channel = 5`, since 5 is the first AUX channel (this is equivalent to `set rssi_aux_channel = 1` in Baseflight).
### failsafe_detect_threshold
reason: improved functionality
See `rx_min_usec` and `rx_max_usec` in Failsafe documentation.
### emfavoidance
reason: renamed to `emf_avoidance` for consistency
### yawrate
reason: renamed to `yaw_rate` for consistency
### yawdeadband
reason: renamed to `yaw_deadband` for consistency
### midrc
reason: renamed to `mid_rc` for consistency
### mincheck
reason: renamed to `min_check` for consistency
### maxcheck
reason: renamed to `max_check` for consistency
### minthrottle
reason: renamed to `min_throttle` for consistency
### maxthrottle
reason: renamed to `max_throttle` for consistency
### mincommand
reason: renamed to `min_command` for consistency
### deadband3d_low
reason: renamed to `3d_deadband_low` for consistency
### deadband3d_high
reason: renamed to `3d_deadband_high` for consistency
### deadband3d_throttle
reason: renamed to `3d_deadband_throttle` for consistency
### neutral3d
reason: renamed to `3d_neutral` for consistency
### alt_hold_throttle_neutral
reason: renamed to `alt_hold_deadband` for consistency
### gimbal_flags
reason: seperation of features.
see `gimbal_mode` and `CHANNEL_FORWARDING` feature

315
docs/Mixer.md
View file

@ -1,315 +0,0 @@
# Mixer
Cleanflight supports a number of mixing configurations as well as custom mixing. Mixer configurations determine how the servos and motors work together to control the aircraft.
## Configuration
To use a built-in mixing configuration, you can use the Chrome configuration GUI. It includes images of the various mixer types to assist in making the proper connections. See the Configuration section of the documentation for more information on the GUI.
You can also use the Command Line Interface (CLI) to set the mixer type:
1. Use `mixer list` to see a list of supported mixes
2. Select a mixer. For example, to select TRI, use `mixer TRI`
3. You must use `save` to preserve your changes
## Supported Mixer Types
| Name | Description | Motors | Servos |
| ---------------- | ------------------------- | -------------- | ---------------- |
| TRI | Tricopter | M1-M3 | S1 |
| QUADP | Quadcopter-Plus | M1-M4 | None |
| QUADX | Quadcopter-X | M1-M4 | None |
| BI | Bicopter (left/right) | M1-M2 | S1, S2 |
| GIMBAL | Gimbal control | N/A | S1, S2 |
| Y6 | Y6-copter | M1-M6 | None |
| HEX6 | Hexacopter-Plus | M1-M6 | None |
| FLYING\_WING | Fixed wing; elevons | M1 | S1, S2 |
| Y4 | Y4-copter | M1-M4 | None |
| HEX6X | Hexacopter-X | M1-M6 | None |
| OCTOX8 | Octocopter-X (over/under) | M1-M8 | None |
| OCTOFLATP | Octocopter-FlatPlus | M1-M8 | None |
| OCTOFLATX | Octocopter-FlatX | M1-M8 | None |
| AIRPLANE | Fixed wing; Ax2, R, E | M1 | S1, S2, S3, S4 |
| HELI\_120\_CCPM | 3D-capable Helicopter | M1 | S1, S2, S3, S4 |
| HELI\_90\_DEG | | | |
| VTAIL4 | Quadcopter with V-Tail | M1-M4 | N/A |
| HEX6H | Hexacopter-H | M1-M6 | None |
| PPM\_TO\_SERVO | | | |
| DUALCOPTER | Dualcopter | M1-M2 | S1, S2 |
| SINGLECOPTER | Conventional helicopter | M1 | S1 |
| ATAIL4 | Quadcopter with A-Tail | M1-M4 | N/A |
| CUSTOM | User-defined | | |
| CUSTOM AIRPLANE | User-defined airplane | M1-M2 | S1-S8 |
| CUSTOM TRICOPTER | User-defined tricopter | | |
## Servo configuration
The cli `servo` command defines the settings for the servo outputs.
The cli mixer `smix` command controls how the mixer maps internal FC data (RC input, PID stabilization output, channel forwarding, etc) to servo outputs.
### Channel Forwarding
Channel Forwarding allows you to forward your AUX channels directly to servos over PWM pins 5-8. You can enable it under features in the GUI or using the cli
with ``feature CHANNEL_FORWARDING``. This requires you to run PPM or another serial RC protocol, and is currently supported on NAZE and SPRACINGF3 targets.
Note that if you have the led feature enabled on the NAZE target, AUX1-2 is mapped to PWM13-14 instead. So for instance if you enable this feature on a Naze
AUX1 from your receiver will automatically be forwarded to PWM5 as a servo signal.
### cli `servo`
`servo <min> <max> <middle> <angleMin> <angleMax> <rate> <forwardFromChannel>`
- `<min>`, `<max>` - limit servo travel, in uS
- `<middle>` - mid value when not forwarding, value from servo mixer is added to this.
- `<angleMin>`, `<angleMax>` - unused
- `<rate>` - scale for value from servo mixer or gimbal input, -100% .. 100%
- `<forwardFromChannel>` - use RC channel value as reference instead of `<middle>`. Servo will follow given RC channel, with possible correction from servo mixer. `<min>`, `<max>` are still honored.
## Servo filtering
A low-pass filter can be enabled for the servos. It may be useful for avoiding structural modes in the airframe, for example.
### Configuration
Currently it can only be configured via the CLI:
1. Use `set servo_lowpass_freq = nnn` to select the cutoff frequency. Valid values range from 10Hz to 400Hz, second order filter is used.
2. Use `set servo_lowpass_enable = ON` to enable filtering.
### Tuning
One method for tuning the filter cutoff is as follows:
1. Ensure your vehicle can move at least somewhat freely in the troublesome axis. For example, if you are having yaw oscillations on a tricopter, ensure that the copter is supported in a way that allows it to rotate left and right to at least some degree. Suspension near the CG is ideal. Alternatively, you can just fly the vehicle and trigger the problematic condition you are trying to eliminate, although tuning will be more tedious.
2. Tap the vehicle at its end in the axis under evaluation. Directly commanding the servo in question to move may also be used. In the tricopter example, tap the end of the tail boom from the side, or command a yaw using your transmitter.
3. If your vehicle oscillates for several seconds or even continues oscillating indefinitely, then the filter cutoff frequency should be reduced. Reduce the value of `servo_lowpass_freq` by half its current value and repeat the previous step.
4. If the oscillations are dampened within roughly a second or are no longer present, then you are done. Be sure to run `save`.
## Custom Motor Mixing
Custom motor mixing allows for completely customized motor configurations. Each motor must be defined with a custom mixing table for that motor. The mix must reflect how close each motor is with reference to the CG (Center of Gravity) of the flight controller. A motor closer to the CG of the flight controller will need to travel less distance than a motor further away.
Steps to configure custom mixer in the CLI:
1. Use `mixer custom` to enable the custom mixing.
2. Use `mmix reset` to erase the any existing custom mixing.
3. Optionally use `mmix load <name>` to start with one of available mixers.
4. Issue a `mmix` statement for each motor.
The `mmix` statement has the following syntax: `mmix n THROTTLE ROLL PITCH YAW`
| Mixing table parameter | Definition |
| ---------------------- | ---------- |
| n | Motor ordering number |
| THROTTLE | Indicates how much throttle is mixed for this motor. All values used in current configurations are set to 1.0 (full throttle mixing), but other non-zero values may be used. Unused set to 0.0. |
| ROLL | Indicates how much roll authority this motor imparts to the roll of the flight controller. Accepts values nominally from -1.0 to 1.0. |
| PITCH | Indicates the pitch authority this motor has over the flight controller. Also accepts values nominally from -1.0 to 1.0. |
| YAW | Indicates the direction of the motor rotation in relationship with the flight controller. 1.0 = CCW -1.0 = CW. |
Note: the `mmix` command may show a motor mix that is not active, custom motor mixes are only active for models that use custom mixers.
Note: You have to configure every motor number starting at 0. Your command will be ignored if there was no `mmix` command for the previous motor number (mixer stops on first THROTTLE value that is zero). See example 5.
## Custom Servo Mixing
Custom servo mixing rules can be applied to each servo. Rules are applied in the order they are defined.
##### `smix`
Prints current servo mixer
Note: the `smix` command may show a servo mix that is not active, custom servo mixes are only active for models that use custom mixers.
##### `smix reset`
Erase custom mixer. Servo reversal in current profile ONLY is erased too.
##### `smix load <name>`
Load servo part of given configuration (`<name>` is from `mixer list`)
##### `smix <rule> <servo> <source> <rate> <speed> <min> <max> <box>`
- `<rule>` is index of rule, used mainly for bookkeeping. Rules are applied in this order, but ordering has no influence on result in current code.
- `<servo>`
| id | Servo slot |
|----|--------------|
| 0 | GIMBAL PITCH |
| 1 | GIMBAL ROLL |
| 2 | ELEVATOR / SINGLECOPTER\_4 |
| 3 | FLAPPERON 1 (LEFT) / SINGLECOPTER\_1 |
| 4 | FLAPPERON 2 (RIGHT) / BICOPTER\_LEFT / DUALCOPTER\_LEFT / SINGLECOPTER\_2 |
| 5 | RUDDER / BICOPTER\_RIGHT / DUALCOPTER\_RIGHT / SINGLECOPTER\_3 |
| 6 | THROTTLE (Based ONLY on the first motor output) |
| 7 | FLAPS |
Only some `<servo>` channels are connected to output, based on mode. For custom modes:
- RUDDER for CUSTOM\_TRI
- ELEVATOR ... FLAPS for CUSTOM\_AIRPLANE
- no servos for CUSTOM
GIMBAL handling is hard-coded, mmix rule is ignored.
- `<source>`
| id | Input sources |
|----|-----------------|
| 0 | Stabilized ROLL |
| 1 | Stabilized PITCH |
| 2 | Stabilized YAW |
| 3 | Stabilized THROTTLE (ONLY the first motor output) |
| 4 | RC ROLL |
| 5 | RC PITCH |
| 6 | RC YAW |
| 7 | RC THROTTLE |
| 8 | RC AUX 1 |
| 9 | RC AUX 2 |
| 10 | RC AUX 3 |
| 11 | RC AUX 4 |
| 12 | GIMBAL PITCH |
| 13 | GIMBAL ROLL |
Stabilized ROLL/PITCH/YAW is taken directly from RC command when in PASSTHRU mode.
- `<rate>` is used to scale `<source>`, -100% - 100% is allowed. Note that servo reversal may be applied, see below. Zero `<rate>` will terminate smix table.
- `<speed>` will limit <source> speed when non-zero. This speed is taken per-rule, so you may limit only some sources. Value is maximal change of value per loop (1ms with default configuration)
- `<min>` `<max>` - Value in percentage of full servo range. For symmetrical servo limits (equal distance between mid and min/max), 0% is servo min, 50% is servo center, 100% is max servo position. When mid position is asymmetrical, 0% and 100% limits will be shifted.
- `<box>` rule will be applied only when `<box>` is zero or corresponding SERVOx mode is enabled.
##### `smix reverse`
Print current servo reversal configuration
##### `smix reverse <servo> <source> r|n`
Each `<source>` may be `r`eversed or `n`ormal for given `<servo>`. It is almost equivalent to using negative <rate> in given rule, but `<min>, `<max>` limits are applied to value before reversing.
`smix reverse` works for non-custom mixers too.
e.g. when using the TRI mixer to reverse the tail servo on a tricopter use this:
`smix reverse 5 2 r`
i.e. when mixing rudder servo slot (`5`) using Stabilized YAW input source (`2`) reverse the direction (`r`)
`smix reverse` is a per-profile setting. So ensure you configure it for your profiles as required.
### Example 1: A KK2.0 wired motor setup
Here's an example of a X configuration quad, but the motors are still wired using the KK board motor numbering scheme.
```
KK2.0 Motor Layout
1CW 2CCW
\ /
KK
/ \
4CCW 3CW
```
1. Use `mixer custom`
2. Use `mmix reset`
3. Use `mmix 0 1.0, 1.0, -1.0, -1.0` for the Front Left motor. It tells the flight controller the #1 motor is used, provides positive roll, provides negative pitch and is turning CW.
4. Use `mmix 1 1.0, -1.0, -1.0, 1.0` for the Front Right motor. It still provides a negative pitch authority, but unlike the front left, it provides negative roll authority and turns CCW.
5. Use `mmix 2 1.0, -1.0, 1.0, -1.0` for the Rear Right motor. It has negative roll, provides positive pitch when the speed is increased and turns CW.
6. Use `mmix 3 1.0, 1.0, 1.0, 1.0` for the Rear Left motor. Increasing motor speed imparts positive roll, positive pitch and turns CCW.
### Example 2: A HEX-U Copter
Here is an example of a U-shaped hex; probably good for herding giraffes in the Sahara. Because the 1 and 6 motors are closer to the roll axis, they impart much less force than the motors mounted twice as far from the FC CG. The effect they have on pitch is the same as the forward motors because they are the same distance from the FC CG. The 2 and 5 motors do not contribute anything to pitch because speeding them up and slowing them down has no effect on the forward/back pitch of the FC.
```
HEX6-U
.4........3.
............
.5...FC...2.
............
...6....1...
```
|Command| Roll | Pitch | Yaw |
| ----- | ---- | ----- | --- |
| Use `mmix 0 1.0, -0.5, 1.0, -1.0` | half negative | full positive | CW |
| Use `mmix 1 1.0, -1.0, 0.0, 1.0` | full negative | none | CCW |
| Use `mmix 2 1.0, -1.0, -1.0, -1.0` | full negative | full negative | CW |
| Use `mmix 3 1.0, 1.0, -1.0, 1.0` | full positive | full negative | CCW |
| Use `mmix 4 1.0, 1.0, 0.0, -1.0` | full positive | none | CW |
| Use `mmix 5 1.0, 0.5, 1.0, 1.0` | half positive | full positive | CCW |
### Example 3: Custom tricopter
```
mixer CUSTOMTRI
mmix reset
mmix 0 1.000 0.000 1.333 0.000
mmix 1 1.000 -1.000 -0.667 0.000
mmix 2 1.000 1.000 -0.667 0.000
smix reset
smix 0 5 2 100 0 0 100 0
profile 0
smix reverse 5 2 r
profile 1
smix reverse 5 2 r
profile 2
smix reverse 5 2 r
```
### Example 4: Custom Airplane with Differential Thrust
Here is an example of a custom twin engine plane with [Differential Thrust](http://rcvehicles.about.com/od/rcairplanes/ss/RCAirplaneBasic.htm#step8)
Motors take the first 2 pins, the servos take pins as indicated in the [Servo slot] chart above.
Settings bellow have motor yaw influence at "0.3", you can change this number to have more or less differential thrust over the two motors.
Note: You can look at the Motors tab in [Cleanflight Cofigurator](https://chrome.google.com/webstore/detail/cleanflight-configurator/enacoimjcgeinfnnnpajinjgmkahmfgb?hl=en) to see motor and servo outputs.
| Pins | Outputs |
|------|------------------|
| 1 | Left Engine |
| 2 | Right Engine |
| 3 | Pitch / Elevator |
| 4 | Roll / Aileron |
| 5 | Roll / Aileron |
| 6 | Yaw / Rudder |
| 7 | [EMPTY] |
| 8 | [EMPTY] |
```
mixer CUSTOMAIRPLANE
mmix reset
mmix 0 1.0 0.0 0.0 0.3 # Left Engine
mmix 1 1.0 0.0 0.0 -0.3 # Right Engine
smix reset
# Rule Servo Source Rate Speed Min Max Box
smix 0 3 0 100 0 0 100 0 # Roll / Aileron
smix 1 4 0 100 0 0 100 0 # Roll / Aileron
smix 2 5 2 100 0 0 100 0 # Yaw / Rudder
smix 3 2 1 100 0 0 100 0 # Pitch / Elevator
```
### Example 5: Use motor output 0,1,2,4 because your output 3 is broken
For this to work you have to make a dummy mmix for motor 3. We do this by just saying it has 0 impact on yaw, roll and pitch.
```
mixer custom
mmix reset
mmix 0 1.0, -1.0, 1.0, -1.0
mmix 1 1.0, -1.0, -1.0, 1.0
mmix 2 1.0, 1.0, 1.0, 1.0
mmix 3 1.0, 0.0, 0.0, 0.0
mmix 4 1.0, 1.0, -1.0, -1.0
save
```

117
docs/Modes.md
View file

@ -1,117 +0,0 @@
# Modes
There are various modes that can be toggled on or off. Modes can be enabled/disabled by stick positions, auxiliary receiver channels and other events such as failsafe detection.
| ID | Short Name | Function |
| -- | ------------------------ | ------------------------------------------------------------------------------------ |
| 0 | ARM | Enables motors and flight stabilisation |
| 1 | ANGLE | Legacy auto-level flight mode |
| 2 | HORIZON | Auto-level flight mode |
| 4 | ANTI GRAVITY | Prevents dips and rolls on fast throttle changes |
| 5 | MAG | Heading lock |
| 6 | HEADFREE | Head Free - When enabled yaw has no effect on pitch/roll inputs |
| 7 | HEADADJ | Heading Adjust - Sets a new yaw origin for HEADFREE mode |
| 8 | CAMSTAB | Camera Stabilisation |
| 12 | PASSTHRU | Pass roll, yaw, and pitch directly from rx to servos in airplane mix |
| 13 | BEEPERON | Enable beeping - useful for locating a crashed aircraft |
| 15 | LEDLOW | Switch off LED\_STRIP output |
| 17 | CALIB | Start in-flight calibration |
| 19 | OSD | Enable/Disable On-Screen-Display (OSD) |
| 20 | TELEMETRY | Enable telemetry via switch |
| 23 | SERVO1 | Servo 1 |
| 24 | SERVO2 | Servo 2 |
| 25 | SERVO3 | Servo 3 |
| 26 | BLACKBOX | Enable BlackBox logging |
| 27 | FAILSAFE | Enter failsafe stage 2 manually |
| 28 | AIRMODE | Alternative mixer and additional PID logic for more stable copter |
| 29 | 3D | Enable 3D mode |
| 30 | FPV ANGLE MIX | Apply yaw rotation relative to a FPV camera mounted at a preset angle |
| 31 | BLACKBOX ERASE | Erase the contents of the onboard flash log chip (takes > 30 s) |
| 32 | CAMERA CONTROL 1 | Control function 1 of the onboard camera (if supported) |
| 33 | CAMERA CONTROL 2 | Control function 2 of the onboard camera (if supported) |
| 34 | CAMERA CONTROL 3 | Control function 3 of the onboard camera (if supported) |
| 35 | FLIP OVER AFTER CRASH | Reverse the motors to flip over an upside down craft after a crash (DShot required) |
| 36 | BOXPREARM | When arming, wait for this switch to be activated before actually arming |
| 37 | BEEP GPS SATELLITE COUNT | Use a number of beeps to indicate the number of GPS satellites found |
| 39 | VTX PIT MODE | Switch the VTX into pit mode (low output power, if supported) |
| 40 | USER1 | User defined switch 1. Intended to be used to control an arbitrary output with PINIO |
| 41 | USER2 | User defined switch 2. Intended to be used to control an arbitrary output with PINIO |
| 42 | USER3 | User defined switch 3. Intended to be used to control an arbitrary output with PINIO |
| 43 | USER4 | User defined switch 4. Intended to be used to control an arbitrary output with PINIO |
| 44 | PID AUDIO | Enable output of PID controller state as audio |
| 45 | PARALYZE | Permanently disable a crashed craft until it is power cycled |
| 46 | GPS RESCUE | Enable 'GPS Rescue' to return the craft to the location where it was last armed |
| 47 | ACRO TRAINER | Enable 'acro trainer' angle limiting in acro mode |
| 48 | DISABLE VTX CONTROL | Disable the control of VTX settings through the OSD |
| 49 | LAUNCH CONTROL | Race start assistance system |
## Auto-leveled flight
The default flight mode does not stabilize the multicopter around the roll and the pitch axes. That is, the multicopter does not level on its own if you center the pitch and roll sticks on the radio. Rather, they work just like the yaw axis: the rate of rotation of each axis is controlled directly by the related stick on the radio, and by leaving them centered the flight controller will just try to keep the multicopter in whatever orientation it's in. This default mode is called "Rate" mode, also sometime called "Acro" (from "acrobatic") or "Manual" mode, and is active whenever no auto-leveled mode is enabled.
If your flight controller is equipped with a 3 axis accelerometer (very likely), then you can enable one of the two available auto leveled flight modes.
## Mode details
### Angle
In this auto-leveled mode the roll and pitch channels control the angle between the relevant axis and the vertical, achieving leveled flight just by leaving the sticks centered.
### Horizon
This hybrid mode works exactly like the previous ANGLE mode with centered roll and pitch sticks (thus enabling auto-leveled flight), then gradually behaves more and more like the default RATE mode as the sticks are moved away from the center position.
### Headfree
In this mode, the "head" of the multicopter is always pointing to the same direction as when the feature was activated. This means that when the multicopter rotates around the Z axis (yaw), the controls will always respond according the same "head" direction.
With this mode it is easier to control the multicopter, even fly it with the physical head towards you since the controls always respond the same. This is a friendly mode to new users of multicopters and can prevent losing the control when you don't know the head direction.
### Airmode
In the standard mixer / mode, when the roll, pitch and yaw gets calculated and saturates a motor, all motors will be reduced equally. When a motor goes below minimum it gets clipped off. Say you had your throttle just above minimum and tried to pull a quick roll - since two motors can't go any lower, you essentially get half the power (half of your PID gain). If your inputs would have asked for more than a 100% difference between the high and low motors, the low motors would get clipped, breaking the symmetry of the motor balance by unevenly reducing the gain.
Airmode will enable full PID correction during zero throttle and give you ability for nice zero throttle gliding and acrobatics. In addition, the cornering / turns will be much tighter now as there is always maximum possible correction performed.
Airmode can also be enabled to work at all times by always putting it on the same switch such as your arm switch, alternatively you can enable/disable it in air.
Additional points and benefits:
* Airmode will additionally fully enable Iterm at zero throttle. Note that there is still some protection on the ground when throttle zeroed (below min\check) and roll/pitch sticks centered. This is a basic protection to limit motors spooling up on the ground.
* Also the Iterm will be reset above 70% of stick input in acro mode to prevent quick Iterm windups during finishes of rolls and flips, which will provide much cleaner and more natural stops of flips and rolls what again opens the ability to have higher I gains for some. Note that AIRMODE will also overrule motor stop function! It will basically also act as an idle up switch.
## Auxiliary Configuration
Spare auxiliary receiver channels can be used to enable/disable modes. Some modes can only be enabled this way.
Configure your transmitter so that switches or dials (potentiometers) send channel data on channels 5 and upwards (the first 4 channels are usually occupied by the throttle, aileron, rudder, and elevator channels).
_e.g. You can configure a 3 position switch to send 1000 when the switch is low, 1500 when the switch is in the middle and 2000 when the switch is high._
Configure your tx/rx channel limits to use values between 1000 and 2000. The range used by mode ranges is fixed to 900 to 2100.
When a channel is within a specified range the corresponding mode is enabled.
Use the GUI configuration tool to allow easy configuration when channel.
### CLI
There is a CLI command, `aux` that allows auxiliary configuration. It takes 5 arguments as follows:
* AUX range slot number (0 - 39)
* mode id (see mode list above)
* AUX channel index (AUX1 = 0, AUX2 = 1,... etc)
* low position, from 900 to 2100. Should be a multiple of 25.
* high position, from 900 to 2100. Should be a multiple of 25.
If the low and high position are the same then the values are ignored.
e.g.
Configure AUX range slot 0 to enable ARM when AUX1 is within 1700 and 2100.
```
aux 0 0 0 1700 2100
```
You can display the AUX configuration by using the `aux` command with no arguments.

86
docs/OSD Profiles.md
View file

@ -1,86 +0,0 @@
# OSD Profiles
An OSD Profile is a screen or page of OSD elements. Three OSD Profiles are supported, i.e. you can configure 3 different OSD Profiles or pages each with their own OSD elements. Elements may also be on all 3 profiles. The OSD can still be turned on or off as before via an AUX channel. Hence users who don't want this feature are not affected by its availability. With no profiles are configured for elements, all elements are visible, i.e. OSD Profile 1 is the default profile. Keep in mind that if an element is used, it must be in the same position on all OSD Profiles in which it is visible. It is not possible to configure an element to be in a different location on a different profile.
## Configuration
Currently (Configurator 10.4.0) OSD Profiles can only be configured via the CLI. Layout your OSD using the configurator and save. Elements in the same position but on different profiles will overlap in the configurator at this stage. OSD Profiles can either be selected via an adjustment range (Adjustments tab, after enabling Expert Mode) or by setting the osd_profile parameter with the set command in the CLI. The selected OSD Profile can either be controlled from a switch on your radio or you can configure different profiles and select the one you want by using the ```set osd_profile=2``` command in the CLI and saving.
###### OSD Configuration
1. Configure your OSD via the OSD tab in the configurator, i.e. element layout, font etc. as before.
###### OPTION 1: Configure an adjustment range to change OSD Profile from your radio
1. Turn on Expert mode - see top right of configurator screen "Enable Expert Mode".
2. The OSD Profile selection is performed using an adjustment configured via the Adjustments tab.
- Enable an adjustment. ("If enabled")
- Select the AUX channel to be used to change OSD Profile. ("when channel")
- Set the range to cover the entire range of the selected AUX channel. ("is in ranges")
- For the action select "RC Rate Adjustment". ("then apply") This will be configured in the CLI since OSD Profiles is not supported by Configurator 10.4.0 and earlier. "RC Rate Adjustment" is only selected to make the configuration in the CLI a little easier below.
- Select the "via channel" to match the selected AUX channel of above. ("when channel").
- Save
3. Open the CLI and type ```adjrange``` followed by enter.
4. Copy the adjrange configured in step 2. above and paste it in the command window. Change the '1' following the range of the channel to '29' and press enter. Type ```save``` and press enter. The configured adjrange will now be saved and the FC will reboot.
5. Configure the AUX channel on your radio. When this channel is changed the selected OSD Profile will change displaying all the elements configured for the selected profile. Note that elements are assigned to profile 1 by default. To revert back to not using OSD Profiles, go to the CLI and select and type ```set osd_profile=1``` press enter, followed by ```save``` and enter. Keep in mind that elements configured to be only visible on profile 2 and 3 will need to reconfigured and will not be visible on profile 1.
###### OPTION 2: Use the CLI to select an OSD Profile (i.e. not selecting the OSD Profile with your radio)
1. Open the CLI.
2. Type ```get osd_profile``` followed by enter to display the currently selected profile.
3. Type ```set osd_profile=x``` where x is the profile number 1,2 or 3 and press enter.
4. Type ```save``` followed by enter to save the selected profile.
###### CONFIGURE OSD PROFILES
The steps below are only required if using The Configurator 10.4.0 or earlier.
1. Open the CLI.
2. Find the name of the element to be configured, all elements can be displayed using the ```dump``` command or ```get osd``` command. Element names end in _pos.
3. Take the current value of the element, apply the OSD Profile config and set its new value using the ```set``` command. The OSD Profile config value is described below.
eg. osd_vbat_pos = 6560
```set osd_vbat_pos = 31136```
```save```
4. Repeat steps 2 & 3 for every element to be configured.
###### OSD PROFILE CONFIG VALUES
The OSD Profile config is stored in the higher order bits, bits 11, 12 & 13 of an OSD element, eg. osd_vbat_pos. This means the initial value, after being configured in the OSD tab needs to be adjusted to add the OSD Profile configuration of the element. To calculate the new value, take the current (initially configured value) of the OSD element and convert it to HEX. Determine which OSD Profiles this element should be visible on and select the corresponding HEX value from the table below. Perform an OR operation between the initial OSD element value (in HEX) and the HEX value from the table. Convert the result to decimal and set the OSD element to this value using the ```set``` command in the CLI.
Binary Value HEX Value Profile Configuration Description
13 12 11
0 0 1 0x0800 - 1 Visible in OSD Profile 1
0 1 0 0x1000 - 2 Visible in OSD Profile 2
0 1 1 0x1800 - 1 and 2 Visible in OSD Profile 1 and 2 only
1 0 0 0x2000 - 3 Visible in OSD Profile 3 only
1 0 1 0x2800 - 1 and 3 Visible in OSD Profile 1 and 3 only
1 1 0 0x3000 - 2 and 3 Visible in OSD Profile 2 and 3 only
1 1 1 0x3800 - 1, 2 and 3 Visible in all OSD Profiles
Example:
1. osd_vbat_pos = 6560
2. Convert 6560 to HEX results in 19A0 (HEX) (All these operations can be done with the windows calculator in programmer mode)
3. We want this element to be visible on OSD Profile 2 & 3 and hence select the HEX value 0x3000 from the table above.
4. OR the two HEX values together 19A0 OR 3000 = 39A0
5. Convert 39A0 (HEX) to decimal results in 14752.
5. In the CLI, ```set osd_vbat_pos = 14752``` enter and ```save``` enter.
## Note:
1. If using Configurator 10.4.0 or earlier, when changing an adjustment on the Adjustments tab, the "then apply" item (29) for OSD Profile will also be cleared, i.e. set to 0 and would have to be re-configured via the CLI, e.g. ```adjrange 0 0 8 900 2100 29 8 0 0```
2. OSD Profile selection is not active if the CLI is open, in other words if you change the value of osd_profile while the CLI is open, nothing will change, the selected OSD Profile will remain as is.
## Use
After completing the above configuration, you should be able to select the active OSD Profile from your radio or via the CLI. The profile can be selected/changed at any time while on the ground or in mid flight.
## Useful OSD Profile CLI commands
```get osd_profile {enter}``` >> displays the currently selected OSD Profile in the CLI.
```set osd_profile= {number, 1-3}``` selects the OSD Profile.

54
docs/Oneshot.md
View file

@ -1,54 +0,0 @@
# Oneshot
Oneshot allows faster communication between the Flight Controller and the ESCs that are present on your multirotor.
It does this in two ways:
1. Use a signal that varies between 125 µs and 250 µs (instead of the normal PWM timing of 1000µs to 2000µs)
1. Only send a 'shot' once per flight controller loop, and do this as soon as the flight controller has calculated the required speed of the motors.
## Supported ESCs
FlyDuino KISS ESCs are able to use the Oneshot125 protocol out of the box. There is only one soldering needed.
BLHeli rev13.0 also supports Oneshot125 and will be automatically selected by the ESC without additional work.
## Supported Boards
The Naze boards are supported, and have been flight tested in a number of configurations.
CC3D boards have been tested with a PPM receiver, however parallel PWM receivers might not work properly with this board.
## Enabling Oneshot
To configure Oneshot, you must turn off any power to your ESCs.
It is a good idea at this stage to configure your ESC for oneshot mode (by soldering JP1 in the case of the KISS ESC).
Connect a USB cable to your board, and connect using the Chrome GUI app.
Go to the CLI tab, and type the following:
feature ONESHOT125
save
Then you can safely power up your ESCs again.
## Configuration
The process for calibrating oneshot ESCs is the same as any other ESC.
1. Ensure that your ESCs are not powered up.
1. Connect to the board using a USB cable, and change to the motor test page.
1. Set the motor speed to maximum using the main slider.
1. Connect power to your ESCs. They will beep.
1. Click on the slider to bring the motor speed down to zero. The ESCs will beep again, usually a couple of times.
1. Disconnect the power from your ESCs.
1. Re-connect power to your ESCs, and verify that moving the motor slider makes your motors spin up normally.
## References
* FlyDuino (<a href="http://flyduino.net/">http://flyduino.net/</a>)

110
docs/PID tuning.md
View file

@ -1,110 +0,0 @@
# PID tuning
Every aspect of flight dynamics is controlled by the selected "PID controller". This is an algorithm which is responsible for reacting to your stick inputs and keeping the craft stable in the air by using the gyroscopes and/or accelerometers (depending on your flight mode).
The "PIDs" are a set of tuning parameters that control the operation of the PID controller. The optimal PID settings are different on every craft, so if you can't find someone with your exact setup who will share their settings with you, some trial and error is required to find the best performing PID settings.
A video on how to recognise and correct different flight problems caused by PID settings is [available here](https://www.youtube.com/watch?v=YNzqTGEl2xQ).
Basically, the goal of the PID controller is to bring the craft's rotation rate in all three axes to the rate that you're commanding with your sticks. An error is computed, which is the difference between your target rotation rate and the actual one measured by the gyroscopes, and the controller tries to bring this error to zero.
## PIDs
**The P term** controls the strength of the correction that is applied to bring the craft toward the target angle or rotation rate. If the P term is too low, the craft will be difficult to control as it won't respond quickly enough to keep itself stable. If it is set too high, the craft will rapidly oscillate/shake as it continually overshoots its target.
**The I term** corrects small, long term errors. If it is set too low, the craft's attitude will slowly drift. If it is set too high, the craft will oscillate (but with slower oscillations than with P being set too high).
**The D term** attempts to increase system stability by monitoring the rate of change in the error. If the error is rapidly converging to zero, the D term causes the strength of the correction to be backed off in order to avoid overshooting the target.
## TPA and TPA Breakpoint
*TPA* stands for Throttle PID Attenuation and according to [AlexYork.net](http://blog.alexyorke.net/what-is-tpa/):
> "TPA basically allows an aggressively tuned multi-rotor (one that feels very locked in) to reduce its PID gains when throttle is applied beyond the TPA threshold/breakpoint in order to eliminate fast oscillations.."
Note that TPA is set via CLI or on the PID TUNING tab of the GUI. `tpa_breakpoint` is set via CLI
Also, note that TPA and `tpa_breakpoint` may not be used with certain PID controllers. Check the description on the individual controller.
TPA applies a PID value reduction in relation to full throttle. It is used to apply dampening of PID values as full throttle is reached.
**TPA** = % of dampening that will occur at full throttle.
**tpa_breakpoint** = the point in the throttle curve at which TPA will begin to be applied.
An Example: With TPA = 50 (or .5 in the GUI) and `tpa_breakpoint` = 1500 (assumed throttle range 1000 - 2000)
* At 1500 on the throttle channel, the PIDs will begin to be dampened.
* At 3/4 throttle (1750), PIDs are reduced by approximately 25% (half way between 1500 and 2000 the dampening will be 50% of the total TPA value of 50% in this example)
* At full throttle (2000) the full amount of dampening set in TPA is applied. (50% reduction in this example)
* TPA can lead into increase of rotation rate when more throttle applied. You can get faster flips and rolls when more throttle applied due to coupling of PID's and rates. Only the PID controllers MWREWRITE and LUX are using a linear TPA implementation, where no rotation rates are affected when TPA is being used.
![tpa example chart](https://user-images.githubusercontent.com/15355893/165317342-9639a7f8-1a05-4584-9b80-3faa2da565cb.png "TPA Example Chart")
**How and Why to use this?**
If you are getting oscillations starting at say 3/4 throttle, set `tpa_breakpoint` = 1750 or lower (remember, this is assuming your throttle range is 1000-2000), and then slowly increase TPA until your oscillations are gone. Usually, you will want `tpa_breakpoint` to start a little sooner than when your oscillations start so you'll want to experiment with the values to reduce/remove the oscillations.
## PID controllers
Cleanflight 1.x had experimental pid controllers, for cleanflight 2.0 there is only one.
### PID controller "LUXFloat"
This is a new floating point based PID controller. MW23 and MWREWRITE use integer arithmetic, which was faster in the days of the slower 8-bit MultiWii controllers, but is less precise.
This controller has code that attempts to compensate for variations in the looptime, which should mean that the PIDs don't have to be retuned when the looptime setting changes.
It is the first PID Controller designed for 32-bit processors and not derived from MultiWii.
The strength of the auto-leveling correction applied during *Angle* mode is controlled by the LEVEL "P" PID term which is labeled "Angle", "Strength" in the GUI (prior to version v1.13.0 the parameter `level_angle` was used). This can be used to tune the auto-leveling strength in *Angle* mode compared to *Horizon* mode. The default is 50.
The strength of the auto-leveling correction applied during *Horizon* mode is set by the LEVEL "I" PID term which is labeled "Horizon", "Strength" in the GUI (prior to version v1.13.0 the parameter `level_horizon` was used). The default is also 50.
The transition between self-leveling and acro behavior in *Horizon* mode is controlled by the LEVEL "D" term which is labeled "Horizon", "Transition" in the GUI (prior to version of v1.13.0 the parameter `sensitivity_horizon` parameter was used) . This sets the percentage of your stick travel that should have self-leveling applied to it, so smaller values cause more of the stick area to fly using only the gyros.
For example, at a setting of "100" for sensitivity horizon, 100% self-leveling strength will be applied at center stick, 50% self-leveling will be applied at 50% stick, and no self-leveling will be applied at 100% stick. If sensitivity is decreased to 75, 100% self-leveling will be applied at center stick, 50% will be applied at 63% stick, and no self-leveling will be applied at 75% stick and onwards.
See below for descriptions of the Horizon Mode Commands.
## RC rate, Pitch and Roll Rates (P/R rate before they were separated), and Yaw rate
### RC Rate
An overall multiplier on the RC stick inputs for pitch, roll, and yaw.
This basically sets the baseline stick sensitivity.
### Pitch and Roll rates
This is an multiplier on overall stick sensitivity, like RC rate, but for roll and pitch independently. Stablility (to outside factors like turbulence) is not reduced at stick extremes. A zero value is no increase in stick sensitivity over that set by RC rate above. Higher values increases stick sensitivity across the entire stick movement range.
### Yaw Rate
It acts as a stick sensitivity multiplier, as explained above.
### Filters
`gyro_lpf` sets the hardware gyro low pass filter value. If 0 or 256 the gyro uses the least hardware filtering available (256Hz) and the internal sampling rate is the fastest possible (8kHz) with the least possible delay. The lower the number the stronger the filtering. Stronger filtering reduces noise in the gyro signal before that data gets into the PID calculations. Stronger filtering adds delays that can be associated with wobble and reduced responsiveness. Filtering is needed because motor/frame noise can cause overheating of motors especially when amplified by Dterm in quads with low mass and fast braking ESCs. If 188 or lower are chosen, the gyro sampling is internally at 1kHz and delays are greater. Faster sampling is good because things are slightly more responsive but can cause aliasing noise. Setting to 188 allows syncing of the FC to the gyro at 1kHz (if `gyro_sync` is enabled and available in the code) which reduces aliasing a lot.
`gyro_soft_lpf` is an IIR (Infinite Impulse Response) software low-pass filter that can be configured to any desired frequency. If set to a value above zero it is active. It works after the hardware filter on the gyro (in the FC code) and further reduces noise. The two filters in series have twice the cut rate of one alone. There's not a lot of sense running `gyro_soft_lpf` at a value above `gyro_lpf`. If used, it is typically set about half the hardware filter rate to enhance the cut of higher frequencies before the PID calculations. Frequencies above 100Hz are of no interest to us from a flight control perspective - they can and should be removed from the signal before it gets to the PID calculation stage.
`dterm_cut_hz` is an IIR software low-pass filter that can be configured to any desired frequency. It works after the gyro_cut filters and specifically filters only the D term data. D term data is frequency dependent, the higher the frequency, the greater the computed D term value. This filter is required if despite the gyro filtering there remains excessive D term noise. Typically it needs to be set quite low because D term noise is a major problem with typical IIR filters. If set too low the phase shift in D term reduces the effectiveness of D term in controlling stop wobble, so this value needs some care when varying it. Again blackbox recording is needed to properly optimise the value for this filter.
### Horizon Mode Commands
The CLI commands `horizon_tilt_effect` and `horizon_tilt_mode` control the effect the current inclination has on self-leveling in the Horizon flight mode. (The current inclination is the number of degrees of pitch or roll that the vehicle is away from level, whichever is greater).
`horizon_tilt_effect`: Controls the effect the current inclination (tilt) has on self-leveling in the Horizon flight mode. Larger values result in less self-leveling (more "acro") as the tilt of the vehicle increases. The default value of 75 provides good performance when doing large loops and fast-forward flight. With a value of 0 the strength of the self-leveling would be solely dependent on the stick position.
`horizon_tilt_mode` SAFE|EXPERT: Sets the performance mode for 'horizon_tilt_effect'
SAFE = leveling always active when sticks centered:
This is the "safer" range because the self-leveling is always active when the sticks are centered. So, when the vehicle is upside down (180 degrees) and the sticks are then centered, the vehicle will immediately be self-leveled to upright and flat. (Note that after this kind of very-fast 180-degree self-leveling, the heading of the vehicle can be unpredictable.)
EXPERT = leveling can be totally off when inverted:
In this range, the inclination (tilt) of the vehicle can fully "override" the self-leveling. In this mode, when the 'horizon_tilt_effect' parameter is set to around 75, and the vehicle is upside down (180 degrees) and the sticks are then centered, the vehicle is not self-leveled. This can be desirable for performing more-acrobatic maneuvers and potentially for 3D-mode flying.
The 'horizon_tilt_effect' and 'horizon_tilt_mode' values are separate for each profile.

245
docs/Profiles.md
View file

@ -1,245 +0,0 @@
# Profiles (aka PID Profiles)
A Profile is a set of performance-related configuration settings. PID values, Filter settings, Anti Gravity, Crash Recovery, and more. Currently, 3 Profiles are supported. The default Profile is profile 1 (`profile 0` in CLI).
Profiles offer another way to perform PID or Filter tuning (currently only Dterm filters). Say that Profile 1 can have default settings you can trust to get in the air and not damage your motors. But you want to try Dterm Bi-quad over PT1, increase P or decrease D values without sacrificing your day of flying. Profiles are perfect for this, edit any Profile when you're at the bench and select the profile when you're in the field. Quad not flying perfectly, merely change your profile back and continue flying.
## Changing profiles
Profiles can be selected using the GUI, CLI, OSD or stick combinations. Once selected, changes to settings can be made and saved to the active Profile. Also worth mentioning when selecting a Profile, that Profile will remain the active Profile even over power cycles.
Betaflight Configurator (GUI): In the PID Tuning Tab > Select a Profile using the drop-down menu. Once a profile is chosen, that profile is activated for current use. Any modifications made are saved when pressing Save button.
OSD: Access CMS (Left Yaw + Pitch up) > Select `Profiles` > Change `PID Prof`.
Stick combinations: When disarmed use the following stick commands to select a Profile. The status LED on your FC will flicker when changing the Profile.
| Profile | Throttle | Yaw | Pitch | Roll |
| ------- | -------- | ----- | ------ | ------ |
| 0 | Down | Left | Middle | Left |
| 1 | Down | Left | Up | Middle |
| 2 | Down | Left | Middle | Right |
CLI: the `profile` command can be used to change the profile:
```
profile <index>
```
To save configuration changes:
```
save
```
# Rate Profiles
A Rate Profile is a set of Rate related settings. These profiles store the settings for Rate Type, RC Rate, Super Rate, Expo for Pitch, Roll, & Yaw. Along with Throttle Expo and TPA settings.
Pre-BetaFlight 3.2 Profiles and Rate Profiles are coupled together. Each Profile had its own set of 3 Rate Profiles. Allowing up to 9 Rate Profiles all together.
Betaflight 3.2 broke this link, giving us independent Profiles and Rate Profiles. Selecting Rate Profiles are independent of Profiles now. Allowing only 3 Rate Profiles.
BetaFlight 3.3 > the number of Rate Profiles increased from 3 to 6 Rate Profiles.
## Changing Rate Profiles
Rate Profiles can be selected using a GUI, CLI, OSD, or AUX channel. Once selected (just like Profiles), changes to settings can be made and saved to the active Rate Profile. Also, when changing our Rate Profile that profile will remain the active Profile even over power cycles, except when using the AUX channel option. When BetaFlight boots the active profile is selected by the position of the AUX channel.
Betaflight Configurator (GUI): Click PID Tuning Tab > Select a Rate Profile using the drop-down menu. Once selected, any changes you make to your settings and click Save will be store to the selected Rate Profile. The action of selecting a Rate Profile also activates that rate profile for current use.
OSD: Access CMS (Left Yaw + Pitch up) > Select `Profiles` > Change `Rate Prof`. Make sure to Save + Exit or Save + Reboot to save settings.
Aux Channel (In-flight Adjustments): Adjustments need to be configured first using the GUI. You must have an available AUX channel configured on your radio.
Enable Expert Mode in the Configurator > Click Adjustments
Click the slider for If enable. Select the AUX # channel to use.
For the Range, Select the whole Range from 900 to 2100. Select Rate Profile Selection from the drop-down menu. Via Channel is the same as the AUX channel used.
CLI: the `rateprofile` command can be used to change the profile:
```
rateprofile <index>
```
To save configuration changes:
```
save
```
# Backing up Profiles and Rate Profiles
Currently creating a backup from the GUI only backs up the active Profile and Rate Profile. So the best way to see and backup all Profiles is to use CLI.
## Using Diff and Dump to output only Profiles
Use these commands to view and back up the complete active profiles (including default settings): `dump profile`, & `dump rates`
In order to see all Profiles configured add the `all` variable: `dump all`, & `diff all`
Use these commands to view and back up the changes the active profiles -defaults settings: `diff profile`, & `diff rates`
Examples:
```
# diff rates
# rateprofile
rateprofile 0
set roll_rc_rate = 200
set pitch_rc_rate = 200
set yaw_rc_rate = 200
set roll_expo = 50
set pitch_expo = 50
set yaw_expo = 90
# dump rates
# rateprofile
rateprofile 0
set thr_mid = 50
set thr_expo = 0
set rates_type = BETAFLIGHT
set roll_rc_rate = 200
set pitch_rc_rate = 200
set yaw_rc_rate = 200
set roll_expo = 50
set pitch_expo = 50
set yaw_expo = 90
set roll_srate = 70
set pitch_srate = 70
set yaw_srate = 70
set tpa_rate = 10
set tpa_breakpoint = 1650
set throttle_limit_type = OFF
set throttle_limit_percent = 100
# diff profile
# profile
profile 0
set p_pitch = 40
set d_pitch = 26
set p_roll = 20
set d_roll = 13
set p_yaw = 80
# dump profile
# profile
profile 0
set dterm_lowpass_type = PT1
set dterm_lowpass_hz = 100
set dterm_lowpass2_hz = 200
set dterm_notch_hz = 0
set dterm_notch_cutoff = 160
set vbat_pid_gain = OFF
set pid_at_min_throttle = ON
set anti_gravity_mode = SMOOTH
set anti_gravity_threshold = 250
set anti_gravity_gain = 5000
set feedforward_transition = 0
set acc_limit_yaw = 100
set acc_limit = 0
set crash_dthreshold = 50
set crash_gthreshold = 400
set crash_setpoint_threshold = 350
set crash_time = 500
set crash_delay = 0
set crash_recovery_angle = 10
set crash_recovery_rate = 100
set crash_limit_yaw = 200
set crash_recovery = OFF
set iterm_rotation = ON
set smart_feedforward = OFF
set iterm_relax = OFF
set iterm_relax_type = GYRO
set iterm_relax_cutoff = 11
set iterm_windup = 40
set iterm_limit = 150
set pidsum_limit = 500
set pidsum_limit_yaw = 400
set yaw_lowpass_hz = 0
set throttle_boost = 5
set throttle_boost_cutoff = 15
set acro_trainer_angle_limit = 20
set acro_trainer_lookahead_ms = 50
set acro_trainer_debug_axis = ROLL
set acro_trainer_gain = 75
set p_pitch = 40
set i_pitch = 50
set d_pitch = 26
set f_pitch = 60
set p_roll = 20
set i_roll = 45
set d_roll = 13
set f_roll = 60
set p_yaw = 80
set i_yaw = 45
set d_yaw = 0
set f_yaw = 60
set p_level = 50
set i_level = 50
set d_level = 75
set level_limit = 55
set horizon_tilt_effect = 75
set horizon_tilt_expert_mode = OFF
set abs_control_gain = 0
set abs_control_limit = 90
set abs_control_error_limit = 20
```
```
# profile
profile 0
set dterm_lowpass_hz = 0
set dterm_lowpass2_hz = 0
set dterm_notch_cutoff = 0
set p_pitch = 40
set d_pitch = 26
set p_roll = 20
set d_roll = 13
set p_yaw = 80
# profile
profile 1
set dterm_lowpass_type = BIQUAD
set dterm_notch_cutoff = 0
# profile
profile 2
set dterm_notch_cutoff = 0
# restore original profile selection
profile 2
# rateprofile
rateprofile 0
set roll_rc_rate = 200
set pitch_rc_rate = 200
set yaw_rc_rate = 200
set roll_expo = 50
set pitch_expo = 50
set yaw_expo = 90
# rateprofile
rateprofile 1
# rateprofile
rateprofile 2
# rateprofile
rateprofile 3
set thr_expo = 25
set roll_rc_rate = 155
set tpa_breakpoint = 1500
# rateprofile
rateprofile 4
# rateprofile
rateprofile 5
# restore original rateprofile selection
rateprofile 3
```

65
docs/Release Notes/Betaflight 3.4 Release Notes.md
View file

@ -1,65 +0,0 @@
# Betaflight 3.4 Release Notes
**Version 3.4.0: The best Betaflight ever!**
We recognise that most of our users just want to two things with new firmware: Install it, and then go fly it. That's why we have spent a lot of time on working out default settings that fly great on most quads. Just install it and try for yourself! To make your craft fly even better, we've added a brand-new, experimental mode to improve the response to stick input by filtering it instead of interpolating. For more info on setting up 3.4 to optimise flight performance, read [these notes](https://github.com/betaflight/betaflight/wiki/Tuning-Tips-for-Betaflight-3.4).
We've also put a lot of effort into optimising the performance of the firmware, especially for boards with an F7 MCU. Now you can go and buy that shiny new F7 board, while your friends still struggle with their boards with F3 and F4. :wink:
For pilots who are into long range flying, we have added the brand new ['GPS Rescue' mode](https://github.com/betaflight/betaflight/wiki/GPS-rescue-mode). It is a simplified version of the 'return to home' mode that exists in other, more navigation oriented firmware, and the great news is that all it needs to work is a GPS, no fiddling to make a compass work required!
Last but not least, we've also added a bunch of new features to improve the convenience of using Betaflight: You can now copy / paste your logs from an SD card or the on board flash chip by [mounting the flight controller as a storage device](https://github.com/betaflight/betaflight/wiki/Mass-Storage-Device-(MSC)-Support), and you can use your flight controller / TX to [emulate a joystick](https://github.com/betaflight/betaflight/wiki/HID-Joystick-Support) with no extra hardware needed, in order to fly on a simulator.
If you are upgrading from an earlier version of Betaflight, please read the following section containing a list of things that you might have to change in your configuration.
We have tried to make this release as bug free as possible. If you still find a **bug**, please report it back to us by opening an **issue [here](https://github.com/betaflight/betaflight/issues)**.
Happy Props!
## Important information when upgrading
- A number of changes and improvements in this release require changes to the Betaflight configurator. These changes have been added to Betaflight configurator 10.3.1 (installation instructions [here](https://github.com/betaflight/betaflight-configurator#installation)). Please update your Betaflight configurator to version 10.3.1. If you are using the Blackbox Log Viewer, there is an updated version 3.1.0 to go with Betaflight 3.4 (installation instructions [here](https://github.com/betaflight/blackbox-log-viewer#installation));
- as part of the overhaul of the various filter stages, and improvements to the PID loop, the default settings have been re-evaluated and updated. The new default values are designed to make optimal use of the new filtering and improved PID loop, and be flyable with (almost) any hardware. Even if your current set up is working ok, it is probably worthwhile to try and only restore the non-filtering / PID loop settings, and have a go with the new default values (store your old `diff` in a safe place, just in case you don't like the new values :wink:). ([#6036](https://github.com/betaflight/betaflight/pull/6036));
- also as part of the filtering overhaul, the names of the debug modes available to log filtering / tuning data have been improved `NOTCH` (gyro data after scaling, before filtering) is now `GYRO_SCALED`, `GYRO` (gyro data after all filtering has been applied) is now `GYRO_FILTERED` ([#6059](https://github.com/betaflight/betaflight/pull/6059));
- the upper limit of `dterm_setpoint_weight` has been increased to 2000 (corresponding to a value of 20 for 'D Setpoint Weight' in Betaflight configurator). This means that pilots wanting a more 'locked in' stick feeling can increase this value beyond the previous maximum of 254. At the same time, an undocumented scaling change was reverted, and the scale is now again how it is described in the Betaflight configurator. If you are using a custom setting for `dterm_setpoint_weight`, divide your value by 1.27 to get the new value that will give you the same feeling as between 3.1.6 and 3.4.0 ([#5945](https://github.com/betaflight/betaflight/pull/5945), [#6052](https://github.com/betaflight/betaflight/pull/6052));
- Dshot beacon configuraton has been changed. Now the `beacon` CLI command can be used analogous to how the `beeper` command is used. This allows for the Dshot beacon to be disabled individually for the conditions that are supported by it (`RX_SET` and `RX_LOST` at the moment). The old way of disabling the Dshot beacon by setting `beeper_dshot_beacon_tone` to `0` is no longer supported. The Dshot beacon is disabled for all conditions by default, if you want to enable it, use `beacon <condition name|ALL>` in CLI ([#5891](https://github.com/betaflight/betaflight/pull/5891), [#6070](https://github.com/betaflight/betaflight/pull/6070));
- in previous versions of the firmware, there was a race condition that could cause Dshot commands (e.g. activation of crash flip) to be ignored by the ESC when the Dshot beacon was active. To prevent this, a timeout has been added to the Dshot beacon that prevents arming for 1.2 seconds after the Dshot beacon was active ([#6079](https://github.com/betaflight/betaflight/pull/6079));
- validation has been added for the RSSI configuration. Unlike in previous versions, it is no longer possible to have multiple sources for RSSI configured simultaneously, since only one can be active at any one time. If you have got more than one of the supported RSSI sources (frame error count / ADC / RX channel) configured, all but the first on this list will be disabled ([#5644](https://github.com/betaflight/betaflight/pull/5644));
- scaling has been added to all RSSI sources. If the RSSI mechanism that you are using does not give you the output range that you want for RSSI, you can now use the `rssi_scale` / `rssi_offset` CLI variables to set the scale and offset for RSSI ([#6001](https://github.com/betaflight/betaflight/pull/6001), [#6032](https://github.com/betaflight/betaflight/pull/6032));
- the functionality of the crash flip mode has been improved: In addition to the existing front / back / left / right spinning of 2 propellers, it now supports spinning only 1 propeller (by moving the roll / pitch stick diagonally), and spinning 2 props that are diagonally opposite (by moving yaw), in order to yaw the overturned craft. The largest stick deflection in any of these directions determines which properllers are spun ([#5163](https://github.com/betaflight/betaflight/pull/5163));
- the setting `moron_threshold` for the acceptable noise limit during gyro calibration was renamed to `gyro_calib_noise_limit`. Additionally, a new setting `gyro_calib_duration` was added. This allows users to configure a longer minimum gyro calibration duration (in 1/10ths of seconds, default: 125). Using a larger setting here will result in reduced gyro drift, which is helpful when flying line of sight ([#5932](https://github.com/betaflight/betaflight/pull/5932));
- unfortunately bugfixes and improvements in the flight controller core functionality have led to an increase of the firmware size, causing it to overflow the available space on a number of F3 based flight controllers. As a result, some features have had to be removed from a number of F3 based flight controllers in order to make the firmware fit into flash. The following targets are affected: BETAFLIGHTF3, COLIBRI\_RACE, FRSKYF3, FURYF3OSD, LUX\_RACE, MIDELICF3, OMNIBUS, RCEXPLORERF3, RG\_SSD\_F3, SPRACINGF3EVO, SPRACINGF3NEO;
- the OSD elements `osd_crosshairs` (crosshairs) and `osd_ah_sbar` (artificial horizon sidebar) have been renamed in CLI to `osd_crosshairs_pos` and `osd_ah_sbar_pos` to make them consistent with the naming of OSD elements. If you are using these elements, please manually change the names in your backup before restoring ([#5534](https://github.com/betaflight/betaflight/pull/5534));
- the range of the `vtx_band` parameter in CLI was extended to start at 0 instead of 1. Setting `vtx_band = 0` allows users of VTX using the SmartPort or Tramp protocols to set the desired frequency directly via the `vtx_freq` parameter. Since direct frequency setting is not supported by the RTC6705 (onboard) VTX driver `vtx_band = 0` does not work for these VTX, and should not be used ([#5465](https://github.com/betaflight/betaflight/pull/5465)).
## Major features:
- Overhauled and improved filtering ([#5391](https://github.com/betaflight/betaflight/pull/5391), [#5458](https://github.com/betaflight/betaflight/pull/5458));
- Optimised and massively improved the performance on F7 ([#5674](https://github.com/betaflight/betaflight/pull/5674));
- Added GPS rescue mode ([#5753](https://github.com/betaflight/betaflight/pull/5753), [#5764](https://github.com/betaflight/betaflight/pull/5764));
- Added support for accessing SD card / onboard flash as USB mass storage device (MSC) ([#5443](https://github.com/betaflight/betaflight/pull/5443), [#5629](https://github.com/betaflight/betaflight/pull/5629), [#5650](https://github.com/betaflight/betaflight/pull/5650));
- Added support for reading RC input as USB joystick (HID) ([#5478](https://github.com/betaflight/betaflight/pull/5478), [#5596](https://github.com/betaflight/betaflight/pull/5596));
- Added support for CMS configuration over CRSF ([#5743](https://github.com/betaflight/betaflight/pull/5743));
- Added support for experimental filter based RC channel smoothing ([#6017](https://github.com/betaflight/betaflight/pull/6017)).
## Minor features:
- Added acro trainer mode ([#5970](https://github.com/betaflight/betaflight/pull/5970));
- Added throttle boost mode ([#5508](https://github.com/betaflight/betaflight/pull/5508));
- Added support for throttle limiting ([#5608](https://github.com/betaflight/betaflight/pull/5608));
- Added PID loop improvements ([#5968](https://github.com/betaflight/betaflight/pull/5968), [#5963](https://github.com/betaflight/betaflight/pull/5963), [#5962](https://github.com/betaflight/betaflight/pull/5962));
- Added support for accelerated [yaw spin recovery](https://github.com/betaflight/betaflight/wiki/Yaw-Spin-Recovery-and-Gyro-Overflow-Detect) ([#5706](https://github.com/betaflight/betaflight/pull/5706));
- Added support for direct adjustment of PID values through an RC channel ([#5584](https://github.com/betaflight/betaflight/pull/5584));
- Added support for multiple overclocking speeds ([#5193](https://github.com/betaflight/betaflight/pull/5193));
- Added MCU temperature monitoring ([#5322](https://github.com/betaflight/betaflight/pull/5322));
- Added paralyse mode ([#5851](https://github.com/betaflight/betaflight/pull/5851));
- Added support for QMC5883L compass ([#5309](https://github.com/betaflight/betaflight/pull/5309));
- Added support for W25M flash chips ([#5722](https://github.com/betaflight/betaflight/pull/5722)).
## New targets:
- Added SPRACINGF7DUAL with dual gyro support ([#5264](https://github.com/betaflight/betaflight/pull/5264)).

35
docs/Release Notes/Betaflight 3.5 Release Notes.md
View file

@ -1,35 +0,0 @@
# Betaflight 3.5 Release Notes
**Wait, there is one more thing we can do to make it better!**
This is what we realised about two months ago, as we were preparing for the release of Betaflight 3.4.0. And this is what led to the 'Feed Forward PID controller' being born. But when we came up with it it was already too late to add it to 3.4.0, and it needed some more refinement before it was ready to go out anyway. So we decided to do Betaflight 3.5.0, a release that focuses on more flight improvements. We put the Feed Forward PID controller into it, we have made the dynamic notch filter a whole lot more awesome, and we made improvements to how anti gravity works. Man, all of these improvements show when you fly it!
To get the best out of the flight performance improvements, please read these [tuning tips](https://github.com/betaflight/betaflight/wiki/3.5-tuning-notes).
If you are upgrading from an earlier version of Betaflight, please read the following section containing a list of things that you might have to change in your configuration.
We have tried to make this release as bug free as possible. If you still find a **bug**, please report it back to us by opening an **issue [here](https://github.com/betaflight/betaflight/issues)**.
We also have a Facebook Group: If you want to talk about Betaflight, ask configuration questions, or just hang out with fellow pilots, you can do this [here](https://www.facebook.com/groups/betaflightgroup/).
Happy Props!
## Important information when upgrading
- A number of changes and improvements in this release require changes to the Betaflight configurator. These changes have been added to [Betaflight configurator 10.4.0](https://github.com/betaflight/betaflight-configurator/releases/tag/10.4.0)(installation instructions [here](https://github.com/betaflight/betaflight-configurator#installation)), please update your Betaflight configurator to at least this version;
- if you are using the Blackbox Log Viewer, there is an updated [version 3.2.0](https://github.com/betaflight/blackbox-log-viewer/releases/tag/3.2.0) to go with Betaflight 3.5 (installation instructions [here](https://github.com/betaflight/blackbox-log-viewer#installation)). Please update to at least version 3.2.0;
- a new 'Feed Forward PID' algorithm has been implemented, replacing setpoint weight ([#6355](https://github.com/betaflight/betaflight/pull/6355)). In addition to this, the dynamic notch filter ([#6411](https://github.com/betaflight/betaflight/pull/6411)) and anti-gravity ([#6220](https://github.com/betaflight/betaflight/pull/6220)) have been optimised for improved flight performance. For all of these changes, default values have been chosen that should result in good flight characteristics for most setups. It is recommended to start testing with default settings, incorporating tuned settings from previous versions if needed, where needed. For more in-depth instructions for tuning Betaflight 3.5, please consult [these notes](https://github.com/betaflight/betaflight/wiki/3.5-tuning-notes).
- unfortunately, bugfixes in the flight controller core functionality have led to an increase of the firmware size, causing it to overflow the available space on a number of F3 based flight controllers. As a result, some features have had to be removed from a number of F3 based flight controllers in order to make the firmware fit into flash. The following targets are affected: CRAZYBEEF3FR, CRAZYBEEF3FS, FRSKYF3, FURYF3, FURYF3OSD, OMNIBUS, SPRACINGF3, SPRACINGF3EVO, SPRACINGF3MINI, SPRACINGF3NEO ([#6497](https://github.com/betaflight/betaflight/pull/6497), [#6501](https://github.com/betaflight/betaflight/pull/6501))
## Major features:
- Added support for feed forward to the PID controller ([#6355](https://github.com/betaflight/betaflight/pull/6355)).
- Improved the performance of the dynamic notch filter ([#6411](https://github.com/betaflight/betaflight/pull/6411)).
## Minor features:
- Improved the performance of anti-gravity ([#6220](https://github.com/betaflight/betaflight/pull/6220));
- Added support for linking of modes ([#6335](https://github.com/betaflight/betaflight/pull/6335));
- Added support for dynamic filter in dual gyro mode ([#6428](https://github.com/betaflight/betaflight/pull/6428)).

69
docs/Release Notes/Betaflight 4.0 Release Notes.md
View file

@ -1,69 +0,0 @@
# Betaflight 4.0 Release Notes
**It took us a long time, but now it’s here, and it’s got so many new things!**
When we released 3.5 in August last year, the number of different targets supported by Betaflight had reached 150, and maintaining them was becoming a major effort and taking up a lot of our time. It became clear that we had to do something. We had been working on changing the architecture of Betaflight to make it possible to use the same firmware for different flight controllers for some time, and so we decided to complete this change before releasing the next version, and that because of this fundamental change the next version would be 4.0.
As we approached the originally set release date for Betaflight 4.0, we realised that we were not quite ready, and we decided to take another three months, in order to be able to complete the work we had started.
So now, here we are, ‘Unified Targets’, as we called the new ‘one firmware for many flight controllers’ technology, is now a reality in Betaflight 4.0. There is still some work left to be done to add support for flashing Unified Targets with their configurations to Betaflight configurator, but once this is done, we will be able to allow manufacturers to make firmware for any number of boards, or RTF products, available directly in configurator.
As you have come to expect from Betaflight, we have picked up a number of new and exciting improvements to the flight performance, like ESC RPM based filtering, D term management with D\_min, and throttle based dynamic gyro and D term filtering.
And, again as expected we have added some more, non flight related new features like launch control, OSD profiles, and support for on-board SPI attached RX.
For an extended list of new features see below.
To get the best out of the flight performance improvements, please read these [tuning tips](https://github.com/betaflight/betaflight/wiki/4.0-Tuning-Notes).
If you are upgrading from an earlier version of Betaflight, please read the following section containing a list of things that you might have to change in your configuration.
We have tried to make this release as bug free as possible. If you still find a **bug**, please report it back to us by opening an **issue [here](https://github.com/betaflight/betaflight/issues)**.
_Kia kaha_ (stay strong)
## Important information when upgrading
- A number of changes and improvements in this release require changes to the Betaflight configurator. These changes have been added to [Betaflight configurator 10.5.1](https://github.com/betaflight/betaflight-configurator/releases/tag/10.5.1) (installation instructions [here](https://github.com/betaflight/betaflight-configurator#installation)), please update your Betaflight configurator to at least this version;
- if you are using the Blackbox Log Viewer, there is an updated [version 3.3.1](https://github.com/betaflight/blackbox-log-viewer/releases/tag/3.3.1) to go with Betaflight 4.0 (installation instructions [here](https://github.com/betaflight/blackbox-log-viewer#installation)). Please update to at least this version;
- if you are using OpenTX and the Betaflight TX Lua scripts, please update them to at least [version 1.2.0](https://github.com/betaflight/betaflight-tx-lua-scripts/releases/tag/1.2.0) in order to get support for the latest features introduced in Betaflight 4.0;
- there are a number of flight performance related improvements in Betaflight 4.0. Therefore, **pasting back-ups of the tuning settings for older versions of Betaflight into Betaflight 4.0 will most likely result in poor flight performance**! The default settings in Betaflight 4.0 should be reasonably well flyable for most hardware configurations, but users wanting to tune the performance of their craft should read the [4.0 Tuning Notes](https://github.com/betaflight/betaflight/wiki/4.0-Tuning-Notes) to learn everything they need to know about tuning Betaflight 4.0 ([#6432](https://github.com/betaflight/betaflight/pull/6432), [#6943](https://github.com/betaflight/betaflight/pull/6943), [#7078](https://github.com/betaflight/betaflight/pull/7078), [#7264](https://github.com/betaflight/betaflight/pull/7264), [#7271](https://github.com/betaflight/betaflight/pull/7271), [#7304](https://github.com/betaflight/betaflight/pull/7304), [#7373](https://github.com/betaflight/betaflight/pull/7373), [#7538](https://github.com/betaflight/betaflight/pull/7538));
- there was a fix to how the `min_check` 'zero throttle' dead zone is applied. Before the fix, there was an additional, undocumented deadband of the same size as the `min_check` range above the `min_check` range. The fix has not brought a change to the arming behaviour and throttle is still required to be below `min_check` for arming to be possible. However the extra unintended throttle deadband above `min_check` has been eliminated. This will result in more responsive throttle near minimum and a slight increase in throttle resolution. If you desire to retain the same range for the 'zero throttle' dead zone, you need to double the amount of dead zone configured in `min_check` (offset from 1000). Be aware that this will also double the throttle range within which the craft can be armed ([#7463](https://github.com/betaflight/betaflight/pull/7463));
- there is a new 'Stick Overlay' OSD element that shows an overlay of the current stick positions. In order to use it, the font loaded onto the OSD needs to be updated to the latest version (available in configurator 10.5.0 or newer) ([#7476](https://github.com/betaflight/betaflight/pull/7476));
- the functionality of the 'crash flip arrow' OSD element was extended to activate as well when the craft is not in crash flip mode, but `small_angle` is set, and the craft is unarmed and tilted more than `small_angle`. This is to show pilots that they won't be able to arm from the current orientation, and allow them to activate crash flip mode and then right their craft ([#7250](https://github.com/betaflight/betaflight/pull/7250));
- As part of the introduction of Unified Targets, the existing `resource` command was complemented with two new commands for resource management: `timer` and `dma`. Just like `resource` can be used to assign pins to functions, `timer` can be used to assign timers to pins, and `dma` can be used to assign DMA streams to subsystems and pins (if they have a timer assigned). **Important:** Since DMA streams are linked to pins through timers, `timer` assignments for pins have to be made first, before `dma` assignments to these pins can be made ([#5824](https://github.com/betaflight/betaflight/pull/5824), [#6837](https://github.com/betaflight/betaflight/pull/6837), [#7620](https://github.com/betaflight/betaflight/pull/7620));
- The syntax for the `resource`, `timer`, and `dma` commands was consolidated, and as part of this the `resource list` subcommand was renamed into `resource show`. This aligns it with the new `dma show` and `timer show` subcommands ([#7712](https://github.com/betaflight/betaflight/pull/7712));
- the following parameters were renamed to more closely match their function: `p_level` => `angle_level_strength`, `i_level` => `horizon_level_strength`, `d_level` => `horizon_transition` ([#6673](https://github.com/betaflight/betaflight/pull/6673));
- the gyro configuration was unified from being done by gyro hardware model to being generic for all gyro models. This means that for some targets that are used for multiple different boards that come with different gyro models _that are mounted with different orientations_, it is necessary from Betaflight 4.0 on to manually set `gyro_1_sensor_align` (and / or `gyro_2_sensor_align` for boards with a second gyro) to match the gyro orientation on the board that is used. See note [#6761](https://github.com/betaflight/betaflight/pull/6761) for an explanation, and instructions for individual boards. This is a temporary workaround, per-board configurations with correct gyro alignment will be released as Unified Target configurations ([#5868](https://github.com/betaflight/betaflight/pull/5868));
- unfortunately, bugfixes in the flight controller core functionality have led to an increase of the firmware size, causing it to overflow the available space on almost all F3 based flight controllers. As a result, features have had to be removed from all but a few of the currently supported F3 based flight controllers. Some of the affected targets are: AIORACERF3, BETAFLIGHTF3, CHEBUZZF3, CRAZYBEEF3FR, FURYF3, FURYF3OSD, IMPULSERCF3, LUX\_RACE, LUXV2\_RACE, MIDELICF3, OMNIBUS, RACEBASE, RMDO, SIRINFPV, SPRACINGF3, SPRACINGF3MINI, SPRACINGF3NEO, STM32F3DISCOVERY ([#6900](https://github.com/betaflight/betaflight/pull/6900), [#6955](https://github.com/betaflight/betaflight/pull/6955), [#7037](https://github.com/betaflight/betaflight/pull/7037), [#7038](https://github.com/betaflight/betaflight/pull/7038), [#7045](https://github.com/betaflight/betaflight/pull/7045), [#7306](https://github.com/betaflight/betaflight/pull/7306), [#7381](https://github.com/betaflight/betaflight/pull/7381), [#7392](https://github.com/betaflight/betaflight/pull/7392), [#7402](https://github.com/betaflight/betaflight/pull/7402), [#7421](https://github.com/betaflight/betaflight/pull/7421), [#7501](https://github.com/betaflight/betaflight/pull/7501), [#7508](https://github.com/betaflight/betaflight/pull/7508), [#7518](https://github.com/betaflight/betaflight/pull/7518), [#7829](https://github.com/betaflight/betaflight/pull/7829), [#7842](https://github.com/betaflight/betaflight/pull/7842));
- in addition to the above point, the following features had to be removed from all F3 based flight controllers in order to make the firmware fit into flash: Smart Feedforward, support for flashing / configuration of SimonK based ESCs ([#7272](https://github.com/betaflight/betaflight/pull/7272), [#7274](https://github.com/betaflight/betaflight/pull/7274), [#7391](https://github.com/betaflight/betaflight/pull/7391));
- support for status display through LED strips was removed from F3 based flight controllers, in order to be able to reclaim some flash space. In its place, [LED Strip Profiles](https://github.com/betaflight/betaflight/blob/master/docs/LedStrip.md#led-strip-profiles) (except for the 'Status' profile which is not supported on F3) can be used to set LED strips to fixed colours. LED strip profiles are also available on F4 / F7, to enable simple configuration of the LED strip in OSD ([#7485](https://github.com/betaflight/betaflight/pull/7485));
- since the above three measures proved to be insufficient to keep flash space from overflowing on F3 based flight controllers, a system of classifying F3 based flight controllers into a number of 'feature cut' levels, and removing features according from them according to their level were introduced. This was used to reduce the number of features built into most F3 based flight controllers even more ([#7429](https://github.com/betaflight/betaflight/pull/7429)).
## Major features:
- real time ESC RPM feedback, and notch filtering based on motor RPM ([#7264](https://github.com/betaflight/betaflight/pull/7264), [#7271](https://github.com/betaflight/betaflight/pull/7271));
- D term management with D\_min ([#7373](https://github.com/betaflight/betaflight/pull/7373), [#7538](https://github.com/betaflight/betaflight/pull/7538));
- throttle based dynamic gyro and D term filtering ([#6943](https://github.com/betaflight/betaflight/pull/6943));
- launch control ([#6992](https://github.com/betaflight/betaflight/pull/6992));
- switchable OSD profiles ([#6714](https://github.com/betaflight/betaflight/pull/6714));
- SPI attached Spektrum RX ([#7210](https://github.com/betaflight/betaflight/pull/7210));
- Unified Targets ([#5824](https://github.com/betaflight/betaflight/pull/5824), [#6837](https://github.com/betaflight/betaflight/pull/6837), [#7620](https://github.com/betaflight/betaflight/pull/7620)).
## Minor features:
- cascaded dynamic notches ([#7078](https://github.com/betaflight/betaflight/pull/7078));
- thrust linearisation ([#7304](https://github.com/betaflight/betaflight/pull/7304));
- integrated yaw control ([#6432](https://github.com/betaflight/betaflight/pull/6432));
- switchable LED\_STRIP profiles ([#7303](https://github.com/betaflight/betaflight/pull/7303));
- stick overlays in OSD ([#7167](https://github.com/betaflight/betaflight/pull/7167));
- profile switching based on battery cell count ([#7516](https://github.com/betaflight/betaflight/pull/7516));
- per profile limiting of maximum motor output ([#7482](https://github.com/betaflight/betaflight/pull/7482));
- support for the Futaba SFHSS protocol on CC2500 (FrSky SPI) hardware ([#6865](https://github.com/betaflight/betaflight/pull/6865));
- EU LBT mode for the FrSky SPI RX ([#7339](https://github.com/betaflight/betaflight/pull/7339));
- support for STM32F765xx based flight controllers ([#6669](https://github.com/betaflight/betaflight/pull/6669)).
- configuration over HoTT telemetry ([#6224](https://github.com/betaflight/betaflight/pull/6224)).

46
docs/Release Notes/Betaflight 4.1 Release Notes.md
View file

@ -1,46 +0,0 @@
# Betaflight 4.1 Release Notes
**We're already late, so let's keep this short!**
As you've come to expect, we've packed this release with a whole lot of new flying goodness, new features, and support for a bunch of new targets.
For an extended list of new features see below.
To make sure you get the latest version of your target installed, head over to [this page](https://github.com/betaflight/betaflight-configurator/releases) and make sure you have got the latest version of Betaflight configurator installed **before updating your firmware**.
To get the best out of the flight performance improvements, please read these [tuning tips](https://github.com/betaflight/betaflight/wiki/4.1-Tuning-Notes).
If you are upgrading from an earlier version of Betaflight, please read the following section containing a list of things that you might have to change in your configuration.
We have tried to make this release as bug free as possible. If you still find a **bug**, please report it back to us by opening an **issue [here](https://github.com/betaflight/betaflight/issues)**.
_Have fun_
## Important information when upgrading
- Betaflight 4.1 brings a fundamental change to how targets are downloaded and installed. The latest release of [Betaflight configurator](https://github.com/betaflight/betaflight-configurator/releases), 10.6.0, contains the changes necessary to support this. For this reason **it is important that you update to the version 10.6.0 or newer of Betaflight Configurator (installation instructions [here](https://github.com/betaflight/betaflight-configurator#installation)) in order to get the latest version of your targets installed**;
- if you are using the [Blackbox Explorer](https://github.com/betaflight/blackbox-log-viewer/releases), there is an updated version 3.4.0 to go with Betaflight 4.1 (installation instructions [here](https://github.com/betaflight/blackbox-log-viewer#installation));
- version 1.4.0 of the [Betaflight TX lua scripts](https://github.com/betaflight/betaflight-tx-lua-scripts/releases) has been released. This includes changes to go with Betaflight 4.1 (installation instructions [here](https://github.com/betaflight/betaflight-tx-lua-scripts#installing));
- bidirectional Dshot, which is the basis for RPM based filtering, has been improved and is now available with BLHeli\_32 (from version 32.7 on) and on BLHeli\_S hardware (by using the JESC firmware). Use [these instructions](https://github.com/betaflight/betaflight/wiki/Bidirectional-DSHOT-and-RPM-Filter) to get it set up ([#8554](https://github.com/betaflight/betaflight/pull/8554), [#8779](https://github.com/betaflight/betaflight/pull/8779));
- as you have come to expect, there is a detailed [Tuning Notes](https://github.com/betaflight/betaflight/wiki/4.1-Tuning-Notes) for Betaflight 4.1. Use them, or use the new tuning sliders in the Betaflight configurator 10.6.0 to get your craft tuned. Please **do not paste tuning configurations from previous versions of the firmware**. Some defaults have been changed, and some parameters are used in different ways, so previous tuning settings will not work well with Betaflight 4.1 ([#8623](https://github.com/betaflight/betaflight/pull/8623), [#8736](https://github.com/betaflight/betaflight/pull/8736));
- with the introduction of fully configurable VTX control (VTX tables), after flashing the firmware you now have to load a VTX tables appropriate for your VTX and for the country you are flying in before you can control your VTX through Betaflight. Support for loading VTX tables from files is integrated into Betaflight configurator from version 10.6.0 on. Please see the documentation in the new 'Video Transmitter' tab for instructions on how to find an appropriate VTX table and install it ([#7251](https://github.com/betaflight/betaflight/pull/7251));
- some optimisations were made to the OSD fonts, and some characters were improved. In order to get a properly working OSD with Betaflight 4.1, the font loaded onto the OSD needs to be updated to the latest version (available in configurator 10.6.0 or newer) ([#8390](https://github.com/betaflight/betaflight/pull/8390));
- as announced before the release of Betaflight 4.0, support for F3 based flight controllers has been removed from Betaflight 4.1.
## Major features:
- new and improved feed forward 2.0 ([#8623](https://github.com/betaflight/betaflight/pull/8623), [#8736](https://github.com/betaflight/betaflight/pull/8736));
- reworked bidirectional Dshot ([#8554](https://github.com/betaflight/betaflight/pull/8554), [#8779](https://github.com/betaflight/betaflight/pull/8779));
- dynamic idle management using RPM telemetry ([#8604](https://github.com/betaflight/betaflight/pull/8604));
- fully configurable VTX control with VTX tables ([#7251](https://github.com/betaflight/betaflight/pull/7251)).
## Minor features:
- support for the Spektrum SRXL2 serial protocol ([#8606](https://github.com/betaflight/betaflight/pull/8606));
- support for board-specific custom defaults ([#8707](https://github.com/betaflight/betaflight/pull/8707));
- support for arbitrary gyro and mag alignment ([#8474](https://github.com/betaflight/betaflight/pull/8474)).

59
docs/Release Notes/Betaflight 4.2 Release Notes.md
View file

@ -1,59 +0,0 @@
# Betaflight 4.2 Release Notes
**Just in time for summer...**
...for most of us, and in time for the end of COVID-19 related lockdowns in a lot of places, we are proud to announce the release of Betaflight 4.2.0!
This is the third release of Betaflight after the switch to our new approach of how we support targets for different boards, and we have put effort into making support for these 'Unified Targets' easier and more seamless than before. We have also managed to convert most of the existing targets to use this new approach. This is enabling us to add support for new targets without additional effort for the developers, and as a result Betaflight is now supporting more different hardware than ever before (currently we are supporting 185 different flight controller models and counting).
As usual, our flight performance wizards have kept busy as well, and have added a bunch of improvements to how Betaflight flies. On top of that, they have improved the defaults, and made the firmware easier to tune than ever before.
One new feature that will be of interest to pilots still forced to stay inside is the new battery sag compensation: This feature results in a more consistent stick feel for the entire duration of the battery. The feedback that we are getting from many of our test pilots is that this is particularly useful for small indoor setups, like whoops or similar. Have a look at the [4.2 Tuning Notes](https://github.com/betaflight/betaflight/wiki/4.2-Tuning-Notes) to find out how to set this up.
Last but not least, we have also reworked how the gyro loop works, and it now runs at a fixed speed that is identical to the native update speed for the model of gyro that is used. This has simplified the setup of loop speeds, and allowed us to add support for a number of new gyro models - hopefully we'll see manufacturers pick this up and start offering exciting new flight controllers with these new gyros.
For an extended list of new features see below.
To make sure you get the latest version of your target installed, head over to [this page](https://github.com/betaflight/betaflight-configurator/releases) and make sure you have got the latest version of Betaflight configurator installed **before updating your firmware**.
To get the best out of the flight performance improvements, please read the [Tuning Notes](https://github.com/betaflight/betaflight/wiki/4.2-Tuning-Notes).
If you are upgrading from an earlier version of Betaflight, please read the following section containing a list of things that you might have to change in your configuration.
We have tried to make this release as bug free as possible. If you still find a **bug**, please report it back to us by opening an **issue [here](https://github.com/betaflight/betaflight/issues)**.
_Happy flying, enjoy summer_
## Important information when upgrading
- Betaflight 4.2 brings some changes to how targets are downloaded and installed. The [latest release](https://github.com/betaflight/betaflight-configurator/releases) of Betaflight Configurator, 10.7.0, contains the changes necessary to support this. For this reason **it is important that you update to the version 10.7.0 or newer of Betaflight Configurator (installation instructions [here](https://github.com/betaflight/betaflight-configurator#installation)) in order to get the latest version of your targets installed**;
- if you are using the [Blackbox Explorer](https://github.com/betaflight/blackbox-log-viewer/releases), there is an updated version 3.5.0 to go with Betaflight 4.2 (installation instructions [here](https://github.com/betaflight/blackbox-log-viewer#installation));
- version 1.5.0 of the [Betaflight TX lua scripts](https://github.com/betaflight/betaflight-tx-lua-scripts/releases) has been released. This includes changes to go with Betaflight 4.2 (installation instructions [here](https://github.com/betaflight/betaflight-tx-lua-scripts#installing));
- as you have come to expect, there is a detailed [Tuning Notes](https://github.com/betaflight/betaflight/wiki/4.2-Tuning-Notes) for Betaflight 4.2. Use them, or use the improved tuning sliders in the Betaflight configurator 10.7.0 to get your craft tuned. Please **do not paste tuning configurations from previous versions of the firmware**. Some defaults have been changed, and some parameters are used in different ways, so previous tuning settings will not work well with Betaflight 4.1 ([#8623](https://github.com/betaflight/betaflight/pull/8623), [#8736](https://github.com/betaflight/betaflight/pull/8736));
- after installing new firmware or resetting the configuration, the motor output protocol selected by default is now 'disabled'. This means that the correct motor protocol has to be selected before the craft can be armed. But this also removed the limitation on the maximum possible PID loop speed imposed by the pre-selected legacy protocol (OneShot125) in earlier versions, resulting in the maximum possible PID loop speed for each MCU type being pre-selected. Arming will be disabled and a warning displayed in configurator until a motor output protocol has been selected ([#9619](https://github.com/betaflight/betaflight/pull/9619));
- when enabling bidirectional Dshot, the maximum possible PID loop speed for Dshot protocols will be reduced by half to accommodate for the time taken by the ESC to send the RPM data packet to the flight controller. This does not affect Dshot600, but if bidirectional Dshot is used with Dshot300, the maximum PID loop speed is 4 kHz, and 2 kHz for Dshot150 ([#9642](https://github.com/betaflight/betaflight/pull/9642));
- the threshold for activation of the yaw spin recovery feature has had an automatic mode added - this mode sets the threshold to a value that is based on the currently configured maximum yaw rate, with a buffer added on top of it. This new mode is the default for yaw spin threshold, since it provides a setting that is safe to use for most users. Manual configuration of the yaw spin threshold is still possible ([#9455](https://github.com/betaflight/betaflight/pull/9455));
- accelerometer calibration is now required before arming is allowed if any feature is enabled that requires the accelerometer. This is to prevent situations arising where the craft may try to self-level with an uncalibrated accelerometer, leading to unexpected or dangerous results. Arming will be disabled and a warning displayed in configurator until the accelerometer has been calibrated ([#9031](https://github.com/betaflight/betaflight/pull/9031));
- the calculation for the virtual current meter device has been changed to be based on the throttle value used in the mixer, instead of the throttle channel RC input. This means that this value has things like throttle limiting and throttle boost applied, resulting in more accurate prediction of current and consumption. If you are using the virtual current meter device, make sure to calibrate it again after updating the firmware to make sure the calibration is still correct ([#9153](https://github.com/betaflight/betaflight/pull/9153));
- the way that the 'RSSI dBm' value is tracked in the firmware has changed to use actual dBM value in a range of -130 to 0, instead of the previous version's 130 to 0 range. This means that if a custom setting for `osd_rssi_dbm_alarm` is used, this will have to be changed to be the inversion of its previous value (e.g. `60` becomes `-60`) ([#9550](https://github.com/betaflight/betaflight/pull/9550));
- since stick arming is not recommended for multirotor craft because it can lead to accidental disarms, it has been disabled by default. If you want to use stick arming (at your own risk), it has to be enabled by setting `enable_stick_arming` to `on` ([#9183](https://github.com/betaflight/betaflight/pull/9183));
- the `name` CLI command has been removed. Use `set name = <name>` instead ([#8837](https://github.com/betaflight/betaflight/pull/8837)).
## Major Features:
- completely reworked the gyro loop, improved performance and made it always run at the native speed of the gyro ([#9444](https://github.com/betaflight/betaflight/pull/9444));
- added new selectable ACTUAL and QUICK rates models ([#9495](https://github.com/betaflight/betaflight/pull/9495), [#9506](https://github.com/betaflight/betaflight/pull/9506));
- added compensation for sagging battery voltage, resulting in more consistent throttle / PID behaviour over for the entire flight time ([#9561](https://github.com/betaflight/betaflight/pull/9561));
- Added level race mode ('NFE race mode' in Silverware) ([#9481](https://github.com/betaflight/betaflight/pull/9481)).
## Minor Features:
- added the option to display the OSD logo on arming ([#9244](https://github.com/betaflight/betaflight/pull/9244));
- added support for enhanced OSD / CMS devices, made it possible to support highligting of text or symbols ([#9212](https://github.com/betaflight/betaflight/pull/9212));
- added support for FrSkyOSD OSD devices ([#9127](https://github.com/betaflight/betaflight/pull/9127));
- added support for the Redpine RC protocol on devices with an SPI connected CC2500 chip (FrSky SPI) ([#7601](https://github.com/betaflight/betaflight/pull/7601)).

188
docs/Release Notes/Betaflight 4.4 Release Notes.md
View file

@ -1,188 +0,0 @@
# Betaflight 4.4 Release Notes
## 1. Cloud build
This is predominantly brought to you for convenience, and to ensure we can keep the 512kb flash targets (STM32F411 and STM32F722) alive and well for years to come. The cloud build system will allow you, the flyer, to select the features you want, and a **custom firmware** will be created for you.
Any issues with the cloud build process please check out the #cloud-build-issues Discord channel. Help us to help you, buy taking advantage of the new `Support` button in the Command Line Interface (CLI) tab in Configurator 10.9.0 (RC4 onwards). This will give us valuable information in trying to diagnose your issue.
**NOTE:** If you have something missing from your cloud build that you would normally expect to be present, e.g. a flash chip or barometer, the reason is because the board configuration (in unified targets) has not been updated with this information (either by the community, or the manufacturer).
If you do have something missing then we suggest flashing the `core` version. This will load all the hardware drivers (but not all features), and then you can submit a `Support` level of detail from the CLI tab. In addition you can use the **custom defines** input box that is shown when "Expert Mode" is enabled.
For those missing a barometer: You can try any or all of `BARO_MS5611 BARO_SPI_MS5611 BARO_BMP280 BARO_SPI_BMP280 BARO_BMP388 BARO_SPI_BMP388 BARO_LPS BARO_SPI_LPS BARO_QMP6988 BARO_SPI_QMP6988 BARO_DPS310 BARO_SPI_DPS310 BARO_BMP085 BARO_2SMBP_02B BARO_SPI_2SMBP_02B` in the **custom defines** input box.
For those missing the flash chip: You can try any or all of `USE_FLASH_W25P16 USE_FLASH_W25Q128FV USE_FLASH_W25M02G USE_FLASH_W25N01G USE_FLASH_W25M` in the custom defines input box.
Thank you all for your patience and assistance in working through what boards have what hardware. Unfortunately we need our flyers to help crowd source this information - as there is such diverse hardware out there!
Thanks to @blckmn for the implementation of the cloud build!
## 2. HD OSD
HD OSD is now supported and adds the following features. Note that not all HD Goggle/VTX combinations support all features, but hopefully will do so in time.
If the `OSD` option alone, or the `OSD (HD)` option is included in the build options, then HD support will be included.
To enable HD support select `VTX (MSP + Displayport)` on the ports tab for the UART to which the VTX is connected. The `MSP` option will automatically be selected.
![image](https://user-images.githubusercontent.com/11480839/212375683-0ac11ca1-9694-451d-a399-db910a72a062.png)
The OSD `HD` preview may be manually selected on the OSD tab along side the `PAL` and `NTSC` options however this is not necessary as the first time the HD Goggle/VTX system is powered the FC detects it and automatically applies the following settings, saves and reboots automatically. This only happens if the setting below are not already applied. This is a new feature, and may not be supported by the your HD system yet, so if the OSD tab does not automatically switch to HD, please enter the commands below manually.
```
set osd_displayport_device = MSP
set vcd_video_system = HD
```
The size of the canvas (visible number of columns/rows) defaults to 53x20 (compared to 30x16 for PAL and 30x13 for NTSC). The VTX is then able to adjust this by sending an MSP command to adjust the canvas size. WTFOS will set this to 60x22 for example. This will be automatic with no user interaction required. Should the goggle vendor decide to support alternate canvas sizes then they would be selected in the goggle menus, and the new canvas size communicated to Betaflight which would then adjust the usable number of OSD rows/columns accordingly.
Regardless of the canvas size the boot logo, armed message, stats, CMS menu etc. will be centred correctly.
If the canvas size is reduced, either by selecting the PAL/NTSC options or by the VTX sending a different canvas size, all OSD elements will be moved onto the available canvas so they can be repositioned using the configurator.
In addition to the usual OSD elements it is now possible, where supported by the Goggle/VTX vendor, to enable/disable and reposition the following OSD elements. If none are explicitly enabled then all those supported will be displayed at their default locations.
1. Goggle battery voltage
2. VTX voltage
3. Bit-rate
4. Delay
5. Distance
6. Video link quality
7. Goggle DVR icon
8. VTX DVR icon
9. VTX warnings
10. VTX temperature
11. Goggle fan speed
To make better use of the colour OSD capabilities of the HD systems, four fonts are now supported. The intent is that these be used to display text and other icons in **white**, **green**, **amber** and **red** corresponding to **normal**, **good**, **marginal**, **critical** conditions respectively. This will allow the link quality text and icon to be display in red when **critical**, **amber** when **marginal**, and **green** when **good** for example.
To enable this feature set the `displayport_msp_fonts` array to select the font number (0-4) to use for each of **normal**, **good**, **marginal**, **critical** conditions respectively.
To enable all four fonts:
```
set displayport_msp_fonts = 0,1,2,3
```
To only use the the default (predominantly white) font:
```
set displayport_msp_fonts = 0,0,0,0
```
To display critial warnings in red, select the first font for **normal**, **good**, and **marginal** OSD elements and for **critical** OSD elements select the third font:
```
set displayport_msp_fonts = 0,0,0,3
```
Thanks goes to @SteveCEvans for these improvements!
## 3. Preset Favourites
This feature reduces the amount of search the users have to do in the presets tab. Configurator will remember the presets you are using, automatically marking them with the "star". Favorite presets will always appear first in the initial list and the search results. In combination with the fix that preselects the current firmware from the plugged in FC it allows users to completely avoid searching of the commonly used presets, and pick them right away. The UI "stars" are clickable, so users can manually add/remove favorite presets.
![image](https://user-images.githubusercontent.com/2925027/212130300-f67a5d82-dbc2-4726-9c07-b6aae0aa98ae.png)
Favorite presets are being remembered by it's path+name in the repo. So a favorite preset in one repository becomes automatically a favorite in another, if it's sharing the same name and path withing the repos.
## 4. GPS Return to Home enhancements
**GPS "Rescue" has been extensively revised and greatly improved.** The quad should reliably return at the set speed, descend at an angle, land within a few metres of the home point, and disarm automatically on touch-down. There are separate PID control elements for altitude and return velocity t home; the defaults work very well for 'typical' quads. The system should initially be tested with a switch at reasonably close range and low altitude. Setting up and testing GPS Rescue to provide a reliable return on the event of an RxLoss failsafe is a non-trivial task, but well worth the trouble.
**We strongly recommend reading the [wiki entry](https://github.com/betaflight/betaflight/wiki/GPS-Rescue-for-4.4) and following the instructions there.**
Remember that in any true failsafe the quad will always enter Failsafe Stage 1 phase for 1s (user-configurable) before initiating the Rescue. You MUST set the Stage 1 behaviour NOT to DROP, or it will disarm and drop in Stage 1 and never enter GPS Rescue. The safest option for Stage 1 is to configure Angle Mode on an aux switch, and set Stage 1 Failsafe to enable Angle Mode at a fixed hover / light climb throttle value with all other sticks forced to center. When you get signal loss of more than 300ms, you'll enter Angle Mode, and the will start to level out. That will give you a clear advance warning that you are getting signal breakup. Alternatively, you can set Failsafe Stage 1 to hold all current values; the quad will then continue on the same path until Stage 1 Failsafe expires and the Rescue starts.
**Please disable the compass/magnetometer** unless:
- it has been fully calibrated and
- you have confirmed, by logging, that the magnetometer heading values are noise free and reflect the true attitude of the quad.
**In most short flights, using the Baro provides a significant improvement in altitude control.** Baro data is updated more frequently than GPS data, and often varies less. The user can control how much trust they place on the Baro vs GPS altitude data. Over long flights, and with some particular Baro units or installations, Baro drift can be more of a problem, and the GPS data should be trusted more.
There are three new, and very useful, GPS Rescue Debug modes. One shows how accurately the quad tracks the requested altitude and the requested velocity. The other two are used for tuning the GPS Rescue PIDs. If Mag is enabled, Mag information is automatically recorded.
Data acquisition from GPS hardware now uses the UBlox protocol, at 10hz, by default. NMEA mode has been improved and in some cases will run at 10hz. We now can log Dilution Of Precision values for future improvements.
There are extensive changes to sanity checks, and in most cases the quad will attempt to land itself, rather than disarm, if necessary using only the Baro signal.
**WARNING: ALWAYS CHECK that the Home Arrow points directly back towards home after takeoff!** Sometimes, if you take off and spin around during arming, or immediately on takeoff, the quad's attitude information can become corrupted, and the Home Arrow can point the wrong way. It's best to arm cleanly and fly away from Home in a straight line at reasonable speed immediately after takeoff. Watch the Home Arrow carefully to ensure that it quickly points back to Home. If the Home Arrow points the wrong way when a failsafe occurs, the GPS Rescue will initially fly off in the wrong direction and in some cases you may lose the quad.
thanks to @ctzsnooze, @karatebrot, @haslinghuis
## 5. Other OSD improvements
**Option to show 'READY' in the OSD with a mode switch**
This is a niche improvement, intended for racing situations where all pilots video feeds are on one central screen.
The pilot can flick a switch to indicate that they are ready to fly, and the word `READY` appears on their OSD.
The race director can then tell if all pilots are ready by looking at the central screen.
On arming, the `READY` text disappears.
For more info see [PR#11886](https://github.com/betaflight/betaflight/pull/11886) - thanks @jonmahoney15
**Craft and Pilot name now handled correctly**
The user can now configure their OSD to show either Craft or Pilot name, or both.
For more info see [PR#11391](https://github.com/betaflight/betaflight/pull/11391) - thanks @krasiyan
**PID profile and Rate profile names shown in OSD**
Thanks @qvasic
## 6. Support for extended DShot Telemetry
If the ESC supports it, we now can get per-motor temp, current and voltage via DSHot Telemetry.
For more info see [PR11694](https://github.com/betaflight/betaflight/pull/11694) - thanks @damosvil
## 7. Flight improvements
**Antigravity**
AntiGravity has been tweaked, resulting in greater stablility during rapid throttle changes, by:
- not applying AntiGravity P boost to yaw, preventing additional yaw wobbles during rapid throttle changes
- reducing the overall AntiGravity P boost to reduce the chance of unwanted P wobbles
- allows the relative P gain during AntiGravity to be set independently of the I boost, with `anti_gravity_p_gain`. The default is 100, meaning 'normal'. A lower number will give proportionally less P boost than default, for machines that get P wobbles readily during throttle boost, and vice versa.
- further optimisations of the timing of the boost effect. A PT2 filter is used at 6Hz by default. The value can be tweaked to focus the boost when it is needed most by changing the `anti_gravity_cutoff` value. Higher values will make the boost a bit stronger but of shorter duration. Lower values may work better for less responsive builds or where a more prolonged boost is needed.
- applying iTerm windup constraints to antigravity-induced iTerm increases (thanks tbolin)
- removing the old 'step' mode, which wasn't working as intended
The AntiGravity value is now directly related to the amount of iTerm boost. The default is now 80, meaning 8x iTerm boost on fast throttle cuts.
**Do not increase AntiGravity unless you've made a log and confirm that there is no P wobble. Use the debug.**
See [PR#11679](https://github.com/betaflight/betaflight/pull/11679) for more information - thanks @ctzsnooze, @tbolin.
**iTermWindup**
iTermWindup is an 'old' way to prevent iTerm growth when the quad cannot achieve the requested target rate.
In 4.4 we are making iTermWindup active by default, at a value of 85.
Whenever the motorMix percentage exceeds the `iterm_windup` limit value of 85%, iTerm growth will be reduced to the extent that motor_mix exceeds the `iterm_windup` value. There will be zero iTerm growth only when motorMix differential is 100%. The iTerm inhibiotion will apply on all axes, including yaw.
The default value is appropriate for nearly all quads. Heavy or very low authority quads with significant iTerm windup problems (slow oscillations on larger moves) may benefit from lower iterm_windup values.
iTermWindup complements iTermRelax, and is especially useful to prevent iterm windup in low authority quads where the machine is not able to meet the target rate for some time after the sticks have stopped moving. iTermRelax is most effective, and operates more smoothly, when the sticks are moving fast. iTermWindup also constrains iTerm growth in a variety of impact or failure states.
For more information see [PR#11806](https://github.com/betaflight/betaflight/pull/11806) - thanks @ctzsnooze.
**Smoother mixer behaviour when airmode is active with extreme stick inputs**
There were a number of edge cases where the onset of airmode throttle boost was not smooth, with different outcomes depending on the mixer type. The mixer is now better behaved.
For more information see [PR#11867](https://github.com/betaflight/betaflight/pull/11867) - thanks @QuickFlash.
## 7. ELRS 3.x support for ELRS SPI boards
NOTE: ELRS 2.x transmitters will not be able to bind to ELRS SPI Boards flashed with Betaflight 4.x.
## Other changes
- Four PID profiles (was 6), and 4 rate profiles (was 3) - thanks @haslinghuis
- TPA settings inside the PID profile - thanks @haslinghuis
- improved barometer smoothing and calibration, attitude calculation fixes, filter fixes - thanks @karatebrot
- HD OSD support - thanks @SteveCEvans
- VTX device over MSP [PR11705](https://github.com/betaflight/betaflight/pull/11705) - thanks @phobos
- parse and log GPS degree of precision (DOP) values [PR11912](https://github.com/betaflight/betaflight/pull/11912) - thanks @karatebrot
- hardware support for newer gyro chips, improved filtering for BMI160/270, etc - thanks @SteveCEvans and others
- lower minimum of 20Hz for dynamic notch, useful for low RPM setups with very large props
- increased dynamic idle minimum RPM from 100 (10k RPM) to 200 (20k rpm) for quads with very small props
- support for 64 discrete LEDs via cloud build option - PR12064 - thanks @Limonspb
- Fixes to NMEA at 10hz and UBlox comms - thanks @Karatebrot, @krzysztofkuczek
- Winbond W25q80 flash support - thanks @David-OConnor
- many bugfixes, target updates, driver updates and fixes - thanks to too many people to mention individually

88
docs/Rssi.md
View file

@ -1,88 +0,0 @@
# RSSI
RSSI is a measurement of signal strength and is very handy so you know when your aircraft is going out of range or if it is suffering RF interference.
Some receivers have RSSI outputs. 3 types are supported.
1. RSSI via PPM channel
1. RSSI via Parallel PWM channel
1. RSSI via ADC with PPM RC that has an RSSI output - aka RSSI ADC
## RSSI via PPM
Configure your receiver to output RSSI on a spare channel, then select the channel used via the CLI.
e.g. if you used channel 9 then you would set:
```
set rssi_channel = 9
```
Note: Some systems such as EZUHF invert the RSSI ( 0 = Full signal / 100 = Lost signal). To correct this problem you can invert the channel input so you will get a correct reading by using command:
```
set rssi_invert = ON
```
Default is set to "OFF" for normal operation ( 100 = Full signal / 0 = Lost signal).
## RSSI via Parallel PWM channel
Connect the RSSI signal to any PWM input channel then set the RSSI channel as you would for RSSI via PPM
## RSSI from Futaba S.Bus receiver
The S.Bus serial protocol includes detection of dropped frames. These may be monitored and reported as RSSI by using the following command.
```
set rssi_src_frame_errors = ON
```
Note that RSSI stands for Received Signal Strength Indicator; the detection of S.Bus dropped frames is really a signal quality, not strength indication. Consequently you may experience a more rapid drop in reported RSSI at the extremes of range when using this facility than when using RSSI reporting signal strength.
## RSSI ADC
Connect the RSSI signal to the RC2/CH2 input. The signal must be between 0v and 3.3v.
Use inline resistors to lower voltage if required; inline smoothing capacitors may also help.
A simple PPM->RSSI conditioner can easily be made. See the PPM-RSSI conditioning.pdf for details.
Under CLI :
- enable using the RSSI_ADC feature : `feature RSSI_ADC`
- set the RSSI_SCALE parameter (between 1 and 255) to adjust RSSI level according to your configuration. The raw ADC value is divided by the value of this parameter.
Note: Some systems invert the RSSI ( 0 = Full signal / 100 = Lost signal). To correct this problem you can invert the input so you will get a correct reading by using command:
```
set rssi_invert = ON
```
### RSSI_SCALE setup method
- set rssi_scale = 100. The displayed percentage will then be the raw ADC value.
- turn on RX (close to board). RSSI value should vary a little.
- Update rssi_scale to the maximum RSSI value previously measured.
FrSky D4R-II and X8R supported.
The feature can not be used when RX_PARALLEL_PWM is enabled.
## RSSI_SCALE setup method
To calculate the rssi offset and scale, check the rc value at full signal (`rssi_fullsig`) and at almost no signal strength (`rssi_nosig`).
Then, calculate the offset and scale values using the following formula:
```
rssi_offset = (1000-rssi_nosig) / 10
rssi_scale = 100 * 1000 / (rssi_fullsig - rssi_nosig)
```
Examples are:
| RC System | RC value at full strength | RC value at no strength | `rssi_offset` | `rssi_scale` |
|:----------|:--------------------------|:------------------------|:--------------|:-------------|
| Graupner | `1900` | `1100` | `-10` | `125` |
Then set these values via CLI:
```
set rssi_offset = -10
set rssi_scale = 125
```

394
docs/Rx.md
View file

@ -1,394 +0,0 @@
# Receivers (RX)
A receiver is used to receive radio control signals from your transmitter and convert them into signals that the flight controller can understand.
There are 3 basic types of receivers:
1. Parallel PWM Receivers
2. PPM Receivers
3. Serial Receivers
As of 2016 the recommendation for new purchases is a Serial or PPM based receiver. Avoid Parallel PWM recievers (1 wire per channel). This is due to the amount of IO pins parallel PWM based receivers use. Some new FC's do not support parallel PWM.
## Parallel PWM Receivers
8 channel support, 1 channel per input pin. On some platforms using parallel input will disable the use of serial ports
and SoftSerial making it hard to use telemetry or GPS features.
## PPM Receivers
PPM is sometimes known as PPM SUM or CPPM.
12 channels via a single input pin, not as accurate or jitter free as methods that use serial communications, but readily available.
These receivers are reported working:
* [FrSky D4R-II](http://www.frsky-rc.com/product/pro.php?pro_id=24)
* [Graupner GR24](http://www.graupner.de/en/products/33512/product.aspx)
* [R615X Spektrum/JR DSM2/DSMX Compatible 6Ch 2.4GHz Receiver w/CPPM](http://www.hobbyking.com/hobbyking/store/__46632__OrangeRx_R615X_DSM2_DSMX_Compatible_6Ch_2_4GHz_Receiver_w_CPPM.html)
* [FrSky D8R-XP 8ch telemetry receiver, or CPPM and RSSI enabled receiver](http://www.frsky-rc.com/product/pro.php?pro_id=21)
* [FrSky X4R and FrSky X4RSB](http://www.frsky-rc.com/download/view.php?sort=&down=158&file=X4R-X4RSB) when flashed with CPPM firmware and bound with jumper between signal pins 2 and 3
* All FrSky S.Bus enabled devices when connected with [S.Bus CPPM converter cable](http://www.frsky-rc.com/product/pro.php?pro_id=112). Without jumper this converter cable uses 21ms frame size (Channels 1-8). When jumper is in place, it uses 28ms frame and channels 1-12 are available
* FlySky/Turnigy FS-iA4B, FS-iA6B, FS-iA10 receivers all provide 8channels if the tx is sending them. (FS-i6 and FS-i10 transmitters). Use setting rx-setup/ppm to enable.
## Serial Receivers
### Spektrum
8 channels via serial currently supported.
These receivers are reported working:
Lemon Rx DSMX Compatible PPM 8-Channel Receiver + Lemon DSMX Compatible Satellite with Failsafe
http://www.lemon-rx.com/index.php?route=product/product&product_id=118
### S.BUS
16 channels via serial currently supported. See below how to set up your transmitter.
* You probably need an inverter between the receiver output and the flight controller. However, some flight controllers have this built in (the main port on CC3D, for example), and doesn't need one.
* Some OpenLRS receivers produce a non-inverted SBUS signal. It is possible to switch SBUS inversion off using CLI command `set sbus_inversion = OFF` when using an F3 based flight controller.
* Softserial ports cannot be used with SBUS because it runs at too high of a bitrate (1Mbps). Refer to the chapter specific to your board to determine which port(s) may be used.
* You will need to configure the channel mapping in the GUI (Receiver tab) or CLI (`map` command). Note that channels above 8 are mapped "straight", with no remapping.
These receivers are reported working:
FrSky X4RSB 3/16ch Telemetry Receiver
http://www.frsky-rc.com/product/pro.php?pro_id=135
FrSky X8R 8/16ch Telemetry Receiver
http://www.frsky-rc.com/product/pro.php?pro_id=105
Futaba R2008SB 2.4GHz S-FHSS
http://www.futaba-rc.com/systems/futk8100-8j/
#### OpenTX S.BUS configuration
If using OpenTX set the transmitter module to D16 mode and ALSO select CH1-16 on the transmitter before binding to allow reception
of all 16 channels.
OpenTX 2.09, which is shipped on some Taranis X9D Plus transmitters, has a bug - [issue:1701](https://github.com/opentx/opentx/issues/1701).
The bug prevents use of all 16 channels. Upgrade to the latest OpenTX version to allow correct reception of all 16 channels,
without the fix you are limited to 8 channels regardless of the CH1-16/D16 settings.
### SRXL (formerly XBUS)
(Serial Receiver Link Protocol)
SRXL is an open data transfer protocol which allows to transport control data from a rc receiver to another device like a flybarless system
by only using one single line. This protocol has been established by SRXL.org based on the idea to create a freely available and unified protocol
that manufacturers can easily implement to their receivers and devices that process receiver data. The protocol does not describe an exact definition of
how the data must be processed. It only describes a framework in which receiver data can be packed. Each manufacturer can have his own ID, which must be
attached to the beginning of each data set, so that the device using this data can correctly identify and process the payload of the dataset.
Supported receivers:
#### Multiplex:
All receivers with SRXL (also FLEXX receivers)
####Gaupner / SJ HOTT:
All receiver with SUMD support
#### Spektrum:
AR7700 / AR9020 receiver
#### JR:
JR X-BUS
Make sure to set your TX to use "MODE B" for XBUS in the TX menus!
See here for info on JR's XBUS protocol: http://www.jrpropo.com/english/propo/XBus/
These receivers are reported working:
XG14 14ch DMSS System w/RG731BX XBus Receiver
http://www.jramericas.com/233794/JRP00631/
#### Jeti:
Receivers with UDI output
### XBUS MODE B RJ01
There exist a remote receiver made for small BNF-models like the Align T-Rex 150 helicopter. The code also supports using the Align DMSS RJ01 receiver directly with the cleanflight software.
To use this receiver you must power it with 3V from the hardware, and then connect the serial line as other serial RX receivers.
In order for this receiver to work, you need to specify the XBUS_MODE_B_RJ01 for serialrx_provider. Note that you need to set your radio mode for XBUS "MODE B" also for this receiver to work.
Receiver name: Align DMSS RJ01 (HER15001)
### SUMD
16 channels via serial currently supported.
These receivers are reported working:
GR-24 receiver HoTT
http://www.graupner.de/en/products/33512/product.aspx
Graupner receiver GR-12SH+ HoTT
http://www.graupner.de/en/products/870ade17-ace8-427f-943b-657040579906/33565/product.aspx
### SUMH
8 channels via serial currently supported.
SUMH is a legacy Graupner protocol. Graupner have issued a firmware updates for many recivers that lets them use SUMD instead.
### IBUS
10 channels via serial currently supported.
IBUS is the FlySky digital serial protocol and is available with the FS-IA4B, FS-IA6B and
FS-IA10 receivers. The Turnigy TGY-IA6B and TGY-IA10 are the same
devices with a different label, therefore they also work.
If you are using a 6ch tx such as the FS-I6 or TGY-I6 then you must flash a 10ch
firmware on the tx to make use of these extra channels.
These receivers are reported working (all gives 10 channels serial):
- FlySky/Turnigy FS-iA4B 4-Channel Receiver (http://www.flysky-cn.com/products_detail/productId=46.html)
- FlySky/Turnigy FS-iA6B 6-Channel Receiver (http://www.flysky-cn.com/products_detail/&productId=51.html)
- FlySky/Turnigy FS-iA10 10-Channel Receiver (http://www.flysky-cn.com/products_detail/productId=53.html)
- FlySky/Turnigy FS-iA10B 10-Channel Receiver (http://www.flysky-cn.com/products_detail/productId=52.html)
#### Combine flysky ibus telemetry and serial rx on the same FC serial port
Connect Flysky FS-iA6B receiver like this:
```
+---------+
| FS-iA6B |
| |
| Ser RX |---|<---\ +------------+
| | | | FC |
| Sensor |--#==#--*-------| SerialTX |
+---------+ +------------+
```
Use a diode with cathode to receiver serial rx output (for example 1N4148),
the anode is connected to the FC serial _TX_ pin, and also via a
resistor (10KOhm) to the receiver ibus sensor port.
Note (2018-07-27): In some cases, the value of the series resistor may be too large, and going down to 1K[ohm] may provide a good result.
Enable with cli:
```
serial 1 1088 115200 57600 115200 115200
feature RX_SERIAL
set serialrx_provider = IBUS
save
```
### Jeti EX Bus
It supports 16 channels with a transfer rate of 100Hz. The HS option (High Speed) is currently not supported.
The receiver must be configured in the device manager to EX Bus and connected to a free FC serial _TX_ pin.
For more information on the wiring and setup see [this document](resources/How.to.setup.your.RX.and.FC.for.Jeti.Ex-Bus.pdf).
## MultiWii serial protocol (MSP)
Allows you to use MSP commands as the RC input. Only 8 channel support to maintain compatibility with MSP.
## Configuration
There are 3 features that control receiver mode:
```
RX_PPM
RX_SERIAL
RX_PARALLEL_PWM
RX_MSP
```
Only one receiver feature can be enabled at a time.
### RX signal-loss detection
The software has signal loss detection which is always enabled. Signal loss detection is used for safety and failsafe reasons.
The `rx_min_usec` and `rx_max_usec` settings helps detect when your RX stops sending any data, enters failsafe mode or when the RX looses signal.
By default, when the signal loss is detected the FC will set pitch/roll/yaw to the value configured for `mid_rc`. The throttle will be set to the value configured for `rx_min_usec` or `mid_rc` if using 3D feature.
Signal loss can be detected when:
1. no rx data is received (due to radio reception, recevier configuration or cabling issues).
2. using Serial RX and receiver indicates failsafe condition.
3. using any of the first 4 stick channels do not have a value in the range specified by `rx_min_usec` and `rx_max_usec`.
### RX loss configuration
The `rxfail` cli command is used to configure per-channel rx-loss behaviour.
You can use the `rxfail` command to change this behaviour.
A flight channel can either be AUTOMATIC or HOLD, an AUX channel can either be SET or HOLD.
* AUTOMATIC - Flight channels are set to safe values (low throttle, mid position for yaw/pitch/roll).
* HOLD - Channel holds the last value.
* SET - Channel is set to a specific configured value.
The default mode is AUTOMATIC for flight channels and HOLD for AUX channels.
The rxfail command can be used in conjunction with mode ranges to trigger various actions.
The `rxfail` command takes 2 or 3 arguments.
* Index of channel (See below)
* Mode ('a' = AUTOMATIC, 'h' = HOLD, 's' = SET)
* A value to use when in SET mode.
Channels are always specified in the same order, regardless of your channel mapping.
* Roll is 0
* Pitch is 1
* Yaw is 2
* Throttle is 3.
* Aux channels are 4 onwards.
Examples:
To make Throttle channel have an automatic value when RX loss is detected:
`rxfail 3 a`
To make AUX4 have a value of 2000 when RX loss is detected:
`rxfail 7 s 2000`
To make AUX8 hold it's value when RX loss is detected:
`rxfail 11 h`
WARNING: Always make sure you test the behavior is as expected after configuring rxfail settings!
#### `rx_min_usec`
The lowest channel value considered valid. e.g. PWM/PPM pulse length
#### `rx_max_usec`
The highest channel value considered valid. e.g. PWM/PPM pulse length
### Serial RX
See the Serial chapter for some some RX configuration examples.
To setup spectrum on the Naze32 or clones in the GUI:
1. Start on the "Ports" tab make sure that UART2 has serial RX. If not set the checkbox, save and reboot.
2. Move to the "Configuration" page and in the upper lefthand corner choose Serial RX as the receiver type.
3. Below that choose the type of serial receiver that you are using. Save and reboot.
Using CLI:
For Serial RX enable `RX_SERIAL` and set the `serialrx_provider` CLI setting as follows.
| Serial RX Provider | Value |
| ------------------ | ----- |
| SPEKTRUM1024 | 0 |
| SPEKTRUM2048 | 1 |
| SBUS | 2 |
| SUMD | 3 |
| SUMH | 4 |
| XBUS_MODE_B | 5 |
| XBUS_MODE_B_RJ01 | 6 |
| IBUS | 7 |
| JETIEXBUS | 8 |
### PPM/PWM input filtering.
Hardware input filtering can be enabled if you are experiencing interference on the signal sent via your PWM/PPM RX.
Use the `input_filtering_mode` CLI setting to select a mode.
| Value | Meaning |
| ----- | --------- |
| OFF | Disabled |
| ON | Enabled |
## Receiver configuration.
### FrSky D4R-II
Set the RX for 'No Pulses'. Turn OFF TX and RX, Turn ON RX. Press and release F/S button on RX. Turn off RX.
### Graupner GR-24 PWM
Set failsafe on the throttle channel in the receiver settings (via transmitter menu) to a value below `rx_min_usec` using channel mode FAILSAFE.
This is the prefered way, since this is *much faster* detected by the FC then a channel that sends no pulses (OFF).
__NOTE:__
One or more control channels may be set to OFF to signal a failsafe condition to the FC, all other channels *must* be set to either HOLD or OFF.
Do __NOT USE__ the mode indicated with FAILSAFE instead, as this combination is NOT handled correctly by the FC.
## Receiver Channel Range Configuration.
The channels defined in CleanFlight are as follows:
| Channel number | Channel name |
| ----- | --------- |
| 0 | Roll |
| 1 | Pitch |
| 2 | Yaw |
| 3 | Throttle |
If you have a transmitter/receiver, that output a non-standard pulse range (i.e. 1070-1930 as some Spektrum receivers)
you could use rx channel range configuration to map actual range of your transmitter to 1000-2000 as expected by Cleanflight.
The low and high value of a channel range are often referred to as 'End-points'. e.g. 'End-point adjustments / EPA'.
All attempts should be made to configure your transmitter/receiver to use the range 1000-2000 *before* using this feature
as you will have less preceise control if it is used.
To do this you should figure out what range your transmitter outputs and use these values for rx range configuration.
You can do this in a few simple steps:
If you have used rc range configuration previously you should reset it to prevent it from altering rc input. Do so
by entering the following command in CLI:
```
rxrange reset
save
```
Now reboot your FC, connect the configurator, go to the `Receiver` tab move sticks on your transmitter and note min and
max values of first 4 channels. Take caution as you can accidentally arm your craft. Best way is to move one channel at
a time.
Go to CLI and set the min and max values with the following command:
```
rxrange <channel_number> <min> <max>
```
For example, if you have the range 1070-1930 for the first channel you should use `rxrange 0 1070 1930` in
the CLI. Be sure to enter the `save` command to save the settings.
After configuring channel ranges use the sub-trim on your transmitter to set the middle point of pitch, roll, yaw and throttle.
You can also use rxrange to reverse the direction of an input channel, e.g. `rxrange 0 2000 1000`.
## Disabling the OpenTx/EdgeTx ADC Filter
OpenTx and EdgeTx both enable an `ADC filter` by default. Betaflight users should turn this off.
The `ADC filter` converts what would otherwise be smooth changes in channel values into a series of steps, where each step is about 1% of the full stick travel. It is intended to reduce 'chatter' when the Rx is connected to a *servo, so that the servo only changes position when a meaningful change has occurred. It is not intended for use with flight controllers.
When the `ADC Filter` is active, Betaflight does not receive the most recent position of the gimabl with each new RC packet. Instead, the Rx repeatedly provides the same data, until a moving-averaged smoothed estimate of gimbal position has increased by about 1% of full stick resolution.
Betaflight needs a non-delayed, smooth and continuous representation of the stick travel to give the PID system a smooth target setpoint value. Our RC Smoothing is based on the assumption that every packet is unique and that each is a new representation of the most recent position of the gimbal. Feedforward is calculated from the packet-to-packet position difference, and absolutely relies on smooth and regular updates in measured gimbal position.
When active with Betaflight firmware, the `ADC filter` causes:
- delay (from the moving averaging)
- sustained transient impacts
- steps in setpoint
- spikes and noise in feedforward, with reduced feedforward precision
- spikes in motor control signals that may cause noticeable jerking in HD video
This is why, whenever an OpenTx or EdgeTx user is using Betaflight, the OpenTx/EdgeTx `ADC Filter` **MUST** be disabled, for accurate smooth flight control.
The user only has to find the `ADC Filter` checkbox in the Hardware tab of the Global Settings for their radio, and ensure it is un-checked. For example, with the Frsky Taranis X9D+ pre 2019 model:
* Turn on your radio.
* Hold Menu to access Global Settings.
* Click the Page button 5 times to go to page 6 (HARDWARE).
* Scroll down and select ADC filter.
* Click Enter to disable the ADC filter as it's enabled by default.
* Click Exit (twice) to return to the startup screen.

29
docs/Safety.md
View file

@ -1,29 +0,0 @@
# Safety
As many can attest, multirotors and RC models in general can be very dangerous, particularly on the test bench. Here are some simple golden rules to save you a trip to the local ER:
* **NEVER** arm your model with propellers fitted unless you intend to fly!
* **Always** remove your propellers if you are setting up for the first time, flashing firmware, or if in any doubt.
## Before Installing
Please consult the [Cli](Cli.md), [Controls](Controls.md), [Failsafe](Failsafe.md) and [Modes](Modes.md)
pages for further important information.
You are highly advised to use the Receiver tab in the CleanFlight Configurator, making sure your Rx channel
values are centered at 1500 (1520 for Futaba RC) with minimum & maximums of 1000 and 2000 (respectively)
are reached when controls are operated. Failure to configure these ranges properly can create
problems, such as inability to arm (because you can't reach the endpoints) or immediate activation of
[failsafe](Failsafe.md).
You may have to adjust your channel endpoints and trims/sub-trims on your RC transmitter to achieve the
expected range of 1000 to 2000.
The referenced values for each channel have marked impact on the operation of the flight controller and the
different flight modes.
## Props Spinning When Armed
With the default configuration, when the controller is armed, the propellers *WILL* begin spinning at low speed.
We recommend keeping this setting as it provides a good visual indication the craft is armed.
If you wish to change this behavior, see the MOTOR_STOP feature in the Configurator and relevant documentation pages.
Enabling this feature will stop the props from spinning when armed.

BIN
docs/Screenshots/Provider ArcTimer.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 107 KiB

BIN
docs/Screenshots/Provider ERLT.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 109 KiB

BIN
docs/Screenshots/Provider iLap.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 96 KiB

BIN
docs/Screenshots/adjustments-incorrect-config-1.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 50 KiB

BIN
docs/Screenshots/adjustments-incorrect-config-2-corrected.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 76 KiB

BIN
docs/Screenshots/adjustments-incorrect-config-2.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 73 KiB

BIN
docs/Screenshots/adjustments-pid-via-6pos-and-3pos.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 49 KiB

BIN
docs/Screenshots/adjustments-pid-via-two-3pos.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 89 KiB

BIN
docs/Screenshots/adjustments-pitch-and-roll-rate-adjustment-via-3pos.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 27 KiB

BIN
docs/Screenshots/adjustments-rate-profile-selection-via-3pos.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 27 KiB

BIN
docs/Screenshots/adjustments-rates-via-a-2pos-and-3pos.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 50 KiB

BIN
docs/Screenshots/blackbox-dataflash.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 53 KiB

BIN
docs/Screenshots/blackbox-screenshot-1.jpg
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 242 KiB

BIN
docs/Screenshots/cleanflight-gui.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 70 KiB

282
docs/Serial.md
View file

@ -1,282 +0,0 @@
# Serial
Betaflight has enhanced serial port flexibility but configuration is slightly more complex as a result.
Betaflight has the concept of a function (MSP, GPS, Serial RX, etc) and a port (VCP, UARTx, SoftSerial x).
Not all functions can be used on all ports due to hardware pin mapping, conflicting features, hardware, and software
constraints.
## Serial port types
* USB Virtual Com Port (VCP) - USB pins on a USB port connected directly to the processor without requiring
a dedicated USB to UART adapter. VCP does not 'use' a physical UART port.
* UART - A pair of dedicated hardware transmit and receive pins with signal detection and generation done in hardware.
* SoftSerial - A pair of hardware transmit and receive pins with signal detection and generation done in software.
UART is the most efficient in terms of CPU usage.
SoftSerial is the least efficient and slowest, SoftSerial should only be used for low-bandwidth usages, such as telemetry transmission.
UART ports are sometimes exposed via on-board USB to UART converters, such as the CP2102 as found on the Naze and Flip32 boards.
If the flight controller does not have an on-board USB to UART converter and doesn't support VCP then an external USB to UART board is required.
These are sometimes referred to as FTDI boards. FTDI is just a common manufacturer of a chip (the FT232RL) used on USB to UART boards.
When selecting a USB to UART converter choose one that has DTR exposed as well as a selector for 3.3v and 5v since they are more useful.
Examples:
* [FT232RL FTDI USB To TTL Serial Converter Adapter](http://www.banggood.com/FT232RL-FTDI-USB-To-TTL-Serial-Converter-Adapter-Module-For-Arduino-p-917226.html)
* [USB To TTL / COM Converter Module buildin-in CP2102](http://www.banggood.com/Wholesale-USB-To-TTL-Or-COM-Converter-Module-Buildin-in-CP2102-New-p-27989.html)
Both SoftSerial and UART ports can be connected to your computer via USB to UART converter boards.
## Serial Configuration
Serial port configuration is best done via the configurator.
Configure serial ports first, then enable/disable features that use the ports. To configure SoftSerial ports the SOFTSERIAL feature must be enabled.
### Constraints
If the configuration is invalid the serial port configuration will reset to its defaults and features may be disabled.
* There must always be a port available to use for MSP/CLI.
* There is a maximum of 3 MSP ports.
* To use a port for a function, the function's corresponding feature must be also be enabled.
e.g. after configuring a port for GPS enable the GPS feature.
* If SoftSerial is used, then all SoftSerial ports must use the same baudrate.
* Softserial is limited to 19200 baud.
* All telemetry systems except MSP will ignore any attempts to override the baudrate.
* MSP/CLI can be shared with EITHER Blackbox OR telemetry. In shared mode blackbox or telemetry will be output only when armed.
* Smartport telemetry cannot be shared with MSP.
* No other serial port sharing combinations are valid.
* You can use as many different telemetry systems as you like at the same time.
* You can only use each telemetry system once. e.g. FrSky telemetry cannot be used on two port, but MSP Telemetry + FrSky on different ports is fine.
### Configuration via CLI
You can use the CLI for configuration but the commands are reserved for developers and advanced users.
The `serial` CLI command takes 6 arguments:
```
serial <port identifier> <port function> <msp baudrate> <gps baudrate> <telemetry baudrate> <blackbox baudrate>
```
| Serial cli command arguments |
| ---------------------------- |
| 1. Serial Port Identifier |
| 2. Serial Port Function |
| 3. MSP baud rate |
| 4. GPS baud rate |
| 5. Telemetry baud rate |
| 6. Blackbox baudrate |
Note: for Identifier see serialPortIdentifier_e in the source; for Function bitmask see serialPortFunction_e in the source code.
### 1. Serial Port Identifier
| Identifier | Value |
| -------------------------- | ----- |
| SERIAL\_PORT\_NONE | -1 |
| SERIAL\_PORT\_USART1 | 0 |
| SERIAL\_PORT\_USART2 | 1 |
| SERIAL\_PORT\_USART3 | 2 |
| SERIAL\_PORT\_UART4 | 3 |
| SERIAL\_PORT\_UART5 | 4 |
| SERIAL\_PORT\_USART6 | 5 |
| SERIAL\_PORT\_USART7 | 6 |
| SERIAL\_PORT\_USART8 | 7 |
| SERIAL\_PORT\_UART9 | 8 |
| SERIAL\_PORT\_USART10 | 9 |
| SERIAL\_PORT\_USB\_VCP | 20 |
| SERIAL\_PORT\_SOFTSERIAL1 | 30 |
| SERIAL\_PORT\_SOFTSERIAL2 | 31 |
| SERIAL\_PORT\_LPUART1 | 40 |
ID's 0-19 reserved for UARTS 1-20
ID's 20-29 reserved for USB 1-10
ID's 30-39 reserved for SoftSerial 1-10
ID's 40-49 reserved for LPUART 1-10
Other devices can be added starting from id 50.
### 2. Serial Port Function
| Function | Value | Bit |
| ---------------------------- | ------ | --- |
| FUNCTION\_NONE | 0 | 0 |
| FUNCTION\_MSP | 1 | 1 << 0 |
| FUNCTION\_GPS | 2 | 1 << 1 |
| FUNCTION\_TELEMETRY\_FRSKY_HUB | 4 | 1 << 2 |
| FUNCTION\_TELEMETRY\_HOTT | 8 | 1 << 3 |
| FUNCTION\_TELEMETRY\_LTM | 16 | 1 << 4 |
| FUNCTION\_TELEMETRY\_SMARTPORT | 32 | 1 << 5 |
| FUNCTION\_RX_SERIAL | 64 | 1 << 6 |
| FUNCTION\_BLACKBOX | 128 | 1 << 7 |
| NOT USED | 256 | 1 << 8 |
| FUNCTION\_TELEMETRY\_MAVLINK | 512 | 1 << 9 |
| FUNCTION\_ESC\_SENSOR | 1024 | 1 << 10 |
| FUNCTION\_VTX\_SMARTAUDIO | 2048 | 1 << 11 |
| FUNCTION\_TELEMETRY\_IBUS | 4096 | 1 << 12 |
| FUNCTION\_VTX\_TRAMP | 8192 | 1 << 13 |
| FUNCTION\_RCDEVICE | 16384 | 1 << 14 |
| FUNCTION\_LIDAR\_TF | 32768 | 1 << 15 |
| FUNCTION\_FRSKY\_OSD | 65536 | 1 << 16 |
| FUNCTION\_VTX\_MSP | 131072 | 1 << 17 |
| FUNCTION\_MSP\_DISPLAYPORT | 262145 | (1 << 18) \| FUNCTION\_MSP |
Note: `FUNCTION_FRSKY_OSD` = `(1<<16)` requires 17 bits.
Note2: We can use up to 32 bits (1<<32) here.
### 3. MSP Baudrates
| Baudrate |
| -------- |
| 9600 |
| 19200 |
| 38400 |
| 57600 |
| 115200 |
| 230400 |
| 250000 |
| 500000 |
| 1000000 |
### 4 GPS Baudrates
| Baudrate |
| -------- |
| 9600 |
| 19200 |
| 38400 |
| 57600 |
| 115200 |
Note: Also has a boolean AUTOBAUD. It is recommended to use a fixed baudrate. Configure GPS baudrate according to device documentation.
### 5. Telemetry Baudrates
| Baudrate |
| -------- |
| AUTO |
| 9600 |
| 19200 |
| 38400 |
| 57600 |
| 115200 |
### 6. Blackbox Baudrates
| Baudrate |
| -------- |
| 19200 |
| 38400 |
| 57600 |
| 115200 |
| 230400 |
| 250000 |
| 400000 |
| 460800 |
| 500000 |
| 921600 |
| 1000000 |
| 1500000 |
| 2000000 |
| 2470000 |
### Serial Port Baud Rates
The Serial Port baudrates are defined as follows:
| ID | Baudrate |
| -- | --------- |
| 0 | Auto |
| 1 | 9600 |
| 2 | 19200 |
| 3 | 38400 |
| 4 | 57600 |
| 5 | 115200 |
| 6 | 230400 |
| 7 | 250000 |
| 8 | 400000 |
| 9 | 460800 |
| 10 | 500000 |
| 11 | 921600 |
| 12 | 1000000 |
| 13 | 1500000 |
| 14 | 2000000 |
| 15 | 2470000 |
### Passthrough
Betaflight can enter a special passthrough mode whereby it passes serial data through to a device connected to a UART/SoftSerial port. This is useful to change the configuration of a Betaflight peripheral such as an OSD, bluetooth dongle, serial RX etc.
To initiate passthrough mode, use the CLI command `serialpassthrough` This command takes four arguments.
serialpassthrough <port1 id> [port1 baud] [port1 mode] [port1 DTR PINIO] [port2 id] [port2 baud] [port2 mode]
`PortX ID` is the internal identifier of the serial port from Betaflight source code (see serialPortIdentifier_e in the source). For instance UART1-UART4 are 0-3 and SoftSerial1/SoftSerial2 are 30/31 respectively. PortX Baud is the desired baud rate, and portX mode is a combination of the keywords rx and tx (rxtx is full duplex). The baud and mode parameters can be used to override the configured values for the specified port. `port1 DTR PINIO` identifies the PINIO resource which is optionally connected to a DTR line of the attached device.
If port2 config(the last three arguments) is not specified, the passthrough will run between port1 and VCP. The last three arguments are used for `Passthrough between UARTs`, see that section to get detail.
For example. If you have your MWOSD connected to UART 2, you could enable communicaton to this device using the following command. This command does not specify the baud rate or mode, using the one configured for the port (see above).
serialpassthrough 1
If a baud rate is not specified, or is set to 0, then `serialpassthrough` supports changing of the baud rate over USB. This allows tools such as the MWOSD GUI to dynamically set the baud rate to, for example 57600 for reflashing the MWOSD firmware and then 115200 for adjusting settings without having to powercycle your flight control board between the two.
_To use a tool such as the MWOSD GUI, it is necessary to disconnect or exit Betaflight configurator._
**To exit serial passthrough mode, power cycle your flight control board.**
In order to reflash an Arduino based device such as a MWOSD via `serialpassthrough` if is necessary to connect the DTR line in addition to the RX and TX serial lines. The DTR is used as a reset line to invoke the bootloader. The DTR line may be connected to any GPIO pin on the flight control board. This pin must then be associated with a PINIO resource, the instance of which is then passed to the serialpassthrough command. If you don't need it, you can ignore it or set it to `none`. The DTR line associated with any given UART may be set using the CLI command `resource` specifying it as a PINIO resource.
For example, the following configuration for an OpenPilot Revolution shows the UART6 serial port to be configured with TX on pin C06, RX on pin C07 and a DTR connection using PINIO on pin C08.
```
resource SERIAL_TX 1 A09
resource SERIAL_TX 3 B10
resource SERIAL_TX 4 A00
resource SERIAL_TX 6 C06
resource SERIAL_RX 1 A10
resource SERIAL_RX 3 B11
resource SERIAL_RX 6 C07
resource PINIO 1 C08
```
To assign the DTR line to another pin use the following command.
```
resource PINIO 1 c05
```
To disassociate DTR from a pin use the following command.
```
resource PINIO 1 none
```
Having configured a PINIO resource assocaited with a DTR line as per the above example, connection to an MWOSD attached to an Openpilot Revolution could be achieved using the following command.
```serialpassthrough 5 0 rxtx 1```
This will connect using UART 6, with the baud rate set over USB, full duplex, and with DTR driven on PINIO resource 1.
A (desirable) side effect of configuring the DTR line to be associated with a PINIO resource, is that when the FC is reset, the attached Arduino device will also be reset.
Note that if DTR is left configured on a port being used with a standard build of MWOSD firmware, the display will break-up when the flight controller is reset. This is because, by default, the MWOSD does not correctly handle resets from DTR. There are two solutions to this:
1. Assign the DTR pin using the resource command above prior to reflashing MWOSD, and then dissasociate DTR from the pin.
2. Rebuild MWOSD with MAX_SOFTRESET defined. The MWOSD will then be reset correctly every time the flight controller is reset.
### Passthrough between UARTs
in BetaFlight 4.1 or later, you can make a serial passthrough between UARTs.
the last three arguments of `serialpassthrough` are used to the passthrough between UARTs: `[port2 id]` `[port2 baud]` `[port2 mode]`, if you don't need passthrough between UARTs, just ignore them, and use `serialpassthrough` according to above description.
if you want passthrough between UARTs, `[port2 id]` is a required argument, the value range is same with `port1 ID` argument, it is the internal identifier of the serial port. `[port2 baud]`and`[port2 mode]` is optional argument, the default of them are `57600` and `MODE_RXTX`.
For example. If you using a filght controller built-in BLE chip, and the BLE chip was inner connected to a UART, you can use the following command to let the UART to talk with other UART:
```
serialpassthrough 0 115200 rxtx none 4 19200
```
the command will run a serial passthrough between UART1 and UART5, UART1 baud is 115200, mode is MODE_RXTX, DTR is none, UART5 baud is 19200, mode is not specific, it will take default value MODE_RXTX.

55
docs/Sonar.md
View file

@ -1,55 +0,0 @@
# Sonar
A sonar sensor can be used to measure altitude for use with BARO and SONAR altitude
hold modes.
The sonar sensor is used instead of the pressure sensor (barometer) at low altitudes (less than about 3.5 meters above the ground).
The sonar sensor is only used when the aircraft inclination angle (attitude) is small (less than 22.5 degrees).
## Hardware
Currently the main supported sensor is the HCSR04 sensor.
The Parallax 28015 single-wire sonar can also be used by connecting 1k resistors to the Trigger and Echo pins, and the other end of the resistors shorted together and to the Sonar module.
```
1k
TRIGGER--/\/\--\
\_______ 28015 SONAR
1k /
ECHO-----/\/\--/
```
## Connections
### Naze/Flip32+
| Mode | Trigger | Echo | Inline 1k resistors |
| ------------------------------- | ------------- | ------------- | ------------------- |
| Parallel PWM/ADC current sensor | PB8 / Motor 5 | PB9 / Motor 6 | NO (5v tolerant) |
| PPM/Serial RX | PB0 / RC7 | PB1 / RC8 | YES (3.3v input) |
#### Constraints
Current meter cannot be used in conjunction with Parallel PWM and Sonar.
### CC3D
| Trigger | Echo | Inline 1k resistors |
| ------------- | ------------- | ------------------- |
| PB5 / RC4 | PB0 / RC5 | YES (3.3v input) |
#### Constraints
Sonar cannot be used in conjuction with SoftSerial or Parallel PWM.
### SPRacingF3
| Trigger | Echo | Inline 1k resistors |
| ------------- | ------------- | ------------------- |
| PB0 / RC7 | PB1 / RC8 | YES (3.3v input) |
#### Constraints
Sonar cannot be used in conjuction with SoftSerial2 or Parallel PWM.

61
docs/Spektrum bind.md
View file

@ -1,61 +0,0 @@
# Spektrum bind support
Spektrum bind with hardware bind plug support.
The Spektrum bind code is enabled for most targets, some boards may not work due to SBus inverters. If you need Spektrum bind code ensure the board you are using specifically provides bind support.
## Configure the bind code
The following parameters can be used to enable and configure this in the related target.h file:
SPEKTRUM_BIND Enables the Spektrum bind code
BIND_PORT GPIOA Defines the port for the bind pin
BIND_PIN Pin_3 Defines the bind pin (the satellite receiver is connected to)
This is to activate the hardware bind plug feature
HARDWARE_BIND_PLUG Enables the hardware bind plug feature
BINDPLUG_PORT GPIOB Defines the port for the hardware bind plug
BINDPLUG_PIN Pin_5 Defines the hardware bind plug pin
## Hardware
The hardware bind plug will be enabled via defining HARDWARE_BIND_PLUG during building of the firmware. BINDPLUG_PORT and BINDPLUG_PIN also need to be defined (please see above). This is done automatically if the AlienFlight firmware is built. The hardware bind plug is expected between the defined bind pin and ground.
## Function
The spektrum_sat_bind CLI parameter is defining the number of bind impulses (1-10) send to the satellite receiver. Setting spektrum_sat_bind to zero will disable the bind mode in any case. The bind mode will only be activated after an power on or hard reset. Please refer to the table below for the different possible values.
If the hardware bind plug is configured the bind mode will only be activated if the plug is set during the firmware start-up. The value of the spektrum_sat_bind parameter will be permanently preserved. The bind plug should be always removed for normal flying.
If no hardware bind plug is used the spektrum_sat_bind parameter will trigger the bind process during the next hardware reset and will be automatically reset to "0" after this.
Please refer to the satellite receiver documentation for more details of the specific receiver in bind mode. Usually the bind mode will be indicated with some flashing LEDs.
## Table with spektrum_sat_bind parameter value
| Value | Receiver mode | Notes |
| ----- | ------------------| --------------------|
| 3 | DSM2 1024bit/22ms | |
| 5 | DSM2 2048bit/11ms | default AlienFlight |
| 7 | DSMX 1024bit/22ms | |
| 8 | DSMX 2048bit/22ms | Used by new DXe |
| 9 | DSMX 2048bit/11ms | |
### Connecting a Spektrum-compatible satellite to a Flip32+ flight controller
The Flip32/Flip32+ is wired in a rather strange way, i.e. the dedicated connector for the satellite module uses the same UART pins as the USB adapter. This means that you can't use that connector as it maps to UART1 which you really shouldn't assign to SERIAL_RX as that will break USB functionality. (Looks this problem is fixed in later versions of the Flip32/Flip32+)
In order to connect the satellite to a Flip32+, you have to wire the serial data pin to RC_CH4. This is the fourth pin from the top in the left column of the 3x6 header on the right side of the board. GND and +3.3V may either be obtained from the dedicated SAT connector or from any ground pin and pin 1 of the BOOT connector which also provides 3.3V.
#### Tested satellite transmitter combinations
| Satellite | Remote | Remark |
| -------------------- | -------------- | -------------------------------------------------------- |
| Orange R100 | Spektrum DX6i | Bind value 3 |
| Lemon RX DSMX | Spektrum DX6i | Bind value 9
| Lemon RX DSM2/DSMX | Spektrum DX8 | Bind value 5 |
| Lemon RX DSMX | Walkera Devo10 | Bind value 9, Deviation firmware 4.01 up to 12 channels |
| Lemon RX DSM2 | Walkera Devo7 | Bind value 9, Deviation firmware |
| Lemon RX DSMX | Spektrum DXe | Bind value 8, Supports up to 9 channels |

157
docs/TargetMaintenance/CreatingAUnifiedTarget.md
View file

@ -1,157 +0,0 @@
# How to Create a Target Configuration
## 1. Considerations for Target Configurations
### 1.1. General
Target Configurations are very flexible - anything that can be configured in Betaflight can be added to a Target Configuration. This is intentional, as it allows Target Configurations to be adapted to many different kinds of targets, from 'general purpose' flight controller boards over 'all in one' boards with on-board ESC and RX all the way to targets for 'ready to fly' craft that come pre-configured and pre-tuned.
However, this flexibility also puts the onus on target designers to be reasonable about what they add to the Target Configurations that they create and propose for publication. In general, Betaflight tries to minimise the risk of damage or injury to users, and to avoid configurations that will create problems and potential support issues for a majority of users of a particular target. We reserve the right to refuse to add Target Configurations that are in breach of these principles. Furthermore, target creators are advised to use common sense, and refrain from using configuration that is likely to annoy most users of their hardware - users are not likely to consider products from a manufacturer that has annoyed them in the past for future purchases.
Another expectation is that Target Configurations that are submitted for publication are **tested** - please, in the interest of your customers, do not submit untested configurations. Instructions on how to install Betaflight with a new and unpublished Target Configuration can be found [here](https://youtu.be/gO7HyoXYYLY).
### 1.2. Minimum configuration
The expectation is that a Target Configuration contains at least all of the settings to make the hardware on a board work for the user out of the box. The instructions in 2. can be used to create such a configuration from a legacy target. For any hardware that is not configured to work in the Target Configuration, Betaflight's answer to support requests for this hardware will be 'target X does not support this hardware'.
### 1.3. Don'ts
These are things that will result in a Target Configuration being rejected by Betaflight, such as:
- any settings that are equal to the defaults in the firmware (e.g. `resource ... NONE`). Having such settings included results in targets that are more likely to break with new versions of the firmware, and are therefore harder to maintain and more likely to cause support issues;
- pre-setting any calibration settings that are dependent on and different for every board, like `acc_calibration` - these are designed for the user to be prompted to calibrate them when connecting to Betaflight Configurator, in order to get the correct calibration for their hardware;
- Target Configurations that result in safety issues or a setup that is potentially illegal to be used where the user is, such as:
- setting `motor_pwm_protocol` to any digital protocol - if this default configuration is used with ESCs that do not support digital protocols, it is likely to result in motors spinning up as soon as a battery is connected. The default of `DISABLED` is safe, and the user will be asked to select a motor protocol that is appropriate for their ESCs when they connect to Betaflight Configurator. (Exception: If a Target Configuration is to be used for an all-in-one / RTF product only, an appropriate value for `motor_pwm_protocol` for the on-board ESCs can be selected.)
- pre-setting any VTX table settings - allowable values for these are governed by law in most countries, and it is up to the manufacturer / supplier of the VTX hardware and the user to make sure that they are complying with the laws in their country.
- setting any values that default to auto-detection (like `baro_hardware`, `mag_hardware`) to `NONE` - the default of `AUTO` is designed to work with no hardware present, and setting the value to `NONE` will result in support issues from users wanting to add their own hardware. (Exception: Boards that do not have any pins or pads for an SPI or I2C bus exposed _can_ define these settings as `NONE`.)
- pre-setting tuning settings for general purpose boards. Betaflight puts a lot of effort into shipping firmware with a default tune that is designed to work reliably across a wide range of hardware, and is extensively tested before every release. All of our documentation is based on this default tune. Adding a different tune to a Target Configuration will result in additional support issues from users for whom the instructions provided by Betaflight do not work. Furthermore, these custom defaults are likely to become outdated with future releases of Betaflight. (Exception: For Target Configurations that are used with only one RTF offering with fixed hardware, it may make sense to add a tune that is optimised for the hardware.)
### 1.4 Discouraged
Betaflight advises target creators against adding any setting to their Target Configuration if it is not strictly related to hardware configuration. Example settings that are discouraged:
- OSD element configuration;
- craft name;
- rates
All of these are really user preferences, and adding them as part of a Target Configuration just means that most customers of this hardware will have to spend extra time on reverting the presets before they can set up their own preferences. There are no strict rules here, and what is reasonable will be dependent on what type of target it is, but manufacturers are advised to use common sense.
## 2. Creating a Target Configuration for a new Board
These instructions explain how to create a new Target configuration. Creating Targets for a new board means you must start with a firmware for your MCU and build up the required pin mappings. The firmware can be a generic one, or one you have built locally. Start with this firmware and then validate pin mappings and hardware functionality needed in the configuration file.
### 2.1 Obtaining a target firmware for your MCU
Betaflight Configurator distributes customised targets featuring settings specific to each board. To create firmware for a new board it is recommended to build a generic firmware for your MCU type - STM32F411, STM32F405, STM32F7X2, and so on. If your board has special "compile time" configuration for specific hardware or boot configuration, these flags should be added as `EXTRA_PARAMS` on the make command line (e.g. `make TARGET=STM32F405 EXTRA_PARAMS="-D'MPU_I2C_INSTANCE=I2CDEV_1'"`. The `EXTRA_PARAMS` can be considered like the old target.h file.
These firmware types can be created by building locally and specifying the MCU type such as `make STM32F405`. Firmware files are created in the `obj` directory and can be flashed by choosing `Load local file` in Betaflight Configurator.
### 2.2 Flashing the target firmware
(Theoretically there is no need for the board to match the firmware that is flashed in this step, but there is a chance that the board configuration is setting an input pin on the board to be an output pin, thus leading to a short and potential hardware damage.)
- the important part is that this is the firmware for the MCU type your board uses.
- make sure to enable 'Full chip erase' before flashing, or reset to default with `defaults` in CLI.
- verify that your board is properly reset to defaults.
### 2.3 Resource Mappings
In CLI enter the command `resource show` and observe the pin mappings. Betaflight shows pin mappings as a single letter and two digits - `PA2` is shown as `A02`.
Validate that the key mappings for UARTs, motors, SPI, ADC and other common resources are correct. Then check that any unique hardware on your board is added.
Configure changed or additional hardware with the command `resource <DEVICE> <ID> <PIN>` where device refers to the type of (resource)[https://github.com/betaflight/betaflight/blob/master/src/main/drivers/resource.c] and ID allows for multiple resources of the same type and represents the number of the motor or UART port.
Once all resources are present type `save` and the board configuration will be persisted.
### 2.4 Validate resources
After saving your resource please test your board to ensure all hardware is fully operational. If hardware is not fully working repeat the "Resource Mappings" step.
Once testing is completed proceed to "Get a dump of your board configuration"
### 2.5 Get a dump of your board configuration
- re-start CLI (Disconnect / Connect), then do a `dump hardware`, save the output into a file with 'Save to File'.
### 2.6 Add #defines for hardware drivers
- edit the file from the previous step, and add #defines for accelerometer, barometer, gyro and magnetometer hardware drivers to be included for the cloud build API.
For example on [this target](https://github.com/betaflight/unified-targets/blob/master/configs/default/AIRB-NOX.config) this will look like:
# Betaflight / STM32F411 (S411) 4.1.0 Oct 16 2019 / 11:57:34 (c37a7c91a) MSP API: 1.42
#define USE_GYRO_SPI_MPU6000
#define USE_GYRO_SPI_MPU6500
#define USE_ACC_SPI_MPU6000
#define USE_ACC_SPI_MPU6500
#define USE_MAX7456
board_name NOX
manufacturer_id AIRB
For more information see reference at the [Hardware specification](https://github.com/betaflight/betaflight/blob/master/docs/Manufacturer%20Design%20Guidelines.md#42-definitions-for-targets)
### 2.7 Add the board and manufacturer information
- edit the file from the previous step, and verify that `board_name` is set to the target name, and `manufacturer_id` is set to the manufacturer's id as listed in [this document](https://github.com/betaflight/unified-targets/tree/master/Manufacturers.md);
- if the manufacturer is not listed, open an [issue](https://github.com/betaflight/betaflight/issues) and ask for a new id to be assigned. This issue needs to contain the following: name of the company selling the board and supporting customers of it; a website URL for this company. In a future release of the Betaflight configurator, the listing for every board will include this company name, and users will be able to open the company's website from within Betaflight configurator. Allow for a day or two for the Betaflight team to respond to your issue and assign a manufacturer it;
- for boards that are homebrew and / or not planned for commercial availability, use `CUST` as the `manufacturer_id`.
### 2.8 Flash the Target firmware
- find the correct Target for your board based on the MCU type, according to the table below. If your target's MCU is not listed, please open an [issue](https://github.com/betaflight/betaflight/issues) about this to let us know there is demand. Currently, MCU types with only one or two boards using them are not released as unified targets.
|Target|MCU Type|
|-|-|
|STM32F405|STM32F405|
|STM32F411|STM32F411|
|STM32G47X|STM32G471|
|STM32F7X2|STM32F722|
|STM32F745|STM32F745|
|STM32H743|STM32H743|
|STM32H750|STM32H750|
- find and install the firmware (4.0 or newer) for the Target identified above. The firmware is available the releases page as assets (generic) for Betaflight, or you may need to build your own. Be aware that after flashing this firmware, the LEDs on your board will not be working - this is normal.
### 2.9 Do the initial setup for your Target configuration
- connect to your board running the Target firmware, enter CLI;
- copy / paste the contents of the dump created in 2. into CLI, then enter `save`;
- when the board reboots now, the LEDs should start working again - this is a sign that the previous step was successful.
### 2.10 Add custom settings for your board to the Target configuration
- enter the command: `feature OSD` in CLI, just before the #master section (to switch on OSD by default);
- the following steps are optional (omitting it will give users of your board a minimal but working board configuration when using a Target):;
- set all the custom settings that are specific to your board (e.g. presets for serial RX on a specific port if the board's instructions are for users to use this port for the serial RX). Changes can be done in the UI or in CLI;
- try to only include extra settings if you are certain that most / all of your users will want them - unwanted extra changes just make it harder for your users to use your board;
- save the changes;
### 2.11 Create a Target configuration file for your board
- re-start CLI (Disconnect / Connect), then do a `diff all bare`, save the output into a file named `<manufacturer_id>-<board_name>.config` with 'Save to File'. It is crucial that the name exactly matches the manufacturer id and board name specified in the file, or else checking of the pull request you are going to open in a subsequent step will fail;
- edit the resulting file and identify the first line in the file starting with `# Betaflight`. This line (called the banner line) should be left untouched, and it has to be the first line in the file. Whatever content is found above this line, delete it. Likewise, there must be no extra lines after the last line starting with `set` - delete all subsequnet lines otherwise;
### 2.12 Test
- thoroughly test your new Target configuration with the actual hardware (or a prototype of it). Make sure you test all peripherals (gyro, OSD, flash, SDcard, ...) and all motor outputs (with analog and digital protocols). Ideally you want to flight test as well. Remember that Betaflight does no testing of your Target configuration, and once it has been accepted it will become available to your customers through Betaflight Configurator immediately - if it does not work then this will reflect badly onto your company and its products;
### 3.0 Get it added to Betaflight
- open a [pull request](https://github.com/betaflight/unified-targets/pulls) to put your target configuration into `configs/default`.

330
docs/Telemetry.md
View file

@ -1,330 +0,0 @@
# Telemetry
Telemetry allows you to know what is happening on your aircraft while you are flying it. Among other things you can receive battery voltages and GPS positions on your transmitter.
Telemetry can be either always on, or enabled when armed. If a serial port for telemetry is shared with other functionality then telemetry will only be enabled when armed on that port.
Telemetry is enabled using the 'TELEMETRY` feature.
```
feature TELEMETRY
```
Multiple telemetry providers are currently supported, FrSky, Graupner
HoTT V4, SmartPort (S.Port), LightTelemetry (LTM) and Ibus
All telemetry systems use serial ports, configure serial ports to use the telemetry system required.
## FrSky telemetry
FrSky telemetry is transmit only and just requires a single connection from the TX pin of a serial port to the RX pin on an FrSky telemetry receiver.
FrSky telemetry signals are inverted. To connect a Betaflight capable board to an FrSKy receiver you have some options.
1. A hardware inverter - Built in to some flight controllers.
2. Use software serial and enable frsky_inversion.
3. Use a flight controller that has software configurable hardware inversion (e.g. STM32F30x).
For 1, just connect your inverter to a usart or software serial port.
For 2 and 3 use the CLI command as follows:
```
set tlm_inverted = ON
```
### Available sensors
The following sensors are transmitted :
| Name | Description |
|----------|--------------------------------------------------------------------------------------------------------|
| Vspd | vertical speed, unit is cm/s. |
| Hdg | heading, North is 0°, South is 180°. |
| AccX,Y,Z | accelerometers values. |
| Tmp1 | baro temp if available, gyro otherwise. |
| RPM | if armed, throttle value. battery capacity otherwise. (Blade number needs to be set to 12 in Taranis). |
| VFAS | actual vbat value (see VFAS precision section bellow). |
| Curr | actual current comsuption, in amp. |
| Fuel | if capacity set, remaining battery percentage mah drawn otherwise. |
| GPS | GPS coordinates. |
| Alt | barometer based altitude, init level is zero. |
| Date | time since powered. |
| GSpd | current speed, calculated by GPS. |
| GAlt | GPS altitude, sea level is zero. |
| Tmp2 | number of sats. Every second, a number > 100 is sent to represent GPS signal quality. |
| Cels | average cell value, vbat divided by cell number. |
> Betaflight will send Cels (FLVSS Individual Cell Voltages Telemetry), disable the setting to use actual FLVSS sensor with:
> ```
> set telemetry_send_cells = OFF
> ```
>
> Note: cell voltage values are an assumed reputation of the cell voltage based on the packs voltage. Actual cell voltage may differ.
>
> To view individual cells or more importantly to get lowest cell (all cells are the sum of vbat, so each cell is the same in this case):
> See [OpenTX 2.1 & FrSky FLVSS Individual Cell Voltages](http://openrcforums.com/forum/viewtopic.php?t=7266).
> Add a new sensor, to display the lowest cell voltage set it up like this:
> - Type: Calculated
> - Formula: Cell
> - Cell Sensor: Cels _(pack total voltage, sum of all cells)_
> - Cell Index: Lowest
### Precision setting for VFAS
Betaflight can send VFAS (FrSky Ampere Sensor Voltage) in two ways:
```
set frsky_vfas_precision = 0
```
This is default setting which supports VFAS resolution of 0.2 volts and is supported on all FrSky hardware.
```
set frsky_vfas_precision = 1
```
This is new setting which supports VFAS resolution of 0.1 volts and is only supported by OpenTX radios (this method uses custom ID 0x39).
## HoTT telemetry
Only Electric Air Modules and GPS Modules are emulated.
Use the latest Graupner firmware for your transmitter and receiver.
Older HoTT transmitters required the EAM and GPS modules to be enabled in the telemetry menu of the transmitter. (e.g. on MX-20)
You can connect HoTT-Telemetry in two ways:
#### Old way:
Serial ports use two wires but HoTT uses a single wire so some electronics are required so that the signals don't get mixed up. The TX and RX pins of
a serial port should be connected using a diode and a single wire to the `T` port on a HoTT receiver.
Connect as follows:
* HoTT TX/RX `T` -> Serial RX (connect directly)
* HoTT TX/RX `T` -> Diode `-( |)-` > Serial TX (connect via diode)
The diode should be arranged to allow the data signals to flow the right way
```
-( |)- == Diode, | indicates cathode marker.
```
1N4148 diodes have been tested and work with the GR-24.
When using the diode disable `tlm_halfduplex`, go to CLI and type `set tlm_halfduplex = OFF`, don't forget a `save` afterwards.
#### New way:
You can use a single connection, connect HoTT RX/TX only to serial TX, leave serial RX open and make sure `tlm_halfduplex` is ON.
As noticed by Skrebber the GR-12 (and probably GR-16/24, too) are based on a PIC 24FJ64GA-002, which has 5V tolerant digital pins.
Note: The SoftSerial ports may not be 5V tolerant on your board. Verify if you require a 5v/3.3v level shifters.
## LightTelemetry (LTM)
LTM is a lightweight streaming telemetry protocol supported by a
number of OSDs, ground stations and antenna trackers.
The Betaflight implementation of LTM implements the following frames:
* G-FRAME: GPS information (lat, long, ground speed, altitude, sat
info)
* A-FRAME: Attitude (pitch, roll, heading)
* S-FRAME: Status (voltage, current+, RSSI, airspeed+, status). Item
suffixed '+' not implemented in Betaflight.
* O-FRAME: Origin (home position, lat, long, altitude, fix)
In addition, in the inav (navigation-rewrite) fork:
* N-FRAME: Navigation information (GPS mode, Nav mode, Nav action,
Waypoint number, Nav Error, Nav Flags).
LTM is transmit only, and can work at any supported baud rate. It is
designed to operate over 2400 baud (9600 in Betaflight) and does not
benefit from higher rates. It is thus usable on soft serial.
More information about the fields, encoding and enumerations may be
found at
https://github.com/stronnag/mwptools/blob/master/docs/ltm-definition.txt
## MAVLink telemetry
MAVLink is a very lightweight, header-only message marshalling library for micro air vehicles.
Betafight supports MAVLink for compatibility with ground stations, OSDs and antenna trackers built
for PX4, PIXHAWK, APM and Parrot AR.Drone platforms.
MAVLink implementation in Betaflight is transmit-only and usable on low baud rates and can be used over soft serial.
## SmartPort (S.Port)
Smartport is a telemetry system used by newer FrSky transmitters and receivers such as the Taranis/XJR and X8R, X6R and X4R(SB).
More information about the implementation can be found here: https://github.com/frank26080115/cleanflight/wiki/Using-Smart-Port
### Available sensors
The following sensors are transmitted :
| Name| Description|
| ----| -----------|
| A4 | average cell value. Warning : unlike FLVSS sensors, you do not get actual lowest value of a cell, but an average : (total lipo voltage) / (number of cells) |
| Alt | barometer based altitude, init level is zero. |
| Vspd | vertical speed, unit is cm/s. |
| Hdg | heading, North is 0°, South is 180°. |
| AccX,Y,Z | accelerometers values. |
| Tmp1 | actual flight mode, sent as 4 digits. Number is sent as (1)1234. Please ignore the leading 1, it is just there to ensure the number as always 5 digits (the 1 + 4 digits of actual data) the numbers are aditives (for example, if first digit after the leading 1 is 6, it means GPS Home and Headfree are both active) <ol><li>1 is GPS Hold, 2 is GPS Home, 4 is Headfree</li><li>1 is mag enabled, 2 is baro enabled, 4 is sonar enabled</li><li>3. 1 is angle, 2 is horizon, 4 is passthrough</li><li>4. 1 is ok to arm, 2 is arming is prevented, 4 is armed</li></ol> |
| Tmp2 | GPS lock status, Number is sent as 1234, the numbers are aditives<ol><li>1 is GPS Fix, 2 is GPS Home fix</li><li>HDOP (0-9, 0 is HDOP >= 5.5m, 9 is HDOP <= 1.0m)</li><li>number of sats</li><li>number of sats</li></ol> |
| VFAS | actual vbat value. |
| GAlt | GPS altitude, sea level is zero. |
| GSpd | current speed, calculated by GPS. |
| GPS | GPS coordinates. |
| 420 | GPS distance to home |
| Cels | average cell value, vbat divided by cell number. |
> Betaflight will send Cels (FLVSS Individual Cell Voltages Telemetry), disable the setting to use actual FLVSS sensor with:
> ```
> set report_cell_voltage = OFF
> ```
>
> Note: cell voltage values are an assumed reputation of the cell voltage based on the packs voltage. Actual cell voltage may differ. It is recommeded that you chain the flight controllers telemetry with a real Frsky FLVSS s.port sensor.
>
> To view individual cells or more importantly to get lowest cell (all cells are the sum of vbat, so each cell is the same in this case):
> See [OpenTX 2.1 & FrSky FLVSS Individual Cell Voltages](http://openrcforums.com/forum/viewtopic.php?t=7266).
> Add a new sensor, to display the lowest cell voltage set it up like this:
> - Type: Calculated
> - Formula: Cell
> - Cell Sensor: Cels _(pack total voltage, sum of all cells)_
> - Cell Index: Lowest
### Integrate Betaflight telemetry with FrSky Smartport sensors
While Betaflight telemetry brings a lot of valuable data to the radio, there are additional sensors, like Lipo cells sensor FLVSS, that can be a great addition for many aircrafts. Smartport sensors are designed to be daisy chained, and CF telemetry is no exception to that. To add an external sensor, just connect the "S" port of the FC and sensor(s) together, and ensure the sensor(s) are getting connected to GND and VCC either from the controler or the receiver
![Smartport diagram](assets/images/integrate_smartport.png)
### SmartPort on F3 targets with hardware UART
Smartport devices can be connected directly to STM32F3 boards such as the SPRacingF3 and Sparky, with a single straight through cable without the need for any hardware modifications on the FC or the receiver. Connect the TX PIN of the UART to the Smartport signal pin.
For Smartport on F3 based boards, enable the telemetry inversion setting.
```
set tlm_inverted = ON
```
### SmartPort on F1 and F3 targets with SoftSerial
Since F1 targets like Naze32 or Flip32 are not equipped with hardware inverters, SoftSerial might be simpler to use.
1. Enable SoftSerial ```feature SOFTSERIAL```
2. In Configurator assign _Telemetry_ > _Smartport_ > _Auto_ to SoftSerial port of your choice
3. Enable Telemetry ```feature TELEMETRY```
4. Confirm telemetry invesion ```set tlm_inverted = ON```
5. You have to bridge TX and RX lines of SoftSerial and connect them together to S.Port signal line in receiver
Notes:
* This has been tested with Flip32 and SPracingF3 boards and FrSky X8R and X4R receivers
* To discover all sensors board has to be armed, and when GPS is connected, it needs to have a proper 3D fix. When not armed, values like ***Vfas*** or GPS coordinates may not sent.
## Ibus telemetry
Ibus telemetry requires a single connection from the TX pin of a bidirectional serial port to the Ibus sens pin on an FlySky telemetry receiver. (tested with fs-iA6B receiver, iA10 should work)
It shares 1 line for both TX and RX, the rx pin cannot be used for other serial port stuff.
It runs at a fixed baud rate of 115200.
```
_______
/ \ /---------\
| STM32 |--UART TX-->[Bi-directional @ 115200 baud]<--| IBUS RX |
| uC |--UART RX--x[not connected] \---------/
\_______/
```
It should be possible to daisy chain multiple sensors with ibus. This is implemented but not tested because i don't have one of the sensors to test with, the FC shall always be the last sensor in the chain.
It is possible to combine serial rx and ibus telemetry on the same uart pin on the flight controller, see [Rx](Rx.md).
### Configuration
Ibus telemetry can be enabled in the firmware at build time using defines in target.h. It is enabled by default in those targets that have space left.
```
#define TELEMETRY
#define TELEMETRY_IBUS
```
CLI command to enable:
```
serial 1 1024 115200 57600 115200 115200
```
CLI setting to determine if the voltage reported is Vbatt or calculated average cell voltage
```
set report_cell_voltage=[ON/OFF]
```
### Available sensors
The following sensors are transmitted :
Tmp1 : baro temp if available, gyro otherwise.
RPM : throttle value
Vbatt : configurable battery voltage or the average cell value, vbat divided by number of cells.
### RX hardware ###
These receivers are reported to work with i-bus telemetry:
- FlySky/Turnigy FS-iA6B 6-Channel Receiver (http://www.flysky-cn.com/products_detail/&productId=51.html)
- FlySky/Turnigy FS-iA10B 10-Channel Receiver (http://www.flysky-cn.com/products_detail/productId=52.html)
Note that the FlySky/Turnigy FS-iA4B 4-Channel Receiver (http://www.flysky-cn.com/products_detail/productId=46.html) seems to work but has a bug that might lose the binding, DO NOT FLY the FS-iA4B!
## Jeti EX Bus telemetry
If telemetry is to be used, only the telemetry feature needs to be activated.
The telemetry names will be transmitted for the first 5-10 seconds.
The following values are available:
| Name | Unit|
| --------------- | ----|
| Voltage | [V]|
| Current | [A]|
| Altitude | [m]|
| Capacity | [mAh]|
| Power | [W]|
| Roll angle | [°]|
| Pitch angle | [°]|
| Heading | [°]|
| Vario | [m/s]|
| GPS Sats | [1]|
| GPS Long | |
| GPS Lat | |
| GPS Speed | [m/s]|
| GPS H-Distance | [m]|
| GPS H-Direction | [°]|
| GPS Heading | [°]|
| GPS Altitude | [m]|
| G-Force X | |
| G-Force Y | |
| G-Force Z | |
The telemetry values that are transmitted depend on whether a suitable sensor is available.
| Value | Sensor |
| ------------------------------------------- | ------ |
| Voltage | Voltage measurement|
| Current | Current measurement|
| Capacity and Power | Voltage & Current Measurement|
| Heading | Magnetometer|
| Altitude and Vario | Barometer|
| Roll angle, pitch angle and G-Froce X, Y, Z | ACC|
| GPS Sats, GPS... | GPS|

54
docs/Transponder.md
View file

@ -1,54 +0,0 @@
# Transponder
Cleanflight supports the generation of race transponder signals on compatiable F3 and F4 targets.
IR led connections is target specific. Please consult the reference manual for your FC.
Cleanflight currently supports 3 tranponder protocol providers (as of 2.10).
## iLap Provider
### Links:
[Web](http://www.rclapcounter.com/)
[Contact](cs@rclapcounter.com)
### Description:
iLap is a commercial system that uses 6 byte transponder codes and a 460kHz carrier.
Transponder codes are entered in the CF Configurator Transponder tab as 12 hex digits.
Codes are theoretical unique. Codes are obtained for iLap or come with some flight controllers.
<img src="Screenshots/Provider%20iLap.png" width="800">
## ArcTimer Provider
### Links:
[Web](http://www.arcitimer.com)
[Contact](info@arcitimer.com)
### Description:
Arctimer is a commercial system that uses 9 byte transponder codes and a 42kHz carrier.
There are only 9 unique Arctimer codes. Codes are pick from a list on CF Configurator Transponder tab.
<img src="Screenshots/Provider%20ArcTimer.png" width="800">
## EasyRaceLapTimer (ERLT) Provider
### Links:
[Web](http://www.easyracelaptimer.com/)
[Facebook](https://www.facebook.com/groups/1015588161838713/)
[RCGroups](https://www.rcgroups.com/forums/showthread.php?2538917-EasyRaceLapTimer-open-source-and-open-hardware-FPV-racing-lap-time-tracking-system)
[GitHub](https://github.com/polyvision/EasyRaceLapTimer)
### Description
EasyRaceLapTimer is a open source system that uses 6bit transponder codes and a 38kHz carrier.
There are 64 unique ERLT codes. Codes are pick from a list on CF Configurator Transponder tab.
<img src="Screenshots/Provider%20ERLT.png" width="800">

54
docs/USB Flashing.md
View file

@ -1,54 +0,0 @@
# USB Flashing
Some newer boards with full USB support must be flashed in USB DFU mode. This is a straightforward process in Configurator versions 0.67 and newer. The standard flashing procedure should work successfully with the caveat of some platform specific problems as noted below. The "No reboot sequence" checkbox has no effect as the device will automatically be detected when already in bootloader mode (a DFU device will appear in the connect dropdown if this is the case). The Full chip erase checkbox operates as normal. The baudrate checkbox is ignored as it has no relevance to USB.
### Charging-Only Cables
If you see no signs of life on your host computer when you plug in your board, check your cable with your mobile phone or some other USB device - some charging cables have only the power pins connected. These will power up the board, so the leds light up, but the host computer will not react to the device at all. You need a proper USB cable to connect your board to the Betaflight Configurator.
## Platform Specific: Linux
In order for Betaflight configurator to be able to access serial ports, your account needs to be in the `dialout` group. You can add yourself to this group as below:
```
sudo usermod -a -G dialout <username>
```
If your logs show `unable to open serial port` you might have skipped this step.
### Ubuntu
Linux requires udev rules to allow write access to USB devices for users. An example shell command to achieve this on Ubuntu is shown here:
```
(echo '# DFU (Internal bootloader for STM32 MCUs)'
echo 'SUBSYSTEM=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", MODE="0664", GROUP="plugdev"') | sudo tee /etc/udev/rules.d/45-stdfu-permissions.rules > /dev/null
```
This assigns the device to the plugdev group(a standard group in Ubuntu). To check that your account is in the plugdev group type `groups` in the shell and ensure plugdev is listed. If not you can add yourself as shown (replacing `<username>` with your username):
```
sudo usermod -a -G plugdev <username>
```
### Fedora
If you are using Fedora, you will not need to add your account to the plugdev group.
Instead use the `uaccess` tag in your udev rule for dfu:
```
(echo '# DFU (Internal bootloader for STM32 MCUs)'
echo 'SUBSYSTEM=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", MODE="0664", TAG+="uaccess"') | sudo tee /etc/udev/rules.d/45-stdfu-permissions.rules > /dev/null
```
### Connectivity Issues: Modem Manager
If you see your ttyUSB device disappear right after the board is connected, chances are that the ModemManager service (that handles network connectivity for you) thinks it is a GSM modem. If this happens, you can issue the following command to disable the service:
```
sudo systemctl stop ModemManager.service
```
If your system lacks the systemctl command, use any equivalent command that works on your system to disable services. You can likely add your device ID to a blacklist configuration file to stop ModemManager from touching the device, if you need it for cellural networking, but that is beyond the scope of betaflight documentation.
If you see the ttyUSB device appear and immediately disappear from the list in Betaflight Configurator when you plug in your flight controller via USB, chances are that NetworkManager thinks your board is a GSM modem and hands it off to the ModemManager daemon as the flight controllers are not known to the blacklisted.
## Platform Specific: Windows
Chrome can have problems accessing USB devices on Windows. A driver should be automatically installed by Windows for the ST Device in DFU Mode but this doesn't always allow access for Chrome. The solution is to replace the ST driver with a libusb driver. The easiest way to do that is to download [Zadig](http://zadig.akeo.ie/).
With the board connected and in bootloader mode (reset it by sending the character R via serial, or simply attempt to flash it with the correct serial port selected in Configurator):
* Open Zadig
* Choose Options > List All Devices
* Select `STM32 BOOTLOADER` in the device list
* Choose `WinUSB (v6.x.x.x)` in the right hand box
![Zadig Driver Procedure](assets/images/zadig-dfu.png)
* Click Replace Driver
* Restart Chrome (make sure it is completely closed, logout and login if unsure)
* Now the DFU device should be seen by Configurator

30
docs/Units.md
View file

@ -1,30 +0,0 @@
# Units
This document describes the current variables used to configure specific elements depending on the measurement unit applied.
### Units
| Unit | Speed | Distance | Temperature |
| -------- | ----- | -------- | ----------- |
| Imperial | MPH | Miles | Fahrenheit |
| Metric | KPH | KM | Celcius |
| British | MPH | KM | Celcius |
### Affected OSD Elements
| OSD Element | Imperial | Metric | British |
| ---------------- | -------- | ------ | ------- |
| Altitude | Feet | Metre | Metre |
| GPS Speed | MPH | KPH | MPH |
| Home Distance | Feet | Metre | Metre |
| Numerical Vario | FTPS | MPS | MPS |
| Flight Distance | Feet | Metre | Metre |
| OSD Efficiency | Miles | KM | KM |
Note: Configuration is done in cli with `set osd_units = <UNIT>` or in the OSD tab in the Betaflight Configurator. For example `set osd_units = BRITISH`
### Affected FrSky Hub Telemetry Elements
| Element | Imperial | Metric | British |
| ------- | ---------- | ------- | ------- |
| HDOP | Fahrenheit | Celcius | Celcius |
The FrSky hub telemetry setting can be changed in cli by `set frsky_unit = <UNIT>`.
For example `set frsky_unit = METRIC`

48
docs/Upgrading/Upgrading from 3.2 to 3.3.md
View file

@ -1,48 +0,0 @@
## Important information when upgrading from Betaflight 3.2 to Betaflight 3.3
- To get optimal support for configuration and tuning of the firmware, please use the latest version of the Betaflight configurator (10.2.0 at the time of this release), available [here](https://github.com/betaflight/betaflight-configurator/releases);
- If you are using OpenTX and the Betaflight lua scripts, please also make sure to use the latest version of these, available [here](https://github.com/betaflight/betaflight-tx-lua-scripts/releases);
- This release is introducing Runaway Takeoff Prevention [#4935](https://github.com/betaflight/betaflight/pull/4935). This feature will prevent uncontrollable acceleration ('tasmanian devil') when the craft is armed with misconfigured motor outputs or props on the wrong way, by disarming the craft if such a configuration is detected. It will also cause disarms when throttling up quickly on the bench with props off. If you get unwanted disarms right after arming, use the parameters (`runaway_takeoff_deactivate_delay`, `runaway_takeoff_deactivate_throttle_percent`) to tune the function to work for you, and please report back your working configuration. See the [wiki article](https://github.com/betaflight/betaflight/wiki/Runaway-Takeoff-Prevention) for details.
- The orientation of the AK8963 magnetometer has been changed, to make it match the orientation it has when it comes integrated in the MPU9250 gyro / accelerometer / magnetometer chip. If you are using an external AK8963 magnetometer, check your orientation to make sure it is still correct. If not, use the `align_mag` to configure the correct orientation;
- More possible reasons for arming to be disabled have been added. Because of this, and because counting the 'arming disabled' beep indications was becoming difficult, the method of how the arming disabled reason is indicated has been changed. See the [wiki article](https://github.com/betaflight/betaflight/wiki/Arming-Sequence-&-Safety#arming-prevention) for details.
- Arming is now disabled when the flight controller is connected to the Betaflight configurator. This was added in order to keep users from accidentally arming their craft when testing their RX / mode switches with a battery connected. In order to enable arming for bench testing, go to the 'Motors' tab and enable the 'Motor test mode' switch (**REMOVE ALL PROPELLERS FIRST**);
- The parameter `sbus_inversion` has been changed into `serialrx_inverted`, and the way it is applied has been changed as follows: It now applies to all RX protocols, not just SBus, and instead of switching the UART to normal when off and inverted when on, 'off' now means that the port is set to whatever the default is for the selected protocol (i.e. inverted for SBus, not inverted for SUMD), and 'on' means that the port is inverted from default (i.e. not inverted for SBus, inverted for SUMD);
- The way that rates are configured has been changed [#4973](https://github.com/betaflight/betaflight/pull/4973). Betaflight now supports independent rates settings for roll / pitch / yaw. When updating from an older version of the firmware, make sure to convert your settings to the new parameters as follows: `rc_rate` becomes `roll_rc_rate` and `pitch_rc_rate`, `rc_rate_yaw` becomes `yaw_rc_rate`, `rc_expo` becomes `roll_expo` and `pitch_expo`, and `rc_expo_yaw` becomes `yaw_expo`. The same change also makes 'RaceFlight' type rate settings available. Set `rates_type = raceflight`. After this, 'rc_rate_<axis>' is RaceFlight 'rate' (scaled down by a factor of 10), `<axis>_expo` is RaceFlight 'expo', and `<axis>_srate` is RaceFlight 'acro+';
- The `DISABLE 3D` mode is now called `DISABLE / SWITCH 3D` [#5179](https://github.com/betaflight/betaflight/pull/5179). In default configuration it works in the same way it used to work before. With `3d_switched_mode = on`, 'switched 3d mode' is enabled: With the 3D switch on, the throttle goes from forward thrust idle (min) to forward thrust full (max), which is the same as with `3d_switched_mode = off`. With the 3D switch off, the throttle goes from reversed thrust idle (min) to reversed thrust full (max). This allows the pilot to fly 3d by using the full throttle range in normal / reversed position, by switching motor directions with the switch when flipping over;
- The `disarm_kill_switch` function that allowed (switch) disarming to be set up to be only possible on low throttle has been removed. There is no use case that requires it, and having it enabled introduces the safety risk of not being able to reliably disarm in an emergency;
- The SmartAudio protocol implementation has been updated to be fully compliant with the SmartAudio specification. First generation AKK / RDQ VTX devices have a bug in their SmartAudio protocol implementation, causing them to fail to work with the SmartAudio protocol as implemented by Betaflight 3.3 (and KISS / RaceFlight). In order to not leave the owners of these VTX devices stranded, a branch off the Betaflight 3.3 maintenance branch has been created with a fix for these devices in it. This branch will be updated for all 3.3 patch releases. If you own one of these first generation AKK / RDQ VTX devices and are affected by this bug, please go to [this website](https://ci.betaflight.tech/job/Betaflight%20Maintenance%203.3%20%28AKK%20-%20RDQ%20VTX%20Patch%29/lastSuccessfulBuild/artifact/obj/) to download a Betaflight 3.3 version that works with your VTX device. (Go back to this page to download the latest version whenever a new version of Betaflight 3.3 has been released.)
## Major features:
- Added support for the FrSky FPort protocol [#4158](https://github.com/betaflight/betaflight/pull/4158);
- Added Spektrum VTX control [#4434](https://github.com/betaflight/betaflight/pull/4434);
- Added CMS configuration over Spektrum telemetry [#4545](https://github.com/betaflight/betaflight/pull/4545);
- Added FrSky X SPI RX protocol [#4683](https://github.com/betaflight/betaflight/pull/4683);
- Added fast Biquad RC+FIR2 filter (optimised version of Kalman gyro filter in #4890) [#4965](https://github.com/betaflight/betaflight/pull/4965);
- Added Runaway Takeoff Prevention (anti-taz) [#4935](https://github.com/betaflight/betaflight/pull/4935).
## Minor features:
- Added CMS power menu [#3724](https://github.com/betaflight/betaflight/pull/3724);
- Added support for FlySky SPI receiver [#4060](https://github.com/betaflight/betaflight/pull/4060);
- Added use TIM_UP and DMAR for all timer channels with Dshot ([#4073](https://github.com/betaflight/betaflight/pull/4073), [#4843](https://github.com/betaflight/betaflight/pull/4843), [#4852](https://github.com/betaflight/betaflight/pull/4852));
- Added '3D on a switch' mode [#4227](https://github.com/betaflight/betaflight/pull/4227);
- Added Dshot beacon activation to BEEPER_RX_LOST_LANDING [#4231](https://github.com/betaflight/betaflight/pull/4231);
- Added generic RunCam device protocol support [#4251](https://github.com/betaflight/betaflight/pull/4251), see the [wiki article](https://github.com/betaflight/betaflight/wiki/RunCam-Device-Protocol) for details;
- Added a reasonable default OSD layout [#4260](https://github.com/betaflight/betaflight/pull/4260);
- Added handling and display of date and time [#4289](https://github.com/betaflight/betaflight/pull/4289);
- Added MSP command to disable arming [#4320](https://github.com/betaflight/betaflight/pull/4320);
- Added support for Spektrum real RSSI from SRXL Rx and fake RSSI from both int and ext bound satellites [#4347](https://github.com/betaflight/betaflight/pull/4347);
- Changed after flight OSD statistics screen to only show when enabled [#4428](https://github.com/betaflight/betaflight/pull/4428);
- Added remaining time estimate based on flight used mAh rate to OSD ([#4487](https://github.com/betaflight/betaflight/pull/4487), [#4543](https://github.com/betaflight/betaflight/pull/4543), [#4618](https://github.com/betaflight/betaflight/pull/4618));
- Added setting of RSSI value with MSP [#4507](https://github.com/betaflight/betaflight/pull/4507);
- Improved SmartAudio update frequency (make it QuietAudio) [#4532](https://github.com/betaflight/betaflight/pull/4532);
- Updated PID calculations to use actual deltaT [#4556](https://github.com/betaflight/betaflight/pull/4556);
- Added AND logic to modes [#4722](https://github.com/betaflight/betaflight/pull/4722);
- Add TCM support to F7 [#4757](https://github.com/betaflight/betaflight/pull/4757);
- Added Benewake TFmini/TF02 rangefinder support [#4793](https://github.com/betaflight/betaflight/pull/4793);
- Added selectable RaceFlight rates [#4973](https://github.com/betaflight/betaflight/pull/4973);
- Added KN (NRF24) SPI RX protocol [#4994](https://github.com/betaflight/betaflight/pull/4994);
- Added Spektrum VTX status via telemtry [#5081](https://github.com/betaflight/betaflight/pull/5081);
- Added PINIOBOX BOX to PINIO general purpose pin output mapper [#5110](https://github.com/betaflight/betaflight/pull/5110).

295
docs/VTX.md
View file

@ -1,295 +0,0 @@
# VTX
Cleanflight supports control of VTX modules.
## VTX Systems
Current support includes
1. RTC6705 directly connected to the CPU (maybe via a PCB board interconnect, e.g. SPRACINGF3NEO)
2. IRC Tramp
3. TBS Smart Audio
## VTX Button
If your FC has a button, excluding a BOOT buttons, then it can be used for VTX control.
Some boards like the SPRacingF3NEO have both a VTX module and a button.
Other boards like the SPRacingF3MINI have multiple buttons.
### VTX Button usage
While the VTX button is held the STATUS 2 LED will flash N times per second indicating the action that will be taken when
the button is released. The flashing starts as soon as the button is held. e.g. You press the button, count flashes and
then release as appropriate.
| Duration | Function | Flashes |
|---------------|---------------------------|-----------|
| 25ms to 1s | Cycle Channel | 4 |
| 1s to 3s | Cycle Band | 3 |
| 3s to 5s | Cycle Power and RF Power | 2 |
| 5s or more | Save FC settings | 1 |
Example to cycle VTX power
```
| 0 seconds | 1 second | 2 seconds | 3 seconds | 4 seconds | 5 seconds | 6 seconds or more |
|-HOLD BUTTON-----------------------------------|-RELEASE BUTTON-NOW------------|-RELEASED TOO LATE TO CHANGE POWER-|
| 4 Flashes | 3 flashes | 3 flashes | 2 flashes | 2 flashes | 1 flash | 1 flash |
```
The VTX button works with ALL VTX systems including onboard RTC6705, Tramp and SmartAudio.
If the VTX can be turned off then POWER 0 will turn off the VTX and POWER 1 will set the VTX into it's lowest power output.
If the VTX cannot be turned off then POWER 0 will set the VTX into it's lowest power output.
## VTX Table
As of Betaflight 4.1.0, band/channel and power level information needed to control videotransmitters is no longer hardcoded,
but stored in a new facility called vtxTable.
The contents of the vtxTable need to be setup manually. They need to match the hardware, local laws and regulations, as
well as user preferences.
The contents of the table can be examined by typing the command `vtxtable` into the cli.
Example:
```
# vtxtable
vtxtable bands 5
vtxtable channels 8
vtxtable band 1 BOSCAM_A A FACTORY 0 5845 5825 5805 5785 5765 5745 0
vtxtable band 2 BOSCAM_B B FACTORY 0 5752 5771 5790 5809 5828 5847 0
vtxtable band 3 BOSCAM_E E FACTORY 0 0 0 0 0 0 0 0
vtxtable band 4 MYBAND M CUSTOM 5745 5769 0 5806 0 5843 0 0
vtxtable band 5 RACEBAND R FACTORY 0 0 0 5769 5806 5843 0 0
vtxtable powerlevels 3
vtxtable powervalues 14 20 26
vtxtable powerlabels 25 100 400
```
### Bands and channels
The example above contains 5 bands, **each with a name, a single-letter abbreviation, a factory flag and eight frequencies.**
The factory flag controls how Betaflight communicates with the vtx.
**When the flag is set to `FACTORY`, Betaflight sends the vtx a band and channel number.**
The vtx will then use its built-in frequency table.
In this mode, the actual contents of the vtxtable are **not** send the vtx. They are only used for display in the OSD and similar places.
As such, bands with the flag set to `FACTORY` should be set to match the built-in frequency table of the vtx.
**When the flag is set to `CUSTOM`, Betaflight sends the vtx the frequency it should use.**
This mode utilizes the contents of the table and allows the user to create custom bands with whatever frequencies they like.
**Videotransmitters without a built-in table, such as IRC Tramp or rtc6705 only support `CUSTOM`.**
Entries of the vtxtable can be blocked by setting their frequency to 0. This is especially useful for bands set to `FACTORY`: The spots of
unwanted entries of the videotransmitter's built-in table can be set to 0, effectively disabling them.
In the example above this was used to only allow frequencies between 5725 and 5875 MHz, as a German pilot would want it to comply with
German laws. Additionally, the Fatshark band was replaced with a new custom one.
As a starting point, the following table contains the commonly used frequencies:
```
# This table should not be used as-is, but trimmed down according to local laws and regulations.
vtxtable band 1 BOSCAM_A A FACTORY 5865 5845 5825 5805 5785 5765 5745 5725
vtxtable band 2 BOSCAM_B B FACTORY 5733 5752 5771 5790 5809 5828 5847 5866
vtxtable band 3 BOSCAM_E E FACTORY 5705 5685 5665 5645 5885 5905 5925 5945
vtxtable band 4 FATSHARK F FACTORY 5740 5760 5780 5800 5820 5840 5860 5880
vtxtable band 5 RACEBAND R FACTORY 5658 5695 5732 5769 5806 5843 5880 5917
```
### Power levels
In addition the the frequency, videotransmitters also need to know how much power they should use for transmission.
The example shown previously contains three power levels, **each with a value and a label.** The label is shown to the user in the OSD,
while the value is sent to the vtx.
Power levels should be setup to match the hardware in use.
#### IRC Tramp devices should use:
```
vtxtable powerlevels 5
vtxtable powervalues 25 100 200 400 600
vtxtable powerlabels 25 100 200 400 600
```
#### rtc6705 should use:
```
vtxtable powerlevels 2
vtxtable powervalues 1 2
vtxtable powerlabels MIN MAX
```
Please note that turning off rtc6705 devices is not possible using powervalues. Use pitmode instead.
#### SmartAudio V1.0 devices should use:
```
vtxtable powerlevels 4
vtxtable powervalues 7 16 25 40
vtxtable powerlabels 25 200 500 800
```
#### SmartAudio V2.0 devices should use:
```
vtxtable powerlevels 4
vtxtable powervalues 0 1 2 3
vtxtable powerlabels 25 200 500 800
```
#### SmartAudio V2.1 devices vary depending on their model. Check the manufacturers website.
For these devices the `powervalues` are the output power in dBm.
To query the available power levels from a SmartAudio 2.1 VTX enter the `vtx_info` command with no parameters. This will report the available power settings thus:
```
# vtx_info
level 14 dBm, power 25 mW
level 20 dBm, power 100 mW
level 26 dBm, power 400 mW
```
For example the
[TBS Unify Pro32 Nano 5G8](https://www.team-blacksheep.com/products/prod:unifypro32_nano):
```
vtxtable powerlevels 3
vtxtable powervalues 14 20 26
vtxtable powerlabels 25 100 400
```
[TBS Unify Pro 5G8 HV - Race 2 (MMCX)](https://www.team-blacksheep.com/products/prod:unify_pro_hv_race2_m):
```
vtxtable powerlevels 3
vtxtable powervalues 13 20 26
vtxtable powerlabels 25 100 400
```
[TBS Unify Pro32 HV (MMCX)](https://www.team-blacksheep.com/products/prod:unifypro32_hv):
```
vtxtable powerlevels 4
vtxtable powervalues 14 20 26 30
vtxtable powerlabels 25 100 400 1W
```
[TBS Unify EVO](https://www.team-blacksheep.com/products/prod:tbs_unify_evo):
```
vtxtable powerlevels 4
vtxtable powervalues 14 20 26 29
vtxtable powerlabels 25 100 400 800
```
Power levels may be omitted. This is useful for compliance with local laws and regulations.
Additionally, powerlabels (but not values!) can be set to anything three characters long.
For example a TBS Unify EVO will also work the this config:
```
vtxtable powerlevels 2
vtxtable powervalues 20 26
vtxtable powerlabels .1W .4W
```
### Complete Examples
#### IRC Tramp device
```
# This example enables a lot of power levels and channels.
# Almost nobody will be able to legally use this without modification.
# Check your local laws and regulations before use!
vtxtable bands 5
vtxtable channels 8
vtxtable band 1 BOSCAM_A A CUSTOM 5865 5845 5825 5805 5785 5765 5745 5725
vtxtable band 2 BOSCAM_B B CUSTOM 5733 5752 5771 5790 5809 5828 5847 5866
vtxtable band 3 BOSCAM_E E CUSTOM 5705 5685 5665 5645 5885 5905 5925 5945
vtxtable band 4 FATSHARK F CUSTOM 5740 5760 5780 5800 5820 5840 5860 5880
vtxtable band 5 RACEBAND R CUSTOM 5658 5695 5732 5769 5806 5843 5880 5917
vtxtable powerlevels 5
vtxtable powervalues 25 100 200 400 600
vtxtable powerlabels 25 100 200 400 600
```
#### SmartAudio 1.0 device
```
# This example enables a lot of power levels and channels.
# Almost nobody will be able to legally use this without modification.
# Check your local laws and regulations before use!
vtxtable bands 5
vtxtable channels 8
vtxtable band 1 BOSCAM_A A FACTORY 5865 5845 5825 5805 5785 5765 5745 5725
vtxtable band 2 BOSCAM_B B FACTORY 5733 5752 5771 5790 5809 5828 5847 5866
vtxtable band 3 BOSCAM_E E FACTORY 5705 5685 5665 5645 5885 5905 5925 5945
vtxtable band 4 FATSHARK F FACTORY 5740 5760 5780 5800 5820 5840 5860 5880
vtxtable band 5 RACEBAND R FACTORY 5658 5695 5732 5769 5806 5843 5880 5917
vtxtable powerlevels 4
vtxtable powervalues 7 16 25 40
vtxtable powerlabels 25 200 500 800
```
#### SmartAudio 2.0 device
```
# This example enables a lot of power levels and channels.
# Almost nobody will be able to legally use this without modification.
# Check your local laws and regulations before use!
vtxtable bands 5
vtxtable channels 8
vtxtable band 1 BOSCAM_A A FACTORY 5865 5845 5825 5805 5785 5765 5745 5725
vtxtable band 2 BOSCAM_B B FACTORY 5733 5752 5771 5790 5809 5828 5847 5866
vtxtable band 3 BOSCAM_E E FACTORY 5705 5685 5665 5645 5885 5905 5925 5945
vtxtable band 4 FATSHARK F FACTORY 5740 5760 5780 5800 5820 5840 5860 5880
vtxtable band 5 RACEBAND R FACTORY 5658 5695 5732 5769 5806 5843 5880 5917
vtxtable powerlevels 4
vtxtable powervalues 0 1 2 3
vtxtable powerlabels 25 200 500 800
```
#### SmartAudio 2.1 device
```
# This example enables a lot of power levels and channels.
# Almost nobody will be able to legally use this without modification.
# Check your local laws and regulations before use!
vtxtable bands 5
vtxtable channels 8
vtxtable band 1 BOSCAM_A A FACTORY 5865 5845 5825 5805 5785 5765 5745 5725
vtxtable band 2 BOSCAM_B B FACTORY 5733 5752 5771 5790 5809 5828 5847 5866
vtxtable band 3 BOSCAM_E E FACTORY 5705 5685 5665 5645 5885 5905 5925 5945
vtxtable band 4 FATSHARK F FACTORY 5740 5760 5780 5800 5820 5840 5860 5880
vtxtable band 5 RACEBAND R FACTORY 5658 5695 5732 5769 5806 5843 5880 5917
vtxtable powerlevels 4
vtxtable powervalues 14 20 26 30
vtxtable powerlabels 25 100 400 1W
```
#### rtc6705
```
# This example enables a lot of power levels and channels.
# Almost nobody will be able to legally use this without modification.
# Check your local laws and regulations before use!
vtxtable bands 5
vtxtable channels 8
vtxtable band 1 BOSCAM_A A CUSTOM 5865 5845 5825 5805 5785 5765 5745 5725
vtxtable band 2 BOSCAM_B B CUSTOM 5733 5752 5771 5790 5809 5828 5847 5866
vtxtable band 3 BOSCAM_E E CUSTOM 5705 5685 5665 5645 5885 5905 5925 5945
vtxtable band 4 FATSHARK F CUSTOM 5740 5760 5780 5800 5820 5840 5860 5880
vtxtable band 5 RACEBAND R CUSTOM 5658 5695 5732 5769 5806 5843 5880 5917
vtxtable powerlevels 2
vtxtable powervalues 1 2
vtxtable powerlabels MIN MAX
```
### Pitmode
Pitmode is separate from vtxTable. No power level should be created for pitmode.
Pitmode can be controlled in a variety of ways including OSD, AUX switches and lua scripts.
Some videotransmitters have restrictions on its usage. For example, SmartAudio V1.0 and V2.0 devices can only enter pitmode on power-up.
Betaflight can make the these devices leave pitmode, but not enter it.
rtc6705 devices do not support a proper ultra-low power pitmode. Instead, if the board supports it, pitmode turns off rtc6705 devices completely.

BIN
docs/Wiring/CC3D - buzzer circuit.pdf
View file

Binary file not shown.

BIN
docs/Wiring/Crius CO-16 OLED diagram.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 214 KiB

BIN
docs/Wiring/Crius CO-16 OLED modifications.jpg
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 83 KiB

BIN
docs/Wiring/PPMRSSI conditioning.pdf
View file

Binary file not shown.

BIN
docs/Wiring/blackbox-installation-1.jpg
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 194 KiB

BIN
docs/assets/cleanflight/cleanflight-icon_128.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 6.2 KiB

BIN
docs/assets/cleanflight/cleanflight-logo-light-wide-1-240px-transparent.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 2.7 KiB

BIN
docs/assets/cleanflight/cleanflight-logo-light-wide-1-240px.jpg
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 4.3 KiB

131
docs/assets/cleanflight/cleanflight-logo-light-wide-1.svg
View file

File diff suppressed because one or more lines are too long
Side by side

Before

Width:  |  Height:  |  Size: 14 KiB

BIN
docs/assets/images/StickPositions.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 104 KiB

805
docs/assets/images/StickPositions.svg
View file

@ -1,805 +0,0 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="2478.5964mm"
height="1086.9835mm"
viewBox="0 0 8782.4284 3851.5164"
id="svg2"
version="1.1"
inkscape:version="0.91 r13725"
sodipodi:docname="StickPositions.svg"
inkscape:export-filename="C:\Users\stuphi\Dropbox\projects\quad\StickPositions.png"
inkscape:export-xdpi="74.996788"
inkscape:export-ydpi="74.996788">
<defs
id="defs4" />
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="0.08"
inkscape:cx="2990.2403"
inkscape:cy="3041.654"
inkscape:document-units="px"
inkscape:current-layer="g4157"
showgrid="false"
inkscape:window-width="1920"
inkscape:window-height="1137"
inkscape:window-x="-8"
inkscape:window-y="-8"
inkscape:window-maximized="1"
fit-margin-top="1"
fit-margin-left="1"
fit-margin-right="1"
fit-margin-bottom="1"
units="mm"
showborder="true" />
<metadata
id="metadata7">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title></dc:title>
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:label="Frame"
inkscape:groupmode="layer"
id="layer1"
transform="translate(2203.3186,1653.7717)"
style="display:inline" />
<g
inkscape:groupmode="layer"
id="layer2"
inkscape:label="StickCentre"
style="display:inline"
transform="translate(2203.3186,1962.0394)" />
<g
inkscape:groupmode="layer"
id="layer3"
inkscape:label="StickDown"
style="display:inline"
transform="translate(2203.3186,1962.0394)" />
<g
style="display:inline"
inkscape:label="StickDownLeft"
id="g4169"
inkscape:groupmode="layer"
transform="translate(2203.3186,1962.0394)" />
<g
inkscape:groupmode="layer"
id="g4173"
inkscape:label="StickDownRight"
style="display:inline"
transform="translate(2203.3186,1962.0394)" />
<g
style="display:inline"
inkscape:label="StickUpRight"
id="g4177"
inkscape:groupmode="layer"
transform="translate(2203.3186,1962.0394)" />
<g
inkscape:groupmode="layer"
id="g4181"
inkscape:label="StickUpLeft"
style="display:inline"
transform="translate(2203.3186,1962.0394)" />
<g
style="display:inline"
inkscape:label="StickRight"
id="g4161"
inkscape:groupmode="layer"
transform="translate(2203.3186,1962.0394)" />
<g
inkscape:groupmode="layer"
id="g4165"
inkscape:label="StickLeft"
style="display:inline"
transform="translate(2203.3186,1962.0394)" />
<g
inkscape:label="StickUp"
id="g4157"
inkscape:groupmode="layer"
style="display:inline"
transform="translate(2203.3186,1962.0394)">
<rect
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="rect4136"
width="288.94339"
height="288.94339"
x="708.38544"
y="-1390.3773"
ry="0" />
<path
inkscape:transform-center-x="-73.935657"
inkscape:transform-center-y="73.935654"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 948.22718,-1104.1681 c 7.47613,7.4761 23.9146,3.1588 36.71634,-9.6429 12.80173,-12.8017 17.11898,-29.2402 9.64285,-36.7163 -7.47612,-7.4762 -126.05745,-105.3018 -138.85919,-92.5 -12.80175,12.8017 85.02386,131.383 92.5,138.8592 z"
id="path4175"
inkscape:connector-curvature="0"
sodipodi:nodetypes="sssss" />
<rect
ry="0"
y="-1390.3773"
x="1114.0997"
height="288.94339"
width="288.94339"
id="rect4208"
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<circle
r="31.819805"
cy="-1245.9056"
cx="1258.5714"
id="circle4210"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:10;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:286.5987854px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="486.66803"
y="-1140.8967"
id="text4574"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
x="486.668"
y="-1140.8967"
id="tspan4578"
style="text-align:end;text-anchor:end">Arm</tspan></text>
<rect
ry="0"
y="-969.96918"
x="708.38544"
height="288.94339"
width="288.94339"
id="rect4615"
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<path
inkscape:transform-center-x="73.935653"
inkscape:transform-center-y="73.935654"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 756.60309,-683.75996 c -7.47613,7.47613 -23.9146,3.15888 -36.71634,-9.64286 -12.80173,-12.80174 -17.11899,-29.2402 -9.64285,-36.71634 7.47612,-7.47614 126.05745,-105.30174 138.85919,-92.5 12.80175,12.80174 -85.02386,131.38307 -92.5,138.8592 z"
id="path4621"
inkscape:connector-curvature="0"
sodipodi:nodetypes="sssss" />
<rect
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="rect4637"
width="288.94339"
height="288.94339"
x="1114.0997"
y="-969.96918"
ry="0" />
<circle
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:10;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="circle4639"
cx="1258.5714"
cy="-825.4975"
r="31.819805" />
<text
sodipodi:linespacing="125%"
id="text4657"
y="-720.48853"
x="486.66803"
style="font-style:normal;font-weight:normal;font-size:286.5987854px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
xml:space="preserve"><tspan
style="text-align:end;text-anchor:end"
id="tspan4659"
y="-720.48853"
x="486.66803"
sodipodi:role="line">Disarm</tspan></text>
<rect
ry="0"
y="-549.56104"
x="708.38544"
height="288.94339"
width="288.94339"
id="rect4667"
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<path
inkscape:transform-center-x="73.935653"
inkscape:transform-center-y="73.935654"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 756.60309,-263.35179 c -7.47613,7.47613 -23.9146,3.15888 -36.71634,-9.64286 -12.80173,-12.80174 -17.11899,-29.2402 -9.64285,-36.71634 7.47612,-7.47614 126.05745,-105.30174 138.85919,-92.5 12.80175,12.80174 -85.02386,131.38307 -92.5,138.8592 z"
id="path4673"
inkscape:connector-curvature="0"
sodipodi:nodetypes="sssss" />
<rect
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="rect4689"
width="288.94339"
height="288.94339"
x="1114.0997"
y="-549.56104"
ry="0" />
<path
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 1090.881,-372.67398 c -10.5728,0 -19.1438,-14.67651 -19.1438,-32.7809 0,-18.10439 8.571,-32.7809 19.1438,-32.7809 10.5729,-1e-5 163.5957,14.6765 163.5957,32.7809 0,18.1044 -153.0228,32.78091 -163.5957,32.7809 z"
id="path4705"
inkscape:connector-curvature="0"
sodipodi:nodetypes="sssss"
inkscape:transform-center-x="94.95434"
inkscape:transform-center-y="0.5050695" />
<text
sodipodi:linespacing="125%"
id="text4709"
y="-300.08038"
x="486.66803"
style="font-style:normal;font-weight:normal;font-size:286.5987854px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
xml:space="preserve"><tspan
style="text-align:end;text-anchor:end"
id="tspan4711"
y="-300.08038"
x="486.668"
sodipodi:role="line">Profile 1</tspan></text>
<rect
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="rect4719"
width="288.94339"
height="288.94339"
x="708.38544"
y="-129.15286"
ry="0" />
<path
sodipodi:nodetypes="sssss"
inkscape:connector-curvature="0"
id="path4725"
d="m 756.60309,157.05638 c -7.47613,7.47613 -23.9146,3.15888 -36.71634,-9.64286 -12.80173,-12.80174 -17.11899,-29.2402 -9.64285,-36.71634 7.47612,-7.47614 126.05745,-105.30174 138.85919,-92.5 12.80175,12.80174 -85.02386,131.38307 -92.5,138.8592 z"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
inkscape:transform-center-y="73.935654"
inkscape:transform-center-x="73.935653" />
<rect
ry="0"
y="-129.15286"
x="1114.0997"
height="288.94339"
width="288.94339"
id="rect4741"
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<path
style="opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 1291.3523,-149.39445 c 0,-10.57285 -14.6765,-19.14384 -32.7809,-19.14384 -18.1043,0 -32.7809,8.57099 -32.7809,19.14384 0,10.57285 14.6765,163.59566 32.7809,163.59566 18.1044,0 32.781,-153.02281 32.7809,-163.59566 z"
id="path4759"
inkscape:connector-curvature="0"
sodipodi:nodetypes="sssss" />
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:286.5987854px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="486.66803"
y="120.3278"
id="text4761"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
x="486.668"
y="120.3278"
id="tspan4763"
style="text-align:end;text-anchor:end">Profile 2</tspan></text>
<rect
ry="0"
y="291.25531"
x="708.38544"
height="288.94339"
width="288.94339"
id="rect4771"
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<path
inkscape:transform-center-x="73.935653"
inkscape:transform-center-y="73.935654"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 756.60309,577.46454 c -7.47613,7.47613 -23.9146,3.15888 -36.71634,-9.64286 -12.80173,-12.80174 -17.11899,-29.2402 -9.64285,-36.71634 7.47612,-7.47614 126.05745,-105.30174 138.85919,-92.5 12.80175,12.80174 -85.02386,131.38307 -92.5,138.8592 z"
id="path4777"
inkscape:connector-curvature="0"
sodipodi:nodetypes="sssss" />
<rect
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="rect4793"
width="288.94339"
height="288.94339"
x="1114.0997"
y="291.25531"
ry="0" />
<path
sodipodi:nodetypes="sssss"
inkscape:connector-curvature="0"
id="path4807"
d="m 1425.2415,403.08564 c 10.5729,0 19.1439,14.67651 19.1439,32.7809 0,18.10439 -8.571,32.7809 -19.1439,32.7809 -10.5728,10e-6 -163.5957,-14.6765 -163.5957,-32.7809 0,-18.1044 153.0229,-32.78091 163.5957,-32.7809 z"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<text
sodipodi:linespacing="125%"
id="text4813"
y="540.73602"
x="486.66803"
style="font-style:normal;font-weight:normal;font-size:286.5987854px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
xml:space="preserve"><tspan
style="text-align:end;text-anchor:end"
id="tspan4815"
y="540.73602"
x="486.668"
sodipodi:role="line">Profile 3</tspan></text>
<rect
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="rect4823"
width="288.94339"
height="288.94339"
x="708.38544"
y="711.66351"
ry="0" />
<path
sodipodi:nodetypes="sssss"
inkscape:connector-curvature="0"
id="path4829"
d="m 756.60309,997.87274 c -7.47613,7.47616 -23.9146,3.15886 -36.71634,-9.64286 -12.80173,-12.80174 -17.11899,-29.2402 -9.64285,-36.71634 7.47612,-7.47614 126.05745,-105.30174 138.85919,-92.5 12.80175,12.80174 -85.02386,131.38307 -92.5,138.8592 z"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
inkscape:transform-center-y="73.935654"
inkscape:transform-center-x="73.935653" />
<rect
ry="0"
y="711.66351"
x="1114.0997"
height="288.94339"
width="288.94339"
id="rect4845"
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<path
sodipodi:nodetypes="sssss"
inkscape:connector-curvature="0"
id="path4849"
d="m 1291.3523,1021.9347 c 0,10.5728 -14.6765,19.1438 -32.7809,19.1438 -18.1043,0 -32.7809,-8.571 -32.7809,-19.1438 0,-10.5729 14.6765,-163.5957 32.7809,-163.5957 18.1044,0 32.781,153.0228 32.7809,163.5957 z"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:286.5987854px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="486.66803"
y="961.14417"
id="text4865"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
x="486.66791"
y="961.14417"
id="tspan4867"
style="text-align:end;text-anchor:end">Calibrate Gyro</tspan></text>
<rect
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="rect4875"
width="288.94339"
height="288.94339"
x="708.38544"
y="1132.0717"
ry="0" />
<path
inkscape:transform-center-x="73.935669"
inkscape:transform-center-y="-73.935654"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 757.10817,1133.9385 c -7.47613,-7.4762 -23.9146,-3.1589 -36.71634,9.6428 -12.80173,12.8018 -17.11899,29.2402 -9.64285,36.7164 7.47612,7.4761 126.05745,105.3017 138.85919,92.5 12.80175,-12.8018 -85.02386,-131.3831 -92.5,-138.8592 z"
id="path4887"
inkscape:connector-curvature="0"
sodipodi:nodetypes="sssss" />
<rect
ry="0"
y="1132.0717"
x="1114.0997"
height="288.94339"
width="288.94339"
id="rect4897"
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<path
sodipodi:nodetypes="sssss"
inkscape:connector-curvature="0"
id="path4901"
d="m 1291.3523,1442.3429 c 0,10.5728 -14.6765,19.1438 -32.7809,19.1438 -18.1043,0 -32.7809,-8.571 -32.7809,-19.1438 0,-10.5729 14.6765,-163.5957 32.7809,-163.5957 18.1044,0 32.781,153.0228 32.7809,163.5957 z"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:286.5987854px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="486.66803"
y="1381.5524"
id="text4917"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
x="486.66803"
y="1381.5524"
id="tspan4919"
style="text-align:end;text-anchor:end">Calibrate Acc</tspan></text>
<rect
ry="0"
y="1552.4799"
x="708.38544"
height="288.94339"
width="288.94339"
id="rect4927"
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<path
inkscape:transform-center-x="-73.935665"
inkscape:transform-center-y="-73.935654"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 948.22718,1554.3467 c 7.47613,-7.4762 23.9146,-3.1589 36.71634,9.6428 12.80173,12.8018 17.11898,29.2402 9.64285,36.7164 -7.47612,7.4761 -126.05745,105.3017 -138.85919,92.5 -12.80175,-12.8018 85.02386,-131.3831 92.5,-138.8592 z"
id="path4937"
inkscape:connector-curvature="0"
sodipodi:nodetypes="sssss" />
<rect
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="rect4949"
width="288.94339"
height="288.94339"
x="1114.0997"
y="1552.4799"
ry="0" />
<path
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 1291.3523,1862.7511 c 0,10.5728 -14.6765,19.1438 -32.7809,19.1438 -18.1043,0 -32.7809,-8.571 -32.7809,-19.1438 0,-10.5729 14.6765,-163.5957 32.7809,-163.5957 18.1044,0 32.781,153.0228 32.7809,163.5957 z"
id="path4953"
inkscape:connector-curvature="0"
sodipodi:nodetypes="sssss" />
<text
sodipodi:linespacing="125%"
id="text4969"
y="1801.9606"
x="486.66803"
style="font-style:normal;font-weight:normal;font-size:286.5987854px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
xml:space="preserve"><tspan
style="text-align:end;text-anchor:end"
id="tspan4971"
y="1801.9606"
x="486.66791"
sodipodi:role="line">Calibrate Compass</tspan></text>
<rect
ry="0"
y="-1390.3773"
x="5835.5283"
height="288.94339"
width="288.94339"
id="rect5607"
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<path
inkscape:transform-center-x="73.935653"
inkscape:transform-center-y="73.935654"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 5883.7461,-1104.1681 c -7.4762,7.4761 -23.9146,3.1588 -36.7164,-9.6429 -12.8017,-12.8017 -17.119,-29.2402 -9.6428,-36.7163 7.4761,-7.4762 126.0574,-105.3018 138.8592,-92.5 12.8017,12.8017 -85.0239,131.383 -92.5,138.8592 z"
id="path5613"
inkscape:connector-curvature="0"
sodipodi:nodetypes="sssss" />
<rect
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="rect5629"
width="288.94339"
height="288.94339"
x="6241.2427"
y="-1390.3773"
ry="0" />
<path
sodipodi:nodetypes="sssss"
inkscape:connector-curvature="0"
id="path5639"
d="m 6481.0845,-1388.5106 c 7.4761,-7.4762 23.9146,-3.1589 36.7163,9.6428 12.8017,12.8018 17.119,29.2402 9.6428,36.7164 -7.4761,7.4761 -126.0574,105.3017 -138.8591,92.5 -12.8018,-12.8018 85.0238,-131.3831 92.5,-138.8592 z"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
inkscape:transform-center-y="-73.935654"
inkscape:transform-center-x="-73.935665" />
<text
sodipodi:linespacing="125%"
id="text5649"
y="-1140.8967"
x="5613.811"
style="font-style:normal;font-weight:normal;font-size:286.5987854px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
xml:space="preserve"><tspan
style="text-align:end;text-anchor:end"
id="tspan5651"
y="-1140.8967"
x="5613.811"
sodipodi:role="line">In-flight Calibration Controls</tspan></text>
<rect
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="rect5659"
width="288.94339"
height="288.94339"
x="5835.5283"
y="-969.96918"
ry="0" />
<path
sodipodi:nodetypes="sssss"
inkscape:connector-curvature="0"
id="path5677"
d="m 6012.781,-990.21079 c 0,-10.57281 -14.6765,-19.14381 -32.7809,-19.14381 -18.1044,0 -32.7809,8.571 -32.7809,19.14381 0,10.57285 14.6765,163.59566 32.7809,163.59566 18.1044,0 32.7809,-153.02281 32.7809,-163.59566 z"
style="opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<rect
ry="0"
y="-969.96918"
x="6241.2427"
height="288.94339"
width="288.94339"
id="rect5681"
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<path
inkscape:transform-center-y="0.5050695"
inkscape:transform-center-x="94.95434"
sodipodi:nodetypes="sssss"
inkscape:connector-curvature="0"
id="path5697"
d="m 6218.024,-793.08215 c -10.5729,0 -19.1438,-14.67651 -19.1438,-32.7809 0,-18.10439 8.5709,-32.7809 19.1438,-32.7809 10.5728,-10e-6 163.5957,14.6765 163.5957,32.7809 0,18.1044 -153.0229,32.78091 -163.5957,32.7809 z"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:286.5987854px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="5613.811"
y="-720.48853"
id="text5701"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
x="5613.811"
y="-720.48853"
id="tspan5703"
style="text-align:end;text-anchor:end">Trim Acc Left</tspan></text>
<rect
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="rect5711"
width="288.94339"
height="288.94339"
x="5835.5283"
y="-549.56104"
ry="0" />
<path
sodipodi:nodetypes="sssss"
inkscape:connector-curvature="0"
id="path5729"
d="m 6012.781,-569.80262 c 0,-10.57285 -14.6765,-19.14384 -32.7809,-19.14384 -18.1044,0 -32.7809,8.57099 -32.7809,19.14384 0,10.57285 14.6765,163.59566 32.7809,163.59566 18.1044,0 32.7809,-153.02281 32.7809,-163.59566 z"
style="opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<rect
ry="0"
y="-549.56104"
x="6241.2427"
height="288.94339"
width="288.94339"
id="rect5733"
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<path
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 6552.3845,-437.73069 c 10.5728,0 19.1438,14.67651 19.1438,32.7809 0,18.10439 -8.571,32.7809 -19.1438,32.7809 -10.5729,10e-6 -163.5957,-14.6765 -163.5957,-32.7809 0,-18.1044 153.0228,-32.78091 163.5957,-32.7809 z"
id="path5747"
inkscape:connector-curvature="0"
sodipodi:nodetypes="sssss" />
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:286.5987854px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="5613.811"
y="-300.08038"
id="text5753"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
x="5613.811"
y="-300.08038"
id="tspan5755"
style="text-align:end;text-anchor:end">Trim Acc Right</tspan></text>
<rect
ry="0"
y="-129.15286"
x="5835.5283"
height="288.94339"
width="288.94339"
id="rect5763"
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<path
style="opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 6012.781,-149.39445 c 0,-10.57285 -14.6765,-19.14384 -32.7809,-19.14384 -18.1044,0 -32.7809,8.57099 -32.7809,19.14384 0,10.57285 14.6765,163.59566 32.7809,163.59566 18.1044,0 32.7809,-153.02281 32.7809,-163.59566 z"
id="path5781"
inkscape:connector-curvature="0"
sodipodi:nodetypes="sssss" />
<rect
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="rect5785"
width="288.94339"
height="288.94339"
x="6241.2427"
y="-129.15286"
ry="0" />
<path
sodipodi:nodetypes="sssss"
inkscape:connector-curvature="0"
id="path5803"
d="m 6418.4953,-149.39445 c 0,-10.57285 -14.6765,-19.14384 -32.7809,-19.14384 -18.1044,0 -32.7809,8.57099 -32.7809,19.14384 0,10.57285 14.6765,163.59566 32.7809,163.59566 18.1044,0 32.7809,-153.02281 32.7809,-163.59566 z"
style="opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<text
sodipodi:linespacing="125%"
id="text5805"
y="120.3278"
x="5613.811"
style="font-style:normal;font-weight:normal;font-size:286.5987854px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
xml:space="preserve"><tspan
style="text-align:end;text-anchor:end"
id="tspan5807"
y="120.3278"
x="5613.811"
sodipodi:role="line">Trim Acc Forwards</tspan></text>
<rect
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="rect5815"
width="288.94339"
height="288.94339"
x="5835.5283"
y="291.25531"
ry="0" />
<path
sodipodi:nodetypes="sssss"
inkscape:connector-curvature="0"
id="path5833"
d="m 6012.781,271.01371 c 0,-10.57285 -14.6765,-19.14384 -32.7809,-19.14384 -18.1044,0 -32.7809,8.57099 -32.7809,19.14384 0,10.57285 14.6765,163.59566 32.7809,163.59566 18.1044,0 32.7809,-153.02281 32.7809,-163.59566 z"
style="opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<rect
ry="0"
y="291.25531"
x="6241.2427"
height="288.94339"
width="288.94339"
id="rect5837"
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<path
sodipodi:nodetypes="sssss"
inkscape:connector-curvature="0"
id="path5841"
d="m 6418.4953,601.52646 c 0,10.57285 -14.6765,19.14384 -32.7809,19.14384 -18.1044,0 -32.7809,-8.57099 -32.7809,-19.14384 0,-10.57285 14.6765,-163.59566 32.7809,-163.59566 18.1044,0 32.7809,153.02281 32.7809,163.59566 z"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:286.5987854px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="5613.811"
y="540.73602"
id="text5857"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
x="5613.811"
y="540.73602"
id="tspan5859"
style="text-align:end;text-anchor:end">Trim Acc Backwards</tspan></text>
<rect
ry="0"
y="711.66351"
x="5835.5283"
height="288.94339"
width="288.94339"
id="rect5867"
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<path
sodipodi:nodetypes="sssss"
inkscape:connector-curvature="0"
id="path5871"
d="m 6012.781,1021.9347 c 0,10.5728 -14.6765,19.1438 -32.7809,19.1438 -18.1044,0 -32.7809,-8.571 -32.7809,-19.1438 0,-10.5729 14.6765,-163.5957 32.7809,-163.5957 18.1044,0 32.7809,153.0228 32.7809,163.5957 z"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<rect
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="rect5889"
width="288.94339"
height="288.94339"
x="6241.2427"
y="711.66351"
ry="0" />
<path
inkscape:transform-center-x="73.935669"
inkscape:transform-center-y="-73.935654"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
d="m 6289.9654,713.53025 c -7.4761,-7.47613 -23.9146,-3.15888 -36.7163,9.64286 -12.8017,12.80174 -17.119,29.2402 -9.6428,36.71634 7.4761,7.47614 126.0574,105.30174 138.8591,92.5 12.8018,-12.80174 -85.0238,-131.38307 -92.5,-138.8592 z"
id="path5901"
inkscape:connector-curvature="0"
sodipodi:nodetypes="sssss" />
<text
sodipodi:linespacing="125%"
id="text5909"
y="961.14417"
x="5613.811"
style="font-style:normal;font-weight:normal;font-size:286.5987854px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
xml:space="preserve"><tspan
style="text-align:end;text-anchor:end"
id="tspan5911"
y="961.14417"
x="5613.811"
sodipodi:role="line">Disable LCD Page Cycling</tspan></text>
<rect
ry="0"
y="1132.0717"
x="5835.5283"
height="288.94339"
width="288.94339"
id="rect5919"
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<path
sodipodi:nodetypes="sssss"
inkscape:connector-curvature="0"
id="path5923"
d="m 6012.781,1442.3429 c 0,10.5728 -14.6765,19.1438 -32.7809,19.1438 -18.1044,0 -32.7809,-8.571 -32.7809,-19.1438 0,-10.5729 14.6765,-163.5957 32.7809,-163.5957 18.1044,0 32.7809,153.0228 32.7809,163.5957 z"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<rect
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="rect5941"
width="288.94339"
height="288.94339"
x="6241.2427"
y="1132.0717"
ry="0" />
<path
sodipodi:nodetypes="sssss"
inkscape:connector-curvature="0"
id="path5951"
d="m 6481.0845,1133.9385 c 7.4761,-7.4762 23.9146,-3.1589 36.7163,9.6428 12.8017,12.8018 17.119,29.2402 9.6428,36.7164 -7.4761,7.4761 -126.0574,105.3017 -138.8591,92.5 -12.8018,-12.8018 85.0238,-131.3831 92.5,-138.8592 z"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
inkscape:transform-center-y="-73.935654"
inkscape:transform-center-x="-73.935665" />
<text
sodipodi:linespacing="125%"
id="text5961"
y="1381.5524"
x="5613.811"
style="font-style:normal;font-weight:normal;font-size:286.5987854px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
xml:space="preserve"><tspan
style="text-align:end;text-anchor:end"
id="tspan5963"
y="1381.5524"
x="5613.811"
sodipodi:role="line">Enable LCD Page Cycling</tspan></text>
<rect
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="rect5971"
width="288.94339"
height="288.94339"
x="5835.5283"
y="1552.4799"
ry="0" />
<path
sodipodi:nodetypes="sssss"
inkscape:connector-curvature="0"
id="path5977"
d="m 5883.7461,1838.6891 c -7.4762,7.4762 -23.9146,3.1589 -36.7164,-9.6428 -12.8017,-12.8018 -17.119,-29.2402 -9.6428,-36.7164 7.4761,-7.4761 126.0574,-105.3017 138.8592,-92.5 12.8017,12.8018 -85.0239,131.3831 -92.5,138.8592 z"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
inkscape:transform-center-y="73.935654"
inkscape:transform-center-x="73.935653" />
<rect
ry="0"
y="1552.4799"
x="6241.2427"
height="288.94339"
width="288.94339"
id="rect5993"
style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:#808080;stroke-width:11.05660725;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
<path
sodipodi:nodetypes="sssss"
inkscape:connector-curvature="0"
id="path6001"
d="m 6481.0845,1838.6891 c 7.4761,7.4762 23.9146,3.1589 36.7163,-9.6428 12.8017,-12.8018 17.119,-29.2402 9.6428,-36.7164 -7.4761,-7.4761 -126.0574,-105.3017 -138.8591,-92.5 -12.8018,12.8018 85.0238,131.3831 92.5,138.8592 z"
style="display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:8.07780743;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
inkscape:transform-center-y="73.935654"
inkscape:transform-center-x="-73.935657" />
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:286.5987854px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="5613.811"
y="1801.9606"
id="text6013"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
x="5613.811"
y="1801.9606"
id="tspan6015"
style="text-align:end;text-anchor:end">Save Setting</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:352.85842896px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
x="2179.2813"
y="-1690.4064"
id="text7907"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
x="2179.2813"
y="-1690.4064"
id="tspan7909"
style="text-align:center;text-anchor:middle">Mode 2 Stick Functions</tspan></text>
</g>
</svg>
Side by side

Before

Width:  |  Height:  |  Size: 40 KiB

BIN
docs/assets/images/bf_logo.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 36 KiB

BIN
docs/assets/images/blheli-bootloader.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 17 KiB

BIN
docs/assets/images/frsky_spi_rx_d_binding.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 2.9 MiB

BIN
docs/assets/images/frsky_spi_rx_mode.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 84 KiB

BIN
docs/assets/images/frsky_spi_rx_protocol.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 167 KiB

BIN
docs/assets/images/frsky_spi_rx_x_binding.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 3.1 MiB

BIN
docs/assets/images/integrate_smartport.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 12 KiB

BIN
docs/assets/images/serial1wire-cc3d-wiring.jpg
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 265 KiB

BIN
docs/assets/images/zadig-dfu.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 22 KiB

48
docs/boards/Board - AikonF4.md
View file

@ -1,48 +0,0 @@
# Aikon F4
## Description
FC with no PDB aimed at multi-rotor and fixed wing use, Aikon F4 features a carefully-chosen timer design which allowed to run 4-6 motors with burst DSHOT with maximum efficiency. On board are dedicated pads for ESC telemetry, VTX and camera control. Board also features an 11-pin connector for plug-and-play connection with Aikon AK32 4in1 ESC, providing voltage, current and ESC telemetry reading with no additional wires.
## MCU, Sensors and Features
### Hardware
- MCU: STM32F405
- IMU: ICM-20602
- Motor outputs: 4-6
- IMU Interrupt: Yes
- BARO: Optionally
- VCP: Yes
- Hardware UARTS: UART1 for SerialRX, UART3 for Inverted SmartPort, UART2 and UART4 available for general use
- Software serial: SOFTSERIAL1 for VTX control (shared with UART1TX), SOFTSERIAL2 for ESC telemetry (shared with UART4RX)
- OSD: Yes
- Blackbox: SPI 16MB
- PPM/LED_STRIP Shared: Yes
- Battery Voltage Sensor: Yes
- Integrated Voltage Regulator: Yes
- Buttons: Boot
### Features
UART3 inverter is controllable by software, you can use the SBUS pad for any unidirectional protocol by setting `serialrx_inverted` accordingly. There's also a solder-jumper to bypass the inverter and connecto UART3_RX to `DSMX` pad directly.
Software serial is preconfigured by default, all you have to do is enable SOFTSERIAL1 for VTX control and SOFTSERIAL2 for ESC sensor on the Ports tab in Configurator.
## Manufacturers and Distributors
https://www.aikon-electronics.com/
## Designers
AIKON Electronics
Avi Jang
## Maintainers
Andrey Mironov (@DieHertz)
## FAQ & Known Issues
* First revision has no diode protecting the 5V input on the 11-pin ESC connector, make sure to pull the 5V wire coming from our ESC in order to avoid two regulators fighting against each other
* First revision has RX4 (ESC Telemetry) and GND pad silkscreen swapped near motor outputs
![Aikon F4 top](images/aikon-f4-rev1-top.jpg)
![Aikon F4 bottom](images/aikon-f4-rev1-bottom.jpg)

45
docs/boards/Board - AlienFlight.md
View file

@ -1,45 +0,0 @@
# Board - AlienFlight (ALIENFLIGHTF1 and ALIENFLIGHTF3 target)
AlienWii is now AlienFlight. This target supports various variants of brushed and brusless flight controllers. The designs for them are released for public use at:
http://www.alienflight.com
All published designs are flight tested by various people. The intention here is to make this flight controllers available and enable skilled users or RC vendors to build this designs.
Here are the general hardware specifications for this boards:
- STM32F103CBT6 MCU (ALIENFLIGHTF1)
- STM32F303CCT6 MCU (ALIENFLIGHTF3)
- MPU6050/6500/9250 accelerometer/gyro(/mag) sensor unit
- The MPU sensor interrupt is connected to the MCU for all new F3 designs and enabled in the firmware
- 4-8 x 4.2A to 9.5A brushed ESCs, integrated, to run the strongest micro motors
- extra-wide traces on the PCB, for maximum power throughput
- USB port, integrated
- (*) serial connection for external DSM2/DSMX sat receiver (e.g. Spektrum SAT, OrangeRx R100, Lemon RX or Deltang Rx31)
- CPPM input
- ground and 3.3V for the receiver
- hardware bind plug for easy binding
- motor connections are at the corners for a clean look with reduced wiring
- small footprint
- direct operation from an single cell lipoly battery
- 3.3V LDO power regulator (older prototypes)
- 3.3V buck-boost power converter (all new versions)
- 5V buck-boost power converter for FPV (some versions)
- battery monitoring with an LED for buzzer functionality (actually for some ALIENFLIGHTF3 variants only)
(*) Spektrum Compatible DSM2 satellites are supported out of the box. DSMX sat will work with DSM2 protocol with default settings (DSM2, 11bit, 11ms is preset). This is chosen for maximum compatibility. For optimal connection it is recommended to adjust settings to match the capabilities of your transmitter and satellite receiver. If possible it is recommended to use the DSMX protocol since it is known as more reliable. Also to make use of additional channels you should adjust the following two parameters with the Cleanflight Configurator.
set serialrx_provider = 1 (0 for 1024bit, 1 for 2048bit)
set spektrum_sat_bind = 5
For more detail of the different bind modes please refer the [Spektrum Bind](Spektrum%20bind.md) document
Deltang receivers in serial mode will work like any other Spektrum satellite receiver (10bit, 22ms) only the bind process will be different.
The pin layout for the ALIENFLIGHTF1 is very similar to NAZE32 or the related clones (MW32, Flip32, etc.). The hardware bind pin is connected to pin 41 (PB5). The pin layout for the ALIENFLIGHTF3 is similar to Sparky. The hardware bind pin is connected to pin 25 (PB12). The new AlienFlightF3 V2 design have the sensor connected via SPI and some slightly different pin layout. All AlienFlight/AlienWii F3 layouts running the same firmware which takes care on the differences with an hardware detection.
The AlienFlight firmware will be built as target ALIENFLIGHTF1 or ALIENFLIGHTF3. The firmware image will come with alternative default settings which will give the user a plug and play experience. There is no computer needed to get this into the air with an small Quadcopter. An preconfigured custom mixer for an Octocopter is part of the default settings to allow clean straight wiring with the AlienFlight. The mixer can be activated with "mixer custom" in the CLI. To use the AlienFlight in an Hexa- or Octocopter or to do some more tuning. Additional configuration changes can be done as usual in the CLI or the Cleanflight configurator.
## Flashing the firmware
The firmware can be updated with the Cleanflight configurator as for any other target. All AlienFlight boards have an boot jumper which need to be closed for the initial flashing or for recovery from an broken firmware.

57
docs/boards/Board - ApexF7.md
View file

@ -1,57 +0,0 @@
# ApexF7
### Features
- STM32F722
- 16 MB of Flash
- USB-C
- Dual Gyro via SPI (MPU6000 + ICM20602)
- Barometer BMP280 via I2C
- VTX Power Switch
- 10V BEC for VTX and Camera
- CamControl
- OSD
- Bluetooth Connectivity via soldered module (active, when board isnt armed)
- WS2812 LED Output
- SmartAudio/Tramp
- Up to 6s Input
### Connections
| Function | SolderPad/SilkScreen | Rescource | MCU Pin | Notes |
|:-------------:|:--------------------:|:---------:|:------------:|:--------------------------------------:|
| SBUS | SBUS | RX1 | PA10 | No Inverter |
| DSM2 | TX1 | TX1 | PA9 | CLI serial_halfduplex = ON |
| SmartAudio | S/A | TX5 | PC12 | |
| F.PORT/S.PORT | F.P | TX3 | PC10 | No Inverter |
| ESC Telemetry | TLM | TX2 | PA2 | Halfduplex by default / on bottom side |
| Cam Control | CC | | PA8 | |
| Video Output | VTX | - | - | |
| Cam Input | CAM | - | - | |
| WS2812 | LED | LED_STRIP | PA15 | |
| BUZZER | BZ-/BZ+ | BEEPER | PB0 | |
| S1-S4 | M1-M4 | | PC8/B6/C9/B7 | Motor Outputs on bottom |
| UART4 | TX4/RX4 | TX4/RX4 | PA0/PA1 | |
| UART6 | TX6/RX6 | TX6/RX6 | PC6/PC7 | |
| VBAT in | BAT | - | - | 3S-6S input |
| Current | CURR | - | PC1 | on bottom |
| SDA | SDA | I2C1_SDA | PB9 | |
| SCL | SCL | I2C1_SCL | PB8 | |
### Picture
![front](images/APEXF7_small_front.png)
![back](images/APEXF7_small_back.png)

145
docs/boards/Board - CJMCU.md
View file

@ -1,145 +0,0 @@
# Board - CJMCU
The CJMCU is a tiny (80mm) board running a STM32F103, which contains a 3-Axis Compass (HMC5883L)
and an Accelerometer/Gyro (MPU6050).
This board does not have an onboard USB-Serial converter, so an external adapter is needed.
# Hardware revisions
| Revision | Notes |
| -------- | ----- |
| 1 | No boot jumper pads by LED1. Uses blue and red LEDs |
| 2 | Boot jumper pads presoldered with pins and a jumper by LED1. Uses green and red LEDs. |
Version 2 boards are supported from firmware v1.4.0 onwards, do NOT flash earlier versions to version 2 boards.
# Pins
## RX Connections
| Pin Label | Description |
| --------- | ------------------------ |
| PA0 | RC Channel 1 |
| PA1 | RC Channel 2 |
| PA2 | RC Channel 3 / USART2 TX |
| PA3 | RC Channel 4 / USART2 RX |
| VCC | Power (See note) |
| GND | Ground |
NOTE: The VCC RX Pin is not regulated and will supply what ever voltage is provided to the board, this will mean it'll provide 5v if a 5v serial connection is used. Be careful if you are using a voltage sensitive RX. A regulated 3.3v supply can be found on the top pin of column 1, just below the RX GND pin.
## Serial Connections
USART1 (along with power) is on the following pins.
| Pin Label | Description |
| --------- | --------------- |
| TX1 | UART1 TX |
| RX1 | UART2 RX |
| GND | Ground |
| 3V3 | Power +3.3v |
| 5V | Power +5v |
USART2 is the following pins.
| Pin Label | Description |
| --------- | ----------- |
| PA2 | USART2 TX |
| PA3 | USART2 RX |
## Power Connections
| Pin Label | Description |
| --------- | ----------------------- |
| Power + | Power - 1 Cell 3.7v Max |
| Power - | Ground |
## Motor Connections
In standard QUADX configuration, the motors are mapped:
| Cleanflight | CJMCU |
| ----------- | ------ |
| Motor 1 | Motor3 |
| Motor 2 | Motor2 |
| Motor 3 | Motor4 |
| Motor 4 | Motor1 |
It is therefore simplest to wire the motors:
* Motor 1 -> Clockwise
* Motor 2 -> Anti-Clockwise
* Motor 3 -> Clockwise
* Motor 4 -> Anti-Clockwise
If you are using the Hubsan x4/Ladybird motors, clockwise are Blue (GND) / Red (VCC) wires, anticlockwise
are Black (GND) / White (VCC).
i.e. there is one wire on each motor out of the standard RED/BLACK VCC/GND polarity colors that can be used to identify polarity.
If you have wired as above, Motor1/Motor2 on the board will be forward.
# Connecting a Serial-USB Adapter
You will need a USB -> Serial UART adapter. Connect:
| Adapter | CJMCU |
| ----------------- | -------------------------- |
| Either 3.3v OR 5v | The correct 3.3v OR 5v pin |
| RX | TX |
| TX | RX |
When first connected this should power up the board, and will be in bootloader mode. If this does not happen, check
the charge switch is set to POW.
After the flashing process has been completed, this will allow access via the cleanflight configurator to change
settings or flash a new firmware.
WARNING: If the motors are connected and the board boots into the bootloader, they will start
to spin after around 20 seconds, it is recommended not to connect the motors until the board
is flashed.
# Flashing
To flash the board:
* Open Cleanflight Configurator
* Choose the latest CJMCU firmware from the list.
* Select "Load Firmware [Online]" and wait for the firmware to download.
* Tick "No Reboot Sequence" and "Full Chip Erase"
* Connect the USB->Serial adapter to the board
* Select the USB-UART adapter from the top left box
* Click "Flash Firmware"
* You should see "Programming: SUCCESSFUL" in the log box
* Click "Connect" -> This should open the "Initial Setup" tab and you should see sensor data from the quad shown
* Unplug the quad and short the 2 "BOOT0" pins. Revision 1 boards require this to be soldered, revision 2 boards can connect the included jumper to the two pre-soldered pins - This prevents the board from going into bootloader mode on next
boot, if anything goes wrong, simply disconnect these two pins and the bootloader will start, allowing you to reflash. You cannot
overwrite the bootloader.
# Charging
The CJMCU has on it a TP4056 Lithium battery charging IC that can charge a 1S battery at 1A using a provided 5v supply attached to the 5v serial pin.
To charge an attached battery:
* Set the power switch to OFF
* Set the charge switch to CHG
* Plug in a 1S battery to the battery pins
* Plug in a 5v supply to the 5v serial pins
The charger will finish when either the battery reaches 4.2v, or the battery's voltage is greater than the charger's input voltage.
The two nearby LEDs will show the status of charging:
| Status | Green LED | Red LED |
|--------------------|-----------|-----------|
| Charging | On | Off |
| Finished | Off | On |
| 5v not connected | Off | Off |
| Batt not connected | Flashing | On |
# Helpful Hints
* If you are only using a 4 channel RX, in the auxiliary configuration tab, you can add a "Horizon" mode range around 1500
for one of the the AUX channels which will result in it being always on
* Enabling the feature MOTOR_STOP helps with crashes so it doesn't try to keep spinning on its back
* When the power runs low, the quad will start jumping around a bit, if the flight behaviour seems strange, check your batteries charge

12
docs/boards/Board - CLRACINGF7.md
View file

@ -1,12 +0,0 @@
MCU: STM32F722RE
IMU: ICM-20602
IMU Interrupt: yes
BARO: NO
VCP: YES
Hardware UARTS: 6 uarts
OSD: uses a AB7456 chip
Blackbox: flash Chip
PPM/UART NOT Shared: YES
Battery Voltage Sensor: 10:1
Current sensor: from 4 in 1 socket
Integrated Voltage Regulator: 1.5A 5v/v1 2A 5v/v2

95
docs/boards/Board - ChebuzzF3.md
View file

@ -1,95 +0,0 @@
# Board - ChebuzzF3
The ChebuzzF3 is a daugter board which connects to the bottom of an STM32F3Discovery board and provides pin headers and ports for various FC connections.
All connections were traced using a multimeter and then verified against the TauLabs source code using the revision linked.
https://github.com/TauLabs/TauLabs/blob/816760dec2a20db7fb9ec1a505add240e696c31f/flight/targets/flyingf3/board-info/board_hw_defs.c
## Connections
Board orientation.
These notes assume that when the board is placed with the header pins facing up, the bottom right of the board is next to the 8 sets of INPUT pin headers.
Inner means between the two rows of header sockets, outer means between the left/right board edges and the header sockets.
### SPI2 / External SPI
sclk GPIOB 13
miso GPIOB 14
mosi GPIOB 15
There are 4 pins, labelled CS1-4 next to a label that reads Ext SPI. The 3rd pin is connected to the flash chip on
the bottom right inner of the board. The other pins on the flash chip are wired up to PB3/4/5
### SPI3 / SPI
sclk GPIOB 3
miso GPIOB 4
mosi GPIOB 5
ssel 1 GPIOB 10 / Ext SPI CS1
ssel 2 GPIOB 11 / Ext SPI CS2
ssel 3 GPIOB 12 / Ext SPI CS3 - wired up to Slave Select of M25P16 15MBitFlash chip
ssel 4 GPIOB 13 / Ext SPI CS4 - not usable since it is used for SPI2 sclk
### RC Input
INPUT
PA8 / CH1 - TIM1_CH1
PB8 / CH2 - TIM16_CH1
PB9 / CH3 - TIM17_CH1
PC6 / CH4 - TIM8_CH1
PC7 / CH5 - TIM8_CH2
PC8 / CH6 - TIM8_CH3
PF9 / CH7 - TIM15_CH1
PF10 / CH8 - TIM15_CH2
### PWM Outputs
OUTPUT
PD12 / CH1 - TIM4_CH1
PD13 / CH2 - TIM4_CH2
PD14 / CH3 - TIM4_CH3
PD15 / CH4 - TIM4_CH4
PA1 / CH5 - TIM2_CH2
PA2 / CH6 - TIM2_CH3
PA3 / CH7 - TIM2_CH4
PB0 / CH8 - TIM3_CH3
PB1 / CH9 - TIM3_CH4
PA4 / CH10 - TIM3_CH2
### Other ports
There is space for a MS5611 pressure sensor at the top left inner of the board.
There is an I2C socket on the left outer of the board which connects to a PCA9306 I2C level shifter directly opposite (inner).
The PCA9306 is not populated on some boards and thus the I2C socket is unusable.
There is a CAN socket on the top right outer of the board which connects to a MAX3015 CAN Tranceiver.
The MAX3015 is not populated on some boards and thus the CAN socket is unusable.
There are some solder pads labelled Ext 1-4 at the top right inner of the board.
GPIOE 6 / PE6 / Ext 1
GPIOD 3 / PD3 / Ext 2
GPIOD 4 / PD4 / Ext 3
GPIOB 3 / PB3 / Ext 4
There are some solder pads labelled ADC0-3 & Diff Press at the top left inner of the board
They are connected to the ADC socket at the top left outer of the board
PC3 / Diff Press - ADC12_IN9 (Differential Pressure)
PC2 / ADC2 - ADC12_IN8
PC1 / ADC1 - ADC12_IN7
PC0 / ADC0 - ADC12_IN6
There is space for a MPXV5004/MPVZ5004 differential pressure sensor, if populated it's analog pin connects to PC3.
There are sockets for 5 UARTs labelled USART1-5.
There is a socket labelled RX_IN.
GPIOD 2 / PD2 / RX_IN

126
docs/boards/Board - ColibriRace.md
View file

@ -1,126 +0,0 @@
# Board - TBS Colibri RACE
The Colibri RACE is a STM32F3 based flight control designed specifically to work with the TBS POWERCUBE multi rotor stack.
## Hardware Features:
* STM32F303 based chipset for ultimate performance
* PPM, SBUS, DSM, DSMX input (5V and 3.3V provided over internal BUS). No inverters or hacks needed.
* 6 PWM ESC output channels (autoconnect, internal BUS)
* RGB LED strip support incl. power management
* Extension port for GPS / external compass / pressure sensor
* UART port for peripherals (Blackbox, FrSky telemetry etc.)
* Choose between plug & play sockets or solder pads for R/C and buzzer
* 5V buzzer output
* MPU6500 new generation accelerometer/gyro
* 3x status LED (DCDC pwr/ 3.3V pwr/ status)
* Battery monitoring for 12V, 5V and VBat supply
* Size: 36mmx36mm (30.5mm standard raster)
* Weight: 4.4g
For more details please visit:
http://www.team-blacksheep.com/powercube
## Serial Ports
| Value | Identifier | Board Markings | Notes |
| ----- | ------------ | -------------- | ------------------------------------------|
| 1 | VCP | USB PORT | Main Port For MSP |
| 2 | USART1 | FREE PORT | PC4 and PC5(Tx and Rx respectively) |
| 3 | USART2 | PPM Serial | PA15 |
| 4 | USART3 | GPS PORT | PB10 and PB11(Tx and Rx respectively) |
## Pinouts
Full pinout details are available in the manual, here:
http://www.team-blacksheep.com/colibri_race
### SWD - ICSP
| Pin | Function | Notes |
| --- | -------------- | -------------------------------------------- |
| 1 | VCC_IN | 3.3 Volt |
| 2 | SWDIO | |
| 3 | nRESET | |
| 4 | SWCLK | |
| 5 | Ground | |
| 6 | SWO/TDO | |
### Internal Bus
| Pin | Function | Notes |
| --- | -------------- | -------------------------------------------- |
| 1 | PWM1 | MOTOR 1 |
| 2 | PWM2 | MOTOR 2 |
| 3 | PWM3 | MOTOR 3 |
| 4 | PWM4 | MOTOR 4 |
| 5 | PWM5 | MOTOR 5 (For Y6 or Hex X) |
| 6 | PWM6 | MOTOR 6 (For Y6 or Hex X) |
| 7 | BST SDA | Use For TBS CorePro Control Device |
| 8 | BST SCL | Use For TBS CorePro Control Device |
| 9 | PWM7 | Can be a normal GPIO (PA1) or PWM |
| 10 | PWM8 | Can be a normal GPIO (PA2) or PWM |
| 11 | 12.2V DCDC | If 12v is detected, the Blue LED will turn on|
| 12 | 5.1V DCDC | Voltage for MCU |
### Servo
| Pin | Function | Notes |
| --- | -------------- | -------------------------------------------- |
| 1 | Ground | |
| 2 | VCC_OUT | 5.1 Volt output to LCD Strip |
| 3 | PWM Servo | PB14 - PWM10 |
### IO_1 - LED Strip
| Pin | Function | Notes |
| --- | ----------------- | -------------------------------------------- |
| 1 | LED_STRIP | Enable `feature LED_STRIP` |
| 2 | VCC_OUT | 5.1 Volt output to LCD Strip |
| 3 | Ground | |
### IO_2 - Sensor Interface
| Pin | Function | Notes |
| --- | ----------------- | -------------------------------------------- |
| 1 | VCC_OUT | 4.7 Volt output to the device |
| 2 | Ground | |
| 3 | UART3 TX | GPS |
| 4 | UART3 RX | GPS |
| 5 | SDA | mag, pressure, or other i2c device |
| 6 | SCL | mag, pressure, or other i2c device |
### IO_3 - RC input
IO_3 is used for RX_PPM/RX_SERIAL. Under the `PORT` tab, set RX_SERIAL to UART2 when using RX_SERIAL.
| Pin | Function | Notes |
| --- | ----------------- | -------------------------------------------- |
| 1 | PPM/Serial | Can PPM or Serial input |
| 2 | VCC_OUT | 3.3 Volt output to the device |
| 3 | Ground | |
| 4 | VCC_OUT | 5.1 Volt output to the device |
### IO_4 - Buzzer
| Pin | Function | Notes |
| --- | ----------------- | -------------------------------------------- |
| 1 | BUZZER | Normal high (5.1v) |
| 2 | VCC_OUT | 5.1 Volt output to the device |
### IO_5 - Free UART
| Pin | Function | Notes |
| --- | ----------------- | -------------------------------------------- |
| 1 | UART1 TX | Free UART |
| 2 | UART1 RX | Free UART |
| 3 | Ground | |
| 4 | VCC_OUT | 4.7 Volt output to the device |
### IO_6 - IR TX (extension)
| Pin | Function | Notes |
| --- | ----------------- | -------------------------------------------- |
| 1 | IR TX | |
| 2 | Ground | |

87
docs/boards/Board - CrazyBeeF3FR.md
View file

@ -1,87 +0,0 @@
# CrazyBee F3 FR
![CrazyBee F3 FR front](images/CrazyBeeF3FRtop.jpg)
![CrazyBee F3 FR back](images/CrazyBeeF3FRbottom.jpg)
## Description
CrazyBee F3 flight controller is a Highly integrated board for 1S Whoop brushless racing drone.
It might be the world first Tiny whoop size brushless flight controller which integrated Receiver/4in1 ESC/OSD/Current Meter.
## MCU, Sensors and Features
### Hardware and Features
- MCU: STM32F303CCT6
- IMU: MPU6000 (SPI)
- IMU Interrupt: yes
- VCP: yes
- OSD: Betaflight OSD
- Battery Voltage Sensor: yes
- Integrated Voltage Regulator: yes, booster, 5V/800mA
- Integrated Current sensor：Max 14A, could be modified to 28A by replace resistor
- Integrated Frsky compatible receiver: Frsky_D(D8) and Frsky_X(D16) switchable mode
- Buttons: 1 (Receiver bind button)
- Integrated 4x Blheli_s ESC: Max 5A per ESC
- ESC Connector: 3-pin, PicoBlade 1.25mm pitch
- Beeper output: 2-pin, soldering pad
- 4 Rx Indicating LEDs: 2 x red and 2 x white
## Resource mapping
| Label | Pin | Timer | DMA | Default | Note |
|----------------------------|------|-------|-----|-------------|----------------------------------|
| MPU6000_INT_EXTI | PC13 | | | | |
| MPU6000_CS_PIN | PA4 | | | | SPI1 |
| MPU6000_SCK_PIN | PA5 | | | | SPI1 |
| MPU6000_MISO_PIN | PA6 | | | | SPI1 |
| MPU6000_MOSI_PIN | PA7 | | | | SPI1 |
| OSD_CS_PIN | PB1 | | | | SPI1 |
| OSD_SCK_PIN | PA5 | | | | SPI1 |
| OSD_MISO_PIN | PA6 | | | | SPI1 |
| OSD_MOSI_PIN | PA7 | | | | SPI1 |
| RX_CS_PIN | PB12 | | | | SPI2 |
| RX_SCK_PIN | PB13 | | | | SPI2 |
| RX_MISO_PIN | PB14 | | | | SPI2 |
| RX_MOSI_PIN | PB15 | | | | SPI2 |
| RX_GDO0_PIN | PA8 | | | | |
| RX_BIND_PIN | PA9 | | | | |
| RX_LED_PIN | PA10 | | | | |
| PWM1 | PB8 | TIM8, CH2 | | | |
| PWM2 | PB9 | TIM8, CH3 | | | |
| PWM3 | PA3 | TIM2, CH4 | | | |
| PWM4 | PA2 | TIM15,CH1 | | | |
| VBAT_ADC_PIN | PA0 | | | | ADC1 |
| RSSI_ADC_PIN | PA1 | | | | ADC1 |
| BEEPER | PC15 | | | | |
| UART3 TX | PB10 | | | | will add pinout soon |
| UART3 RX | PB11 | | | | will add pinout soon |
## Manufacturers and Distributors
https://www.banggood.com/Racerstar-Crazybee-F3-Flight-Controller-4-IN-1-5A-1S-Blheli_S-ESC-Compatible-Frsky-D8-Receiver-p-1262972.html
## Designers
## Maintainers
## FAQ & Known Issues
- The board specifications claim DSHOT600-ready, but due to the use of a type L (BB1 24MHz) ESC, only DSHOT300 is reliably supported, although DSHOT600 seems to be working for quite a few people. But just how clean that ESC control signal is when using DSHOT600, is untested. For a discussion on this, see https://www.rcgroups.com/forums/showthread.php?3036325-Racerstar-Crazybee-F3-Ultimate-Micro-AIO-FC%21-1S-5A-BlheliS-Frsky-Flysky-OSD/page3 .
- The factory default GYRO / PID config is 8KHz / 2KHz . There are reports that this may lead to possible instability and 4KHz / 4KHz is recommended.
Specific information for the factory supplied Betaflight 3.3.0 version:
- The DSHOT beeper function does not work.
- When turtle mode ("Flip over after Crash") is activated, the FC will only arm if the failsafe timeout is 1s (10 * 0.1s) or more. If the timeout is set lower than that, you may see the motors shortly try to spin up and then stop, and then the quad will not be armed. Rumour has it that this is fixed in BF 3.4 .
FRSKY Version:
- To bind to your Taranis, you need to be running the non-eu OpenTX version, which allows you to use the required D8 setting to bind to the RX. The factory default BF receiver mode is FRSKY_X, so remember to configure this if needed.
- FrSky X (8 / 16 channels) and FrSky D (8 channels) work both reliably, including in combination with crash flip / Dshot beacon, as long as the TELEMETRY feature is disabled;
Basic telemetry information like RSSI and battery voltage will be sent even when the TELEMETRY feature is disabled;
- On FrSky D, the TELEMETRY feature causes occasional dropouts, depending on how many sensors (BARO, GPS, ...) are enabled, probably due to a timing overrun;
- On FrSky X, the TELEMETRY feature causes hard lockups due to a bug in the telemetry generation code.
## Other Resources
User Manual: http://img.banggood.com/file/products/20180209021414Crazybeef3.pdf

73
docs/boards/Board - CrazyBeeF3FS.md
View file

@ -1,73 +0,0 @@
# CrazyBee F3 FS
![CrazyBee F3 FS front](images/CrazyBeeF3FStop.jpg)
![CrazyBee F3 FS back](images/CrazyBeeF3FSbottom.jpg)
## Description
CrazyBee F3 FS flight controller is a Highly integrated board for 1S Whoop brushless racing drone.
It might be the world first Tiny whoop size brushless flight controller which integrated Receiver/4in1 ESC/OSD/Current Meter.
## MCU, Sensors and Features
### Hardware and Features
- MCU: STM32F303CCT6
- IMU: MPU6000 (SPI)
- IMU Interrupt: yes
- VCP: yes
- OSD: Betaflight OSD
- Battery Voltage Sensor: yes
- Integrated Voltage Regulator: yes, booster, 5V/800mA
- Integrated Current sensor：Max 14A, could be modified to 28A by replace resistor
- Integrated Flysky compatible receiver
- Buttons: 1 (Receiver bind button)
- Integrated 4x Blheli_s ESC: Max 5A per ESC
- ESC Connector: 3-pin, PicoBlade 1.25mm pitch
- Beeper output: 2-pin, soldering pad
- 4 Rx Indicating LEDs: 2 x red and 2 x white
## Resource mapping
| Label | Pin | Timer | DMA | Default | Note |
|----------------------------|------|-------|-----|-------------|----------------------------------|
| MPU6000_INT_EXTI | PC13 | | | | |
| MPU6000_CS_PIN | PA4 | | | | SPI1 |
| MPU6000_SCK_PIN | PA5 | | | | SPI1 |
| MPU6000_MISO_PIN | PA6 | | | | SPI1 |
| MPU6000_MOSI_PIN | PA7 | | | | SPI1 |
| OSD_CS_PIN | PB1 | | | | SPI1 |
| OSD_SCK_PIN | PA5 | | | | SPI1 |
| OSD_MISO_PIN | PA6 | | | | SPI1 |
| OSD_MOSI_PIN | PA7 | | | | SPI1 |
| RX_CS_PIN | PB12 | | | | SPI2 |
| RX_SCK_PIN | PB13 | | | | SPI2 |
| RX_MISO_PIN | PB14 | | | | SPI2 |
| RX_MOSI_PIN | PB15 | | | | SPI2 |
| RX_IRQ_PIN | PA8 | | | | |
| RX_BIND_PIN | PA9 | | | | |
| RX_LED_PIN | PA10 | | | | |
| PWM1 | PB8 | TIM8, CH2 | | | |
| PWM2 | PB9 | TIM8, CH3 | | | |
| PWM3 | PA3 | TIM2, CH4 | | | |
| PWM4 | PA2 | TIM15,CH1 | | | |
| VBAT_ADC_PIN | PA0 | | | | ADC1 |
| RSSI_ADC_PIN | PA1 | | | | ADC1 |
| BEEPER | PC15 | | | | |
| UART3 TX | PB10 | | | | will add pinout soon |
| UART3 RX | PB11 | | | | will add pinout soon |
## Manufacturers and Distributors
https://www.banggood.com/Racerstar-Crazybee-F3-Flight-Controller-4-IN-1-5A-1S-Blheli_S-ESC-Compatible-Flysky-AFHDS-Receiver-p-1271331.html
## Designers
## Maintainers
## FAQ & Known Issues
See the same item for [CrazyBeeF3FR](Board%20-%20CrazyBeeF3FR.md#FAQ%20&%20Known%20ssues)
## Other Resources
User Manual: http://img.banggood.com/file/products/20180225215703Crazybeef3flysky.pdf

Some files were not shown because too many files have changed in this diff Show more