Products > Test Equipment

How does waveform updates on an oscilloscope work? Why do they work that way?

<< < (4/14) > >>

2N3055:

--- Quote from: Someone on April 17, 2023, 11:08:37 pm ---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.

--- End quote ---

I don't know of any current production scope that has software triggers (out of mainstream brands i know off). I certainly don't know them all naturally..

You seem not to understand what I want to say. Let's take example of my Keysight 3000T and Siglent SDS6000Pro H12.
MSOX3000T has faster retrigger rate in normal mode, no question. But it has 4MPts of memory total while SDS6000 has 500MPts and even more in segmented mode.
Which means I can capture 125 times longer capture at same sampling rate and just capture whole burst of data from sensor for instance.
And for data in that capture, there is 0 blind time. Zero.
With MSOX3000T I have to use segmented memory...
And I have to have very short blind time not to miss packets...

With sds6000 I don't have to use segmented  memory most of the time.  And if I do I get many more segments.. and blind time is minimal because in segmented mode it skips processing. In segmented mode difference is minimal.

Segmented memory is better for sparse packets on fast protocols (short packets, long dead time). Which incidentally makes short retrigger time less critical. No missed events.

For a burst of really fast packets with very little interpacket time, continuous long memory can capture tens of thousands of packets in single go. With zero blind time inside. No missed events.


As for decoding speed, on scopes with hardware trigger and software decode, decoding is asynchronous to capture. If decode is too slow to decode every screen refresh,

Short rearm time is (like I said) useful. If that is so important and if you feel that software decoding is slowing down retriggering ( it should not because trigger is hardware and decode processing is not included in retrigger time but in display threads), you can disable decoding, capture packets you like and then stop scope and enable decoding. It will decode it then. That is one great advantage of decoding as postprocessing. You can also grab some data and play with decoding settings until you get meaningful data. Compare that with MSOX3000T that you need to have all protocol parameters perfectly set before capture or it won't decode right and you have no other choice but to capture again...

And at the end of the day, I use both Siglent, Pico and Keysight and they are all up to the task, just by using different techniques.

That is one thing.


Other is this: If you are looking at scope interactively with packets flying by, hundreds per second, looking at the screen will show you just a bunch of changing data and waveforms.. You will see just a blur.   
You need to either :

1.  trigger on a rare packet that happens rarely enough for you be able to see, read and comprehend messages
2. Capture 100s of packet individually using segmented mode, stop and sift trough them. In which case even scopes with software decode don't do any processing and have extremely fast retrigger rates.. POI is very high on all.
3. Capture very long capture that has 100s of packets inside, stop and sift trough them. In which case there is 0 retrigger time between packets and POI is 100%.

Someone:

--- Quote from: 2N3055 on April 17, 2023, 11:53:59 pm ---Which means I can capture 125 times longer capture at same sampling rate and just capture whole burst of data from sensor for instance.
And for data in that capture, there is 0 blind time. Zero.
--- End quote ---

--- Quote from: 2N3055 on April 17, 2023, 11:53:59 pm ---No missed events.
--- End quote ---
Which immediately means you can only capture for that length maximum with 100% coverage (and slower offline search/processing). I get it, you are correct for that specific situation. No complaints. But that is almost no use at all if you are trying to pull out intermittent problems that appear in minutes or hours of time (longer than the maximum memory depth).

If you can capture the entire systems operation within the memory sure, go for it and have 100% capture probability. But that is not the situation for every case.

--- Quote from: 2N3055 on April 17, 2023, 11:53:59 pm ---1.  trigger on a rare packet that happens rarely enough for you be able to see, read and comprehend messages
2. Capture 100s of packet individually using segmented mode, stop and sift trough them. In which case even scopes with software decode don't do any processing and have extremely fast retrigger rates.. POI is very high on all.
3. Capture very long capture that has 100s of packets inside, stop and sift trough them. In which case there is 0 retrigger time between packets and POI is 100%.
--- End quote ---
I think you are wildly misinformed and inexperienced if you believe turning on software decodes does not slow down any scope or increase the blind time. Regardless, as I have said from the start and you keep ignoring/discounting/arguing against, it is unusual to have systems where you can capture 100% of the systems operation in memory. So to say that is a given absolute and true statement is why this keeps going around and around.

To rephrase those 3 points in a more balanced and representative manner:
1. capture the problem with a complex hardware trigger if possible, captures the first event and others following it with some blind time
2. generic trigger with post processing/search in segmented memory, longer blind time unless the entire operation fits in memory
3. capture everything in memory and search through it, blind all the time outside that capture

Long memory is not 100% capture in the general case, only IF you can guarantee that the entire possible system operation and state is captured within. I could show you examples where that is a 0% capture rate every time, equally true and equally not generalised. In the general case any one of those options might be the most appropriate or have the least blind time. But the OP asked about blind time and how that related to protocol analysis, so the answers are surprise surprise nothing to do with "what happens with protocol decodes within a single capture?" or any of your 3 examples.

Scopes miss everything outside their captures so its up to the user to make sure the triggering and memory settings are set for the task at hand.

tggzzz:
This whole discussion appears to be ending up down a traditional rathole, equivalent to trying to use a hammer to insert a screw.

Use a scope to ensure signal integrity, i.e. that the analogue waveforms will be correctly interpreted as digital signals.

