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

[David Hess]

If it has to do with peak detection which I think is the most likely option, then it will be easy to determine; check to see if the number of horizontal display points is halved when peak detection is used.

It always returns 1200 pts, also in peak det. mode.

But it cannot return a 1200 point peak detected record in 1200 8-bit words; it would take 2400 words.  I assume the FPGA always returns a 1200 word record but in peak detect mode, the record is composed to 600 pairs and in normal mode, it is 1200 separate points.  At least that is how other DSOs handle it.  By returning a record which is twice as long as necessary in normal mode, peak detection mode does not visibly halve the horizontal resolution.

There is no reason the FPGA could not return different record lengths for different modes but it is an added complication which is not needed for a questionable increase in performance.

Offtopic, what I personally find strange is, why it uses a vertical resolution of only 25 lsb's per division.
For comparison, the DS6000 uses 32 lsb's per vertical division and thus uses the full dynamic range of the ADC for the display.

Lots of DSOs work this way.  An integer mapping of LSBs to display pixels prevents unneeded processing and aliasing.  Further having the digitizer range exceed the displayable screen size prevents clipping during some types of processing although I am unclear if the Rigol can take advantage of this.

I have seen and mostly used DSOs which use 25, 40, 50, 100, and 102.4 points per vertical division.  Resolution in excess of that necessary to display 8-bit data operates on 16 bit data when averaging, high resolution, or DPO modes are used

[MrWolf]

I did  the weird thing... switched on Diff math function:

For square there was flat line initially but cranking up scale did show something:


Switched to 100MHz sine. Again cranking up scale produced some pixellated stuff. Took auto-measurement off it: 32MVpp/s


Further down the menu discovered "Smooth" with minimum setting of 3:


Cranked "Smooth" setting up to 21 and got new auto-measurement value off 85.9MVpp/s (original signal still the same!):


Switching Auto Scale ON/OFF did not help.

So dunno, isnt the diff for 100MHz, 1Vpp sine supposed to be in the 1.2GVpp/s vicinity?
Or the "Smooth" is working other way around - smaller value means more "Smooth"  but why "pixels" then...

[Karel]

But it cannot return a 1200 point peak detected record in 1200 8-bit words; it would take 2400 words.

The peak detect acquisition mode is used to help discover if any “interesting” sample points would be lost in the
aforementioned sample mode. Here, the highest and lowest peaks from adjacent pairs of sample intervals are
saved and put into memory. Thus, any abnormal high or low values, glitches, etc. will be clearly captured in the waveform
memory so that further investigation of these anomalies is possible. In this mode, there isn’t any data loss, but the
precise waveform shape will be somewhat obscured by the high/low value envelope.

source: http://www.tek.com/blog/sample-processing-digital-oscilloscope

So, 1200 samples in peak detect mode is correct.

[TurboTom]

@MrWolf
It's been discussed in detail already, have a look here: https://www.eevblog.com/forum/testgear/rigol-ds1054z-how-to-get-_maximum_-positive-slew-rate/

The Diff function on all the recent rigol oscilloscopes is unusable where the "baseline" model (DS1000Z) still offers the best performance while the "advanced"  models are even worse -- same as the FFT.

It seems Rigol makes most of their revenue with their basline models so no need to take care of improvements for the the DS2000 and DS4000 series...

Cheers,
Thomas

[David Hess]

But it cannot return a 1200 point peak detected record in 1200 8-bit words; it would take 2400 words.

The peak detect acquisition mode is used to help discover if any “interesting” sample points would be lost in the
aforementioned sample mode. Here, the highest and lowest peaks from adjacent pairs of sample intervals are
saved and put into memory. Thus, any abnormal high or low values, glitches, etc. will be clearly captured in the waveform
memory so that further investigation of these anomalies is possible. In this mode, there isn’t any data loss, but the
precise waveform shape will be somewhat obscured by the high/low value envelope.

source: http://www.tek.com/blog/sample-processing-digital-oscilloscope

So, 1200 samples in peak detect mode is correct.

I know how peak detection works in detail.  The question was exactly how Rigol implements it.

Earlier Fungus posted:

