Closed dzid26 closed 2 years ago
Did you try also different trigger modes when the screen was not visible? In your 1st picture I see "Normal" mode, that doesn't display anything unless a valid trigger condition is met (top left TR
turns green), while 2nd picture shows "AUTO", where you see always the trace, even without trigger condition (TR
stays red).
Ohhhhhh.
That explains a lot. It probably was just defaulting to Normal mode on newer versions.
I don't know how I managed to never learn this behavior, but to my defense - showing an empty screen is never good for the UX. :) It gives the impression that something isn't working. But I guess it's a legacy thing.
Maybe we could improve that experience a bit?
...Because I did that mistake again yesterday even when doing measurements - I must have pressed Normal mode and didn't realize it. Then to recover from the empty screen I was trying to press Pause/Play. But since the screen was empty, my immediate thought was that the thing broke again.
I think that is why physical scopes have deliberately separated Run/Stop LED showing the state of the scope. It becomes straightforward to realize the scope is halting the display.
showing an empty screen is never good for the UX. :) It gives the impression that something isn't working. But I guess it's a legacy thing.
The screen is not empty, it gives a lot of info - triggered/not triggered in clearly assigned colours, run/stop, and some more. But you're right when you say something isn't working, the trigger is missing :)
... if the Auto mode was a default mode after pressing the Play button.
Nope, normally you don't have to press play, the scope starts running automatically. And when I press Pause and then Play again, the scope is supposed to be in exactly the mode I selected before. I don't believe in well-intentioned automatisms, just "make it as simple as possible, but not simpler".
Another option would be to rename TR to more meaningful STOP and RUN that would display in red and green. I think that is why physical scopes have deliberately separated Run/Stop LED showing the state of the scope. It becomes straightforward to realize the scope is halting the display.
I disagree, TR just means triggered (green) or not triggered (red).
It has nothing to do with RUN/STOP, this is an extra button (||
/ >
) that shows exactly the RUN/STOP state.
The NORMAL mode (also on real physical DSOs as well as on the old CRT analog scopes functions like this: If the trigger condition is met the trace is updated, otherwise not. This makes absolute sense - the screen shows the status at the last trigger condition. But what should be displayed if there has never been a trigger? If you want to see always some traces - just use AUTO. And finally, there is also the SINGLE mode, which stops with the 1st trigger and freezes the screen, so that you can better analyse more complex structures (e.g. serial data, UART, I2C etc.) without a changing display all the time.
I understand - it works as intended.
One thing to consider though, this plug'n'play scope but in OpenHantek it is not straightforward to discern whether the scope is frozen due to a trigger or an interrupted USB connection or something else. Perhaps it would be good to show a dedicated text on status bar that the data is being received to avoid double-guessing.
But what should be displayed if there has never been a trigger?
I would actually just show the running signal. Like for the Single mode. At least setting the right trigger level would be quicker.
This makes absolute sense - the screen shows the status at the last trigger condition.
This would make total sense if the mode was called "Refresh on the trigger". It's called "Normal", so it better be intuitive :D. I know, I know - read the manual; learn the scopes, etc...
In the end, it doesn't matter, I am sure people will figure it out.
Describe the bug The signals plot/scope doesn't show up after upgrading to 3.3.1 release.
Reproduce Install drivers and open the new app.
Screenshots
Computer environment (please complete the following information):
Scope device (please complete the following information):
It took me a while to figure it out. Before I was using the 3.2.5 version with FW0209 firmware. I wanted to update to 3.3.1, but that issue didn't let me use it. I thought something with the drivers, because other people were complaining. No. I tried other 3.3.x version. The only ones that worked with FW02010 were 3.3.0-RC3, RC2, and RC1. I thought something is wrong with the latest releases 3.3.1.
Fix
In the end the fix was easy. I just reset settings to default. After that, all the versions started to work.
So there is something wrong with reading the old settings in 3.3.1. Not sure if this is worth further investigation.