Help with Oscilloscope purchase decision.

[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.