Siglent SDS1000X and (MSO) SDS1000X+ series oscilloscopes

[rf-loop]

Something about serial decoding, with new P06 FW.

Here simple (UART) RS232 9600baud 8N1 and 259 bytes long message.

One important rule. Trigger position need be in memory range if you want byte count in table is from trigger. If trigger is left from main window left border it decode but byte count in table start from left border.
(If use window zoom, always byte count start from zoom window left border)
Memory for this function is 1.4M (with some t/div 1.8M)  when single channel in use. If use two channel, example for RX and TX then half.

Now there is available hex, decimal, binary and also ASCII.

If have long dense string in window it can not of course show decode result in bottom decode display. If all ok it show blue bar. If there is errors then these are marked with red.  But in this case you can use window zoom and move this window to position in string what you want look.
If you do not want window zoom you still can look what are there by scrolling decode table. In this case table byte count start from trigger if trigger is in memory area. (Whole memory lenght is in main window). Same as also time. (I hope they add small indicator on waveform display where is my selection in table. So that if I have selected byte 173 there is indicator where it is horizontally in waveform, just example small dial arrow or something like it. Example just top on the screen where is also trigger position symbol but different shape and color))

If use window zoom, table time is from trigger position BUT table byte number is from bottom zoom window left border. (I hope they add in some later FW update one column where is also counting from trigger position.)

If you want after decoding you can stop and zoom in or out in main window using t/div  for details and go to horizontal position what you are interest or you can also in stop mode turn window zoom on.

If scope is stopped without decoding. If you now turn decode on. It can not decode. But if it is decodes in run mode. You can zoom and go to details where ever it is in decoded acquisition.

Fun detail.
In second image there read "Decimalism".  What -ism.
Chinese language translation is difficult if do not use special dictionary (engineering, medical, chemistry, electronics, etc depending what is doing)
Some times I hope they use western professionals who can tell what are right terms for use in T&M equipments. Also this can see in many data sheets. I can not understand why they do not open example older HP and Tek data sheets. There they find everything what they need. Also, as we know they have big difficulties some times to understand what are differencies with m and M etc.  Just as difficult as if we try read chinese text. (example: it is not mhz, it is not mHz if mean Mega Herz. It is not v if mean voltage. It is V.   It is not T/div if mean time per division. It is t/div. And so on.

[rf-loop]

About waveform update rate now after FWP06. Some things works better.

Mostly there is manufacturers advertisements about maximum speed or even maximum peak speed using just these settings what give best speed. In practice we use oscilloscope with many kind of settings and also perhaps measurements and cursors on etc. Scopes are very different with these things if look wfm/s speed.

In SDS1000X measurements, persistence, manual cursors and sin(x)/x do not affect speed or the effect is so small that does not matter.

There is one factor, and its effect is significant.
Display mode vectors (lines) or dots if timebase is faster or equal 200ns/div with one channel in use or faster or equal 500ns/div when 2 channels are in use.

Other things what reduce wfm/s speed are, window zoom. (this is bit complex where also zoom factor have effect depending base speed) Later I will show something about it.

Then if go to other than normal acquisition mode. Averaging drops wfm/s speed lot of, same is ERES. Peak detect effect is so small, if any, that it does not matter. Later about these.


The first thought when talk about dots display mode is often: "I want to use vectors not dots. I like see continuous line."

But, here need remember speed. Dots mode draw (mostly) very continuous line when wfm/s speed is high enough.

There is lot of captured waveforms overlayed in one TFT update. If take example 50ns/div and one channel. There is inside TFT update period wfm/s speed around 70kwfm/s *). If TFT is updated 25 times in second there is then 2800 wfm overlayed in one TFT picture (this is one thing what give data for intensity gradation) and next turn after 1/25s again next 2800wfm and so on. There is so much dots that it is like continuous line.
*) 60.9kwfm/s average. There is 70kwfm/s burst speed, then pause, burst, pause...etc. Pause is every time scope is processing data and updating display. Pauses + 70k bursts give this 60.9kwfm/s.

Also it need ask do you really need fastest possible wfm/s speed for just this work you are doing.
It is perhaps the wrong idea if we believe that always have to be the maximum speed. Also it is good to remember that there is lot of high-end oscilloscopes what have maximum wfm/s speed somewhere around 1kwfm/s! (If this feels unbelievable please look example Keysight (Agilent) most modern and expensive Infiniium series models. Of course these scopes have many features what can help for example rare glitch hunting, so truth is not so simple that most fast is always best. This is partially marketing trick and no one can say this scope is better because it have better wfm/s speed.
It is partially marketing trick but then it is also very important specially in oscilloscopes what do not have most advanced (and expensive) features. When we go over around 20kEuro prices situation may be different.

Who is thinking this as only truth he do not know what he is talking. Just as stupid as if think best camera is what have highest amount of pixels or best car is what maximum speed is highest.


Note that always backround running history recording works just with these wfm/s speed. When you stop scope you can search previous captured single waveforms what was stored to history buffer before you stop. Maximum count of individual waveforms is same as in sequence mode segments amount depending memory and speed settings.

Sequence mode wfm/s (segment/s) speed is very different, this is handled previously. In Sequence mode dots/lines or any these other settings do not have effect. This is whole different story (max 500000 wfm/s)

In this table is compared lines and dots display mode in normal acquisition mode and trigger mode normal, rising edge. Trigger horizontal position zero (center).

[rf-loop]

FW update P06 have changed Sequence mode.  Test with SDS1202X show that now it overlay all acquired segments in sequence to display after whole sequence is ready.  It is not free. Price is that it need more process time between sequences depending amount of segments in sequence and also depending display settings. This is low price for this improvement. Segments/s speed is not affected. Only whole Sequence repeating interval is increased.

Important is that when it update display after whole sequence there can see overlayed every segment so that detecting anomalies is possible. After display is updated it start new Sequence if we are repeating Sequence acquisitions it keep this last display until next Sequence is ready and processed for display.  (if in this mode use vectors display mode in case when there is high amount of segments it may rise processing time lot of. This is natural and is acceptable.)

This is very good fix/improvement.


What I can hope is that Siglent add also user selectable overlay mode also to "History" player so that if look normal history or segmented acquisition it is more easy to detect differencies.  Overlay all and overlay last displayed n (user selectable amount) segments.  Also I hope that variable persistence can use in history viewer/player. This add more value for normal backround history and for Sequence function.

[rf-loop]

Bit more testing new FW P06  sequence mode.

Now I'm sure it is mapping all segments to display after one Sequence is ready. In continuous mode and in single Sequence
mode.


Images

1. Normal acquistion.
You can see image when more and more segments are stacked (overlay)
2. 50 segments Sequence
3. 300  segments Sequence
4. 5000 segments Sequence. (in this image I also push multifunction knob to call virtual keyboard what can use for set values. Previously only turning this knob adjust value, nor can use turning for select or enter value using this virtual keyboard, what is much more fast with big numbers.
5. 29000 segments Sequence.

6-7 pulse period is slow 100us (100kHz) This Sequence is 100kwfm/s (100ksegment/s)
Max speed is 500ksegment/s.
If do not have sequence acquistion mode and need capture this to continuous memory.  29100 segment and period 100us (100000ns) Samplerate is 1GSa/s.  29100*100000=2910000000 points. It need 2910M points.  This is one important advantage of Sequence mode.

6. Signal have 29100 pulses. One pulse include one glitch. (1:29100)
this image include stacked (overlayed) every 29100 segment.

7.Looking individual segments can find that that in this case this one glitch is in segment number 51.

[Performa01]

Thank you for this very descriptive test, the results look excellent!

I have updated the SDS2304 but didn't get around playing with it yet.

[rf-loop]

Thank you for this very descriptive test, the results look excellent!

I have updated the SDS2304 but didn't get around playing with it yet.

Also I have not yet tested SDS2304 but with just playing with it after new FW looks like same. Exept, SDS2k have more processing power so also processing after Sequence captured and before displayed is more short.

Now when all segments are mapped to display it also  means more long time before it can start new sequence. If user need continuously repeating sequences it is better to use display mode dots if possible. (example, if there is 40000 segment in sequence and every segment is 700 point  there need handle 27960000 intervals of the sample points for lines before whole sequence can dipslay so that there is all segments overlayed, it takes while.)

[rf-loop]

Small test about Pass/Fail mask test speed with new FW P06

Pass/Fail mask test do not affect normal wfm/s speed. It works with full wfm/s speed in all cases.

Here input signal is pulses. Frequency 1MHz.
Manually triggered generated exatly 1000000 pulses burst.
Trigger normal.

When burst arrive it can capture and test 61000 waveforms.
Independent of test result. Test fail and pass speed is same.
Every single acquisition if mask test result is fail it generate Pass/fail output 2us wide pulse. Inserted small image in first image is from second scope (SDS2303) connected to 1202X P/F output. (in this image case there come out 61029 pulse.(yes, it is counted also using HP53131A)




OMG...  There in image text read Bug,  it is NOT The Bug. Instead, it is just as clever as it looks like!

[Performa01]

Regarding the "small bug" you are indicating:

The signal always has the color of the associated channel, yellow in this example.
Mask violations are always shown in red.

If you have a constant signal causing permanent mask violations, the red trace might never get displayed as the actual signal (the yellow one) might take priority over that. If that's actually the case, it could be discussed whether it would be better to give the error trace priority on the display. But then again, permanent mask violation isn't a real use case anyway.

I have suggested to include the persistence setting for displaying the error trace and Siglent have implemented that a while ago - I just don't know whether this is already included with the current official firmware. You can try - set up a test with infrequent mask violations and set persistence in the display menu, then you should clearly see any faulty signal in red on the screen.

With infinite persistence this means you can start the mask test, leave for a beer or two, then come back and not only know the number of violations that occurred in the meantime, but also see what exactly was going wrong with the signal.

[rf-loop]

Regarding the "small bug" you are indicating:

The signal always has the color of the associated channel, yellow in this example.
Mask violations are always shown in red.

If you have a constant signal causing permanent mask violations, the red trace might never get displayed as the actual signal (the yellow one) might take priority over that. If that's actually the case, it could be discussed whether it would be better to give the error trace priority on the display. But then again, permanent mask violation isn't a real use case anyway.

I have suggested to include the persistence setting for displaying the error trace and Siglent have implemented that a while ago - I just don't know whether this is already included with the current official firmware. You can try - set up a test with infrequent mask violations and set persistence in the display menu, then you should clearly see any faulty signal in red on the screen.

With infinite persistence this means you can start the mask test, leave for a beer or two, then come back and not only know the number of violations that occurred in the meantime, but also see what exactly was going wrong with the signal.

Thank you. Good!
In my previous text it is this kind of..... when do with lack of time

This is nice (not tested if it is there in SDS1000X also but if not now , then later.

[rf-loop]

About waveform update rate.
Of course it is well known that this is bit complex group of things. Also important but same time also not very important depending what we are doing and what tools/features oscilloscope have.

Usually if oscilloscope have trigger output where is available one pulse for every trigged acquisition it is quite simple, and typically we count how many trig out pulse there exist example in one second. I think mostly there is used continuous repetitive signal to oscilloscope input. Usually so that frequency is enough high so that after trigger is rearmed scope do not need next available trigger event so long time that it start reduce wfm/s speed.
Usually in specifications manufacturer tell maximum average speed what is available with some settings what give maximal speed.

Example in SDS1000X this hapend when horizontal speed is  50ns/div and display mode dots and single channel in use.
This max average speed is 60kwfm/s  if there is enough trigger events what depends input signal.

If turn display mode lines (what do not need often with fast signal when update speed is high) all know it reduce wfm/s speed.  Also other settings may affect.
Every t/div and memory setting also affect. And last, of course signal itself. 
If you look 1kHz square wave rising edge and setting is (example) this 50ns/div  do it have 60kwfm/s update rate. No, of course not. Then it is near but under 1kHz.

But if think there is signal what give this top average speed 60kwfm/s and think it triggers every 16.666us at regular intervals. No. It do not.  It do >70kwfm/s  stop >70kwfm/s stop >70kwfm/s etc.  If input is example 1MHz pulses and horizontal 50ns/div.  This acquisition run-stop interval is somewhere around 40ms in this case.
Burst speed inside this interval is around 71kwfm/s max.  (Some manufacturer may tell this value as max wfm/s)

What happend if signal frequency drop under this ~25Hz.  It do not at all run/stop, there is capture regular intervals.

But, there is more.

If look 100ms (10 pulse one second) period fast pulses (in this example case ~100ns width pulses)
Nothing special happend and continuously 10 times second see this pulse using 50ns/div.
Previously I told max burst speed is 71kwfm/s (with fast repeating continuous input) it means it can trigger after every 14.1us. (until it stop acq. for processing data and refresh wfms to display)

But this is not whole truth.
It can trig in normal use also faster.
Example:
t/div
Input double pulses. Pulses A and B.  |period|
A 50ns width
B 12ns width
d delay
One period: ___|AdB__________________|AdB_____    period in this case 100ms and delay (d) from A rise to B rise 5.6us.

It trigger first to A and immediately it can trig also B if distance is 5.6us or more.

If we now make decision that scope wfm/s speed is max 178.5 kwfm/s  ... if it is not exatly lie but it more like stretched the truth and a lie border!   So, if use these methods, think really carefully what you get... how 60kwfm/s  max average speed scope is now 180kwfm/s scope. (even if this peak can give small advantage in some very special rare situations)

Long time ago when I did something with glitches I did not understand why I find more fails detected what was expected. I repeat it many times because I think there was some mistake in my test.  But I did not think it then more because problem was solved other way.

But then I hit dejavu because in last days I think wfm/s update rate in scope what do not have trigger out.
 
And I made also some tests then with SDS1000X and I find unexpexted fast wfm/s update speeds using this double pulse method and also using rise/fall (alt) trigger method.
It was surprise it give result around 180kwfm/s maximum (peak) speeds.
After then I look what happend, connecting second scope to SDS1000X trigger output. And really, it can trig and capture agen after 5.6us  after previous trig (50ns/div setting).   Now I think that this perhaps also explain this earlier mystery in my previous fail/glitch counting when it find more than expected with 60kwfm/s speed. 

[nctnico]

What you are looking for is the guaranteed minimum trigger re-arm time (aka blind time). This is the driver number behind being able to do fast sequential acquisitions. Waveforms/s also includes the time taken for the acquisition itself and therefore doesn't say much because it is a combination of acquisition time (known) and trigger re-arm time. Unless the trigger re-arm time is specified it can be anything and may change without notice between firmware versions. As usual: if it isn't specified then don't rely on it.

[rf-loop]

What you are looking for is the guaranteed minimum trigger re-arm time (aka blind time). This is the driver number behind being able to do fast sequential acquisitions. Waveforms/s also includes the time taken for the acquisition itself and therefore doesn't say much because it is a combination of acquisition time (known) and trigger re-arm time. Unless the trigger re-arm time is specified it can be anything and may change without notice between firmware versions. As usual: if it isn't specified then don't rely on it.

Of course, it is trivial. But this is not question at all. And in practice things are not so straighthforward.

Give me exact full definition about quaranteed minimum trigger re-arm time.  Give me also full and perfect definition about "blind time".  After you have done these whitepapers I ask again if things are so trivial.

Scope acquisition and trigger may have lot of things what affect in practice when we analyze variable not continuous repetitive signals and things may be very different if we look 10Hz repetitive narrow pulses or if we are looking all time variable (non repetitive) signals or repetitive signals with very different frequencies.  It depends also hardware architechture and of course FW.

Just previous message I try tell  it how there is different things and after then your bit wiseacre trivia like ideal square wave from student basic fundamentals book. After you get more real practice perhaps you find whole world is not only black and white or true and untrue.

[tautech]

About waveform update rate......

And I made also some tests then with SDS1000X and I find unexpexted fast wfm/s update speeds using this double pulse method and also using rise/fall (alt) trigger method.
It was surprise it give result around 180kwfm/s maximum (peak) speeds.

Have you tested your SDS2304 to see if a similar burst wfm/s update rate peak is used?
How fast is it?

[rf-loop]

About waveform update rate......

And I made also some tests then with SDS1000X and I find unexpexted fast wfm/s update speeds using this double pulse method and also using rise/fall (alt) trigger method.
It was surprise it give result around 180kwfm/s maximum (peak) speeds.

Have you tested your SDS2304 to see if a similar burst wfm/s update rate peak is used?
How fast is it?

Only quick look but I need more evidence that the data can be published. Careful examination is time-consuming. Time is a limited resource.

[rf-loop]

Siglent limited time Offer

Buy between 26.04. - 26.07.2016 from Siglent accepted seller/distributor and you get free Serial Decode option SDS1000X-DC.
(IIC, SPI, UART/RS232, CAN, LIN)

[rf-loop]

Sequence mode segment/s speed table is now quarateed max speed instead of average maximum. Guaranteed max speed is speed where every trig leads to segment acquisition.

Test with new FW version 1.1.2.6   (also called as P06):
 
Oscilloscope (SDS1202X-S) in Sequence mode.
Trig normal, rising edge. Sequence lengh maximum amount of segments with current t/div.
In Sequence mode, display settings dots or lines/vectors, persistence settings and Sin(x)/x on or off do not affect acquisition max speed inside one sequence.

Signal:
External pulse generator (SDG5000)  generate pulses in burst mode. 
Amount of pulses in one burst is exactly same as in oscilloscope amount of segments in Sequence.
Initial pulse interval faster so that scope can not trig and capture every pulse.
Burst is manually trigged out when oscilloscope is waiting signal.
Adjusted pulse interval until scope can reliable trig and capture every pulse (one pulse - one segment).
Repeated test so many times that it is sure result was not lottery win.
Repeating is important because when oscilloscope run, there may exist some small variations in trigger rearm time,
perhaps due to scope other running processes but also input signal is not perfect.
(perfect do not exist in nature, all what we have is total sum of all errors. Perfect exist only in school books and )

If final result is that it can capture guaranteed speed say example 24565 segment/s without any loose, result is then always rounded down to nearest step what is used in table. 100, 10 or 1 -   so in this case to 24500 for get "tolerance margin."(Steps used: 50us, 100us/div step 10 and 200us - 1ms/div step 1, all other t/div step is 100.)

Maximum average wfm/s is tested with enough high input signal frequency and measured average over around 1 second.

Note also wfm/s burst speeds and also this very unexpected low frequency "double pulse" test very fast trigger rearm. In some cases with natural signals in practice they may give some times small advantage for find some rare unwanted glitch etc. What ever but it is never bad thing to know and understand how test equipment work.

After every whole Sequence is captured, oscilloscope display whole one Sequence segments overlayed in display even if amount is 80000 segment in Sequence.  After then it is ready to next Sequence. Processing time between whole Sequences depends also what are display settings.
 
Sequence mode is highly improved and also some bugs fixed in FW version P06.
But as all know there is not free lounges. Mapping every single segment to display after whole sequence is ready, depending amount of segments and display settings may take now more time. (example:  if there is one channel 40000 segments and segment lenght is 700 points it need handle 28 000 000 lines even if there is not but every step from data point to next need check. So, if you want continuously run several sequences with lot of segments it is better to use display mode dots.  If you want lines when you are in stop state and looking individual segments you can use lines. (and zoom vertical, horizontal, do measurements, math etc.)

With this new improvement in Sequence mode it is more useful because now it can sure see if these is some anomalies in some segments, without need to go looking separate segments using History/segments viewer in stop mode.


Right side bottom table (segments/s, CH1+CH2 in use)
Sample speed in this part is wrong 1Gsa/s.   Right is of course 500MSa/s (for both channels)
In )left side) wfm/s Ch1 + Ch2 it is right.



Right side bottom table (segments/s, CH1+CH2 in use)
Sample speed in this part is wrong 1Gsa/s.   Right is of course 500MSa/s (for both channels)
In )left side) wfm/s Ch1 + Ch2 it is right.

[Deuze]

Is it able to decode the data into ASCII? Thanks!

[rf-loop]

ASCII is just added to latest FW.

I have not now time for more testings but this tiny test copy is here with some remarks.

Something about serial decoding, with new P06 FW.

Here simple (UART) RS232 9600baud 8N1 and 259 bytes long message in all images.

One important rule. Trigger position need be in memory range if you want byte count in table is from trigger. If trigger is left from main window left border it decode but byte count in table start from left border. If use window zoom, then main decoding window is bottom zoomed window.
(If use window zoom, always byte count start from zoom window left border)

Memory for Decode function is 1.4M (with some t/div 1.8M)  when single channel in use. If use two channel, example for RX and TX then half.

Now there is available hex, decimal, binary and also added ASCII.

If have long dense string in window it can not of course show decode result in bottom decode display. If all ok it show blue bar. If there is errors then these are marked with red.  You can use window zoom and move this window to position in string what you want look.
If you do not want window zoom you still can look what are there by scrolling decode table. In this case table byte count start from trigger if trigger is in memory area. (Whole memory lenght is in main window). Same as also time position in decode table. (I hope they add small indicator on waveform display where is my selection in table. So that if I have selected byte 173 there is indicator where it is horizontally in waveform, just example small dial arrow or something like it. Example just top on the screen where is also trigger position symbol but different shape and color))

If use window zoom, table time is from trigger position BUT table byte number is from bottom zoom window left border. (I hope they add in some later FW update one column more where is also counting from trigger position.)

If you want you can stop and zoom in or out in main window using t/div  for details and go to horizontal position what you are interest or  also in stop mode you can turn window zoom on for more details.

If scope is stopped without decoding. If you now turn decode on it can not decode. But if it is already decoded in run mode you can in stop mode zoom and go to details where ever interesting detail is in decoded acquisition.





Decode result in binary. With universal know you can select what bytes you want see. Table lenght is max 7 row. Left side you see what are byte numbers in this decoded string. Count starts here from trigger.
 
Note: Timebase here is 50ms/div. Default is that scope use "Scroll" mode with this speed.
Decode is NOT available in Scroll mode. You need select normal acquisition with  trigger settings what need/want use.



Decode result in decimal. (with 8 data bits 0-255)


Decode result in hex. (with 8 data bits 00-FF)


Decode result in ASCII


You can also zoom but now byte numbers are counted from zoom window left border. Byte time in table is still counted from trigger. I wish they improve this in next some FW update.

[nctnico]

One important rule. Trigger position need be in memory range if you want byte count in table is from trigger. If trigger is left from main window left border it decode but byte count in table start from left border.

How useless... basically it still decodes only what is on screen and you have no idea where you are exactly inside a packet. There are far better decoding solutions on other scopes. Some even have the ability to decode UART data as a packets based on a packet termination character so you can see a message exchange between two devices.

[rf-loop]

One important rule. Trigger position need be in memory range if you want byte count in table is from trigger. If trigger is left from main window left border it decode but byte count in table start from left border.

How useless... basically it still decodes only what is on screen and you have no idea where you are exactly inside a packet. There are far better decoding solutions on other scopes. Some even have the ability to decode UART data as a packets based on a packet termination character so you can see a message exchange between two devices.

Yes decode option need some improvements as I have told.

Decode what is on the display.  Of course it decode only what is captured! 
In siglent, always(!) all what is captured is on the screen. You did not still know it.
It is not different in decode mode or just normal watching mode. Even if normal watching mode is example 70M long one acquisition it is all in image, there is not overlapp. WICIWYS principle.

Example there is one image where is around 275ms long capture. This is also decoded. But, it is so dense bottom blue decode area can not see any details. (exept that there is not errors)
Now if you want look details, just zoom. Zoom how deep you want. All is still decoded and you see details in zoom window. Also you can see whole decode list just scrolling list, if zoomed or not.

But, developing continue.

[nctnico]

One important rule. Trigger position need be in memory range if you want byte count in table is from trigger. If trigger is left from main window left border it decode but byte count in table start from left border.

How useless... basically it still decodes only what is on screen and you have no idea where you are exactly inside a packet. There are far better decoding solutions on other scopes. Some even have the ability to decode UART data as a packets based on a packet termination character so you can see a message exchange between two devices.

Yes decode option need some improvements as I have told.

It needs lots of improvement! Just look at the last picture you posted. It has a long acquisition but it is zoomed in on a short piece. Now the decoding starts at the beginning of the short piece. That is wrong in so many ways! Can't Siglent look at how Keysight or GW Instek are implementing decoding? Why does Siglent insist in doing it the wrong way for so many years already? Siglent really should stop trying to reinvent the wheel because their version is square. First get the basics right and then add features if you want to be innovative.

[tautech]

It needs lots of improvement! Just look at the last picture you posted.

Let's do that



 

It has a long acquisition but it is zoomed in on a short piece. Now the decoding starts at the beginning of the short piece.

Yes, that's the waveform of interest, that's why it's zoomed in on

Decode what is on the display.  Of course it decode only what is captured! 
In siglent, always(!) all what is captured is on the screen.
It is not different in decode mode or just normal watching mode.

Now if you want look details, just zoom. Zoom how deep you want. All is still decoded and you see details in zoom window. Also you can see whole decode list just scrolling list, if zoomed or not.

That is wrong in so many ways!

How? Why?
If the info you seek can be identified using the UI, what's wrong with the decoding?

Whats a preferred method of extracting the same information?

No I'm not trying to wind you up, I'd really like to know your considered reply.

[nctnico]

In many cases you are interested in looking whether a part of a message is correct. Say the message is 50 bytes long and the problem or value you want to inspect is in byte 40. When zooming in you'll miss the beginning and with Siglent's way of decoding you can either see the whole message with unreadable decoding or start somewhere in the middle without knowing where you are.

[rf-loop]

In many cases you are interested in looking whether a part of a message is correct. Say the message is 50 bytes long and the problem or value you want to inspect is in byte 40. When zooming in you'll miss the beginning and with Siglent's way of decoding you can either see the whole message with unreadable decoding or start somewhere in the middle without knowing where you are.

Why not just then scroll decode list to byte 40. Decode list then tell also time mark for byte 40.

[nctnico]

My Agilent/Keysight scope jumps to the right byte when it is selected in the list (you can enable/disable this behaviour).