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

[alank2]

I tried a DS1074Z-S and had to return it.  I was buying it mostly for the signal generator and thought I could perhaps sell my other scope because it is a scope too.  The problem was that I encountered too many bugs.  Some of these bugs may already be known.

One was that it was blinking on the 5nS timebase for some reason.  Instead of a solid display like you see at 10nS or slower, it would be fine fine fine, and then flicker a bit.

The signal gen is where I had most problems.  I got the feeling I was trying to use something no one has ever tested, I figured by now most features would be tried and bugs would be known and made known to Rigol.  I tried loading some arbitrary waveforms, but every time I would do this the amplitude would reset to 10mV for some reason.  I would then the button on it and set it back to 2.5V, but the output would NOT change.  Only once I tried to do anything with the offset would it actually change the output for some reason.  What is really dumb is that the offset can only be zero because the amplitude is 2.5V, but that doesn't matter, just trying to change the offset seems to set the channel and finally make the new amplitude take hold.  I finally gave up trying to load an arbitrary waveform file, though the square wave and ramp wave ones seemed to do much better than the sine wave one I tried.  I decided to just use the internal editor to create an arbitrary waveform.  I entered 16 points for a sinewave by hand and at the end, it was all jaggy and not right.  I did that with create.  When I used edit to go back in and apply it a second time, then it corrected itself and was ok.  If you save it and try to reload it, it won't load properly.  I finally gave up and decided to return it.

[gojimmypi]

HDMI!!!

Here's my attempt to catalog the bugs and wish list items for the Rigol DS1000Z oscilloscopes.   
...(snip)...

Is Rigol listening? (hope so)

I think it would be ridiculously awesome to have an HDMI output that mirrors what you see on the otherwise small screen: resulting in not only easier to read screens at the bench, but also the ability to more easily record what you see.

OR

Even easier and simpler (no hardware mod): implement something in software that allows the user to "cast" the screen onto a Chromecast device on the local ethernet:

http://www.amazon.com/dp/B00DR0PDNE/

https://support.google.com/chromecast/answer/2998336

maybe even a web browser:

https://support.google.com/chromecast/answer/2998338

that would seriously ROCK! 

[marber]

I'm debugging an SPI communication issue with a chip that uses SPI mode 3, and while using the Rigol DS1000Z's SPI decoding, I noticed something odd:

It decodes individual bits in an 8-bit SPI transfer as '0xFF'.

This happens when 'Polarity' is (incorrectly) set to GND=1 - otherwise it decodes it as '00' which is not incorrect but confusing enough for a 1 bit value. Edge is set to 'falling'; when set to rising edge (which is what I need) it doesn't decode at all. Likewise, if I change Polarity it doesn't decode either. Width is set to 8. If I zoom out further, it doesn't decode the full 8 bit 'packet' either, just the individual bits.

Bug, or am I just missing something?

DS1074Z-S 'upgraded', Software Version 00.04.03.SP1, Board Version 4.1.1.

[kwass]

The scope only uses the screen memory buffer for decoding.  You pretty much need to be able to see all the bits in each character yourself for accurate decoding.  It's a severe limitation and one that Rigol will hopefully address in a future upgrade, it's (B) on the wishlist at the top of this thread.

[marber]

The scope only uses the screen memory buffer for decoding.  You pretty much need to be able to see all the bits in each character yourself for accurate decoding.  It's a severe limitation and one that Rigol will hopefully address in a future upgrade, it's (B) on the wishlist at the top of this thread.

Yes, but it has all 8 bits available, so it's able to decode the full byte. Granted, it doesn't have the falling edge of CS to aid this in the screenshot I provided, but a) when I zoom out a bit to include that it still doesn't decode the full packet, and b) it certainly shouldn't be decoding individual bits as 0xFF (or even 0x7F as I saw later).

[Howardlong]

