Rigol DS1000Z series (ds1054z, ds1074z, ds1104z and -s models) Bugs/Wish List

[Karel]

Karel, where do you see this bug?

On my computer after connecting the scope to an usb port.
I open a console and type "dmesg".

[Dwaine]

MrWolf, I could not duplicate any of the issues you reported here. I used a 100 MHz osc and split the signal via BNC T, with various coax lengths to each of 3 channel inputs - 4th channel On without input, and observed proper delay and phase measurements. The frequency counter worked fine for me too.

Karel, where do you see this bug?

Karel is seeing that problem under Linux computer.  The scope USB commutations is wrong.   Firmware problem.

[BEM]

It would be cool if there was an open source OS for this scope...but I guess it's too much a challenge for the hacker community to tackle. 

[MrWolf]

MrWolf, I could not duplicate any of the issues you reported here. I used a 100 MHz osc and split the signal via BNC T, with various coax lengths to each of 3 channel inputs - 4th channel On without input, and observed proper delay and phase measurements. The frequency counter worked fine for me too.

I updated test procedure description for counter problem in original post:
https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg1072742/#msg1072742
Counter test was done with 10x probes at 10x setting, not 50ohm coax! Did re-run the test with different probes. Some numbers changed a bit (updated) but general situation is same. When pushing sensitivity limits counters fails much earlier while trigger and wfm graph still work properly.

As for phase/delay stuff - I ordered some high quality cables, terminators etc. Will re-run 50ohm test when I get them.

[metrologist]

Thanks! I'm surprised your posts have gotten such little attention. I tried a number of configurations and could not get phase shift measurements to fail.

[MrWolf]

Thanks! I'm surprised your posts have gotten such little attention.

Well I guess not many people really max out this box or try to use it for RF purposes...
Anyway I did final test on the subject, using 10X probe + BNC adaptor. Probe was
correctly configured as 10X probe. Probe was only 60MHz (I do not have BNC adaptor
for Rigol probes), but this does not matter much because I did graph based on
Rx values, and signal was basic sine.

Conclusions:
- counter sensitivity drops about 6...9dB from 25MHz to 100MHz.
- 100, 200mV/div ranges have funny stuff going on switching 1GS/s => 500MS/s => 250MS/s
- 10mV/div range is fake from counter's viewpoint and is really 20mV/div range
- do not ever assume counter as working ok based on clean visual signal and trigger working correctly

Attached Excel file and PDF with report.

Edit: Tx/Rx are mVpp, not mV in report. Reports fixed.

[MrWolf]

It's bashing time again. Now I got 100% solid proof that this  box is doing its "measurements" basically off the screen (pixels!?), not the datapoints. But while I'm putting screenshots together - heres a little warmup. It's this error I found earlier:

- look attached image. Here is no 180' excuse for erroneous reading this time.

Error is too big even for "pixel math". Luckily it has cursor mode called "Auto", if you apply this mode to specific measurement item it will readily reveal what is going on - and it's insane. Screenshot attached.

[ruffy91]

Where is the problem? It takes the middle of your signals. How should it take the middle of a sine which is not complete? You only have 60 Points depth!

[metrologist]

Is it bad that those on-screen measurements are performed on screen data? What is the trade-off, no automatic on-screen measurements and manual on-screen measurement?

I am still just a bit perplexed as to the play you're getting on this issue. It took me a sec to realize what was going on in your pic and I think I need to look more to be convinced that is not just a fleeting, opportunistic grab. I could not get the measurement to give me erroneous results, but I am limited in my inputs.

What is the funny icon next to the speaker icon?

[MrWolf]

Ok, now down the proof that Haxx0magical "pixel math" takes place instead of measurements...

Test setup:
25MHz sine signal, 90' phase diff.
Cursor=Auto, Auto item=Quick4

DUT: Rigol DS1000Z

Test 1-1: 5ns timebase, 500MS/s sampling. 
"DS1104Z_25MHz_5ns_500MS__phase_error_.png"
Note that that it should be heavily averaging (over 128wfms), but both delay and phase are jumping around quite happily and wfm twitches by couple of pixels. Values are not that off... but it's just tip of the iceberg.

Test 1-2: 50ns timebase, 500MS/s sampling. 
"DS1104Z_25MHz_50ns_500MS__phase_error_.png"
Note that sampling rate is same, but more datapoints due to 10x bigger timebase. On normal scope this would yield much better precision. But on this thing we have total fail because it operates far beyond measure - in the fantasy land of colorful pixels  But hey, at least wfm is rock solid this time and almost fools you into thinking that averaging is actually applied to measurement and it might be correct...   

Test 1-3: 20us timebase, 500MS/s sampling
"DS1104Z_25MHz_20us_500MS__phase_error_.png"
Now in this case user should get to use full power of modern DSO with deep memory and zoom. But  something has gone horribly wrong  All the little pixels are molten into a yellow goo and powerful "phase shift" has taken place.

