This mod adds an arrow symbol showing the location of the up/down on the OSD. The arrow direction points in the direction of up or down.
Update osd_elements.c
Making the Up/Down OSD reference its own element
Removing the Up/Down reference from the artificial horizon and making a specific element for this feature. Activation via CLI (for now)
Updates to Up/Down refernce OSD element
Changed the up/down reference so that it is its own separarte element. The position is absolute on the screen and immutable by the user for consistent operation. Updated settings to include CLI option for turning the feature on and off.
Update cms_menu_osd.c
Updated file to add Up/Down reference selection from OSD menu
Updates to simplify/correct Up/Down OSD element
Simplified/corrected logic and removed arcsine function. OSD up/down reference is now positionable by the user in the configurator.
Tweaks and codestyle updates
Feedback from Michael Keller
Updates to Up/Down OSD indicator
Created a bounding box of +/- 25 degrees for indicator
Coding style correction
minor correction to match BF coding style
Enable Up/Down reference in OSD
This mod adds an arrow symbol showing the location of the up/down on the OSD. The arrow direction points in the direction of up or down.
Update osd_elements.c
Making the Up/Down OSD reference its own element
Removing the Up/Down reference from the artificial horizon and making a specific element for this feature. Activation via CLI (for now)
Updates to Up/Down refernce OSD element
Changed the up/down reference so that it is its own separarte element. The position is absolute on the screen and immutable by the user for consistent operation. Updated settings to include CLI option for turning the feature on and off.
Updates to simplify/correct Up/Down OSD element
Simplified/corrected logic and removed arcsine function. OSD up/down reference is now positionable by the user in the configurator.
Tweaks and codestyle updates
Feedback from Michael Keller
Enable Up/Down reference for artificial horizon in OSD
This mod adds an arrow symbol showing the location of the up/down on the OSD. The arrow direction points in the direction of up or down.
Update osd_elements.c
Making the Up/Down OSD reference its own element
Removing the Up/Down reference from the artificial horizon and making a specific element for this feature. Activation via CLI (for now)
Updates to Up/Down refernce OSD element
Changed the up/down reference so that it is its own separarte element. The position is absolute on the screen and immutable by the user for consistent operation. Updated settings to include CLI option for turning the feature on and off.
Updates to simplify/correct Up/Down OSD element
Simplified/corrected logic and removed arcsine function. OSD up/down reference is now positionable by the user in the configurator.
Tweaks and codestyle updates
Feedback from Michael Keller
Coding style correction
minor correction to match BF coding style
Enable Up/Down reference for artificial horizon in OSD
This mod adds an arrow symbol showing the location of the up/down on the OSD. The arrow direction points in the direction of up or down.
Update osd_elements.c
Making the Up/Down OSD reference its own element
Removing the Up/Down reference from the artificial horizon and making a specific element for this feature. Activation via CLI (for now)
Updates to Up/Down refernce OSD element
Changed the up/down reference so that it is its own separarte element. The position is absolute on the screen and immutable by the user for consistent operation. Updated settings to include CLI option for turning the feature on and off.
Updates to simplify/correct Up/Down OSD element
Simplified/corrected logic and removed arcsine function. OSD up/down reference is now positionable by the user in the configurator.
Tweaks and codestyle updates
Feedback from Michael Keller
Corrections to unit tests
Corrected unit tests link failing due to not being able to find rMat[3][3]
Extends the OSD element position setting to include a 2 bit selector for alternate representations of the element. So up to 4 variants of an element can be supported. Meant to be used instead of adding new elements when the request is a mutually exclusive variant of an existing element. If there are no variants of an element then the logic falls back to "type 1" (`OSD_ELEMENT_TYPE_1`) which is the only representation of the element.
As an example, in this PR the "Battery usage" element has been extended to 4 types:
1. The original capacity remaining graphical bar (shrinks as battery is used) - this is the default.
2. Capacity used graphical bar (grows as battery is used).
3. Remaining capacity numerical percentage (goes down as battery is used).
4. Capacity used numerical percentage (goes up as battery is used).
When extending an element it is not necessary to support all 4 types and the element rendering code should default to the original type 1 version for unsupported types.
Will require Configurator support. Since the 2 high bits of the `uint16` were previously unused the setting will default to the "type 1" original variant in all cases where an incompatible Configurator is used.
Adds angle setpoint roll/pitch expo for self-level modes.
Previously the angle setpoint was a simple linear calculation based on the stick deflection percentage and the angle limit. This makes control very jumpy around center stick and people would often resort to adding expo in their radios to compensate. This then adds the complication of wanting expo in the radio when in self-level but not when in acro - leading to complicated mixes, virtual switches, etc.
This PR adds separate self-level expo settings for roll/pitch so the user can customize the axis behavior. Yaw is excluded because this axis uses normal rates and expo controlling the rotational rate around the yaw axis and not an angle setpoint. The roll/pitch expo can range from 0 (off) to 100 (max) like other RC expo settings. For example:
```
set roll_level_expo = 30
set pitch_level_expo = 40
```
The default values are 0 which disables any expo and behaves as before.
The settings are available in the CMS rate profile menu.
Logic error would cause the MSP data to be written to every port that had MSP enabled if the selected port was -1 (`SERIAL_PORT_NONE`). Since the (correct) default for `displayport_msp_serial` is -1, this was causing MSP displayPort traffic to be "spammed" to every UART with MSP enabled. Since MSP displayPort is the fallback when no other OSD device is detected (in "AUTO" mode) this could cause large amounts of unnecessary MSP traffic - for example in cases with flight controllers with no MAX7456 and using the DJI air unit connected via MSP. This "might" be related to earlier reports of the DJI OSD no longer working with softserial (even though that's not really a recommended configuration) because of the extra serial traffic.
This was not so much a "bug" but instead a shortsighted design. The only other thing using `mspSerialPush()` is the MSP-based current sensor. In that case the logic does in fact want to "spam" all the MSP ports with the current sensor request. So it was using the `SERIAL_PORT_NONE` identifier to mean "every port". But this conflicts with MSP displayPort logic which really needs a "no ports" identifier. So this PR adds a `SERIAL_PORT_ALL` identifier to explicitly differentiat "all" from "none" and this is used for the current sensor.
Was incorrectly defaulting to 0 which is UART1. Should be -1 (`SERIAL_PORT_NONE`).
Add validation to ensure the selected UART exists, has MSP enabled, and is appropriate (not VCP).
Previously the display rows was hardcoded to 13 (NTSC). Now it will use 16 if the user has explicitly selected PAL. This allows the display to fully use the screen - particularly when in the CMS menus. Since there is no device to "AUTO" detect, this will still default to safer value of 13 rows as NTSC.
Eventually we may want to extend MSP displayPort to add an auto-detect capability. But since the protocol is a one-way "push" from the firmware to the device that's somewhat difficult. Will probably need a MSP message that the displayPort device can use to "register" its capabilities.
Often the user doesn't realize that there are more menu items then displayed and the only way to tell was to try and move the selection to the bottom to see if another page appears.
This PR adds page up/down indicators if there are more menu items than those visible on the current display.
Uses the OSD arrow symbols when possible (for OSD supporting devices), otherwise the `^` (carat) and `V` are used for text-only represenatations.
To determine if the device was capable of displaying symbols the `displayPort` structure has a new `deviceType` set when it is initialized. There have been other times when knowing the type of device would have been useful so that's now supported. Then this is abstracted by a new `displaySupportsOsdSymbols()` function. Devices that support OSD are assumed to support the OSD symbols as the OSD element drawing code always uses them. For devices that don't support OSD function we have to presume the sybols aren't available.
Resets to defaults if not.
If the min/max were set to the same value then this will lead to div-by-zero errors.
If the min was set to a greater value then this would lead to negative values and underflow in the battery remaining calculations. This would affect the OSD, dashboard, various telemetries, LED strip, and the Configurator.
Improves menu readability by changing the background from a transparent display of the camera image to a static opaque gray background.
The behavior is controlled with the `osd_menu_background` parameter which defaults to `TRANSPARENT` to preserve the previous behavior. Other opaque options are available:
```
osd_menu_background = TRANSPARENT
Allowed values: TRANSPARENT, BLACK, GRAY, LIGHT_GRAY
```
The background setting is available in the CMS OSD menu and the user can cycle through the various options with the display updating in real-time.
Currently only the onboard MAX7456-based OSD is supported, but the implementation adds `displayPort` support so it can easily be extended to other OSD devices if those manufacturers want to add support. Also can be extended to other background types (like colors, varying transparency, etc.) for future device support.
Makes use of the built-in MAX7456 feature to display all transparent pixels as "gray". The MAX7456 display area seems to be a few scan lines smaller than the actual camera video image so it's normal for some of the camera image to "leak" at the top/bottom of the display. The OSD display area can be adjusted up/down using the `vcd_v_offset` setting if desired.
