Rigol DS1000Z series buglist continued (latest: 00.04.04.04.03, 2019-05-30)

[rob040]

Simply rename the .01.zip to .z01 and open the .zip with any packer (WinRAR, 7zip, ...).

Yessss, that does the trick. Thanks!

[Payne]

New bug found?

Hi all,

When I do the following, something weird happens with the vertical position of the signal line:

Set VerticalRef = Center (Utility, System)
No probes connected
Set vertical sensitivity to 5V
Center the vertical line to 0V
Center the trigger point to 0V
Set vertical to -5V
Set trigger point to -5V
Now turn the vertical sensitivity knob to 2V, 1V, 500mV
When you turn to 200mV (and even lower), the trace will appear on the screen again (but it should have been close to the floor in your room!)
 
I can reproduce this error also with other settings for the Y-axes sensitivity and other channels

Rigol DS1054z
SW: 00.04.04.SP3
Board: 0.1.4

[frozenfrogz]

I can not reproduce that on my scope. The trace leaves the screen (yellow line glued to the bottom) in all Vscale settings.

Edit: Same board revision by the way, Rigloled DSER.

Boot: 0.0.1.4
FW: 0.2.3.11

[Payne]

Try to set the probe for CH1 at 1x, then it should be there!

[Fungus]

When you turn to 200mV (and even lower), the trace will appear on the screen again (but it should have been close to the floor in your room!)

You hear that click as you go to 200mV? That's a clue that the 'scope switched ranges there.

If the line is in the wrong place in those ranges it means you need to run calibration on your scope.

[frozenfrogz]

With 1x magnification it is showing the described behavior on my scope.
When using 1x and moving the trace you can only shift it +/- 2.0V in the 200mV range. I guess the ADC would be out of bounds otherwise or something...something. While you can not shift the trace more than 2V naturally in the 200mV magnification, jumping from 500mV to 200mV breaks that. I could not think of a real world application where the proposed settings are needed though.

[RoGeorge]

At the beginning, the trace is in the middle of the screen.
When setting the trace to -5V, the trace is displayed one division lower than the middle of the screen.
When scale is set to 2V, the trace is 2.4 divisions lower than the middle of the screen.
When scale is set to 1V, the trace is at the bottom of the screen.
When scale is set to 500mV, the trace is still displayed at the bottom of the screen. Is this "the bug"?

This is expected, because when the trace is supposed to be out of screen, the oscilloscope still displays the trace as a line at the most upper or lower side of the display area. For example, if you signal is "out of the screen" only some areas, you will not see an interrupted trace. The displaying of a trace is always bounded by the upper or by the lower screen area.

Other said, if a trace should be represented "1 meter under the display", the oscilloscope will still draw a continuous line at the most lower pixels of the display. It is not like on an analogue display where the trace completly dissapear when it is too high or too low. This is not a bug, it was always like that, it was debated before and many people prefer to see a line at the extremes of the display rather than seeing the trace completely disappearing.

To be sure a waveform is correct, never let the trace to touch the most upper or the most lower pixels.

[Payne]

RoGeorge, you get the problem when you set to 200mV, the trace will suddenly appear again.

Yeah, I know the problem maybe is a bit academically, but still it is strange and confusing

Actually, you can go out of the borders, and still have a nice trace, because the DS1054z works internally with 10 vertical divisions but only show/zoom into 8 divisions

[JohnPen]

I am not able to reproduce the problem on my scope. (No probe connected and X1 setting).  As mentioned by Fungus there is a relay click when changing sensitivity to the 200 mV range and the trace stays glued to the bottom of the graticule. 

Whilst typing this comment and having let the scope warm up fully I now get a different effect!  On switching to the 200 mV range the trace now reappears in the middle of the screen and then progresses positively towards the top of the graticule.  Increasing the sensitivity to 20 mV the trace glues to the top of graticule and remains there for further increases of sensitivity.

Strange that it was different from initial startup but behaviour not unreasonable for for offsets hitting the stops of the ADCs.  Presumably the F/W could have covered these extremes by covering <=200 mV ranges in the same way as 500 mV. 

If it is off the screen usually you turn the sensitivity down until you see the trace again but I suppose one could be confused under some circumstances.

[Fungus]

I can not reproduce that on my scope.settings.

Nor me.

[ebastler]

RoGeorge, you get the problem when you set to 200mV, the trace will suddenly appear again.

It has been mentioned before: For ranges of 200mV and below, the offset range is only +- 2V. As you have set a larger offset, the scope must do "something" to get back into the available operating range. Not sure what it does exactly, since I don't have the scope in front of me. Does it reset the offset to zero? In any case, not a bug.

Offset Range:
1 mV/div to 499 mV/div: ± 2 V
500 mV/div to 10 V/div: ± 100 V

https://www.batronix.com/pdf/Rigol/UserGuide/DS1000Z_UserGuide_EN.pdf,  page 17-2

EDIT: fixed the link

[ankerwolf]

Hello,
what ist the problem?
Beginning at 5V/div, open BNC, set trace to -5V >> 1 div under middle.
Changing to 2V, 1V, ...
nothing happens, the trace ist stable 1 div under middle!

LG Wolfgang

[JohnPen]

A little more detail on the display readings for <200 mV.   On my scope the 200 mV range the display shows plus 100 mV with the aforementioned -5 volt offset input.  Increasing sensitivity to 100 mV doubles on the display similarly for 50 mV the display implies reading 100 mV.  20 mV as referred to in my previous comment hits the top of the graticule correctly.  So I suppose one could get confused.  Incidentally if one has a signal on the input it reappears as well for <=200 mV but no chance of triggering.

[JohnPen]

Hi ankerwolf,

Did you Set VerticalRef = Center before doing the test?

[ankerwolf]

Hi,

Did you Set VerticalRef = Center before doing the test?

No, but now: Normal action: left and right cursor changed if out of range. That ist absolut normal.

LG

[frozenfrogz]

As already stated by ebastler, offset ranges are restricted.
From the manual you can see: 1mV/div .. 499mV/div: +/- 2V
500mV/div and above: +/- 100V

I would not consider it a bug but more of a user error though one might argue what the proper representation of "hey, that setting does not compute" could be.

[tv84]

The decrypted release notes of the new firmware Rigol DS1000Z 00.04.04.03.05 2018-05-09 is here:

https://www.eevblog.com/forum/testgear/new-firmware-ds1000z-00-04-04-03-05-2018-05-09-(2018-02-28)/msg1534916/#msg1534916

[RoGeorge]

The 1GSa/s, or the full 24Mpts memory, are possible to select only for CH2 alone (or for no channels at all ).

If CH1 alone is selected, the maximum sample rate is 500MSa/s, and the maximum memory is 12 million samples. My current SW version is 00.04.04.03.02

Is this a known bug, or I am missing something?
If it's a bug, is it still present in the latest SW v00.04.04.03.05, please?

[Karel]

The 1GSa/s, or the full 24Mpts memory, are possible to select only for CH2 alone (or for no channels at all ).

If CH1 alone is selected, the maximum sample rate is 500MSa/s, and the maximum memory is 12 million samples. My current SW version is 00.04.04.03.02

Is this a known bug, or I am missing something?
If it's a bug, is it still present in the latest SW v00.04.04.03.05, please?

It's not a bug. I can select 1GSa/s or 24Mpts with whatever channel I select (as long as there's only one channel active ofcourse).

[BravoV]

It's not a bug. I can select 1GSa/s or 24Mpts with whatever channel I select (as long as there's only one channel active ofcourse).

+1 , same here at my DS1104Z-S.

[JohnPen]

If you select any single channel, no inputs, and with triggering set for that same channel you get the full 1GSa/s and 24M Mem depth available.  Move just the trigger source to a different channel (not enabled/displayed) and the sample rate changes to 500 MSa/s and 12M Mem depth.  So both previous comments are correct.  if you enable CH1 or (2) and Ch3 or (4) together and trigger off either of those live channels you get 500 MSa/s and 12M Mem depth as expected.  However if you select the trigger to be either of the disabled channels the sample rate drops to 256 MSa/s and 6M Mem depth.  So I suppose it could be a bug but then why would you trigger off a waveform/trace you are not displaying?

[metrologist]

You may want to use a channel for triggering but not care to see the triggering signal. You are still using the channel, just not displaying the data.

[RoGeorge]

If you select any single channel, no inputs, and with triggering set for that same channel you get the full 1GSa/s and 24M Mem depth available.

That was it, the trigger source must be on the same channel (or on AC Line). Didn't know that.

I noticed that the trigger still works even when set on a disabled channel, so it might be useful to trigger on a rare event from another channel, then sample a different signal with full 24 Mpoints, but I wouldn't call that a bug. I think that was a design choice. In my case it just happened that my trigger was left on CH2 from some previous measurements. My bad, sorry.