Very important: after that test I pressed [STOP] button and next test was just zooming in on saved signal.

Test 1-4:
"DS1104Z_25MHz_20us_500MS__phase_error__zoom_.png"
When zooming in on stopped signal "measurements" wonderfully transform and auto cursors jump around like kangaroos until at max zoom somewhat correct values are displayed. Now I felt true power of modern DSO 

[MrWolf]

Where is the problem? It takes the middle of your signals. How should it take the middle of a sine which is not complete? You only have 60 Points depth!

My signals are two perfect sines. Nowhere in manual it says it will take middle of the "stuff on the screen". What if signals are more complex and cut by screen window in funny places?
What if many users wont ever discover magic cursors and just rely on the measurement number?
It's the simple case if you do no know - do not show.
If you gonna do automagic - do it properly. It must first make sure it has full cycle on waveform, and only then show something.

[MrWolf]

What is the funny icon next to the speaker icon?

USB PictBridge.

[metrologist]

You could probably also figure out the discrete pixel steps and correlate measurement data that way.

What does it mean exactly when the screen says 30.0pts? Is that 30 data points to make up the entire waveform of both channels, 30 data points per waveform per channel?

[MrWolf]

To put things into perspective I did same stuff on heavily outgunned old soapbox called Pico 2205 MSO. Guess could have done it on any Tek, Agilent etc also and gotten pretty much the same. It is what you expect from properly programmed DSO:

Test setup:
25MHz sine signal, 90' phase diff.

Test 2-1: 50ns timebase, 100MS/s sampling
"2205MSO_25MHz_50ns_100MS_.png"
Take note that poor soapbox is totally outgunned (5x worse sampling rate, operating at max analog freq) but manges display value with same abs error. Avg value is rock solid as it should be with 128 count avg.

Test 2-2: 20us timebase, 100MS/s sampling.
"2205MSO_25MHz_20us_100MS_zoom_.png"
Nothing changes about measurements when I zoom in/out since it's all calculated from actual data. Zoom is just UI feature as it should be. This pic is 500x zoom, with honest datapoint display.
Measurement values are exactly same as they are on other timebases with same sampling rate. And another time: Measurements do not (should not, cannot) depend on timebase, do not depend on zoom. They only depend on sampling rate and datapoints (more points - better averaging).

Edit:
Test 2-3: 20us timebase, 100MS/s sampling.
"2205MSO_25MHz_20us_100MS_.png"
Forgot no-zoom pic from 20us timebase. All measurements same as any other 100MS/s case.

So what's the bottom line. Why bashing the  Z-box? Because it wastes human resources. Maybe "pixel math off the screen" seems normal to someone coming from CRO. It's not normal for someone buying his fifth scope after using properly programmed DSOs for years. You wont be expecting s*it like that. It will waste your time and ruin your day.
Also as former pro programmer (now exec) I can ensure you that problem is not hardware here, it's just GUI/core logic is made a** inside out. I know the programmer type that does this. I have personally fired about 5 like this and another 5 in outsourced company f*cked a project worth millions. Worst case is when Haxx0r-aces manage it to senior programmer stage by luck or coincidence, more collateral when you fire these.

[BravoV]

So what's the bottom line. Why bashing the  Z-box? Because it wastes human resources. Maybe "pixel math off the screen" seems normal to someone coming from CRO. It's not normal for someone buying his fifth scope after using properly programmed DSOs for years. You wont be expecting s*it like that. It will waste your time and ruin your day.

Also as former pro programmer (now exec) I can ensure you that problem is not hardware here, it's just GUI/core logic is made a** inside out. I know the programmer type that does this. I have personally fired about 5 like this and another 5 in outsourced company f*cked a project worth millions. Worst case is when Haxx0r-aces manage it to senior programmer stage by luck or coincidence, more collateral when you fire these.

Is there any chance you sell it ? Anyway, you've played with so many scopes before, its not like your "precious" 1st scope like teenage hobbyist which is stuck with the 1st scope for quite a while.

Feel sorry for you that this crap & cheap ass scope is ruining your day/time or even life.

As you're an "executive" level now, money wise, again, just don't believe this cheap ass < $500 scope is still bugging and annoying you for so long, its been months isn't it ?

C'mon, just sell it, or donate it maybe to one of your fav programmer or employees, or young hobbyist or etc.

Cause once you're free from it, just take a deep breath and it will be a huge relieve for you, trust me.

[MrWolf]

Well I did know it will be talk like that. From consumer level yes, bad wolf bashes "poor mans" scope, woooo... negative feeback, omg 
But I look to it from another perspective: programmers like this should not be in the industry - because they force proper ones to deal with s*it they leave behind... if the company did not collapse.
Also when some yuongsters learn their stuff on scope with software like this he will take it as a norm and produce similar afterwards. What if he gets to program avionics eventually? What if the self driving car that he did program kills whole bus-station?