The programming guide uses numbers in the range 0 to 1199 for setting start/end points. This suggests it works with 2 samples per pixel (600x2 = 1200 points).

The mystery is why 1200 samples are used for a 600 point wide display instead of 600.  My hypothesis is that 1200 samples are used so that peak detection is supported without halving the displayed horizontal resolution.  It may have been easier to always have the FPGA return 1200 samples for every acquisition than 600 or 1200 samples depending on the mode.

[Karel]

Just posting this so maybe Rigol wakes up...

Apply the same test signal to inputchannels 1 & 2 (e.g. a squarewave of 1MHz).
Set the timebase to 50 nanoSec.
Set the memory depth to 600 Kpts.
acquire the waveform and set the scope to STOP mode.

At this point, everything is still ok.

Now download the waveforms of both channels
(in this example I use DSRemote/Wave Inspector but there's plenty of other software that can do the same).

Compare the downloaded waveform with the screen waveform... big fail.

This has been reported to, and confirmed by, Rigol in February 2016. So far, they didn't fix it.

[David Hess]

Going by the graticule and sample rate, the horizontal displacement is about 60 points which unfortunately does not seem to match up with anything.

Is there a vertical displacement as well or was the signal offset changed?

[MrWolf]

Going by the graticule and sample rate, the horizontal displacement is about 60 points which unfortunately does not seem to match up with anything.

How not match? 600,000 samples, 60 sample error. 10,000x ratio. Must run out of precise mem address bits doing port from mahjong 

[TheoB]

Mr kwass is not updating the index of this thread to keep track of reported/found bugs.
You may wonder why the community should want to do that at all (just for fun I guess?). Rigol should mention the issues that are known but not fixed. It would give me somewhat more confidence in the supplier.

I also have reported a bug which was confirmed. I hope this new firmware solves it.

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


The Rigol engineer promised me that I would receive an update when this would be solved:

I saw this behavior also on my unit. I reported it to our R&D department
and asked them to correct it for next firmware update.

When I get a feedback I will communicate with you the date when the next
firmware update will be available.

[Karel]

Is there a vertical displacement as well or was the signal offset changed?

Yes but that was caused by me, I made some error during experimenting.
Didn't influence the problem though.
I fixed & replaced the screenshots.

[David Hess]

Is there a vertical displacement as well or was the signal offset changed?

Yes but that was caused by me, I made some error during experimenting.
Didn't influence the problem though.
I fixed & replaced the screenshots.

Now you can tell that the trigger position got displaced as well so there are two bugs shown.

[kazam]

This bug can be confirmed by me. Infuriating when you're trying to measure IQ output signals and compute complex ffts. The offset changed with timebase also.

I ended up getting a R&S RTE1024 and that works fine of course although I realize that is certainly not an option for everybody.

In my opinion rigol should just open source the firmware. It's not likely anyone can manufacture the hardware cheaper anyway. Also most people wouldn't risk running the firmware on unsupported hardware.

I'm not holding my breath though!

[Karel]

I ended up getting a R&S RTE1024 and that works fine of course although I realize that is certainly not an option for everybody.

For the price of an RTE1024 you can buy 20x DS1054Z ...

[RoGeorge]

Just posting this so maybe Rigol wakes up...

Apply the same test signal to inputchannels 1 & 2 (e.g. a squarewave of 1MHz).
Set the timebase to 50 nanoSec.
Set the memory depth to 600 Kpts.
acquire the waveform and set the scope to STOP mode.

At this point, everything is still ok.

Now download the waveforms of both channels
(in this example I use DSRemote/Wave Inspector but there's plenty of other software that can do the same).

Compare the downloaded waveform with the screen waveform... big fail.

This has been reported to, and confirmed by, Rigol in February 2016. So far, they didn't fix it.

1. This seems to affect only the downloaded data. On the oscilloscope screen, all the traces are synchronous.
2. Only data for channel 1 seems to be shifted in time relative to the other 3 channels. The other 3 channel appears to be all synchronous when downloading their waveform.
3. The time shift varies with the memory depth setting (somewhere between 20-70 data points, depending on Mem Depth)

Tested with FW 04.04.SP1

Does anybody else have synchronous downloaded waveforms for channels 2, 3 and 4, or is it just for this particular oscilloscope unit?

[Karel]

It's not just a matter of not beeing synchronous.
They must be all at the trigger point as well.

[Karel]

Another bug is the blatant USB spec violation:

Output of dmsg after connecting th scope to a pc:

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.

Depending on the combination of software (OS) and hardware (USB host controller on motherboard)
this causes connection problems.

[RoGeorge]

It's not just a matter of not beeing synchronous.
They must be all at the trigger point as well.

Yes indeed, they are all shifted in relation with the trigger point, and the saved waveform for channel 1 is also shifted in relation with the channels 2, 3, 4, but the saved waveforms for channels 2, 3 and 4 are not shifted between each other for my oscilloscope.

For what I am trying to do now, I don't need the exact location of the trigger point, but I need at least two channels that can save their waveforms well aligned in time relative to each other.

Can anybody please confirm if the saved waveforms for channels 2, 3 and 4 are aligned or shifted between each other?

[Karel]

Can anybody please confirm if the saved waveforms for channels 2, 3 and 4 are aligned or shifted between each other?

Will do that when I have some spare time. Holidays are over

[Karel]

Here are the results with all channels switched on and connected to the same signal:

[duracell]

I need an advice.

As I could read here, there were some bugs with DS1054Z.
Are they fixed now ?

I need a scope for 400 $.
Should I buy DS1052E or DS1054Z or something else.

Thank you very much for your opinion.

[ebastler]

As I could read here, there were some bugs with DS1054Z.
Are they fixed now ?

I need a scope for 400 $.
Should I buy DS1052E or DS1054Z or something else.

There may be a couple of bugs remaining, but none of them should stop you from buying a DS1054Z. It is not a perfect scope, but its limitations are by design, not due to bugs:

• The user interface can react a bit slowly when many curves are displayed and you e.g. move a trace around on the screen.
• All measurements (measuring e.g. rise time, frequencies etc. from the trace) and decoding of serial data streams are done on the screen data only and do not use the deeper sample memory. That makes the precision of timing measurements and the decoding dependent on the time resolution you have currently set on the screen, which can make handling a bit awkward (when using those functions).
• Build quality is very good, but some users get annoyed by the fan noise. Some (incl. me) also end up replacing the encoder for menu selection with one which has detents, to make it easier to select a desired menu item.
  

Whether or not these stop you from buying a DS1054Z is your personal choice. At the $400 price level (in Europe) you will not find a better scope in my opinion. Please don't buy the old D1052E, it is much more limited! 

BTW, please don't double-post on this forum. I just notice that you have posted the same question on the general DS1054Z thread.

[duracell]

Sorry for the double post and thank you very much for your response.

You (and the the kind guy from other thread (double post  ) gave me the all important infos I need to know.
So i made my final decision and will purchase tomorrow a DS1054Z.
Will come with impressions, as soon as it arrives.
 

[duracell]

I found this video on Youtube,



showing  DS1054Z freezing.

I gave the owner the advice to upgrade to firmware 00.04.04.01.01  2016/09/14
but it didn't help.

Because I today purchased the same scope, am little bit worried now.
Can this freezing showed in the video be fixed ?

[alsetalokin4017]

There is something seriously wrong with that scope. I've had 3 different DS1054z units in my lab thus far and none of them have been anywhere near that noisy. People have complained about the fan noise from the very beginning, and on the strength of those complaints I bought one of the quieter fans recommended when I ordered the scope in the first place-- but I never bothered to install it since the noise is negligible in my scope. But I think the noise from that scope is much greater even than what people complained about.

And I've identified and posted about a Freeze Bug that sometimes can make the scope start up in a "frozen" condition, but as far as I know only scopes with Boot Version 0.0.1.2 were affected, and the bug was fixed several firmware revisions ago.

It would have been helpful if the owner of the scope in that video showed the full system information screen.

You should not experience this problem, and if you buy your scope from a reputable vendor if you do you can return it for replacement with a good unit.

[duracell]

You should not experience this problem, and if you buy your scope from a reputable vendor if you do you can return it for replacement with a good unit.

 
thank you.