enter the required delay in the time field of the Navigate function
But how often do we actually know the required delay? I guess not so often?
As long as you have an idea where you want to go, a quick look at the main window will tell you the required delay. But of course, this are mostly outdated methods, since a simple double-touch/click on the desired position in the main window is the fastest method to position the zoom window nowadays.
That lagging in the zoom function currently renders it kinda usless (its pretty bad sometimes). Have you encountered this behaviour?
I was inclined to say "absolutely no", but then actually experienced a moment of confusion this morning, when I played with the zoom. Positioning the zoom window worked fine, yet any signal change exhibited a pretty bad delay. The word "unusable" actually came to mind in this situation.
I was about filing an error report, but thankfully took a closer look and noticed that the scope did not trigger continuously. Only when I doublechecked the trigger settings, I realized that I had accidentally left the trigger holdoff at 30 seconds after some test yesterday evening.
After disabling holdoff I can state without any doubt that the zoom function absolutely doesn't exhibit any lag within the usual working conditions. Only at 100 Mpts record length (and a rather extreme zoom ratio of 2 million: 10 ms/div main, 5 ns/div zoom), there was some noticeable lag, yet far from “unusable”.
With a max. record length of 10 Mpts, there’s absolutely no lag. And even with 40 Mpts it is still barely noticeable. Only 100 Mpts slows down considerably.
Maybe I should take the opportunity to put a friendly reminder for all those who might not be aware:
No deep memory DSO/MSO will do its processing (math, measurements, protocol decoding…) on the full memory, even less so in this class of instruments. In any case, the data gets decimated internally when the record length exceeds a certain limit, and this is not reflected by the sample rate display (for the Siglent it’s in the Timebase tab).
An extreme example would be the once popular Rigol DS1000Z which only processed the screen buffer (~1000 points).
For the SDS800X HD, this limit is 10 Mpts. This means that the effective sample rate for measurements, decoding etc. drops to e.g. 1/10 of what is displayed in the Timebase tab whenever the max. record length of 100 Mpts is utilized. Not only does this compromise measurement accuracy and decoding results, but it also takes additional time for the decimation of the massive amount of data.
In order to be able to rely on the displayed sample rate for math, measurements and decoding, everyone should limit the “Max Mem Depth” (actually it should read “Max Rec Length”) to 10 Mpts in the Acquire menu, whenever accurate signal processing or analysis is to be accomplished. The longer memory settings are for less demanding tasks like just viewing and maybe old-fashioned cursor measurements.
And the ones who might try to tell me that this is a bug – or at least a bad thing – should go and buy a Keysight, LeCroy, R&S, Tek or any other serious brand DSO. Oh, wait, that might prove difficult – for the price of an SDS800X HD they might not even get a Can decoder license from these brands.
Just to put the performance of the SDS800X HD into perspective: for the very successful and well regarded Keysight Megazoom series, the before mentioned limit of undecimated analysis capability is 32 kpts (in some situations up to 62 kpts) – and even if they’d process the entire memory, this wouldn’t help either, since their max. record length cannot even come close to 10 Mpts.