inav
inav copied to clipboard
iNavFlight
OSD flashes very slowly (Warning) when there are many OSD items added
My FC fw is 7.0.0-release When there are few osd items added, the flashing is very fast. When the added osd item exceeds a certain value, the flashing slows down visibly to the naked eye. At this time, more OSD items are added, and the flashing becomes slower and slower. #9525 contains the data text I collected from the osd serial port.
My normal OSD layout has typically a dozen or so items on it. When a condition alarms, it causes an item to hide for 3s and show for 3s. This is unworkable, and my workaround is to turn alarms off for everything, as currently they add no value for me.
Given that the reason for an alarm is to get the pilot's attention, when scanning the OSD during busy flying, the actual effect is often to find that a critical piece of information, far from being brought to the pilots attention.... is not even there on the display at the instant that it is viewed.
I think it is important from a usability point of view to realise that if the goal is to get a user's attention, alarms should be :
a) a much faster flash (perhaps sub second) b) of a consistent frequency, independent of the number of items displayed
My FC fw is 7.0.0-release
This isn't new. Its been a problem since 6.0.0 on all my HD systems. By the time you have 30 items on a single screen. You no longer have a flashing warning, but a blank space for literally half a minute.
My FC fw is 7.0.0-release
This isn't new. Its been a problem since 6.0.0 on all my HD systems. By the time you have 30 items on a single screen. You no longer have a flashing warning, but a blank space for literally half a minute.
Agreed, but it is still a problem whether old or new and needs looking at.
My FC fw is 7.0.0-release
This isn't new. Its been a problem since 6.0.0 on all my HD systems. By the time you have 30 items on a single screen. You no longer have a flashing warning, but a blank space for literally half a minute.
Exactly what I see. On analog I used the OSD to do some inflight tuning. For example put the PIDS on the OSD and configure an AUX channel to choose which item you want to tune during flight. The item of choice starts to blink, at which you know when tuning can begin. Totally useless on digital. No blinking happens, selected item goes blank. So when tuning you have no idea what the value is at a given time. I gave up OSD inflight tuning with digital OSD..... :-(
I went to report this bug, but I see it's already been raised. It indeed makes it difficult to trust displayport OSD flash warnings, when a greater number of elements are used. I do not see this problem when I place many elements on the OSD using betaflight. The flash warning is constant.
@ligenxxxx 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.
@MrD-RC @mmosca Is there a chance a repair could be made for this before 7.1.0?
@MrD-RC @mmosca Is there a chance a repair could be made for this before 7.1.0?
Sure, if you want to submit a PR before the end of January.
This is happening in analog too for some people
Does it happen in analog when you set display_force_sw_blink = true ?
This is happening in analog too for some people
Does it happen in analog when you set display_force_sw_blink = true ?
The FC I use requires display_force_sw_blink = true.
Can someone test if #9625 with set display_force_sw_blink = true fixes it for msp displayport?
This is happening in analog too for some people
Does it happen in analog when you set display_force_sw_blink = true ?
The FC I use requires display_force_sw_blink = true.
What kind of fc/osd are you using?
Can someone test if #9625 with
set display_force_sw_blink = truefixes it for msp displayport?
@mmosca Test with MSP displayport using display_force_sw_blink = ON. And placed 34 OSD characters on the screen.
It now works great. With all items in a warning state, blinking at a constant rate. Just under 1Hz.
This was using Avatar. Of which I knew more than 20 previously caused a noticeable slowing of the warning blinking rate.
This is happening in analog too for some people
Does it happen in analog when you set display_force_sw_blink = true ?
The FC I use requires display_force_sw_blink = true.
What kind of fc/osd are you using?
Matek F405-Wing, F411-Wing and F411
Can someone test if #9625 with
set display_force_sw_blink = truefixes it for msp displayport?@mmosca Test with MSP displayport using
display_force_sw_blink = ON. And placed 34 OSD characters on the screen. It now works great. With all items in a warning state, blinking at a constant rate. Just under 1Hz.This was using Avatar. Of which I knew more than 20 previously caused a noticeable slowing of the warning blinking rate.
It should be 200ms on, 200ms off, so sounds right.
Rebased to INAV 7.1.0, so it gets added in the next release.
Please test #9627 instead of #9625
Not sure if this is related or can help https://github.com/iNavFlight/inav/issues/8574
Rebased to INAV 7.1.0, so it gets added in the next release.
Please test #9627 instead of #9625
@mmosca Tested what you merged today. The issue still remains. I have 23 items on the screen. The flashing cycle is 14s ON, 14s OFF. Much too slow for a warning.
Did you change the setting in the cli?[]s,Marcelo Bezerra @.>On 14 Jan 2024, at 00:26, rts18 @.> wrote:
Rebased to INAV 7.1.0, so it gets added in the next release. Please test #9627 instead of #9625
@mmosca Tested what you merged today. The issue still remains. I have 23 items on the screen. The flashing cycle is 14s ON, 14s OFF. Much too slow for a warning.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
Did you change the setting in the cli?
I set display_force_sw_blink = ON and even set it to OFF; with no change being detected.
I conducted some tests with commits db207a1 and 455dcf2 to double check.
From my observations it appears another timer is influencing the blink timer.
My OSD item count is typically in the mid twenties.
When the item count is configured below 20 or above 33. The flashing cycle is 1Hz as expected. But if set within the range of 20 to 33. The flashing cycle slows to a minimum of 14s ON, 14s OFF with 26 items.
I considered osd_msp_displayport_fullframe_interval may be causing timer coupling. But it changed nothing. Tested range was from 0.1s to 10s.
Testing was conducted with WTFOS HD.
Wtfos updates the osd in a fixed interval that may interact badly with inav’s blink. You can try changing msp osd _update_rate_hz[]s,Marcelo Bezerra @.>On 14 Jan 2024, at 04:13, rts18 @.> wrote:
Did you change the setting in the cli?
I set display_force_sw_blink = ON and even set it to OFF; with no change being detected. I conducted some tests with commits db207a1 and 455dcf2 to double check. From my observations it appears another timer is influencing the blink timer. My OSD item count is typically in the mid twenties. When the item count is configured below 20 or above 33. The flashing cycle is 1Hz as expected. But if set within the range of 20 to 33. The flashing cycle slows to a minimum of 14s ON, 14s OFF with 26 items. I considered osd_msp_displayport_fullframe_interval may be causing timer coupling. But it changed nothing. Tested range was from 0.1s to 10s. Testing was conducted with WTFOS HD.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
Increasing DJI WTFOS osd_update_rate_hz by an extra 10 had no effect.
What I reported in my last post rang true of my testing with the Avatar HD system as well.
Much talk (understandably) about DJI and Avator, but is there a build which is expected to work with HDZero (the subject of the original issue). If so I can try to test ? Thanks for looking into this.
The change has been merged into 7.1, so you can either use the build from the PR checks or built 7.1 from the release_7.1.0 branch.
On Sun, Jan 14, 2024 at 3:54 PM MartinHugh @.***> wrote:
Much talk (understandably) about DJI and Avator, but is there a build which is expected to work with HDZero (the subject of the original issue). If so I can try to test ? Thanks for looking into this.
— Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/9552#issuecomment-1890974572, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFTWX5F4OUP5TESFFMQLIJLYOPWTRAVCNFSM6AAAAABANOLYE2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJQHE3TINJXGI . You are receiving this because you were mentioned.Message ID: @.***>
The change has been merged into 7.1, so you can either use the build from the PR checks or built 7.1 from the release_7.1.0 branch.
I built branch release_7.1.0 and flashed to FC, target MATEK405TE. I was running this with a HDZero Race 2 VTX flashed to 1.5.0
I set the LQ alarm so that the icon would flash, and this is a desktop test rig, so has no GPS and that icon was flashing too.
With display_force_sw_blink = OFF Both icons flashed 1s displayed, 1s hidden
With display_force_sw_blink = ON Both icons flashed 1s displayed, 1s hidden (no change)
I am not sure this flag is having any effect in my case.
The flash frequency is too slow at the moment this probably needs to be flashing (equal mark:space) at 3-5 times a second to be of use.
Thank you for your work on this so far.
Same issue on analog with display_force_sw_blink = ON:
INAV 7 MATEKF411TE 2 seconds on, 2 seconds off INAV 6.1 MATEKF411SE 6 seconds on, 6 seconds off
Can you please test with 7.1 RC1?
This has been fixed by https://github.com/iNavFlight/inav/pull/9644 .. It now works much better. You can use it for inflight tuning with HD. And still have a consistent blink rate, when the screen is loaded up with characters.
This has been fixed by #9644
that's why I asked to test it for confirmation but if you are sure its fixed, I'll close.