I'm debugging an SPI communication issue with a chip that uses SPI mode 3, and while using the Rigol DS1000Z's SPI decoding, I noticed something odd:

It decodes individual bits in an 8-bit SPI transfer as '0xFF'.

This happens when 'Polarity' is (incorrectly) set to GND=1 - otherwise it decodes it as '00' which is not incorrect but confusing enough for a 1 bit value. Edge is set to 'falling'; when set to rising edge (which is what I need) it doesn't decode at all. Likewise, if I change Polarity it doesn't decode either. Width is set to 8. If I zoom out further, it doesn't decode the full 8 bit 'packet' either, just the individual bits.

Bug, or am I just missing something?

DS1074Z-S 'upgraded', Software Version 00.04.03.SP1, Board Version 4.1.1.

I suspect there may be something not quite right with your decoder set up, maybe the CLK/CS/MOSI not assigned to the correct channels?

[marber]

I suspect there may be something not quite right with your decoder set up, maybe the CLK/CS/MOSI not assigned to the correct channels?

Yeah, but I checked every setting available multiple times. CLK, CS and MOSI are certainly correct.

I only started seeing this when I went to set it up for SPI mode 3, i.e. active low CLK and on rising edge - it successfully decoded packets in a SPI mode 0 setup before, with otherwise unmodified settings.

[Howardlong]

I suspect there may be something not quite right with your decoder set up, maybe the CLK/CS/MOSI not assigned to the correct channels?

Yeah, but I checked every setting available multiple times. CLK, CS and MOSI are certainly correct.

I only started seeing this when I went to set it up for SPI mode 3, i.e. active low CLK and on rising edge - it successfully decoded packets in a SPI mode 0 setup before, with otherwise unmodified settings.

See photo: I tried all four SPI modes, all OK.

[marber]

See photo: I tried all four SPI modes, all OK.

Strange. I think I'll do a factory settings reset later just to be sure, and then try to reproduce it and post the exact settings.

What firmware are you running on? Also, you're using an MSO, which I think is subtly different hardware/firmware especially in the logic analyzer / decoding department, isn't it? That may or may not make the difference as well...

[Howardlong]

See photo: I tried all four SPI modes, all OK.

Strange. I think I'll do a factory settings reset later just to be sure, and then try to reproduce it and post the exact settings.

What firmware are you running on? Also, you're using an MSO, which I think is subtly different hardware/firmware especially in the logic analyzer / decoding department, isn't it? That may or may not make the difference as well...

I'm not with the scope right now, but it's the version DS/MSO1000Z version that was released about a month or so ago that everyone's complaining about the UI response speed, ISTR 04.03.02.03. Board version 6.1.1.

There may be some differences, but I deliberately left the MSO channels off and used the same channels as you and the same settings to the extent that I could see (and guess!).

[marber]

I'm not with the scope right now, but it's the version DS/MSO1000Z version that was released about a month or so ago that everyone's complaining about the UI response speed, ISTR 04.03.02.03. Board version 6.1.1.

Right. My firmware is at least one version older - it reports as 04.03.SP1. It may already be fixed, but with people complaining about the latest version, I'll wait with upgrading.

There may be some differences, but I deliberately left the MSO channels off and used the same channels as you and the same settings to the extent that I could see (and guess!).

Before a factory reset, I decided to play a bit more first while it still has the same settings. I tracked it down to decode setting "Mode CS" vs "Mode Timeout" - in the latter it decodes correctly as a full frame, in CS mode it shows the behavior I've been seeing.

I've attached screenshots of all settings of the Decode menu.

I could understand mode CS not working as the CS line goes down outside the screen in my screenshots, and the DS1000Z won't decode outside the screen area. However if I zoom out just enough to have CS go down within the range of the screen (last screenshot, CS going down in the left behind the table) the scope still decodes individual bits as FF/7F. No longer readable on the decode trace in that zoom range, but the event table shows the same values.

