* stop motors after 90 degrees of rotation and with max rate
* handle no accelerometer data
* improve check for acc, although seems to be OK without it
* disable all attenuation if rate is set to zero
* refactoring thanks Karate
* use sensors.h
* remove unnecessary arming check
* exit crashFlip immediately switch is reverted if throttle is zero
* add Crashflip Rate to OSD
* Revert unnecessary changes in crashflip core.c code
and clarify comments about crashflip switch
* update / minimise comments, thanks Karate
* ensure all names say `crashflip` consistently
* Undo quick re-arm because motrors were not reversed
* fix issue with reversed motors, we must disarm
* ignore yaw rotation and set gyro limit to 1900 deg/s
* default attenuation to off (crashflip_rate = 0)
* refactoring, increase rate limit to allow stronger inhibition
* enable in race_pro mode
* don't attenuate on attitude until a significant change occurs
* no attenuation for small changes
* Updates from review by PL
* remove whitespace
* refactor motorOutput, update comments, renaming variables
thanks PL
* changes from review PL
* only permit fast re-arm if crashflip rate set and crashflip was successful
* properly exit turtle mode
* add crashFlipSuccessful to unit test extern c
* small updates from review
* improved crashflip switch handling
* remove unnecessary motors normal check
* RX task update rate to 22Hz, to improve 25Hz link stability
* modified Rx code
* add LQ to debug
* use max of frameAge or FrameDelta
* Require a dropouit of 200ms, not 100ms, before RXLOSS
* remove FrameAge, use 150ms timeout 50ms checks
* fix tests and tidy up the comments
* Handle NULL input as before, log frame time
* possible solutions to review comment about names
* Remove rxFrameTimeUs
- prepare for direct use of lastRcFrameTimeUs
- refactor rx_spi callback
* remove global currentRxRateHz
* simplify updateRcRefreshRate
* re-name to recheck interval, return frame time debug
* Calculate RxRate only once
* use rxReceivingSignal for consistency
* use signalReceived not rxDataReceived for consistency
* suggestions from review PL
* move defines, thanks K
* fixes from review, thanks MH
* review changes, undo task interval change
rename bool rxIsReceivingSignal to isRxReceivingSignal
thanks Steve for resolving that tasks changes are not needed
thanks PL for your feedback also
---------
Co-authored-by: Petr Ledvina <ledvinap@hp124.ekotip.cz>
* Add LED functions: Battery Bar, GPS Bar
Battery Bar:
Indicates the battery percentage with a loading bar style
GPS Bar:
Indicates the amount of locked GPS satellites with a loading bar style
* LED altitude function
Adds a new function: LED altitude.
Sets the LED color based on the altitude, measured from the initialized position.
* set led color to background if value decreases
Even if the gps satellite count decreases at a later point in time, the LEDs update correctly now.
It is the same for the battery level function.
LEDs color changes more strongly now when based on altitude.
* Added proper ifdefs for GPS and Barometer
* fixed unittest and use estimate altitute
- fixed unittest
- cleaner indentation
- the altitude function now uses the estimate function instead of the raw value (gps+barometer)
* counters in struct, gps bar color gradient
- Counters for the led bar are now handled in a structure.
- Moved the led bar code to a seperate function that is only called when the led config changes.
- improved usefulness of the gps led bar with less than 4 leds installed by adding a color gradient.
* Update src/main/io/ledstrip.c
Co-authored-by: Petr Ledvina <ledvinap@gmail.com>
* Update src/main/io/ledstrip.c
Co-authored-by: Petr Ledvina <ledvinap@gmail.com>
* Update src/main/io/ledstrip.c
Co-authored-by: Petr Ledvina <ledvinap@gmail.com>
* Update src/main/io/ledstrip.h
Co-authored-by: Petr Ledvina <ledvinap@gmail.com>
* Update src/main/io/ledstrip.c
Co-authored-by: Petr Ledvina <ledvinap@gmail.com>
* one min led for very low battery, use failsafe sats to interpolate
- at least one led is lit up for the battery/gps bar at all time (to show color gradient, also making the function more useful when only applying it to 1 led).
- gps bar now takes the failsafe min sats (or default 8) to interpolate between red and green.
- rewrote the led codes to be less fragile
- some structural changes that also adress comments on the pull request
* fix code if no gps rescue is used
fixes code if no gps rescue is used.
sets the default min sats to 8.
* Update src/main/io/ledstrip.c
Co-authored-by: Petr Ledvina <ledvinap@gmail.com>
* Fixes per review ledvinap
* Fixes per review Ledvinap 2
* Update src/main/io/ledstrip.c
* Update src/main/io/ledstrip.c
---------
Co-authored-by: jonas-becker <jonas@Thinkpad>
Co-authored-by: Petr Ledvina <ledvinap@gmail.com>
Co-authored-by: Mark Haslinghuis <mark@numloq.nl>
* Method for adding defaults using defines for resources.
* As we will always be using the fullTimerHardware, we just need to configure the pin mapping.
This is done in the config.h as
#define TIMER_PIN_MAPPING \
TIMER_PIN_MAP(0, PA0, 1, 0) \
TIMER_PIN_MAP(0, PA1, 1, 0)
timerHardware[] dependencies to be removed in another PR
* Adding missing pin definitions (removing dependency on timerHardware)
* Typo
* In case MOTOR1_PIN is not defined, but a motor is configured
Previous logic was updating updating the DMA buffer for all possible LED positions (32) regardless of how many were used. Since there are 24 bytes per LED, this performed a lot of unnecessary processing in cases where the user had less than 32 LEDs configured.
Also includes a bug fix in that if the LED count was decreased (like making changed using the Configurator LED tab), the now unused LEDs at the end of the string would remain on at the last color applied. Now they will be properly turned off. The bug was minor as it was resolved by a reboot, but made setup using the Configurator confusing since changes made are reflected when the user clicked the "Save" button (which does not reboot).
Moved vtxtable frequency mode implementation into `vtx_common.c`.
This makes the implementation available for all vtx types and allows
for some code deduplication (see point below)
Removed band and channel tracking from tramp and rtc6705.
The hardware underlying both only support frequency mode and
the tracking is now done in `vtx_common.c` using the new factory flag.
Deleted vtxStringXXX. to continue supporting builds without
`USE_VTX_TABLE`, new infrastructure was created in
`drivers/vtx_table.c`, which loads fixed tables into vtxTableXXX
when built witout `USE_VTX_TABLE`. Individual vtx implementations no
longer need to load any band/channel tables. They only need to load
their individual power tables when built without `USE_VTX_TABLE`.
Additionally this allows for the next point:
Fully integrated vtxTableXXX and removed the old and no longer needed
indirection of frequency and power tables in `vtxDevice_t`.
Removed VTX_SETTINGS_* constants from `vtx_common.h` and replaced them
with the vtxtable equivalent.
rtc6705 implementation now uses power values from vtxtable instead of
using indices directly. It also stops using index 0. This makes it
consistent with other vtx implementations and is more user configurable.
It also cleans up `telemetry\srxl.c` which had to have a special case for rtc6705.
Finally, frequency entries in the vtxtable can now be marked as empty
by setting their frequency to 0. Betaflight will never allow a blocked
channel to be selected. This is useful for vtxtable index mode
(FACTORY flag set) where manufacturer-defined bands can be truncated
to ensure compliance with local laws and regulations.
Added features to the BEACON ledstrip profile:
Added a `ledstrip_beacon_color` to allow color selection rather than forcing to white.
Added `ledstrip_beacon_period_ms` to configure the blink period in milliseconds. Smaller time periods mean faster blinking.
Added `ledstrip_beacon_percent` to configure the "ON" time duty cycle. User can set to 100% to have the beacon display a solid color. 0% can be used to turn the becaon completely off.
Added `ledstrip_beacon_armed_only` to allow the user to configure whether the beacon is only on when armed.
Added `ledstrip_visual_beeper_color` to allow configuration of the visual beeper color.
Added the new parameters to the CMS menu.
Simplified the code and combined the RACE and BEACON profile processing.
Added support for auutomatically displaying a beacon that indicates RX_SET or failsafe regardless of the other RACE or BEACON settings.
The range was underflowing the calculated hue value causing it to loop back to other colors. For example when battery ranged from below 20% the color would shift from red (the correct color for minimum battery) to shades of magenta. RSSI had the same problem.
Now the logic reserves the base color (red in these cases) for the minimum 20% of the range. From 20-100% the color will scale from red through to green.
Previous logic bypassed optimizations and updated the ws2811 on every task execution - leading to and average of 92us task execution time. Restored the previous optimizations and additionally optimized the new "RACE" and "BEACON" modes so that they only update the led's when there's an actual state change. Task time for these modes is now in the 2-4us range for F405. For the normal "STATUS" profile the performance has been restored to previous optimized levels and typical configurations will generally have task times in the 8-14us range.
Revised the LEDLOW disable mode to function all the time and disable the ledstrip completely. Previously if visual beeper was enabled that would override the disable and the ledstrip would display whatever would be otherwise displayed but only during the duration of the beep. The resulted to a very inconsistent behavior depending on the user's settings.
Added visual beeper support to the new "RACE" and "BEACON" profile modes.
General cleanup and refactoring.
