Reading this topic reminded me of a quote that I recall but can't find it again, I recall it was Chuck Yeager at an airshow - a P51 was being compared to a modern jet and someone was extolling the virtues of the P51 - his reply was to the effect of - don't get sentimental - old gear is fine for restoration - but almost always the most modern is the best - something like don't bring a knife to a gun fight.
I think the "almost always" is the key here. The strategists inebriated with the newfangled technology of radar seeking fitted their F4 Phantoms with AIM-7s only and removed the ancient machine gun tech. As per McNamara's words: “…being equipped with a gun is as archaic as warfare with a bow and arrow.”
When talking about menus and such, the interface of older technology tends to be much more accessible - after all, the options are entirely enclosed in the front panel and not hidden under tabs, drawers, doors, etc. (the physical equivalent of soft menus).
The problem is how to aggregate the plethora of new options in such small panel. Sure, a Tek 555 sized gear could probably have enough real state to accommodate all the options in a DS1054Z.
That's a significant issue, of course.
Dual beam and dual time base with delayed sweep would be easy enough to implement in a DSO. Not cheap, but certainly easy. People instead make do with really deep memory.
Dual beam is implemented simply by having a single ADC for every input channel. It only costs more and requires more memory bandwidth.
You definitely don't want to play around with altering the ADC clock rate. Any mechanism to do that would add jitter, and that's a no no.
You could implement a delayed sweep by simply not clocking data into memory until the relevant number of samples after the trigger occurred, but that would mean you couldn't see the pre-trigger data thus losing a major advantage of digitising scopes. Avoiding that requires storing all the incoming samples in case a trigger arrives later, and that might mean a deep memory. But memory is cheap, so that's a good tradeoff.
Early digitising scopes used a CCD to sample and store the waveform, typically limited to the 1024 samples shown on a screen. Such shallow memory was a necessary evil, but is of limited use and should be avoided.
It takes more than just an ADC per input to implement dual beam functionality. For each ADC there should be an independent time base and triggering circuitry. A dual beam scope is really two separate scopes that share only the phosphor on the CRT. Well, and power supplies I suppos.
With delayed sweep you see two traces for each input: The main trace with the A timebase, and an expanded trace running at the faster B timebase. The portion displayed by the B timebase trace is intensified on the A timebase trace which gives the context. Note that the dual time base feature exists for single as well as dual beam scopes.
For those of us that grew up with dual time base scopes, it is second nature to pull the time/div knob and rotate it clockwise to get the faster B sweep speed.
Why do you ask is more important ?
I use one. But is it time to upgrade to DSO now?
You currently have no ability to capture a single shot or non-repetitive waveform and analyse it. That an enormous gap in electronics troubleshooting.
That's the killer use case for a storage scope.
But I've found it far less useful that many people claim. Why? Basically I can usually make my tests repetitive - and that's necessary during development.
The one case in the past few years when I really needed a storage scope was to look at PSU turn-on behaviour. Ironically that was in an old Tek 485 with a dodgy PSU; I could only do one test every 12 hours.
When talking about menus and such, the interface of older technology tends to be much more accessible - after all, the options are entirely enclosed in the front panel and not hidden under tabs, drawers, doors, etc. (the physical equivalent of soft menus).
The problem is how to aggregate the plethora of new options in such small panel. Sure, a Tek 555 sized gear could probably have enough real state to accommodate all the options in a DS1054Z.
That's a significant issue, of course.
It is not an issue at all; modern DSO interfaces (and other test instruments) are just poorly designed.
I would be happy if someone made a DSO with the advantages of an analog oscilloscope and a good user interface but nobody even bothers even though I know it is possible.
I am slowly working on my own design but more for fun than any practical use.
2) Can see things which DCOs have great difficuly in seeing. Like AM RF or a mild 25Mhz oscillation in a power amplifier on a particular part of 1kHz sinewave... .
You currently have no ability to capture a single shot or non-repetitive waveform and analyse it. That an enormous gap in electronics troubleshooting.
That's the killer use case for a storage scope.
2) Can see things which DCOs have great difficuly in seeing. Like AM RF or a mild 25Mhz oscillation in a power amplifier on a particular part of 1kHz sinewave... .
I don't see the difficulty. Even entry level scopes have nowadays 10M+ sample memory so if you make a 10ms capture (10 periods of the 1kHz signal) with 1GSa/s it fits into memory and can check both the 1kHz and 25MHz signal.
More advanced DSOs can have even more memory.
Note: In my view (and limited experience) it helps a lot also if you know what to expect (to trigger properly) or in other words you know what to look for.
With delayed sweep you see two traces for each input: The main trace with the A timebase, and an expanded trace running at the faster B timebase. The portion displayed by the B timebase trace is intensified on the A timebase trace which gives the context. Note that the dual time base feature exists for single as well as dual beam scopes.
For those of us that grew up with dual time base scopes, it is second nature to pull the time/div knob and rotate it clockwise to get the faster B sweep speed.
It is worth mentioning *why* delayed timebases existed. It was for more than a magnified view.
Delayed timebases implement "slideback" measurements which are more accurate than counting divisions on the CRT. That is why the delay control either has calibrated markings or a readout of delay time. If you align a waveform feature on the graticule and then align a second waveform feature on the graticule, then the difference in the delay control settings is the duration between the waveform features. This measurement has higher accuracy because it does not rely on CRT calibration or linearity. Some later instruments supported dual *delta* delay timebases which displayed two separate delayed sweeps allowing the direct readout of the time or frequency.
DSOs never really needed delayed sweep for measurements so it eventually became rare. They could use cursors or automatic measurements.
You currently have no ability to capture a single shot or non-repetitive waveform and analyse it. That an enormous gap in electronics troubleshooting.
That's the killer use case for a storage scope.
I agree; easy single shot acquisitions are a killer feature of a digital storage oscilloscope if you need it. Analog storage can do it also of course but it is not nearly as easy to use and I would never recommend it.
snip
I could count the number of times I had to use a delayed timebase in the described manner on the fingers of one hand.
Working in Television, there was always a known source of timing reference available in the video waveform itself.
If you are finding a "glitch" that was not inherent to the original signal absolute accuracy was not all that important.
I'm not disputing the original reason for delayed sweep, more pointing out that many users found the other advantages of this facility of primary importance.
I could count the number of times I had to use a delayed timebase in the described manner on the fingers of one hand.
Working in Television, there was always a known source of timing reference available in the video waveform itself.
If you are finding a "glitch" that was not inherent to the original signal absolute accuracy was not all that important.
I'm not disputing the original reason for delayed sweep, more pointing out that many users found the other advantages of this facility of primary importance.
Video is where "trigger on delay" is especially useful. Trigger on delay allows the delayed sweep to track the signal so you can count the sync pulses and then start the sweep synchronized at a specific point of the video signal without any jitter.
That's the killer use case for a storage scope.
But I've found it far less useful that many people claim. Why? Basically I can usually make my tests repetitive - and that's necessary during development.
The one case in the past few years when I really needed a storage scope was to look at PSU turn-on behaviour. Ironically that was in an old Tek 485 with a dodgy PSU; I could only do one test every 12 hours.How would you make something like button bounce reliably repetitive?
That's the killer use case for a storage scope.
But I've found it far less useful that many people claim. Why? Basically I can usually make my tests repetitive - and that's necessary during development.
The one case in the past few years when I really needed a storage scope was to look at PSU turn-on behaviour. Ironically that was in an old Tek 485 with a dodgy PSU; I could only do one test every 12 hours.How would you make something like button bounce reliably repetitive?
Right tools for the job. Use a universal counter for debouncing stuff