Awesome!

So far, you have not run python script to generate Settings.md
And I see that are some intendation problems in the code.
I will try to review next week

I have run the script and updated the PR, but the test is still failing. I ran the same test on my local branch and it passes ok.
Please advise.

I just had a look a settings.md and it needs to be updated. If you look for a boolean value, it should have off and on in the min and max table columns respectively.

You may need to fetch upstream on your branch to get the latest documents generating script.

There is definitely a problem with the settings.md file. In this screenshot, the settings.md on the left is the one submitted with this PR. The one on the right is the master. Check out the beeper_pwm_mode section. You can see on the master that the MIN and MAX in the table have OFF and ON. The version in this PR does not.

How does the file look on your computer? If you have the OFF and ON in the beeper_pwm_mode table, it's correct and just hasn't been pushed to the change branch. if the OFF and ON for MIN and MAX are missing, you have the wrong document creation script. If you perform a fetch upstream on your branch, it should get the correct creation script. It is src/utils/update_cli_docs.py and should have the lines:

66 | member["min"] = "OFF"
67 | member["max"] = "ON"

I just checked your branch, and the creation script is not up to date. So the fetch upstream on your branch should get everything sorted.

Please do not merge yet as I am working on an optimisation to reduce the amount of data being sent over the serial port.

Ok, all done. Please consider for merging .
An issue raised in discord groups found a problem that was crashing some F722 flight controllers, but this ended up being a hardware issue. However, it did prompt me to redesign the HD Zero OSD code to reduce the amount of data being sent to the VTX and to stop sending altogether if the VTX is not detected.

Thanks @geoffsim I'll quickly check analog functions and DJI for regression and then we will go futher

Apologies for the late change. A flight test today showed an issue with the AHI when aircraft nears a 90 degree bank.

The AHI code needs work at some stage to reduce the number of changes reported each time it is called. Currently it (AHI code) blanks out the AHI and then redraws it. This can create a lot of changes that have to be sent to the OSD, especially around the 90 degree bank when the AHI is spanning multiple lines. I'm sure the code could be optimised.

@geoffsim This PR completely breaks the Analog OSD functionality. After flashing with default, no elements are visible and I found no way to make them visible. This has to be fixed before merging.

Thanks @geoffsim
I think it's connected with changed visibility flag

Fixed, tested, and added to the PR.
The initialisation in fc_init.c was stealing the displayPort regardless of whether HDZero was selected or not.
I followed the example of the frsky code to fix this.
I had also broken the analog AHI display when I reduced the calls to drawScreen(). I have reverted that change.

Regards,
Geoff.

Does it work with all HD-receivers?

All HDZero VTX and VRX models, yes.

I have some more changes to come in the next few days. Please do not review until then.

Changes complete. Please review.

Nice! I'll test and review when I will find a moment

I promise to not make any more changes! That last one was important to facilitate the "OSD OFF" mode.
The changes have been flight tested with success.

Known issue (HDZero VTX specific):
When exiting the Camera or VTX menus, the OSD will not redraw fully.
This will be fixed in the next VTX update (not iNav).
A temporary work around is to switch to a different OSD (or OSD OFF) and back again.

And it's merged. I will run some more tests and build PR1 for 4.1 quite soon