I wonder if the signal quality may also have an effect (with the auto thresholds perhaps?). Obviously the signal quality is pretty bad in these captures - it's on a large breadboard going all over the place.

[Jeff5341]

I have an MSO 1104z. Nice Scope for the money. I wish they would have chosen green for the channel 2 or 4  trace. I often use all four channels, and sometimes get channels 2 and 4 (light and dark blue) mixed up when changing circuit test points. A better match of the probe color rings to the corresponding traces would be nice.

[MarkF]

I have an MSO 1104z. Nice Scope for the money. I wish they would have chosen green for the channel 2 or 4  trace. I often use all four channels, and sometimes get channels 2 and 4 (light and dark blue) mixed up when changing circuit test points. A better match of the probe color rings to the corresponding traces would be nice.

They use green for the logic analyzer channels.  But, I agree.  I would much rather they used green for channel 4 and used the dark blue (or some other color) for the logic analyzer.  I too am always getting the dark and light blue channels mixed up.

[Karel]

13) RAW mode of data acquisition over USB returns garbage, rather than the waveform.

Can you please be more specific? For example, which platform and/or software is used to test this?

For sure, RAW mode of data acquisition over USB works fine on linux!!

Please correct this.

Thank you.

[Karel]

3) The FFT function only works for channel 1.  However it will work for the other channels as long as channel 1 is turned on.

Not true, at least not with latest firmware.

There is, however, a new bug: the TMC command :MATH:SOUR1 CHAN1 or :MATH:SOUR1 CHAN2 is ignored by the scope,
so, it's impossible to select the source channel for the FFT via remote connection.

[ankerwolf]

Hello Karel,

There is, however, a new bug: the TMC command :MATH:SOUR1 CHAN1 or :MATH:SOUR1 CHAN2 is ignored by the scope,
so, it's impossible to select the source channel for the FFT via remote connection.

Test following:
  :MATH:FFT:SOUR?         // ok - entgegen S.107
  :MATH:FFT:SOUR CHAN1    // ok - entgegen S.107

LG Wolfgang

[Karel]

Hello Karel,

There is, however, a new bug: the TMC command :MATH:SOUR1 CHAN1 or :MATH:SOUR1 CHAN2 is ignored by the scope,
so, it's impossible to select the source channel for the FFT via remote connection.

Test following:
  :MATH:FFT:SOUR?         // ok - entgegen S.107
  :MATH:FFT:SOUR CHAN1    // ok - entgegen S.107

LG Wolfgang

Thanks but that doesn't work either.
And Rigol's programming guide from July 2015 says :MATH:SOUR1 CHAN1

[Karel]

I believe I found another bug.

When the FFT is activated in splitscreen and "trace" mode, when you remotely change the horizontal timebase, the string
"FFT: CH2 10.00 dBV  12.5KHz/Div 500K Sa/s" will not be updated and as a result will show wrong values.

[ankerwolf]

Hello Karel,

Thanks but that doesn't work either.
And Rigol's programming guide from July 2015 says :MATH:SOUR1 CHAN1

It does work ! Look at my Log & Picture before and after ...
I know, the Manual does say an other syntax 

Code: [Select]

*IDN?
RIGOL TECHNOLOGIES,DS1104Z,DS1ZAxxxxxxxx,00.04.03.SP2

:MATH:FFT:SOUR?
CHAN2

:MATH:FFT:SOUR CHAN1

:MATH:FFT:SOUR?
CHAN1


LG Wolfgang

[Karel]

Hello Karel,

Thanks but that doesn't work either.
And Rigol's programming guide from July 2015 says :MATH:SOUR1 CHAN1

It does work ! Look at my Log & Picture before and after ...
I know, the Manual does say an other syntax 

Code: [Select]

*IDN?
RIGOL TECHNOLOGIES,DS1104Z,DS1ZAxxxxxxxx,00.04.03.SP2

