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
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.
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.
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?
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?
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
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.
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.
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
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.
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.
I mostly gonna use the scope for software engineering
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.
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?