-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OSD flashes very slowly (Warning) when there are many OSD items added #9552
Comments
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) |
This isn't new. Its been a problem since 6.0.0 on all my HD systems. |
Agreed, but it is still a problem whether old or new and needs looking at. |
Exactly what I see. |
I went to report this bug, but I see it's already been raised.
@MrD-RC @mmosca Is there a chance a repair could be made for this before 7.1.0? |
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 |
What kind of fc/osd are you using? |
@mmosca Test with MSP displayport using This was using Avatar. Of which I knew more than 20 previously caused a noticeable slowing of the warning blinking rate. |
Matek F405-Wing, F411-Wing and F411 |
It should be 200ms on, 200ms off, so sounds right. |
Not sure if this is related or can help #8574 |
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: ***@***.***>
|
I set I conducted some tests with commits 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 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 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 ? |
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
<#9552 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFTWX5F4OUP5TESFFMQLIJLYOPWTRAVCNFSM6AAAAABANOLYE2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJQHE3TINJXGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I built branch release_7.1.0 and flashed to FC, target MATEK405TE. 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 With display_force_sw_blink = ON 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 INAV 7 MATEKF411TE 2 seconds on, 2 seconds off |
Can you please test with 7.1 RC1? |
This has been fixed by #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. |
that's why I asked to test it for confirmation but if you are sure its fixed, I'll close. |
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.
The text was updated successfully, but these errors were encountered: