REVIEW - Rigol DS2072 - First Impressions of the DS2000 series from Rigol

[Teneyes]

Limits on Decoding RS232:
    After reading about errors using RS232 on the MSO4000 blog,  I did some testing,  Here is a test of decoding  a Data stream at 115.2Kb/s  using a display scan rate of 20ms/div, and 56 Mpts.

Displays:
  
EDIT:    This Bug is Fixed in Latest Firmware 00.03.00.01.03
1, Shows  setup for Decoding RS232

  2, Shows  that error occurs at scan rate of 20.2 ms/div  ,
     where a start bit is missed in the decoding,
     but because this is a repetitive data pattern the decode is the same
     but the Data would be corrupted o the 1st error.

  3, Shows  a display of  the Event table, no errors for this pattern

  4   Show the 2nd frame of a recording ,
      Important to note that it takes about 1 second to display the input trace ;
      and it takes about 6 seconds to display the Decoded data of the next frame
Can anyone explain why  this limit happens at this point  and with the missing a byte on decoding?

[Wim13]

Hi Teneyes,

give it a try..., 200 Mega samples per sec in 56 Mega points, gives memory full in about 250 milli sec
if you have 50 Mega samples per sec in 56 mega Points, gives memory full in about 1 second.

Then it will stop sampling i think , for a moment, to do other things like decoding or arrange things in the software
to show samples on screen, it has to do something with the gathered information. And does need the sampled memory for that.

I dont think it will continuous fills the memory non stop, and never stop, there will be some dead time...?
to do things i mentioned above. Maybe i am wrong, but i dont think the DSO is a real time non stop sampling device.

[Sparky]

Just FYI to the group: way back I posted I had the heat-sink clip fall out.  I just received my DS2072 back from Rigol following repair (RMA service).  The repair took 1 week (and an additional 1 week for shipping to/from Rigol).

The warranty seal was removed and not replaced.

