Choosing between entry-level 12-bit DSOs

[tggzzz]

• GUI responsiveness. One scope I played with for a short time had an appalling lag between changing the Y offset and the trace on the display moving

Rigol DHO800 sucks in this respect. My definition of "sucks": the waveform update freezes and remains stopped while the vertical (or horizontal) offset encoder is being turned. Analog scopes do not suck: you can turn the offset dials for as long as you want, and the trace(s) will continue to update in real time as if nothing is happening. Do any digital scopes behave this way too?

After the offset encoder stops turning, the waveform update/rendering on DHO800 resumes in what feels to be about 300-400 ms.

p.s. I may have misunderstood the meaning of your question. If you ask how quickly the screen content moves when an offset encoder is turned, then it happens nearly instantly, so in this particular function DHO800 does not suck. With one exception: when you scroll along a large memory buffer with the zoom window turned on, then it becomes somewhat slower (yet still acceptable even to my taste), and sometimes it's glitching when the offset is at the edges of the memory buffer.

My question was a general one.

The example I hinted at sounds like the DHO800 freeze you mention. Made it very difficult to align a waveform minimum with a graticule line.

[shapirus]

The example I hinted at sounds like the DHO800 freeze you mention. Made it very difficult to align a waveform minimum with a graticule line.

Not exactly difficult per se. It is easy, but tedious, as it may require multiple steps (turn the dial - see result - repeat if necessary), which take time and effort.

[ebastler]

Rigol DHO800 sucks in this respect. My definition of "sucks": the waveform update freezes and remains stopped while the vertical (or horizontal) offset encoder is being turned. Analog scopes do not suck: you can turn the offset dials for as long as you want, and the trace(s) will continue to update in real time as if nothing is happening. Do any digital scopes behave this way too?

I think this is the common way of implementing it; certainly all entry-level scopes I have used or seen demonstrated in videos behave the same.

As long as the frozen trace follows the encoder movement smoothly and with little lag, I don't find that too bad: You can still position the frozen trace nicely relative to the grid and to the other traces. It would be much worse if they tried to continue "live" updates of the trace, but with a jerky movement. 

[shapirus]

I think this is the common way of implementing it; certainly all entry-level scopes I have used or seen demonstrated in videos behave the same.

Yeah I realize it may be because of limited hardware capabilities. On the other hand, for a comparison, computers have no issues whatsoever with smoothly playing a movie in a player window that is being moved in any direction on the screen without any freezes and interruptions. They have been able to do so for at least past 20 years, and modern oscilloscopes definitely have much more capable hardware than a 20 year old PC, so I'm inclined to see no plausible excuse here.

I wonder how the more expensive scopes behave in this regard.

[tggzzz]

The example I hinted at sounds like the DHO800 freeze you mention. Made it very difficult to align a waveform minimum with a graticule line.

Not exactly difficult per se. It is easy, but tedious, as it may require multiple steps (turn the dial - see result - repeat if necessary), which take time and effort.

In that case you must think measuring a voltage with a KVD-based null voltmeter is easy but tedious



Personally I think it is difficult but fun, so long as I don't have to do it regularly.

Mind you, it is my only 1kV voltmeter with "infinite" input impedance.

[Phil1977]

Yeah I realize it may be because of limited hardware capabilities. On the other hand, for a comparison, computers have no issues whatsoever with smoothly playing a movie in a player window that is being moved in any direction on the screen without any freezes and interruptions. They have been able to do so for at least past 20 years, and modern oscilloscopes definitely have much more capable hardware than a 20 year old PC, so I'm inclined to see no plausible excuse here.

I wonder how the more expensive scopes behave in this regard.

How many millions of man-years for development went into nowadays GUIs with smooth video playback? How many thousands of man-years are spent for developing test equipment, and how many of these development hours are spent for smooth playback and how many are spent for e.g. signal processing?

I think it´s the same if you compare the UI of an Amazon Fire stick with the UI of a modern car. Though the car costs 1000x more than the fire stick, the UI of the fire stick is smoother and more intuitive and responding quicker etc. And no, the car OEMs do not want to sell bad UI's, but the amount of development budget for these topics is just smaller.

Maybe the numbers I guessed are wrong, but I'm quite sure their general context is not.

[core]

