Here’s a demonstration how search across the history works on the SDS5000X with FW 0.8.2R1.
Look at the first screenshot:
SDS5104X_PRBS_10Mbps_Capture
Here we can see – well, nothing but a green wall
It is the 1ms capture of a 10Mbps PRBS-28 signal and let’s see how often we can find a positive 1.6µs wide pulse in that data stream.
Next step is to hit the [Stop] button and analyze the current record data. For this a search for positive pulses between 1.59 and 1.61µs is set up:
SDS5104X_PRBS_10Mbps_Search_Current
Search didn’t yield any result yet. The small note “Event Num 0” hints on zero hits for the current search. Now we have to enter History (we could have done that before already instead of hitting [Stop], but I didn’t want to proceed too fast):
SDS5104X_PRBS_10Mbps_Search_History_86
In the history, we ‘re still looking at the most recent acquisition frame and we already know that there is no hit. So we just activate the “Stop On Search Event” function and then press the reverse playback button. Within less than a second we find the one and only matching record. Please note that the playback speed can be freely defined – in this example it was set to 1ms per frame.
SDS5104X_PRBS_10Mbps_Search_History_24
The event got a white marker at the top of the trace display and the (end of the) event is centered on the screen. We can engage zoom in order to see the waveform and verify that we’ve indeed found a 1.6µs wide positive pulse.
If you look at these pictures, you’ll notice that we’ve captured a total of 86 frames of 5Mpts each in the history.
Record length is 5Mpts, so let’s do the math:
86 x 5Mpts = 430Mpts
This means that even though 250Mpts is huge already, we get even more for the history and also sequence recording, where the SDS5000X has low blind time and provides a maximum of >500kWf/s.
Now let’s try something different. Here’s the 50ms capture of a 200Mbps PRBS-28 data stream and we’re looking for positive pulses 79 to 80ns wide:
SDS5104X_PRBS_200Mbps_Search_Overview
No history here, we’ve captured 250Mpts at once. Search works much faster in this case – it only takes a fraction of a second to find all 34 occurrences of the 80ns wide positive pulses in the record. Each of them has a white marker at the top of the display window. For closer inspection we need to engage zoom and then we use the [Navigate] function to find the individual search events:
SDS5104X_PRBS_200Mbps_Search_01
If we turn the event list on, then all events are displayed with their respective timestamps. We can scroll through the list and select any of the entries in order to have it centered in the zoom window. Here’s an example for event #21:
SDS5104X_PRBS_200Mbps_Search_Eventlist_21
Now let’s try this with segmented memory. Of course this is not a realistic test scenario; segmented memory is best suited for infrequent trigger events and of course I could set up one for the PRBS stream, but then the search event would most likely be found either in all segments or in none of them. That’s why I have to stick with the unspecific edge trigger.
History frame #60 contains the first hit, i.e. a positive pulse width of 80ns:
SDS5104X_PRBS_200Mbps_Search_History_01
History frame #3958 contains the next (2nd) hit:
SDS5104X_PRBS_200Mbps_Search_History_02
And finally, here’s the last (14th) hit in history frame #49154:
SDS5104X_PRBS_200Mbps_Search_History_14
Search through the segmented memory takes a lot longer than within a single record – we can search about 12500 history frames per second. Consequently, a search through the maximum of 100k history frames takes 8 seconds. So it’s not the memory size, but overhead of the list structure with 100k entries that takes its toll. Here we can see one of the reasons why e.g. a Keysight MSOX3000T can be so responsive: If the SDS5000X where limited to just 1000 history frames, it could search through the entire segmented memory within just 80ms …