Implemented debug output on uart1 for stm32
Replaced hardcoded eeprom offsets with documented constats
Fixed a bug affecting telemetry on Atmega328p using the invert_telemetry flag.
This feature will not activate the selected protocol unless a bind is
requested using bind from channel or the GUI "Bind" button. It is only
enabled if bind from channel and autobind are set since I think they are
working well together.
The goal is to prevent binding other people's model when powering up the
TX, changing model or scanning through protocols.
There is a new blinking pattern associated to it as well as a new status
"Waiting for bind".
This feature is enabled by default in _config.h .
This new feature is available:
- in serial mode and when binding from the GUI. As soon as the Bind
window is closed = serial bind bit was set and cleared, the current bind
operation will be terminated.
- if the bind was initiated from the Bind on channel feature (bind
channel goes high) then as soon as the bind channel goes low the current
bind operation will be terminated.
Tested on ersky9x which does open a bind window, not sure about
OpenTX...
Some protocols (Hubsan, Assan, FY326, Shenqi...) which are waiting for
model/RX to reply will stay in bind mode.
- rewritten the handling of the incoming over the air telemetry packet
- rewritten the TX_RSSI calculation (link frame[4])
- added RX LQI and TX_LQI information in the link frame (frame[5] and
frame[6])
Protocol WK2x01 number 30
Sub protocols:
- WK2801 number 0, 8 channels, fixed id not supported
- WK2601 number 1, 6/7 channels, option is used see doc for details
- WK2401 number 2, 4 channels
Extended limits supported
Autobind protocol
Most receivers support WK2801 so always start trying this sub protocol
first.
Toggling channel 16 (-100%->+100%->-100%) will execute a bind only if
the loaded protocol is an autobind protocol or autobind is set AND
throttle is low (below -95%).
This allows the multi module to tell the TX software (e.g. OpenTX) which telemetry protocol is in use. Also Status of the module and signaling binding/invalid protocol
Changed telemetry configuration and validation for AFHDS2A and HUBSAN
Added default Bayang telemetry from Silverxxx:
- Option=1 to activate telemetry (option=0 -> standard Bayang protocol)
- Value returned to the TX: RX RSSI, TX RSSI, A1=uncompensated battery
voltage, A2=compensated battery voltage
- Wait for transmit completion before switching to RX (no more fixed
delays...)
- Verify if data has been received before processing it (better handling
of telemetry)
- Added TX_RSSI (along with the existing RX_RSSI)
Known issue: RX_RSSI value needs to be looked at. I'm seeing only values
between 157 (bad) and 196 (good). Is this normal for this protocol?
Loads of changes:
STM32 board introduction: NOT TESTED
XMEGA renamed to ORANGE_TX to be more explicit
DSM: added reset if cyrf freezed
Validate: added a validate file to verify the different compilation
options
Pascal Langer
Arne Schwabe