:MATH:FFT:SOUR?
CHAN2

:MATH:FFT:SOUR CHAN1

:MATH:FFT:SOUR?
CHAN1


LG Wolfgang

You are right, using telnet it works...

edit:
Found it, I tried :MATH:FFT:SOUR1 CHAN1 instead of :MATH:FFT:SOUR CHAN1

Thanks again, that was very helpfull.

[ankerwolf]

Hello Karel,

I believe I found another bug.
When the FFT is activated in splitscreen and "trace" mode, when you remotely change the horizontal timebase, the string
"FFT: CH2 10.00 dBV  12.5KHz/Div 500K Sa/s" will not be updated and as a result will show wrong values.

That is right! It ist a BUG.

But when you turn the Horizontal-Knob remotely, then it works.

Code: [Select]

:SYST:KEY:DECR HSCALE,1


[Karel]

But when you turn the Horizontal-Knob remotely, then it works.

Code: [Select]

:SYST:KEY:DECR HSCALE,1


What is this, another undocumented "feature" of Rigol? Where did you find that command?

[ankerwolf]

Hello Karel,

What is this, another undocumented "feature" of Rigol?

Yes, look here:
https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg731215/?topicseen#msg731215

LG Wolfgang

[Mechatrommer]

havent read all pages, maybe this is a repeat anyway... nothing special just some UI brought from less buggy and enjoyfull DS1052E series, i dont ask for new features, just expecting the same or better performance as what i used to (older DS1052E), namely:

1) encoders for intensity, channel position, horizontal time position, and trigger level (the four smaller knobs at the top of two bigger knobs)... the new DS1054Z knobs respond are very slow, with exception to intensity knob when used to select sub menu which is overly sensitive (super fast). the older DS1052E smaller knobs respond and speed all are about perfect, not too fast not too slow. i dont know why the later programmer want to reinvent the new speed rate from better to worse.

2) clipped signals should not be visible, just as older DS1052E, instead of confusing ceiling or bottomed horizontal (clipped) line. again, why reinvent from better to worse?

3) when we set horizontal time far from center, or trigger level far up or down... and then we set time div or V/div to smaller value, making time offset or trigger level goes out of bound, and then the scope will reset the time offset and trigger level to smaller magnitude, when we restore our previous time/div and V/div, time offset and trigger level is not what it was... older DS1052E does not exhibit this symptom, it remembers the larger offset and trigger level set by user earlier. this new DS1054Z cannot remember it (reset to nearly zero), maybe too much memory all 24Meg are used up for data capture, no space for user settings

still new with this ver 4.03 DS1054Z (modded to DS1104Z already), will search for another bugs, hopefully not much...

[Mechatrommer]

some confusion or WTF moment during an attempt to transfer data from ds1000z to my pc... i thought the label at the top is memory depth for 1 channel since enabling the other channel will half the memory, so i thought they must be shared (600 for one, 600 for the other), but it turned out to be even worst (at data dso->pc transfer at least)... rigol, cant you capture 600 pts per channel? so i can have 1.2Kpts memory for both ch1 and ch2 shared? maybe this involve hardware limitation but i'm not sure, i'm just confused with the top memory depth label... and with this shared-half-the-memory, i cant even get the whole screen capture for every channel at this particular setting (during stop mode, pictures below) ..

and this expose a really serious issue, because from extrapolation of the concept, maximum memory usage is not shared, but half-the-half like the following table: this i guess will affect decoding recording depth as well... and max no of points the off-(pc)-processing FFT can be done when multiple channels are activated...

1 channel visible: 24Mpts capture per channel
2 channel visible: 6Mpts capture per channel (12Mpts / 2)
3 channel visible: 2Mpts capture per channel (6Mpts / 3)
4 channel visible: 1.5Mpts capture per channel (6Mpts / 4)

at 4 channels visible, 24 - 6 = 18Mpts of memory are useless... how can such a design?