Help with Oscilloscope purchase decision.

[Tomer]

Hi, I am new here so hello to everyone.
I am a student and learning electronics, I am working on audio applications such as Compressors, EQ's, PreAmps.

I need your help with an Oscilloscope purchase decision.
My 2 top candidates will be the Rigol "1054Z" and the KeySignt "EDUX1002A", the price difference between them is small.
The Rigol gives 4 channels (I don't see that i will need more than 2)
The Rigol can be "Hacked" easily for more features and bandwidth (Again, I don't need 100Mhz)

Are there any other factors that i am missing? what is your suggestion?
Or maybe a completely different candidate?

Thanks a lot for your help
Tom.
 

[james_s]

You might find the FFT function useful for audio work of that nature, it may be worth looking into whether the scopes you are looking for have that and if they do, whether it works well enough to be useful.

[Fungus]

You might want to look at the Analog Discovery instead. It's a great little device for learning electronics and has a high resolution ADC which gives really good FFTs (much better than those two 'scopes).

You can also program it to output frequency sweeps and do really nice Bode plots - very handy for audio work.

It's also half the price. 

[JPortici]

based on your requirements i'd say that
- you don't need high bandwidth (also less bandwidth < > less noise)
- you'd rather need more resolution 10,12,16 bit
- you'd probably need more than two channels. for example, compressor: input, output, control.
- you may need decodes

basically for resolution, i second the analog discovery

[Fungus]

PS: Here's Dave's video:



nb. That's the old version. We now have the Analog Discovery 2.

[nctnico]

I'd also look at the GW Instek GDS-1054B. Pricewise in the same ballpark but it has 1Mpts FFT and input filtering. Input filtering is very useful to get rid of HF noise in a signal. For audio work the analog discovery also seems nice but you'll always need a PC and (AFAIK) the input ranges are limited.

[tautech]

Hi, I am new here so hello to everyone.
I am a student and learning electronics, I am working on audio applications such as Compressors, EQ's, PreAmps.

I need your help with an Oscilloscope purchase decision.
My 2 top candidates will be the Rigol "1054Z" and the KeySignt "EDUX1002A", the price difference between them is small.
The Rigol gives 4 channels (I don't see that i will need more than 2)
The Rigol can be "Hacked" easily for more features and bandwidth (Again, I don't need 100Mhz)

Are there any other factors that i am missing? what is your suggestion?
Or maybe a completely different candidate?

Thanks a lot for your help
Tom.

Welcome to the forum.

There's a lot of choices in the market presently and more to come.
An updated version of the Siglent SDS1000X series is just a few weeks away, the SDS1202X-E.
Pricing indications I have are very favourable against any existing model in the marketplace.
There's mot much info out about it yet but our Dave has a prototype and is quite impressed with it.
Have a hunt for X-E within the forum for bits and pieces that Dave has said of it.

Mentions:
https://www.eevblog.com/forum/testgear/new-siglent-sds1000x-e-oscilloscope-based-on-xilinx-zynq-7000-soc-architecture/

[thanasisk]

In general you either get bandwidth (benchtop oscilloscopes) or resolution bits (pc-based) - (within a reasonable price range that is!).

Even for audio work you might need high(er) BW such as 100 MHz - for example if you want to study op-amp behaviour/oscillation.

Some oscilloscopes reduce the sample rate to increase the equivalent resolution bits (e.g. R&S HMO1212 - it can go to 16 bits).

And resolution bits should be considered together with sensitivity and front-end noise, which might matter I guess if you mess around with small-scale signals (Microphone level is -60 dBV / 1mVrms to -40 dBV / 10 mVrms ).. This is where things get complicated because there is not much information in a single place to make an informed decision.

Other points:
- Adequate FFT >=128kpts would be nice (with a decent update rate of course!). See Dave's FFT comparison video. I also think the Zynq-based oscilloscopes (GW-Instek models and the new Siglent - and the Red Pitaya devboard) are also very competent in this area.

[GlowingGhoul]

Get the Keysight. It's the smoothest functioning option of those presented, and you want your tools to be as invisible as possible, not an impediment to overcome.

[kcbrown]

If you can, you might want to wait for the new Siglent to come out and for people to review it.  It looks like it may well be a good contender.  It'll only have two channels, and that might prove limiting, or it might not be, depending on your needs.  It'll be a 200MHz scope, however, and that might put its price beyond what you're willing to pay after considering the competition and your bandwidth requirements.

If you don't need any sort of decoding, then the Instek GDS-1054 actually looks quite good, particularly for your uses (I'm presuming that 50MHz is more than sufficient for your needs), and especially because it has 4 channels.  If you don't need 4 channels, you can get the 100MHz 2 channel model for $30 more (I'm going by the tequipment.net prices).

Of course, the Keysight is going to be the most responsive in terms of its user interface (it's been described as behaving as if the controls are directly wired to the screen), but it's potentially the most limited for the price, particularly in the memory department (100K points for the 50 MHz educational version, compared with 10M points for the Instek).  If your decoding needs are limited to i2c and UART (assuming you need or want any decoding at all), then the educational model might suit your needs just fine, though the decoding is an optional extra from the looks of it (and I've no idea how much it'll cost).

At this point, there are a number of good options for rather good prices if 50 MHz will suit your needs.   Looks like it's a good time to be in the market for an entry-level scope.

[tautech]

If you can, you might want to wait for the new Siglent to come out and for people to review it.  It looks like it may well be a good contender.  It'll only have two channels, and that might prove limiting, or it might not be, depending on your needs.  It'll be a 200MHz scope, however, and that might put its price beyond what you're willing to pay after considering the competition and your bandwidth requirements.

You may want to rethink that last sentence in the next few weeks. 

[kcbrown]

If you can, you might want to wait for the new Siglent to come out and for people to review it.  It looks like it may well be a good contender.  It'll only have two channels, and that might prove limiting, or it might not be, depending on your needs.  It'll be a 200MHz scope, however, and that might put its price beyond what you're willing to pay after considering the competition and your bandwidth requirements.

You may want to rethink that last sentence in the next few weeks. 

Looking forward to it!   


Sent from my iPhone using Tapatalk

[Tomer]

Hi Everyone and thank you for so many good replies. it is hard for a beginner to decide, trying to make the best choice possible.

From the replies, i understand the following:
1) It will be a good idea to go with 4 channels. 2 channels might won't be enough for audio applications.
2) Sometimes i might need a Bandwidth higher than 50Mhz.
3) FFT will be an important factor.

Notes:
- Analog Discovery - looks really nice, but i would like to have full size scope. (and other hardware such as Signal generator).
- Waiting for the new Siglent - I am a newbie, but from reading and watching around the web i learned that Siglent products release with half baked software and it takes time until the software mature.

Question:
How to Determent the FFT feature in a scope. what data in the spec should i be looking for ?

Thank again for all your help!
Tom

[Fungus]

Question:
How to Determent the FFT feature in a scope. what data in the spec should i be looking for ?

The single biggest factor is number of bits in the ADC. This is where the Analog Discovery really shines.

Secondly, memory/window size. More is good.

[Electro Fan]

Kind of late to this thread and have been away from EEVblog for a while so just getting caught back up on scopes.  I'm a pretty happy Rigol MSO2072 hobby user but I'm not wedded to any make or model.

If you were thinking about a birthday gift for a 2nd year college EE student, which of the entry scopes might be preferred among the Rigol 1054Z, the EDUX1002A, the GW Instek GDS-1054B, the impending Siglent, or perhaps some other model.  It would be nice to stay at $400 or lower but if there's a reason to spend somewhat more it's worth considering.  FWIW, the student already has an Analog Discovery 2.

The goal is not to solve every EE problem with this scope but to provide a good first experience with a personal scope (I'm pretty sure the university has better gear in the labs - maybe Agilent 2k/3k models).  My theory is that more hands-on time might lead to more/faster/better learning, and some fun.  I know it's a somewhat open-ended and subjective question but any thoughts/recommendations are welcome. 

Thanks

[Electro Fan]

Just saw this "Logic Analyzer Comparison" regarding scopes vs. Digilent AD, LAs, etc.  Might be interesting for beginners, new users, or others.



- Checkout the other videos by tomtektest, lots of interesting videos....

[james_s]

Kind of late to this thread and have been away from EEVblog for a while so just getting caught back up on scopes.  I'm a pretty happy Rigol MSO2072 hobby user but I'm not wedded to any make or model.

If you were thinking about a birthday gift for a 2nd year college EE student, which of the entry scopes might be preferred among the Rigol 1054Z, the EDUX1002A, the GW Instek GDS-1054B, the impending Siglent, or perhaps some other model.  It would be nice to stay at $400 or lower but if there's a reason to spend somewhat more it's worth considering.  FWIW, the student already has an Analog Discovery 2.

The goal is not to solve every EE problem with this scope but to provide a good first experience with a personal scope (I'm pretty sure the university has better gear in the labs - maybe Agilent 2k/3k models).  My theory is that more hands-on time might lead to more/faster/better learning, and some fun.  I know it's a somewhat open-ended and subjective question but any thoughts/recommendations are welcome. 

Thanks

The Rigol seems to be really well liked around here, and it's compact for a standalone instrument, possibly an important consideration to a college student. You probably won't go too wrong with any of the ~$400 DSOs as long as you don't get some no-name brand that nobody has heard of. None of them are stellar instruments but none of them seem to be turds either. It's really pretty amazing what you can get brand new for 400 bucks these days.

[Pitrsek]

Hi,
for your audio stuff, no scope can touch a decent sound card. So for audio FFT, THD plots, eq transfer functions and other stuff, buy a decent sound card + make yourself nice front end(levels control,protection,etc.). Two completely different tools. You are buying scope to see the "fast" stuff. If you can wait, I'd wait for X-E Siglent. Once it's out you can decide weather its good enough or you'll by EDUX. Hopefully there will be some more progress on EDUX hacking as well. For me Rigol is not an option due to user interface - it's lagy. I had 2072 for a test, it drove me nuts  . 1062 was absolutely ok in this regard, dunno why they messed new ones up....

I'm shopping for a new scope for my home workshop - waiting for X-E. Then I'll decide.

[Keysight DanielBogdanoff]

We've had really good feedback on the 1000 X-Series FFT capabilities, I think it's one of the places it shines compared to other cheap scopes I've used.

[snoopy]

Is the Keysight like the Rigol and only does protocol analysis on the display contents rather than what's in the capture memory ? I find this an annoying limitation of the Rigol and limits it somewhat !!

[fonograph]

Siglent 1000 x-e    have lowest noise front end of the three,1 million bin fft,big memory a no hacking required,it comes at 200mhz with decode and segmented memory straight out of box,for 425 eur its best.The rigol have crap front end and keysight have worst of the worst no name chinese capacitors in psu,but keysight software is superior to rigol/siglent,lot less bugs.

[chrisalbertson]

You might end up with multiple scopes.   Buy the entry level DSO.  The Rigol 1054z that you were looking at is not bad but also for audio you could use more bits and lower sampling rate.   Do you already have a studio grade USB audio interface?  My USB interface does 96K samples per second at 24 bits per sample on two channels it has about a 100db dynamic range.  These are pretty standard specs for an audio interface from companies like Focusrite or MOTU.  I can use this to drive a software scope on my iMac.  I can run a useful FFT and display multiple scope screens on a 27" LCD screen.   But I do need to keep the Rigol scope as my audio interface is limited to audio frequency

I the software in the link below.  Look at the screen shots.  No readably priced DSO oscilloscope can draw images like this: http://www.faberacoustical.com/apps/mac/electroacoustics_toolbox/

Having both is good.   But I also own a 1980's vintage Tektronix analog scope.  You can find these now for under $100.   Actually with an analog scope and the PC software scope you'd be set.  Unless you need to look at digital stuff

[Keysight DanielBogdanoff]

Is the Keysight like the Rigol and only does protocol analysis on the display contents rather than what's in the capture memory ? I find this an annoying limitation of the Rigol and limits it somewhat !!

Yes, the InfiniiVision Oscilloscopes do decoding on the display data. A scope that does decode on the entire trace will generally take a hit to update rate and possibly even UI responsiveness.

[rsjsouza]

Is the Keysight like the Rigol and only does protocol analysis on the display contents rather than what's in the capture memory ? I find this an annoying limitation of the Rigol and limits it somewhat !!

Yes, the InfiniiVision Oscilloscopes do decoding on the display data. A scope that does decode on the entire trace will generally take a hit to update rate and possibly even UI responsiveness.

That is something I never quite understood from the critics detracting the brands that decode only what is displayed, as my understanding is similar to Daniel's, especially for the multi-MB storage scopes. Also, how useful it is to show decoded data while displaying "real-time" waveforms? I usually gather a specific stream of data and perform post-analysis by navigating on the scope memory. If a frame is outside of the displayed area, I simply use the horizontal delay to frame it more appropriately and get the decoded data - well, one improvement would be if the decoder actually decoded, say, twice or four times the size of the display size, so you wouldn't have invalid data in the edges of the displayed area.

BTW, I am genuinely curious (I may not be thinking about other usage scenarios). 

(edited for clarification)

[nctnico]

Is the Keysight like the Rigol and only does protocol analysis on the display contents rather than what's in the capture memory ? I find this an annoying limitation of the Rigol and limits it somewhat !!

Yes, the InfiniiVision Oscilloscopes do decoding on the display data. A scope that does decode on the entire trace will generally take a hit to update rate and possibly even UI responsiveness.

I think you better rephrase that because a scope which decodes only what is on screen is rather useless because you can't zoom in on the bits very easely. The decode will dissapear once the start of the message is outside the display area. From my own experience with an Agilent DSO7000 the decoding fills a seperate memory during an acquisition cycle. This means you have to have decoding enabled & setup properly before doing an acquisition and you can't change the decode settings for an existing acquisition. DSOs which do decoding on the actual waveform data are more flexible in this regard.

[Fungus]

That is something I never quite understood from the critics detracting the brands that decode only what is displayed, as my understanding is similar to Daniel's, especially for the multi-MB storage scopes.

I'm with you. DSO serial decoding is useful for checking the baud rates, signal integrity, etc. If you're using it to debug long exchanges of data then you're doing it wrong.

(use printf() on one of the devices for that, or get a $10 logic analyzer)

[nctnico]

That is something I never quite understood from the critics detracting the brands that decode only what is displayed, as my understanding is similar to Daniel's, especially for the multi-MB storage scopes.

I'm with you. DSO serial decoding is useful for checking the baud rates, signal integrity, etc. If you're using it to debug long exchanges of data then you're doing it wrong.

Buzzzz... wrong. I guess you never needed to look for a problem where a message gets corrupted every now and then. You can only find those with deep memory and the cause usually is only visible in the analog domain. So that $10 logic analyser is only going to tell you the bits ain't right (which was already obvious) but not what the cause is.

[rsjsouza]

That is something I never quite understood from the critics detracting the brands that decode only what is displayed, as my understanding is similar to Daniel's, especially for the multi-MB storage scopes.

I'm with you. DSO serial decoding is useful for checking the baud rates, signal integrity, etc. If you're using it to debug long exchanges of data then you're doing it wrong.

Buzzzz... wrong. I guess you never needed to look for a problem where a message gets corrupted every now and then. You can only find those with deep memory and the cause usually is only visible in the analog domain. So that $10 logic analyser is only going to tell you the bits ain't right (which was already obvious) but not what the cause is.

Despite I don't do much decode (thus my limited usage scenarios), I agree with you that the world is analog and a LA will only tell you the partial truth.

However, in the scenario you highlighted wouldn't it be more efficient to store the long record and let the oscilloscope search for a specific decoded pattern (if it has such capability)? Or perhaps have a feature where the decoder can match a pattern and trigger the oscilloscope? In both cases I suspect this starts to move towards more expensive solutions (or even a LA).

In case negative, and you need to look yourself for the pattern on the oscilloscope display, I can see what you describe below as being a limitation:

(...) a scope which decodes only what is on screen is rather useless because you can't zoom in on the bits very easely. The decode will dissapear once the start of the message is outside the display area.

Despite this, I wouldn't necessarily say "useless", but perhaps more difficult as I mentioned before:

I usually gather a specific stream of data and perform post-analysis by navigating on the scope memory. If a frame is outside of the displayed area, I simply use the horizontal delay to frame it more appropriately and get the decoded data

I think there has to be some sort of tradeoff between how much memory is decoded and the oscilloscope processing power. Granted, some more advanced models have Intel processors that may execute this at a split second, but an embedded processor on a lower cost oscilloscope will most probably have to compromise (UI, decoder, math, FFT, etc.), don't you think?

(...) From my own experience with an Agilent DSO7000 the decoding fills a seperate memory during an acquisition cycle. This means you have to have decoding enabled & setup properly before doing an acquisition and you can't change the decode settings for an existing acquisition. DSOs which do decoding on the actual waveform data are more flexible in this regard.

I would have guessed this would help enhance the breadth of the decoding range, but perhaps not. Thus my previous hypothesis of:

(...)well, one improvement would be if the decoder actually decoded, say, twice or four times the size of the display size, so you wouldn't have invalid data in the edges of the displayed area.

[nctnico]

Regarding triggering on a pattern: in most cases you don't know what the problem is so you can't really trigger on something you don't know.
Decoding the full memory can give you a list with all decoded messages in an acquisition. This usually can be saved to a CSV file which can be processed on a computer to (for example) find specific or malformed messages quickly using search features of Excel (or a similar program).

[james_s]

This is where having two instruments or a mixed signal instrument can be nice. Use the scope to check for signal integrity, use the logic analyzer to capture and decode the data. In most cases you don't really need to know what the data is in order to see that it's garbled, distorted by ringing, noise or of the wrong amplitude.

[mikeselectricstuff]

Is the Keysight like the Rigol and only does protocol analysis on the display contents rather than what's in the capture memory ? I find this an annoying limitation of the Rigol and limits it somewhat !!

Yes, the InfiniiVision Oscilloscopes do decoding on the display data. A scope that does decode on the entire trace will generally take a hit to update rate and possibly even UI responsiveness.

I think you better rephrase that because a scope which decodes only what is on screen is rather useless because you can't zoom in on the bits very easely. The decode will dissapear once the start of the message is outside the display area. From my own experience with an Agilent DSO7000 the decoding fills a seperate memory during an acquisition cycle. This means you have to have decoding enabled & setup properly before doing an acquisition and you can't change the decode settings for an existing acquisition. DSOs which do decoding on the actual waveform data are more flexible in this regard.

I think you are mistaken in your understanding - the display is re-rendered from the acquisition data if you zoom, so you can take a long acquisition and zoom in and decode any part of it, with resolution  limited only by the sample rate.

[kcbrown]

Is the Keysight like the Rigol and only does protocol analysis on the display contents rather than what's in the capture memory ? I find this an annoying limitation of the Rigol and limits it somewhat !!

Yes, the InfiniiVision Oscilloscopes do decoding on the display data. A scope that does decode on the entire trace will generally take a hit to update rate and possibly even UI responsiveness.

I think you better rephrase that because a scope which decodes only what is on screen is rather useless because you can't zoom in on the bits very easely. The decode will dissapear once the start of the message is outside the display area. From my own experience with an Agilent DSO7000 the decoding fills a seperate memory during an acquisition cycle. This means you have to have decoding enabled & setup properly before doing an acquisition and you can't change the decode settings for an existing acquisition. DSOs which do decoding on the actual waveform data are more flexible in this regard.

It's immensely important to distinguish between acquisition-time decoding and display-time decoding.   You can have display-time decoding of the entire acquisition when the scope is stopped while having acquisition-time decoding of only the displayed portion (or some slightly larger amount).

It's also very important to distinguish decoding-based triggering from the decoding that is shown on the display.  The triggering might well do just barely enough to meet the triggering conditions, while display would require full decoding (though I have a hard time imagining how the two would differ in practice).

Usually, when you're looking at decoded data in such a way that you're interested in more than just what's on the screen at the time, you're doing so with the scope stopped.  There's no good reason for not decoding the entire acquisition under those conditions, and there's nothing that says that you have to compromise the waveform update rate for it.  I can understand why you might want to limit decoding to the displayed portion of the waveform during capture, particularly if your trigger conditions don't involve that decoding, but that's no longer valid once the scope is stopped.

[snoopy]

Is the Keysight like the Rigol and only does protocol analysis on the display contents rather than what's in the capture memory ? I find this an annoying limitation of the Rigol and limits it somewhat !!

Yes, the InfiniiVision Oscilloscopes do decoding on the display data. A scope that does decode on the entire trace will generally take a hit to update rate and possibly even UI responsiveness.

Hi Daniel

I can only speak for the Rigol scope but recently I had to debug a bit banged SPI flash ROM programming system. The problem with the Rigol is even though you can capture a lot of the SPI data and zoom in on it, as soon as the start frame (ie nCS goes low) moves off the screen as you pan through the data the decoding switches off which kind of defeats the purpose. Because of this I have ordered a cheap USB logic analyzer which will hopefully overcome this issue. BTW I managed to get the thing going but the scope was not as useful as I thought it would be I was wondering if the Keysight scope is an improvement on this as the high acquisition rate would not of helped in this situation.

BTW People using the Rigol for protocol analysis I found the delayed triggering and zoom was much more useful than changing the timebase and panning the data contents using the horizontal position control because it allows you to trigger at the left side of the display and zoom in around the trigger point much more easily

cheers

[Fungus]

I'm with you. DSO serial decoding is useful for checking the baud rates, signal integrity, etc. If you're using it to debug long exchanges of data then you're doing it wrong.

Buzzzz... wrong. I guess you never needed to look for a problem where a message gets corrupted every now and then. You can only find those with deep memory and the cause usually is only visible in the analog domain. So that $10 logic analyser is only going to tell you the bits ain't right (which was already obvious) but not what the cause is.

How exactly are you going to trigger on that to be able to look at the problem? 

(me? I'd do it by sending a short message over and over and using pass/fail - a longer serial decode wouldn't make any difference to that)

[nctnico]

I'm with you. DSO serial decoding is useful for checking the baud rates, signal integrity, etc. If you're using it to debug long exchanges of data then you're doing it wrong.

Buzzzz... wrong. I guess you never needed to look for a problem where a message gets corrupted every now and then. You can only find those with deep memory and the cause usually is only visible in the analog domain. So that $10 logic analyser is only going to tell you the bits ain't right (which was already obvious) but not what the cause is.

How exactly are you going to trigger on that to be able to look at the problem? 

Not. Just capture as much data as possible (segmented recording) and post process on a PC to find the garbled message. It may help though to have some information so only certain messages are captured to reduce the amount of data.

(me? I'd do it by sending a short message over and over and using pass/fail - a longer serial decode wouldn't make any difference to that)

Unfortunately that doesn't always work. Sometimes it is a specific message which can cause a device to misbehave every now and then. At some point I had to deal with a problem where a message went wrong once every 30 minutes to an hour.

[Fungus]

Usually, when you're looking at decoded data in such a way that you're interested in more than just what's on the screen at the time, you're doing so with the scope stopped.  There's no good reason for not decoding the entire acquisition under those conditions, and there's nothing that says that you have to compromise the waveform update rate for it.  I can understand why you might want to limit decoding to the displayed portion of the waveform during capture, particularly if your trigger conditions don't involve that decoding, but that's no longer valid once the scope is stopped.

I'm half with you on this one: This is the way oscilloscopes would behave in a Utopia.

OTOH oscilloscopes aren't really designed internally for this sort of programming pattern and I can see why they don't do it.

(are there any oscilloscopes that do?)

If the problem is consistent/repeatable then I bet you can solve it with a DSO that only decodes what's on screen (even if it it isn't the ideal tool for the job). If it isn't consistent/repeatable then I don't see how more decoding would help.

[Fungus]

Unfortunately that doesn't always work. Sometimes it is a specific message which can cause a device to misbehave every now and then. At some point I had to deal with a problem where a message went wrong once every 30 minutes to an hour.

Was the problem in the analog domain?

[nctnico]

Unfortunately that doesn't always work. Sometimes it is a specific message which can cause a device to misbehave every now and then. At some point I had to deal with a problem where a message went wrong once every 30 minutes to an hour.

Was the problem in the analog domain?

Yes. A logic analyser would not have caught this problem:

What happens here is that an I2C device is stretching the clock to make the I2C master wait but the I2C master doesn't care.

[Fungus]

What happens here is that an I2C device is stretching the clock to make the I2C master wait but the I2C master doesn't care.

Fun times. 

Still, a DSO with "whole buffer decode" wouldn't have helped much either.

[nctnico]

What happens here is that an I2C device is stretching the clock to make the I2C master wait but the I2C master doesn't care.

Fun times. 

Still, a DSO with "whole buffer decode" wouldn't have helped much either.

Wrong conclusion. The Agilent scope I used has all the segments decoded in the list display which means it has decoded the entire memory (8Mpts in this case). This was necessary to find the malformed message.

[snoopy]

Unfortunately that doesn't always work. Sometimes it is a specific message which can cause a device to misbehave every now and then. At some point I had to deal with a problem where a message went wrong once every 30 minutes to an hour.

Was the problem in the analog domain?

Yes. A logic analyser would not have caught this problem:

What happens here is that an I2C device is stretching the clock to make the I2C master wait but the I2C master doesn't care.

Just set to trigger on a runt pulse ?

[GeorgeOfTheJungle]

What happens here is that an I2C device is stretching the clock to make the I2C master wait but the I2C master doesn't care.

What's causing that funny step?? BTW, nice scope that Agilent!

[Fungus]

What happens here is that an I2C device is stretching the clock to make the I2C master wait but the I2C master doesn't care.

Fun times. 

Still, a DSO with "whole buffer decode" wouldn't have helped much either.

Wrong conclusion. The Agilent scope I used has all the segments decoded in the list display which means it has decoded the entire memory (8Mpts in this case). This was necessary to find the malformed message.

 

If it's only wrong "once every 30 minutes to an hour" then you need to trigger on it with a DSO. How does that work?

[Fungus]

What happens here is that an I2C device is stretching the clock to make the I2C master wait but the I2C master doesn't care.

What's causing that funny step??

An I2C device stretching the clock and the master ignoring it.

I think this particular bus is breaking the I2C specification: If any slave can do clock stretching (ie. hold the clock line low to slow down the master) then a master isn't allowed to actively drive the bus high (the only way a signal can go half way up is if the master is putting out a high voltage while a slave is trying to pull it down).

Just set to trigger on a runt pulse ?

Would probably have worked - look for a pulse that doesn't rise all the way up.

[rsjsouza]

Regarding triggering on a pattern: in most cases you don't know what the problem is so you can't really trigger on something you don't know.
Decoding the full memory can give you a list with all decoded messages in an acquisition. This usually can be saved to a CSV file which can be processed on a computer to (for example) find specific or malformed messages quickly using search features of Excel (or a similar program).

Ah, so you are saying you don't scan for errors in the oscilloscope screen, but instead do post-processing on a PC. That is what I would think it is easier. In theory the Rigol could do the same if you perform a "zoom out", which will allow the decoder to work, and then save all this data. I will try this at a later time.

This is where having two instruments or a mixed signal instrument can be nice. Use the scope to check for signal integrity, use the logic analyzer to capture and decode the data. In most cases you don't really need to know what the data is in order to see that it's garbled, distorted by ringing, noise or of the wrong amplitude.

That is always my discomfort of having protocol decoding on a pure waveform oscilloscope - is this simply trying to shoehorn a non-target functionality into an instrument designed for another purpose? Obviously that the more features the merrier, but if they negatively impact the core functionality of the equipment than it should be left to more specialized brethren in the product line. All in all, I think it is already a feat on a very low cost to account for such advanced functionality, let it be on screen or on the buffer.

Usually, when you're looking at decoded data in such a way that you're interested in more than just what's on the screen at the time, you're doing so with the scope stopped.  There's no good reason for not decoding the entire acquisition under those conditions, and there's nothing that says that you have to compromise the waveform update rate for it.  I can understand why you might want to limit decoding to the displayed portion of the waveform during capture, particularly if your trigger conditions don't involve that decoding, but that's no longer valid once the scope is stopped.

Ok, so I agree with you in theory but, as I mentioned before, if the decoding process takes too long to scan through the entire buffer due to processing limitations, then I suspect the UI may be perceived as "slow" (you never know, it is hard to please everyone  ). Obviously that you can get a more powerful oscilloscope with an Intel processor in it, but that is certainly not entry level anymore.

I can only speak for the Rigol scope but recently I had to debug a bit banged SPI flash ROM programming system. The problem with the Rigol is even though you can capture a lot of the SPI data and zoom in on it, as soon as the start frame (ie nCS goes low) moves off the screen as you pan through the data the decoding switches off which kind of defeats the purpose.

BTW People using the Rigol for protocol analysis I found the delayed triggering and zoom was much more useful than changing the timebase and panning the data contents using the horizontal position control because it allows you to trigger at the left side of the display and zoom in around the trigger point much more easily

Oh, so I see you already tried this with the Rigol. I will see what happens with the method you described on the DS4000. Thanks for sharing the procedure!

(me? I'd do it by sending a short message over and over and using pass/fail - a longer serial decode wouldn't make any difference to that)

Unfortunately that doesn't always work. Sometimes it is a specific message which can cause a device to misbehave every now and then. At some point I had to deal with a problem where a message went wrong once every 30 minutes to an hour.

I agree with nctnico here - sometimes the sequence of bits on the wire is what triggers and error (transmission losses, ringing, etc.), not the line itself.

(couldn't yet read the rest of the post. Thanks for the discussion and OP, please apologize for hijacking the thread.)

[snoopy]

Oh, so I see you already tried this with the Rigol. I will see what happens with the method you described on the DS4000. Thanks for sharing the procedure!

It's not until you use the scope in situ that you really find out its limitations. Perhaps there is a way around it but for decoding long lengths of data packets I kind of think not from the experience I've had with the Rigol DS1054Z to date. I'd like to try out the keysight under the same test conditions to see if it has the same limitations otherwise the logic analyser that I have ordered may do the trick and get me out of trouble in future scenarios

http://www.qdkingst.com/en/products/LA5016

cheers

[Fungus]

Perhaps there is a way around it but for decoding long lengths of data packets

Leaving aside for a moment the philosophy of decoding "long lengths of data packets" on a DSO, it's not difficult to line up the start of a byte/packet with the left edge of the screen. If you can manage that then decoding works perfectly on that screen of data.

OTOH, if you really do this sort of stuff ll day long then a logic analyzer is the way to go. You get gigabytes of capture memory, easy text searching (mouse and keyboard FTW!), you can put data packets in a 'list' view, there's all sorts of advantages.

The Saleae devices also have analog inputs which are displayed on screen perfectly aligned with the digital channels. It doesn't make them DSOs but I'm sure a lot of the people posting here could think of a use for them. 

In short: Use the right tool for the job.

[nctnico]

What happens here is that an I2C device is stretching the clock to make the I2C master wait but the I2C master doesn't care.

Just set to trigger on a runt pulse ?

In hindsight that could have been a solution but when starting doing the troubleshooting I had absolutely no idea what to look for. The only information I had was that an I2C device was giving the wrong information when a certain register was read. The problem might as well have been that the wrong register was read. So to get to the cause of the problem I wanted to see the I2C signals surrounding the operation which lead to reading the wrong value.

[kcbrown]

Usually, when you're looking at decoded data in such a way that you're interested in more than just what's on the screen at the time, you're doing so with the scope stopped.  There's no good reason for not decoding the entire acquisition under those conditions, and there's nothing that says that you have to compromise the waveform update rate for it.  I can understand why you might want to limit decoding to the displayed portion of the waveform during capture, particularly if your trigger conditions don't involve that decoding, but that's no longer valid once the scope is stopped.

I'm half with you on this one: This is the way oscilloscopes would behave in a Utopia.

OTOH oscilloscopes aren't really designed internally for this sort of programming pattern and I can see why they don't do it.

It depends entirely on whether or not the acquisition memory is available at scope stop.   Frankly, it almost has to be, because you can zoom and pan on that same data (I can envision implementations that would implement zooming and panning in hardware, but I very much doubt that such scopes are in the same class as the ones that tend to have the kind of problems we're talking about here).

So with that in mind, the designers have to choose where on the span between two points to put their implementation: decode of the entirety of memory (so that decoding need only be done once), or decoding of only what's on the screen (which means that decoding has to be re-done every time the view is changed).   

Keeping in mind that the "window" here means the section of the waveform that begins at the left screen edge and ends at the right screen edge, a proper hybrid approach to that, which would get you guaranteed correctness with minimum memory usage, would be to scan backwards from the start of the window and find the packet start indicator (protocol dependent, obviously), then note that location, then decode from there to the end of the window.   If the window start changes so that it's before the previously recorded packet start indicator, then you go through the above process again.  If the end of the window moves forward, then you need only decode from where the end of the window was previously to the new window end, since you'd already decoded the data in the other direction.  If you find a new packet start indicator, then you note that as well.  When that new packet start indicator falls off the left edge of the window, you can discard everything before it.

If you don't find a packet start indicator before the beginning of the window, then you can revert to screen-only decoding.

(are there any oscilloscopes that do?)

No idea, but since we're talking about software decoding, there isn't anything in principal or in practice (that I'm aware of) that would prevent it.

If the problem is consistent/repeatable then I bet you can solve it with a DSO that only decodes what's on screen (even if it it isn't the ideal tool for the job). If it isn't consistent/repeatable then I don't see how more decoding would help.

That depends entirely on how much there is between the packet start indicator and the problem area.  The problem with screen-only decoding is that the packet start indicator has to remain on the screen no matter how much data there is between it and the problematic area.   That could well be so much data that you simply can't display it.

[Fungus]

OTOH oscilloscopes aren't really designed internally for this sort of programming pattern and I can see why they don't do it.

It depends entirely on whether or not the acquisition memory is available at scope stop.   Frankly, it almost has to be, because you can zoom and pan on that same data

Nope. It has to be done in hardware because of the enormous amount of data.

The acquisition memory will be on one bus. Data is fed to it via DMA direct from the ADC.

Also connected to that RAM ss some sort of FPGA/ASIC which takes data from there and copies it to another buffer, scaled to fit the number of pixels visible on screen (depending on your timebase). It will also do the sin(x)/x interpolation, etc. There's no way this scaling/interpolation could be done in software on a cheap CPU, data can be coming in a 1GS/s even on low-end oscilloscopes.

This secondary buffer is all the main CPU has direct access to, not the original sample data. This is the reason most calculations are done "on screen".

It's not impossible to process the whole of sample memory but it would either have to be done in batches on the main CPU or directly inside the FPGA/ASIC.

No idea, but since we're talking about software decoding, there isn't anything in principal or in practice (that I'm aware of) that would prevent it.

Apart from (eg.) trying to access the 24MB of sample memory in 1200 byte chunks (on a DS1054Z).

In principal it could be done - they did something like it for the DS1054Z's improved FFT.

In practice it doesn't seem like anybody is. Not for serial decoding.

I'm thinking it would be too slow.

Math: If the system is designed to update four traces on screen at 60Hz then we're talking about 240 buffer accesses per second. To decode 24Mb of RAM needs 2000 accesses, that's 7 seconds for the decode. People here would be having a party laughing at it.

Yes, the decode could be done in the FPGA/ASIC but that assumes there's enough gates left over and they bothered to do it.

[nctnico]

This secondary buffer is all the main CPU has direct access to, not the original sample data. This is the reason most calculations are done "on screen".

It's not impossible to process the whole of sample memory but it would either have to be done in batches on the main CPU or directly inside the FPGA/ASIC.

Utter nonsense!

[Fungus]

This secondary buffer is all the main CPU has direct access to, not the original sample data. This is the reason most calculations are done "on screen".

It's not impossible to process the whole of sample memory but it would either have to be done in batches on the main CPU or directly inside the FPGA/ASIC.

Utter nonsense!

It's true! I read it on the Internet.

eg. http://debugmo.de/2013/03/whats-inside-tektronix-dpo5034/



The "display memory" in that block diagram is what the CPU has access to, not the "memory".

[nctnico]

And you believe that is the only way to make a digital oscilloscope? 

[Fungus]

And you believe that is the only way to make a digital oscilloscope? 

What do you mean "only"? A few seconds ago it was "Utter nonsense!" 

Of course it's not the only way, but it's a very sensible way, especially on a budget device where you have to keep chip costs down.

I guess you can unify the two memories into one but that'll drive up the cost of the RAM chips and memory controllers.

[james_s]

There are multiple different architectures that can and have been used in digital scopes, they all have advantages and disadvantages, some are geared toward a specific use case while others are more general purpose. Which is "better" is a subjective matter.

[Fungus]

There are multiple different architectures that can and have been used in digital scopes, they all have advantages and disadvantages, some are geared toward a specific use case while others are more general purpose. Which is "better" is a subjective matter.

I'm sure.

The only point I'm trying to make is that the decoding CPU doesn't necessarily have access to the sample data, that doing a full-memory serial decode on a device that isn't designed for it could be a programming nightmare.

[james_s]

I would say that it's a feature that a sensible modern scope ought to be designed for though. If the capture memory is separate from the CPU RAM it should be possible to transfer the entire capture RAM into CPU RAM for additional processing. IMO if it's going to bother to do protocol decoding, it ought to do so on more than what is displayed on the screen at once.

[Electro Fan]

Unfortunately that doesn't always work. Sometimes it is a specific message which can cause a device to misbehave every now and then. At some point I had to deal with a problem where a message went wrong once every 30 minutes to an hour.

Was the problem in the analog domain?

Yes. A logic analyser would not have caught this problem:

What happens here is that an I2C device is stretching the clock to make the I2C master wait but the I2C master doesn't care.

Sorry if I missed it, but what model Agilent scope made the decoder view in the image you posted?  Thx

[Fungus]

IMO if it's going to bother to do protocol decoding, it ought to do so on more than what is displayed on the screen at once.

Of course!

All we need is to persuade them to do it.

[nctnico]

Unfortunately that doesn't always work. Sometimes it is a specific message which can cause a device to misbehave every now and then. At some point I had to deal with a problem where a message went wrong once every 30 minutes to an hour.

Was the problem in the analog domain?

Yes. A logic analyser would not have caught this problem:

What happens here is that an I2C device is stretching the clock to make the I2C master wait but the I2C master doesn't care.

Sorry if I missed it, but what model Agilent scope made the decoder view in the image you posted?  Thx

A DSO7104A (but it has moved on to a new owner).

[GeorgeOfTheJungle]

A DSO7104A (but it has moved on to a new owner).

And what have you put in its place? If you don't mind me asking?

[kcbrown]

OTOH oscilloscopes aren't really designed internally for this sort of programming pattern and I can see why they don't do it.

It depends entirely on whether or not the acquisition memory is available at scope stop.   Frankly, it almost has to be, because you can zoom and pan on that same data

Nope. It has to be done in hardware because of the enormous amount of data.

The acquisition memory will be on one bus. Data is fed to it via DMA direct from the ADC.

Also connected to that RAM ss some sort of FPGA/ASIC which takes data from there and copies it to another buffer, scaled to fit the number of pixels visible on screen (depending on your timebase). It will also do the sin(x)/x interpolation, etc. There's no way this scaling/interpolation could be done in software on a cheap CPU, data can be coming in a 1GS/s even on low-end oscilloscopes.

This secondary buffer is all the main CPU has direct access to, not the original sample data. This is the reason most calculations are done "on screen".

It's not impossible to process the whole of sample memory but it would either have to be done in batches on the main CPU or directly inside the FPGA/ASIC.

I certainly don't disagree with this.  But see below.

No idea, but since we're talking about software decoding, there isn't anything in principal or in practice (that I'm aware of) that would prevent it.

Apart from (eg.) trying to access the 24MB of sample memory in 1200 byte chunks (on a DS1054Z).

That isn't something that prevents it.  And remember, the situation here is when the scope is stopped.  And especially if the implementation is done in the way I described, you'd be accessing chunks backwards starting with the one immediately prior to that of the display, and accessing only those chunks sufficient to arrive at the packet start location, then moving forwards from there, and saving the decoded values (along with their locations) so that you can easily display them should the user decide to pan/zoom.

In principal it could be done - they did something like it for the DS1054Z's improved FFT.

That's exactly my point.  There isn't anything that prevents them from implementing correct decoding.  And I'd argue that it's not necessarily uneconomical to do so either since it's just software -- it takes some additional time, but it only has to be done once.

In practice it doesn't seem like anybody is. Not for serial decoding.

I'm thinking it would be too slow.

Why in the world would it be too slow if you only do it when the scope is stopped??

It's a different matter altogether if the scope is running.  In that case, you can just do on-screen decoding and be done with it.   It might not be correct, but at that point there are real tradeoffs that you can't get away from.

Yes, the decode could be done in the FPGA/ASIC but that assumes there's enough gates left over and they bothered to do it.

Yeah, and it would also require additional memory that the FPGA/ASIC would have to write data and position information to.   I was thinking a strictly software-based approach.  Having hardware support opens up a lot of possibilities.

[Fungus]

it only has to be done once.

...assuming there's enough spare RAM to store all the decoded data along with its position on the timeline, etc.

How much serial data+position could 24Mb of samples actually decode to? What's the maximum?

Data is one byte, position would need 3 bytes. I'm thinking it could be a megabyte or more of data in total if you set the timebase to worst case.

[kcbrown]

it only has to be done once.

...assuming there's enough spare RAM to store all the decoded data along with its position on the timeline, etc.

Sorry, I meant that the programming only has to be done once.  It was a comment about the engineering resources needed to pull it off (and if you architect it properly, then you can make it easily adaptable to future architectures).

How much serial data+position could 24Mb of samples actually decode to? What's the maximum?

Data is one byte, position would need 3 bytes. I'm thinking it could be a megabyte or more of data in total if you set the timebase to worst case.

Well, the scope is stopped.  If the timebase is such that you wouldn't be able to display the decoded data, then you might not bother to do the decoding at all (until, of course, the user changes the timebase such that decoded data would be possible to show).  That tends to pretty severely limit the circumstances in which a decoding pass would be necessary.

If, on the other hand, you have a scrollable list that you're overlaying on the display, then you might have to deal with that problem.

For modern hardware, a megabyte of memory is nothing.   The memory for this doesn't have to be SRAM or anything special like that -- it's just general-purpose RAM for the CPU.  Modern ARM-based SBCs have gigabytes of RAM these days.   Even the DS1054Z might have enough in total for that (looks like the processor has a 32M RAM chip hanging off of it, the SK Hynix H5PS5162GFR: https://www.skhynix.com/product/filedata/fileDownload.do?seq=1909).

[snoopy]

There are multiple different architectures that can and have been used in digital scopes, they all have advantages and disadvantages, some are geared toward a specific use case while others are more general purpose. Which is "better" is a subjective matter.

I'm sure.

The only point I'm trying to make is that the decoding CPU doesn't necessarily have access to the sample data, that doing a full-memory serial decode on a device that isn't designed for it could be a programming nightmare.

I believe it is changed in the Tek mdo3000 scopes where decodes and search occur across the whole sample memory and not just what's on the screen, that is why the Tek will take sometime to complete decodes after a new trigger

cheers

[MrW0lf]

I believe it is changed in the Tek mdo3000 scopes where decodes and search occur across the whole sample memory and not just what's on the screen, that is why the Tek will take sometime to complete decodes after a new trigger

Surely you can gate to screen, zoomed area or cursors? In case if want check surroundings only if spotting something interesting around (trigger point) can stop and change gate to full record.
Dunno why opinion that full-mem decoding scopes have only option to decode all (which is inevitably bit slow) 
Another option - not decode at all on-the-fly, and then enable full record (or gated) decoding on stop.
Get luxurious event table over hundreds of MB with analog voltage stats for each packet etc...
IMHO this whole battle DSO vs DMO (data mining oscilloscope) is weird. Like comparing DSO and multimeter. Of course simple instrument is better/faster for simple task. But cannot do complex task at all...

[Fungus]

IMHO this whole battle DSO vs DMO (data mining oscilloscope) is weird.

I get the feeling that if the 'scope manufacturers give people a full memory decode they'll just start saying things like, "Wahhh! It's such a pain to have to scroll through the data by twisting a knob in zoom mode, why can't we have a vertical list view? CSV dump? Automatic search for bad signals?"

It'll never end. 

[nctnico]

IMHO this whole battle DSO vs DMO (data mining oscilloscope) is weird.

I get the feeling that if the 'scope manufacturers give people a full memory decode they'll just start saying things like, "Wahhh! It's such a pain to have to scroll through the data by twisting a knob in zoom mode, why can't we have a vertical list view? CSV dump? Automatic search for bad signals?"

My GW Instek GDS-2204E can do all that so I'm not complaining and I'm sure it is not the only oscilloscope with such features.

[MrW0lf]

I get the feeling that if the 'scope manufacturers give people a full memory decode they'll just start saying things like,

If?! 128MB of mixed analog/digital with database-like interface. Including search/sort by packet voltages:



Seems I have to continue my Pico 2000 review sometime. Strangely limited perception of modern budget scope powers is...

[nctnico]

IMHO Pico should change their UI so it can work with a touch-screen and create an Android version so you can connect your scope to a tablet. I have used a Picoscope a couple of times many years ago and it didn't inspire me to buy one. Needing to mess around with the mouse to adjust something made using it way too tedious.

[Fungus]

IMHO Pico should change their UI so it can work with a touch-screen and create an Android version so you can connect your scope to a tablet. I have used a Picoscope a couple of times many years ago and it didn't inspire me to buy one. Needing to mess around with the mouse to adjust something made using it way too tedious.

Yep, I get that their software is powerful but I just don't think having to use it via a PC for the basic stuff is good.

Maybe they could make another USB box with knobs and buttons on it. 

[MrW0lf]

IMHO Pico should change their UI so it can work with a touch-screen and create an Android version so you can connect your scope to a tablet.

I agree that going touch is inevitable. They are trying to go in this direction with new "big buttons" in taskbar etc. However for me as oldschool PC user this whole touch business does not compute. Microscopic movement of wrist with "tuned" laser mouse vs waving hands around... what next - throwing stones at cyborgs trying to "communicate" with them?  Due to my line of work I'm chained to PC 8+ hours a day... cannot image how tiresome would be poke (and clean) screen all the time. Plus touch is extremely inaccurate. In "old days" playing Quake you got so good that could basically hit individual pixels with rail gun, on the run... So dunno, think its very personal / cultural thing and depends on persons background and task at hand. I'm not saying that DMO with classical PC interface is for everyone and every situation. Would not climb comms pole with it... Maybe only fix tiny USB scope at the top of pole, or maybe robot-DUT and enjoy the show from safe place over LAN/WiFi extender.

[rsjsouza]

Very interesting discussion about the protocol decoding.

Out of the whole discussion I gather that, in practice, to have access to a well-round decoding feature the low entry bench oscilloscopes such as the DS1054Z or others are not the way to go. Only the more expensive models such as the GDS2204E and the DSO7104 have a complete decoding in memory. Not a surprise given the low-entry have more processing constraints.

Pico seems to have better options in this regard - no wonder, as the embedded hardware does not have to spare its time to process the User Interface. That and the fact they have "the world" to do whatever they can with the incoming data.

Just like having a capacitance meter in a regular DMM - limited when compared to a real LCR but good for the occasional quick check - the limited decoding has its place in low entry bench scopes. We only have to be aware of that.

Similarly to other facts of life, you must make a choice between cost and how well a feature is implemented... No surprises here.

[kcbrown]

IMHO this whole battle DSO vs DMO (data mining oscilloscope) is weird.

I get the feeling that if the 'scope manufacturers give people a full memory decode they'll just start saying things like, "Wahhh! It's such a pain to have to scroll through the data by twisting a knob in zoom mode, why can't we have a vertical list view? CSV dump? Automatic search for bad signals?"

My GW Instek GDS-2204E can do all that so I'm not complaining and I'm sure it is not the only oscilloscope with such features.

It can automatically search for bad signals?   That's quite a nice capability if that's the case.

What's the WFM/s rate difference between when you have full memory decoding turned on and when you have it turned off?