oscilloscope performance at slow <1 Hz signals

Question

My question needs a little background, I apologize for this in advance.

I have slowly changing signals typically in the 0.1 - 1 Hz which I want to observe on a scope. I'm measuring things like slowly-changing temperatures.

When making any change on the scope front panel while observing slow signals here are the 3 types of scope responses I've observed:

1. The scope screen freezes for 6-12 seconds before it "comes alive" again and shows the moving trace. I have observed this behavior in a Rigol 1054Z and Keysight DSO-1002A.

2. Scope clears the screen and immediately starts a new trace from the edge of the screen. But no 6-12 second dead time. I see this behavior in an Instek GDS-2104E and an Instek GDS-1054B.

3. Scope immediately performs the front panel setting you made and simply carries on with the display at the new setting: No 6-12 second dead time, no blanking and restart of the trace. Just keeps going. This is the best behavior of course, and I see this on a Tek DPO-3034 and Tek TDS-2012.

My Question is: How do I refer to this behavior, that is, what do I call it? If I'm talking with an apps engineer at an instrument company and I want to know if their scope handles this scenario (slow signal display) according to options 1, 2, or 3 above, what do I ask??

I've searched here and on oscilloscope forums and I don't see this feature of scope operation addressed. Is this addressed in the spec sheet for a scope? What do I look for? I know most folks don't care much about how well a scope goes slow; we want them to go fast, right? ;-) But I would appreciate if anyone could point me to where I can find some answers...

Thanks all, and again sorry for the long-windedness.

Answer 1

What's happening in #1 is that the scope is acquiring data on the left hand side of the screen, then switches to real-time (ish) plotting on the right hand side of the screen.

When you set a trigger point on the oscilloscope, you are basically saying that you want the trigger event to be at the middle of the oscilloscope screen. So, that means the scope has to acquire half of the data before the trigger event occurs. What that means, is that the scope has to have a continuous buffer that has to store info in case a trigger event pops up afterwards. So, it uses a rotational buffer to make sure that it has the data it needs when it needs it.

So, the "dead time" is going to be the duration of the left half of your screen. At 1 second/division on a Keysight DSOX1002A you'll have a delay of 5 seconds while the scope captures buffer data. Then (in auto trigger mode), the scope will automatically trigger and plot out the second half of the data.

2: For the Instek, it sounds like they are simply saying "forget it, we haven't found a valid trigger, grab new data. And, if a valid trigger event occurs we'll maybe catch it next time" The Keysight (and other rotational buffer based oscilloscopes) will give you the trigger where you want it if it happens to pop up in the 1st half of that data collection. Instek won't read it as a trigger (to my knowledge).

3: Tek has an interesting philosophy on this. From a Keysight standpoint, I appreciate that what you see is what actually happens. For example, if I change the V/div setting, I don't want to see old signal on screen that was captured at a different V/div setting. It's a philosophy thing more than anything. In fact, you'll see this for acquisition modes too. For example, if you are in High-res mode and change a V/div or time/div setting, the oscilloscope will actually re-run the high-resolution plotting algorithm on the same data. It's done in hardware, so there's not noticeable delay. Tek, on the other hand, will just keep the old plot because their plotting is a software/processor thing and can take a while under certain circumstances.

I hope that all makes sense! I highly recommend trying roll mode, no delay!

Answer 2

As a Test Engineer over the last 40 yrs I have seen this behavior before. But with my design experience, I can only hypothesize why this can occurs.

It is neither a feature nor a bug but perhaps an artifact of very high RAM storage per point and extremely slow time base with determination that all historical data is preserved even during a sweep.

Samples per time interval will change with sampling rate if sweep rate if samples per visible point must be changed to utilize the memory available. This amounts to storing way more data than is displayed so you can zoom like a microscope in time even during a a slow active trace.

So does the designer toss the memory when the sweep rate is changed?
Does the CPU add a timestamp to each conversion so that slow sweep rate changes mid-stream can be displayed in the correct timebase, regardless of how slow? Does the CPU have to decimate memory to avoid wasting RAM with a timestamp? so that samples have a fixed sample time interval in memory?

But what if the memory is 8 GBytes worth and you know how long that takes to retrieve from a PC during a wakeup from hibernation loading the disk file into DRAM.

Scope trace memory is meant to be preserved even if the sweep rate is changed but does the scope have the CPU bandwidth to decimate GB of memory due to a quick flip on the sweep? Probably not.

But TEK got it right with strip chart mode where user response time is paramount too , where the trace buffer is a FIFO of continuous time like a cardiac trace.

Ask the others if they have the option to abort a trace capture if the time scale is longer than X seconds so that display refresh time is minimize during a rescale on a long sweep. THis requires a timestamp and more memory.

Or compare how many MB's per point and note which input changes are the slowest then compare datasheets for "Decimation Modes"

'Decimation' might say '1-n Decimation', then there is Peak-to-Peak Decimation (also called 'Peak Detect Decimation', again not the same as Peak Detect Acquisition Mode), Decimation by Binning, Decimation by Resampling, Rho mean square Decimation, and a few others.

They all have in common to reduce the amount of data and the effects on display buffer refresh time.

You don't care about glitch detection so, 1-n Decimation is the preferred method for your DSO choice. But you probably want long trace buffer memory so that slowest capture rates can last the longest without tossing the memory each time you make a change.

So stick with the TEK models you have. The details get complicated by the fact that anti-aliasing is critical to prevent glitch artifacts at low frequency due to signals that get past the Nyquist adaptive filter that changes with each sampling rate. LeCroy used to have deep memory but limited sampling rates to simplify screen decimation without losing data captured.

I am trying to fix a buddy's old 150MHz LeCroy now which used only 2 sampling rates. Slow (40MHz ) and fastest possible. tons of math features, statistics, binning, auto-calibration , fast and easy to use, but this has a glitch that stops the clock and CPU.