There are some aspects of the Rigol DHO800 that I like and use all the time, like displaying multiple windows

BTW, Rigol cannot (or I don't know how to make it) render the math waveform in the main waveform window, which defeats half of the purpose:

good point, i just tried it myself, overlayed display sometime preferable, sometime i wonder the rigol GUI developer is a kid clueless about real life usage of dso... maybe posting in rigol dho800 bug/wishlist if good idea to make rigol aware of this issue..

On DHO1074 you can select overlay on the main window for any Math function.
In the math window config,  just move the "Display Area" selector from "Math" to "Main". The Math window will dissapear.

I suppose that DHO800 have this option. Sorry if I am wrong.

[core]

As far as choosing an entry level DSO, to be honest, either of these two (DHO800 or SDS800) are more than enough for the usual stuff.
If you need more, then you need to spend more (a lot) of money.

There are both advantages and disadvantages on both sides, but not as major as some are letting on. Choose the one you like by taking into account the reviews you can find here and on youtube.

I have scopes from both manufacturers, and I can't say that Siglent is better than Rigol or vice versa. It's just details, and I use both with equal pleasure.

If I were to choose one scope for any task, it would be much more expensive and I don't think it would be worth buying just for the hobby.

[2N3055]

I think this is the common way of implementing it; certainly all entry-level scopes I have used or seen demonstrated in videos behave the same.

Yeah I realize it may be because of limited hardware capabilities. On the other hand, for a comparison, computers have no issues whatsoever with smoothly playing a movie in a player window that is being moved in any direction on the screen without any freezes and interruptions. They have been able to do so for at least past 20 years, and modern oscilloscopes definitely have much more capable hardware than a 20 year old PC, so I'm inclined to see no plausible excuse here.

I wonder how the more expensive scopes behave in this regard.

They behave mostly the same. Faster than that but in similar fashion.
Let's not forget that scope does many other things in addition to showing stuff on screen.
Moving trace up and down invalidates most measurements etc...
So scope simply waits for a user to make up their mind.

I can understand that this might be something that aesthetically annoys you in comparison to analog scope, but what practical problem does it create for you?

Scope freezes current display that serves as reference of what are you moving up and down.
It is not like it goes blank and you have no idea what are you moving.
And that movement is instantaneous on most new scopes.

So nobody cares. Maybe it might have been done the way you prefer but nobody cares. It is good enough as it is.

[2N3055]

There are some aspects of the Rigol DHO800 that I like and use all the time, like displaying multiple windows

BTW, Rigol cannot (or I don't know how to make it) render the math waveform in the main waveform window, which defeats half of the purpose: you can't overlay traces on the same scale and you lose half of the screen height by placing the windows one above the other if you want to observe raw and math input aligned horizontally.

It also cannot use math result waveform as one or more of the X-Y sources. It cannot use math result as a source for another math operation. So the usability of math is quite limited.

Is all of this also the case with Siglent? Or it's a general limitation? If so, is it a limitation in this class only or it applies to all digital scopes?

On Siglent touch scopes, math channels are treated as full channels in main window.

[Fungus]

I had the DHO814, and i was very frustrated:
- At least one crash a day. (gotta love android)
- Waveforms dissappear when scrolling around.

Firmware 1.0 was a long time ago.

[Mechatrommer]

I think this is the common way of implementing it; certainly all entry-level scopes I have used or seen demonstrated in videos behave the same.

Yeah I realize it may be because of limited hardware capabilities.

but i think with multicore cpu, it should be possible to dial X or Y offset while signal continue like nothing happens. in my theory, signal stream from FPGA can be assigned to one core, and UI update is assigned to another. maybe they havent figure it out, or maybe its true hardware limitation 

[Fungus]

It's orders of magnitude better, it also has tables of the peaks, etc.

But it cannot, for whatever reason, display the peak values on top of the peaks themselves, right in the FFT window

Can the Siglent? All the screenshots I've seen only show a table overlaid on the display.

Not to mention that the user has to waste a significant section of the screen for the window with the peaks table.

Doesn't seem to be a problem in practice. At least you get to choose where it goes on screen.

Again: If you live and die by FFTs then I don't think either is ideal. Get a proper oscilloscope.

[core]

I had the DHO814, and i was very frustrated:
- At least one crash a day. (gotta love android)
- Waveforms dissappear when scrolling around.

Firmware 1.0 was a long time ago.

These problems are certainly gone today 

[Mechatrommer]

How many millions of man-years for development went into nowadays GUIs with smooth video playback? How many thousands of man-years are spent for developing test equipment, and how many of these development hours are spent for smooth playback and how many are spent for e.g. signal processing?

its not about man hour, its about HW limitation. my first PC was single core CPU. video a bit laggy when watching, but becomes extra laggy when you move around. today you can play 4-8 movies at the same time without lag... up to date enginner/programmer should get datasheet first hand and know how to utilize multicore to the limit, but i;m not sure whats up with these new fancy dragon multicore android cpu..

[core]

But it cannot, for whatever reason, display the peak values on top of the peaks themselves, right in the FFT window, forcing the user to constantly move the eye from the diagram to the table and back and match the visual peaks with rows in the table by looking for each peak individually. Not to mention that the user has to waste a significant section of the screen for the window with the peaks table.

You can place windows vertically or horizontally. I prefer horizontal and that's fine.
As for the eye movements, it's very funny ... I don't have any problems.

[Mechatrommer]

On DHO1074 you can select overlay on the main window for any Math function.

no DHO800/900 dont have that... see attached.

[core]

On DHO1074 you can select overlay on the main window for any Math function.

no DHO800/900 dont have that... see attached.

That's a pitty, I'm sure it can be done ...

[pdenisowski]

Rigol DHO800 sucks in this respect. My definition of "sucks": the waveform update freezes and remains stopped while the vertical (or horizontal) offset encoder is being turned. Analog scopes do not suck: you can turn the offset dials for as long as you want, and the trace(s) will continue to update in real time as if nothing is happening. Do any digital scopes behave this way too?

Do you mean something like this?  (apologies for the unprofessional video)
 


Edit:  input is a sine wave that is being edge-triggered continuously

[core]

Rigol DHO800 sucks in this respect. My definition of "sucks": the waveform update freezes and remains stopped while the vertical (or horizontal) offset encoder is being turned. Analog scopes do not suck: you can turn the offset dials for as long as you want, and the trace(s) will continue to update in real time as if nothing is happening. Do any digital scopes behave this way too?

Do you mean something like this?  (apologies for the unprofessional video)
 


Edit:  input is a sine wave that is being edge-triggered continuously

Maybe one day we'll have one of these ... 

[2N3055]

Rigol DHO800 sucks in this respect. My definition of "sucks": the waveform update freezes and remains stopped while the vertical (or horizontal) offset encoder is being turned. Analog scopes do not suck: you can turn the offset dials for as long as you want, and the trace(s) will continue to update in real time as if nothing is happening. Do any digital scopes behave this way too?

Do you mean something like this?  (apologies for the unprofessional video)
 


Edit:  input is a sine wave that is being edge-triggered continuously

No not like that. That scope also stops triggering while you are moving waveform up and down. Look at trigger light.
Feed a nonuniform signal (like one of data protocol streams from demo board) and move waveform up and down. Wth stable sine signal you cannot see it stopped changing.

All recent Siglent scopes behave exactly like that R&S you show. Actually, 3000xHD and 6000A restart a smidge faster after you let it go.

But this is exactly what I was arguing all the time: there is no problem.
It it just stubborn nostalgia of "it is not analog" without any usefulness per se.

[shapirus]

Rigol DHO800 sucks in this respect. My definition of "sucks": the waveform update freezes and remains stopped while the vertical (or horizontal) offset encoder is being turned. Analog scopes do not suck: you can turn the offset dials for as long as you want, and the trace(s) will continue to update in real time as if nothing is happening. Do any digital scopes behave this way too?

Do you mean something like this?  (apologies for the unprofessional video)
 
Edit:  input is a sine wave that is being edge-triggered continuously

Yes, but a clean sine wave is not a proper signal to demonstrate it (because it's hard to tell if it's frozen or not -- the trace stays the same): a noisy, ideally jittery, signal would be better, so that it would be easy to see that it's being updated in real time while the offset is being changed.

[shapirus]

But this is exactly what I was arguing all the time: there is no problem.
It it just stubborn nostalgia of "it is not analog" without any usefulness per se.

Not really nostalgia in my case. I've not had much time spent with analog scopes and mentioned them just as an illustration of an ideal outcome for that particular scenario.

It's not too much of a practical issue, either. It just makes me wonder why it is so. A smartphone that fits in your pocket can easily play a video (or several videos) and do a bunch of other stuff simultaneously. I refuse to believe that the hardware used in oscilloscopes can't handle the tasks of generating the vector data and visualizing that (2d!) data on screen simultaneously without locking. It sounds more like nobody cares to implement a multi-threaded algorithm to achieve this. Of course I may be wrong.

Practical implications are *not* non-existent, however. It is an issue from the UX perspective. As was discussed above, it makes it more difficult (or tedious) to align a certain section (e.g. peaks) of the waveform with a certain graticule line, particularly when the waveform is zoomed into such that it does not fully fit on the screen vertically. Instead of a smooth continuous movement in a single motion it becomes "move - stop to let the waveform be updated - see if it's ok now - repeat if it's not".

[shapirus]

You can place windows vertically or horizontally. I prefer horizontal and that's fine.

Yes of course I can. Thankfully, they at least allowed us to move windows.
But I'd prefer same-window trace display. Maybe there are use cases when having math in a separate window is better (FFT is an example), but if you use, for example, two channels and A-B math as a poor man's differential probe, then the resulting trace must definitely be drawn in the main window along with the direct input, as you may naturally want to correlate that math waveform with something on the third channel, for example. Having it in a separate window as the only option defeats half the purpose of having the math function.
I'm not even mentioning that the windows borders and titlebars, when they are placed horizontally, consume the precious vertical space, which is already in great shortage with huge sections of the screen dedicated to the upper and lower status/control bars. This makes the useful vertical space of the two windows (main and math) ridiculously small, bordering uselessness.

As for the eye movements, it's very funny ... I don't have any problems.

There's nothing funny. Forcing the user to shift focus, unless it is a natural part of the flow in question, is bad, it's that simple. Good UI designers know this and place related elements in such a way that they are all can be seen and read without a single movement of the eyeball. An example would be the central section of a car's dashboard, a wristwatch, or winamp's main window.

[tggzzz]

But this is exactly what I was arguing all the time: there is no problem.
It it just stubborn nostalgia of "it is not analog" without any usefulness per se.

Not really nostalgia in my case. I've not had much time spent with analog scopes and mentioned them just as an illustration of an ideal outcome for that particular scenario.

It's not too much of a practical issue, either. It just makes me wonder why it is so. A smartphone that fits in your pocket can easily play a video (or several videos) and do a bunch of other stuff simultaneously. I refuse to believe that the hardware used in oscilloscopes can't handle the tasks of generating the vector data and visualizing that (2d!) data on screen simultaneously without mutual locking. It sounds more like nobody cares to implement a multi-threaded algorithm to achieve this. Of course I may be wrong.

Practical implications are *not* non-existent, however. It is an issue from the UX perspective. As was discussed above, it makes it more difficult (or tedious) to align a certain section (e.g. peaks) of the waveform with a certain graticule line, particularly when the waveform is zoomed into such that it does not fully fit on the screen vertically. Instead of a smooth continuous movement in a single motion it becomes "move - stop to let the waveform be updated - see if it's ok now - repeat if it's not".

That video showed acceptable behaviour. That's unsurprising since there is no reason to believe the laggy behaviour is inherent in digitising scopes: it is an artefact of an implementation.

As you say, the laggy behaviour I saw was a pain in the backside. Not insurmountable, just very irritating. The kind of thing you put up with when there is no alternative.

If you don't fit the entire waveform vertically on the display, then that causes other problems. When the input front-ends are overloaded the amplifiers become saturated. Exiting saturation is never timely nor clean. Decent old analogue scopes can be better behaved in that it can take more of an overload to cause saturation; nonetheless it can occur.

The only way to avoid such problems is to have a sampling bridge front end. I have one such scope, and when there is a 1Vpp square wave, I can "zoom in" vertically to see the end-of transition ringing at 1mV/division. Good luck with that with any other type of scope!

One important use case where that is essential was described by Jim Williams in AN47 appendix B: measuring the 0.1% settling time of an amplifier/DAC.