Recommend mid-price oscilloscope

[Karel]

If you can connect the DS1054Z to a pc/laptop, you can do the serial decoding there
at the highest samplerate possible (up to 1 GHz) and using the whole waveform memory (up to 24Mpts).
So, the limitation that it decodes only what's on screen, is not valid anymore (if you connect it to a pc).

With what software would that decoding happen? And how about browsing through the results? Think about segmented acquisitions, triggering on certain packets, etc. If you go that route you are way better off using a USB logic analyser. In other words: doing the decoding offline defeats the purpose of decoding in the oscilloscope because you'll be creating a PC based oscilloscope in the end. Just buy an oscilloscope which has decoding implemented properly.

DSRemote has a function called "Wave Inspector". It let you browse/zoomin/zoomout through the whole
24Mpts of memory and it is able to decode UART and SPI. This is all done at the aquisition samplerate of
max 1GHz, not the 1200 display samples.

I2C and parallel decoding haven't been implemented yet.

[AndyP]

I like to have ~10 samples per cycle, not compulsory, but at least some feel for what the waveform looks like. So I'm OK with 1Gsps on a 100Mhz signal. Maybe overkill but since I've got the kit....
The higher speed can useful for checking integrity of the hard edges in digital signals, overshoot, ringing, reflections etc can benefit from a high sample rate.
Also the headline sample rate may be split 2 or even 4 ways.
 

[nctnico]

The higher speed can useful for checking integrity of the hard edges in digital signals, overshoot, ringing, reflections etc can benefit from a high sample rate.
Also the headline sample rate may be split 2 or even 4 ways.

With low bandwidth a higher samplerate isn't going to produce more information so the deep memory is just wasted. For looking at edges an older scope with equivalent time sampling can also be an option. If decoding isn't a requirement then there is a whole range of used gear to choose from.

[MrWolf]

With low bandwidth a higher samplerate isn't going to produce more information so the deep memory is just wasted. For looking at edges an older scope with equivalent time sampling can also be an option. If decoding isn't a requirement then there is a whole range of used gear to choose from.

So on new scope high samplerate is always "wasted", but on old scopes it is useful for looking at the edges? 
Recently discussed:
https://www.eevblog.com/forum/testgear/rigol-ds1054z-bandwidth/msg1098795/#msg1098795
Even on 100MHz scope 1GS/s on every channel is good to have.

[Fungus]

Yea but my old 400€ scope does serial (lots of protocols) off 48k buffer, not screen
900€ scope from same company does 1-Wire, ARINC 429, CAN, DCC, DMX512, FlexRay, Ethernet 10Base-T, USB 1.1, I²C, I²S, LIN, PS/2, SPI, SENT, UART/RS-232 off 128M buffer. But psst... that technology is not supposed to exist, so it is "despised around here" as per herr Fungus. 

Sure, as long as you attach a PC to it and enjoy using a double-priced oscilloscope with your keyboard+mouse (ick).

If you're going to use a PC to do the serial decoding then a USB logic analyzer costs $10 (or less) on eBay. No need to spend 900€.

[nctnico]

With low bandwidth a higher samplerate isn't going to produce more information so the deep memory is just wasted. For looking at edges an older scope with equivalent time sampling can also be an option. If decoding isn't a requirement then there is a whole range of used gear to choose from.

So on new scope high samplerate is always "wasted", but on old scopes it is useful for looking at the edges? 

I guess you never heard about 20GHz scopes with 250ks/s samplerates. Also older DSOs with ETS tend to have Gaussian filters instead of brickwall like modern ones so yes, on an older DSOs you need a higher sampling rate to prevent aliasing.

[MrWolf]

I guess you never heard about 20GHz scopes with 250ks/s samplerates. Also older DSOs with ETS tend to have Gaussian filters instead of brickwall like modern ones so yes, on an older DSOs you need a higher sampling rate to prevent aliasing.

In which fundamental way modern budget DSO with 250MS/s and Gaussian frontend differs from these old DSOs?

If you're going to use a PC to do the serial decoding then a USB logic analyzer costs $10 (or less) on eBay.

OMG you just wiped out while industry producing logic analyzers costing more than $10. Powerful start for new year 

[JPortici]

One thing that the Rigol does to do well is serial triggering, despite not doing a great job at decoding.

Really? I couldn't be able to trigger on serial to save my life. Fortunately (for me) i almost don't use the rigol at all anymore

[tautech]

One thing that the Rigol does to do well is serial triggering, despite not doing a great job at decoding.

Really? I couldn't be able to trigger on serial to save my life. Fortunately (for me) i almost don't use the rigol at all anymore

Pretty darn simple once you know how, even not recent DSO's and those without Decoding but with Pulse or adjustable period triggering can do it with minimal effort.

[Fungus]

One thing that the Rigol does to do well is serial triggering, despite not doing a great job at decoding.

Really? I couldn't be able to trigger on serial to save my life.

Did you try reading the manual?

[tggzzz]

I guess you never heard about 20GHz scopes with 250ks/s samplerates. Also older DSOs with ETS tend to have Gaussian filters instead of brickwall like modern ones so yes, on an older DSOs you need a higher sampling rate to prevent aliasing.

In which fundamental way modern budget DSO with 250MS/s and Gaussian frontend differs from these old DSOs?

You can't see/measure a 40ps risetime, nor measure 20ps time differences. That's rather useful when looking at cables, connectors and short PCB traces, and the various types of input protection diodes to see where they are mangling the signal integrity.

For an example of a cheap 45 year old instrument that measures a ~50ps risetime, see
https://entertaininghacks.wordpress.com/2016/09/04/measuring-input-protection-components-effects-with-a-tdr/
https://entertaininghacks.wordpress.com/2016/08/30/a-traditional-tdr-cable-tester-with-2cm-resolution/

Try doing that with any modern budget DSO!

[nctnico]

I guess you never heard about 20GHz scopes with 250ks/s samplerates. Also older DSOs with ETS tend to have Gaussian filters instead of brickwall like modern ones so yes, on an older DSOs you need a higher sampling rate to prevent aliasing.

In which fundamental way modern budget DSO with 250MS/s and Gaussian frontend differs from these old DSOs?

I just wrote that: Gaussian versus brickwall filters in the analog frontend.

[lordvader88]

David, the OP is attempting to fix his Tek:
https://www.eevblog.com/forum/testgear/tekronix-2430a-can't-figure-out-vertical-position-setting/

You're no doubt more familiar with them than I am and some guidance would be appreciated.

I am very familiar with the 2440 series but I followed that discussion and did not have anything useful to add.  The posters are making suggestions that are on the right track.  I am sure I could find the problem in an hour but I would be doing what nctnico suggests in his most recent post using another oscilloscope to compare the circuits for channel 1 to channel 2 with a known low frequency input signal.  That should easily reveal at what point the channel 1 signal is corrupted.

For the record: I'm suggesting to use only ONE scope to measure itself using the working channel. I've done that before...

To the OP: OK. Now we have a budget. What are you areas of interest? What kind of circuits do you plan to build?

I don't know,

soon I will try using this 2430A scope, with CH2, to measure CH1............unless people here think thats a bad idea

I wait til sober tomorrow

[JPortici]

One thing that the Rigol does to do well is serial triggering, despite not doing a great job at decoding.

Really? I couldn't be able to trigger on serial to save my life. Fortunately (for me) i almost don't use the rigol at all anymore

Pretty darn simple once you know how, even not recent DSO's and those without Decoding but with Pulse or adjustable period triggering can do it with minimal effort.

and that's what i end up doing most of the time, but trigger on serial conditions/specific packet/missing ack, that sort of stuff... what serial triggering should do.. never been able to get a result before i got pissed off and did it in a different way/with a different tool

[MrWolf]

Try doing that with any modern budget DSO!

Missed the point. Point is: What is this wonderful (perhaps quantum?) magic that protects Gaussian rolloff RTS-only budget DSO from stuff above Nyquist so they do not need ETS functionality?
Edit: little example how 5ns rise looks on 25MHz analog bw - 100MSa/s RTS single shot vs 4GSa/s ETS. Same source. CH2 on ~60cm longer cable. Wobbly Sinc crap vs looking at true analog response. Hmm...

[Howardlong]

One thing that the Rigol does to do well is serial triggering, despite not doing a great job at decoding.

Really? I couldn't be able to trigger on serial to save my life. Fortunately (for me) i almost don't use the rigol at all anymore

I've used serial decode *triggers fairly extensively and never had a problem, unlike the decode, which sometimes doesn't decode correctly the sequence that the scope correctly triggered on. Serial triggers aren't computed with the same mechanism that decodes are.

*Edit to correct my mental aberration.

[Fungus]

One thing that the Rigol does to do well is serial triggering, despite not doing a great job at decoding.

Really? I couldn't be able to trigger on serial to save my life. Fortunately (for me) i almost don't use the rigol at all anymore

I've used serial decode fairly extensively and never had a problem, unlike the decode, which sometimes doesn't decode correctly the sequence that the scope correctly triggered on. Serial triggers aren't computed with the same mechanism that decodes are.

DS1054Z serial decoding isn't much use for decoding massive amounts of data, doing in-depth reverse engineering of communications protocols or anything like that.

OTOH it works just fine (in my experience) for looking at single packets of data, making sure devices are responding properly to requests, checking baud rates, etc. You can trigger on particular sequences of data, with I2C You can trigger by device...it does quite a lot.

(and before the usual suspects leap in and say, "Oh, Rigol is rubbish!", get some perspective. How many other 'scopes can do any better? At what price?)

For massive amounts of serial decoding an oscilloscope really isn't the right tool. Get a USB logic analyzer. Mouse, keyboard and masses of RAM are what's needed for that particular job.

[nctnico]

For massive amounts of serial decoding an oscilloscope really isn't the right tool. Get a USB logic analyzer. Mouse, keyboard and masses of RAM are what's needed for that particular job.

Very bad advice! When dealing with protocol problems the cause is often in the analog domain which is what gets hidden by using a logic analyser. In other words: it is very beneficial to have good protocol decoding and protocol triggering abilities in an oscilloscope so it might be worth something spending extra money on.

[MrWolf]

For massive amounts of serial decoding an oscilloscope really isn't the right tool. Get a USB logic analyzer. Mouse, keyboard and masses of RAM are what's needed for that particular job.

Hm, but what if oscilloscope already has masses of RAM onboard + PC RAM, mouse, keyboard, 16ch digital, 4ch analog. Why cannot you use that and instead have to resort to some other thing just becasue it's called "logic analyzer"? 
Looking here https://www.saleae.com/performancecalculator they are cutting corners pretty round with sample rates massively dropping with all digital channels in use. Much less severe issue with MSOs.

[tggzzz]

Try doing that with any modern budget DSO!

Missed the point. Point is: What is this wonderful (perhaps quantum?) magic that protects Gaussian rolloff RTS-only budget DSO from stuff above Nyquist so they do not need ETS functionality?
Edit: little example how 5ns rise looks on 25MHz analog bw - 100MSa/s RTS single shot vs 4GSa/s ETS. Same source. CH2 on ~60cm longer cable. Wobbly Sinc crap vs looking at true analog response. Hmm...

That's true, of course. But it wasn't the question you asked about 20GHz scopes with a 250kS/s sampling rate, viz:

I guess you never heard about 20GHz scopes with 250ks/s samplerates. Also older DSOs with ETS tend to have Gaussian filters instead of brickwall like modern ones so yes, on an older DSOs you need a higher sampling rate to prevent aliasing.

In which fundamental way modern budget DSO with 250MS/s and Gaussian frontend differs from these old DSOs?

I have a >2GHz scope with a 13kS/s sample rate; it does things simply impossible with modern budget DSOs.

[Howardlong]

My biggest concenrs over USB Logic Analysers, particularly the cheaper ones, are that they tend to lack anything more than quite rudimentary triggering facilities, and are often low sampling rate devices.

Whether you use a USB LA or a scope is often a matter of personal preference, but 99% of the time nowadays I do it on the scope. It wasn't always that way, not long ago parallel busses were far more prevalent, and only the most expensive scopes did serial decode. It's pretty rare I find I need to delve into multi megabit decodes and do post mortem analysis, but I accept that it happens, and indeed I do keep a few USB LAs for this purpose, but they sit in a drawer 99% of the time.

[Fungus]

For massive amounts of serial decoding an oscilloscope really isn't the right tool. Get a USB logic analyzer. Mouse, keyboard and masses of RAM are what's needed for that particular job.

Very bad advice! When dealing with protocol problems the cause is often in the analog domain which is what gets hidden by using a logic analyser.

I didn't mean to imply the two are mutually exclusive. Obviously you need to look at signal edges if you're designing stuff.

What I meant was: There's not much point in spending $500 extra for serial decoding on an oscilloscope if there's a PC on your bench and a $10 USB device will do the job.

My biggest concenrs over USB Logic Analysers, particularly the cheaper ones, are that they tend to lack anything more than quite rudimentary triggering facilities, and are often low sampling rate devices.

Normally you don't trigger, you record massive amounts of data then do a "search".

Whether you use a USB LA or a scope is often a matter of personal preference, but 99% of the time nowadays I do it on the scope.

I guess if the devices are talking to each other OK (which the 'scope will let you see) then the rest is mostly software debugging. Use printf() for that.

IOW a DS1054Z is usually enough. 

Hm, but what if oscilloscope already has masses of RAM onboard + PC RAM, mouse, keyboard, 16ch digital, 4ch analog.

Then it's not one of the 'scopes currently being discussed.

[MrWolf]

I have a >2GHz scope with a 13kS/s sample rate; it does things simply impossible with modern budget DSOs.

Im not english speaker it was bad wording. Im well aware of ETS monsters. Also I think that ETS has its place, especially in budget scopes with Gaussian rolloff & sample rates dropping almost to Nyquist limit when enabling more than 1 channel.

Then it's not one of the 'scopes currently being discussed.

Well within "mid-range" price class.

[nctnico]

For massive amounts of serial decoding an oscilloscope really isn't the right tool. Get a USB logic analyzer. Mouse, keyboard and masses of RAM are what's needed for that particular job.

Very bad advice! When dealing with protocol problems the cause is often in the analog domain which is what gets hidden by using a logic analyser.

I didn't mean to imply the two are mutually exclusive. Obviously you need to look at signal edges if you're designing stuff.

It is not just about timing but the causes of protocol violations. That means being able to trigger on such events (make long segmented recordings!) and look at them in the analog domain. Using two seperate tools for that job just makes things more complicated especially if the error occurs only once per hour.

[Fungus]

It is not just about timing but the causes of protocol violations. That means being able to trigger on such events (make long segmented recordings!) and look at them in the analog domain. Using two seperate tools for that job just makes things more complicated especially if the error occurs only once per hour.

Who's forcing you to use both? Use the right tool for the particular job.

If you do a lot of serial decoding and one of the tools is only $10 then it's no biggie to have both. There are things the 'scope isn't best at.