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

[Fungus]

Good. Then of course you will immediately install it when it is available, you will test all the scope's functions (even the ones you don't need yourself) and give us a nice thorough report. Won't you?

Like you did with the last firmware update?   No.... wait....

What's this? Personal attacks in multiple threads? 

[Marcos]

When he's telling you the truth you consider that "personal attacks" ?
Fungus mate, why do you always expect to see only great references for your "beloved" Rigol Scope?
Are they paying you for this?

[Fungus]

When he's telling you the truth you consider that "personal attacks" ?

What "truth" was there in his post. As far as I can tell there wasn't a single factual statement that could be tested. It was all speculation and opinion and all directed personally at someone (me, in this case).

Fungus mate, why do you always expect to see only great references for your "beloved" Rigol Scope?

I don't.

This thread is a place for listing Rigol bugs, discussing shortcomings, etc., right? Do you see me posting in here trying to defend the DS1054Z? Nope. I've even posted a few complaints myself.

Do I go into threads which were specifically started to discuss Rigol bugs and try to defend it or start attacking people for being mean? Nope.

Do I call out the handful of people who try to derail every single thread that mentions a DS1054Z by "Rigol Bashing". Yep, guilty (raises hand).

[Gabri74]

Maybe I've found a new bug in the measure/statistic function   

- 2 channels on with width measurement
- statistics on
- 1st channel is connected to a debug pin to measure max/min duration
  of a touchscreen IRQ event callback on a MCU
- Normal duration is around 650ns, when finger pressed it should vary from 650ns to about 6us

This is what happens:

