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

[neslekkim]

Similar behaviour on my ds2202a-s, did not let the scope warm up though, but ch1 moves a tiny bit.
Since I have 10x probes i set my scope to adjust for that, so I adjusted to 30v when testing. (Don't know how to turn on those labels at the bottom that shows the measurements yet though, but visually, the line moves)

I'm not worried though, far outside my usage-range I guess.

[Circlotron]

To check if there is an offset between the pointer and what the DSO perceives as ground, set the coupling to GND.

When I set the coupling to ground there is ZERO offset between the pointer and the trace, both channels, and turning one channel on and off has no effect on the other channel. If I wind the sensitivity right up and set to X1 then CH1 has no offset and CH2 has +250uV offset. Using averaging to get good trace. If I short the BNC connector with a small screwdriver the CH2 offset goes down to 150uV, not zero like with GND coupling.

[Circlotron]

What I will do next (not now, it's 1AM here ) is set the trace pointer to vertical midpoint on screen then put in a DC voltage of say +4 divisions worth and note the voltage the scope displays, then reverse polarity and see if it goes down exactly 4 divisions and what voltage is displayed.

[JDubU]

Not sure if anyone else has seen this yet - Each trace has a pointer at the edge of the screen identifying it as CH1 or CH2. With no signal in, CH2 trace lines up perfectly with CH2 pointer and so the offset reading of the trace (if any) corresponds with the trace position. For CH1 the pointer and the trace are offset by several pixels so the offset reading and the trace position are different. For example the pointer might be offset three divisions and the reading shows 3.00 volts offset but the trace is not directly over the graticule line. This is after the scope has calibrated itself after running about 6 hours. What's more, this offset of CH1 trace varies as you turn CH2 off and on.

On my DS2072, I found that the lineup between marker and zero input trace changed slightly with each self calibration.  I got the best result by performing a self calibration in an area as far away from potential sources of EMI as possible.

[Circlotron]

Having a further look at this offset business - at about 1 or 2 pixels below halfway up the screen there is a point where the pointer and the trace line up perfectly. The further you go up or down the screen the greater the offset between the pointer and the trace, positive offset up the screen and negative offset down the screen. What's more, if you have the peak voltage reading turned on, at 1V/div it shows 40mV at 1 div, 80 mV at 2 div etc. So the scope is actually reading some kind of voltage.

Another probably related thing, if you wind the trace off the top of the screen it gets to where it says "adjustment overrange" or some words to that effect, can't remember now. But if you wind the trace off bottom of the screen, at say -20v offset position the peak voltage reading shows about 15v when there is no actual input. Hmmm....

[Circlotron]

Had a super close look at the screen with my watchmaker's loupe.
The grid is 400 pixels top to bottom. (screen is 480 of course)
Thinnest trace when using large average number is 2 pixels wide. (not always, see next post)
The trace pointer can be moved in 1 pixel increments - 400 steps
The two pixel wide trace can only be moved in two pixel increments - 200 steps. (8 bit D/A?)

What happens is the pointer may be pointing to the lower line of the trace. Wind the pointer up one pixel and it points to the upper line of the trace (the trace does not move). Wind the pointer up one pixel further and the trace moves up two pixels so the pointer is now pointing to the lower line of the trace again.

At 1V per div one pixel is worth 20mV. The pointer can move in 20mV steps but the trace can only move in 40mV steps. There will always be some ambiguity with the measured voltage vs trace position if the trace is not an odd number of pixels wide, or if the trace pointer moves in different size steps to the trace.

[Circlotron]

Okay, so you can get a 1 pixel wide trace in some circumstances. See pic.
Notice though that the blue trace has a minimum resolution of 2 vertical pixels (1 LSB?) whereas the trace pointer can be moved 1 pixel at a time. Whether a 1 pixel wide trace can be moved 1 pixel at a time with the pointer though remains to be seen.

[Galaxyrise]

Okay, so you can get a 1 pixel wide trace in some circumstances. See pic.

High Res Acquisition, right?

[marmad]

Having a further look at this offset business - at about 1 or 2 pixels below halfway up the screen there is a point where the pointer and the trace line up perfectly. The further you go up or down the screen the greater the offset between the pointer and the trace, positive offset up the screen and negative offset down the screen. What's more, if you have the peak voltage reading turned on, at 1V/div it shows 40mV at 1 div, 80 mV at 2 div etc. So the scope is actually reading some kind of voltage.

This is normal and listed in the specifications:  "DC Offset Accuracy: ±0.1 div ± 2 mV ± 1% offset value"

I suggest you do some reading on DC offset in DSOs - and how it's specified.

[marmad]

The trace pointer can be moved in 1 pixel increments - 400 steps
The two pixel wide trace can only be moved in two pixel increments - 200 steps. (8 bit D/A?)

Discussed many many times in this thread: the DS2000 (and DS1000Z) map 200 ADC values to the 400 pixel high waveform display area.

[Circlotron]

Discussed many many times in this thread: the DS2000 (and DS1000Z) map 200 ADC values to the 400 pixel high waveform display area.

Okay, I'll try and find it. That's the trouble when threads get this long.

[marmad]

Okay, I'll try and find it. That's the trouble when threads get this long.

Sorry if I came across as short - I know it can be difficult to locate things we've talked about in such a lengthy thread. It's not a very efficient system for locating information.

BTW, here's a pretty good Tektronix link on DC gain and offset accuracy (and specification) in DSOs.

[Teneyes]

Can Anyone Confirm this RARE BUG??
The time base is INCORRECT with my DS2072 under these conditions
  1.  Timebase is set to 200ms/div
  2   Memory is set to 28Mpts or 56Mpts
  3.  Aliasing is ON

The Display Locks up , struck on T'D and no tracing

In these pics
  1.I am sweeping from 1-100Mhz ,with the 20MHz BW filter  & Alaising off, OK
  2.with same conditions &  Aliasing ON  ,
  3.with same conditions,56Mpts &  Aliasing ON  ,

The timebase is compressed from(14x200ms)2.8Sec into (9.6x200ms)=1.92S.for 28Mpts
The timebase is compressed from(14x200ms)2.8Sec into (12x200ms)=2.4S.for 56Mpts

A setting of 50, 100 or 500ms/div are OK

This Bug occurs on FW 00.01.00.05,  FW 01.01.00.02, & FW 02.01.00.03

[Rory]

Yes. I can confirm.

[gaijin]

Happens here also.
Only seems to happen with channel 2 enabled.

[gaijin]

yeah my mistake

[neslekkim]

Does it exists any youtube channel that teaches how to use the scope?, or any places with good usability writeups?

Say, I tried something simple, to see if there are any overshoot on my psu, I think I somewhat managed to make the trigger to work (voltage) but I couldn't get an detailed view of it.. And when I try to capture an wave, it seems like it captures like 5-7 frames?

[gaijin]

it doesn't seem to be limited to 200ms

28Mpts
I see it happening in:
200ms
1s
2s
10s
20s

while these don't seem to have the problem:
500ms
5s
50s

[Circlotron]

I have it too.
Move the centre reference to the right and the end of the trace doesn't move as far as the reference.
The trace actually stops scanning. I could see a glitch on the trace where I plugged the USB flash drive in and it never went away.

-> The problem does not seem to occur in hi-res mode, only normal and peak detect. <-

[luchog]

Hello:

When decode zoomed data in SPI mode, the bus status is shifted respect waveforms.
The sample picture was captured in 1mS scale and zoomend to 100.0nS.
DS2202, [FW v.02.01.00.03]

Can someone verify this?

Settings:
SCLK:
Channel: 2
Slope: Rissing.
Threshold 1.92V
SDA:
Channel: 1
Polarity: _|1|_
Threshold 1.9V

Timeout: 87.0nS
Data Bits: 8
Endian: MSB
Format : Hex


Thanks.

Luis Gomez B.

[luchog]

Hello Teneyes.

I'm triggering on external event with dedicated pin, I need to isolate especific data for debug.
Runtime Zoom wont work, It does not update bus status until stop, may be a bug, decode is just a buggy thing, and very usefull.
You can see in the image that it is showing data:0x07 when it is really 0x27...?? another bug??

[casinada]

Luchog,
Is it possible to improve the quality of the SPI signals? may be the ground line is too long and the Scope is having a hard time decoding properly.

[luchog]

Hello casinada.

Yes, you are right, the ground line is not good, anyway, in good signals i get the same problem.
Next week I´ll test more, and post results here.

Thanks.

[luchog]

Hello.

Here i uploaded two more samples, this time good waveforms.
- One sample SPI mode, 12Mbit. same settings as before.
- The other sample in RS232 mode, 2Mbit, 8bit, no parity, 1 stop, LSB.

[Mark_O]

Here i uploaded two more samples, this time good waveforms.
- One sample SPI mode, 12Mbit. same settings as before.
- The other sample in RS232 mode, 2Mbit, 8bit, no parity, 1 stop, LSB.

Yes, those are much cleaner.  I'm still confused about two things.

1) why do you think the scope should be able to properly decode a bitstream, when not  triggering on that protocol as well?  In both cases, you trigger on alternate sources.  Just because you draw lines on the screen where you think bytes should begin and end, how is the scope supposed to know that?  The Green boxes indicate, for better or worse, where the scope decided it should start & stop.  When those don't match your expectations, you can be pretty sure you've got one or more settings wrong.

2) on the RS232 decode, the second Green box indicates a Data value of 0, yet I see no way the bitstream could be interpreted in such a fashion.  Regardless of MSB/LSB settings, etc., that's not a zero.  So I'm curious how the scope made that determination.

One clue is that every byte is flagged with a red Error marker at the end.  Since there's no Parity defined, that means the Start/Stop bits are not lining up where the scope thinks they should be.  It's saying, "Here's what I'm decoding, based on the info I have, and it all looks wrong to me".

I understand you want/need to trigger on some other conditions, but is there some reason you're not willing to even try triggering on SPI and UART, to see what happens?