New Rigol DS1054Z oscilloscope

[Assafl]

Ok - Just got confirmation and a case number from Rigol NA for both the Meka77's RMS bug and the Spelling Error. They were able to recreate both and stated that I will be alerted when resolved.

[Assafl]

The RMS bug was first introduced with firmware version 00.04.03.01.05 from 2015-06-16. It had been discussed exhaustively about a year ago already (for the new owners of a DS1000Z  ). The only disappointment is that Rigol didn't fix it in the recent update. So no need to get nervous about that now, all of those who installed the mentioned update learned to live with that bug and surely will survive the next several months until Rigol comes up with a fix (I'm quite optimistic they will...).

Cheers,
Tom

Unlike the freezing bugs (annoying) and spelling bugs (albeit annoying less than freezing) - Meka77's RMS bug has the ability to get someone to err in a design or troubleshooting session due to the scope. Therefore I believe it behooves anyone who uses the VRMS measurement should understand when it happens and how to avoid it.

[bitseeker]

Ok - Just got confirmation and a case number from Rigol NA for both the Meka77's RMS bug and the Spelling Error. They were able to recreate both and stated that I will be alerted when resolved.

Excellent. Thanks for the update, Assafl.

[linearphase]

I think the measureable difference will be tiny in practice.

I agree, it is somewhat of a moot point because the sample rate is not there if using more than one channel anyway.

1ch = 1GSa = 10 samples per second @ 100 MHz
2ch = 500MSa = 10 samples per second @ 50 MHz
4ch = 250MSa = 10 samples per second @ 25 MHz

Then general rule of thumb is this:

To reproduce a sine wave with 5% envelope accuracy IF you are using sinx/x interpolation requires 2.5 samples per cycle NOT per second.
So for 1 GS/s the DIGITAL part of the scope could accurately reproduce 400 Mhz sine waves that look like they were modulated 5%. However, most square waves have significant frequency components to at least the 5th  harmonic . So this scope in single channel mode could do 80 MHz square waveforms. BUT this is further limited by the analog bandwidth of the scope.
Since you have to reproduce the 5th harmonic reasonably accurately to have square wave a 100Mhz scope would reproduce only a 100/5 or 20 MHz square waveform accurately using sinx/x interpolation. This would also require 100/2.5 samples PER CYCLE or 250MS/s. Stated another way a 100MHz Rigol should be able to accurately reproduce a 20 MHz square wave on all fours channels simultaneously. The same scope would also only be able to do 20 MHz square waves on 2 channels because the analog bandwidth assumed here is 100MHz. The Digital storage  bandwidth would however be 40 MHz on square waves. Once again not usable because of the analog bandwidth limitations.

If the interpolation is linear only, and some scopes are. then the 2.5 quote above becomes 10 , which lowers the bandwidth by a factor of 4!
Also certain scopes, Notably Agilent for a long time required a factor of 4 rather than 2.5 due to the interpolation algorithm used. This reduced the usable bandwidth at any given sample rate.

[Karel]

I seem to be able to get this running on Linux (Gentoo specifically), however PyDSR, sigrok, and DSremote all seem to not be able to communicate with my scope over USB.  I know it is not simply a permissions issue.  DSremote works over LAN.

DSremote worked before I upgraded to the latest firmware.  Any Linux using 1054Z owners have any ideas?

The latest firmware update (version 00.04.04.00.07) breaks the usbtmc interface.

[metrologist]

You mean not just terrible anymore, just fully broken?

https://www.eevblog.com/forum/testgear/rigol-usbtmcvisa-interface-is-really-terrible/

And what does that mean? Does the the Rigol app (UltraSigma or UltraScope) still work to send scpi commands?

BTW, is this where to download the firmware? When I try to navigate from the rigolna site, I get to a form where I have give them all my contact info and serial number.

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

[Karel]

You mean not just terrible anymore, just fully broken?

https://www.eevblog.com/forum/testgear/rigol-usbtmcvisa-interface-is-really-terrible/

It still needs to be seen what exactly the cause is, Rigol or the usbtmc kerneldriver.

And what does that mean?

It means that applications like DSRemote don't work anymore via usb connection (at least in this moment). Only via lan.

Does the the Rigol app (UltraSigma or UltraScope) still work to send scpi commands?

I don't know, I don't use them.

[alsetalokin4017]

You mean not just terrible anymore, just fully broken?

https://www.eevblog.com/forum/testgear/rigol-usbtmcvisa-interface-is-really-terrible/

And what does that mean? Does the the Rigol app (UltraSigma or UltraScope) still work to send scpi commands?

BTW, is this where to download the firmware? When I try to navigate from the rigolna site, I get to a form where I have give them all my contact info and serial number.

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

You can download the DS1000z firmware update from this link:
http://beyondmeasure.rigoltech.com/acton/fs/blocks/showLandingPage/a/1579/p/p-0019/t/page/fm/0
Note that the "release notes" directly linked on this page is not up to date, but the firmware in the link is the latest version 00.04.04.00.07, and the update zipfile contains an updated release notes text file.

