Products > Test Equipment
How does waveform updates on an oscilloscope work? Why do they work that way?
<< < (11/14) > >>
pdenisowski:
If you're looking at a relatively low speed protocol where the physical layer is (assumed to be) clean and reliable, then a cheap USB logic analyzer will often be good enough.  I have a whole collection of these and for the most part, there isn't much difference between them.

In most other cases, a scope has significant advantages for serial decodes, most of which other people have already touched on, such as hardware triggering.  One of the biggest ones is the mixed signal (analog + digital) aspect.

For example, if I'm trying to debug an issue on a CAN bus, I might want to only capture frames with a bad CRC or a recessive ACK bit.  This requires a hardware trigger unless I want to somehow try to capture and post-process a huge number of frames (and assuming the error is frequent enough to make this practical). 

But having captured an errored frame, how do I determine the root cause of the error?  Was the CRC incorrectly calculated by the sender?  Or were bits corrupted on the bus?  If I trigger on errored frames, I can then look at the analog signal(s) to see what happened during the errored frame - noise, misbehaving node, etc.  This is what makes a mixed signal oscilloscope such a powerful tool:  the ability to correlate events in two domains.

There's a reason why pretty much every modern oscilloscope - even "hobbyist" scopes - has an MSO option, even though this option is always considerably more expensive than a $20 USB logic analyzer.

Again, there are plenty of cases where that $20 USB logic analyzer is more than sufficient, but there are also plenty of cases where it isn't :)


jonpaul:
Research the many fine digital Oscilloscope application notes simcem1980s..1990s from

Tektronix
Hewlett Packard
Lecroy

These detail the issues of real time, sampling, ADC sampling, memory depth.

See Tekwiki, W140, etc

Bon journée

Jon
tggzzz:

--- Quote from: 2N3055 on April 20, 2023, 10:36:34 am ---
--- Quote from: tggzzz on April 20, 2023, 09:22:08 am ---
--- Quote from: nctnico on April 19, 2023, 10:20:50 pm ---
--- Quote from: 2N3055 on April 17, 2023, 12:35:35 pm ---So you would have trigger on every packet, and it's waveform would be shown on screen in real time. And decoding would skip some decodes in a burst and show you only last one. Instead of unrecognizable blur and then the last one... Same difference...

--- End quote ---
In some cases it is usefull to look at the decoded data in near realtime. Think about checking which bits change every now and then when reverse engineering a protocol.

--- End quote ---

If you are looking for changes in bits, then use a digital domain tool (LA, protocol analyser, printf()) to capture the bits, and a PC application to show diffs.

A scope is a non-optimum tool for that, even if it can be bent to the purpose.

--- End quote ---

I agree but premise of the question is a scope for that use.. Not what are alternatives.

--- End quote ---

If people are discussing bicycle's characteristics and how they can be problematic when wanting to cycle over the Alps/Rockies, I think it is useful to point out that cars are a more appropriate tool.

Don't you?


--- Quote ---I did agree with you many messages ago that you can even use analog CRT scope for SI and some sort of LA for actual decoding. How it was done for ages..
When you don't want to look at lots of decoded data, digital scope with decoding is useful because you can do both at the same time. Saves time and fiddling with connections...

But I don't want to look at 1000 messages on scope screen. Even super expensive scopes with HUGE 15"  :-DD screens are joke compared to the screen on a PC.. So for that job, for me it is MSO Pico or a LA... occasional print to uart. For stuff I'm making I bridge Pico's trigger deficiencies by toggling a pin of µC at critical points and trigger of that. Kind of "breakpoints" for scope.....

--- End quote ---

If you can be certain that a tool will meet the requirements of your use case, then by all means use that tool.

But if you think a tool's characteristic weaknesses might make your task difficult or impossible, don't obsessively discuss fine details of such tools. Far better to simply choose a different type of tool without the weaknesses.

Not rocket science :)
2N3055:

--- Quote from: Someone on April 20, 2023, 10:14:40 am ---
--- Quote from: 2N3055 on April 20, 2023, 07:54:56 am ---As for missing packets  in real time, if scope has hardware serial triggers, if you miss packets on the screen it won't be because trigger missed it, but because you got fast burst of 3-4 packets in 100 µs, and you will be able to see only the last one because previous 3 went by in such a hurry you didn't see them.
--- End quote ---
Finally you are actually getting to the point, the dead time can miss valid triggers. Scopes can run with segmented or waveform history modes to collect such bursts for inspection, but they are still limited by finite dead time.... which can be a different length when the serial trigger or decode is enabled.

--- End quote ---

No you missed the point: none of the triggers were missed. I used my very fast MSOX3104T and was monitoring trigger out. It was triggering at 100 packets per second. On screen, you could see waveform frantically flickering, but decoded string under waveform was standing still.. It didn't change. Scope didn't refresh display of DECODED data because changed too fast..
Only thing that was pointing to data being non static was waveform.

So in order to make sense what is happening here I either have to : segment capture some number op packets and analyse then offline (STOP mode) or capture longer single capture to get multiple packets that way, STOP and analyse online.
Again I'm not talking waveform but decoded strings.

Real time looking at scope decoding data in Normal RUN mode is useful only if data we are triggering on is maybe up to 5 Hz. That is as fast as I could actually catch a glimpse  of something useful.

Which funny enough is same for Siglent SDS6000ProH12 (6000A family) and SDS2000HD. They are slower than Keysight but fast enough
if triggers are slower than 5 per second. If you go faster than that both Siglents and Keysight start skipping decoded data in normal RUN mode. Still faster, Siglent will start loosing packets but you won't be able to see that on screen. I had to connect both Keysight and Siglent in parallel and monitor Trig Out with another scope.... But on screen, both will just have some waveform flickering and mostly static decoded data.  But looking at screen both are equally useless, decoding wise. You might as well disable decoding and simply look at waveform..

So if data to be decoded is slower than some speed both types of scopes will do. If data is coming fast, you need to use segmented or long capture for both... That is what I'm trying to say...
2N3055:

--- Quote from: tggzzz on April 20, 2023, 10:53:48 am ---

--- End quote ---

I hear you , but it is called "questions and answers",  not "lets' ignore questions  and show them  the errors of their ways.."
That is more like priest work...  :-DD

And you and others already mentioned it competently, I had nothing to add...
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod