Siglent's new product- MSO/SDS2000 Series

[nctnico]

@marmad: if roll mode has blind time then it is not roll mode. It's simple as that.

Blind time means any time when a DSO is processing /displaying samples and not acquiring

Roll mode is acquiring AND displaying at the same time. There is no blind time by definition; is that so hard to imagine? Did you ever use a scope with roll mode? Very handy and I'm really missing that feature on my current oscilloscope.

Look at page 123: http://cp.literature.agilent.com/litweb/pdf/54610-97009.pdf

[tautech]

@marmad: if roll mode has blind time then it is not roll mode. It's simple as that.

Blind time means any time when a DSO is processing /displaying samples and not acquiring

Roll mode is acquiring AND displaying at the same time. There is no blind time by definition; is that so hard to imagine? Did you ever use a scope with roll mode? Very handy and I'm really missing that feature on my current oscilloscope.

Look at page 123: http://cp.literature.agilent.com/litweb/pdf/54610-97009.pdf

I suspect the architecture of a DSO might not let it perform in Roll mode the same way as it does in a CRT scope.
The time between samples that a DSO must process will exclude it from real time roll mode.

[marmad]

Roll mode is acquiring AND displaying at the same time. There is no blind time by definition; is that so hard to imagine?

You seem to be forgetting about processing time. Of course, if no processing (or almost none) is involved, the blind time will be virtually nil - because the DSO will be sampling so slow in roll mode anyway.

But do you remember your original claims?

"The beauty of roll mode with peak detect is that you get a scope with ZERO deadtime and infinite waveforms/second." *and* "Peak detect works at the maximum samplerate".

Did you ever use a scope with roll mode?

I use it all the time and have done for over 35 years.

Look at page 123: http://cp.literature.agilent.com/litweb/pdf/54610-97009.pdf

I'm not sure what it proves posting a document for a scope that doesn't do peak detect in roll mode (and the HP 54610 doesn't), nor even do peak detect at it's maximum sample rate (it only does peak detect up to 20MSa/s - 1/500 of it's max. rate). According to your original claims, DSOs will do peak detect at their maximum sample rate in roll mode with no blind (processing) time.

[rf-loop]

I'm not sure what it proves posting a document for a scope that doesn't do peak detect in roll mode (and the HP 54610 doesn't), nor even do peak detect at it's maximum sample rate (it only does peak detect up to 20MSa/s - 1/500 of it's max. rate).

No, psst....

HP 54610 maximum sample rate is 20MSa/s  what is its ADC native speed.
It is designed for repetitive waveforms.

[marmad]

HP 54610 maximum sample rate is 20MSa/s  what is its ADC native speed.
It is designed for repetitive waveforms.

I was just quoting the specs from the document he posted. Are you saying it's doing ETS? Because I didn't see that mentioned anywhere...

But in any case, peak detect is limited to sweep speeds of 50 µs/div and slower - and it doesn't do it while in roll mode.

[rf-loop]

HP 54610 maximum sample rate is 20MSa/s  what is its ADC native speed.
It is designed for repetitive waveforms.

I was just quoting the specs from the document he posted. Are you saying it's doing ETS? Because I didn't see that mentioned anywhere...

But in any case, peak detect is limited to sweep speeds of 50 µs/div and slower - and it doesn't do it while in roll mode.

Lsst sentence, yes afaik.


It is repetitive sampling scope for higher frequencies analyze. It is around 1-2MHz real time (single shot) scope.  I do not know exatly what is sampling timing principle (random time shift or random hopping or equal time step shifting or what ever there are) for collect enough data.
So it can not use for fast changing signals at all. But, it have its place. It is not "all can do" scope. It is designed for repetitive signals and there it is still quite good.

Analog front end BW is nominal 500MHz and when I have used (not exactly this individual model)
 

[nctnico]

More lexical nitpicking and de-railing the discussion I have worked on designing a DSO so I know a thing or two on how to implement DSO features. I'm only curious if the people at Siglent are as smart as I am and implement peak-detect also in roll mode.

[rf-loop]

More lexical nitpicking and de-railing the discussion I have worked on designing a DSO so I know a thing or two on how to implement DSO features. I'm only curious if the people at Siglent are as smart as I am and implement peak-detect also in roll mode.

As I told previously, before this marmad case, I miss this function to SDS2000 and I hope they add it to some later FW but this is not, at this time, in most high priority in queye.

And what I told about this "blindness" is totally different and not at all same as this blind time what is normal if we talk about sequently captured waveforms. There (in normal sequential capture) is of course real blind time as all understand. Roll mode do not have this kind of blind time at all. But I do not know how Rigol roll mode works so perhaps there is.

For marmad: Roll mode what I know is like roll paper pen recorder.  No processing time for change sheet or retract pen to make it blind.

[marmad]

More lexical nitpicking and de-railing the discussion I have worked on designing a DSO so I know a thing or two on how to implement DSO features. I'm only curious if the people at Siglent are as smart as I am and implement peak-detect also in roll mode.

You want to blame me for de-railing the discussion when my original comment was just a response to a claim you made that had nothing to do with the Siglent (about how roll mode with peak detect is "infinite wfrm/s"), fine. From my point of view, you seem to make exaggerated and unsubstantiated claims often, and either never admit you were exaggerating/theorizing - or else blame someone for "nitpicking".

And what I told about this "blindness" is totally different and not at all same as this blind time what is normal if we talk about sequently captured waveforms. There (in normal sequential capture) is of course real blind time as all understand. Roll mode do not have this kind of blind time at all. But I do not know how Rigol roll mode works so perhaps there is.

For marmad: Roll mode what I know is like roll paper pen recorder.  No processing time for change sheet or retract pen to make it blind.

I understand well how roll mode works - but what you describe here is an analog device. Digital devices, by their very nature, *always* have processing time - although, as I've already mentioned, I would agree that normal roll mode on a DSO has inconsequential processing time. Nctnico's claim was that (all/some?) DSOs do peak detect mode in roll mode by sampling at their maximum rate, then reducing those samples to the peak detect info. This - most certainly - is processing and requires time.

So for example, with a 2GS/s DSO @ 100ms/div @ 40 pixels per div (i.e. 2.5ms per pixel) - that means the DSO is reducing 5 million individual samples (per display column) to peak detect information before displaying it. I'm skeptical about this claim - but would be willing to admit that I'm wrong - if he posted any substantiating documents about DSOs that are doing this.

As far as the Rigol DS2000 series goes, it DOES do peak detect in roll mode, but there is nothing to indicate that it's sampling at it's maximum rate while doing it. In fact, it displays a lowered sampling rate; so for example, 10MSa/s @ 200ms/div (50 pixels per div)- and that would lead me to believe that it (at this time base) is reducing 40 thousand individual samples to peak detect information per display column. Again, I could certainly be wrong - but there is no documentation (that I've found) which clarifies it either way.

Anyway, I won't waste more time on this issue - and just agree that it's something I hope Siglent implements in the future.

[rf-loop]

...then reducing those samples to the peak detect info. This - most certainly - is processing and requires time.

It can call as delay, not blind time. Blind time there is no data. In delay, data is collected and processing take delay. But during delay it do not loose collected data. (collected data is min max values). I feel you now mix delay and blind. Do we need go to basic fundamentals and principles. If you want talk about details how some peak detect and or roll modes or these combination works perhaps it is better to open topic for it example in beginners area.

Of course it was analog what I tell to you for imagine what is roll mode and imagine that there is not at all this kind of blind time what appears in sequential waveforms capturing. There is blind time. There is time when oscilloscope do not collect data at all so that we can (after short delay) know what happen in signal under test.  If there is 100ns visible data (waveform this part what is visible) and then 99800ns time where is "nothing" what can see, this 99800 is blind time.)
Totally different "blindness" principle I have told previously (example was this 10ms time interval)

If need continue this, I hope someone who want it or need it for learning, open new topic for it.
But perhaps it is also good to study basics fundamentals  before start it.

[nctnico]

I understand well how roll mode works - but what you describe here is an analog device. Digital devices, by their very nature, *always* have processing time - although, as I've already mentioned, I would agree that normal roll mode on a DSO has inconsequential processing time. Nctnico's claim was that (all/some?) DSOs do peak detect mode in roll mode by sampling at their maximum rate, then reducing those samples to the peak detect info. This - most certainly - is processing and requires time.

That is peanuts in hardware. Peak detect is nothing more than keeping the minimum and maximum values from the ADCs. It doesn't even require storing the samples and processing them later. Even with an FPGA this is very doable at 2Gs/s.  For example: My old Tektronix TDS744A which is designed in the late 1980's does all the displaying in hardware. With peak detect enabled the ADCs run at full speed (2Gs/s) even if the scope is set to 1s/div. See http://www.google.com.ar/patents/EP1048954A2?cl=en Please do more Googling and less attacking.

[marmad]

That is peanuts in hardware. Peak detect is nothing more than keeping the minimum and maximum values from the ADCs. It doesn't even require storing the samples and processing them later. Even with an FPGA this is very doable at 2Gs/s.  For example: My old Tektronix TDS744A which is designed in the late 1980's does all the displaying in hardware. With peak detect enabled the ADCs run at full speed (2Gs/s) even if the scope is set to 1s/div. See http://www.google.com.ar/patents/EP1048954A2?cl=en Please do more Googling and less attacking.

I actually did a fair bit of Googling - specifically about the things you wrote. And I couldn't find any definitive documentation of a DSO using peak detect in roll mode at maximum sample rates - and certainly nothing supporting the idea that roll mode + peak detect = no blind time + infinite wfrm/s. In any case, I will cease discussion of this topic now.

[rf-loop]

Peak detect is nothing more than keeping the minimum and maximum values from the ADCs. It doesn't even require storing the samples and processing them later. Even with an FPGA this is very doable at 2Gs/s.

Exactly.

For marmad.

I just tested also this with my old digitals what have peak mode and roll. also with entry level today oscilloscope what have peak detect and roll mode. Also peak detect with Siglent SDS2304 (using normal mode because today it do not have peak detect function if it is in roll mode)

Example, Owon SDS7102.  1GSa/s (and dual channel 500MSa/s) (it have single chip dual ADC what have two 500MSa/s ADC what can merge together with chip internal function where same clock is inverted internally (180 degree).

Tested:
Roll mode, peak detect, 5sec/div. sampling speed selected for 10s/s if 1k sampling buffer is selected. Used this setting.

Pulse. 3ns (! note Owon analog risetime and it is 100MHz model) Pulse period ~1s
It do not loose any pulse. There is peaks  level "aliasing".  I do not know what mode this ADC chip run. But it looks like it use ADC in its native speed. This inaccuracy is because  I do not know exactly this signal real shape in ADC input. (but I know what same scope show on the display if use it 2ns/div but it need remember there is sin(x)/x)
So thinking this by using amount of level alising and what signal looks if use scope full speed  and also trick to show real sample points in stop mode) it can think it use least 500MSa/s for this peak mode. (1ns or 2ns interval.) (signal level on the display is around 7 div. Aliasing p-p is around 1.5div and this p-p value do not change if scope is 2 channel or 1 channel mode so it "nearly) proof that it use its ADC with 500MSa/s speed.

I have watched many times as long as my eyes last... I can not find any missing pulse. I can not see even any pulse what peak drops below half of max displayed peak.

Same test with Siglent SDS2034 using 50ms/div (not roll mode) and 7k buffer for as low as 10ksa/s. Peak mode.
As far as I know it do not have missed any single 3ns pulse. Level aliasing is less due to faster ADC and faster analog front end rise and fall times. (pulse itself have around 1ns risetime (in HP specification 1.3ns)
If ADC run much less than full native speed result is totally different.

This test but least it proof what is minimum samplerate for peak detect in these cases due to known pulse width, level and due to fact scope do not loose pulses.

If I can produce reliable pulses down 1ns width pulses with known adjustable  periods result can proof more about real samplerate what is going to min max peak detect.

[rf-loop]

I will cease discussion of this topic now.

Good because it looks that you did not know what you start commenting and after then you need argument after argument for hide this and now your argument book is empty.

If Rigol have blind time in roll mode then I can understand this feel. If it do not have, then I do not understand at all reasons for these comments.

[marmad]

Good because it looks that you did not know what you start commenting and after then you need argument after argument for hide this and now your

argument book is empty.

If Rigol have blind time in roll mode then I can understand this feel. If it do not have, then I do not understand at all reasons for these comments.

Argument book?   Is that a Finnish thing? I guess you want me to respond... otherwise why this post?

So - in the hope of your understanding:

My original comment was in response to 'infinite wfrm/s'. That didn't make logical or mathematical sense to me. After 'infinite' was downgraded to 'maximum samplerate', I questioned whether all DSOs actually use their maximum sample rate for peak detect while in roll mode - using the term 'blind time' in this context (incorrectly, I admit) to mean any samples not acquired - i.e. anything less than the maximum sample rate in roll - which seems to have caused much confusion. As I already mentioned, I haven't seen or read any documentation confirming this roll mode/peak detect behavior - but I'm happy to hear your tests seem to prove that it's true. If so, I heartily apologize to nctnico for my dubious and doubtful nature.

[tautech]

Riveting stuff. 

Thank you rf-loop for taking the time to accurately test and post your findings.

Is your SDS2304 the same unit you got last year?
How long have you had FW 1.1.1.26.5 ?

[rf-loop]

Is your SDS2304 the same unit you got last year?
How long have you had FW 1.1.1.26.5 ?

Yes it is. I get this "V100R01B01D01P2605"   22. May  from Siglent (after I ask)  and later I get some time for run it.
There was extremely bysy times after start of this year and total lack of time to do  tests with this Siglent. (Situation still continue but sometimes now I have some more time also for tests etc)  But, also need to do works  queye is long...

[rf-loop]

It was need to check RS232 messages (and signal quality due to some problems) coming from one Trimble Thunderbolt (GPS-OCXO).

Note: Of course SDS2000 do not decode from this memory where is TFT "image" because of course there is not enough resolution for decode.  But area where decode works is same as TFT area. (SDS2000 waveform lenght is same as display width, in normal scope and also of course if decoding) So, if signal is just so dense on the display that can not detect details with eye it of course decode it.

Picture 1 is so that also it can decode manually from screen and next is whole message (around 150 (lenght is not constant exactly) bytes (trafic is 9600baud, 1start, 1 stop, noparity, 8bit.)
It send continuously these messages and scope follow and decode continuously these messages. Message interval in this case is slow,..  after around 1-2 second one message.
Picture 2 show this whole message (with decoding)

Trig was set so that it trigs just only once for one whole message.

Picture was take in run mode. *)

*) And it also show one FW bug when I do this print image to USB stick.
After print image to USB, it freeze decoding. Signal run but decoding stop, until push horizontal position knob (independent if it was centered or not).

[Hydrawerk]

So is it a hardware decoder (as on many Agilent scopes) or software decoder (as on Tektronix or Rigol scopes)?

[marmad]

Note: Of course SDS2000 do not decode from this memory where is TFT "image" because of course there is not enough resolution for decode.  But area where decode works is same as TFT area. (SDS2000 waveform lenght is same as display width, in normal scope and also of course if decoding) So, if signal is just so dense on the display that can not detect details with eye it of course decode it.

Thanks, rf-loop. Any idea if the decoder works on segments? With the SDS2000's extremely fast capture speed of segments, this could prove invaluable for debugging.

In comparison, the Rigol DS2000 series just started being able to do it with their latest v.3 firmware release - but I think the DS4000 still can't do it - and I'm not sure about the DS1000Z (although I think also not).

[echen1024]

Note: Of course SDS2000 do not decode from this memory where is TFT "image" because of course there is not enough resolution for decode.  But area where decode works is same as TFT area. (SDS2000 waveform lenght is same as display width, in normal scope and also of course if decoding) So, if signal is just so dense on the display that can not detect details with eye it of course decode it.

Thanks, rf-loop. Any idea if the decoder works on segments? With the SDS2000's extremely fast capture speed of segments, this could prove invaluable for debugging.

In comparison, the Rigol DS2000 series just started being able to do it with their latest v.3 firmware release - but I think the DS4000 still can't do it - and I'm not sure about the DS1000Z (although I think also not).

DS1000Z does not. 

[tautech]

I thought I might share some samples of Decoding I have done with the SDS2304 using 3 wire SPI decoding between a 4 kb Serial CMOS EEPROM (CAT93C66) and an 8-BIT MICRO (PD78P014).

Not that it matters, but they are in an old alarm control board that I had under the bench.

Note:
This was a "live" bus on which data was frequently changing. I could have set a trigger for a specific bit in a specific condition (0 or 1), but I chose to just get a stable trigger close to the middle of a stream of data.

Settings
BW full
No filters
All other info on screen.

Ch 1 Clock
Ch 2 DO
Ch 3 DI

Connection at SOIC8 EEPROM with Tek grabbers with short leads to 10:1 probes.

Run Stop.
Decoding captured in Roll mode with repetitive triggering.

Timebase changed to 20 ms/div from 5 ms/div
Decoding remains as captured.


Timebase changed from 20 ms/div to 100us/div
Decoding remains as captured although only a small portion of the original data stream is now visible.


Trigger point is the same for both images...obviously, but when the images are compared
they show the quanty of data captured.
Scope is responsive when Trigger and Decoding settings are correct and with minimal lag.(blink and it's there)

[Mark_O]

I thought I might share some samples of Decoding I have done with the SDS2304 using 3 wire SPI decoding between a 4 kb Serial CMOS EEPROM (CAT93C66) and an 8-BIT MICRO (PD78P014).

...

Ch 1 Clock
Ch 2 DO
Ch 3 DI

Thanks for posting these.  They're quite interesting.

Trigger point is the same for both images...obviously, but when the images are compared they show the quanty of data captured.

I'm having a bit of trouble correlating the two traces.  You say the trigger point is the same, yet the offset in the Packet Table differs?  Apparently the time offset is not relative to the trigger, but rather the Start of Screen?  So T1 would change, as one slides the bottom trace left & right? 

And which part of the top have we zoomed in on by 200x, in the bottom view?  There is no capture buffer overview, with zoom highlight, as there is on some other scopes.  So I can't tell where we're at in the buffer.

The top shows a 12B decode (96 bits), indicating the span is for the entire 140 ms covered in the reduced trace. 

Looks like we have a ~100kHz SPI clock.  Looking at the bottom view, if what it has decoded is just for the first 430 us clock burst, then I don't understand why the MOSI decode ends in a long string of zeroes, when the level is high during the Clock sampling?  Shouldn't they be FF's?  I.e., MOSI seems to be inverted.

Yet the decode trace on the bottom spans beyond the left and right-hand sides, indicating it is for the full 140 ms capture (as above).  But in that case, since there are more than 7 Clock bursts, shouldn't those be decoded as separate packets, with their own time-stamps?  Not all smushed together?  (Sorry to get all technical with the terminology.  )

Something just doesn't seem quite right?

[Mark_O]

From what little I know about that particular 4K microwire EEPROM, most packets should be between 19-29 bits, depending on addressing mode (Start, Opcode, Address).  So ~5-6 nibbles. 

That suggests that the 24 nibbles decoded in the trace are a jumble of many packets pushed together, with the timing relationships between packets stripped out?

[more]

I.e., from the top trace, it's evident that there is a 30ms gap between the first and second packet.  Yet I see no indication of that in the decode.  Then 10ms between the next four (with the 6th being a wider transaction, probably Cmd/Reply).  Then another 30ms gap to the final packet.

So I'd say the Decode looks broken, to me.

[tautech]

Thanks Mark for your analysis, seems like I have a bit of homework to do.
BTW throw in the terminology, it helps us all. 
If I have done it wrong and I may have    I take on your comments, let me get back to it and see if I can provide some answers.

I'm having a bit of trouble correlating the two traces.

The Decode result table unfortunately obscures the Trigger marker at top of screen.
This table can be turned on off, it is by default, as is the Decode display at foot of screen.
The options for control of these are controlled by the buttons below the screen and are in the top menu of the Decode menus. Correlation below:

And which part of the top have we zoomed in on by 200x, in the bottom view?

The "zoom" as you describe is only an increase in timebase of the Run/stop captured waveform image.
I only mentioned the "same trigger point" to further illustrate how the images where related.
If I had posted an additional "in between" instead of 200 x all may have been clearer. 

I will hunt out some more answers.