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

[H.O]

Hi,

When decode zoomed data in SPI mode, the bus status is shifted respect waveforms.

Isn't this the same issue that was on the DS4k a couple of firmware versions ago. Ie, the decoded data "drifted" in relation to the trace when "zooming" and panning thru the captured data?

To me it sounds like that is the problem and, at least on the DS4k, it was fixed one or two firmware revisions ago. If you're not running the latest version or have any specific reasons not to I'd probably try that.

[sotos]

What version are we talking about?

[H.O]

Hi,
Provided this IS indeed the same issue the problem went away when upgrading to 02.00.00.04 - but that was and is for the DS4k, I can't speak for the DS2k as I don't think they share the same firmware.

[marmad]

I'm triggering on external event with dedicated pin, I need to isolate especific data for debug.

As mentioned many times already in this thread, the External Trigger is basically worthless (and a separate analog path from the digital triggers) - and could introduce timing errors to decoding.

As Mark_O already posted - and as explicitly shown in the the DS2000 User Manual section on decoding (see attached image taken from manual) - protocol decoding should be teamed with the corresponding trigger.

[luchog]

Hello Mark_O.


Some more info:
- As i can see, decode is not related to trigger at all but wave forms, you can even decode in auto triggering mode in the midle of a string.
- The lines i draw are in the correct place,  confirmed with LA1034 LOGICPORT tool that is decoding as expected.
- I dont know how the scope knows the start bit, anyway it is doing it in not zoomed strings any kind of trigger.
- In SPI i trigger with CS signal, sometimes with GPIO, edge or SPI trigger with same result in zoomed string.
- In current string I can not trigger In RS232 mode because the scope suport up to 900Kb for trigger, the string is 2Mb.

I don`t know if any parameter is wrong, but ...  decoded data don´t match waveforms.


sotos, firmware version is 02.01.00.03.


marmad:
- Where in the manual you can find this? "protocol decoding should be teamed with the corresponding trigger".
- The image you refer is other topic, the case of not enough clocks.
- After heavy use of decode function, i can asure that it is not dependant of trigger mode.



Please see the new image, trigger SPI.

Thanks.

[Mark_O]

Hello Mark_O.

Hi, Luis.  Thanks for continuing to pursue this.  I hope you don't interpret my comments as argumentative.  I'm just trying to be helpful, and come to some understanding, along with you.  I don't have a DS2000 here, or I'd hook it into one of my SPI-bus projects, and look for myself.

Some more info:
- As i can see, decode is not related to trigger at all but wave forms, you can even decode in auto triggering mode in the midle of a string.

Yes, but can you do so properly?  It's always possible to say, "Start here and decode what you see", but getting the Start point correct is critical.  Otherwise, what you get out is garbage.

- The lines i draw are in the correct place,  confirmed with LA1034 LOGICPORT tool that is decoding as expected.

I'm sure they are correct, with the way you (and the LogicPort) are interpreting the stream.  Does the Logicport have only two SPI lines connected, as the DS2000 does?  Or does it also have a CE/CS (Enable/Select) line to help demarcate active segments?

One thing I noticed right away is that your last SPI snapshot actually has a gated CLK signal.  In all the rest, it has been (or appeared) continuous.  And with a continuous clock, no CE signal, and no gaps between data bytes (to trigger a resync), how would any device (or person) be able to tell where the byte boundaries were?  I've written software SPI decoders before, and I couldn't figure that one out.  So I wasn't surprised that the DS2000 couldn't either.

- I dont know how the scope knows the start bit, anyway it is doing it in not zoomed strings any kind of trigger.

Bingo!  I think that's the crux of the problem.  Sure you can ignore the trigger type.  And yes, the DS2000 will scrape the display memory and (try to) decode anything you throw at it.  But the Start bit is fundamental.  Look back at your RS232 capture.  It jumps in and interprets what it sees, but flags every byte as defective.  That's because you didn't use RS232 triggering, which would let it know it needed to detect Start and Stop bits, to demarcate a byte cell.  Without that context, Start and Stop bits are just more data.

- In SPI i trigger with CS signal, sometimes with GPIO, edge or SPI trigger with same result in zoomed string.

I'm not quite sure what you're saying here.  If you mean that you're using a Select line (CS) through the ExtTrigger input, marmad has already explained why that won't work.  It should!  I think we all agree it would be much better if it did.  Trying to decode SPI without it is problematic at best.  But it doesn't.

- In current string I can not trigger In RS232 mode because the scope suport up to 900Kb for trigger, the string is 2Mb.

Ah, OK.  So you've exceeded the documented capability of the scope.  I didn't think of that right away, because the fastest I've ever driven RS232 in any of my designs was about 1 Mbit/sec.

I don`t know if any parameter is wrong, but ...  decoded data don´t match waveforms.

I think the later implies the former.    Unless the scope is completely broken, which hasn't been reported here.  Maybe it's just because you're the only one who has dug into this.     I don't know.

marmad:
- Where in the manual you can find this? "protocol decoding should be teamed with the corresponding trigger".

