Products > Test Equipment
How does waveform updates on an oscilloscope work? Why do they work that way?
2N3055:
Lots of info here... Let's sift through it to see what could be relevant to OP's question.
Blind time: the time scope is not registering new acquisition after previous trigger. I say registering because ADC conversions are running all the time... Most new scopes are having digital trigger engine, so ADC is running all the time, putting samples into buffer all the time. Triggering engine is processing all the time until it encounters trigger term in input data.
Then for short time it stops being ready for new trigger and that is blind time...
So if you are doing protocol analysis by triggering on single communication packet, then you need to have a scope whose blind time is less then inter-packet time.
But, why would you look at packets this way? If you have a burst of 100 packets in 10ms, what you will actually see on screen?
Only last packet. Your super-duper fast scope is useless... You cannot see packets that change every millisecond.
To overcome this you need for scope to capture all 100 of them and stop for you to be able to go through data...
And you can do that two ways: by using long memory,where you capture 100ms of data and all the packets inside with zero (0) blind time inside that capture, or you can use segmented memory mode, where you capture short packets individually but capture 100s of those segments in one burst. That mode (segmented memory mode, manufacturers have different names for it) usually have very little blind time because it doesn't refresh the screen or do anything with data until it is finished with whole burst. Not a zero blind time, but really fast.
And that makes scope refresh rate pretty much irrelevant to decoding. Fast scope refresh rate is sometimes useful for some other tasks. But for decoding, not really.
As for decoding in software or hardware, I have scopes with both. Ones with software decodes I have are fast enough to be faster than me, i.e. the decode faster than I can read and comprehend.
Fact that my Keysight can decode much faster than I can read looks cool on paper but is not really useful.. I look at the packet where data is changing all the time and all I see is blur. Like benchtop DMM set to really fast conversion, where last two digits are just flipping so fast you can't see the number...
Software decoding was (is) a problem only with really slow (old or entry level) scopes, where it needs a second or two for decode to appear. If decode pops up in 100ms or faster, that is real time to a human.
And if you look at a packet to see if it changes, you can see that on waveform. Software decoding is asynchronous from waveform drawing if done properly. You still see waveform change even if protocol decoder is lagging....
For protocol decoding, long memory is more important than retrigger rate...
Someone:
--- Quote from: 2N3055 on April 17, 2023, 10:23:47 am ---As for decoding in software or hardware, I have scopes with both. Ones with software decodes I have are fast enough to be faster than me, i.e. the decode faster than I can read and comprehend.
--- End quote ---
As we keep saying, that you have not exploited the feature does not make it equivalent to the poorer cousin. When you know what you are looking for hardware triggers will get there quicker and easier, you often know something about the problem data/word but need to see it in context with other signals or data before/after it. Yes in some situations the software triggering will be quick enough to keep up (not a published specification) but there are real world examples where it isn't sufficient and hardware triggers are going to collect the capture faster. To take extreme examples to the other side some software decoders (and triggers in general) are nonrandom, you always get the first in a burst and the following are always caught in the blind time, they will never see the anomaly if it only occurs inside that blinded region (again coming from a real world example of that).
Long memory and sifting through (hoping the relevant point is within the captured window and not the blind time) vs triggering directly on what you are looking for are not equivalent as you make out.
--- Quote from: 2N3055 on April 17, 2023, 10:23:47 am ---For protocol decoding, long memory is more important than retrigger rate...
--- End quote ---
They are radically different tools for different situations, neither is more important than the other until you know specific details about the signals.
2N3055:
--- Quote from: Someone on April 17, 2023, 11:13:23 am ---
--- Quote from: 2N3055 on April 17, 2023, 10:23:47 am ---As for decoding in software or hardware, I have scopes with both. Ones with software decodes I have are fast enough to be faster than me, i.e. the decode faster than I can read and comprehend.
--- End quote ---
As we keep saying, that you have not exploited the feature does not make it equivalent to the poorer cousin. When you know what you are looking for hardware triggers will get there quicker and easier, you often know something about the problem data/word but need to see it in context with other signals or data before/after it. Yes in some situations the software triggering will be quick enough to keep up (not a published specification) but there are real world examples where it isn't sufficient and hardware triggers are going to collect the capture faster. To take extreme examples to the other side some software decoders (and triggers in general) are nonrandom, you always get the first in a burst and the following are always caught in the blind time, they will never see the anomaly if it only occurs inside that blinded region (again coming from a real world example of that).
Long memory and sifting through (hoping the relevant point is within the captured window and not the blind time) vs triggering directly on what you are looking for are not equivalent as you make out.
--- Quote from: 2N3055 on April 17, 2023, 10:23:47 am ---For protocol decoding, long memory is more important than retrigger rate...
--- End quote ---
They are radically different tools for different situations, neither is more important than the other until you know specific details about the signals.
--- End quote ---
I really don't understand software and hardware TRIGGERS mentioning ... TRIGGERS are hardware (for both analog and decodes) on Siglent for instance...... Screen data decoding is software... But triggers are hardware based state machine... That works in normal and segmented mode in full speed.
That is why I said that for Siglent, for instance, only on screen update rate (human readable) of actual messages is related to software speed.
But triggering is hardware based digital trigger working off the ADC full sample rate..
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...
ballsystemlord:
Thanks again. That answers my question.
Someone:
--- Quote from: 2N3055 on April 17, 2023, 12:35:35 pm ---
--- Quote from: Someone on April 17, 2023, 11:13:23 am ---
--- Quote from: 2N3055 on April 17, 2023, 10:23:47 am ---As for decoding in software or hardware, I have scopes with both. Ones with software decodes I have are fast enough to be faster than me, i.e. the decode faster than I can read and comprehend.
--- End quote ---
As we keep saying, that you have not exploited the feature does not make it equivalent to the poorer cousin. When you know what you are looking for hardware triggers will get there quicker and easier, you often know something about the problem data/word but need to see it in context with other signals or data before/after it. Yes in some situations the software triggering will be quick enough to keep up (not a published specification) but there are real world examples where it isn't sufficient and hardware triggers are going to collect the capture faster. To take extreme examples to the other side some software decoders (and triggers in general) are nonrandom, you always get the first in a burst and the following are always caught in the blind time, they will never see the anomaly if it only occurs inside that blinded region (again coming from a real world example of that).
Long memory and sifting through (hoping the relevant point is within the captured window and not the blind time) vs triggering directly on what you are looking for are not equivalent as you make out.
--- Quote from: 2N3055 on April 17, 2023, 10:23:47 am ---For protocol decoding, long memory is more important than retrigger rate...
--- End quote ---
They are radically different tools for different situations, neither is more important than the other until you know specific details about the signals.
--- End quote ---
I really don't understand software and hardware TRIGGERS mentioning ... TRIGGERS are hardware (for both analog and decodes) on Siglent for instance...... Screen data decoding is software... But triggers are hardware based state machine... That works in normal and segmented mode in full speed.
That is why I said that for Siglent, for instance, only on screen update rate (human readable) of actual messages is related to software speed.
But triggering is hardware based digital trigger working off the ADC full sample rate..
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 ---
There are scopes out there with no hardware serial trigger, but do have software serial decode, or the serial trigger only frames the packet and does not qualify/inspect the contents. Yet this thread is a mess of people not making that key separation which answers part of the question of the OP. You can talk about your specific situation and be correct, but stop making it sound like that is true for everyone and everything because it is not.
Even with hardware triggers that extract errors or specific data values/patterns, there is still dead time which can miss some events. In some situations that is important and cannot be replaced with deep memory, instead segmented memory can be the better choice, or a more powerful trigger. Long memory is not a replacement for short re-arm time.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version