[LokiChaos]

I seem to be able to get this running on Linux (Gentoo specifically), however PyDSR, sigrok, and DSremote all seem to not be able to communicate with my scope over USB.  I know it is not simply a permissions issue.  DSremote works over LAN.

DSremote worked before I upgraded to the latest firmware.  Any Linux using 1054Z owners have any ideas?

The latest firmware update (version 00.04.04.00.07) breaks the usbtmc interface.

Thank you, at least I can't not worry about trying to track down where the problem is.

I spun up a VM and installed UltraSigma & such and while it appears XP correctly sees and device and installs the driver, nothing seems to actually be able to use it.  I however, cannot verify if that is a problem with the scope's firmware or my software setup as I only set things up now to test.  However, I can verify it works over LAN in windows as well as with DSremote. 

[Dwaine]

I seem to be able to get this running on Linux (Gentoo specifically), however PyDSR, sigrok, and DSremote all seem to not be able to communicate with my scope over USB.  I know it is not simply a permissions issue.  DSremote works over LAN.

DSremote worked before I upgraded to the latest firmware.  Any Linux using 1054Z owners have any ideas?

The latest firmware update (version 00.04.04.00.07) breaks the usbtmc interface.

Thank you, at least I can't not worry about trying to track down where the problem is.

I spun up a VM and installed UltraSigma & such and while it appears XP correctly sees and device and installs the driver, nothing seems to actually be able to use it.  I however, cannot verify if that is a problem with the scope's firmware or my software setup as I only set things up now to test.  However, I can verify it works over LAN in windows as well as with DSremote.

I have been using my DS1054z by USB with pyDSR just fine for the last hour.  At the latest firmware version

[LokiChaos]

I'm looking into it, apparently some issues with my PyVISA install, now resolved (Need an actual VISA lib, though I need to do some other work regarding versions).

Still, sigrok, dsremote, as well as the official tools under MS Windows fail to see it.

[technogeeky]

I think the above poster meant to say PyDSA. I can also run PyDSA in Mac OSX.

That said, it seems like the FFT on-scope with the Memory (instead of Trace) option is better than what you can get with PyDSA. And PyDSA for me, is ending in weird ways which require me to reset the USB connection and restart it.

I'll investigate further, later.

[Karel]

The latest firmware update (version 00.04.04.00.07) breaks the usbtmc interface.

I have my DS1104Z-S updated with firmware 00.04.04.00.07.
My program 'Rigol Bildschirmkopie' works with the USB connection.

But there is no response to the command '*IDN?'.
A combination with other commands work, eg.'*IDN?;:SYST:ERR?'.

Peter

Thanks! Now DSRemote works again thanks to your tip!

[LokiChaos]

git pull & make and dsremote works, many thanks.

[metrologist]

* Maybe never mind. I was just reading the start/stop point. I tried it in RAW format too and certainly did not get 250k values. I'll check again tonight and report any anomalies, if I see any.

I upgraded to the latest FW. The Rigol UltraSigma SCPI panel works, but *IDN? is slower to return. I was checking out the waveform data return. When the mode is set to MAX and format is set to ASC, I get around the max number of records (~15k), but when the format is set to BYTE or WORD, I only get ~1k. It should return 250k or 150k, respectively. (actually, I'm not sure if the ASC format returned 15k values, it was a much larger block of numbers though...). OTOH, I appreciate the programming demos they provided.

[freebil]

I think the above poster meant to say PyDSA. I can also run PyDSA in Mac OSX.

That said, it seems like the FFT on-scope with the Memory (instead of Trace) option is better than what you can get with PyDSA. And PyDSA for me, is ending in weird ways which require me to reset the USB connection and restart it.

I'll investigate further, later.

Any news about it? Fft function is better on pyDSA or in-scope? I would like to buy this scope and fft function is important for me. Could you please add a screenshot from pyDSA and in-scope fft if possible? Thanks.

[heatbreak]

Any news about it? Fft function is better on pyDSA or in-scope? I would like to buy this scope and fft function is important for me. Could you please add a screenshot from pyDSA and in-scope fft if possible? Thanks.

From what I gather, FFT is not a strong feature on the 1054Z.  See EEVBlog #845.

[technogeeky]

Any news about it? Fft function is better on pyDSA or in-scope? I would like to buy this scope and fft function is important for me. Could you please add a screenshot from pyDSA and in-scope fft if possible? Thanks.

From what I gather, FFT is not a strong feature on the 1054Z.  See EEVBlog #845.

Again, I think this is somewhat old news. I'm not saying the 1054z is a strong signal analysis tool, but the FFT with Memory mode on is a great deal better than it was back when Dave tested it.

Maybe I misremember.

I can't watch it right now because I'm on cell.

[heatbreak]

Again, I think this is somewhat old news. I'm not saying the 1054z is a strong signal analysis tool, but the FFT with Memory mode on is a great deal better than it was back when Dave tested it.

Mmm...  The firmware update came out like June '15 and Dave's comparison was done in Jan 2016.  I wonder why he was testing with the outdated firmware.  In any case, one guy in the #845 thread showed the improvement with the new firmware at 1kHz and the results looked similar to the GW Instek.  However, Dave's tests were done at 1 MHz.  Will the new firmware match the performance of the GW Instek at 1 MHz?

I'm interested to know because I too am in the position to buy an entry level scope soon.  My choices are between the GW Instek 1000B (or 2000E) series and the 1054z.  What put me off about the Rigol are the slow UI performance (like the lag between moving the vertical knob to when the trace moves), some of the weird bugs (I know most of them have been fixed except the rms bug, but the nature of the bugs kinda make me think the software isn't well design or implemented), and the fft.  Is the UI lag fixed and the fft performance matches the GW Instek?

I mostly gonna use the scope for software engineering, with occasionally hardware tinkering, so I think most, if not all, of the "bells and whistles", including the fft, of the Rigol are not important to me.  I have never used nor do I ever feel the need to use the decode feature.  I can see it would come handy if you're trying to reverse engineer something though.  But they're still good to have maybe I'll use them more once I have a chance to try them

But anyhow, is the GW Intek more robust than the Rigol?  I know the Rigol has the best value, but if I have to question my tool from time to time, then I rather spend a little more money on something that's more robust.  Nothing is worst than having to troubleshoot your tool in the middle of troubleshooting if you know what I mean.

[CustomEngineerer]

If FFT performance is that important to you, just get the GW Instek 2000E series and be done with it. While Rigol did improve FFT on the DS1000Zs, its still not great. I have a Rigol DS2072A which has even worse FFT than the DS1000Z (think its the same as it was on the DS1000Z before the update). I have used the PyDSA software before, but its no substitute for having the scope do it natively. If you plan on using FFT frequently, I think you will regret getting a DS1000Z.

[Fungus]

I mostly gonna use the scope for software engineering

I'm not sure what that means....but, in the oscilloscope world bandwidth is king. Ask anybody.

A hacked Rigol has more bandwidth.


PS: In reality you don't spend much time moving the traces up/down, and exactly how much better is the Instek at that? There's two or three people in this forum who criticize Rigols endlessly but no side-by-side comparison videos from them.

[pascal_sweden]

Yes, only some text summaries, and if there is only a handful of GW-Instek users, it is of course no surprise that there are less bugs reported, simply because they have not been discovered by that handful of GW-Instek users.

[Fungus]

if I have to question my tool from time to time, then I rather spend a little more money on something that's more robust.  Nothing is worst than having to troubleshoot your tool in the middle of troubleshooting if you know what I mean.

The Rigol haters in this forum have done us one enormous favor: We can confidently list the questionable measurements on a Rigol DS1054Z.

The list at the moment is:

a) RMS voltage readings when more than 1 adjacent channel is enabled.
b) There is no (b)

If you buy any other oscilloscope then there's no such list. You're on your own.

Think about that before continuing. 

[heatbreak]

I mostly gonna use the scope for software engineering

I'm not sure what that means....but, in the oscilloscope world bandwidth is king. Ask anybody.

A hacked Rigol has more bandwidth.


PS: In reality you don't spend much time moving the traces up/down, and exactly how much better is the Instek at that? There's two or three people in this forum who criticize Rigols endlessly but no side-by-side comparison videos from them.

Sorry I should have said I will use it for embedded software engineering.  The highest SPI/IC2 speed I've encountered is 4 MHz so 50 MHz bandwidth should be enough for me.  Not to say more bandwidth is not welcomed.  Plus the diff between a 100 MHz and a 50 MHz is not much.  You can watch Dave's GW Instek unboxing video and some other guy's metube video complaining about 1054z UI lag for a comparison.  Can you post a video with the latest firmware showing the UI speed of the trace movements?

[Fungus]

Sorry I should have said I will use it for embedded software engineering.  The highest SPI/IC2 speed I've encountered is 4 MHz so 50 MHz bandwidth should be enough for me.  Not to say more bandwidth is not welcomed.  Plus the diff between a 100 MHz and a 50 MHz is not much.

In the digital realm and oscilloscope's "bandwidth" has very little relation to the frequency of the signal you're looking at.

eg. Imagine you have a single rising edge on screen - that's a 0Hz signal.

On a 100MHz 'scope the trace will rise in half the time that it takes on a 50Mhz 'scope and that's a big difference.

You can watch Dave's GW Instek unboxing video and some other guy's metube video complaining about 1054z UI lag for a comparison.  Can you post a video with the latest firmware showing the UI speed of the trace movements?

If you're doing digital work and basing a purchasing decision on that rather than bandwidth and number of channels then you're doing it wrong.

Me? I say 4 channels/100Mhz/Serial decoders is a minimum requirement for digital/microcontroller work.

I really don't care what brand you buy, but: Make a shortlist based on that specification then compare prices. Now consider if moving the trace up and down a bit faster is worth that much money.