Certain OSD elements not being updated properly [iNav 7.0.0 RC3, HDZero]

[MartinHugh]

Current Behavior

Battery level and battery percentage, elements are intermittently displayed.

Flight timer seems to show for a couple of seconds and then hide for a few seconds, but only, after 10:00 has passed

All affected elements are in the inner "blue" area of the OSD layout, which I understand gets higher priority updates than those areas further from the centre

Steps to Reproduce

Refer to these two links to observer the two problems above
Battery Elements
https://www.mhr.me.uk/batteryoccult.mp4

Timer after 10mins
https://www.mhr.me.uk/flighttimeoccult.mp4

Expected behavior

Anything on the OSD should remain on the OSD and be randomly disappearing.
I dont object to warning "flashing" of an element, but when it is gone for more than 2s this is not "flashing"

Suggested solution(s)

See expected behaviour

version

INAV/SPEEDYBEEF405WING 7.0.0 Nov 19 2023 / 20:18:17 (2e9b1c7)

GCC-10.3.1 20210824 (release)

[MrD-RC]

There are no high or low priority area in INAV. All OSD elements get sent to the VTx at the same rate, regardless of position. I believe the blue area is for if you’re using the 4:3 mode in HDZero.

The elements randomly disappearing and reappearing is down to the VTx to VRx communications. It is down to HDZero to stop this happening.

Please don’t have two separate problems in a single issue. The Autolaunch report should be completely separate, with DVR or logs. This issue will be closed as it is outside of INAV’s control. It’s down to HDZero. But this will hide the potential autolaunch issue. Also, with RC versions, please state which Release Candidate you’re using.

[MartinHugh]

There are no high or low priority area in INAV. All OSD elements get sent to the VTx at the same rate, regardless of position. I believe the blue area is for if you’re using the 4:3 mode in HDZero.

The elements randomly disappearing and reappearing is down to the VTx to VRx communications. It is down to HDZero to stop this happening.

Please don’t have two separate problems in a single issue. The Autolaunch report should be completely separate, with DVR or logs. This issue will be closed as it is outside of INAV’s control. It’s down to HDZero. But this will hide the potential autolaunch issue. Also, with RC versions, please state which Release Candidate you’re using.

Thank you for your comments.
I will raise this over on HDZero

Note: I mentioned the RC version in the title

[MartinHugh]

I thought I would follow this up to point out that the flashing is likely due to the fact that alarms are set in Inav. One reason this was a surprise to me is that this aircraft is running li Ion and so is running longer than 10 mins, which appears to be the default flight time alarm, and, below the 3.5v minimum voltage which was set before I switched from Lipo on this aircraft.

However, I think my real problem is how long an Alarming element is hidden, which the combination of having two voltage elements displayed seems to be 2 to 3 s. This is far too long when scanning for critical information whilst flying.

I understand that this mark / space ratio to alarm elements is set and controlled by iNav?
I wonder if this can be changed with osd_msp_displayport_fullframe_interval
?

[ligenxxxx]

Please reopen this issue.
My FC fw is 7.0.0 release.

My vtx fw is 1.5.0 release.
I placed the RSSI OSD at (0x00,0x17) location.

• When I add a few other OSDs, the RSSI OSD blinks quickly.
  faster.txt
• When I add a lot of OSDs, the RSSI OSD blink is very slow, and it takes about 5-6 seconds to complete a blink.
  slower.txt

I grabbed the data twice and analyzed it, and it turned out that there was indeed a problem with iNav's blinking. My guess is that blinking has its own timer. If there is some coupling between the OSD refresh rate and the blinking timer, an error will occur.

• You can quickly search 00 19 00 in txt to analyze RSSI osd blinking.
• You can quickly search 00 9E in txt to view ON TIME osd.