Fast, efficient UIs are something that the computing field at large has known how to implement for decades now. Scopes today are executing on hardware that is equivalent in speed to state-of-the-art computers of perhaps a decade ago, if not less. So it's not like the necessary horsepower isn't there.
All true but one cannot forget that scopes are realtime devices that have timing constraints all around.
So, it's not only a matter of doing all things a lot faster. It's all about fulfilling the preemptive multitasking within a certain timeframe, be it at 1 MHz or 1 THz.
And that would matter
if the realtime nature of the scope needed to be maintained as the controls are manipulated.
But it doesn't. When you manipulate the controls of the Siglent, it
throws away the history. This is because the capture parameters are being changed. As such, the realtime characteristics no longer need to be maintained. In fact, some scopes stop all processing altogether while it handles the UI, precisely because their manufacturers recognize that manipulation of the UI means that the user wants to change something, which means that the realtime processing is no longer relevant.
Furthermore, what we're talking about here is a
tiny amount of processing, namely that which is sufficient to see and record the control changes. Nothing more. Remember that the scope executes
billions of instructions per second
per core, and the number of instructions necessary to record the control changes is in the thousands of instructions range, which means that the amount of wall clock time that should be necessary for this operation should be in the microseconds range (at most! In reality, a properly optimized control recording mechanism would be hundreds of instructions long, not thousands).
The problem here isn't that the scope's display isn't keeping up with the controls, it's that it's
dropping control events on the floor.
Assigning a high priority to the manual encoder just so that it doesn't loose a click may be a nightmare when we have tens/hundreds of other more important tasks.
The user is making changes on the scope. What in the world is more important than recognizing and responding to those changes?
In fact, nothing prevents the manufacturer from stating up front that if the user wants the scope to faithfully and reliably perform captures and analysis of the captures, then he must refrain from manipulating the controls. Given the fact that, firstly, the amount of processing required to capture and record the control input events is comparatively tiny and, secondly, the trigger re-arm time is
itself present and variable, I see no justification for insisting that the scope drop control events on the floor even if the processing wasn't going to be thrown away anyway.
Of course we can buffer the encoder BUT, in my book, I also don't like to see all the buffered movements appear in rapid sequence just because they had been accumulating in the buffer, and now they got their turn.
The proper approach to processing of buffered movements is to consolidate them and to make the appropriate changes after consolidation. End result: multiple "clicks" of the encoder, but one actual change to the scope. For instance, if it buffered 3 "clicks" of the timebase, it would immediately make a 10x change to the timebase.
Since I had no way of knowing how the buffering was working, the most probable thing that would happen is that I would over turn the encoder just because I didn't have any type of visual feedback.
But you have
tactile feedback. That's the whole point of the detents!
Providing a lossy feedback, where we loose some clicks, is sometimes the best compromise between the gamers that became TEA and the retirees who have all the time in the world to rotate an encoder at 1-click/sec.
I don't see how. From the user's standpoint, dropping events on the floor doesn't gain you any advantages and makes the response of the scope
unpredictable. A piece of equipment that's unpredictable in how it responds is a piece of equipment that you have to pay an inordinate amount of attention to when manipulating it. If you don't believe me, try typing on something that randomly drops your keypresses. I guarantee you'll find it a frustrating experience.
In fact, Siglent's very own implementation already negates your entire argument. It does
not drop mouse movement events on the floor. The mouse pointer can sometimes be seen to be updated less often when there's a lot going on (e.g., the FFT is going), but that movement still faithfully tracks your mouse movement itself. This proves once and for all that the scope has the capability of buffering control events properly.
Home
Help
Search
Login
Register