Then flip to the digital domain, and use a logic analyser's superior clocking, triggering and filtering to discard (i.e. don't store) the irrelevant crap.

If that is insufficient, use a protocol analyser to concentrate on the messages in conversations between devices.

2N3055:

--- Quote from: Someone on April 18, 2023, 12:20:20 am ---
--- Quote from: 2N3055 on April 17, 2023, 11:53:59 pm ---Which means I can capture 125 times longer capture at same sampling rate and just capture whole burst of data from sensor for instance.
And for data in that capture, there is 0 blind time. Zero.
--- End quote ---

--- Quote from: 2N3055 on April 17, 2023, 11:53:59 pm ---No missed events.
--- End quote ---
Which immediately means you can only capture for that length maximum with 100% coverage (and slower offline search/processing). I get it, you are correct for that specific situation. No complaints. But that is almost no use at all if you are trying to pull out intermittent problems that appear in minutes or hours of time (longer than the maximum memory depth).

If you can capture the entire systems operation within the memory sure, go for it and have 100% capture probability. But that is not the situation for every case.

--- Quote from: 2N3055 on April 17, 2023, 11:53:59 pm ---1.  trigger on a rare packet that happens rarely enough for you be able to see, read and comprehend messages
2. Capture 100s of packet individually using segmented mode, stop and sift trough them. In which case even scopes with software decode don't do any processing and have extremely fast retrigger rates.. POI is very high on all.
3. Capture very long capture that has 100s of packets inside, stop and sift trough them. In which case there is 0 retrigger time between packets and POI is 100%.
--- End quote ---
I think you are wildly misinformed and inexperienced if you believe turning on software decodes does not slow down any scope or increase the blind time. Regardless, as I have said from the start and you keep ignoring/discounting/arguing against, it is unusual to have systems where you can capture 100% of the systems operation in memory. So to say that is a given absolute and true statement is why this keeps going around and around.

To rephrase those 3 points in a more balanced and representative manner:
1. capture the problem with a complex hardware trigger if possible, captures the first event and others following it with some blind time
2. generic trigger with post processing/search in segmented memory, longer blind time unless the entire operation fits in memory
3. capture everything in memory and search through it, blind all the time outside that capture

Long memory is not 100% capture in the general case, only IF you can guarantee that the entire possible system operation and state is captured within. I could show you examples where that is a 0% capture rate every time, equally true and equally not generalised. In the general case any one of those options might be the most appropriate or have the least blind time. But the OP asked about blind time and how that related to protocol analysis, so the answers are surprise surprise nothing to do with "what happens with protocol decodes within a single capture?" or any of your 3 examples.

Scopes miss everything outside their captures so its up to the user to make sure the triggering and memory settings are set for the task at hand.

--- End quote ---

We are finally getting somewhere.. I know my English is not very good but we seem to have more trouble than usual. But getting there...

First I am talking about decoding and looking at serial protocol data on scope ( that is what OP asked about). Not about general scope use. That is so wide and unpredictable and I would not generalize that in two sentences, and a reason why there are more than one type scope out there...

Also OP spoke about Rigol scope that has I2C, SPI, CAN, UART protocols...  Not about 10 Gbit Ethernet.
So speeds are known in some general terms, and order of magnitude is known...
CAN at 1MBit will have packets in 100 us range for instance..

You usually cannot EVER capture whole system messages in memory. You divide and conquer. 
Hence you either set trigger for specific data ( address, payload, error type).
Or you capture a manageable chunk (by either segmented capture or single long capture), stop (or single in a first place) and sift through data. By which you gain knowledge what is in there so you can start drilling down to specific information.

And then we get to the point that if I use my scopes in segmented mode, they all are VERY fast.
While Keysight has faster retrigger time than Siglents I have here in normal display mode. But in segmented mode Siglents have less than 2 µs blind time , and Pico 3406D has less than 0.6 µs and is faster then Keysight for that....

And yes, on SDS6000, enabling software decode DOES NOT slow down data acquisition in normal mode. It is not me here who is talking without knowing..
I know. I measured ..
And in segmented mode ALL processing except trigger and memory acquisition is stopped so there can not be influence..

Of course there might be scopes out there that behave like you said. I don't know. But those I have behave the way I explained.

Someone:

--- Quote from: 2N3055 on April 18, 2023, 09:57:14 am ---First I am talking about decoding and looking at serial protocol data on scope ( that is what OP asked about). Not about general scope use.
--- End quote ---
1500 words on and you still try to talk about what you want to talk about. Ignoring the OPs question, and taking a long long time to add in the honest details.....    :=\


--- Quote from: 2N3055 on April 17, 2023, 11:53:59 pm ---I don't know of any current production scope that has software triggers (out of mainstream brands i know off). I certainly don't know them all naturally.
--- End quote ---

--- Quote from: 2N3055 on April 18, 2023, 09:57:14 am --- Pico 3406D has less than 0.6 µs [blind time]
--- End quote ---
Arent Picoscopes in that category of software based serial triggers? At which point the best case blind time of captures is irrelevant when talking about sustained throughput.

Yes you want to talk at length about non realtime serial analysis/search. But dont make out like that is some replacement for all realtime cases, or add mountains of half-truths and misleading drivel.

OP asked really clearly what is the interaction between dead time/update rate and serial decode, that has been covered quite well in a non biased and polite manner.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod