This is a ‘close relative’ to the ‘eternal boot screen’. It is also caused by the all-mighty triggering system, which governs the whole oscilloscope – even when it shouldn’t. One of the most annoying things is that this can block / halt screen updates and make the thing completely unresponsive to ANY user input – except the power switch.
How to reproduce:
Set the timebase to a large value (say 50s/div) and press the ‘AUTO’ button. The scope will be bricked for 10 minutes!
ah, the can’t walk and chew gum simultaneous problem….
many a scope has this problem. they need to fill the acquisition buffer FIRST halfway and then they start crunching…. bad signalpath design.
It is just terribly stupid.
I would have imagined / expected that the user interface is completely separate from DAQ and processing. The least thing they could have implemented is to abort whatever the thing was doing once a user chooses to hit a button or turn a knob. Most likely there is a reason to change things…