Thank you all for taking the time to test this.

[JohnPi]

I have a new bug (I posted this as a separate topic earlier; I'll try to delete that post):
I am trying to read binary waveforms from my 1054Z using pyvisa over USB. Using sockets over LAN (not pyvisa) works. I have a problem when reading certain specific lengths of data from the instrument -- specifically lengths of 8244 and increments of 64 beyond; using MDEPTH of 30000. I don't know if the issue is in the instrument or pyvisa. I have filed a ticket at https://github.com/pyvisa/pyvisa/issues/354 also. I have tried pyvisa 1.9.1, 1.9.0 & 1.8. My 1054Z is unlocked to 1104Z. This is the *IDN? RIGOL TECHNOLOGIES,DS1104Z,DS1ZA20100****,00.04.04.SP3

If anyone has the same setup, perhaps with different software/firmware versions, I would appreciate if you could run this example and report:

Code: [Select]

import visa
import numpy as np
import sys
import re

print(sys.version)
print("visa", visa.__version__)
#visa.log_to_screen()

GPIB = visa.ResourceManager()
GPIB_Resources = GPIB.list_resources()
for resource in GPIB.list_resources(): print(resource) # list instruments -- selects the 1054Z in the next line
DS1054Z = GPIB.open_resource([_ for _ in GPIB_Resources if re.search('^USB.*:DS.*INSTR$', _)][0])
print("DS1054Z:", DS1054Z.query("*IDN?"))

DS1054Z.write(":WAV:FORMAT BYTE;:WAV:MODE RAW;:SYSTEM:BEEPER OFF")
DS1054Z.write(":ACQUIRE:MDEPTH 30000")
DS1054Z.write(":STOP")
err=0

#for NPOINTS in range(20010,30100):
for NPOINTS in range(8200,30100):# fails at 8244 and increments of 64 beyond
  print(NPOINTS, end='')
  err+=1 
  DS1054Z.write(":WAV:START 1;:WAV:STOP %i;:WAV:DATA?" % NPOINTS)
  print(">",DS1054Z.read_bytes(11),"<", end='') # Contains '#90000ddddd'
  try:
    CURVE1 = np.frombuffer(DS1054Z.read_bytes(NPOINTS), dtype='b')
  except:
    print("\nError at", NPOINTS, " after ", err)
    err=0
  print(len(CURVE1), "chars")
  DS1054Z.read_bytes(1) # trailing '\n'

This tests reading lengths from 8200 on in increments of 1. I see fails like this:

Code: [Select]

8241> b'#9000008241' <8241 chars
8242> b'#9000008242' <8242 chars
8243> b'#9000008243' <8243 chars
8244> b'#9000008244' <
Error at 8244  after  8243
8243 chars
8245> b'#9000008245' <8245 chars
8246> b'#9000008246' <8246 chars
8247> b'#9000008247' <8247 chars
and filtered, the patterns looks like:

Code: [Select]

Error at 8244  after  8243
Error at 8308  after  64
Error at 8372  after  64
Error at 8436  after  64
Error at 8500  after  64
Error at 8564  after  64
Error at 8628  after  64
Error at 8756  after  128
Error at 8820  after  64
Error at 8884  after  64
Error at 8948  after  64
Error at 9012  after  64
Error at 9076  after  64
Error at 9140  after  64
Error at 9268  after  128
Error at 9332  after  64
Error at 9396  after  64
Has anyone seen anything similar to this ?

[Karel]

I have a new bug (I posted this as a separate topic earlier; I'll try to delete that post):
I am trying to read binary waveforms from my 1054Z using pyvisa over USB. Using sockets over LAN (not pyvisa) works. I have a problem when reading certain specific lengths of data from the instrument -- specifically lengths of 8244 and increments of 64 beyond; using MDEPTH of 30000. I don't know if the issue is in the instrument or pyvisa. I have filed a ticket at https://github.com/pyvisa/pyvisa/issues/354 also. I have tried pyvisa 1.9.1, 1.9.0 & 1.8. My 1054Z is unlocked to 1104Z. This is the *IDN? RIGOL TECHNOLOGIES,DS1104Z,DS1ZA20100****,00.04.04.SP3

Are you claiming that you have found a new bug in the scope's firmware?
I'm asking because DSRemote seems to work fine when downloading binary waveforms via USB.