Cause once you're free from it, just take a deep breath and it will be a huge relieve for you, trust me.

What I'm gonna bash then? Those hand picked programmers I work now with? Nooo... Gotta have some can of worms to poke in... 

[Karel]

programmers like this should not be in the industry - because they force proper ones to deal with s*it they leave behind... if the company did not collapse.

You should tell to that same industry that they should hire better programmers and, because of that, they should be willing to pay higher wages...
At the end of the story, it's always the problem of the boss that wants to have the "best" employee for the lowest wage.
I don't see this change soon, if ever.

[Fungus]

You should tell to that same industry that they should hire better programmers and, because of that, they should be willing to pay higher wages...

It's not just about the wages. The head programmer might be the Boss's nephew and won't let anybody else touch the code or something.

The Daily WTF has endless stories about ways 'good intentions' can go wrong or be thwarted by idiots.  I'm sure it's even worse in China.

[MrWolf]

You should tell to that same industry that they should hire better programmers and, because of that, they should be willing to pay higher wages...

Dunno how is it in China... But in my experience all the dudes had ok wages and really nothing to complain about. Kickass ski tours paid for gods sake... Problem is cultural. Somehow it sneaks in to their brain that only result matters, not how they do it... If in all use cases (they can think of) "black box" gives out right readings it's ok they think. What they do not think: what if I did not think of something and my fast formula that makes 2*2=4 by 2+2 is not gonna cut it? What if someone else has to do some changes to my spagetti code that only doped raccoon can understand? What if the system I work on has to still work after 10 years and will have 100x the load??? What if "bad boss" actually tries talk some sense to me for my own good?

I'll give you an example: High load database GUI had to display some data that had ~100 fields in it. In spec it said: fields may change at any time, internal I/O must be configurable and array-based. After going live system still had some minor bugs. Fixing each bug caused chain reaction of 10 new bugs. After doing expertise on the code it became evident that dudes had programmed I/O with functions that had ~100 hardcoded parameters... (specific hardcoded order, no config possibility!) Eventually system was scrapped despite looking very modern and professional...

So now there is possibility that I have to deal IoT stuff and actually dissecting some badly programmed product is very interesting - what are ways of Haxx0rs at the GUI-hardware interface...

EEVblog #818 - Embedded Electronics With Jack Ganssle 
https://youtu.be/1apCAzCTZdQ?t=12m25s

[BravoV]

Also when some yuongsters learn their stuff on scope with software like this he will take it as a norm and produce similar afterwards. What if he gets to program avionics eventually? What if the self driving car that he did program kills whole bus-station?

Its called certification and compliance to certain safety standard.

Your cheap ass scope don't need that, otherwise it will be so expensive that probably you can't afford it, hence no more whining.

What I'm gonna bash then? Those hand picked programmers I work now with? Nooo... Gotta have some can of worms to poke in... 

I knew it, its never about the scope, g'luck on the whining and venting out your frustration thru this scope , I'm out.

[Fungus]

What I'm gonna bash then? Those hand picked programmers I work now with? Nooo... Gotta have some can of worms to poke in... 

I knew it, its never about the scope, g'luck on the whining and venting out your frustration thru this scope , I'm out.

I saw it a few posts ago and kept quiet.

If he can't see that $400 is unbelievable value for so much 'scope, warts and all, then it's his own problem. It's like buying a Ford Fiesta then complaining it won't fit a piano in the back and go 200mph.

PS: All cars have annoying 'bugs', too. Not just niggles, even the expensive ones often have recalls for critical failures.

My friend's new Ford Fiesta is totally clueless at calculating remaining kilometers even after a firmware update that was supposed to fix it. This isn't something that somebody at Ford might have overlooked in testing, they just don't seem capable of writing that code.

[MrWolf]

Your cheap ass scope don't need that, otherwise it will be so expensive that probably you can't afford it, hence no more whining.

Looks we have a winner here - why do something properly when you are not forced by framework of expensive-to-implement ruleset? Ever heard of agile software development?

Picos 2205 is 2x cheaper at 200€, yet it works like professional tool.
If Tek would do 200€ scope it would also work the same, just have very low specs.
I'm suspect Digilents AD2 is also executed 5+.
It's a cultural thing...

[Fungus]

Picos 2205 is 2x cheaper at 200€, yet it works like professional tool.

Are you claiming that Pico software is bug free? 

[MrWolf]

Are you claiming that Pico software is bug free? 

There's massive difference between a bug and whole logic built using a** inside out methods. Latter is not fixable without scrap-it-someone-does-it-properly process.

[Fungus]

Are you claiming that Pico software is bug free? 

There's massive difference between a bug and whole logic built using a** inside out methods. Latter is not fixable without scrap-it-someone-does-it-properly process.

I'll take that as a "no"....