I'll let marmad respond to this (if he likes), but it's been my opinion that enabling a decoder should also at least default to the corresponding trigger mode.  And then let you override that, where needed or appropriate.  But the DS2000 is not the only scope that gives you the flexibility to hang yourself in this way.  On the scopes I've seen, defaulting to the matching trigger mode is the exception, not the rule.  You're forced to redundantly set both, and I'd guess this is because they're independent options.  I.e., not linked, as they should be.

- After heavy use of decode function, i can asure that it is not dependant of trigger mode.  Please see the new image, trigger SPI.

I don't think we can reach that conclusion at this point.  For example, in your last screen shot with SPI triggering (thanks for trying that), we see a gated CLK-signal line, for the first time.  AND all the data bytes are decoded correctly!  Also for the first time.  However, there is a 1 division skew in the decoded green boxes that I don't understand (yet).  But I am curious about it.

[luchog]

Thanks Mark_O, you are very scientific  .

I found, decoding is ok, the problem is the data display is shifted respect waveforms, more far from trigger event more shifted.
I think it is an cumulative error calculating the position of data to show.
May be there are more cases when this shifting is happening.

Can someone verify this?

Thanks.

[Circlotron]

Okay, 200mS/div sweep, single shot, hi-res mode.
The resulting trace is pretty dull. After it is captured, if I move it even slightly to the right or left it becomes normal brightness.
The vertical sections of the blue trace are 1 pixel wide in both cases.
Not a really big deal, but maybe something Rigol should consider on their bug list.

Is anyone here actually going to send them a list of bugs?

[AndersAnd]

Is anyone here actually going to send them a list of bugs?

As you can read earlier in this topic, e.g. here, the OP marmard send all bugs to Rigol via Drieg (Petr Šmíd) who owns the official Rigol distributor Silicon Electronics in the Czech Republic.
Drieg is also a member of this forum: https://www.eevblog.com/forum/profile/?u=343

[Mark_O]

I found, decoding is ok, the problem is the data display is shifted respect waveforms, more far from trigger event more shifted.
I think it is an cumulative error calculating the position of data to show.

Thanks, Luis.  That's good to know.  Too often, someone will show up here and loudly proclaim that something on the Rigol is broken or malfunctioning.    But when they later find that it was really OK, they quietly disappear.  I'm glad you took the time to confirm that it does work, and to let us know about it.

As for the shifting, I suspect you are correct.  This isn't the first time someone has noticed a peculiar offset.  But after further testing, it seems to disappear, without any explanation.  This is the first time I've heard someone suggest a reason for why this may be happening, to varying degrees.  Distance between the trigger point and the display point may be the variable factor.  I don't have a DS2000 here to test with, but you anyone here with a DS2000 could explore the possible relationship by examining packets close to, and progressively farther from, the trigger point.

EDIT:  to emphasize that Luis isn't the only one who could explore this shift.

[luchog]

Hello Mark_O.

Thanks for replay.

I would like to give more feedback in this topic, but usually im just little busy .

Best regards to all.

[Salas]

Can this be a software thing or is it just the kinda washed out screen quality of the DS2000 series?

[Mark_O]

Can this be a software thing or is it just the kinda washed out screen quality of the DS2000 series?

I believe the video makes the DS2000 screen look worse than it does by eye.  I haven't heard any serious complaints about it, and there are certainly enough people who who have them that we would have heard about it, if it sucked.    So I wouldn't consider it a deal-breaker, by any stretch of the imagination.  It's good enough that there are far more important factors to base one's decision on.

I'm sure marmad will correct me if I'm FOS.   

[Circlotron]