- pic 1, finger not pressed, you can see on the display 2 alternating width, one of ~650ns and one of 1.8us
Measure statistic is already wrong, because it takes into account minimum value only
- pic 2, finger pressed. Now we have a series of different duration pulses, from 650ns to 1.8us. Statistic max/average are wrong
- pic 3, acqusition stopped... still wrong
- pig 4, waveform moved with horizontal knob, statistic updated with 1.8us value (but now min/avg are wrong, but I guess that's ok in stop mode)

 

Any toughs ?

[Fungus]

Any toughs ?

They all look OK to me. The gap in the 0V baseline is measured correctly in every picture.

I suspect that if you want "average" to mean anything then you'll need more than one baseline-gap visible on screen.

[Gabri74]

I suspect that if you want "average" to mean anything then you'll need more than one baseline-gap visible on screen.

Thanks for your replay.
So, If I understand correctly, the statistics only works on the displayed data for ONE trigger event? I.e. Id does not
accumulate measures from multiple trigger events ?   
Looking through the manual now...

[Fungus]

So, If I understand correctly, the statistics only works on the displayed data for ONE trigger event? I.e. Id does not
accumulate measures from multiple trigger events ?   

I think it works from what's visible on screen.

On your screendumps there's only one place where the signal isn't ambiguous. That's what it measures.

[alsetalokin4017]

I suspect that if you want "average" to mean anything then you'll need more than one baseline-gap visible on screen.

Thanks for your replay.
So, If I understand correctly, the statistics only works on the displayed data for ONE trigger event? I.e. Id does not
accumulate measures from multiple trigger events ?   
Looking through the manual now...

No, that's not right. For this particular "average" shown in the Statistics measurement, the scope is taking the average, max, min, std dev, of consecutive samples of the screen data, which occur at around 3 times per second or so, more or less, depending on how much other stuff is going on. That is, yes, it does accumulate measures from multiple trigger events, or rather screen updates. It is still working on the data displayed on screen though.  This is different from selecting an "average" from the left-hand Measurements menu, where you get an average across several cycles of a waveform displayed on screen during one screen update.  So you can even use the Statistics display to get the average, max, min, std.dev.  of "Average" measurements from the left-hand menu.

[Gabri74]

the scope is taking the average, max, min, std dev, of consecutive samples of the screen data, which occur at around 3 times per second or so, more or less, depending on how much other stuff is going on

Thanks for your replies. So ultimately statistics are useful for slow changing signals or signals with a low std dev.
If I need to characterize a pseudo-randomly variable signal in terms of min/max/avg value they are not to be trusted   

[borjam]

New firmware version!

http://int.rigol.com/Support/SoftDownload/3

Code: [Select]

[Supported Model]    All the MSO/DS1000Z Series Digital Oscilloscopes
[Latest Revision Date]  2016/05/31

[Updated Contents]
--------------------
v00.04.04.00.07  2016/07/19
     - Added the full-screen display in the XY mode
     - Modified the Trace data of average sample mode
     - Fixed the bug of system halted for wave persistance in the Zoom mode
     - Fixed bugs about Measure


Now. Who dares?

 

[bitseeker]

Good one, borjam!

Well, I hope they fixed more than they documented in that release note. But I shall be patient and see what the more adventurous forum members report about this new version. I'll stay on SP1 for now.

[Mechatrommer]

installed. XY and FFT can viewed as fullscreen now (FFT ovelapped with CH display, but XY mode no CH view overlapping, not the best thing), FFT in memory mode can halt signal display, i need to change timescale, press buttons etc to get it running again, few second stopped again, this is repeatable behaviour, but i guess when i set memory length to max 6M, when set to auto seems fine (no halt, but still slow). "pluses" typo is still there so i guess this is a "during the non busy week" rigol project "in the lab" after so many months.

[bitseeker]

When you set memory depth to auto, is it using a lot less than 6M?

[Roeland_R]

installed. XY and FFT can viewed as fullscreen now (FFT ovelapped with CH display, but XY mode no CH view overlapping, not the best thing), FFT in memory mode can halt signal display, i need to change timescale, press buttons etc to get it running again, few second stopped again, this is repeatable behaviour, but i guess when i set memory length to max 6M, when set to auto seems fine (no halt, but still slow). "pluses" typo is still there so i guess this is a "during the non busy week" rigol project "in the lab" after so many months.

Is it possible to go back to an older firmware now ?

[Mechatrommer]

Is it possible to go back to an older firmware now ?

according to the mainstream... no. and why should i? the rotary knobs perform poorly now, and they performed poorly before. (hint: press stop before adjusting knobs to proper positions for better performance) but i do find myself reaching all channels more and more now, thats all i care most.

When you set memory depth to auto, is it using a lot less than 6M?

no difference to FFT appearance and performance. it seems FFT has its own wisdom at selecting memory depth. its just when i set to 6M, FFT got halted, not in Auto Mem Length. and "Memory" mode FFT performs poorly now, just as before, if not a bit slower. no worry i have my VisaDSO if i need full memory length FFT. for now FFT is not my game.

[bitseeker]

OK. Guess I'll check out VisaDSO at some point. The only FFT use I'm considering in the short term is to adjust my analog function generator. There's a pot to set minimum distortion on the sine output. I can't see buying a spectrum analyzer just for that.

[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...

[RoGeorge]

I guess I should post this here....

5 Bugs at once:

Software Version: 00.04.04.SP1 (== 00.04.04.01.01), Board Version: 0.1.1

[Supported Model]    All the MSO/DS1000Z Series Digital Oscilloscopes
[Latest Revision Date]  2016/09/14

[Updated Contents]
--------------------
v00.04.04.01.01  2016/09/14
     - Supported the multi-inteface of LXI
     - Fixed bugs about Measure

Generator was set at 1.5MHz square, 9Vpp, 4.5Vdc offset.

Seems to be working good enough. Could not reproduce any of the five bugs.
 

LATER EDIT:
Well, except the Pluses instead of Pulses, of course

[RoGeorge]

If CH3 is on DC or AC instead of GND, then the Rms=130..140mV.
Rms=334mV could be debatable, but could also be just noise and op amp offset (+/- 1 ADC count at 10V/div).

[2N3055]

If CH3 is on DC or AC instead of GND, then the Rms=130..140mV.
Rms=334mV could be debatable, but could also be just noise and op amp offset (+/- 1 ADC count at 10V/div).

It is noise and offset... 10V/DIV is 80V full scale, divided by 0.334 is something about 240.... that is 8 Bit ADC  basically running at ENOB 7.9 .. Not bad actually.. and because of DC offset, it is different between DC and AC coupling..

[RoGeorge]

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?

[2N3055]

That bug was reported by someone and it was not something you can see on the scope.. It was related to data downloaded to PC..
As far as I know, nobody reproduced it, it was specific set of doing something to scope together with his own software that he wrote...

[RoGeorge]

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.

What I don't understand is why each data point value seems to be repeated?

I mean, for the same channel, let's say CHAN1, each second sample seems to have the same value with the previous one. It can be clearly seen from the chart that consecutive points always comes in pairs of the same value (same level). I will look into this one later. Just in case someone else want to reproduce the 'pairs', I did:

nc 192.168.1.3 5555

wav:form asc
wav:star 1
wav:stop 1200
wav:sour chan1
wav:data?

wav:sour chan2
wav:data?

then plot the CSV data.

[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.

[RoGeorge]

Thanks for mentioning the 800 horizontal resolution.

So why 1200? I'm not sure yet. The only mention I found as a reason for the number 1200 is related with the MATH channel:

The source selected is equally divided into 1200 parts horizontally

One more thing to mention: If the Acquire -> Mem Depth is left on Auto, the scope will choose 500MSa/s and only 600 pts, which is very low and also is half of the number 1200 - that might be related with the pairs of values seen in the extracted data points.

I need to do more experiments before drawing any conclusions.