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

[rf-loop]

There are only 800 horizontal dots on the screen yet the data comes back as 1200 points.  I could see doubles if the dataset was twice the screen size but that doesn't appear to be the case.  Sooner or later it is going to come down to the resolution.

In this scope visible part of trace lenght is 600 points on the screen, not 800. 12 div 50 pts/div

[Karel]

Indeed, in the PC extracted points I couldn't reproduce any time shift between channels bug.

Since the first scope screen capture from the bug description shows a "T'D" in the upper left corner, I guess the data was extracted with the scope in the running mode. In running mode, only 1200 points can be saved to PC (the same as the ones from the display). So I saved first 1200 points from channel 1 and 2, then chart them in a spreadsheet. The points from the 2 channels are well aligned in time.

Use DSRemote to download the deep memory waveformdata (12 or 24 mpts) and you'll see clearly the bug.
At least, I can reproduce it here with sw version 00.04.04.SP1 and board version 0.1.1.
The bug is also confirmed by Rigol.

[Karel]

Unfortunately, the time-difference bug as described here:

https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg862373/#msg862373

and which was reported to and confirmed by Rigol on March 1th, has not been solved with the latest fw 00.04.04

So, downloaded deep waveform data is still defect...

I was looking at the data points within the screen, and I could not reproduce this bug with FW 00.04.04.01.01 (SP1)

Could somebody please help me with some details, in order to reproduce the bug?
- What scope settings must be used(other then the ones that can be seen in the pic)?
- How many data points were extracted?
- At what point(s) can be seen the time difference?
- The data points were retrieved in ASC or Byte mode?
- What SCPI commands were sent in order to retrieve the data points?

Code: [Select]

tmc_lan write: :STOP
tmc_lan write: :WAV:MODE RAW
tmc_lan write: :WAV:YINC?
tmc_lan write: :WAV:YREF?
tmc_lan write: :WAV:YOR?
tmc_lan write: :WAV:STAR 1
tmc_lan write: :WAV:STOP 250000
tmc_lan write: :WAV:DATA?
received 250000 bytes, total 250000 bytes
tmc_lan write: :WAV:STAR 250001
tmc_lan write: :WAV:STOP 500000
tmc_lan write: :WAV:DATA?
received 250000 bytes, total 500000 bytes
tmc_lan write: :WAV:STAR 500001
tmc_lan write: :WAV:STOP 750000
tmc_lan write: :WAV:DATA?
received 250000 bytes, total 750000 bytes
tmc_lan write: :WAV:STAR 750001
tmc_lan write: :WAV:STOP 1000000
tmc_lan write: :WAV:DATA?
received 250000 bytes, total 1000000 bytes
tmc_lan write: :WAV:STAR 1000001
tmc_lan write: :WAV:STOP 1200000
tmc_lan write: :WAV:DATA?
received 200000 bytes, total 1200000 bytes


[rstofer]

There are only 800 horizontal dots on the screen yet the data comes back as 1200 points.  I could see doubles if the dataset was twice the screen size but that doesn't appear to be the case.  Sooner or later it is going to come down to the resolution.

In this scope visible part of trace lenght is 600 points on the screen, not 800. 12 div 50 pts/div

That's the problem with datasheets.  The datasheet for the family of scopes clearly states 800x480
http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-0504/1/-/-/-/-/MSO1000Z_Datasheet.pdf
See page 8:

Display Resolution 800 horizontal × RGB × 480 vertical pixel

But if it is really 600, then 1200 points is exactly 600 pairs.

That this datasheet is applicable to the DS1054Z is shown on page 1

[ruffy91]

The resolution of the LCD is 800 horizontal, but the waveform doesn't span the whole width. There is the menu on the right side.

[bitseeker]

The resolution of the LCD is 800 horizontal, but the waveform doesn't span the whole width. There is the menu on the right side.

Exactly. Unlike the higher-end Rigol models, the onscreen menus can't be hidden, so you don't get the full screen width for trace data.

[rf-loop]

The resolution of the LCD is 800 horizontal, but the waveform doesn't span the whole width. There is the menu on the right side.

Exactly. Unlike the higher-end Rigol models, the onscreen menus can't be hidden, so you don't get the full screen width for trace data.

Also higher models do not give full screen width trace when menu is off.
Attached Rigol DS6000 menu off and menu on.
Display TFT resolution 800x480

Menu Off trace lenght is 700  ( 14 div) and menu On trace lenght looks like around 642 (bit under 13 div)
Example in Siglent (SDS1000X and 2000X) trace lenght is 700. (TFT800x480  and 14 div) (with menu, and it is always on)

This is normal in digital oscilloscopes, take R&S, Keysight, Siglent, LeCroy, Owon, Tektronix, GW or what ever. More or less under TFT horizontal resolution. With menu or without. Show me scope what give full TFT horizontal amount of pixels for trace
There is nothing wrong in this thing in DS1000Z. Just normal.
But, why 1200 data points looks like there is always 2 data points exactly same without exceptions. What "secret" is behind this.

But example if we go to Spectrum analyzers. Many times there data sheets told also trace lenght (data points).
Example Rigol DSA1000, full screen: displayed data points 751, normal 600   (TFT 800x480  8.5")
Example Siglent SSA3000X,  1024×600(waveform area 751×501), 10.1"
Example Keysight N9320B, Sweep point 461, fixed. (TFT 640x480  6.5")

Rigol DS6000

[bitseeker]

Exactly. Unlike the higher-end Rigol models, the onscreen menus can't be hidden, so you don't get the full screen width for trace data.

Also higher models do not give full screen width trace when menu is off.
Attached Rigol DS6000 menu off and menu on.
Display TFT resolution 800x480

Menu Off trace lenght is 700  ( 14 div) and menu On trace lenght looks like around 642 (bit under 13 div)
Example in Siglent (SDS1000X and 2000X) trace lenght is 700. (TFT800x480  and 14 div) (with menu, and it is always on)

Sorry, didn't mean literally "full screen" as in all 800 pixels, just more than with the menus showing.

[BEM]

Hi,

This is my first post.

I have a 1054z. The history graph is such a cool feature, that I wished the scope had before I discovered it, BUT I dearly wish it could go full-screen just like the FFT function can, with a grid.

[I am writing a sinusidal smooth stepper program, and I am going to use it to plot the actual step frequency/period over a course of steps. Also for speaker testing it would be useful, though it's currently small with limited resolution.]

Thanks for your consideration,
BEM

[BEM]

I found a change I would like to make: It's interesting that the user adds measurements on the left menu, and attempts to delete them on the right menu, but it should be changed.

What would be so wrong with selecting the same item you added again, to delete them?

[BEM]

Saddly, I just tried the 1054z history function. Apparently, it only works from the screen buffer. It appears useless for my application. 

That's all I wanted to do is get a period graph over time of sampled pulses and waits, for a stepper driver, but it can't do it 

[JPortici]

I found a change I would like to make: It's interesting that the user adds measurements on the left menu, and attempts to delete them on the right menu, but it should be changed.

What would be so wrong with selecting the same item you added again, to delete them?

if in the meantime you change the channel and you press onthe measurement button you won't delete the one you want but rather add a new one.
the real bug/feature miss is that they are still. not. deleted. at. all. only "hidden"

[garnix]

if in the meantime you change the channel and you press onthe measurement button you won't delete the one you want but rather add a new one.
the real bug/feature miss is that they are still. not. deleted. at. all. only "hidden"

Sure, but then you just tap it again and it would be gone - then switch channel and tap on the correct one... much much easier than always change to Measure tab on the right side and hang through the menus... They could even indicate on the left-side buttons if measurement is active e.g. by displaying the button in a highlighted state - or even better: display the actual value inside the button.

And agree, this "hidding" feature is crazy.

But what I use most: Long-Press the Measure button - then all measurements are gone. Then add new ones from the left.

[TheoB]

I reported a bug for the DS1054z at Rigol. At least I think it is a bug. The math-filter functions seems to not work at the entered frequencies (lowpass/highpass/bandpass/notch). As an example I want to filter 1kHz and set the lower limit to 750Hz and the higher limit to 1250Hz. I then get a bandpass filter around 500Hz . Same with low pass. If I specify 20kHz then I find the low pass edge (-3dB) roughly around 8.9kHz.
I don't run the latest version of the firmware (00.04.03.SP2) but I have also not found anyone reporting this. So I prefer not to update (yet).
To repeat (with a 1kHz sine at the input):

Code: [Select]

$ cat filter_bandpass.scpi
:TIMebase:MAIN:SCALe 0.002
:MATH:OPERATOR FILTER
:MATH:FILTer:TYPE BPASS
:MATH:FILTer:W1 750
:MATH:FILTer:W2 1250
:MATH:DISPlay ON
cat filter_bandpass.scpi > /dev/usbtmc


[MrWolf]

Some stuff I discovered about my new measurement instrument from Rigol:

Feature:

If you have both LAN and USB cable connected and set USB Device to "PictBridge" you do not have to disconnect USB to use LAN.

Bug:

Frequency Counter

Attached page from manual: "DS1000Z_UserGuide_EN__page_145.pdf"

Quote: "The hardware frequency counter supplied with this oscilloscope can make
more precise measurement of the input signal frequency."

Bug: It was enabled on CH1, CH2 was active (500MS/s). Turned on CH3, CH4. Sample rate dropped to 250MS/s. Counter failed to display correct freq. Some investigation showed thresold at >=30MHz. But later I failed to reproduce this. Instead reproduced similar problem, look "DS1104Z_100MHz_5ns_250MS.png". Counter was enabled on CH2, CH1 was active (500MS/s). Turned on CH3, CH4. Sample rate dropped to 250MS/s. Counter failed to display correct freq.

Software counter managed to do a better job overall but still fails, despite average mode being enabled and waveform being steady.

"DS1104Z_100MHz_5ns_500MS.png" shows exact same situation at 500MS/s. All counters work ok.

Conclusion: Counter(s) should considered non-functional when scope is in 250MS/s mode.

Edit: On some days it's in the mood and works. Currently cannot find a pattern.
Found the pattern: It is function(vertical scale, signal level, signal frequency, sampling rate)

Tests conducted using 10x probe connected directly to Siglent SDG2000X gen output
via probe adapter. Output in HiZ mode.

Test 1:

Test signal: 1MHz sine
Signal applied: CH1
Counter enabled: CH1
Vertical scale = 500mV/d
Timebase = 500ns/d

Counter failure mode 1-1:
CH1=ON, CH2-4=OFF, 1GS/s
Signal amplitude: <=250mVpp

Counter failure mode 1-2:
CH1-2=ON, CH3-4=OFF, 500MS/s
Signal amplitude: <=250mVpp

Counter failure mode 1-3:
CH1-3=ON, CH4=OFF, 250MS/s
Signal amplitude: <=400350mVpp

Test 2:

Test signal: 100MHz sine
Applied: CH1
Counter enabled: CH1
Vertical scale = 500mV/d
Timebase = 5ns/d

Counter failure mode 2-1:
CH1=ON, CH2-4=OFF, 1GS/s
Signal amplitude: <=1.21Vpp

Counter failure mode 2-2:
CH1-2=ON, CH3-4=OFF, 500MS/s
Signal amplitude: <=1.31.4Vpp

Counter failure mode 2-3:
CH1-3=ON, CH4=OFF, 250MS/s
Signal amplitude: <=1.81.2Vpp

Possible solution: counter value display disabled  based on
function(vertical scale, signal level, signal frequency, sampling rate)

[MrWolf]

In the second post let's discover territory that is seemingly beyond measure for Rigol DS1000Z:

Phase and Delay

Let's look at user guide page 141 (6-63) "DS1000Z_UserGuide_EN__page_141.pdf"
Seems to be straight forward stuff...
So I did this:

10MHz sines, 180 degrees phase, 500MS/s.

Hardware counter: ok
Software counter: ok
Period: ok
Graph: ok (checked by cursors)

Delay: insane
Phase: ludicrous

As manual says it first does period (and gets it right!), then it does delay and gets it insanely wrong. Based on that it does some ludicrous phase calc. Also the more waves are on the screen at the same time the more awkward it goes. On the normal scope it is the other way around - more data - more precision.

It cant be that bad and I must doing something wrong?   

Edit: Found sort of workaround. If you go [Measure] => Range,  Change "Region" from Screen to Cursor and fiddle around with cursors there may appear some more-less valid data. BUT as soon as you leave cursors alone they disappear and there is no indication what range is used for data. They must stay on screen in some form or the feature is basically unusable. Screenshot attached from brief moment where cursors are still visible. They are not visible even if you just go to the menu. Only way they appear if you actually move them. Mysterious position number seems to be pixels Someone has been hacking like there is no tomorrow... It reminds me time when I was a kid and programmed well working Tetris game that used actual screen memory on PC XT computer and no separate array Se when little block did fall it actually asked screen memory: Hello, is there anyting on my way...  And it worked!

[MrWolf]

As a possible hint to developers I'll show how phase data done on another scope that is up to 4x cheaper than cheapest DS1000Z, but gets proper software:

Tests:
25MHz, 100ns timebase, 100MS/s - to show how proper sin(x)/x OFF should look like
25MHz, 5ns timebase, 4GS/s (ETS) - to show how proper averaging works
2.5MHz, 1us timebase, 100MS/s - interesting to see how phase math function settles down

What can be seen on these test:

- if it does not know, it does not show! In ETS mode math is OFF because
ETS graph can be uncertain (line gets "thick" - not seen in provided example)

- it does not have built in phase function (probably because it's sort of complex
subject and depends on many variables). Instead one can do math that fits the situation,
for example I have this set as Phase(A,B) measurement:

acos(integral(A*B)/(sqrt(integral(A*A))*sqrt(integral(B*B))))/Pi*180

- it does have special "phase cursors" in addition to regular ones, find these
very helpful

- it does have actual zoom feature that makes placing the cursors very easy,
in DS1000Z you basically need magnifying glass to work with cursors
on smallest timebase & 100MHz

- using ETS and cursors one can get very precise phase data for steady wfm

- Phase(A,B) math works well in non-ETS mode

- sin(x)/x honestly turns off

[Ducttape]

My vote/wish item is for the ability to connect a USB keyboard that could duplicate the functionality of the multifunction knob and, of course, input characters without having to use that carnival game otherwise known as the on-screen keyboard.

Auto fan speed control would be nice to reduce noise.

[metrologist]

Phase and Delay

Anyone else looked into this? Does averaging affect this measurement, and is it possibly this region of phase shift? If I understand correctly, I should be able to duplicate the test with an ~1.3m coaxial delay line and 100 MHz source.

[MrWolf]

Anyone else looked into this? Does averaging affect this measurement, and is it possibly this region of phase shift? If I understand correctly, I should be able to duplicate the test with an ~1.3m coaxial delay line and 100 MHz source.

Actually you do not need 100MHz, it does not matter at all what the frequency is.
All you need is 2 waves on the screen.
This is because some ultimate HaXX0r has done it basically this way:
- let's first print the wave on the screen (and have some matrix representing screen pixels)
- now we have some set of data-pixels that is 602 pixels wide
- lets haxx0nalyze these pixels until    and rising/falling edges are "found"
- then lets apply some kickass low bit integer math (its fast!) and spit the out

In original example signal is 10MHz.
On "solution" picture with cursors it is 100MHz.
And now I did additional pic at only 10kHz (attached).

As you can see precision sort of improves regaring
"Cur" values but signs are all over the place and "Avg" values
are as mad as ever.

Turning Averaging, Sin(x)/x, Mem depth to various values
does not change anything. Also 500MS/s vs 250MS/s do
not matter.

So currently I stick to my theory it's done 12yo HaXX0r style
on some pixel matrix basically off the screen...
Processing power savings are huge compared to analyzing
actual data points 

Edit: Again attached pic how it's done on another scope with 100€ starting price,
but with software from actual engineers. Signal generated also by
properly engineered gen. Note the deviations are in ns and mHz range!
Phase by cursors has absolute accuracy since I can zoom into picoseconds if needed.
Calculated phase is by 2 degrees off but it's just a dumb math function
that cannot account for boundary effects. Would be easy to avoid in
actual software.
Actually I'm dumb, not math... My terminators suck. There is very small phase
difference. Both scopes pick it up from noise floor in A + B. Images
attached.

Dunno maybe in bashing poor Rigol to much but this is how I'm gonna get
even with my 400EUR. Could take it back to shop no prob. But not gonna
do it. I'm gonna hope that this will be fixed instead and someone is gonna learn
how to do stuff properly.

[metrologist]

I notice the Rigol counter does not seem to have having a problem measuring 10 kHz with 250 MS/s in your follow-up screen shot.

What happens if you shift your second source offset so it is out of the phase noise differential? I'm just wondering how the algorithm would determine if a signal is +180+ or -180- degrees.

What I mean, is it correct +180.01 degrees or -179.99 degrees?

[MrWolf]

I notice the Rigol counter does not seem to have having a problem measuring 10 kHz with 250 MS/s in your follow-up screen shot.

Indeed. Today its in the mood... 
Pattern found. Look original post.

What I mean, is it correct +180.01 degrees or -179.99 degrees?

Very metrological remark  180' phase shift is indeed bad case to test against.
But this does not get  Z off the hook. New findings:

- you do not have to own 1+n channel generator to test this stuff! Just feed same signal to all channels you want and make phase shifts using Delay-Cal in channel menu. It cross-checked against real signal and it seems to match. Sadly Delay-Cal is enabled only on 5us or faster timebase.

- workaround to using magnifying glass with cursors is to use [Cursor]=>Mode=>Track and set Cursors A and B to different channels. Then is easy to search for zero crossings. BUT there are only 2 cursors to work with and it is a 4 channel scope... Also it seems that Delay and Phase are also available on 2 channels only.

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

Overall I think that this  box will not get AI anytime soon. Maybe these haxx0magical measurements should be just disabled... And instead there should be possibility add multiple cross-channel Tracking cursor pairs. For example if there would be up to 4 pairs of cursors... Cursor A-1 is  locked to channel A and gets according color. Cursor A-2 can be locked to any channel, but has same color as A-1. Cursor B-1 is locked to channel B and so on...
Exact identification scheme may vary. Anyway with 4x2 cursors lots of stuff could get done 

[MrWolf]

Tracking cursors idea illustrated.

[Karel]

Another bug:

Code: [Select]

usb 1-2: new high-speed USB device number 4 using ehci-pci
usb 1-2: config 1 interface 0 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
usb 1-2: config 1 interface 0 altsetting 0 bulk endpoint 0x3 has invalid maxpacket 64
usb 1-2: New USB device found, idVendor=1ab1, idProduct=04ce
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2: Product: DS1000Z Series
usb 1-2: Manufacturer: Rigol Technologies.
usb 1-2: SerialNumber: DS1ZA17040xxxx
usbcore: registered new interface driver usbtmc

A bulk endpoint in a high-speed device MUST have a max packet size of 512.

[metrologist]

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?