The DS2000 will look somewhat different when looking down toward it rather than looking upward at the start of the vid. (didn't watch it all).

[Pinkus]

As I do own both and want to sell one set: would you suggest to keep the RP3300 or the newer RP3300A probes?
Both are rated 300/350Mhz by Rigol, however I assume the fixed one is a bit better due to lower capacity, but these as just assumtions....  Did anybody make measurements regarding frequency, rise time etc. ?

I know the A-type is fixed to 1:10, but I very seldom need 1:1 and I would have two other probes for this if needed.

Thanks for your help

[rowifi]

I have a new DS2202A - unadulterated, no licenses activated, updated with the latest offical Rigol firmware, days ago.
Was working ok until...
I was messing with the menu, actually looking for the FFT function and pressed a soft button to do with Math... ( It had options X Y Math with tick boxes) X was originally ticked but I was having problems clearing the menu ( It was saying something like 'must choose one') so I also ticked Math.
The Math box duly checked ok, but at some point moments later the scope locked up.

I've power cycled it 3 times now, I get one beep, a delay then two beeps a little later. The little dot is sitting on the 3rd from left square... and so it stays.

Am about to contact distributor / Rigol, but am now quite disappointed.

I've not yet read this thread to see if this is known about, just posted in haste and anger.

 

[marmad]

I was messing with the menu, actually looking for the FFT function and pressed a soft button to do with Math... ( It had options X Y Math with tick boxes) X was originally ticked but I was having problems clearing the menu ( It was saying something like 'must choose one') so I also ticked Math.
The Math box duly checked ok, but at some point moments later the scope locked up.

AFAIK, I don't have any menu or sub-menu on my DS2000 similar to what you're mentioning: in fact, I don't seem to have a single menu that even uses the word "Math" (see next post). The Math Menu (when you press the MATH button) is just a subset of features including FFT, Logic, simple A/B formulas, and advanced formulas using variables. So without better info, there is no way to try to replicate your problem.

That being said, if I was having the same problem as you, I would try reloading the firmware via the boot-loader (as mentioned at the bottom of this post).

[marmad]

I was messing with the menu, actually looking for the FFT function and pressed a soft button to do with Math... ( It had options X Y Math with tick boxes) X was originally ticked but I was having problems clearing the menu ( It was saying something like 'must choose one') so I also ticked Math.
The Math box duly checked ok, but at some point moments later the scope locked up.

AFAIK, I don't have any menu or sub-menu on my DS2000 similar to what you're mentioning: in fact, I don't seem to have a single menu that even uses the word "Math". The Math Menu (when you press the MATH button) is just a subset of features including FFT, Logic, simple A/B formulas, and advanced formulas using variables. So without better info, there is no way to try to replicate your problem.

Hmm... perhaps you meant in the Measure Menu? Although it doesn't use X / Y (I can't imagine any menu that would), there you can select between CH1 / CH2 / MATH.

[rowifi]

Hi
Yes - I think it was the Measure menu. Of course until I get the scope back up working I can't confirm - but I'm confident that you are correct.

Anyway - yes .. something I did when that menu was showing has locked it up.
I will try a re-boot - unless there's a 'hold down at power up' button that resets everything?

[marmad]

Anyway - yes .. something I did when that menu was showing has locked it up.
I will try a re-boot - unless there's a 'hold down at power up' button that resets everything?

Well, as mentioned in the linked post, you could try booting up with left-menu F6 pressed in, but it sounds to me like you need to re-install the FW. When I was testing the new FW (before using F6 on the first-boot), the same thing happened to me - the scope locked up and refused to boot until I re-installed the FW.

[rowifi]

Back in business - re-installed and F6 pressed ( repeatedly ) as per Rigol instructions.
Thanks

[Fagear]

I've done a small video with DS2072A working on my LED controller project.
RGB-? LEDtuner: ? ?? MIBAM

[Ivan7enych]

Hello,

I've bought the Rigol 2072A as a second oscilloscope to my old Tek TDS744A (4 chanels, 500MHz), and I've compared some features of both oscilloscopes.

1. I've linked together 2 oscilloscopes (Trig Out from 2072A to Tek external Trig input) (it can be useful to observe the same event on both screens), and connected inputs of both oscilloscopes to the signal gen output (Rigol DG4062, pure sine 50MHz). I've seen stable pure sine on 2072a, and jumping signal on Tek (see picture). When I link in opposite (Trig Out from Tek to external Trig input of 2072a), I've seen stable picture on both oscilloscopes.

It seems, that Trig Out of 2072a is not hardware, but a kind of software (from FPGA logic) and it is suitable for low frequencies only, not higher than 1MHz I think.

2. I've tested rise time on the same test signal (Tek probe signal, I don't know exactly it's rise time). Ground has been connected as close as possible to the tip of the probe (1-2cm length) to make signal as pure as possible.
1 - Tek 1GHz Active probe
2 - 2072a (unloked to 300MHz)
3 - 2072a with 100MHz band limit option

500MHz and 300MHz really makes the difference, but I like it, fine picture, almost no overshoot on rigol.

[Ivan7enych]

3. FFT math on the Rigol looks very disappointing to me, very slow user interface (slower than my old Tek), low resolution (only 2048 points from the record), no averaging options at all (both scalar and vector averaging). Tek TDS744 with it's old slow user interface in that terms is a much better choice.

4. protocol decoding and triggering (the main feature I missed in Tek) - triggering works fast, but decoding makes the oscilloscope very slow, may be 2 frames per second. UI of triggering is strange, for example I want to see RS232 data as ASCI chars, I see interesting place to me, and want to trigger on specific letter 'D' for example. For that purpose I need to find somewhere ASCI codes table and find the number of that letter.  Just because triggering UI works with numbers only, no letters, no HEX.

I've found picture with another example, I2C decoding shows hex values, triggering works with dec values only.

[Ivan7enych]

5. Intensity grading - very nice feature, but sometimes it works, sometimes doesn't and I don't know the all reasons of that.
Here is 50Mhz AM modulated sine, one picture is very nice, another shows moire artifacts. Changing number of recorded points sometimes turns on and off the intensity grading.
And a comparison pictures for the same signal from Tek, one with instavu option (old type of intensity grading), another with peak detect mode.

That's all from me for now. I hope it will be helpful for somebody to see good and bad points of that oscilloscope.