The firmware was updated to latest 00.03.00.00.00 (it had 00.02 installed when I sent it in), which is just further confirmation that 00.03 is the latest firmware for DS2000(A) series (and is listed on Rigol's firmware request webpage).

[Teneyes]

I dont think it will continuous fills the memory non stop, and never stop, there will be some dead time...?
to do things i mentioned above. Maybe i am wrong, but i dont think the DSO is a real time non stop sampling device.

Hi Wim.
   Yes , Marmad has often explained about sample Aquistion and long Dead times.
I was wondering why after the data was collected correctly,(good waveform traces) why does the decoding miss a start edge and only start decoding on the next stop/start bit transition?
Is there some interrupt routine corrupting pointers into the data where the decode function is analyzing the data stream for displaying ??
when I play back large data traces in Zoom mode I can see the yellow traces appear on the display about 3 sec. before the green Decoded characters are displayed.
Thanks Wim.

[Teneyes]

Trigger Holdoff Is NOT on Ds2000 only on DS4000


So here's the need for  Holdoff.
It occurs with and number of pulses that stop and burst again.
below I show 8 pulse that  reoccur in bursts
 (short stop time between bursts)
Now I varied the repeat burst period.
at a burst Period of 7ms the trigger is Ok
at a burst Period of 8ms the trigger is Lost and bad jitter
at a burst Period of 9ms the trigger is Ok
1Gsa/s
500us/div
7Mpts

For 8 pulses the Error (trigger jitter) also occurs at burst periods of 12ms and 24ms
The period where the error occurs changes if the number of pulses change.

There is no jitter using burst envelope sync pulse on chan. 2 to trigger

Can anyone Confirm? 

EDIT  Pix #5  , with Trigger out on CH2,  trigger out is Correct.  WTF??

[seronday]

Teneyes,
Try adjusting the trigger Holdoff time to around 3 - 4 mS.
It looks like the trigger circuit has re-armed and is triggering on the next pulse that it sees.

[Wim13]

Teneyes,
Try adjusting the trigger Holdoff time to around 3 - 4 mS.
It looks like the trigger circuit has re-armed and is triggering on the next pulse that it sees.

i think the same, it triggers on the first on going pulse.

I did the same test, and indeed, it triggers on the fist pulse it finds, i think thats is correct
Played around with the delay, and that worked for me.., then it triggers oke

[Teneyes]

Teneyes,
Try adjusting the trigger Holdoff time to around 3 - 4 mS.
It looks like the trigger circuit has re-armed and is triggering on the next pulse that it sees.

i think the same, it triggers on the first on going pulse.

I did the same test, and indeed, it triggers on the fist pulse it finds, i think thats is correct
Played around with the delay, and that worked for me.., then it triggers oke

Good Point.
There is NO Trigger Holdoff on a RS232 Trigger, see Pics   

See Discuss on DS4000 Blog here

[Teneyes]

Can anyone Confirm that the DS2000 does NOT decode when recording frames?
see gif

[marmad]

Can anyone Confirm that the DS2000 does NOT decode when recording frames?

Hi Len,

It does not decode recorded frames. I thought this was reported and confirmed here awhile ago when first reported on one of the UltraVision models.

[Teneyes]

Hi Len,
It does not decode recorded frames. I thought this was reported and confirmed here awhile ago when first reported on one of the UltraVision models.

HI Mark
It is not on your Bug list (post 3) and at first  I was thinking it was important. but as I was testing maybe the best way to monitor a serial data stream is with a long buffer(using best Mem depth), , then analyze by using the zoom feature , where the decoding does work.  and to record frames , then zoom and scan the Data.  I guess the DSO is only a preliminary device for Serial Data debugging. I am not sure when data could be missed.

[Mark_O]

It does not decode recorded frames. I thought this was reported and confirmed here awhile ago when first reported on one of the UltraVision models.

Mark, did you miss this demonstration, where teneyes showed it working on a DS2000?  (Post capture, not real-time.)

[Teneyes]

A difference between the DS2000 and DS4000

This gives me  "RS232 Trigger Holdoff Envy" 

From the User's guide:
'The adjustable range of holdoff time is from 100 ns to 10 s. Note that trigger holdoff is not available for Nth edge trigger, video trigger, RS232 trigger, I2C trigger, SPI trigger and USB trigger.'

[marmad]

Mark, did you miss this demonstration, where teneyes showed it working on a DS2000?  (Post capture, not real-time.)

I'm currently travelling so I haven't been following the threads closely, but I've tried decoding on segments before (using I2C) and it didn't work.

[Teneyes]

It does not decode recorded frames. I thought this was reported and confirmed here awhile ago when first reported on one of the UltraVision models.

Mark, did you miss this demonstration, where teneyes showed it working on a DS2000?  (Post capture, not real-time.)

Hi Folks ,  I tried to re test the decoding of Frames in record mode referenced above
But I could Not      
Then  Breakfast

And guess what ,   I remembered  a change I had made

This Feature is only in latest FW 00.03.00.00   , I think Rigol is smirking at me 



Below are displays of Frames, recording 140 bytes burst every 3 seconds 

[marmad]

This Feature is only in latest FW 00.03.00.00   , I think Rigol is smirking at me 

Great to hear!!   I've been on the road since the latest FW release, so I haven't had a chance to test it at all.

[Teneyes]

Here I am checking  the recording & decoding of 2 Channels RS232
      230byte bursts at 10sec on Ch1,   Ch2 continuous
Note:  The decoding of a new frame in playback takes about 2 seconds at this setup     

[Teneyes]

Data Decoding Limit  ( RS232 test)

it appears that to Decode without  Errors, at least 28 Pts must be allocated for Each 'BIT' of data or else the Decode will miss a byte.

To test I used:
            2ms/div
            70Kpts/display
            89.2Kb.s   all OK   = 28.027 Pts/bit
            89.4Kb/s   Errors occuring
See Pics

[Teneyes]

EDIT:    Max=900k in Latest Firmware 00.03.00.01.03
A High Speed Test of  RS232 Data Recording & decoding
 I used:
          892Kb/s      (maximum trigger setting is 900000)
          140Kpts/display
          475 Byte Block
          396 us/div
          3.96 us/div  Zoom

          Recorded 508  Frames

  For a Total of  241300  Bytes recorded

[Mark_O]

Here I am checking  the recording & decoding of 2 Channels RS232
      230byte bursts at 10sec on Ch1,   Ch2 continuous
Note:  The decoding of a new frame in playback takes about 2 seconds at this setup   

I just wanted to say "thanks" for all the testing, and posting of your screen shots.  Very helpful.   

[Mark_O]

A High Speed Test of  RS232 Data Recording & decoding
 I used:
...
          475 Byte Block
...
          Recorded 508  Frames

  For a Total of  241300  Bytes recorded

Yes, and the key point being that the same results would have been obtained if those 508 frames had gaps of seconds or minutes or hours between them, regardless of the inter-frame latencies.  (Plus, you could turn on the ClockTag, and see the date/time stamp for each frame.)

That's the power of segmented captures.

[Mark_O]

Data Decoding Limit  ( RS232 test)

it appears that to Decode without  Errors, at least 28 Pts must be allocated for Each 'BIT' of data or else the Decode will miss a byte.

To test I used:
            2ms/div
            70Kpts/display
            89.2Kb.s   all OK   = 28.027 Pts/bit
            89.4Kb/s   Errors occuring
See Pics

I'm not so sure about that.   It's not decoding from those 28 samples (or less) per bit cell.  It's decoding from what's on the screen.  When you zoom in too far (or equivalently, increase your bit stream and thereby compress what's on-screen), then decodes will fail.

In your second test at 89.4Kb/s, if you had just zoomed out a bit from the 100us/div you were at, then it would have had more bits to work with, and started "working" again.  Even though the sample Pts/dataBit hadn't changed at all.

I think. 

So the real conclusion would be that with 10-bit RS232 bytes (at 1 Start, 8 Data, and 1 Stop each), the 700 points on-screen can support up to 12 bytes at once, but not 13.

[Teneyes]

In your second test at 89.4Kb/s, if you had just zoomed out a bit from the 100us/div you were at, then it would have had more bits to work with, and started "working" again.  Even though the sample Pts/dataBit hadn't changed at all.
I think. 

EDIT:    This Bug is Fixed in Latest Firmware 00.03.00.01.03
Note last displays shows  90KBytes/s= 900,000b/s

 Just to make it Clear to all; Zooming has no effect if there are Decoding errors. The decoding is done on the full un-Zoomed data.  Below I show 3 displays where the errors still exists. Note you can see the error gaps

In order to make full used of the 140KPts I fill the full display with DATA  (by increasing byte count in the frame/segments or reducing the time of the display (<timebase)   

Also Note that  if there are errors in non- Record mode there will be errors in the recorded frame ( same recorded points are used, Not the display data)

PS  I captured all 3 frames into eevblog from the DSO in 150 seconds , using RUU

[Teneyes]

..the key point being that the same results would have been obtained if those 508 frames had gaps of seconds or minutes or hours between them, regardless of the inter-frame latencies.  (Plus, you could turn on the ClockTag, and see the date/time stamp for each frame.)
That's the power of segmented captures.

I agree and here is an example ( thanks for pointing out TimeTag)
high speed data (1Mb/s), short bursts(100us) , with recording that could record for 5.5 Days

[Teneyes]

With more and more people stating and receiving the New FW 00.03.00.00, I thinking it would good to report new Bugs here.  Marmad has kept a good list on the 3rd post of this Blog.  Altough Marmad usually confirms all bugs himself , I think it would be helpful for a few others to confirm any reports.  Also if any Fixs to an existing bug is a complete fixed.

These are Bugs I have found:

     #03__01   The Clear Button does not work.
              EDIT:    Fixed in Firmware 00.03.00.01.03

     #03__02   The decode display does not clear when decode is turned off
              EDIT:    Fixed in Firmware 00.03.00.01.03

     #03__03   Once the lg(CH1) advance Math function is applied you can Edit the function;
                   If the Expression button is press the DSO hangs. and if in start Last System. the
                   attempt to change the expression , will hang the DSO!!!    
              EDIT:    Fixed in Firmware 00.03.00.01.03


     #03__04   The Set Counter Menu has display Error (unnecessary scrolling,small )  see Pics
                   This occurs when system 'System'-'Power On' - is set to 'Last' and the trigger is
                   NOT set to EDGE trigger.
                   Power cycle after PULSE trigger causes 3 items in Menu ,most others 2 items set in Menu
                   Auto Setup Button resets trigger to Edge  and all 4 Menu Items??? (CH1,Ch2,Ext,Off)
              EDIT:    Not Fixed in Firmware 00.03.00.01.03

If anyone ventures onto Fw 00.03.00.00, please help to confirm any of these.

Edit 1  Added more info on Bug #03__04