EEVblog Electronics Community Forum

Products => Test Equipment => Topic started by: frozenfrogz on April 12, 2017, 08:53:13 am

Title: Rigol DS1000Z series buglist continued (latest: 00.04.04.04.03, 2019-05-30)
Post by: frozenfrogz on April 12, 2017, 08:53:13 am
Disclaimer

This is the straightly bug related thread. If you find something that needs to be reported or double checked feel free to post here.
For all other general discussion please stick to THIS THREAD (https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/) (please read the first post to get some overview, thanks to the OP rolycat :) ).

Disclaimer

Because the original posting from kwass (https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/) can no longer be maintained by Katie, the original poster, we were talking about how to keep things going.

Updates on bug reports for current software version 00.04.04.04.03 onward will be bundled here. Please drop a comment, or PM in case you run into an issue with the latest firmware.
If you find new issues, please supply a description of how to reproduce the bug - together with detailed device information.
Please provide: Software Version, Board Version, Boot Version, Firmware Version
Pressing MENU, MENU, FORCE, MENU, Utility, (soft button) System, (soft button) System Info quickly one after the other will get you there.

Direct download link to latest release: V.00.04.04.04.03  (https://beyondmeasure.rigoltech.com/acton/attachment/1579/f-0576/1/-/-/-/-/DS1000Zver_04.04.04.03.zip)
Direct download link to last release that also contained boot version update file: V.00.04.00.00.00  (http://gotroot.ca/rigol/DS1000Z-04_00_00_00.7z)

Check this link (https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/) for a plethora of information made possible due to the efforts of »konnor« and a couple of people on the forums.

I took the list formerly maintained by Katie and re-checked what I could on my DS1054Z, Board Version: 0.1.4, Boot Version: 0.0.1.4, Firmware Version: 0.2.3.11


The following bugs seem to be fixed in the latest firmware:

Recommended update procedure
Forgot to mention, before doing the upgrade, I did the memory "sanitation"* 1st as Rigol document stated, just want to make sure its like fresh from factory, which are :
  • Clear the internal volatile memory: Buttons pressed = STORAGE > DISK MANAGE > FLASH ERASE
  • Restore Power of Setup to "Default": Buttons pressed = UTILITY > SYSTEM > POWER SET = Default
  • Power off the unit.
  • Power on, insert the "blank" USB flash drive, to check whether it recognizes the USB first.
      (PS: "blank" means a freshly formatted 8GB FAT32 with 4K allocation and without any file on it as it is freshly formatted.)
  • Unplug the flash drive, copy "only" the single .GEL file from your computer to the root directory.
  • Plug the flash drive into the unit, new firmware should instantly be recognized, proceeded with update.
  • After successful update, hard-cycle reboot unit.
  • Perform self calibration routine.
*see also pdf file provided by ted572 appended below


Bugs remaining or not tested by me, please review when you were affected and could reproduce it on previous releases:
Release notes supplied by Rigol
Code: [Select]
[Supported Model]    All the MSO/DS1000Z Series Digital Oscilloscopes
[Latest Revision Date]  2015/05/30

[Updated Contents]
--------------------

[History]
-------------
v00.04.04.04.03  2019/05/30
     - Fixed the wave error when STOP and changing timebase

v00.04.04.04.02  2019/02/26
     - Add new encoder drivers

v00.04.04.03.05  2018/04/28
     - Fixed the login bug of lxi-web
     - Fixed the bug of average measure
     - Fixed the bug of information display

v00.04.04.03.02  2017/02/06
     - Improved the LXI module
     - Fixed the freeze problem when upgrading based on the boot version of 0.0.0.13
     - Improved the menu in the language of Traditional Chinese and Korean
     - Modified the failure when downloading waveform to the source module
     - Fixed bugs about reading the memory data through SCPI commands
     - Fixed bugs about Measure
     - Fixed bugs about Filter

v00.04.04.01.01  2016/09/14
     - Supported the multi-inteface of LXI
     - Fixed bugs about Measure

v00.04.04.00.07  2016/07/19
     - Added the full-screen display in the XY mode
     - Modified the Trace data of average sample mode
     - Fixed the bug of system halted for wave persistence in the Zoom mode
     - Fixed bugs about Measure

v00.04.03.02.03   2015/10/20
     - Added commands concerning the type and format of the image
     - Added four measurement items (+Pulses, -Pulses, +Edges, -Edges) and related commands
     - Added commands concerning the digital filter
     - Added more information to the last setting
     - Fixed option installation
     - Fixed Intg operation

v00.04.03.01.05   2015/06/16
     - Added French in system language
     - Added the mutual communication with DG4000 Series
     - Added the digital filter
     - Supported using memory data to carry out FFT operation
     - Supported invert and format setting when reading a image remotely
     - Fixed bugs when the data of the digital channel is saved in the CSV format

v00.04.03.00.01   2015/05/05
     - Added DS1104Z Plus and DS1074Z Plus
     - Fixed pass/fail test
     - Fixed FFT operation

v00.04.02.04.07   2014/12/31
     - Fixed triggering function
     - Fixed storage function
     - Fixed bugs of jitter in the signal under the AC or low-frequency coupling

v00.04.02.03.00   2014/10/21
     - Added commands concerning remote reading and download of pass/fail test rules
     - Improved the command set for decoding and waveform recording
     - Fixed bugs in RS232 decoding
 
v00.04.01.02.00   2014/07/28
     - Added traditional Chinese language for the measurement menu
     - Optimized the event table display
     - Pressed and held [Measure] to remove all the measurement items
     - Added hardware version number to the displayed system information
     - Fixed bugs in storage function
     - Fixed bugs in the Undo operation for AUTO
     - Fixed bugs in signal source function
 
v00.04.00.00.00   2014/03/18
     - Added remote reading of LA waveform data
     - Added commands concerning the measurement of MATH waveform
     - Optimized the prompt message of LA probe calibration
     - Fixed bugs in triggering function

v00.02.03.05.00   2014/01/27
     - Added the command set for the keypad
     - Added multiple system languages
     - Optimize the prompt message of LA probe calibration
     - Fixed bugs in frequency counter
     - Fixed bugs in storage
     - Fixed the crash problem when formatting U disk in NTFS format

v00.02.01.01.00   2013/10/31
     - Added measurement history function
     - Added the setting for measurement range 
     - Adjusted the priority order of the remote interface
     - Realized the seamless integration of digital oscilloscope and the signal generator
     - Optimized trigger state display
     - Fixed bugs in horizontal scale

v00.02.00.01.00   2013/09/02
     - Optimized the brightness of waveform display
     - Optimized the waiting time for the slow sweep mode
 
v00.01.00.16.09   2013/08/14
     - Supported the remote access to memory data
 
v00.01.00.13.09   2013/ 07/ 25
     - Added the export function of deep memory waveform data
     - Added the delay calibration function for the channel
     - Optimized the persistence time of waveform display
     - Fixed bugs in slow sweep

v00.01.00.12.08   2013/07/10
     - Optimized the USB Device interface communication
     - Fixed bugs in print function
     - Modified the abnormal trigger level line after the AUTO operation

v00.01.00.03.00   2013/05/21
     - Fixed bugs for the expiration of the trial options

v00.01.00.02.00   2013/05/19
     - Added the display interface of the installed option

v00.01.00.00.05   2013/05/19
     - Released the first edition


Please feel free to confirm, or mark as solved from the above list. All new issues and bugs belong in this thread and will be maintained in the opening post by me.

Regards and happy testing,
Frederik


Latest changes
Updated firmware link to latest 00.04.04.04.03
Added link to Pluses corrected version
Started updating the post for FW 00.04.04.03.05
Minor maintenance, release notes fixed / formatting
Added ADC gain / display mismatch bug
Added SCPI command bug
Small follow up on calibration fail after update
Disclaimer regarding general discussion thread
Added remote command frame size bug
Added more information on USB packet bug
Appended PDF file with memory wipe instructions
Added recommended update procedure
Updated info on calibration fail
Appended device to freeze bug (#5) table
Added link and info on boot version
Typos and formatting
Added download link to latest software file
Added saving to USB takes incredibly long bug
Added possible bricking bug
Reformated buglist as ordered list (as proposed by metrologist)
Title: Re: Rigol DS1000Z series buglist continued (from: FW 00.04.04.03.02)
Post by: frozenfrogz on April 12, 2017, 08:56:47 am
Here's my attempt to catalog the bugs and wish list items for the Rigol DS1000Z oscilloscopes.   This should apply to the regular and -s versions, but may not apply to the MSO versions)  I'll try to modify this top post as people add their found bugs and wish list items.  Hopefully Rigol will see this thread and respond to it.

This list is for software version: 00.04.02 and 00.04.03  only, with the current hardware (possibly only board 0.1.1).


Rigol fixed the following bugs (according to their documentation between 4.02 and 4.03):

  • Modified the method of key board test and screen test and optimized processing speed.
  • The display of keyboard lights and the show of menu was wrong while switch the timebase mode between YT and ROLL in the Normal trigger mode.
  • The saved data of REF waveform was wrong while STOP the system then open the channel.
  • The output of AUX was wrong while the function of Pass/Fail was closed.
  • The display of LA signal was wrong while adjust the delay calibration of LA signal.
  • The position of LA wave and label of LA channel was wrong while load the file of LA waveform then RUN the system.
  • The wave of channel1 can not be displayed while open the scan mode then switch the channel2 over and over again.
  • The position of LA wave was wrong while load the file of LA waveform before change the position of the LA channel.
  • The memory data of LA channel was wrong when use the remote command to read.
  • Save the CSV file failed while the system stopped.
  • Fixed the bug of unlocked the key board failure when save the file.



Bugs:

1) The new Large and Extra Large measurement fonts are nice, but they are reset to Normal on each power cycle.  This should be retained like all the measurement settings are.

2) The Select Item sub-menu on the Measurement menu has 5 check boxes implying that it should be useable for Normal font too, but it's grayed out.  The only way to remove a measurement from the screen using Normal font is a power off/on cycle.

One member has already suggested that the left side menu as a series of on/off toggles as the means for including/removing the measurement.  This in conjunction with the Select Item sub-menu (which could turn on/off the display position of an item) might give maximum flexibility and ease of use.

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.  It's actually more complicated than that for more details see this thread: https://www.eevblog.com/forum/testgear/another-rigol-1000z-bug/msg568478/#msg568478 (https://www.eevblog.com/forum/testgear/another-rigol-1000z-bug/msg568478/#msg568478)

Also, the FFT cdisplay shows bad aliasing under most circumstances.  See this thread for more details: https://www.eevblog.com/forum/testgear/rigol-ds1054z-fft-bug%28s%29/ (https://www.eevblog.com/forum/testgear/rigol-ds1054z-fft-bug%28s%29/)

4) The Large and Extra Large fonts cover up items that display at the bottom of the screen.  For example the brightness indicator and the math equation. 

5) Some users have reported that the zero line of the trace is not perfectly centered after doing a calibration.  This is not an issue on all units, however, so might be more of a hardware variability item.  Users expect that all traces along with their channel number indicator should perfectly centered on the display (on top of each other) after a calibration.

(See this post for some post-calibration screen shots:  https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-%28ds1054z-ds1074z-ds1104z-and-s-models%29-bugswish-list/msg584977/#msg584977 (https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-%28ds1054z-ds1074z-ds1104z-and-s-models%29-bugswish-list/msg584977/#msg584977))

If it's not possible for the calibration routine to automatically do this, maybe allow the user to manually set the channel offset at the exact center and save that value until the next calibration.

6) Writing full memory to a CSV file takes an extremely long time.  Write speeds seem to be about 0.15 MB/sec instead of the expected 10MB/sec or so.

7) When show measurements from the MATH trace the units don't match to the units selected (or computed) in the MATH function.  For example:  Ch 1= Volts, Ch 2=Amps, Math= Ch1 x Ch2 will show Watts on the trace but MATH measurements will show Volts, instead of correctly showing Watts.

8 ) The 20M Bandwidth Limit setting for each channel is not saved, it resets of OFF each power cycle.

9) If the following settings are used:

  Input signal: probe compensation 1kHz square wave from the scope
  Trigger: DC / CH1 / 1.5V
  Aquisition: High Res / 120k mem. depth
  Horizontal position: 0ps
  Horizontal scale: 50us/div

  The scope will display the waveform shifted by around 75us.    See details in this picture:

(https://www.eevblog.com/forum/testgear/ds1054z-bug-(with-poll)/?action=dlattach;attach=153347)

10) Some users have reported scope lock ups when setting memory depth to AUTO, timebase to 1us, zooming in and changing the persistence from MIN something else. Apparently not all users experience this problem but those that do can reproduce it every time.  See this thread for much more detail: https://www.eevblog.com/forum/testgear/rigol-ds1054z-freeze-up-bug/ (https://www.eevblog.com/forum/testgear/rigol-ds1054z-freeze-up-bug/)

11) Remote I/O menu will not allow selection of LAN if USB is ON.  You need to unplug the USB device first.

12) Inside the CSV file, the scope stores the "increment", in the memory dumps that increment is 25X longer than it should be to correctly represent the expected sampling period.  For example: if the increment is 10us, one has to set the time increment to 400ns (2.5MSPS) in order to get the correct plot of data.

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


Wish List Items:

A) Full screen X-Y mode, the current display is tiny.  Also, allow screen persistence to be set in X-Y mode.

B) Decoders should allow DATASRC to be either Trace or Memory.  This is documented in the manual but apparently only Trace is implemented, so this might be a bug.  Even the SCREEN option could be improved so that decoding starts at a start-bit not at the left edge of the screen.

C) When displaying a math function allow the underlying channels to be hidden.

D) Compress and move the waveform to the bottom of the screen when Measure All is on as is done, optionally, for FFT display.  Also for measurement history.

E) Allow Measure All to be selected in the AUTO options menu.

F) Allow the user to hide the left and right side menus.  Also the left side menu is often irrelevant and that screen space could be used for other display items.

G) When selecting a channel, show some corresponding channel color around the settings instead of having everything in just white.  Maybe just change the color of the tiny CH1, CH2, CH3, CH4 label next to the Coupling setting.

H) Use a larger font for the popup keyboard.

I) Save the last few file names in the Storage menu for faster access.  Maybe use the left side menu for this?  Alternatively, just remember the last file name entered and allow the user to increment any trailing digits.  So TEST0001 would go to TEST0002 automatically (or will a key press).

J) Allow the trace Display Persistence Time to be turned off -- instead of just MIN.  The scope would then just show each waveform as it's captured and blank the display before showing the next.  Even the MIN persistence level can hide some detail.

K) Allow larger fonts for certain items.  For example:  timebase, trigger level and channel gain (volts/div).  Also use a larger icon showing the coupling (DC/AC/GND) next to the channel gain.

L) Use a different color for the math trace, something that stands out better, maybe red?

M) Allow the user to select a color for the A and B cursors, individually.  Currently they are distinguished by a solid and dotted line both in white.

N) Allow for selectable FFT size (number of points: 128, 256, 512, 1024) calculation -- ie, trade off speed for accuracy.

O) Show the trigger type and coupling method (DC/AC/LFR/HFR) next to the trigger type icon in the upper right corner.

P) Consider moving the selection of the trigger coupling method to the top-level trigger menu instead of the Setting sub-menu.  Same for the Holdoff.

Q) Allow for variable high and low pass filtering for each channel, as was done in the earlier 1000 series scopes.

R) Add boxes for Math and Ref to the bottom bar alongside the channel info.  Color coding them and added relevant info such as gain or offset offset voltage.

S) Allow for a simple screen title.  Maybe allow more text to be added via a PC connection, perhaps a query that could be responded to with a key press on the scope.

T) Hardware frequency counter shows "<15Hz" when the STOP button is pressed even though it had been showing a valid value.  It would be best to freeze this value like other measurements are.

U) Ability to save a Recorded data to USB drive.

V) Consider checking the way the menu system works, as follows:

Push a soft menu button to open a menu, push the same button again to close the menu.
When a menu is open you can use the light blue up/down arrows to select an item in the menu, or use the multifunction knob if you prefer that.  When you have the correct item highlighted in the menu, push the soft menu button again to select the item and close the menu (or push the multifunction knob if you prefer).

W) Change file file numbering scheme so that instead of using the first available file number simply use a sequential number (stored in persistent memory) until reset by the user.

X) Use a meaningful amount of decimals in the horizontal position display (e.g. '0.00000000 ps' should be something like 0.0 ns since the smallest step size is 0.1ns)

Y) Have the FFT function compute an average if the channel it's set to is set to "average" in Acquire menu.  Other single-argument math functions seem to do this.

Z) Allow a push of the trigger level control to set the trigger level at the 50% level or at the 0% level - as it currently does.

AA) Improve the response of the vertical and horizontal position movements, they have quite a bit of lag.

AB) It would be helpful to be able to see the on-screen ASCII table when setting up an RS-232 trigger.

AC) Add (wired/wireless) USB keyboard support for navigating menus and character input.

AD) Add a menu option to allow the user to set the offset voltage (or whatever the current units are).  This is in addition to the normal offset control knob.

AE) Allow MATH to be used in the X-Y mode.  This means that instead of 6 options of what to display there would be 20 options (so that MATH can be either X or Y).
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 12, 2017, 09:27:22 am
I could not reproduce the waveform shifting bug in the latest firmware.
Please confirm.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: BravoV on April 12, 2017, 10:07:19 am
Subbed
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Gabri74 on April 12, 2017, 10:35:00 am
I could not reproduce the waveform shifting bug in the latest firmware.
Please confirm.

Confirmed, bug seems gone  :-+

Software Version: 00.04.04.03.02
Board Version: 0.1.1
Boot Version: 0.0.1.2
Firmware Version: 0.2.3.11
CPLD Version: 1.1
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on April 12, 2017, 10:39:25 am
There's a bug missing in your list: https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg1178649/#msg1178649 (https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg1178649/#msg1178649)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on April 12, 2017, 10:41:35 am
7) RAW mode of data acquisition over USB returns garbage, rather than the waveform.

(Not tested)

I tested it and it works fine. Please remove it from the list of bugs.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 12, 2017, 11:25:55 am
Done.

And finally figured out how to escape BBcode to get 8) instead of 8)

*yay*

Also: I found the language menu to hold a lot of languages now. As far as I remember it was only chinese and english before. Or am I mistaken?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on April 12, 2017, 11:51:30 am
Also: I found the language menu to hold a lot of languages now. As far as I remember it was only chinese and english before. Or am I mistaken?

Yes.  :popcorn:

I don't know if there are any new ones in this release but there were definitely more than that.

Release notes say French was added in 2015.

Quote
v00.04.03.01.05   2015/06/16
     - Added French in system language
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 12, 2017, 12:09:30 pm
Strange. I could have sworn that when I first got my scope (00.04.03.xx software) it only showed two options. But then again I could easily confuse it with something totally different.  :-//
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: kcbrown on April 12, 2017, 03:21:08 pm
4) Some users have reported scope lock ups when setting memory depth to AUTO, timebase to 1us, zooming in and changing the persistence from MIN something else. Apparently not all users experience this problem but those that do can reproduce it every time.  See this thread for much more detail: https://www.eevblog.com/forum/testgear/rigol-ds1054z-freeze-up-bug/ (https://www.eevblog.com/forum/testgear/rigol-ds1054z-freeze-up-bug/)

(Could not be reproduced by me, please check if your unit was affected)

I'm able to consistently reproduce this with my unit with the current firmware.

Software version: 00.04.04.03.02
Board version: 0.1.1
Boot version: 0.0.1.2
Firmware Version: 0.2.3.11
CPLD Version: 1.1

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 12, 2017, 03:27:20 pm
That is unfortunate  :(
Thanks for testing and sharing.

Added Pass/Fail info on bug list.
Title: Re: Rigol DS1000Z series buglist continued (from: FW 00.04.04.03.02)
Post by: Fennec on April 12, 2017, 03:46:45 pm
9) If the following settings are used:

  Input signal: probe compensation 1kHz square wave from the scope
  Trigger: DC / CH1 / 1.5V
  Aquisition: High Res / 120k mem. depth
  Horizontal position: 0ps
  Horizontal scale: 50us/div

  The scope will display the waveform shifted by around 75us.    See details in this picture:

(https://www.eevblog.com/forum/testgear/ds1054z-bug-(with-poll)/?action=dlattach;attach=153347)

Works. But:

PNG screenshot with thumb-drive and printer button takes 2 1/2 MINUTES !

Cannel Mark out of Range. So the scope measures 2.8Vpp but the signal is 3Vpp. (checked with 2 other scopes too.) Fluke 8842A => 1,492Vp

With this settings I can change the persist time to anything I want, the scope still freeze. So I have to turn it off (Power cycle and soft-button-reset) to make it usable again. ALL settings gone. Calibration too.

Since the last 3 updates the scope is still very very slow.   
Title: Re: Rigol DS1000Z series buglist continued (from: FW 00.04.04.03.02)
Post by: kcbrown on April 12, 2017, 03:53:15 pm
With this settings I change the persist time to anything the scope still freeze. So I have to turn it off (Power cycle and soft-button-reset) to make it usable again. ALL settings gone. Calibration too.

What I've found is that power cycling the scope is sufficient to restore functionality, because the scope restores every setting except the one that caused it to lock up, which suggests to me that (at least in my case) the scope is locking up before it gets a chance to save the last setting change.

Did you try a plain power cycle before doing a soft button reset?

Also, what are the versions of the various things (CPLD, firmware, board, boot) on your scope?   Note that to get that detailed information, you need to first quickly hit, in the trigger area, MENU MENU FORCE MENU, and then you can go to Utility -> System -> System Info to get the details.
Title: Re: Rigol DS1000Z series buglist continued (from: FW 00.04.04.03.02)
Post by: Fennec on April 12, 2017, 03:56:43 pm
Did you try a plain power cycle before doing a soft button reset?
Yepp, but most times it wouldn't work. I have to do a full reset, with the soft button. Maybe 8 of 10 times.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: 2N3055 on April 12, 2017, 03:57:18 pm
4) Some users have reported scope lock ups when setting memory depth to AUTO, timebase to 1us, zooming in and changing the persistence from MIN something else. Apparently not all users experience this problem but those that do can reproduce it every time.  See this thread for much more detail: https://www.eevblog.com/forum/testgear/rigol-ds1054z-freeze-up-bug/ (https://www.eevblog.com/forum/testgear/rigol-ds1054z-freeze-up-bug/)

(Could not be reproduced by me, please check if your unit was affected)


Cannot reproduce. Tried several times, different zoom, different persistence...
Scope detail info attached:
Title: Re: Rigol DS1000Z series buglist continued (from: FW 00.04.04.03.02)
Post by: kcbrown on April 12, 2017, 03:58:14 pm
Did you try a plain power cycle before doing a soft button reset?
Yepp, but most times it wouldn't work. I have to do a full reset, with the soft button. Maybe 8 of 10 times.

Hmm...interesting.  I didn't reproduce the issue quite that many times, perhaps four.  But in each case, a power cycle was sufficient to restore functionality.

What are the versions of the various things (CPLD, firmware, board, boot) on your scope?   Note that to get that detailed information, you need to first quickly hit, in the trigger area, MENU MENU FORCE MENU, and then you can go to Utility -> System -> System Info to get the details.
Title: Re: Rigol DS1000Z series buglist continued (from: FW 00.04.04.03.02)
Post by: 2N3055 on April 12, 2017, 04:07:53 pm
9) If the following settings are used:

  Input signal: probe compensation 1kHz square wave from the scope
  Trigger: DC / CH1 / 1.5V
  Aquisition: High Res / 120k mem. depth
  Horizontal position: 0ps
  Horizontal scale: 50us/div

  The scope will display the waveform shifted by around 75us.    See details in this picture:

(https://www.eevblog.com/forum/testgear/ds1054z-bug-(with-poll)/?action=dlattach;attach=153347)

Works. But:

PNG screenshot with thumb-drive and printer button takes 2 1/2 MINUTES !

Cannel Mark out of Range

With this settings I can change the persist time to anything I want, the scope still freeze. So I have to turn it off (Power cycle and soft-button-reset) to make it usable again. ALL settings gone. Calibration too.

Since the last 3 updates the scope is still very very slow.

Just tried that too. Doesn't happen either.  No shift, saves normally, maybe 6-8 seconds.. It does, however, save a bit faster (4-5 sec) if you stop acquisition.
It seems to me that it does behave differently on different batches. Maybe board rev, bootloader.. I don't know.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on April 12, 2017, 06:23:09 pm
Thanks for creating the new thread, frozenfrogz. Following.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: metrologist on April 12, 2017, 07:20:52 pm
Mee two. I was wondering if you would use an ordered list for the bug list? It's just marginally easier to parse, but a heck of a lot harder to maintain and edit.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 12, 2017, 08:12:09 pm
I was wondering if you would use an ordered list for the bug list? It's just marginally easier to parse, but a heck of a lot harder to maintain and edit.

Tried to do some proper formatting, could not find a BBcode option to do an indent / tab stop that seems to work here, so for the moment it’s lists within lists :-/O

@Fennec:

Please provide your long system info, thanks :)

Also, it seems that some of the wish list items have been implemented in the recent software release. However, I do not really know how to synchronize with the wish list. I could dedicate my second post (with the quoted original post from the old thread) to be the place for wish list items in the future, but am not shure about that right now. A second thread just for the wish list seems a little misplaced IMO.
What do you think?

Regards,
Frederik
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fennec on April 12, 2017, 08:41:48 pm
Please provide your long system info, thanks :)

I post nothing. Since my last RESET my scope is complete ded. It boots up with this screen.



Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ankerwolf on April 12, 2017, 08:42:06 pm
Hello,
I made update now on my DS1054Z (with Options now DS1104Z):
SW: 00.04.04.03.02 = 00.04.04.SP3
Board: 0.1.1
Boot: 0.0.1.3
FW: 0.2.3.11
CPLD: 1.1

Warm up >30'
Update ok > Power off > Power on
1. SelfCal (I seem to recall there were two more SoftButtons: [... LF ...] and [... Output ...]  ) >>> FAILED !!!
Same screen as Fennec !!!
> Power off > Power on
2. SelfCal (now only two SoftButtons) > ok.

LG Wolf
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 12, 2017, 08:48:07 pm
I post nothing. Since my last RESET my scope is complete ded. It boots up with this screen.

Damn.

Did you try deep cycle / alternative reset?
PDF from Rigol on alternate reset (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-02f4/1/-/-/-/-/file.pdf)

Also there is a memory clearing procedure:
PDF from Rigol on sanitizing memory (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-067a/1/-/-/-/-/Sanitize%20DS1000Z%20memory.pdf)

Good luck!
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fennec on April 12, 2017, 09:04:35 pm
Telnet still work. I check it tomorrow.
All knobs around the screen are ded. So Start or Exit wouldn't work. The screenshot takes a li'll less than 30 MIN. !

Never never again I buy those cheap crap from Rigol !

hf
"Pluses"

Thx for the PDF btw.


Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on April 13, 2017, 04:17:58 am
Never never again I buy those cheap crap from Rigol !

hf
"Pluses"

Yes, there are some minuses. :-DD :horse:

Maybe if I sell some more of my stuff I can get a Keysight. But for now the Rigol does what I need it to. Hope you get yours running again.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ebastler on April 13, 2017, 05:50:04 am
Did you try deep cycle / alternative reset?
PDF from Rigol on alternate reset (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-02f4/1/-/-/-/-/file.pdf)
Do we know whether this applies to the DS1000Z series as well? The tech note only refers to the DS2000 series and up.

Also there is a memory clearing procedure:
PDF from Rigol on sanitizing memory (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-067a/1/-/-/-/-/Sanitize%20DS1000Z%20memory.pdf)
The recommendation to disable the "recall last setup after power-up" option makes sense; maybe this can avoid the freeze upon startup which Fennec experiences. As the buttons are all locked up -- can the UTILITY > SYSTEM > POWER SET > Default setting be achieved via a Telnet command?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: alsetalokin4017 on April 13, 2017, 06:10:53 am
Did you try deep cycle / alternative reset?
PDF from Rigol on alternate reset (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-02f4/1/-/-/-/-/file.pdf)
Do we know whether this applies to the DS1000Z series as well? The tech note only refers to the DS2000 series and up.
Yes, but there aren't as many buttons so you have to count up from the bottom rather than down from the top. See the image below.
Quote

Also there is a memory clearing procedure:
PDF from Rigol on sanitizing memory (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-067a/1/-/-/-/-/Sanitize%20DS1000Z%20memory.pdf)
The recommendation to disable the "recall last setup after power-up" option makes sense; maybe this can avoid the freeze upon startup which Fennec experiences. As the buttons are all locked up -- can the UTILITY > SYSTEM > POWER SET > Default setting be achieved via a Telnet command?

I don't think so, at least I can't find anything in the Programming Manual, but there have been undocumented commands come up before now. You can Calibrate and stop Calibration via telnet though.

But if the above "alternative reset"  procedure works (it always has for me)  it resets everything to factory default anyway and this should turn "power set" back to where it doesn't remember the last setup and boots to the Default setup. It also resets language to Chinese! But the first thing you can do is set your own language if it isn't Chinese.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fennec on April 13, 2017, 12:42:03 pm
Easy way.
I made a new thumb-drive with the firmware, pluged it in and start the scope. And viola, the screen doesn't show the calibration failure screen anymore and want do a firmware update. NOW the buttons working. I have no idea what happens yesterday.

Startup reset wouldn't work. If I tried this, it beeps a few times, than the beeper wouldn't stop and ALL the grey buttons are dead, no way to stop it.

The issues, a few posts up, are still there.

But for now the Rigol does what I need it to. Hope you get yours running again.

It is NOT the scope, its RIGOL!
If I know the issues I can deal with it, because it is cheap and functional. BUT RIGOL knows all the listed bugs we found here over the years and they still didn't fix them? Why? 
The older Scopes has some hardware failures. OKAY, can I deal with, but why the heck RIGOL says nothing about this problem?  Only one set in the Doku, maybe "Hardware Vers. 1.1.2 freeze bug can't be fixed" and all is fine. But no, there's no comment about some bugs anywhere and RIGOL loughing, jumps around and sell more and more of this not fixable crap without any comment. High five RIGOL!
Maybe two years ago, this RIGOL member here says they have no Vers. 1.1.2 to test the bugs. Wanna kidding me ?!

If RIGOL wanna play fair, they should upload the schematics for the old and the new hardware, a hex dump from the chips, so we have a chance (maybe) to fix our scopes himself.
I have no idea why all the schematics today set to cosmic top secret. Normal a schematic should be in the instruction manual. For me a shematic is a "must have".
Maybe they are afraid someone is rebuilding it on a breadboard and sell it as original with CE on the back.

The RIGOL Service is my problem , not the scope itself.

Not the "Pluses" is a joke, the whole service is a joke. So I don't buy RIGOL anymore and good. Learned my lesson.

*Exsample Fluke. I send in a 30 years old Fluke 8840A for calibration. One Knob wouldn't work sometimes, not a real deal. It comes back with a complete new Front, new Knobs and a Letter "Thank you for using our Service". So what should I say ?!
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 13, 2017, 12:47:56 pm
On the positive side: I am glad you could revive your scope via reinstalling the firmware again.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fennec on April 13, 2017, 01:08:07 pm
On the positive side: I am glad you could revive your scope via reinstalling the firmware again.

Yepp, hope the new owner is happy with the scope. I don't like use it anymore.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 13, 2017, 01:18:17 pm
I totally understand your frustration. Could you please post the board/boot/fw version of the scope so I can put it in the buglist? Might be a good thing for others to not crash into that same wall as you did.

Thank you :)

FYI:
Just had a talk with someone at Rigol EU here in Germany and on Tuesday 18th the technician in charge of handling bug reports is back in office. I am going to call to talk about the buglist and some other things. Don’t know what will happen, but you never know :)
Will keep you posted.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fennec on April 13, 2017, 01:57:04 pm
There's /was a RIGOL contributor here in the forum.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on April 13, 2017, 03:38:20 pm
Easy way.
I made a new thumb-drive with the firmware, pluged it in and start the scope. And viola, the screen doesn't show the calibration failure screen anymore and want do a firmware update. NOW the buttons working. I have no idea what happens yesterday.

Ummmm... your firmware got corrupted? Flash memory, it happens.

Luckily the 'scope has a recovery mode, all you had to do was insert a thumb-drive and it fixed itself.

No need for all the anti-Rigol ranting, it can happen to any device with Flash memory.

*Exsample Fluke. I send in a 30 years old Fluke 8840A for calibration. One Knob wouldn't work sometimes, not a real deal. It comes back with a complete new Front, new Knobs and a Letter "Thank you for using our Service". So what should I say ?!

Have you looked at the price of Flukes?  :-//

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fennec on April 13, 2017, 04:22:52 pm
Luckily the 'scope has a recovery mode, all you had to do was insert a thumb-drive and it fixed itself. No need for all the anti-Rigol ranting, it can happen to any device with Flash memory.

How does it works, if I can not press any key ?

Have you looked at the price of Flukes?  :-//

I don't have payed for that fix, for the calibration only.

What has the price to do with the quallity of service? Nothing.

Exsample again. Uni-T. I had a damaged Uni-T. I have sent it back to CHINA. Shipping was more than $US150. The device itself costs about $US90. I've got a new Device + my money back. Is that service or what ?
So don't say "i have to pay for service"
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: kcbrown on April 13, 2017, 04:25:46 pm
Luckily the 'scope has a recovery mode, all you had to do was insert a thumb-drive and it fixed itself. No need for all the anti-Rigol ranting, it can happen to any device with Flash memory.

How does it works, if I can not press any key ?

Your scope still doesn't work?  I thought reflashing the scope brought it back to normal operation.  At least, that's what your message implied.  Is that not the case?

If your scope now works after reflashing, then what Fungus is saying is a real possibility: the previous upgrade attempt resulted in a corrupt image and a malfunctioning scope, and the last flash attempt you did restored it to normal working order.


Quote
Have you looked at the price of Flukes?  :-//

I don't have payed for that fix, for the calibration only.

What has the price to do with the quallity of service? Nothing.

Everything, actually.  High quality service requires more manpower, which requires paying people, which costs money.   It also tends to require higher quality people, which also costs money.

You may have paid for the calibration only, but the people who fixed your meter took time to do so, time which they could have spent on other jobs that were explicitly paid for.  That time cost Fluke money.  That money had to come from somewhere.  Either it came from the price of the calibration service or it came from the price they charge for their instruments.  But either way, something is more expensive because of it.

There ain't no such thing as a free lunch.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Lightages on April 13, 2017, 04:31:41 pm
Why are you guys polluting this thread which has a specific subject? I know that this is normal for the internet, but please stop trashing the thread with garbage.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on April 13, 2017, 04:42:11 pm
Why are you guys polluting this thread which has a specific subject? I know that this is normal for the internet, but please stop trashing the thread with garbage.

My messages removed.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ankerwolf on April 13, 2017, 09:59:04 pm
Hy Fennec,
what is the problem you have?

Why do you not read my post after your post?

My scope did the same effect as yours. Read my post !!!
Power OFF > Power ON > SelfCal
... wait ... and all is ok

Why all these violent words?

LG Wolf
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ankerwolf on April 13, 2017, 10:48:34 pm
Hello Fennec,
What's LG ?
My native language is german. Therfore my valediction is also in german: LG means "Liebe Grüße". Or if you want: Kind regards
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fennec on April 13, 2017, 10:49:19 pm
Why do you not read my post after your post?

Why you didn't read mine ?

Since my last RESET my scope is complete ded. It boots up with this screen.

All knobs around the screen are ded. So Start or Exit wouldn't work.

Startup reset wouldn't work. If I tried this, it beeps a few times, than the beeper wouldn't stop and ALL the grey buttons are dead, no way to stop it.

what is the problem you have?

What's LG ?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fennec on April 13, 2017, 10:50:42 pm
Hello Fennec,
What's LG ?
My native language is german. Therfore my valediction ist also in german: LG means "Liebe Grüße". Or if you want: Kind regards

Thx

LG
Title: Re: Rigol DS1000Z series buglist continued (from: FW 00.04.04.03.02)
Post by: rsjsouza on April 13, 2017, 10:59:45 pm
PNG screenshot with thumb-drive and printer button takes 2 1/2 MINUTES !
One detail: at a certain point in the firmware merry-go-round, the DS4000 series had the same issue. I found out that FAT32 pendrives were terribly slow while FAT16 was very fast. Perhaps you could try this with your DS1000Z?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fennec on April 13, 2017, 11:34:40 pm
Yepp, thats it. 3-4s only.
The downside is, FAT16 can handle 4GB only. So you have to use an old "pendrive" nice name btw. or you lost the rest of the partition. If the RIGOL can handle more than one partitions with FAT16 I didn't checked.
Maybe I find in da junk box an old small thumb-drive. All I have is much larger than 64GB  :(

But thx.

The 100 is cracked  :blah:  :blah:
Title: Re: Rigol DS1000Z series buglist continued (from: FW 00.04.04.03.02)
Post by: ankerwolf on April 13, 2017, 11:45:57 pm
Hello,
PNG screenshot with thumb-drive and printer button takes 2 1/2 MINUTES !
One detail: ... I found out that FAT32 pendrives were terribly slow while FAT16 was very fast. Perhaps you could try this with your DS1000Z?

I'v tried that: No difference !
PLATINUM 2GB new formatted:
FAT (Std) same as FAT32: ~4 sec png screen (size ~32kB)

Kingston (DTSE9) 16GB FAT32: same ~4sec

BUT:
Another bootable 2GB FAT32 USB-Stick: ... not a DOS Disk ...
Another bootable 16GB NTFS USB-Stick: Saving failed!
...

LG Wolf
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fennec on April 13, 2017, 11:59:54 pm
Which OS do you use ? Windows ? So try "hp_usb_disk_storage_format_tool" It works fine. Sometimes it can refresh older or damaged pendrives. /attached  (Change txt to exe.) Ya, it's clean.
On Linux it is easy formatt to FAT16. On Windows I am an idiot.

For me the FAT16 works way better than FAT32. Maybe it is the pendrive chipset. Idk. I've checked only one laying arround.

Maybe it is possible plant in such a cheap bluetooth or wifi modul for $US5 ? So it would work with all devices, include mobile phones and without any cables. I never test it, because the scope is still sealed.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ProBang2 on April 14, 2017, 05:08:21 am
Yepp, thats it. 3-4s only.
The downside is, FAT16 can handle 4GB only. So you have to use an old "pendrive" nice name btw. or you lost the rest of the partition. If the RIGOL can handle more than one partitions with FAT16 I didn't checked.
Maybe I find in da junk box an old small thumb-drive. All I have is much larger than 64GB  :(

That is probably the main problem. Even with the failed first update (flashing error).   :-BROKE

There is (well hidden) on page 16-2 under point 8. (3) in the DS 1054Z Manual (https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwj539_kj6PTAhUCJsAKHeoaA3EQFggjMAA&url=http%3A%2F%2Fwww.batronix.com%2Fpdf%2FRigol%2FUserGuide%2FDS1000Z_UserGuide_EN.pdf&usg=AFQjCNHLqk5orQTATeZn10EhEN2STvr5FQ&sig2=yR1a9WFEdwPSqy77OX--9Q&bvm=bv.152180690,bs.1,d.d2s&cad=rjt) this text:

"Make sure whether the capacity of the USB storage device is too large. It is
recommended that the capacity of the USB storage device being used with
this oscilloscope is no larger than 8 GBytes."


And it gets still much worse. In this description of the "DS1000Z Firmware Upgrade Procedure" (http://beyondmeasure.rigoltech.com/acton/ct/1579/p-0019/Bct/-/-/ct6_0/1?sid=TV2%3At03F5okPu) they recommend this:

"The USB stick must be FAT32 format. If the device is not recognized, try reformatting or
another USB memory stick. We also recommend minimizing the number of folders, files,
and programs on the stick. Drives less than 4GB in total volume are also recommended."


What should I say? My 8 GB USB stick, FAT32, worked and still works fine...   :-//
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on April 14, 2017, 10:12:46 am
"The USB stick must be FAT32 format. If the device is not recognized, try reformatting or
another USB memory stick. We also recommend minimizing the number of folders, files,
and programs on the stick. Drives less than 4GB in total volume are also recommended."


What should I say? My 8 GB USB stick, FAT32, worked and still works fine...   :-//

If it can handle FAT32 then I don't see why the drive size would make any difference at all.  :-//

PNG screenshot with thumb-drive and printer button takes 2 1/2 MINUTES !
One detail: at a certain point in the firmware merry-go-round, the DS4000 series had the same issue. I found out that FAT32 pendrives were terribly slow while FAT16 was very fast. Perhaps you could try this with your DS1000Z?

Was it the exact same pendrive formatted both ways?

I don't think FAT16/FAT32 is the reason. I put big pendrives in mine all the time and it's not slow.

If somebody here owns a 'slow' pendrive then it would be good if they could try formatting it different ways and different capacities and report back with actual numbers.

FAT16
FAT32 4Gb partition
FAT32 8Gb partition

I'm betting it won't make any difference though, pendrives have lots of hidden secrets* and formatting them doesn't erase all the information.

You might be able to make a pendrive into a 'fast' one with clever use of Windows' diskpart/bootsect. I wouldn't know the commands you'll need though.

(*) As anybody who's ever tried to make a bootable pendrive to install Windows can tell you.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 14, 2017, 10:24:18 am
If it can handle FAT32 then I don't see why the drive size would make any difference at all.  :-//

Actually it does and there is no problem at all writing to:

USB Stick CNMemory "Spaceloop"
      PCI Device ID: 0x268c
      PCI Revision ID: 0x0009
      PCI Vendor ID: 0x8086
      32Gb, FAT32 formatted via OS X Disk Utility


Can not remember having any trouble writing to USB sticks, apart from ExFAT, OS X Extended,... formatted media. So as long as it is FAT16/32 formatted – no problem at all.

However, there is another issue: The timestamp is always 1st of November 2014
There is no difference, if connected to LAN via DHCP. But AFAIK the DS1000Z does not have an RTC.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on April 14, 2017, 10:39:40 am
However, there is another issue: The timestamp is always 1st of November 2014
There is no difference, if connected to LAN via DHCP. But AFAIK the DS1000Z does not have an RTC.

Yep. It doesn't know the time so what should it do?

1st of November 2014 is probably the design meeting when the DS1054Z was 'born' or something like that.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: rsjsouza on April 14, 2017, 04:29:50 pm
PNG screenshot with thumb-drive and printer button takes 2 1/2 MINUTES !
One detail: at a certain point in the firmware merry-go-round, the DS4000 series had the same issue. I found out that FAT32 pendrives were terribly slow while FAT16 was very fast. Perhaps you could try this with your DS1000Z?

Was it the exact same pendrive formatted both ways?
I don't own a DS1000Z and that was definitely an issue on the DS4000 at a certain point that manifested itself similarly to what was reported by Fennec - all bases covered (different brands, sizes and formats).
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on April 14, 2017, 05:06:18 pm
If it can handle FAT32 then I don't see why the drive size would make any difference at all.  :-//

Actually it does and there is no problem at all writing to:

USB Stick CNMemory "Spaceloop"
      PCI Device ID: 0x268c
      PCI Revision ID: 0x0009
      PCI Vendor ID: 0x8086
      32Gb, FAT32 formatted via OS X Disk Utility


Can not remember having any trouble writing to USB sticks, apart from ExFAT, OS X Extended,... formatted media. So as long as it is FAT16/32 formatted – no problem at all.

There are definitely issues reading/writing some USB stick/thumb/pen drives. There was a bit of discussion about it back in 2015 having to do with media, allocation table, and cluster sizes: https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg782838/#msg782838 (https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg782838/#msg782838)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 14, 2017, 05:14:21 pm
I am aware of that and maybe I expressed poorly what I meant. This was more in regard to "32Gb should not be a problem if FAT32 works".

There definitely needs to be evaluation done on what kind of USB sticks are affected and if we can pin it down to a certain chipset or what-do-I-know :)
Yesterday I added this silently to the original post where this issue is taking up space número diez in the bug list.

For know, the only work around seems to be trying out different brands and stick with one that gets the job done.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: rstofer on April 15, 2017, 02:17:27 pm
I have been using an Imation 2 GB Clip device and I can save a .png image in about 5 seconds.  I'm pretty sure this is FAT16.
It also takes about 5 seconds on a Cruzer Glide 256 GB which is FAT32.

I have no idea what is inside either of these devices but they sure seem to work for me!

I have a much smaller stick that I use for software upgrades.  No reason, really, it's just that I don't want to get things confused so I have this stick dedicated to the purpose of upgrading.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: BravoV on April 15, 2017, 02:26:35 pm
From Rigol manual :

(https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/?action=dlattach;attach=308481;image)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on April 15, 2017, 04:52:36 pm
Yeah, the Rigol manual (which version is that from, BravoV?) says maximum 8GB formatted as FAT32. However, there have been problems reported that conflict with the manual. Rstofer just posted success with 2GB FAT16 and 256GB FAT32. Others have had failures with 2GB FAT32.

I upgrade my scope with a 512MB FAT16, which defaults to either 8KB or 16KB clusters (https://support.microsoft.com/en-us/kb/140365) on Windows.(Unfortunately, Microsoft doesn't explicitly specify the size ranges. Grrr! e.g., 256 MB–512 MB has 8KB clusters; 512 MB - 1 GB has 16KB clusters. So, to which range does 512 MB apply?

It would've been helpful if Rigol published what maximum cluster size is supported.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 15, 2017, 05:09:30 pm
Testing out different allocation unit sizes might be worth trying.
BRB
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: BravoV on April 15, 2017, 05:10:24 pm
Yeah, the Rigol manual (which version is that from, BravoV?) says maximum 8GB formatted as FAT32. However, there have been problems reported that conflict with the manual. Rstofer just posted success with 2GB FAT16 and 256GB FAT32. Others have had failures with 2GB FAT32.

I upgrade my scope with a 512MB FAT16, which defaults to either 8KB or 16KB clusters (https://support.microsoft.com/en-us/kb/140365) on Windows.(Unfortunately, Microsoft doesn't explicitly specify the size ranges. Grrr! e.g., 256 MB–512 MB has 8KB clusters; 512 MB - 1 GB has 16KB clusters. So, to which range does 512 MB apply?

It would've been helpful if Rigol published what maximum cluster size is supported.

The manual is dated Dec 2015, didn't aware if there is newer one. Downloaded it quite long ago though.

Looking at the USB flash drive fiasco, I suspected Rigol programmer probably either was using a really crappy FAT(32/16) library, or they screwed the library by forking/shrinking it too much, maybe to save flash size or RAM memory or even CPU cycles ?  :-//
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 15, 2017, 05:54:08 pm
I took two USB sticks, one with 32Gb and one with 2Gb and tried to get my Rigol fail on write due to unsupported allocation size. Everything passed.

drive size   |file system |allocation unit size |Rigol write test
2Gb / 32Gb FAT16 32 kbyte PASS
2Gb / 32Gb FAT16 64 kbyte PASS
2Gb FAT32 512 byte PASS
2Gb / 32Gb FAT32 1024 byte PASS
2Gb / 32Gb FAT32 2048 byte PASS
2Gb / 32Gb FAT32 4096 byte PASS
2Gb / 32Gb FAT32 8192 byte PASS
2Gb / 32Gb FAT32 16 kbyte PASS
32Gb FAT32 32 kbyte PASS
32Gb FAT32 64 kbyte PASS

(formatted on Windows 7 32bit machine via on-board disk utility)

But as I reported before, there have been no issues with USB drives on my scope (apart from the obvious: NTFS / ExFAT / OS X Extended formatted drives)
I would need an USB drive that is reportedly not working to further investigate...
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: smithnerd on April 15, 2017, 05:56:28 pm
Yeah, the Rigol manual (which version is that from, BravoV?) says maximum 8GB formatted as FAT32. However, there have been problems reported that conflict with the manual. Rstofer just posted success with 2GB FAT16 and 256GB FAT32. Others have had failures with 2GB FAT32.

I upgrade my scope with a 512MB FAT16, which defaults to either 8KB or 16KB clusters (https://support.microsoft.com/en-us/kb/140365) on Windows.(Unfortunately, Microsoft doesn't explicitly specify the size ranges. Grrr! e.g., 256 MB–512 MB has 8KB clusters; 512 MB - 1 GB has 16KB clusters. So, to which range does 512 MB apply?

It would've been helpful if Rigol published what maximum cluster size is supported.

The manual is dated Dec 2015, didn't aware if there is newer one. Downloaded it quite long ago though.

Looking at the USB flash drive fiasco, I suspected Rigol programmer probably either was using a really crappy FAT(32/16) library, or they screwed the library by forking/shrinking it too much, maybe to save flash size or RAM memory or even CPU cycles ?  :-//

The library is called MFS, it's part of Freescale/NXP's MQX. Somebody put an (unofficial) mirror of the source code tree on github, if you're curious:

https://github.com/gxliu/MQX-3.7.0/tree/master/mfs

...though some code from later MQX releases (3.7 is ancient) may have been back-ported into Rigol's build.

Edited to add: Freescale MQX(TM) MFS(TM) User’s Guide:

https://raw.githubusercontent.com/gxliu/MQX-3.7.0/master/doc/mfs/MQXMFSUG.pdf


Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ankerwolf on April 18, 2017, 04:57:01 pm
Hello,
Bug #5 I can say:
Pass: Board Version: 0.1.1, Boot Version: 0.0.1.3, Firmware Version: 0.2.3.11, CPLD Version: 1.1

LG Wolf
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 18, 2017, 05:03:56 pm
Thanks ankerwolf :)
Sooo.. Maybe we can pin this on boot version <0.1.3?
(still needs a bigger dataset obviously)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on April 19, 2017, 02:05:17 pm
Thanks ankerwolf :)
Sooo.. Maybe we can pin this on boot version <0.1.3?
(still needs a bigger dataset obviously)

Nope. I've got boot version 0.0.1.1 and it doesn't happen here.

Edit: Here's my full info...
(https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/?action=dlattach;attach=309378;image)

(Screenshot took about 8 seconds to complete)

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: BravoV on April 19, 2017, 04:01:17 pm
Big jump, just upgraded DS1104Z-S (with FG), from v04.00.00.00 straight to v04.04.03.02, so far no problem, at least at the upgrade process it self.

Just fyi, used an old 8GB USB flash drive with FAT32 and 4096 bytes allocation unit, freshly reformatted and just copy the single .GEL file at the root directory, no other files in it.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 19, 2017, 04:15:11 pm
Thanks BravoV,

did you run self-calibration without problems?
That is where issues seem to be sticking their head out.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: BravoV on April 19, 2017, 04:28:07 pm
Thanks BravoV,

did you run self-calibration without problems?
That is where issues seem to be sticking their head out.

Yes, after the upgrade process finished, turned the power off, power on again, and straight to the long self-calibration process, and it finished without any problem.

Forgot to mention, before doing the upgrade, I did the memory "sanitation" 1st as Rigol document stated, just want to make sure its like fresh from factory, which are :

- Clear the internal volatile memory :
   Buttons pressed = STORAGE > DISK MANAGE > FLASH ERASE

- Restore Power Of Setup restored to "Default" :
   Buttons pressed = UTILITY > SYSTEM > POWER SET = Default

- Then power off the unit.

- Power on, insert the "blank" USB flash drive, to check whether it recognizes the USB first, and it did.
  (PS : "blank" means a freshly formatted 8GB FAT32 with 4K alloc. and without any file in it as its freshly formatted.

- Unplugged the flash drive, brought it to my computer, copied "only" the single .GEL file, as I mentioned above, its the only file in the drive and at the root directory.

- Plugged the flash drive, instantly it recognized the new firmware, proceeded next as my previous post's photos.

Thats all.

EDIT :

Here is the USB drive details from Windows standard check disk result (CHKDSK), formatted under Win 7 x64 from the Explorer, right click at the drive and quick format using default allocation.

Code: [Select]
The type of the file system is FAT32.
Volume USB 8G created 4/19/2016 9:58 AM
Volume Serial Number is 503E-347B
Windows is verifying files and folders...
File and folder verification is complete.
Windows has checked the file system and found no problems.
    7,551,380 KB total disk space.
        4,632 KB in 1 files.
    7,546,744 KB are available.

        4,096 bytes in each allocation unit.
    1,887,845 total allocation units on disk.
    1,886,686 allocation units available on disk.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: BravoV on April 19, 2017, 04:51:07 pm
I did capture the screen using the print feature too, apart from taking the photo using camera.

What I found an interesting change is the screen layout, at least from 4.0.0.0 to 4.4.3.2 , looks like they resized part of the screen real estate abit.

Just watch this animation switching between these two versions. This is untouched PNG file saved using the print, size untouched and converted straight into animated GIF.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 19, 2017, 05:17:08 pm
Also: You got a hardware upgrade via USB implant as it seems xD
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: BravoV on April 19, 2017, 05:19:36 pm
Also: You got a hardware upgrade via USB implant as it seems xD

Yep , what a sharp eyes you got there.  :-+
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 19, 2017, 06:02:14 pm
I added the direct link to last known firmware release that also contained a board / boot version update file to the opening post. (v.00.04.00.00.00)

Please: If any of you does the boot version update, or did the update already, can you leave some info on what version is included here? I would like to add this info as well :)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ebastler on April 19, 2017, 06:10:34 pm
Also: You got a hardware upgrade via USB implant as it seems xD
Yep , what a sharp eyes you got there.  :-+

I noticed that the displayed board version has changed; assume this is what you are referring to?
But what's up with the "USB implant"? I must have missed something there... ???
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on April 19, 2017, 06:18:05 pm
But what's up with the "USB implant"? I must have missed something there... ???

In other words, it's as if a hardware upgrade was physically implanted via the USB interface. That'd be a nice feature, indeed.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 19, 2017, 06:20:09 pm
I noticed that the displayed board version has changed; assume this is what you are referring to?
But what's up with the "USB implant"? I must have missed something there... ???

USB implant was actually a joke ;)

The version number does not really make sense, as the more recent ones are labeled 0.1.4 and this unit had 0.1.1 and now is shown as 4.1.1 – the flying spaghetti monster knows why...
As a change in hardware revision usually needs some physical change of components, I implied surgical procedure via USB stick. Must be some kind of futuristic replicator technology...

Edit: What bitseeker said
In other words, it's as if a hardware upgrade was physically implanted via the USB interface. That'd be a nice feature, indeed.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: BravoV on April 19, 2017, 06:23:49 pm
LOL  :-DD, although I haven't thoroughly test all, I guess that big jump 0.1.1 to 4.1.1 probably has something to do with the FG board, at least for service engineer. Since it doesn't show additional field for the FG's firmware version at the screen. Its a DS1104Z-S , not a hacked DS1054Z which doesn't have it.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 19, 2017, 07:28:42 pm
Thanks ankerwolf :)
Sooo.. Maybe we can pin this on boot version <0.1.3?
(still needs a bigger dataset obviously)
Nope. I've got boot version 0.0.1.1 and it doesn't happen here.

Might be interesting if the freeze bug could then be pinned to only affecting boot version 0.0.1.2

Hopefully we can resolve this :)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: rbino on April 21, 2017, 08:31:30 am
Reporting in, since yesterday I've upgraded to 00.04.04.03.02 (starting from the version ending with SP1, I can't remember the precise version).

Software version: 00.04.04.03.02
Board version: 0.1.1
Boot version: 0.0.1.2
Firmware version: 0.2.3.11
CPLD version: 1.1

I can't reproduce the Zoom lock-up (issue number 5), so it's a PASS for me.

After the software upgrade, the additional buttons on the auto-calibration showed up, and the auto-calibration failed.
When I've rebooted, the buttons were gone, but the calibration failed again.
Both the times the only symptom was the calibration failing, the scope didn't lock-up and I could continue to use it.
I will now try another self-calibration, if it fails again I will try cleaning the memory as BravoV did.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: rbino on April 21, 2017, 09:01:57 am
Ok, I've just finished the third self-calibration since the software upgrade and this time it didn't fail. :-+
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 21, 2017, 09:15:55 am
Thanks rbino for reporting in.
So basically the freeze bug can not be pinned down to any given device stats – strange.

Nice to hear that you could finally initialize/calibrate your scope.
Did it just work on the third try, or did you do some memory clean or alternative reset?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: szpila on April 21, 2017, 09:36:15 am
Yesterday, I've updated my scope to latest firmware. After that calibration went smooth without any errors. I've noticed two more buttons on calibration screen.

Wys?ane z mojego 2014811 przy u?yciu Tapatalka

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Sredni on April 21, 2017, 09:47:38 am
Big jump, just upgraded DS1104Z-S (with FG), from v04.00.00.00 straight to v04.04.03.02,

How come your Board Version has been updated, too?
From 0.1.1 to 4.1.1.
I thought that was only possible in hardware.

EDIT: I'll chip in with my USB weirdness.
Every now and then the USB stick I save screenshots on (it's mostly a Sandisk Cruzer 4GB) gets corrupted. I experienced blue screens of death the moment I try to open the stick's folder ("Windows has been shut down to prevent damage to your computer.  Yaddayadda... PAGE_FAULT_IN_NONPAGED_AREA yaddayadda... Fastfat.sys").
This only happens with the stick I use with the scope. I changed stick, it still happened. I emptied and reformatted the stick, it still happened.
PC has the latest bios and the latest usb drivers according to the manufacturer. It also happened on another computer.

One other USB weirdness (probably associated to this) it that sometimes I found a corrupted filesystem on the stick with multiple files with the very same filename. For example two files with the name "DS1Z_QuickPrint12".
Yeah, you read it right: two files with the same filename.

I believe weird stuff began to happen when I started saving screenshots on a stick from where previous screenshots had been removed. It may have something to do with the way the DS1054Z names files. It seems to start from the lowest number available, but if after that there is a higher numbered filename still present, it messes things up.

I am now on version v00.04.04.01.01  (2016/09/14) - board version 0.1.1 - but it happened on v00.04.03.01.05   2015/06/16 and v00.04.02.04.07   2014/12/31, too.

I am now stalling the upgrade to the last one because I'd hate to make it worse.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 21, 2017, 09:50:01 am
Seems to be some hick-up weirdness issued on the page before.

Edit: I added the update procedure as recommended by BravoV to the OP. Anything else I missed to include?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: rbino on April 21, 2017, 11:42:13 am
Did it just work on the third try, or did you do some memory clean or alternative reset?

I just retried the calibration and it went well, without other special procedures.
Little note: the additional soft buttons were present when it succeeded (the third try). Now they're gone.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ProBang2 on April 21, 2017, 02:01:25 pm
[...] Little note: the additional soft buttons were present when it succeeded (the third try). Now they're gone.

That´s not 100 % correct... - they´re just hidden.
In the (let´s call it) "expanded mode" they´re visible.
 
How to get in the "expanded mode"?
Fast pressing the hard buttons [Menu] [Menu] [Force] [Menu]
Then pressing the hard button [Utility]

After that:
Press the soft buttons <System> and <System Info> gives the expanded system info.
Or, press the soft button <Self-Cal> and the scope shows the usual two soft buttons "Start" and "Exit"
and additional two soft buttons: "LFCal" and "Output".

With a DS1054Z both functions are failing.                             :-//
Perhaps the first is associated to an inbuild logic analyzer, the second to the function generator of a 1054S?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Gary.M on April 22, 2017, 06:31:14 am
Key elements of my scope are:

Board version: 0.1.1
Boot version: 0.0.1.2

I'm reluctant to try the upgrade, but I did test for the freeze on zoom bug. I followed instructions to the letter and I was able to keep using the scope beyond that. Is the Freeze referred to one that requires a power cycle to recover from?

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: BravoV on April 22, 2017, 01:55:36 pm
Big jump, just upgraded DS1104Z-S (with FG), from v04.00.00.00 straight to v04.04.03.02,

How come your Board Version has been updated, too?
From 0.1.1 to 4.1.1.
I thought that was only possible in hardware.


Looks like lots of people are amazed by that.  :-DD

Its possible, by upgrading the latest firmware, it even popped out a new knob and new functionality.  >:D



Ok, seriously ...

Just to repeat just in case you missed it, its NOT DS1054Z , its a DS1104Z-S, watch "S" (highlighted) suffix, means it has a 25MHz function generator (FG) board that DS1054Z doesn't have, also its already 100MHz ready/capable from factory, not a hacked DS1054Z.

My "speculation" on the instantaneous magically board/hardware upgrade is, since in the detail firmware's screen, those lazy programmers just don't want to add additional field to show the FG's firmware, so they just "duct-taped" it at the most significant digit at the board version number to indicate that, probably to aid Rigol's field engineer or their support staffs.

Again, this is just my guess, but it makes sense though.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on April 22, 2017, 06:18:11 pm
Sounds plausible to me.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: BravoV on April 24, 2017, 12:36:59 pm
Helped friend upgrade his DS1054Z from 04.03.02.03 to the latest 04.04.03.02, so far no problem in the upgrading process and also the self cal after that. Also all DSER options are still active in this new firmware.

Spotted minor screen's change, not as many as my previous DS1104Z-S as it was a big jump, but this time is just the right panel buttons, watch closely the minor shift at right side at the attached GIF animation.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: BravoV on April 24, 2017, 03:14:37 pm
How to get in the "expanded mode"?
Fast pressing the hard buttons [Menu] [Menu] [Force] [Menu]
Then pressing the hard button [Utility]

After that:
Press the soft buttons <System> and <System Info> gives the expanded system info.
Or, press the soft button <Self-Cal> and the scope shows the usual two soft buttons "Start" and "Exit"
and additional two soft buttons: "LFCal" and "Output".

With a DS1054Z both functions are failing.                             :-//
Perhaps the first is associated to an inbuild logic analyzer, the second to the function generator of a 1054S?

The new extra "Output" button does some extra magic.  ;)

Here are the steps :

Now, the fun of decoding that CalData.txt file is started ...  :-DD


For those who still confused, attached below pictures of two versions of Self-Cal screens, the normal one and in the "Expanded" mode.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ted572 on April 24, 2017, 07:19:19 pm
The following procedure can be used to Sanitize Memory in the DS1000Z Series Oscilloscopes. This is similar to the procedure released by Rigol (Titled: Sanitization of memory with the DS1000Z series of oscilloscopes) with some additional details.

Edit Added -> Re-Calibration Requirement: Sanitization of the instrument's memory will of course erase the stored Self-Calibration values.  Therefore it is important to perform Self-Calibration following Sanitization.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Gary.M on April 26, 2017, 01:48:56 am
Just did the update. I was a little cautious as my hardware and boot version seemed to be the troubled ones. However all went well. I did the full memory sanitise first.



Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: maxiq4 on April 26, 2017, 05:33:12 am
Im updated, ds1054Z, self cal is ok

but why not show boot version etc?
my system info menu short. have any body know why?

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: metrologist on April 26, 2017, 05:45:27 am
Im updated, ds1054Z, self cal is ok

but why not show boot version etc?
my system info menu short. have any body know why?

How to get in the "expanded mode"?
Fast pressing the hard buttons [Menu] [Menu] [Force] [Menu]
Then pressing the hard button [Utility]

After that:
Press the soft buttons <System> and <System Info> gives the expanded system info.
Or, press the soft button <Self-Cal> and the scope shows the usual two soft buttons "Start" and "Exit"
and additional two soft buttons: "LFCal" and "Output".

With a DS1054Z both functions are failing.                             :-//
Perhaps the first is associated to an inbuild logic analyzer, the second to the function generator of a 1054S?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: maxiq4 on April 26, 2017, 05:53:03 am
thank you  :)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: video on May 01, 2017, 07:10:20 pm
Hello,
sorry for my english, it's not my mother langage
It's my first message here, but i read sometimes this topic as i'm an new DS1054Z owner.
Just a remarq:
The second bouton "Output" could be named "WFCal" for "Write File Calibration" and of course the first hidden button (what is named "LFCal") seem to be "Load File Calibration".
But i didn't try to "Load" (if it's really a loading function..)..to much afraid..

Does anybody say if i'm wrong or right ?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Roeland_R on May 01, 2017, 07:32:45 pm
Hello,

Just upgraded my scope. First sanitized and warmed up. (Had still the last version from 2015 before pulses function was introduced) All went fine. Only first calibration failed after about 30%. Second calibration (no reboot, just started again) did well. Only difference with all other scopes mentioned in this thread is the CPLD version 2.3

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ebastler on May 01, 2017, 07:36:59 pm
The second bouton "Output" could be named "WFCal" for "Write File Calibration" and of course the first hidden button (what is named "LFCal") seem to be "Load File Calibration".
But i didn't try to "Load" (if it's really a loading function..)..to much afraid..

That's quite plausible! We already know that "Output" writes a calibration file to USB; and as the two buttons are grouped together, "LFCal" could indeed be its counterpart. I was too much stuck on interpreting it as "low frequency calibration", so this would not have occured to me.

I can't figure out, however, what this would be used for. Why would one want to store and recall a calibration, rather that redo a fresh calibration (after some time has passed, or after a firmware upgrade, or...)? Well, I guess those to buttons are only meant for debugging or service purposes anyway. I don't think I will try an "LFCal" any time soon...
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: video on May 01, 2017, 08:24:01 pm
Yes, as is a hidden button, it's probably for development/debugging, but if it exists, there is a reason  :) even if it seems not logic to load a such file; but loading is quicker (fresh calibration can take an half hour), may be it's usable after some kind of reset or firmware update..i don't know
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Sredni on May 01, 2017, 08:58:49 pm
I wonder what the calibration data is...
For example:

{//CH1
500       ,ATT_X1  ,G_X2    ,1  ,13 ,4233  ,
1000      ,ATT_X1  ,G_X2    ,1  ,13 ,2116  ,
2000      ,ATT_X1  ,G_X2    ,1  ,13 ,1058  ,
5000      ,ATT_X1  ,G_X2    ,1  ,10 ,1058  ,
10000     ,ATT_X1  ,G_X2    ,1  ,7  ,1058  ,
20000     ,ATT_X1  ,G_X2    ,1  ,5  ,1058  ,
50000     ,ATT_X1  ,G_X2    ,1  ,2  ,1058  ,
100000    ,ATT_X1  ,G_X0625 ,1  ,3  ,1364  ,
200000    ,ATT_X1  ,G_X0625 ,1  ,1  ,1364  ,
500000    ,ATT_X50 ,G_X2    ,1  ,7  ,1080  ,
1000000   ,ATT_X50 ,G_X2    ,1  ,5  ,1080  ,
2000000   ,ATT_X50 ,G_X2    ,1  ,3  ,1080  ,
5000000   ,ATT_X50 ,G_X0625 ,1  ,3  ,1392  ,
10000000  ,ATT_X50 ,G_X0625 ,1  ,1  ,1392  ,
}
...


or

------------100M-----------
{
{,32732,32699,32634,32640,32649,32670,32753,34786,36988,32664,32696,32771,34929,37221},
{,32721,32688,32622,32624,32628,32639,32668,34702,36814,32639,32659,32697,34817,37029},
{,32673,32640,32575,32578,32584,32593,32647,34635,36700,32596,32621,32673,34774,36992},
{,32744,32712,32646,32653,32660,32676,32741,34825,37032,32671,32699,32760,34904,37250},
},
...

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on May 01, 2017, 09:02:55 pm
I can't figure out, however, what this would be used for. Why would one want to store and recall a calibration, rather that redo a fresh calibration (after some time has passed, or after a firmware upgrade, or...)?

Perhaps to recreate a known state of the machine to reproduce particular results. It could also be useful if running a new self-cal didn't work properly for some reason.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: garnix on May 01, 2017, 09:36:06 pm
That sounds neat - I always see some small offset after calibration. Perhaps with some editing and reloading that file we could tune it to get rid of that offset...
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on May 01, 2017, 10:12:22 pm
That would be nice. The offset does aggravate the OCD. :-DD
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: BravoV on May 02, 2017, 07:19:20 am
I don't think I will try an "LFCal" any time soon...

Definitely not me either.  :scared:

Dunno, I have a feeling that someone that will be brave enough to modify their cal file to certain extreme values at each entries, load it and compare the measurement results with previous loaded cal that was altered to "another" extreme values, just for the sake to decode that file alone.  >:D

Probably those people who contribute at this thread ->  Rigol DS10xxZ firmware re-write  (https://www.eevblog.com/forum/projects/rigol-ds10xxz-firmware-re-write/)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on May 02, 2017, 08:03:34 am
I can't figure out, however, what this would be used for. Why would one want to store and recall a calibration

Beats me.  :-//

I could understand it if calibration was only done by an expensive calibration service center and comes with a certificate. On a DS1054Z you just press a button to make a new one.

I guess those to buttons are only meant for debugging or service purposes anyway.

Yep. I'm guessing somebody at Rigol added it so they can compare calibration results with different firmware versions.

Has anybody looked at the file? Is it binary/ASCII? How big is it? If it's binary, have we got a hex dump?

More important: Is it calibration data or is it a log file of the last calibration process? (which would make a lot more sense)

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: video on May 02, 2017, 08:44:13 am
In this file, there're 4 parts with a (chinese/japanese ?)  title: i don't read or speak this very complex language, i don't know exactly what it is; i tried a google and online dictionnary search, but not easy; if somebody can translate this header, it will be interesting for understand, even partially, the content of the file, but i don't know asian person to help us  :(
this is a part of the CalData.txt:

------------------????????---------------------
{
 {
  0,0x5b,1,1,
  0,0x4f,1,1,
 },etc..
------------------?????????---------------------
------------100M-----------
{
{//CH1
500       ,ATT_X1  ,G_X2    ,1  ,13 ,4154  ,
1000      ,ATT_X1  ,G_X2    ,1  ,13 ,2077  ,
2000      ,ATT_X1  ,G_X2    ,1  ,13 ,1038  ,
5000      ,ATT_X1  ,G_X2    ,1  ,10 ,1038  ,
10000     ,ATT_X1  ,G_X2    ,1  ,7  ,1038  ,
20000     ,ATT_X1  ,G_X2    ,1  ,5  ,1038  ,
50000     ,ATT_X1  ,G_X2    ,1  ,2  ,1038  ,
100000    ,ATT_X1  ,G_X0625 ,1  ,3  ,1362  ,
200000    ,ATT_X1  ,G_X0625 ,1  ,1  ,1362  ,
500000    ,ATT_X50 ,G_X2    ,1  ,7  ,1060  ,
1000000   ,ATT_X50 ,G_X2    ,1  ,5  ,1060  ,
2000000   ,ATT_X50 ,G_X2    ,1  ,3  ,1060  ,
5000000   ,ATT_X50 ,G_X0625 ,1  ,3  ,1390  ,
10000000  ,ATT_X50 ,G_X0625 ,1  ,1  ,1390  ,
},etc..
-------------????-------------
{
{
101.423302,101.811897,102.006195,ATT_X1  ,G_X2    ,10 ,1024  ,
332.540192,333.123077,334.094574,ATT_X1  ,G_X0625 ,10 ,1024  ,
},etc..
-------------??????-------------
------------100M-----------
{
{,32918,32885,32819,32821,32826,32833,32868,35007,37103,32841,32862,32910,35116,37377},
{,32937,32904,32839,32839,32841,32852,32859,34938,37030,32851,32866,32899,35018,37213},
{,32901,32869,32803,32805,32807,32812,32818,34776,36774,32815,32831,32857,34866,36993},
{,32930,32897,32831,32836,32842,32850,32898,34939,37130,32853,32875,32923,35078,37335},
},etc..
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: video on May 02, 2017, 08:47:49 am
 :-[ Sorry, but the chinese/japanese characters are changed by smiley in my post, i didn't check that by preview, so lock in your own file to see its
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: tautech on May 02, 2017, 09:05:15 am
:-[ Sorry, but the chinese/japanese characters are changed by smiley in my post, i didn't check that by preview, so lock in your own file to see its
Drop it into some document, Word, txt... and attach it in a post of try dropping it within the brackets for Insert Table (below Font Face) when you make a post. Like this:

FILE CONTENTS

Quote this post and you can see the syntax used.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: BravoV on May 02, 2017, 10:27:50 am
Has anybody looked at the file? Is it binary/ASCII? How big is it? If it's binary, have we got a hex dump?

Here you go, attached below zipped, its a text file with some headers presumably Chinese characters.  :-//

Please be reminded, also to others, this is from DS1104Z-S (with func gen), "NOT" a hacked DS1054Z.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ebastler on May 02, 2017, 10:34:58 am
Attached is the screencopy of "LFCal".

Do you also get the error message when a USB stick with a previously saved calibration file is present?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: zbyr on May 02, 2017, 10:55:35 am
I tried google translate with these chinese characters, and it seems ok.

Attached file with translated headers.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: video on May 02, 2017, 11:54:27 am
Thanks for the  chinese-english translation zbyr, and my idea about "LFCal" for load file calibration wasn't good, ebastler was maybe more near to the truth.
I compared the 2 CalData files from the DS1104Z-S and the DS1054Z, the structure are similar, the 2 channels generator is probablely not concerned by this caldata file. PeDre, i can't find the [SCPI command for the "LFCal" function ":CALibrate:LFSTARt", and for the "OUTPUT" function ":CALibrate:OUTPut?"] in the Rigol programming guide: did you find it in an official doc ?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on May 14, 2017, 02:48:35 pm
In case somebody thought that most bugs have been solved, I have an unpleasant surprise:

The command :FUNCtion:WREPlay:FMAX? returns the value that belongs to :FUNCtion:WREPlay:FEND
instead of the number of recorded frames.

Example: 5 frames have been recorded. :FUNCtion:WREPlay:FEND is set to 5.
When using the command :FUNCtion:WREPlay:OPERate PLAY, it plays the 5 frames as expected.
Now use the command :FUNCtion:WREPlay:FEND 3 to playback frames 1 to 3.
When using the command :FUNCtion:WREPlay:OPERate PLAY, it plays the 3 frames as expected.
Now, when requesting the maximum number of frames that can be set to playback using the command :FUNCtion:WREPlay:FMAX?
it returns 3 instead of 5.

 :--

Together with all other (resolved) bugs, it explains why their pc software is so shitty.
It's impossible to write good remote control software when the firmware doesn't work as documented.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on May 14, 2017, 04:02:19 pm
In case somebody thought that most bugs have been solved, I have an unpleasant surprise:

The command :FUNCtion:WREPlay:FMAX? returns the value that belongs to :FUNCtion:WREPlay:FEND
instead of the number of recorded frames.

Example: 5 frames have been recorded. :FUNCtion:WREPlay:FEND is set to 5.
When using the command :FUNCtion:WREPlay:OPERate PLAY, it plays the 5 frames as expected.
Now use the command :FUNCtion:WREPlay:FEND 3 to playback frames 1 to 3.
When using the command :FUNCtion:WREPlay:OPERate PLAY, it plays the 3 frames as expected.
Now, when requesting the maximum number of frames that can be set to playback using the command :FUNCtion:WREPlay:FMAX?
it returns 3 instead of 5.

That's correct behavior.

Read the manual:

(https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/?action=dlattach;attach=315684;image)

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: metrologist on May 14, 2017, 04:14:24 pm
maybe because that is the way they've written it, but I would expect the FEND? keyword. that stuff happens to the best anyway...
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on May 14, 2017, 04:34:28 pm
I have read the manual and it's not correct behaviour. Thank you very much.

Instead of showing me a screenshot of a part of the manual that I have already read for three times, you could maybe offer
some arguments or reasoning why you think it is correct.


The maximum number of frames recorded is 5.

The maximum number of frames to be played back is set to 3.

The query to maximum number of frames that can be played back should be the number of recorded frames: 5.

The query to maximum number frames set to playback is 3.

Quote
:FUNCtion:WREPlay:FMAX?
Description Query the maximum number of frames can be played, namely the maximum number of frames recorded.

When you set the end frame for playback, you don't change the number of recorded frames.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: pascal_sweden on May 14, 2017, 05:04:26 pm
Who is actually communicating all these bugs to Rigol? Or is there a Rigol application engineer on this forum?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on May 14, 2017, 05:20:55 pm
Who is actually communicating all these bugs to Rigol? Or is there a Rigol application engineer on this forum?

A couple of forum members have reported most of the bugs.

To my knowledge, no Rigol representative visits this forum.
If they do, they do it quietly.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on May 14, 2017, 05:47:09 pm
I have read the manual and it's not correct behaviour. Thank you very much.

Instead of showing me a screenshot of a part of the manual that I have already read for three times, you could maybe offer
some arguments or reasoning why you think it is correct.


The maximum number of frames recorded is 5.

The maximum number of frames to be played back is set to 3.

The query to maximum number of frames that can be played back should be the number of recorded frames: 5.

The query to maximum number frames set to playback is 3.

Quote
:FUNCtion:WREPlay:FMAX?
Description Query the maximum number of frames can be played, namely the maximum number of frames recorded.

When you set the end frame for playback, you don't change the number of recorded frames.

My "argument" is that on the very next line of the manual, under the one you're throwing around, it says this:

Code: [Select]
Use the :FUNCtion:WRECord:FEND command to set the maximum number of frames
recorded.

So yes, it does change the number of recorded frames.

You may not like the function, but it's not a bug.  :popcorn:

PS: You can play back a subset of frames using the ":FUNCtion:WREPlay:FCURrent" function, or just start playing and monitor the current position.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on May 14, 2017, 06:16:17 pm
I'm not talking about :FUNCtion:WRECord:FEND.

I'm talking about :FUNCtion:WREPlay:FMAX

Changing the setting for :FUNCtion:WREPlay:FMAX has nothing todo with :FUNCtion:WRECord:FEND.

Recording and playback are two completely different things. Once you have recorded some frames (5 in the xample),
you can playback them, either all five or just one or only frame 2 to 4. This does not affect the number of frames stored in memory.

After playback has finished, you can playback again the same frames or set other values for the number of frames to playback.
Again, as long as you don't record again, the number of recorded frames stays the same.

What's so difficult  to understand about this?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: kcbrown on May 14, 2017, 08:42:27 pm
I'm not talking about :FUNCtion:WRECord:FEND.

I'm talking about :FUNCtion:WREPlay:FMAX

Changing the setting for :FUNCtion:WREPlay:FMAX has nothing todo with :FUNCtion:WRECord:FEND.

The documentation clearly claims otherwise.


Quote
Recording and playback are two completely different things. Once you have recorded some frames (5 in the xample),
you can playback them, either all five or just one or only frame 2 to 4. This does not affect the number of frames stored in memory.

After playback has finished, you can playback again the same frames or set other values for the number of frames to playback.
Again, as long as you don't record again, the number of recorded frames stays the same.

What's so difficult  to understand about this?

If the documentation says that "function A reads value X, and function B sets value X", then how is it a bug when your use of B results in A reporting the value that you handed to B?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on May 14, 2017, 10:00:16 pm
I'm not talking about :FUNCtion:WRECord:FEND.

I'm talking about :FUNCtion:WREPlay:FMAX

Changing the setting for :FUNCtion:WREPlay:FMAX has nothing todo with :FUNCtion:WRECord:FEND.

The documentation clearly claims otherwise.

No, it doesn't. Please show me where it does.

Quote
Recording and playback are two completely different things. Once you have recorded some frames (5 in the xample),
you can playback them, either all five or just one or only frame 2 to 4. This does not affect the number of frames stored in memory.

After playback has finished, you can playback again the same frames or set other values for the number of frames to playback.
Again, as long as you don't record again, the number of recorded frames stays the same.

What's so difficult  to understand about this?

If the documentation says that "function A reads value X, and function B sets value X", then how is it a bug when your use of B results in A reporting the value that you handed to B?

It doesn't. The documentation says  that "function A reads value X, and function B sets value Y".

:FUNCtion:WRECord:FEND sets or contains the number of recorded (or to be recorded) frames in memory.

Let's say, we set this value to 5. After that we start a recording. After the recording has finished, the memory contains 5 frames.

Now we can set the range of frames we want to playback by setting the start frame and the stop frame.
For that we use the commands :FUNCtion:WREPlay:FSTart and :FUNCtion:WREPlay:FEND.
Setting those commands does not alter the settings for recording.
We can playback as many times we want. We can also change the range of frames that we want to playback.
That doesn't alter the content of the memory as long as we don't start a new recording.
The maximum frame number for playback must be less than, or equal to, the max number of frames in memory.

The command :FUNCtion:WREPlay:FMAX tells us what is the maximum frame number we select for playback.
Obviously, the maximum frame number for playback must be less than, or equal to, the max number of frames in memory:

"Syntax :FUNCtion:WREPlay:FMAX?

Description Query the maximum number of frames can be played, namely the maximum number of frames recorded."

That's clear, the command returns the maximum frame number we set for the range of frames we want to playback.
Ofcourse that number can not be more than the number of frames in memory.

"Explanation Use the :FUNCtion:WRECord:FEND command to set the maximum number of frames recorded."

That's also clear. We have used this command before starting the recording in order to set the number of frames that must be
recorded.

Initially, when using the command :FUNCtion:WREPlay:FMAX? it tells us the correct maximum: the number of frames in memory.

Now let's say you use the command :FUNCtion:WREPlay:FEND to define the end frame for the range of frames to be played back,
and set it to a lower number.
When playing back again, the number of frames being played back are adjusted accordingly.

So far so good. Now use the command :FUNCtion:WREPlay:FMAX? again. Now it shows a lower number!
Somehow magically the number of frames in memory have been lowered! (Which isn't true by the way)

:FUNCtion:WREPlay:FEND != :FUNCtion:WRECord:FEND  !!

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: kcbrown on May 14, 2017, 11:32:47 pm
:FUNCtion:WREPlay:FEND != :FUNCtion:WRECord:FEND  !!

Ah.  Yes, you're right, those should be different.   My apologies.  So it appears the internals are confusing the two, which is a bug.




Sent from my iPhone using Tapatalk
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: technogeeky on May 15, 2017, 02:50:59 am
In case Rigol does ever visit: Rigol would, at this point, have nothing to lose and everything to gain by releasing/open sourcing the firmware.





. For example, if you compare the new Keysight scope which is a few hundred dollars more to the 1054z, it's a difficult decision perhaps. But if you compare the Keysight with the Rigol 1054z with open source and community improved firmware, then it's no contest. All of the features of the Keysight could easily be added to the 1054z.[/li][/list].

I don't really see the downside. The Rigol 1054z is already probably the best selling oscilloscope of all time. The software feature keying mechanism is already hacked.

Can anyone else here come up with business arguments that would make this move a clear win? Is there something I'm missing, where they will be throwing away something that Rigol considers critical?

Cheers,
-tg
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on May 15, 2017, 03:56:14 am
:FUNCtion:WREPlay:FEND != :FUNCtion:WRECord:FEND  !!
Ah.  Yes, you're right, those should be different.   My apologies.  So it appears the internals are confusing the two, which is a bug.

Oh, duh! Yes.  :palm:

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on May 15, 2017, 04:30:17 am
I had to read through that a few times, as well, since the commands are very similar looking. Perhaps the bug arose from a similar confusion during coding of the functionality. Nice bug find, Karel.

Regarding Rigol doing something because it would seem to make sense to, I have one word for it: "pluses". :horse:

Seriously, though, it would be nice to be able to fix things ourselves. But, alas, we're the minority. Hence, I'd be skeptical of it happening, but very pleased if it did.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: boggis the cat on May 15, 2017, 05:41:40 am
In case Rigol does ever visit: Rigol would, at this point, have nothing to lose and everything to gain by releasing/open sourcing the firmware.

...

Can anyone else here come up with business arguments that would make this move a clear win? Is there something I'm missing, where they will be throwing away something that Rigol considers critical?

Cheers,
-tg
I am surprised that none of the low-cost manufacturers have considered this.  After all, if your firmware is already being hacked, why not harness that work?

One argument against this would be that someone could grab that code-base and install it is their own hardware, precluding any significant software development.  This could end up with the first-mover manufacturer having both their hardware design and software copied rapidly by competitors.

Although, if the DS/MSO1xxxZ series is now due for replacement (due to Siglent's recent release -- likely to be followed up by a four channel option at minimum), then it may well be worth the experiment.  Hantek or someone lower down the quality chain might take your code, but then they're stuck on the now obsolete hardware platform so are still lagging you.

(Another argument may be that more could be squeezed from older products, thus disrupting the 'upgrade cycle'.  I don't know how big a factor this is.)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: BravoV on May 15, 2017, 06:50:31 am
Can anyone else here come up with business arguments that would make this move a clear win? Is there something I'm missing, where they will be throwing away something that Rigol considers critical?

Few that I could think of with the current opened firmware mechanism and current cost sensitive design :

1. Support cost , bricked or damaged scope caused by noob or mistake in using a custom modified firmware.

2. Related to point no.1 , the possibility of rejections or disgruntled distributors as handling product return/replacement caused by bricked modded firmware is considered a money loosing business deal for low margin product. This will hurt business relations.

2. Reputation cost, imagine a high profiled internet celebrities, but a noob that bricked the scope by mistake, and shouting out loud at the internet damaging their reputation, the cost to recover from that isn't something easily to cope with, especially with this low margin product, and also damaging effect for their overall brand's reputation.

3. Control, what this means is, they want to be "in control" on what they produced and sold, even its shitty. As there is NO GUARANTEE that opened model and publicly modded firmware will be always better.

4. Sum up all above points 1 to 3, they are big company, pretty sure the risk & gain from their business perspective, this will be not a top priority, and imo they must have something "else" better to do.


Few notes especially to point 1 if they really want to pursue this road, I think its mandatory that they need to put a clearly stated EULA, like putting on the boot screen, that a custom modded firmware will void the scope warranty. Also not sure if this is even legal at all countries ?

Also put some protection mechanism that is not easily to tamper, in order to detect if modded firmware was loaded even once, hence its easy to reject warranty claim. Not sure if this will increase the cost.  :-//
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: boggis the cat on May 15, 2017, 07:47:01 am
You could make a software check / dump part of the support / RMA process.  'Put this on USB drive, insert in product, record information on display' type deal.  If the check fails to work, then a dump of critical software could be done to determine if the problem was due to 'official' software or not.  (Posting a process to 'un-brick' the 'scope for those who do manage to do so shouldn't be too hard.  It shouldn't be possible to physically damage a 'scope via firmware -- so far as I am aware.)

If you choose to modify something then you lose warranty, unless you stick to 'sanctioned' modifications such as updates from the manufacturer.  The manufacturer could choose to use better code that is released, or just stay with a buggy 'official' version and let customers decide whether they want to tinker or not.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on May 15, 2017, 07:47:06 am
Thank you for confirming my findings related to this "new" bug. I thought it was me getting crazy...

I reported it to Rigol and I'll let you know when they respond and if they confirm the bug.

Fortunately it's not an important bug and it's possible to workaround it.
Despite that, it should be added to the buglist...
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on May 15, 2017, 07:55:34 am
All of the features of the Keysight could easily be added to the 1054z.

I believe you make the wrong assumption that the internal system (FPGA/CPU/memory) of the scope allows for that.

It's my impression that one of the reasons for the "shitty" firmware is that there's not enough space (memory/cpu-power) to implement all the features in the correct way.
They are strugling with it. Probably, the only way to improve the firmware is to throw out half of the features...

For example, the big blunder with the USB max packetsize (64 bytes instead of 512), they can't solve it because changing the
usb stack from using 64 byte buffers to 512 byte buffers requires more memory.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: BravoV on May 15, 2017, 09:50:52 am
You could make a software check / dump part of the support / RMA process.  'Put this on USB drive, insert in product, record information on display' type deal.  If the check fails to work, then a dump of critical software could be done to determine if the problem was due to 'official' software or not. 

"What if" .. the modded firmware is so bad that put the scope into infinite loop once booted ?

Assuming they released "all" including the boot code, and the user screwed the initialization code so bad that made the scope just sit there doing nothing in the deadly infinite loop.

When its time to RMA, and as usual, "few" users  >:D will be pretending innocent, and as expected, the fight dispute between seller and user on RMA ... and so on, you just need a little imagination to think of the next scenes. 


(Posting a process to 'un-brick' the 'scope for those who do manage to do so shouldn't be too hard. 

"What if" .. the un-brick process only can be done if the initialization code also is not modded, and alas, because of the low cost constraints, design wise, protecting the init code is not possible.  :-//


It shouldn't be possible to physically damage a 'scope via firmware -- so far as I am aware.)

"What if" ... the modded firmware is so shitty, forgot to switch the front end relay to switch to less sensitive input level, while the screen is prompting its ok to plug and pump in high voltage signal ?   :palm:

... another "what if" ... the over temperature mechanism is triggered, and the part of the firmware that supposed for handling the shutdown sequences is ignored or buggy ...   >:D

Too many "what ifs" ... and back to my previous post, its never about these "what ifs" scenarios anyway, the "fact" is, these scopes are selling like hot cakes, so why bother ?  :-//



Rather than sink deep in this fuss and mess, why not focus and concentrate on designing and making another new generation low cost scope, sort of DS1054Z successor, as DS1054Z is considered quite old now, and the new beast is specifically targeted to hit very hard to those new competing products.  >:D
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: boggis the cat on May 15, 2017, 10:11:05 am
"What if" .. the modded firmware is so bad that put the scope into infinite loop once booted ?

Assuming they released "all" including the boot code, and the user screwed the initialization code so bad that made the scope just sit there doing nothing in the deadly infinite loop.
The 'un-brick' option.
Quote
When its time to RMA, and as usual, "few" users  >:D will be pretending innocent, and as expected, the fight dispute between seller and user on RMA ... and so on, you just need a little imagination to think of the next scenes.
"Someone snuck into my house and flashed dodgy firmware onto my 'scope!"

Yeah...  Not seeing the big problem there.  🤔
Quote
"What if" .. the un-brick process only can be done if the initialization code also is not modded, and alas, because of the low cost constraints, design wise, protecting the init code is not possible.  :-//
Then those people 'hacking' this 'scope right now had better be careful.  I am assuming that Rigol would know a bit more about their products than the people tinkering with the firmware, so would be able to make that call.
Quote
"What if" ... the modded firmware is so shitty, forgot to switch the front end relay to switch to less sensitive input level, while the screen is prompting its ok to plug and pump in high voltage signal ?   :palm:
The DS1054Z doesn't have a 50 Ohm input.  I don't see how you could damage it through a firmware issue.
Quote
... another "what if" ... the over temperature mechanism is triggered, and the ISR for handling shutdown sequences is ignored or buggy ...   >:D
Un-bricking time again...
Quote
Too many "what ifs" ... and back to my previous post, its never about these "what ifs" scenarios anyway, the "fact" is, these scopes are selling like hot cakes, so why bother ?  :-//
To lure the adventurous / foolish into spending their cash on your now out-classed product while you prepare your next true competitor.  Money in your business, rather than your competitor's.
Quote
Rather than sink deep in this fuss and mess, why not focus and concentrate on designing and making another new generation low cost scope, sort of DS1054Z successor, as DS1054Z is considered quite old now, and the new beast is specifically targeted to hit very hard to those new competing products.  >:D
Opening up an obsoleted code base costs you nothing.  Every 'tech' site and blog will wibble excitedly about your awesome 'open' system, yada yada...

Are there possible down-sides?  Sure.  Are they significant?  I don't think so, but Rigol would decide that, not me.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: BravoV on May 15, 2017, 10:17:56 am
The 'un-brick' option.

If you mean this option is to revert the firmware back to factory's original firmware, are you absolutely sure the "current design" capable of doing that ? Of course, no hardware modding say like soldering headers to do some on board hacking firmware override.

Do you even own or even ever used this DS1000Z scope ?  :-DD
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: boggis the cat on May 15, 2017, 10:20:35 am
It's my impression that one of the reasons for the "shitty" firmware is that there's not enough space (memory/cpu-power) to implement all the features in the correct way.
They are strugling with it. Probably, the only way to improve the firmware is to throw out half of the features...
You can tell the problem is resources -- processor power is definitely lacking, tight memory possibly.

Turn on features and it slows down.  Turn on everything and it isn't really usable.  Rigol could have chosen to ration out what you can set 'on', but they obviously went for the maximum features and leave it up to the end user to decide what they're willing to trade off.

Perfectly sensible approach, but it does mean that you can't just compare feature lists then assert that this inexpensive 'scope can match another.  (Same issue as assuming that every 6000 count DMM with the same feature list is equivalent.  They really aren't.)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: boggis the cat on May 15, 2017, 10:29:10 am
The 'un-brick' option.

If you mean this option is to revert the firmware back to factory's original firmware, are you absolutely sure the "current design" capable of doing that ? Of course, no hardware modding say like soldering headers to do some on board hacking firmware override.
I have no idea.  I don't have one of these 'scopes, and have no interest in getting one.  (Maybe I will want a new 'scope later, and see no reason to not consider whatever Rigol are making then.  I don't much like the DS1054Z or variants thereof, but Rigol might put a much better 'scope on the market tomorrow, for all I know.)

Perhaps you are assuming that by "un-brick" I mean a simple process.  I mean 'whatever it takes' -- what they would do in the factory.  You could provide a series of steps from firmware updates right through to flashing the chips via the headers -- or even replacing them.  Tell some YouTube techies how it works and let them produce your 'documentation' for the processes.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on May 15, 2017, 11:19:45 am
Dudes!

It would be really nice to keep the chatting in the New Rigol D1054Z thread (https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/) and stick to strictly bug-related issues here.
That way, I have a chance in catching up with adding stuff to the first post.

I tried to establish something like a pipeline for bug reporting with Rigol here in Germany. They are aware of this forum and know that the buglists and device discussions exist. However, there was no interest in chiming in / setting up an account here.
I also tried to get in touch via the "official" Rigol feedback/forum (https://rigol.desk.com/), but that is just a waste of time.

Can someone please break down the :FUNCtion:WREPlay:FEND // :FUNCtion:WRECord:FEND issue for me? I have not used the remote commands and am not sure if I understand correctly what is going on.
To my understanding, setting the frame size should be two different variables for record and play, but both functions seem to be using the same variable. -> or something like that.. Sorry, I did not have the time to dig into what is going on yet.

Regards,
Frederik
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on May 15, 2017, 12:15:45 pm
Can someone please break down the :FUNCtion:WREPlay:FEND // :FUNCtion:WRECord:FEND issue for me? I have not used the remote commands and am not sure if I understand correctly what is going on.
To my understanding, setting the frame size should be two different variables for record and play, but both functions seem to be using the same variable. -> or something like that.. Sorry, I did not have the time to dig into what is going on yet.

I connected the scope via LAN and opened a telnet connection.

Then I enabled the record function:

Code: [Select]
:FUNC:WREC:ENAB 1

:FUNC:WREC:FEND 20

:FUNC:WREC:OPER RUN

:FUNC:WREP:FST?
1

:FUNC:WREP:FEND?
20

:FUNC:WREP:FMAX?
20

:FUNC:WREP:FEND 10

:FUNC:WREP:FMAX?
10

:FUNC:WREP:FEND 20

:FUNC:WREP:FINT?
5.000000e-01

:FUNC:WREP:OPER PLAY   (plays 20 frames)

:FUNC:WREP:FEND 10

:FUNC:WREP:OPER PLAY (plays 10 frames)

:FUNC:WREP:FMAX?
10

:FUNC:WREP:FEND 20

:FUNC:WREP:FMAX?
20

:FUNC:WREP:OPER PLAY (plays 20 frames)

The problem here is with the command :FUNC:WREP:FMAX?
It returns the value of :FUNC:WREP:FEND, not the number of frames recorded in memory (set with :FUNC:WREC:FEND).

I refer to the DS1000Z_Programming_Guide_EN_December_2015, page 91 (2-75):

Syntax
 :FUNCtion:WREPlay:FMAX?
Description
 Query the maximum number of frames can be played, namely the maximum number of
frames recorded.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: BravoV on May 15, 2017, 12:19:22 pm
@Frederik,

As an OP, I suggest you to report to moderator to clean up / delete posts from posters that don't own this scope, and clearly not even interested in this scope, but still keep doing pointless bashing here.

Its obvious this DS1000Z does and still create lots of troubles on competing brands.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: HoracioDos on May 15, 2017, 12:56:48 pm
Hello
I recently tried to connect DSRemote via USB (USBTMC) in linux and found this bug. It seems it's NOT a Linux bug. Can it be included in the list?
(Rigol Firmware Version 00.04.04.SP3)

Probably it's a bug in the firmware of the scope that triggers this error in combination with certain USB host controller chipsets.

The reason that this problem occurs on Linux is probably because the kernel developers are more strict with the USB standard.

To give you an example, connect your DS1000Z to a USB port and enter dmesg:

Code: [Select]
[  569.775078] usb 1-2: new high-speed USB device number 4 using ehci-pci
[  569.911485] usb 1-2: config 1 interface 0 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
[  569.911499] usb 1-2: config 1 interface 0 altsetting 0 bulk endpoint 0x3 has invalid maxpacket 64
[  569.911976] usb 1-2: New USB device found, idVendor=1ab1, idProduct=04ce
[  569.911987] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  569.911991] usb 1-2: Product: DS1000Z Series
[  569.911994] usb 1-2: Manufacturer: Rigol Technologies.
[  569.911998] usb 1-2: SerialNumber: DS1ZA17040xxxx
[  569.934523] usbcore: registered new interface driver usbtmc

The scope presents itself as a highspeed USB device but set the maxpacket value for the bulk endpoint to 64 bytes.

The USB standard says that a highspeed USB device MUST set that value to 512 bytes!

I reported this bug to Rigol but no answer so far.

My impression is that they don't care about Linux...

More details here:
https://github.com/Teuniz/DSRemote/issues/12#issuecomment-283940080
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on May 15, 2017, 01:31:42 pm
Hello
I recently tried to connect DSRemote via USB (USBTMC) in linux and found this bug. It seems it's NOT a Linux bug. Can it be included in the list?

Hello Horacio,

it is already listed as Bug #8, however I could add more information on this. The Problem of USB interface not being standards compatible (64 bytes instead of 512 bytes packet size) has been discussed.
I will add a more descriptive comment to that.

Regards,
Frederik
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: HoracioDos on May 15, 2017, 01:43:14 pm
it is already listed as Bug #8, however I could add more information on this.
Hi frozenfrogz!
Ohh I'm sorry for the inconvenience. I checked the list before posting but obviously I've got it wrong. Thanks!!!
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on May 15, 2017, 01:49:38 pm
No problem :)

The implications of this are not very self-explanatory.

Edit: Additional Info on USB behavior and new bug regarding telnet query has been appended to the OP.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: technogeeky on May 16, 2017, 03:26:25 am
All of the features of the Keysight could easily be added to the 1054z.

I believe you make the wrong assumption that the internal system (FPGA/CPU/memory) of the scope allows for that.

It's my impression that one of the reasons for the "shitty" firmware is that there's not enough space (memory/cpu-power) to implement all the features in the correct way.
They are strugling with it. Probably, the only way to improve the firmware is to throw out half of the features...

For example, the big blunder with the USB max packetsize (64 bytes instead of 512), they can't solve it because changing the
usb stack from using 64 byte buffers to 512 byte buffers requires more memory.

I secretly hoped this counter-argument would come up. With the slow rate of patches and relatively small list of fixes in each patch, I think we really don't have any clue as to the level of ingenuity and competence of the Rigol software engineers -- at least those who work on these devices after initial release. It is possible that there is a great deal of room for optimization, or it's possible that users would choose to turn off/disable some features selectively in order to add new features or to enhance the speed of existing features. I think this could be warped to be an argument in support of releasing the firmware open source.

Part of the problem is that nobody apparently has the ear of anyone with any clout at Rigol around here. While other manufacturers have representatives on this forum, Rigol seems to keep their distance. It would be nice for someone to step in and say: I'm not an official channel, but I have the ear of xxx of Rigol engineering and I could try to be a proxy for making this case.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: sandor626 on May 20, 2017, 05:08:00 pm
Hi,
I've updated the firmware. It's okay.
1) I downloaded the firmware from the rigol site.
2) I did the oscilloscope memory sanitization procedure.  I reboot.
3) I re-calibrated. I Reboot.
4) I installed the firmware. I Reboot.
5) I checked the extended version installed (menu, menu, force, menu) and everything was ok !
6) At that moment, two new options appeared on the calibration screen. I did not re-calibrate, I Rebbot
7) After re-boot, the two new options had disappeared . I re-calibrated , successfull after 20min.

This firmware  version is very very good . The trigger is better on small signals. The measures is better ,
stable Is better, stable, and equal between the channels .

Thanks Rigol !!


 
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Nat on June 14, 2017, 08:01:13 am
So, to experienced folks out there, should I update my DS1054z (Board Version: 0.1.4, Boot Version: 0.0.1.4, Firmware Version: 0.2.3.11, CPLD Version: 1.1) to the latest firmware, given that the only thing that bother me right now is the display mode Normal that merges with Peaks.

And, yes, I've read the whole thread, still can't make up my mind.

Thanks.

(This is my first post!, fantastic forum.).
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on June 14, 2017, 09:42:31 am
So, to experienced folks out there, should I update (...) ?

Of course I can not give you a definite answer, but as I see it, no devices were bricked by the current firmware. There is the one issue with failing calibration, however all units experiencing the described behavior could be recovered without any further trouble.
Update procedures are described above, but you already know that :)

If it was my scope I would drop in the update.

Regards,
Frederik
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Nat on June 14, 2017, 10:27:49 am
Make sens, this .gel loaded USB stick is burning my fingers anyway :)

Thanks.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: grants225 on July 07, 2017, 07:46:06 am
regarding ""pluses" - did I missed something, but yesterday I updated and see this   :-// :
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ebastler on July 07, 2017, 07:53:14 am
regarding ""pluses" - did I missed something, but yesterday I updated and see this   :-// :

I think the "pulses" in the left-hand menu have always been correct. Please enable pulse measurement and check the label on the actual read-out, at the bottom of the screen.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: psysc0rpi0n on July 07, 2017, 05:03:03 pm
I'm not sure if this post is the best place to ask my question. I'm sorry if it's not!

I have all the non-free options unlocked using a less legit way as described all over the forum here. If I update, will I lose those already unlocked options?

Side note to @Fungus:
Thanks for correcting me! I am myself pretty demanding regarding language and gramar matters. But I can only be demanding in my own mother language which is Portuguese. I like to see when people actually cares about keeping their own language sane and don't let themselves deviate from the good spelling, writing and speaking!
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on July 07, 2017, 07:37:02 pm
I'm not sure if this post is the best place to ask my question. I'm sorry if it's not!

I have all the non-free options unlocked using a less legit way as described all over the forum here. If I update, will I loose those already unlocked options?

No.

http://theoatmeal.com/comics/misspelling (http://theoatmeal.com/comics/misspelling)

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on July 07, 2017, 09:05:49 pm
I'm not sure if this post is the best place to ask my question. I'm sorry if it's not!

Everything not strictly bug related (factual and possible bugs) is being discussed in this thread (https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/3916/) over a cup of tea - sometimes even with a hint of humor.

Btw. installed options are still being kept after updating to the latest firmware.

Cheers,
Frederik

P.S. Please let me know if I should include more summarizing/general info regarding the scope in the opening post.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: psysc0rpi0n on July 08, 2017, 09:30:16 am

P.S. Please let me know if I should include more summarizing/general info regarding the scope in the opening post.

Was this to me? I didn't understood! Do you want to know the scope I own so that you add it to the 1st post, is that it?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on July 08, 2017, 11:10:26 am

P.S. Please let me know if I should include more summarizing/general info regarding the scope in the opening post.
Was this to me?

Sort of...  I try to maintain the opening post as comprehensive and self explanatory as possible so that general discussions can take place in the thread mentioned before and bug related discussion has a dedicated space here. I am open to suggestions for making that more clear in the OP.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: PeLa on July 23, 2017, 12:27:12 pm
I am surprised that I could not find any reference to the following bug in the list yet:

When setting the number of averages using :ACQuire:AVERages <int>
and setting acquisition mode to :ACQuire:TYPE AVERages and :RUN the scope,
there is no way to find out how many averages have been acquired.

So if I want to acquire a certain number of averages of an event that only occurs every now and then, I have no way to find out via a query sent to the scope.

The closest I can get to finding out whether an acquisition of a certain number of averages has finished is to look at the number of counts displayed on the screen by enabling any statistics item in diff mode. This can be done by sending the following command sequence prior to starting the acquisition with :RUN

:STOP
:MEASure:STATistic:MODE DIFF
:MEASure:STATistic:ITEM VPP,CHANNEL1
:MEASure:STATistic:DISPlay 1
:MEASure:STATistic:RESet
:RUN

As soon as triggers come in the "cnt" will be displayed in the statistics on the screen. However this value cannot be read. The only valid commands to read statistic items are MAXimum|MINimum|CURRent|AVERages|DEViation. No counts. |O

I have interfaced HP/Agilent/Keysight and Tektronix scopes before in my day job. - I never came across a scope that wouldn't tell you how many averages it has acquired (Tektronix) or if the acquisition of a certain number of averages is complete (HP/Agilent/Keysight)

00.04.04.03.02 software
0.0.1.4 Boot version
0.2.3.11 firmware


Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ebastler on July 23, 2017, 04:39:29 pm
I am surprised that I could not find any reference to the following bug in the list yet:

I am not.  ;)

I won't call it an arcane usage scenario, but is is certainly not a common one. And while I agree that it would be nice if there were a command to poll the number of averages taken, I don't think the lack of it qualifies as a bug, since the documentation doesn't promise such functionality anywhere.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: PeLa on July 23, 2017, 06:27:08 pm
If a digitising scope is unable to tell me whether an acquisition has finished, so that I can go ahead and start the data transfer, that is a bug in my eyes. The number of averages is not required but might be the easiest way to implement as solution.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on July 23, 2017, 09:59:04 pm
I don't think the lack of it qualifies as a bug, since the documentation doesn't promise such functionality anywhere.

Correct. It is a deficiency, as compared to other products, and a feature that seems logical to have for the use case described, but it's not a bug.

By contrast, having a label that says "Pluses" instead of "Pulses" for pulse-related functionality is a bug. :horse:

Just a matter of semantics? Absolutely. The meanings are important.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on July 23, 2017, 10:14:33 pm
Sooo.. does it qualify for a wish list item?

I do not really use the remote interface and thus am a little ambivalent towards everything related to that :)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on July 23, 2017, 10:17:18 pm
It's a feature request, yes.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: PeLa on July 24, 2017, 11:02:27 pm
Thanks for your help guys. I'll leave you to make the decision, whether it goes into any list. It does look like I am asking for a niche feature for this oscilloscope, since nobody else chipped in. What a shame.

It was one of the features that I just assumed every digitising scope has to have because it is (at least in my field) absolutely essential for data acquisition and transfer. I learned the lesson.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on July 24, 2017, 11:49:34 pm
Sure thing. Thanks for chiming in, PeLa. We can't all know about every industry's use cases.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: RoGeorge on September 07, 2017, 11:27:36 pm
NEW BUG (Software 00.04.04.SP3, Board 0.1.1): When a bad SCPI command is followed by at least one other command, then querying the error queue using ":SYST:ERR?" will lead to unresponsive (hang) SCPI over TCP/IP (LXI) until the next power cycle.
Note: This will not happen for any bad command, so far I found that commands that make the oscilloscope to display "Function Limited!" or "Invalid Input!" will trigger this kind of bug. I didn't test it for USB/SCPI commands.

Steps to reproduce:
1. Connect a Rigol DS1054Z to LAN, then start Netcat by typing in a terminal:
nc 192.168.1.3 5555

3. In the NetCat, type
:WAV:STAR 0

4. Now type at least one more SCPI command, good or bad, for example
:WAV:STAR 1

5. SCPI apparently is still working, until you type:
:SYST:ERR?

6. Now the oscilloscope won't respond to any other SCPI command, and it won't accept new TCP connections until the next power cycle.

Rigol, please fix it.
 :-BROKE



Example
Code: [Select]
:WAV:MODE:NORM
:syst:err?
-113,"Undefined header; keyword cannot be found"

:WAV:MODE NORM
:syst:err?
0,"No error"

:WAV:MODE STAR 1201
:syst:err?
-220,"Parameter error"
:syst:err?
0,"No error"
So far all good, as expected.

Now, try this:
Code: [Select]
:WAV:STAR 1201
:WAV:STAR 120
:syst:err?
That's it, after the last ':SYST:ERR?' SCPI hangs, and no other SCPI commands will work until the next power on.

Later edit:
It would be useful if anybody else can reproduce this, please. Does your DS1000Z hangs, too?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: zbyr on September 08, 2017, 11:44:39 am
Yup. Bug also exist in SCPI with USB connection.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: RoGeorge on September 08, 2017, 01:06:30 pm
Thank you for testing it.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on September 08, 2017, 01:32:07 pm
Regarding the scpi command bug, is somebody going to report it to Rigol and post the date of reporting and contact details (Rigol NA/Europe/etc, name of Rigol contact person) here?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: SparkyM8 on September 08, 2017, 01:50:51 pm
So if I want to acquire a certain number of averages of an event that only occurs every now and then, I have no way to find out via a query sent to the scope.

PeLa are you checking the OPC bit?

OPC should not be set to 1 until the operation is complete. Certainly, whenever I have programmed Agilent spectrum analysers with averaging involved OPC does not go high until all averages have been collected.
This aspect is not only desirable, it is usually essential, because the connection will probably timeout and halt your program if you ask for a response before all the data are collected.
Normally you would put the program into a timer loop, checking OPC with every pass, and jump out when it goes high then collect the data.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: RoGeorge on September 08, 2017, 02:02:19 pm
Regarding the scpi command bug, is somebody going to report it to Rigol and post the date of reporting and contact details (Rigol NA/Europe/etc, name of Rigol contact person) here?

Not me.
Just in case more details about versions are required, I am attaching them here. The SN was partially deleted by me.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on September 09, 2017, 11:50:59 am
Original posting has been updated with info on SCPI lock up.

Regards,
Frederik
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: rob040 on October 10, 2017, 03:10:04 pm
Today I've received a reply on my mail to Rigol asking for a release date of the new software. I was asking for that after reading this threat.
Reply came from Rigol EU, but not giving a date. I also referred to the long existing typo "Pluses" and the answer on that was that it was first time reported to Rigol only 5 weeks ago.  :-//
So, if there will be a new release, at least that should be solved... The rest will be a surprise.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on October 10, 2017, 10:04:30 pm
I also referred to the long existing typo "Pluses" and the answer on that was that it was first time reported to Rigol only 5 weeks ago.  :-//

Hmmm. Fascinating.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Wall-E on October 10, 2017, 10:51:14 pm
Today I've received a reply on my mail to Rigol asking for a release date of the new software. I was asking for that after reading this threat.
Reply came from Rigol EU, but not giving a date. I also referred to the long existing typo "Pluses" and the answer on that was that it was first time reported to Rigol only 5 weeks ago.  :-//
So, if there will be a new release, at least that should be solved... The rest will be a surprise.

Rigol told me that if they only get a couple of complaints its is generally ignored and not thought about as necessarily being a significant issue to be concerned with, or taken that seriously.  But when they receive multiple reports, say over  10, 25 and more on a new active product it is indeed taken seriously.  Right now most of the Rigol equipment is mature enough that it isn't a active design product, and as a result it takes a lot of complaints, possibly hundreds, to get anything changed in the firmware.  After all the software teams are off on to the next product designs.  That's not hard to understand for any progressive business organization with new designs in the works to enhance their product line.

So guys we need to get together and each chime in when a issue is found if we want to have any action taken.  Is this so unexpected.  We all need to do our share of bitching to get something done.  Don't just let it go because someone has submitted a technical support issue.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on October 11, 2017, 06:27:19 am
That's not hard to understand for any progressive business organization with new designs in the works to enhance their product line.

On the contrary, it is very hard to understand from a test & measurement company that claims:

"Uncompromised Performance… Unprecedented Value"

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ebastler on October 11, 2017, 07:13:23 pm
On the contrary, it is very hard to understand from a test & measurement company that claims:

"Uncompromised Performance… Unprecedented Value"

Well, you know what "value" means in marketing-speak, right? It's a euphemism for "cheap".  :P

But, seriously: Of course Rigol will have to triage, and will not fix all issues. Otherwise they would never get around to releasing further new products once they have to sustain a few existing products in the market.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on October 21, 2017, 12:41:52 pm
I want to add another bug. The DS1000Z series does not display the full vertical resolution, it clips it at 80%.
The 8-bit ADC produces 8-bit samples which have 2^8 = 256 possible values. Only 200 of them are visible on the display,
the rest is cut-off.
Downloading the waveform sample data will give you acces to the full vertical resolution.
Have a look at the screenshots, one is made internally in the scope and shows the clipped waveform.
By using DSRemote you can view the full dynamic range of the ADC. It's an increase of dynamic range of 25%!
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on October 21, 2017, 02:52:40 pm
I want to add another bug. The DS1000Z series does not display the full vertical resolution, it clips it at 80%.

I think you are mistaken (or I do not fully understand).
My guess is, that you have not yet figured out that you can set the division from coarse to fine. »coarse« jumps from 1V/div to 2V/div whereas »fine« lets you also select various zoom factors between 1 and 2 volts (or which ever range you are in).

Edit: In case you did not notice: The screen of the 1054Z gives you 8 vertical divisions while the emulated 1104Z screen shows 10 vertical divisions, hence can show the full waveform without clipping at 2V/div.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on October 21, 2017, 03:40:55 pm
I want to add another bug. The DS1000Z series does not display the full vertical resolution, it clips it at 80%.

I think you are mistaken (or I do not fully understand).

The latter, you do not fully understand. I will try to explain better.

The scope and DSRemote use the same settings.
The waveform you see with DSRemote is downloaded from the scope at the very moment that scope was displaying
the clipped sinewave.

And yes, DSRemote shows more divisions in vertical direction because it can utilize the full 8-bit or 256 steps.
The scope's display instead, is using only 200 steps of the same waveform data.

Ofcourse, you can adjust the vertical scale of the scope to make the sinewave fit, but that's not my point.
My point is that the scope is not using the full dynamic range of the adc.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on October 21, 2017, 04:43:13 pm
So basically you are saying, that there is a mismatch between displayed divisions and actual ADC gain setting / range?

Namely:

8 div@2V: 16V/256 = 0.06V expected resolution
10 div@2V: 20V/256 = 0.08V true resolution *

*where true gain setting might have to be determined via experiments
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on October 21, 2017, 05:36:43 pm
Yes. Also, it's kind of a "documented bug". If you take a look at the programming guide 2 - 223 (page 239)
there's written that the "Yincrement" steps are verticalscale / 25.

For example, the 4000 and 6000 series don't suffer from this limitation.
In their respective programming guides they specify that "Yincrement" steps are verticalscale / 32.

Which is weird because the 4000 series uses a display with the same number of pixels.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on October 21, 2017, 05:42:35 pm
Karel, this is interesting. I normally use the built-in screen and so never noticed the discrepancy. I wonder what they gained or saved by truncating the screen rather than scaling it to fit. Just a case of ease of implementation?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on October 21, 2017, 06:29:52 pm
Karel, this is interesting. I normally use the built-in screen and so never noticed the discrepancy. I wonder what they gained or saved by truncating the screen rather than scaling it to fit. Just a case of ease of implementation?

Probably because "200" maps to a 400 pixel display very easily in hardware but "256" doesn't.

I would be interesting to know if any other 'scopes do this. It wouldn't be the first time somebody points a finger at the DS1054Z only to find out that many other 'scopes do it as well.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on October 21, 2017, 07:13:39 pm
Yeah, ease of implementation.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on October 21, 2017, 07:51:32 pm
Karel, this is interesting. I normally use the built-in screen and so never noticed the discrepancy. I wonder what they gained or saved by truncating the screen rather than scaling it to fit. Just a case of ease of implementation?

Probably because "200" maps to a 400 pixel display very easily in hardware but "256" doesn't.

Then why didn't they do it with the 4000 series which uses the same resolution?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on October 21, 2017, 09:40:00 pm
Good question. I dunno.

- Product differentiation? Pay more, get more/better.
- Processing limitation?
- Not sharing code between models?
- Implemented by different team?
- Something else? :-//

I wouldn't think it's to avoid quantization error from fitting 256 values across 400 pixels. Scopes aren't so accurate for that to matter so much anyway.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on October 21, 2017, 09:43:57 pm
Then why didn't they do it with the 4000 series which uses the same resolution?

Bigger FPGA, more free gates?

Who knows...?

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: technogeeky on October 21, 2017, 10:00:32 pm
Karel, this is interesting. I normally use the built-in screen and so never noticed the discrepancy. I wonder what they gained or saved by truncating the screen rather than scaling it to fit. Just a case of ease of implementation?

There is a kind of hidden feature in this somewhat-bug. One of the annoying limitations of the 1054z is that you can't hide a waveform that you are using as a source of data like you can on other scopes. For instance, if you are doing some MATH function (say, FFT) on a trace you can't turn it off to hide it, and just see the result.

But this way, as long as your trace is small, you can hide it just off screen!

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on October 21, 2017, 10:09:30 pm
LOL, nice side effect, technogeeky. The down side, though, is that you sacrifice the resolution of your input to that math function by allowing the "hidden" signal to be small enough to fit within that small space up (or down) there.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on October 27, 2017, 12:43:51 pm
Since I was quite busy the last couple of days I added the ADC gain <-> display mismatch bug to the OP just today.

In case you have a better description in mind, please let me know :)

The OP needs some work to become untangled and more approachable in my opinion and I am thinking about sorting the bug list by matter of importance // urgency. Maybe I can do it this weekend, but I can not make any promises.

Regards,
Frederik
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: metrologist on October 27, 2017, 02:05:43 pm
Yes. Also, it's kind of a "documented bug". If you take a look at the programming guide 2 - 223 (page 239)
there's written that the "Yincrement" steps are verticalscale / 25.

For example, the 4000 and 6000 series don't suffer from this limitation.
In their respective programming guides they specify that "Yincrement" steps are verticalscale / 32.

Which is weird because the 4000 series uses a display with the same number of pixels.

The specifications state that the vertical resolution is 8 bits. How does DSRemote get all 8 bits? Is it using Raw mode?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: RoGeorge on October 27, 2017, 02:58:58 pm
The vertical resolution is 8 bits. It doesn't says all 256 values must fit on one screen.
As a parallel situation, it would be unfair to consider the time zoom feature as a bug, just because it doesn't fit all the samples in the same screen without scrolling, right?

I see this 8 divisions instead of 10 as a display limitation, not as a bug. Yes, it could have been better, with 10 divisions drawn on the screen, but it's not.

One more thing, only 8 horizontal divisions instead of 10 is nothing when compared with only half resolution on some voltage ranges (as in 7 bits instead of 8 bits). I remember there were certain voltage ranges where the values were all odd when read by SCPI, which led me to the conclusion that some voltage ranges were just simulated in software by a x2 multiplication, instead of using a real voltage divider in the analog path of the measured signal.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: metrologist on October 27, 2017, 03:08:30 pm
But how do you qualify the vertical resolution as being 8 bits? It seems there is only one way to get the full 8 bits out of the device, via SCPI in RAW mode, which presents other limitations.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on October 27, 2017, 03:15:02 pm
Yes. Also, it's kind of a "documented bug". If you take a look at the programming guide 2 - 223 (page 239)
there's written that the "Yincrement" steps are verticalscale / 25.

For example, the 4000 and 6000 series don't suffer from this limitation.
In their respective programming guides they specify that "Yincrement" steps are verticalscale / 32.

Which is weird because the 4000 series uses a display with the same number of pixels.

The specifications state that the vertical resolution is 8 bits. How does DSRemote get all 8 bits? Is it using Raw mode?

It uses the ":WAVeform:DATA?" command as described in Rigols programming guide.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on October 27, 2017, 03:20:59 pm
I see this 8 divisions instead of 10 as a display limitation, not as a bug. Yes, it could have been better, with 10 divisions drawn on the screen, but it's not.

The problem is not the number of divisions on the screen. The problem is that the scope is not able to display the full dynamic range of the adc.
It shows max 200 steps instead of 256. In other words, the vertical steps (as displayed on the screen) become unnecessary course.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: metrologist on October 27, 2017, 03:25:49 pm
Yes. Also, it's kind of a "documented bug". If you take a look at the programming guide 2 - 223 (page 239)
there's written that the "Yincrement" steps are verticalscale / 25.

For example, the 4000 and 6000 series don't suffer from this limitation.
In their respective programming guides they specify that "Yincrement" steps are verticalscale / 32.

Which is weird because the 4000 series uses a display with the same number of pixels.

The specifications state that the vertical resolution is 8 bits. How does DSRemote get all 8 bits? Is it using Raw mode?

It uses the ":WAVeform:DATA?" command as described in Rigols programming guide.

But then must it issue :WAV:MODE RAW beforehand? Otherwise, YINC is /25.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on October 27, 2017, 04:08:51 pm
Yes. Also, it's kind of a "documented bug". If you take a look at the programming guide 2 - 223 (page 239)
there's written that the "Yincrement" steps are verticalscale / 25.

For example, the 4000 and 6000 series don't suffer from this limitation.
In their respective programming guides they specify that "Yincrement" steps are verticalscale / 32.

Which is weird because the 4000 series uses a display with the same number of pixels.

The specifications state that the vertical resolution is 8 bits. How does DSRemote get all 8 bits? Is it using Raw mode?

It uses the ":WAVeform:DATA?" command as described in Rigols programming guide.

But then must it issue :WAV:MODE RAW beforehand? Otherwise, YINC is /25.

Normal mode. And indeed YINC is 25/division, which is actually the problem because, apparently, the scopes display uses also 25 steps per division. Not 32 steps per division like the 4000 series.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: metrologist on October 27, 2017, 04:17:08 pm
So then, how did DSRemote get the info for the extra divisions? In normal mode, it would only receive the display data.

Edit:
page 2-218: "NORMal: read the waveform data displayed on the screen."
and reference the illustrations on page 2-216...

I was also just looking at some screen dumps and every displayed sample uses two vertical pixels. The graticule is 400 pixels tall, with the bottom division's 50 pixels encorporate both the bottom and it's top graticule lines; all other division's 50 pixels seem to start just above the graticule line and encorporate just the top graticule line. So, there is the ease of implementation for the display.

And, how do we qualify 8-bit vertical resolution? I seem to recall that the measurements use display data for the calculations, so we actually do not have 8 bit resolution. Who's to quibble over a few (56) bits?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on October 27, 2017, 05:31:02 pm
So then, how did DSRemote get the info for the extra divisions? In normal mode, it would only receive the display data.

When requesting the display data in normal mode, the scope will send 1200 samples (200 for every horizontal division).
Every sample is transmitted as one byte (when format is set to byte). So every sample contains 2^8=256 vertical steps which is the full dynamic range of the adc.


Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: metrologist on October 27, 2017, 05:59:57 pm
So then I don't understand the point of having a mode setting, at least not the RAW setting. Seems you could set the format to WORD and get the same information (range). Anyway, that's off topic now.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on October 27, 2017, 06:17:04 pm
Since I was quite busy the last couple of days I added the ADC gain <-> display mismatch bug to the OP just today.


Is it definitely a bug then? A "bug" implies it's something unintentional that needs fixing with a firmware update. If it's due to a hardware limitation then it's not really a bug (in my book). Even if it's done deliberately due to a marketing decision, then ... it's still not really a bug as such.

The vertical resolution is 8 bits. It doesn't says all 256 values must fit on one screen.

What happens if you freeze the display and move it up/down. Does the extra signal scroll into view?

If it does then it's not a bug, it's a feature.  :popcorn:

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on October 27, 2017, 06:38:40 pm
What happens if you freeze the display and move it up/down. Does the extra signal scroll into view?

Good question, I just tried. You can scroll into view.

But still, it makes no sense. Why not showing the whole waveform when it's running?
The 4000 series has the same display resolution and they do it correctly i.e. they show the whole waveform when running.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on October 27, 2017, 06:56:56 pm
What happens if you freeze the display and move it up/down. Does the extra signal scroll into view?

Good question, I just tried. You can scroll into view.

It's a feature! R&S charge extra for their "virtual screen" function (which basically does the same thing).


But still, it makes no sense. Why not showing the whole waveform when it's running?
The 4000 series has the same display resolution and they do it correctly i.e. they show the whole waveform when running.

Must be a hardware limitation. If 200 pixels are visible then they're obviously just dividing by two in the display logic instead of fully scaling the values. Maybe they ran out of gates in the FPGA or it would be much slower or something. Only Rigol knows for sure. The 4000 series will have a more powerful chipset.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: metrologist on October 27, 2017, 07:02:37 pm
I'm not sure what to make of it. The example has a 20Vp-p signal with the graticule set to show 16V, 2V/div, but DSRemote has the graticule set to show 20Vp-p. Perhaps the bug is DSRemote not using the same display range as the scope? Of course, then you could argue that it would be using 1.6V/div, which also does not match the scope.

What would DSRemote display with the 4000 series? What happens at the 16V graticule line? Does it clip there as it would on the scope display?

I guess since the data is there and can be moved into view, that is considered display data and is used for the measurements, and is therefore still 8 bits. You just don't get to see them all at once. That introduces some uncertainty since I generally try to maximize my signal for best accuracy, so do I now need to maximize it beyond the display region go get the highest accuracy?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on October 27, 2017, 07:40:17 pm
Perhaps the bug is DSRemote not using the same display range as the scope?

There's a setting in DSRemote where you can change this behaviour. You can select to let DSRemote show exactly the same
as the scopes display with the same number of vertical divisions.
With DSRemote you simply have the option to show more divisions and the complete waveform.

What would DSRemote display with the 4000 series? What happens at the 16V graticule line? Does it clip there as it would on the scope display?

The 4000 and 6000 series show the complete waveform. At least they specify 32 steps per vertical division.
So, with eight vertical divisions, there are 256 steps on the scopes display. Exactly what fits in one byte and what should come out of the adc.
For obvious reasons, DSRemote shows exactly the same with the 4000 and 6000 series. There's no option to extend the vertical range.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: metrologist on October 27, 2017, 07:47:39 pm
So DSRemote only shows 8 divisions with the 4/6000 series? The complete waveform would be clipped on the display, if you set it the same way as the 1054.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on October 27, 2017, 10:04:52 pm
Correct. The 4000/6000 series scale the 256 values to fit into 8 divisions. The 1054Z, on the other hand, clips values above and below the 200 that will appear on the screen. In other words, it's as if the screen had 10 vertical divisions, but the top and bottom division are simply not visible on the device.

As Fungus said, it's as if the 1054Z was permanently zoomed in. So, you can pan the view port up and down by one division to see the data that is out of view.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on October 28, 2017, 06:25:16 am
Correct. The 4000/6000 series scale the 256 values to fit into 8 divisions. The 1054Z, on the other hand, clips values above and below the 200 that will appear on the screen. In other words, it's as if the screen had 10 vertical divisions, but the top and bottom division are simply not visible on the device.

As Fungus said, it's as if the 1054Z was permanently zoomed in. So, you can pan the view port up and down by one division to see the data that is out of view.

Correct. Ofcourse there can be debate whether or not this is a bug. It could be very well that, like Fungus wrote before, it's a hardware limitation i.e Rigol cut some corners to keep the price acceptable and this is all done by purpose.

I just wanted to bring it up here and will let it up to others if it should be added to the buglist or not.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: TD-Linux on October 28, 2017, 06:38:23 am
I wouldn't think it's to avoid quantization error from fitting 256 values across 400 pixels. Scopes aren't so accurate for that to matter so much anyway.

Yeah, normally this would be nonissue - you increase precision when downsampling memory for display, or averaging for persistence, and can utilize it when drawing lines on the display and often you have at least 1 lsb of noise anyway. One possible reason is that they may be really trying to cheap out on the math - nearest downsampling, or quantizing the output of their filters back to 8 bits before processing for display. You'd think in this day and age that sparing a few extra bits in your adders and multipliers would be cheaper than throwing away 10% of your expensive ADC's dynamic range... alas, after seeing that pitiful FFT, maybe there's a stock shortage of multipliers at Rigol.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on October 28, 2017, 07:29:38 am
My vote is that it's simply a consequence of minimizing cost (i.e., by design).

I'm just glad to know that there's more data above and below the display that I can access. Thanks for the revelation, Karel.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on October 28, 2017, 07:57:57 am
I am going to keep it in the bug list and sort the issues later. I think it belongs into the "oddities" category, meaning »things you need to know about your scope« such as that the math / decode / ... functions use the screen data instead of the recorded memory.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bd139 on October 28, 2017, 09:55:52 am
I think that’s my biggest annoyance. In the math functions it defaults to using the display as a source. So if I want any resolution in the math functions, I have to change the memory depth and frig the math source every bloody time and then set it back to auto when I’m done.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: RoGeorge on October 28, 2017, 10:34:56 am
I am going to keep it in the bug list and sort the issues later.

I wouldn't mix the 'bugs list' with the 'wish list', because this will make the rest of the real bugs to look less credible. 8 divisions on the vertical screen is not a bug.

Even more, do I want a grid of rectangles instead of squares, or fuzzy reticles, or a slower display because of the required interpolation? Probably not.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on October 28, 2017, 10:48:34 am
I wouldn't mix the 'bugs list' with the 'wish list'

That is what I meant with the OP needing some sorting out and reformatting.

The bug list will be reorganized by severity / urgency and quirky feature issues that are not real bugs have to be moved into a separate list - maybe as wish list items (that I had not touched yet :) )
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on October 28, 2017, 12:34:22 pm
8 divisions on the vertical screen is not a bug.

That was not the issue. Nobody here, including me, cares about the number of vertical divisions.
The issue is/was that the scopes display isn't showing the complete waveform as captured by the adc,
i.e. the dynamic range is (unnecessary) limited.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: lundmar on October 28, 2017, 10:57:45 pm

Now, try this:
Code: [Select]
:WAV:STAR 1201
:WAV:STAR 120
:syst:err?
That's it, after the last ':SYST:ERR?' SCPI hangs, and no other SCPI commands will work until the next power on.

Later edit:
It would be useful if anybody else can reproduce this, please. Does your DS1000Z hangs, too?

I can confirm that this sequence of SCPI commands results in the ":syst:err?" command hanging. I can also confirm that the hanging command ends up blocking the telnet/nc connection on port 5555.

That being said, the best way to fire SCPI commands to any LXI enabled device is to use tools that use the VXI11 protocol to communicate/handle the commands. In case of the hanging command, using the VXI11 protocol simply results in the command timing out and then you can continue sending commands - no need to restart the instrument. As demonstrated here using the wonderful/fantastic/amazing lxi-tools:

Code: [Select]
$ lxi scpi --address 192.168.1.210 --timeout 5 --script crash-test.scpi
Connected to 192.168.1.210
Running script crash-test.scpi

:WAV:MODE:NORM
:syst:err?
-113,"Undefined header; keyword cannot be found"

:WAV:STAR 1201
:WAV:STAR 120
:syst:err?
Error: Read error (timeout)
Error: Failed to receive message

*IDN?
RIGOL TECHNOLOGIES,DS1104Z,DS1ZA171206207,00.04.04.SP3

With nc/telnet you don't get any timeout management etc. - it is less robust and it results in locking up your instrument when you hit buggy commands.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: RoGeorge on October 29, 2017, 08:50:44 am
8 divisions on the vertical screen is not a bug.
The issue is/was that the scopes display isn't showing the complete waveform as captured by the adc,
i.e. the dynamic range is (unnecessary) limited.

"8 divisions" is just a bad name I choose in order to refer to your findings, I understand the complain is about why keeping some margins outside the viewing area. Sorry about the bad name I used. What I am trying to say is that it's not a bug.

A bug is something unintended, a side effect that the designer didn't planed for. Your findings is not something unintended by design. It was intentionally designed and implemented to be exactly how it is now, so not a bug.

...the best way to fire SCPI commands to any LXI enabled device is to use tools that use the VXI11 protocol to communicate/handle the commands. In case of the hanging command, using the VXI11 protocol simply results in the command timing out and then you can continue sending commands - no need to restart the instrument.
...
With nc/telnet you don't get any timeout management etc. - it is less robust and it results in locking up your instrument when you hit buggy commands.

That's a very interesting finding, thank you for testing the hang!

AFAIK it should work without VXI, so I will try your code in order to see what are the main differences introduced by using VXI11.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: lundmar on October 29, 2017, 09:19:55 am
That's a very interesting finding, thank you for testing the hang!

AFAIK it should work without VXI, so I will try your code in order to see what are the main differences introduced by using VXI11.

No problem. I just upgraded to the latest 1000z firmware and I wanted to test the updated LXI module to make sure it is ok. Luckily nothing is really broken. It's just missing error handling that makes some specific commands hang - still something for Rigol to fix though.

If you do take lxi-tools for a test spin please install the latest versions of liblxi and lxi-tools from https://lxi.github.io - the latest versions contains new features and many bug fixes but it is now in a pretty good state. I'm quite happy with how it works. Finally we have a solid commandline tool for Linux to talk to our various instruments.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on October 29, 2017, 09:31:09 am
That being said, the best way to fire SCPI commands to any LXI enabled device is to use tools that use the VXI11 protocol to communicate/handle the commands.

I don't agree. The fact that the TCP-socket implementation of the Rigol is buggy, doesn't make the VXI-11 protocol necessary better in general. You could only say that it's a workaround for the buggy Rigol.

Unfortunately, VXI-11 creates more overhead and is slower. I quote:

Quote
VXI-11 or TCP sockets: Which should you use?

VXI-11 is used exclusively if you are accessing GPIB instruments through a LAN-to-GPIB gateway like the
Agilent E5810A or if you are using a PC as a gateway. However, many native LAN instruments support both
VXI-11 and TCP socket communication. Which is the better option?

Often, it is a matter of preference. However, VXI-11 is the more complex (higher-layer) protocol.
Consequently, direct socket communication will provide better performance in many situations,
especially if the actual measurement time is short and you conduct many individual transactions.
Furthermore, as the examples in this document will show, sockets are considerably easier to use.
Therefore, if they are supported by the instrument, sockets are the recommended approach for native
LAN instruments.

literature.cdn.keysight.com/litweb/pdf/5989-6717EN.pdf (http://literature.cdn.keysight.com/litweb/pdf/5989-6717EN.pdf)


Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: lundmar on October 29, 2017, 11:53:18 am
That being said, the best way to fire SCPI commands to any LXI enabled device is to use tools that use the VXI11 protocol to communicate/handle the commands.
I don't agree. The fact that the TCP-socket implementation of the Rigol is buggy, doesn't make the VXI-11 protocol necessary better in general. You could only say that it's a workaround for the buggy Rigol.

Unfortunately, VXI-11 creates more overhead and is slower.

True, issuing SCPI via raw TCP-sockets is faster but you compromise as you don't get any timeout management which is key to handling troublesome SCPI commands or when doing production optimization etc. - whether you need it or not depends on your use case of course. Even then, the performance difference for doing basic stuff is negligible. However, when you start transferring large amounts of SCPI data at higher network speeds thats when you really start to suffer the overhead. This is why new LXI enabled instruments are now replacing VXI11 with HiSlip which is basically as fast as using raw TCP-sockets but it comes with the same basic protocol mechanisms for controlling e.g. command timeout - its just a more modern message protocol. I'm planning to implement this protocol for liblxi so we can have first class open source HiSlip support on Linux.

Here is an interesting raw TCP vs.VXI vs. HiSlip comparison made by R&S:
(https://i.imgur.com/3RcLaEM.png)

It is speculation of course, but I don't think it is the TCP-socket of the Rigol that is actually failing. I think it is simply the internal command error handling or interpreter for this specific command that fails and it ends up blocking the single command channel which is mapped to port 5555. Likely Rigol does not enable any timeout handling for commands coming in on this port and that is why it stays locked up when a command stalls. For the VXI channel(s) stalling commands are handled as every command call (RPC call) includes a timeout defined by the caller and it seems the Rigol complies with that part of the protocol.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: RoGeorge on October 29, 2017, 03:15:42 pm
If you do take lxi-tools for a test spin please install the latest versions of liblxi and lxi-tools from https://lxi.github.io

I just did, then sniffed the actual LAN data packets using Wireshark.

First, lxi-tools is a very nice and useful tool, thank you for making it available.  :-+

Second, I found it very hard to install, even if I'm familiar with Linux. By familiar I mean able to follow README instructions, and able to use the command line, but not being a Linux developer. The problem was that there were no binary, so I need to compile from sources. In the README file it says "./configure", "make", "make install", which won't work, because there is no "./configure". By looking inside various files I realized that I should generate the ./config file myself, then after a lot of googling I found out about autoreconf and so on.
 :horse:
This is probably trivial for any Linux developer, but it was not for me. IMHO the build and installation instruction should have been something like these:
Code: [Select]
cd ~
mkdir lxi-tools
cd lxi-tools/
git clone https://github.com/lxi/liblxi
cd liblxi/
su
apt-get update
apt-get install automake
apt-get install autogen autoconf libtool

./autogen.sh
./configure
make
make install
cd ..

git clone https://github.com/lxi/lxi-tools
cd lxi-tools/
./autogen.sh

apt-get install libreadline-dev

./configure
make
make install

export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/lib"

lxi
For my Debian 8, some of the build tools were not installed by default.

Third, the lxi-tool is using a different protocol, VXI-11, and different ports. lxi-tools is not using TCP/5555, I guess that is why the hang is not reproducible when using VXI-11.

TBH, the DS1000Z specifications are "Conform to LXI CORE 2011 DEVICE class instrument standards", and I couldn't find any mention in the Rigol DS1000Z manuals about using TCP and port 5555, like in a remote SCPI sent by Telnet or Netcat/TCP.

Unless LXI CORE 2011 requires SCPI to work over a raw TCP socket (it might require, but at a draft look I couldn't find any required feature about plain SCPI text sent over LAN), I guess SCPI text sent over a raw TCP socket is just an undocumented feature, so even if the TCP hangs when using netcat, then we can not file a bug about it.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on October 29, 2017, 04:08:51 pm
Unless LXI CORE 2011 requires SCPI to work over a raw TCP socket (it might require, but at a draft look I couldn't find any required feature about plain SCPI text sent over LAN), I guess SCPI text sent over a raw TCP socket is just an undocumented feature, so even if the TCP hangs when using netcat, then we can not file a bug about it.

Why not? For Rigol it makes no difference if some feature is documented or not. If they feel like fixing it they'll fix it.
If they don't feel like fixing it, then they don't.

For example, the USB max packet size is clearly documented but they don't feel like fixing the USB max packet size bug in their firmware...

There are also three bugs still open for the DS6000 series which have been reported and confirmed by Rigol long time ago and they don't care...

Edit:

According to Keysight it is:

Quote
In 2000, the VXIplug&play Alliance added support for LAN-based instruments to its VISA specifications.
Two popular methods of instrument control via Ethernet were adopted by VISA:
VXI-113 and “direct” TCP socket communication


Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: lundmar on October 29, 2017, 04:37:33 pm
First, lxi-tools is a very nice and useful tool, thank you for making it available.  :-+

I'm glad you like it. I try hard to make it a simple to use tool and library  :D

I hope some people in this forum might contribute some screenshot plugins so that the lxi tool can include screenshot support for more instruments. I've made it pretty easy to write a new screenshot plugin for the lxi tool but I don't have the instruments to do it myself.

For those interested in trying to add a screenshot plugin for their particular instrument they can find inspiration in the code for the Rigol 1000z screenshot plugin here:
https://github.com/lxi/lxi-tools/blob/master/src/plugins/screenshot_rigol.c

Second, I found it very hard to install, even if I'm familiar with Linux. By familiar I mean able to follow README instructions, and able to use the command line, but not being a Linux developer. The problem was that there were no binary, so I need to compile from sources. In the README file it says "./configure", "make", "make install", which won't work, because there is no "./configure". By looking inside various files I realized that I should generate the ./config file myself, then after a lot of googling I found out about autoreconf and so on.
 :horse:

Sorry about that. I'm actually working on pushing lxi-tools and liblxi into the most popular GNU/Linux distributions. It is currently being packaged for Fedora/RHEL and soon I hope Debian/Ubuntu packages will be ready so that most people can avoid installing from source. I know the source install instructions are very generic but that is only because it assumes that the user knows how to deal with configure/make stuff.

In your case you made the mistake of using the github repository which never includes a configure file. Only the public released tarballs include the configure script. The tarballs download links are available at https://lxi.github.io

Don't worry, many still makes the mistake of using the raw git repos in which case they will need to know all the ins and outs of using autogen.sh ;)

Third, the lxi-tool is using a different protocol, VXI-11, and different ports. lxi-tools is not using TCP/5555, I guess that is why the hang is not reproducible when using VXI-11.

That is correct. Actually, the VXI protocol uses port 111 to initiate communications but all subsequent communication is performed using arbitrary ports. In case you use wireshark to inspect the packages I suggest you just filter by IP src and dst to see what is going on. As I mentioned earlier in this thread, all SCPI commands fired via VXI are defined by a RPC call which includes a timeout definition which is used by the receiving instrument for timeout handling. In case of using raw TCP on port 5555 you don't define any timeout per SCPI call and nor does the Rigol seem to use a default timeout via this channel, hence the stalling command ends up blocking the command channel mapped to TCP port 5555. At least that is what I speculate is happening.

Quote
Unless LXI CORE 2011 requires SCPI to work over a raw TCP socket (it might require, but at a draft look I couldn't find any required feature about plain SCPI text sent over LAN), I guess SCPI text sent over a raw TCP socket is just an undocumented feature, so even if the TCP hangs when using netcat, then we can not file a bug about it.

You can safely file a bug for that specific command sequence failing to respond. I think it is the command which is failing and not the communications channel, regardless of it being RAW/TCP or VXI/TCP.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: RoGeorge on October 29, 2017, 06:11:08 pm
Quote
In 2000, the VXIplug&play Alliance added support for LAN-based instruments to its VISA specifications.
Two popular methods of instrument control via Ethernet were adopted by VISA:
VXI-113 and “direct” TCP socket communication

Thank you for pointing to that, I'll further look into it.
TBH, I'm still confused about the precise requirements and the relationship between different specification protocols like LXI, VXI, VISA, SCPI and so on.

I hope some people in this forum might contribute...
...
I'm actually working on pushing lxi-tools and liblxi into the most popular GNU/Linux distributions. It is currently being packaged for Fedora/RHEL and soon I hope Debian/Ubuntu packages

Yep, I would like to contribute, but most of all I would like to see a generic implementation that does not require to install a few GB of closed source drivers, like e.g. NI-VISA for Windows does now. All the best wishes with that. It's pretty lame that a lot of people are wasting their time to implement their own software for sending SCPI commands (including myself, which I'm not a programmer), instead of just using some open source established library.

Regarding my personal hassle with the installation, I'm glad that I made the mistake of starting from the github repo, because that led me to new insights about building from sources.  ^-^

Thank you for all the other clarifications as well, it all makes more sense now.

I noticed that you opened a topic about lxi-tools and liblxi: https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/ (https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/)
Since other questions related to lxi-tools might become offtopic here, would the above link be the right place for further eevblog talks about lxi-tools and liblxi?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: lundmar on October 29, 2017, 06:45:26 pm
Yep, I would like to contribute, but most of all I would like to see a generic implementation that does not require to install a few GB of closed source drivers, like e.g. NI-VISA for Windows does now. All the best wishes with that. It's pretty lame that a lot of people are wasting their time to implement their own software for sending SCPI commands (including myself, which I'm not a programmer), instead of just using some open source established library.

Yes, and installing GBs of data just to communicate with your instruments seems even more ridiculous as the lxi-tool and liblxi is only about 30k in total ;)

I also find it silly that standardizing organizations like the LXI consortium do not provide open source tools that implements their open standards. I guess it takes developers like me to step up and do the work if we want better tools. sigh.

By the way, there are various ways to contribute to a open source project like lxi-tools. I'll be happy to write the screenshot plugin for any instrument people might have but I need their help to test it.

Regarding my personal hassle with the installation, I'm glad that I made the mistake of starting from the github repo, because that led me to new insights about building from sources.  ^-^

Thank you for all the other clarifications as well, it all makes more sense now.

No problem. Learning new stuff is often fun.

I noticed that you opened a topic about lxi-tools and liblxi: https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/ (https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/)
Since other questions related to lxi-tools might become offtopic here, would the above link be the right place for further eevblog talks about lxi-tools and liblxi?

Yes, besides the github issue tracker, https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/ (https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/msg1318434/#msg1318434) is a good place to discuss lxi-tools.

Also, just to help clarify. LXI (LXI Core etc.) is simply the standard that dictates that LXI certified instruments are required to communicate SCPI commands using communication protocols like RAW/TCP, VXI11/TCP, and HiSlip/TCP.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: TinkeringSteve on November 04, 2017, 07:28:27 pm
I just installed the lates firmware on mine, thinking, they probably got most of the kinks out of there.

Well. I just wanted to try the FFT function, played around with the options, and when I set
Mode to "Memory", the thing froze, none of the controls (e.g. channel buttons) worked, had to reset.

Can someone else confirm this?
(could have had a bad download, who knows... Although they hopefully do CRC or so on those files...)

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on November 04, 2017, 07:40:27 pm
No problems using FFT in memory mode.
Does your scope freeze every time / is it reproducible?
If it is persistent: Please try re-uploading the firmware as you already mentioned and if the error still remains, please share the extended system info for reference.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on November 04, 2017, 07:59:37 pm
Try resetting the scope: switch it off and then on again and press repeatedly the 5th grey button on the left.
The language will change to chinese but that's easily fixed in the menu at the left.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: TinkeringSteve on November 04, 2017, 08:02:07 pm
Oh starting does work, the firmware apparently doesn't get to store that setting, it's back to "trace" when I start again.

No problems using FFT in memory mode.
Does your scope freeze every time / is it reproducible?
If it is persistent: Please try re-uploading the firmware as you already mentioned and if the error still remains, please share the extended system info for reference.

As to "does it always" - no - apparently not on CH1, but with at least CH2, when it's the only active channel, and I'm feeding in a sine @ 20 Hz, 3V with offset so that it's DC. And then set Mode to Memory.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on November 04, 2017, 08:30:21 pm
My scope does not freeze - regardless of which channels are activated etc. I fiddled around with the active channels selection, input selection of FFT function, window mode, trace/memory both in auto and record/stop mode and single shot triggering. My scope does not lock up.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: TinkeringSteve on November 04, 2017, 08:47:21 pm
My scope does not freeze - regardless of which channels are activated etc. I fiddled around with the active channels selection, input selection of FFT function, window mode, trace/memory both in auto and record/stop mode and single shot triggering. My scope does not lock up.

Funny. I can't reproduce it anymore either. I did a couple times before, only using Ch2 and restariting and going straight to "math" and changing the setting.
Now that I fiddled around a bit more, even restarting with only Ch2 active, going to math/fft and oing the memory setting, nah.
Weird.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on November 13, 2017, 09:46:09 am
Good news everyone!

I recently bought another DS1054Z (and a DP832) and since the re-seller asked me to give some feedback I wrote a lengthy email regarding my user experience and also pointed towards this thread for more detailed information.
The re-seller forwarded my mail to the European Rigol service (had one or two phone calls with them in the past) and they again forwarded it to Rigol R&D, also stating they will have a closer look at our bug-list.
If and how this might affect the next firmware releases I can not tell, but after all it is another chance for communication.

This is just a heads up and while Rigol might be reading this: Thanks for taking us seriously and you are very welcome to chime in and get a part of this forum!
Lots of Rigol users to get in contact with around here!
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: bitseeker on November 14, 2017, 02:38:20 am
Excellent. Thanks for doing that. Hopefully, one day Rigol will pay attention to what goes on here. So far, they seem not to notice.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on March 01, 2018, 11:38:02 am
Since the last firmware release some water has gone under the bridge and I am interested to see if some of you did check out what bugs still remain. I would like to keep the opening post up to date and as comprehensive as possible :)

Please let me know if you are missing information there.
I downgraded the »freeze on update/calibrate issue« since there has not been word about further issues or permanent bricking.

Also, I might start working on the wish list that has remained untouched until today - if there is demand.

Kind regards,
Frederik
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on March 01, 2018, 12:12:45 pm
Since the last firmware release some water has gone under the bridge and I am interested to see if some of you did check out what bugs still remain. I would like to keep the opening post up to date and as comprehensive as possible :)

There's not much left. A typo in a menu, and... I can't remember any more.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on March 01, 2018, 12:20:34 pm
There's not much left. A typo in a menu, and... I can't remember any more.

That is my experience as well - the scope does what I expect it to do. I am no scope specialist though and most likely need just the basic functions anyway.
Personally, I hope Rigol does not fix the pluses spelling! I am feeling kind of attached to it by now :)
Title: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Roeland_R on March 01, 2018, 12:26:45 pm
For the wish list: Alternate triggering perhaps?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on March 01, 2018, 12:55:17 pm
Re. alternate triggering: There is this thread (https://www.eevblog.com/forum/testgear/rigol-and-multiple-triggering-individual-triggering-on-each-channel/).

I’ll add it as a wish list item when going through the post :)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on March 01, 2018, 04:41:57 pm
The USB protocol violation that causes a failing connection dipending on motherboard USB-controller chipset and operating system, is still present and Rigol has no plan to fix it.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on March 01, 2018, 07:19:37 pm
The USB protocol violation that causes a failing connection dipending on motherboard USB-controller chipset and operating system, is still present and Rigol has no plan to fix it.

Bummer!

(I guess I"ll have to use an Ethernet cable instead...)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Porcine Porcupine on March 04, 2018, 06:15:49 am
Bug report: Some DS1000Z units display in peak detect acquisition mode while set to normal acquisition mode.

I posted a separate thread in December about seeing a double trace on my DS1054Z I had just bought. As mentioned in my other thread, I found a Reddit post by someone who encountered the same problem about a year before I did. The Reddit poster returned his unit and received a replacement with the same problem. He concluded that the problem is likely a firmware bug causing the oscilloscope to remain in peak detect acquisition mode when set to normal acquisition mode. After discussing the problem with the Reddit poster and comparing raw data to on-screen traces, I've become convinced the problem is in fact a firmware bug causing the unit to display in peak detect mode whether it is set to peak detect or normal mode.

My original thread about the problem: https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/ (https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/)

Reddit post by someone with the same problem: https://www.reddit.com/r/AskElectronics/comments/5mi24b/recently_purchased_a_rigol_ds1054z_oscilliscope_i/ (https://www.reddit.com/r/AskElectronics/comments/5mi24b/recently_purchased_a_rigol_ds1054z_oscilliscope_i/)

The steps to reproduce the problem are listed in the Reddit post linked above.

The problem is present whether the oscilloscope is in dots or vectors display mode, but the separation between the peak detect points becomes obvious in dots mode.

My oscilloscope shipped with what is still the latest firmware; although, not all DS1054Z units running the latest firmware seem to be affected.

Here is my DS1054Z's information:

(https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/?action=dlattach;attach=375296;image)

I recently captured some data from my DS1054Z with MATLAB using SCPI commands over Ethernet. By doing this I was able to plot raw data stored in the acquisition memory and compare it to the trace shown on the oscilloscope's screen.

Here's the trace shown on the screen (1-kHz internal source):

(https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/?action=dlattach;attach=400730;image)

Here's the raw acquisition memory data plotted:

(https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/?action=dlattach;attach=400732;image)

With a memory depth setting of 2.4 Mpts, the 1920x963 image above obviously only shows a fraction of the points. However, I did zoom in to take a closer look, and the data looks just like I would expect. This issue obviously occurs after the oscilloscope processes the data for display on its screen.

Here's the raw data downsampled to the same 1,200 points shown in the oscilloscope's on-screen trace plotted with the actual on-screen trace data in normal acquisition mode:

(https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/?action=dlattach;attach=400766;image)

The downsampled raw data and on-screen trace data are represented by blue and red dots, respectively. I think these plots make it very clear that the oscilloscope is stuck in peak detect mode. In normal mode, the trace displayed on the oscilloscope should look like the downlsampled blue trace. Instead, we are stuck with a double trace when in dots mode and a fat trace in vectors mode that appear to show way more noise than is actually present.

I've tried to present this problem as clearly as I can with the hope someone at Rigol will see this and include a fix in the next firmware update.

Edit: I replaced the original plot I posted of the downsampled raw data and on-screen data together. The MATLAB function I used for the original plot to do the downsampling low-pass filtered the data, which removed a lot of noise. The new plot has the downsampling done without filtering. You might notice in that plot the on-screen data is slightly delayed compared to the raw data, but I believe that's normal for whatever reason, and it doesn't concern me.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on March 04, 2018, 09:17:18 am
Thank you for the detailed report! I will add it to the list and try to recreate the issue on my device.

Kind regards,
Frederik
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Porcine Porcupine on March 04, 2018, 10:17:50 am
Thank you for the detailed report! I will add it to the list and try to recreate the issue on my device.

Kind regards,
Frederik

You mentioned in the thread I posted in December that you weren't able to reproduce the problem on yours. It seems we have the same hardware and firmware too. It's interesting that this issue affects some units and not others.

https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363199/#msg1363199 (https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363199/#msg1363199)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on March 04, 2018, 11:03:29 am
I could not reproduce it at that time, but maybe I did not try hard enough ;)
Would be interesting to see if it can be tracked down to certain behavior / sequence of operation.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on March 04, 2018, 11:12:38 am
This has had its own thread:

https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145 (https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145)

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Porcine Porcupine on March 04, 2018, 11:36:42 am
This has had its own thread:

https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145 (https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145)

That's the thread I started about it several months ago. I wasn't sure what the problem was then, but now I'm convinced it's a bona fide firmware bug that deserves Rigol's attention.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on March 04, 2018, 11:52:32 am
This has had its own thread:

https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145 (https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145)

That's the thread I started about it several months ago. I wasn't sure what the problem was then, but now I'm convinced it's a bona fide firmware bug that deserves Rigol's attention.

I still think it's a hardware limitation in the circuit that copies raw sample data to the display.

It simply can't apply a wide-enough filter to display it correctly (which is understandable - it would need to filter an awful lot of data for each screen pixel). As such, it can't be fixed by firmware.

I'd be interested to how other oscilloscopes deal with this problem (in theory they should all do it to some extent!)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Porcine Porcupine on March 04, 2018, 01:09:02 pm
I still think it's a hardware limitation in the circuit that copies raw sample data to the display.

It simply can't apply a wide-enough filter to display it correctly (which is understandable - it would need to filter an awful lot of data for each screen pixel). As such, it can't be fixed by firmware.

I'd be interested to how other oscilloscopes deal with this problem (in theory they should all do it to some extent!)

One thing that convinced me it's stuck in peak detect mode is that I was able to produce a trace with MATLAB that looks exactly as it should by simply downsampling the raw data to the same number of points displayed on the screen. I assume Rigol's normal acquisition mode is supposed to do the same thing in software to go from acquisition memory sample points to the points displayed on the screen.

Another thing that makes me feel it really is stuck in peak detect mode is the traces in both normal and peak detect modes look the same.

Here's a trace captured in normal mode:

(https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/?action=dlattach;attach=400800;image)

And here's one captured in peak detect mode:

(https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/?action=dlattach;attach=400802;image])

Both traces look like classic peak detection to me. If it was actually switching modes when the setting was changed, I would expect the traces to look different (as they probably do on a DS1054Z that isn't affected by this problem). These two example plots don't line up point-for-point because I had to do a new sweep after changing modes to get it to draw a new trace.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on March 04, 2018, 03:53:40 pm
One thing that convinced me it's stuck in peak detect mode is that I was able to produce a trace with MATLAB that looks exactly as it should by simply downsampling the raw data to the same number of points displayed on the screen.

Correct.

The problem is simply in the number of points you need to sample in your downsampling filter.

In Matlab there isn't really a problem, you can sample 100 points, no problem. It's a powerful PC.

In the Rigol ASIC there may be a much more defined limit for this downsampling. It might only be able to sample (eg.) 4 points (I don't know the exact number but it will be quite small).

This means that at some ratios of imput->output frequencies you're going to get aliasing, ie. You'll see two lines instead of one line.

In my post in the other thread you can see this happening, The aliasing on the displayed changes with zoom level.

This isn't a firmware bug, it's a hardware limitation (number of input samples in the downsampling filter).
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: 2N3055 on March 04, 2018, 04:35:58 pm
@Porcine Porcupine,

With do all respect, you don't seem to really understand how peak detect mode works...

In normal mode running at let's say 100M/sec, A/D converter is discarding 9 samples and use only one out of ten..
In peak detect mode, it won't discard 9 samples, but will remember min/max value, and show those two points on screen.
That way, you can detect 10 nsec pulse on time base where one pixel would only mean 1 usec and normally you wouldn't know something happened in meantime..
So far, so good...

But if you go to time base where your scope already samples at 1GS/sec (max rate here),  Peak detect mode and Normal mode ARE THE SAME.... That is how it works... Usually, other scopes have warning in their manual that Peak detect works only on slower timebases....


And double line can also be caused by more likely reason: since A/D converter used actually works by interleaving 4x250MS/sec converters, if converters have offset relative to each other, consecutive samples wouldn't be vertically aligned..  Like what you see... If there is a bug, it is more likely it is in self cal procedure...

But it probably is not even that.. I can replicate this only on two lowest ranges, that are software zoom created. At 1mV/DIV (1X probe) vertical res of scope is about 40 pixel ... And any offset between A/D converters is multiplied by 5x, making it really visible...
Lowest real vertical range is 5mv/div...

Just something to think about...

Regards,

Sinisa
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on March 05, 2018, 10:20:19 am
After some fiddling I could get to show the double tracing on my scope. It is very dependent on the time base and magnification setting though.
Looks like a quantization issue to me but that is just a wild guess.
It is gone in hi-res and average mode, thus my suspicion for quantization through the ADC.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on March 05, 2018, 10:29:41 am
Btw. if you are on the low end, say 10mV per unit, you are seeing all the noise.
If you zoom in per time base, the "double trace" resolves into a scattered point cloud, showing kind of a rendering issue.
The black area between the top and bottom "trace" should actually be all yellow in this case, but for some reason the individual dots add up to *null* when merged closely together.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on March 05, 2018, 11:36:37 am
Looks like a quantization issue to me but that is just a wild guess.
I agree 100%.

It is gone in hi-res and average mode, thus my suspicion for quantization through the ADC.

ie. If you choose sensible display settings it vanishes. Not an issue.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on March 05, 2018, 12:03:40 pm
That "inverse brightness coagulation" (as per my second post above and resembling what PP is referring to) behavior is interesting. I would count that as an unexpected rendering issue that does not actually spawn from the ADC.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: metrologist on March 05, 2018, 03:27:22 pm
I can report a more potentially benign bug. I enabled FFT and was setting the Center, Hz/Div, and Offset. I adjusted the Offset and then went to adjust the Center or Hz/Div. With either of those values outlined with the blue box (indicating that was my current parameter selection), the twiddle knob was still adjusting the Offset value  ???

I could recover this by selecting different parameters and the scope would release the Offset setting, but it came back again after changing something in the second menu and returning to the first. I reset (Default) the scope and set it up again without an issue, so I did not test the issue further.

I have the latest FW and probably one dot down from the latest hardware.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Porcine Porcupine on March 06, 2018, 05:39:03 am
One thing that convinced me it's stuck in peak detect mode is that I was able to produce a trace with MATLAB that looks exactly as it should by simply downsampling the raw data to the same number of points displayed on the screen.

Correct.

The problem is simply in the number of points you need to sample in your downsampling filter.

In Matlab there isn't really a problem, you can sample 100 points, no problem. It's a powerful PC.

In the Rigol ASIC there may be a much more defined limit for this downsampling. It might only be able to sample (eg.) 4 points (I don't know the exact number but it will be quite small).

This means that at some ratios of imput->output frequencies you're going to get aliasing, ie. You'll see two lines instead of one line.

In my post in the other thread you can see this happening, The aliasing on the displayed changes with zoom level.

This isn't a firmware bug, it's a hardware limitation (number of input samples in the downsampling filter).

When I downsampled with Matlab, I did it in about the crudest way possible by just throwing samples away without any low-pass filtering. If downsampling were going to cause such aliasing with this signal, don't you think it would have happened then?

It also seems strange to me that noise or anything else in this signal could alias into two lines like that without any points between them.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Porcine Porcupine on March 06, 2018, 05:44:35 am
@Porcine Porcupine,

With do all respect, you don't seem to really understand how peak detect mode works...

In normal mode running at let's say 100M/sec, A/D converter is discarding 9 samples and use only one out of ten..
In peak detect mode, it won't discard 9 samples, but will remember min/max value, and show those two points on screen.
That way, you can detect 10 nsec pulse on time base where one pixel would only mean 1 usec and normally you wouldn't know something happened in meantime..
So far, so good...

But if you go to time base where your scope already samples at 1GS/sec (max rate here),  Peak detect mode and Normal mode ARE THE SAME.... That is how it works... Usually, other scopes have warning in their manual that Peak detect works only on slower timebases....


And double line can also be caused by more likely reason: since A/D converter used actually works by interleaving 4x250MS/sec converters, if converters have offset relative to each other, consecutive samples wouldn't be vertically aligned..  Like what you see... If there is a bug, it is more likely it is in self cal procedure...

But it probably is not even that.. I can replicate this only on two lowest ranges, that are software zoom created. At 1mV/DIV (1X probe) vertical res of scope is about 40 pixel ... And any offset between A/D converters is multiplied by 5x, making it really visible...
Lowest real vertical range is 5mv/div...

Just something to think about...

Regards,

Sinisa

I haven't been able to find satisfactory documentation about how Rigol's peak detect mode works, but I assumed it does what you described plus a second stage of downsampling. The second stage is needed because there are still too many points to show on the screen.

My thinking is it first stores the result of the downsampling you described in the acquisition memory. Then it downsamples again just like the first time: it divides points stored in the acquisition memory into the same number of time bins as points shown on the screen, and then alternately selects a maximum or minimum point from each bin. I could be be wrong about this, but this is the most sensible way I can think of to do it.

If it does do it in two stages, then peak detect mode would still be different than normal mode because the second downsampling stage still happens even though there's no first-stage downsampling to do. It seems to me it has to do a second stage of downsampling this way to ensure the peak points make it to the screen trace.

I don't think this problem is caused by ADC offsets, because I didn't see any obvious sign of that in the raw data before or after downsampling.

The effect I see on my oscilloscope is easily seen at 500 V/div. It's possible your oscilloscope isn't affected by the same problem as mine, and you're seeing a different effect at those low V/div ranges. Maybe what you see is the ADC offset you mentioned.

Edit: It just occurred to me that there is likely a third peak detect mode downsampling stage to go from the screen trace buffer to what is actually shown on the screen. If the screen trace buffer has 1,200 points stored in it, it would have to be downsampled again with the peak detect downsampling algorithm to preserve the peaks on the displayed trace, which doesn't even cover the full 800-pixel width of the screen.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Porcine Porcupine on March 06, 2018, 05:59:15 am
I played with my oscilloscope some more and got a couple more results I think are interesting.

I fed it train of 5-V, 70-ns-wide pulses spaced at 1-ms intervals and set the time base and memory depth appropriately to test peak detect mode. I changed from dots to vectors for this so the pulses are lines instead of hard-to-see dots.

First in normal mode:

(https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/?action=dlattach;attach=401274;image)

As expected the pulses were captured erratically and unreliably in normal mode. Each sweep showed a different number of pulses in different spots.

Then in peak detect mode:

(https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/?action=dlattach;attach=401276;image)

Peak detect mode worked beautifully and did exactly what it's supposed to do. So now I know turning on peak detect mode does something, and the unit isn't simply stuck in peak detect mode.

I'm wondering now if that second stage of peak detect mode I speculated about in my last post might be stuck on, meaning that turning peak detect mode on and off is only controlling that first stage of downsampling. I know that scenario might sound a little farfetched, especially since I'm guessing about how peak detect mode works exactly. However, I think that scenario would be consistent with what I'm seeing. The double line with nothing in the middle and the points all displayed at the extremes of the noise amplitude looks so consistent with what I would expect out of peak detect mode that I'm still not satisfied a peak detect bug isn't somehow behind this.

I also fed a 4-Vpp, 1-MHz sine wave into the oscilloscope while in normal mode. With the time base set very slow compared to the signal's period, this is what I got with dots:

(https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/?action=dlattach;attach=401278;image)

It looks like the envelope of the signal, which is what I would expect to see under these conditions with peak detect mode enabled. Nothing changed on the screen when I varied the frequency around 1-MHz, so I don't think this effect is caused by aliasing. As in the other examples of double lines, it looks like the fog you'd expect to see if displaying vectors because of the lines connecting the two lines of points.

Could this be a more extreme example of this double line issue?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Porcine Porcupine on March 06, 2018, 07:25:23 am
Btw. if you are on the low end, say 10mV per unit, you are seeing all the noise.
If you zoom in per time base, the "double trace" resolves into a scattered point cloud, showing kind of a rendering issue.
The black area between the top and bottom "trace" should actually be all yellow in this case, but for some reason the individual dots add up to *null* when merged closely together.

In your screenshot with the point cloud, I believe it is displaying 600 points (50 ns * 12 divisions * 1 GSa/s = 600 samples) of raw data directly from the acquisition memory with no downsampling or other processing. The traces in all the other images you posted were downsampled, and I think something Rigol didn't intend is happening during that downsampling at some time base settings to create that gap in the trace. It looks like peak detect mode finding the minimum and maximum noise points to me, but it shouldn't be happening whatever it is.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on March 06, 2018, 08:00:25 am
It also seems strange to me that noise or anything else in this signal could alias into two lines like that without any points between them.

So, you need to learn more about aliasing.

Look at texture mapping in 3D graphics where the same problem occurs. When an object is far away then one pixel on screen might cover hundreds (or even thousands!) of pixels in the texture map. There's no way to downsample/filter it in real time.

nb. In 3D graphics they solve it by using precomputed mipmaps for the textures but an oscilloscope can't do that.

When I downsampled with Matlab, I did it in about the crudest way possible by just throwing samples away without any low-pass filtering. If downsampling were going to cause such aliasing with this signal, don't you think it would have happened then?

Nope.

What you see depends on the ratio of the high frequency components of the signal to the samples you kept.

In the post I linked to there's 4 different views of the same data, all views are completely different. The difference you see on screen comes purely from the selection of which points were thrown away and which were kept.

It's nothing to do with peak mode or anything else, that's a complete red herring. It's 100% due to the limits of the downsampling filter and it can't be fixed by a firmware update.

(more correctly: it can't be fixed without reducing the screen update rate to something unacceptable).

https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145 (https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Porcine Porcupine on March 06, 2018, 10:05:55 am
It also seems strange to me that noise or anything else in this signal could alias into two lines like that without any points between them.

So, you need to learn more about aliasing.

Look at texture mapping in 3D graphics where the same problem occurs. When an object is far away then one pixel on screen might cover hundreds (or even thousands!) of pixels in the texture map. There's no way to downsample/filter it in real time.

nb. In 3D graphics they solve it by using precomputed mipmaps for the textures but an oscilloscope can't do that.

When I downsampled with Matlab, I did it in about the crudest way possible by just throwing samples away without any low-pass filtering. If downsampling were going to cause such aliasing with this signal, don't you think it would have happened then?

Nope.

What you see depends on the ratio of the high frequency components of the signal to the samples you kept.

In the post I linked to there's 4 different views of the same data, all views are completely different. The difference you see on screen comes purely from the selection of which points were thrown away and which were kept.

It's nothing to do with peak mode or anything else, that's a complete red herring. It's 100% due to the limits of the downsampling filter and it can't be fixed by a firmware update.

(more correctly: it can't be fixed without reducing the screen update rate to something unacceptable).

https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145 (https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145)

Thanks for the explanation, but I'm still a little confused about how such aliasing is happening. I'm interested in replicating the aliasing in Matlab from the raw data to understand it better. Do you have any suggestion on how I might do that?

I downsampled by a factor of 2,000 to go from 2.4 million raw sample points to 1,200 like the oscilloscope presumably did to get the trace data but didn't get the aliasing. Would I perhaps see similar aliasing if I tried other downsampling ratios or different sampling phases?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on March 06, 2018, 10:30:53 am
I downsampled by a factor of 2,000 to go from 2.4 million raw sample points to 1,200 like the oscilloscope presumably did to get the trace data but didn't get the aliasing. Would I perhaps see similar aliasing if I tried other downsampling ratios or different sampling phases?

You just described the problem perfectly: How do you reduce 2000 points of data to a single point on screen?

I don't know what method the DS1054Z uses, sorry. I'm sure it's done in hardware though so expect it to be a compromise.  :popcorn:

(nb. The DS1054Z only displays 600 points on screen so there's a secondary 2:1 reduction somewhere...)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ebastler on March 06, 2018, 10:57:34 am
How do you reduce 2000 points of data to a single point on screen?
I don't know what method the DS1054Z uses, sorry. I'm sure it's done in hardware though so expect it to be a compromise.

Obviously we don't know how it is implemented by Rigol. But I can't see a good reason for always showing the extreme data points, and hardly ever showing one with medium amplitude. That does hint towards an unintended peak-detect like algorithm, as postulated by porcupine.

And, not to forget: At just slightly faster time base settings, where the scope still has to do massive down-sampling, the effect disappears and the curves or point clouds look reasonable. Something must go "wrong" at those slow time bases. Maybe some histogram counter overflowing or whatever?

Anyway, this is just guessing. But I think it likely that, within the limitations of the existing DS1000Z hardware, there would be a better way to down-sample and display the signals at slow time bases.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Porcine Porcupine on March 06, 2018, 06:27:01 pm
I downsampled by a factor of 2,000 to go from 2.4 million raw sample points to 1,200 like the oscilloscope presumably did to get the trace data but didn't get the aliasing. Would I perhaps see similar aliasing if I tried other downsampling ratios or different sampling phases?

You just described the problem perfectly: How do you reduce 2000 points of data to a single point on screen?

I don't know what method the DS1054Z uses, sorry. I'm sure it's done in hardware though so expect it to be a compromise.  :popcorn:

(nb. The DS1054Z only displays 600 points on screen so there's a secondary 2:1 reduction somewhere...)

In the image below, taken from one of my previous posts, I plotted the points stored in the oscilloscope's 1,200-point trace buffer in red and the raw data I downsampled from 2.4 million raw points to 1,200 points in blue. So the effect happens before that final 2:1 reduction.

This is making me want an oscilloscope with open source hardware and software so I can peer inside the black box. But guessing what the black box is doing is sort of fun too in its own way. :)

(https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/?action=dlattach;attach=400766;image)

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on March 06, 2018, 06:59:53 pm
Anyway, this is just guessing. But I think it likely that, within the limitations of the existing DS1000Z hardware, there would be a better way to down-sample and display the signals at slow time bases.

Just don't use dot mode, problem solved!   :-+

(why would you use dots to look at a signal like that?)

Or ... use dots but turn on averaging - also solved!


Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ebastler on March 06, 2018, 07:32:21 pm
Just don't use dot mode, problem solved!   :-+
(why would you use dots to look at a signal like that?)

Or ... use dots but turn on averaging - also solved!

Well, it's most obvious in dot mode -- but the line mode suffers from an inflated noise (trace width) if it plots only the outliers and connects them with lines.

Averaging is fine if you want to look at a stationary signal, but pretty useless when looking for fluctuations or spurious events. So you will have to live with the inflated noise when you are after that. (And at the same time have to measure at the slower time bases, to be fair.)

I'm still happy with my DS1054Z; but it would be a pity if Rigol make the noise performance look worse than it is, just by careless digital processing.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: 2N3055 on March 06, 2018, 07:39:45 pm
Sorry but i have a question:

I would like to know what you guys think an analog CRT scope would show in these circumstances...

Namely, a slow time sweep and fast pulses... For instance, 10 ms/div and feed it 1 MHz signal....

Tadaaaa...

You would get solid block, from left to right, vertically sized to P-P amplitude of signal....
Depending of waveform, parts of that "band" would be darker or brighter, depending on statistical distribution of signal amplitude over time ....
It works only in what a DSO crowd would call "Peak mode"....

I don't know who started dot mode fetish, but it is not optimal mode that shows signal best... Vector mode is your friend. Dot mode is used only sometimes, for specific reasons.

Also, unless you want to specifically filter out higher frequencies (by using BW limit, average or HiRes mode), you want a Peek mode pretty much always...
You don't want to miss super short interference bursts because you are looking at slow timebase..

I don't know what are you measuring but from my practice...

Regards,

Sinisa
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ebastler on March 06, 2018, 07:52:04 pm
I would like to know what you guys think an analog CRT scope would show in these circumstances...
Namely, a slow time sweep and fast pulses... For instance, 10 ms/div and feed it 1 MHz signal....
Tadaaaa...

Read again, please, and go one page further back. The real discussion of the artefacts starts around post #237 or so. The demo signal is simply the 1 kHz square wave from the calibration output. And the problem is that the parts of the trace where the signal is stable appear either split in two (dot mode) or artificially widened, with inflated apparent noise (line mode).

The short pulses at large intervals, shown further down in the thread, only serve to show that peak mode actually works (and only works when enabled).
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Porcine Porcupine on March 06, 2018, 07:56:45 pm
Anyway, this is just guessing. But I think it likely that, within the limitations of the existing DS1000Z hardware, there would be a better way to down-sample and display the signals at slow time bases.

Just don't use dot mode, problem solved!   :-+

(why would you use dots to look at a signal like that?)

Or ... use dots but turn on averaging - also solved!

I just think it would be desirable for Rigol to include a fix in their next firmware update if this issue is fixable in firmware without any compromises. That might not be possible, as you've pointed out, but I don't think any of us knows for sure what's causing this effect. It would be nice to at least hear something from Rigol since they know exactly how the oscilloscope processes data.

Either way, I'm still satisfied overall with my DS1054Z. It's a fantastic oscilloscope for the price.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: 2N3055 on March 06, 2018, 07:59:25 pm
I would like to know what you guys think an analog CRT scope would show in these circumstances...
Namely, a slow time sweep and fast pulses... For instance, 10 ms/div and feed it 1 MHz signal....
Tadaaaa...

Read again, please, and go one page further back. The real discussion of the artefacts starts around post #237 or so. The demo signal is simply the 1 kHz square wave from the calibration output. And the problem is that the parts of the trace where the signal is stable appear either split in two (dot mode) or artificially widened, with inflated apparent noise (line mode).

The short pulses at large intervals, shown further down in the thread, only serve to show that peak mode actually works (and only works when enabled).


I am specifically commenting Reply #254.....

As for what you are saying, I made my comment on that before... 
He needs to self cal scope first, and than not use software magnified input ranges..
Also, DS1000Z IS sensitive to external RF fields... It might as well be that he REALLY HAS high frequency interference injected... In that case noise is not artificially inflated....
Or his scope might really have some issue....
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: 2N3055 on March 06, 2018, 08:06:21 pm
Anyway, this is just guessing. But I think it likely that, within the limitations of the existing DS1000Z hardware, there would be a better way to down-sample and display the signals at slow time bases.

Just don't use dot mode, problem solved!   :-+

(why would you use dots to look at a signal like that?)

Or ... use dots but turn on averaging - also solved!

I just think it would be desirable for Rigol to include a fix in their next firmware update if this issue is fixable in firmware without any compromises. That might not be possible, as you've pointed out, but I don't think any of us knows for sure what's causing this effect. It would be nice to at least hear something from Rigol since they know exactly how the oscilloscope processes data.

Either way, I'm still satisfied overall with my DS1054Z. It's a fantastic oscilloscope for the price.

Put it in vector mode and it looks exactly as it should....

On the other hand I do agree that I would like for Rigol (and everybody else) would exactly explain how they massage data before handing it to us...
I'm all for it...

Regards,
 Sinisa
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on March 06, 2018, 08:08:35 pm
As for what you are saying, I made my comment on that before... 
He needs to self cal scope first, and than not use software magnified input ranges..
Also, DS1000Z IS sensitive to external RF fields... It might as well be that he REALLY HAS high frequency interference injected... In that case noise is not artificially inflated....
Or his scope might really have some issue....

Nah, they all do it (I think).

It's not noise, it's a high frequency sine wave. See my post in the other thread, the signal is very clear at maximum zoom:

https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145 (https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ebastler on March 06, 2018, 08:10:24 pm
I am specifically commenting Reply #254.....

Me too, and specifically on the first two screenshots in that post.  ;)

As to the third image in #254, I agree that it is not a meaningful measurement setting. But it can serve as another test case for the assumed "unwanted peak detection": I would indeed expect to see the occasional dot inbetween those two extreme lines. (While the sine signal spends most of its time near the extrema, the transition time between them is certainly not negligible, and hence the probability to "catch" a sample inbetween should not be negligible either.)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ebastler on March 06, 2018, 08:13:24 pm
Put it in vector mode and it looks exactly as it should....

Well, it's most obvious in dot mode -- but the line mode suffers from an inflated noise (trace width) if it plots only the outliers and connects them with lines.

Averaging is fine if you want to look at a stationary signal, but pretty useless when looking for fluctuations or spurious events. So you will have to live with the inflated noise when you are after that. (And at the same time have to measure at the slower time bases, to be fair.)

I'm still happy with my DS1054Z; but it would be a pity if Rigol make the noise performance look worse than it is, just by careless digital processing.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: 2N3055 on March 06, 2018, 08:21:50 pm
I am specifically commenting Reply #254.....

Me too, and specifically on the first two screenshots in that post.  ;)

As to the third image in #254, I agree that it is not a meaningful measurement setting. But it can serve as another test case for the assumed "unwanted peak detection": I would indeed expect to see the occasional dot inbetween those two extreme lines. (While the sine signal spends most of its time near the extrema, the transition time between them is certainly not negligible, and hence the probability to "catch" a sample inbetween should not be negligible either.)


@ebastler,  I apologize, I meant specifically to that last third image...

In non peak detect mode at slow timebase and dot mode, with decimation,  signal would get very VERY few dots vertically in between...  At that sampling ratio, it does spend negligible time going up and down...
That is why you have to use vector interpolation....

Regards,

Sinisa
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Porcine Porcupine on March 06, 2018, 09:15:59 pm
Nah, they all do it (I think).

It's not noise, it's a high frequency sine wave. See my post in the other thread, the signal is very clear at maximum zoom:

https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145 (https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145)

Ah, I think I see now why you were saying it's aliasing and I had a hard time understanding how it could be aliasing. I was assuming the noise is a spectrum of high frequencies, and I think you had that single-frequency sine wave in mind.

The time segment you zoomed into isn't indicative of the noise over a full cycle of the square wave on my oscilloscope. When I zoom all the way into the trace on my oscilloscope, I can find time segments that look like a single sine wave as in your example. But I can move around and find other segments that look very different and obviously have other frequency components. This is why I didn't think it was aliasing.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: konnor on March 30, 2018, 07:33:32 pm
I publish my attempt to correct some errors on DS1000Z firmware (2017).
The archive in this message contains the modified firmware.
In the next post is attached an archive with a library and tools for
make&load plugins. Two simple examples are included.

changes on firmware:
1) Ext port 6000 funcs - read/write/call (see rigolif programm)
2) pluses -> pulses
3) rnage -> range (decoder:conf:range)
4) Changed USB Buffer Size (40->200) - test, please. I don't use USB IF
5) Disabled set bandwidth to license maximum on start (BW20 fix)

directory in plugin archive:
rigolif           sample programm for 6000/UDP
add_info          mixed info
libb              plugin library       
patch             port 6000/UDP patch sources
plugin_simple     sample of simple plugin (single LED cycle and exit)
plugin_thread     plugin with thread (permanent LED cycle)

!!!WARNING!!!
This is Beta version. Tested only in my Rigol
AS IS, AS IS, AS IS.....


Update: Archive with color-bug firmware removed, see update in new topic: https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/ (https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ebastler on March 30, 2018, 07:36:52 pm
I publish my attempt to correct some errors on DS1000Z firmware (2017).

Wow, that is quite amazing! But I am reluctant to try it...

What version number did you give the new firmware? If I want to go back to a standard firmware, can I do that? (To which version?) I seem to recall that Rigol does not allow "downgrades" of the verion number, so can one ever go back?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: metrologist on March 30, 2018, 07:38:10 pm
Tempting. Somebody needs to test this. Where did you come from?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: konnor on March 30, 2018, 07:42:25 pm
Tempting. Somebody needs to test this. Where did you come from?

i don't change version, 00.04.04.03.02

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on March 30, 2018, 07:43:13 pm
Is it possible to 'downgrade' to standard firmware after installing this, or install newer versions?

(ie. has your firmware's version check been disabled?)

This should maybe have its own thread.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ebastler on March 30, 2018, 07:44:24 pm
i don't change version, 00.04.04.03.02

OK, thanks. I assume you have tested that one can upgrade to the same version number multiple times, and can go back and forth between the regular firmware and your modfied version?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: konnor on March 30, 2018, 07:45:10 pm
Where did you come from?
The city is listed in the profile.  :)
I have no relationship to Rigol.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: konnor on March 30, 2018, 07:51:13 pm
can go back and forth between the regular firmware and your modfied version?
Yes.

Actually, downgrde is also not a problem, it's enough to write a special signature on a flash drive. But very different firmware may have compatibility problems of the settings.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on March 30, 2018, 07:52:42 pm
Actually, downgrde is also not a problem, it's enough to write a special signature on a flash drive.

This should definitely have its own thread with more info. People have been trying to do that for ages.

Keep the first post in the thread up to date with the latest version, installation info, etc.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: konnor on March 30, 2018, 08:01:07 pm
I did not know that this was a big problem. It is more difficult to find the algorithm for generating keys at times.
The only problem with the distribution of this signature is that it opens other additional functions that make it easy to kill an oscilloscope. And it is not tied to either the serial number or the firmware version.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: metrologist on March 30, 2018, 08:19:14 pm
Where did you come from?
The city is listed in the profile.  :)
I have no relationship to Rigol.

Yes, well there is more to that...

Actually, downgrde is also not a problem, it's enough to write a special signature on a flash drive.

This should definitely have its own thread with more info. People have been trying to do that for ages.

Keep the first post in the thread up to date with the latest version, installation info, etc.

Ages, yes. And this out of the blue, it falls from the sky, like candy.

I agree, new thread, or added to the other one (whatever it was called, the FW hacking rewrite uber thread that has been going on since the beginning of time...)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: rob040 on March 30, 2018, 08:44:34 pm
Thanks Konnor for sharing this firmware.
I am not able to unzip both files into one .GEL file. Get an error. Anyone else tried it?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: RoGeorge on March 30, 2018, 10:08:59 pm
I publish my attempt to correct some errors on DS1000Z firmware (2017).
The archive in this message contains the modified firmware.
In the next post is attached an archive with a library and tools for
make&load plugins. Two simple examples are included.

changes on firmware:
1) Ext port 6000 funcs - read/write/call (see rigolif programm)
2) pluses -> pulses
3) rnage -> range (decoder:conf:range)
4) Changed USB Buffer Size (40->200) - test, please. I don't use USB IF
5) Disabled set bandwidth to license maximum on start (BW20 fix)

directory in plugin archive:
rigolif           sample programm for 6000/UDP
add_info          mixed info
libb              plugin library       
patch             port 6000/UDP patch sources
plugin_simple     sample of simple plugin (single LED cycle and exit)
plugin_thread     plugin with thread (permanent LED cycle)

!!!WARNING!!!
This is Beta version. Tested only in my Rigol
AS IS, AS IS, AS IS.....

P.S. The archive is divided into two parts, because I can not attach a file more than a megabyte.

Thank you very much, this is quite a nice surprise.
Can you please upload again the attachments DS1000ZUpdate.zip and DS1000ZUpdate.01.zip?

They can not be opened as zip archives. I tried to unzip them in both Win10 and Debian8. Also concatenate then unzip in Deb8, still doesn't work.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Daruosha on March 30, 2018, 11:41:25 pm
I publish my attempt to correct some errors on DS1000Z firmware (2017).
The archive in this message contains the modified firmware.
In the next post is attached an archive with a library and tools for
make&load plugins. Two simple examples are included.

changes on firmware:
1) Ext port 6000 funcs - read/write/call (see rigolif programm)
2) pluses -> pulses
3) rnage -> range (decoder:conf:range)
4) Changed USB Buffer Size (40->200) - test, please. I don't use USB IF
5) Disabled set bandwidth to license maximum on start (BW20 fix)

directory in plugin archive:
rigolif           sample programm for 6000/UDP
add_info          mixed info
libb              plugin library       
patch             port 6000/UDP patch sources
plugin_simple     sample of simple plugin (single LED cycle and exit)
plugin_thread     plugin with thread (permanent LED cycle)

!!!WARNING!!!
This is Beta version. Tested only in my Rigol
AS IS, AS IS, AS IS.....

P.S. The archive is divided into two parts, because I can not attach a file more than a megabyte.

Thank you very much, this is quite a nice surprise.
Can you please upload again the attachments DS1000ZUpdate.zip and DS1000ZUpdate.01.zip?

They can not be opened as zip archives. I tried to unzip them in both Win10 and Debian8. Also concatenate then unzip in Deb8, still doesn't work.

Same here, I couldn't unzip the files.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on March 30, 2018, 11:48:48 pm
I agree, new thread, or added to the other one (whatever it was called, the FW hacking rewrite uber thread that has been going on since the beginning of time...)

It really needs to be a thread where konnor can edit the first post and keep it updated.

ie. A completely new thread.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: TurboTom on March 31, 2018, 12:40:32 am
I've been able to extract the GEL file with the unZIP tool integrated with "Total Commander". Flashed it and found it to be "very beta"... Pallette got messed up so the screen looks somewhat funny now, see attached screenshot. Since it's quite late already over here, I didn't do any serious testing - this will have to wait until tomorrow. But I can confirm the "Pluses" spelling error is corrected. Kudos to @konnor for all the effort -- I guess this might be the starting point for some serious improvements! Thanks a lot.

Cheers,
Thomas
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: RoGeorge on March 31, 2018, 12:51:17 am
I've been able to extract the GEL file with the unZIP tool integrated with "Total Commander". Flashed it and found it to be "very beta"...

I've extracted a GEL, too, but it seems to be a corrupt file. When I try to unpack it, I get this output (Corrupt input data):
Code: [Select]
python-3.6.1-embed-amd64\python.exe" unpack.py DS1000ZUpdate.GEL
instrument series:      DS1000Z
firmware version:       00.04.04.03.02
updateType:     0x00070000
found 10 files

{'filename': '/sys/SparrowAPP.out', 'type': 1, 'start': 640, 'length': 1066438, 'crc': 1846034540, 'unknown': (0, 0, 0)}
{'filename': '/sys/SparrowFPGA.hex', 'type': 5, 'start': 1067078, 'length': 803698, 'crc': 1737700535, 'unknown': (0, 0, 0)}
{'filename': '/sys/SparrowDGFPGA.hex', 'type': 6, 'start': 1870776, 'length': 290564, 'crc': 3841850537, 'unknown': (0, 0, 0)}
{'filename': '/sys/logo.hex', 'type': 10, 'start': 2161340, 'length': 768024, 'crc': 1763548407, 'unknown': (0, 0, 0)}
{'filename': '/sys/guiResData.hex', 'type': 12, 'start': 2929364, 'length': 748076, 'crc': 4026022475, 'unknown': (0, 0, 0)}
{'filename': '/sys/guiPicData.hex', 'type': 17, 'start': 3677440, 'length': 124855, 'crc': 2240924515, 'unknown': (0, 0, 0)}
{'filename': '/sys/SparrowConfig.hex', 'type': 16, 'start': 3802295, 'length': 768024, 'crc': 2145407491, 'unknown': (0, 0, 0)}
{'filename': '/sys/SparrowWaveTable.hex', 'type': 11, 'start': 4570319, 'length': 8424, 'crc': 2957269910, 'unknown': (0, 0, 0)}
{'filename': '/sys/SparrowCalFile.hex', 'type': 15, 'start': 4578743, 'length': 144028, 'crc': 4225940020, 'unknown': (0, 0, 0)}
{'filename': '', 'type': 50, 'start': 4722771, 'length': 280, 'crc': 1792089006, 'unknown': (0, 0, 0)}
writing /header  (640 bytes)
writing /sys/SparrowAPP.out.header       (24 bytes)
writing /sys/SparrowAPP.out      (1066414 bytes)
writing /sys/SparrowAPP.out.decompressed         (3934200 bytes)
writing /sys/SparrowFPGA.hex.header      (24 bytes)
writing /sys/SparrowFPGA.hex     (803674 bytes)
writing /sys/SparrowDGFPGA.hex.header    (24 bytes)
writing /sys/SparrowDGFPGA.hex   (290540 bytes)
writing /sys/logo.hex.header     (24 bytes)
writing /sys/logo.hex    (768000 bytes)
writing /sys/guiResData.hex.header       (24 bytes)
writing /sys/guiResData.hex      (748052 bytes)
writing /sys/guiPicData.hex.header       (24 bytes)
writing /sys/guiPicData.hex      (124831 bytes)
writing /sys/guiPicData.hex.decompressed         (4031460 bytes)
writing /sys/SparrowConfig.hex.header    (24 bytes)
writing /sys/SparrowConfig.hex   (768000 bytes)
writing /sys/SparrowWaveTable.hex.header         (24 bytes)
writing /sys/SparrowWaveTable.hex        (8400 bytes)
writing /sys/SparrowCalFile.hex.header   (24 bytes)
writing /sys/SparrowCalFile.hex  (144004 bytes)
Corrupt input data
Traceback (most recent call last):
  File "unpack.py", line 160, in checkCreateDir
    os.makedirs(os.path.dirname(filename))
  File "os.py", line 220, in makedirs
FileNotFoundError: [WinError 3] The system cannot find the path specified: ''

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "unpack.py", line 173, in <module>
    main()
  File "unpack.py", line 109, in main
    save(h["filename"],bFile)
  File "unpack.py", line 166, in save
    checkCreateDir(prefix + filename) #create missing directories
  File "unpack.py", line 162, in checkCreateDir
    if exc.errno != errno.EEXIST:
NameError: name 'errno' is not defined

Did you tested the checksum for the GEL file you extracted with Total Commander?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Adrian_Arg. on March 31, 2018, 03:03:32 am
You could do an update of only the correction of the word pluses by pulses, which is the only thing that bothers me ;) ;)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: konnor on March 31, 2018, 06:34:49 am
Pallette got messed up so the screen looks somewhat funny now, see attached screenshot.

Thanks, I somehow did not notice this. I will correct. Most likely the error is not in the palette. Probably in my converter pic <-> bmp (16bit / 24bit) is not quite correctly converted. This error should not influence the operation of the device.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: DC1MC on March 31, 2018, 06:43:13 am
Quick naive question @konnor, is this firmware suitable for the MSO1000Z series ?

 Thanks,
 DC1MC
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ebastler on March 31, 2018, 06:43:36 am
Probably in my converter pic <-> bmp (16bit / 24bit) is not quite correctly converted.

So you seem to have gone deeper into the firmware than just patching bytes in the binary, right? I would love to learn a bit more about your approach. Could you open a new thread and describe how you did this, please?

(Also, as others have mentioned above, being able to "trick" the scope into accepting any firmware versions, including downgrades to older versions, would be a feat of its own. And you mentioned something about generating keys independent from serial numbers, which I'm sure would also interest quite a few people here...)

Thank you for the work you have done, and for sharing the results with us. And thank you in advance for sharing some of the background!  :-+
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Wirehead on March 31, 2018, 04:37:44 pm
Awesome work being done  :-+ :-+
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: janekivi on March 31, 2018, 07:20:05 pm
You could do an update of only the correction of the word pluses by pulses, which is the only thing that bothers me ;) ;)

You definitely haven't seen our thread...
https://www.eevblog.com/forum/testgear/rigol-dsxxxx-gel-firmware-file-format/msg1453156/#msg1453156 (https://www.eevblog.com/forum/testgear/rigol-dsxxxx-gel-firmware-file-format/msg1453156/#msg1453156)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Adrian_Arg. on March 31, 2018, 07:40:39 pm
my English is not good, so I understand you have to do it yourself, but I do not understand that, that's why I asked Konnor if he did not have the latest firmware version of the rigol ds1054z with the correction of the word pulses
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: konnor on March 31, 2018, 07:47:09 pm
I did not engage in the reverce-engineering of those 8 kilobytes of operations with long integers. I use the original firmware signature and adjust the firmware so that the codes match. The current firmware is laid out in a separate thread.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: janekivi on March 31, 2018, 07:59:09 pm
We did it exactly the same way but finally we like to make new footer and test more
before we release something reliable.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ankerwolf on March 31, 2018, 08:03:40 pm
Simply rename the .01.zip to .z01 and open the .zip with any packer (WinRAR, 7zip, ...).
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: rob040 on March 31, 2018, 08:21:35 pm
Simply rename the .01.zip to .z01 and open the .zip with any packer (WinRAR, 7zip, ...).
Yessss, that does the trick. Thanks!
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Payne on April 09, 2018, 06:56:40 am
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
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 09, 2018, 07:42:06 am
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
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Payne on April 09, 2018, 07:53:47 am
Try to set the probe for CH1 at 1x, then it should be there!
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on April 09, 2018, 08:02:13 am
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.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 09, 2018, 08:12:35 am
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.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: RoGeorge on April 09, 2018, 08:17:00 am
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.

Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Payne on April 09, 2018, 08:28:42 am
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
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: JohnPen on April 09, 2018, 08:43:44 am
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.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Fungus on April 09, 2018, 08:46:40 am
I can not reproduce that on my scope.settings.

Nor me.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ebastler on April 09, 2018, 08:59:53 am
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.

Quote
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 (https://www.batronix.com/pdf/Rigol/UserGuide/DS1000Z_UserGuide_EN.pdf,),  page 17-2

EDIT: fixed the link
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ankerwolf on April 09, 2018, 09:11:21 am
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
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: JohnPen on April 09, 2018, 09:22:11 am
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. ;D
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: JohnPen on April 09, 2018, 09:25:51 am
Hi ankerwolf,

Did you Set VerticalRef = Center before doing the test?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ankerwolf on April 09, 2018, 11:28:36 am
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
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on April 09, 2018, 12:22:34 pm
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.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: tv84 on May 12, 2018, 04:24:36 pm
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 (https://www.eevblog.com/forum/testgear/new-firmware-ds1000z-00-04-04-03-05-2018-05-09-(2018-02-28)/msg1534916/#msg1534916)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: RoGeorge on May 17, 2018, 11:51:54 am
The 1GSa/s, or the full 24Mpts memory, are possible to select only for CH2 alone (or for no channels at all ;D ).

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?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on May 17, 2018, 12:02:55 pm
The 1GSa/s, or the full 24Mpts memory, are possible to select only for CH2 alone (or for no channels at all ;D ).

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).
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: BravoV on May 17, 2018, 12:40:00 pm
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.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: JohnPen on May 17, 2018, 05:50:55 pm
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?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: metrologist on May 17, 2018, 06:03:09 pm
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.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: RoGeorge on May 17, 2018, 06:25:21 pm
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.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: JohnPi on September 02, 2018, 08:05:51 pm
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 ?
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on September 03, 2018, 10:56:33 am
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.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: JohnPi on September 03, 2018, 12:36:03 pm
I looked through that code (I don't have a convenient system to build/run it on)-- it appears to download either 1200 or 250000 bytes. My problem is when downloading 8244+n*64 only -- 250000 is not an issue in that.

My problem arose when I was specifically downloading different lengths in the range below 30000; it arose from old habits of being frugal with memory. I changed my own code to download 8000 byte chunks, but I guess I could just download a single 30000 byte block and truncate it.

In the end, I don't know if this ia Rigol or a pyvisa bug.

p.s. I updated my example above to select the USB instrument more easily.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: MarkF on September 03, 2018, 12:54:33 pm
It looks like you're trying to use a USB connection?

I don't know if it will have any effect.  But, you could try changing the OS low level receive buffer size.  The default size for a LAN connection would be different than a USB connection.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: JohnPi on September 03, 2018, 04:19:50 pm
@PeDre - thanks for checking. I see it works for you at 8244. What is that program you used ?

When I run my pyvisa program with different values for chunk_size:
DS1054Z = GPIB.open_resource([_ for _ in GPIB_Resources if re.search('^USB.*:DS.*INSTR$', _)][0],chunk_size=3000)

it doesn't appear to fail as often, but there are definite slow downs at some points (watch the results scroll by) -- they appear to be at 64-count intervals. In my case, starting at 8200:
for NPOINTS in range(8200,30100):# fails at 8244 first

gives a slowdown (but not a fail) at 8226.

3.6.5 |Anaconda, Inc.| (default, Mar 29 2018, 13:32:41) [MSC v.1900 64 bit (AMD64)]
visa 1.9.1
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: JohnPi on September 03, 2018, 04:42:22 pm
It looks like you're trying to use a USB connection?

I don't know if it will have any effect.  But, you could try changing the OS low level receive buffer size.  The default size for a LAN connection would be different than a USB connection.

Yes, USB. I have tried with the LAN with longer lengths with no problems. I haven't tried this code over the LAN -- will do (it appears you have to reboot the scope to switch from USB to LAN).

-- update: - I can't get my pyvisa to work over the LAN. Anyone know the magic resource name ? IP = 10.1.0.54, port = 5555
Code: [Select]
GPIB = visa.ResourceManager()
DS1054Z = GPIB.open_resource('TCPIP0::10.1.0.54::5555::INSTR')
print("DS1054Z:", DS1054Z.query("*IDN?"))
fails

Don't know how to change the OS buffer size. There is a chunk_size option in pyvisa which has an impact -- it moves the starting point of the issue around, but doesn't eliminate the issue.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Hauke on December 29, 2018, 07:15:48 pm
Hi all,

for me the password login rigollan/111111 or test/111111 never worked, and since the headline post of this thread states that this problem should be gone with the current firmware version, I updated and tried again; no success. But this finally worked for me:


So I used as username test, blah, 1234, a - all worked. 12345 or rigollan or rigolan did not work.

No idea why my scope behaves differently as others, but from the forum I find others that used test and blah also successfully.

Whatever - /me is happy now.

Cheers

Hauke
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: ankerwolf on January 01, 2019, 03:39:47 pm
Hello,
I posted sometimes:

With the last Version 00.04.04.03.05 the login is now working with:
username: rigolan
password: 111111

LG Wolfgang
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Hauke on January 04, 2019, 06:17:15 pm
Hi Wolfgang,

sorry to say: But not for me. It is as I write: any four letter (or shorter) username works, anything 5 digits plus: No success.

Or are we talking about different logins? I refer to accessing http://[IP of the scope]/, and then hitting "Network settings". Where do you refer to?

Cheers

Hauke
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: PeDre on May 21, 2019, 05:51:29 am
DS1104Z-S, Software 04.04.SP4

I can only read the first 99 frames from the recordings with SCPI commands.
It doesn't matter if you read the screen or the memory data, 100 is the end.
Saving on a USB stick works on the oscilloscope even with frames larger than 99.

The same code or SCPI commands work with a MSO2000A without problems with more than 100 recordings.

Can anyone confirm this error?

Code: [Select]
Screen data:
OK frame 99
0008 [07:57:21] DS1104Z - Before Waveform SCPI: :FUNCtion:WREPlay:FCURrent 99;:WAVeform:MODE NORMal;:WAVeform:FORMat BYTE;:WAVeform:STARt 1;:WAVeform:STOP 1200
0009 [07:57:21] DS1104Z - Waveform SCPI: :WAVeform:Source CHANnel1;:WAVeform:PREamble?;:FUNCtion:WREPlay:FCURrent?;:WAVeform:DATA?

ERROR frame 100
0010 [07:57:50] DS1104Z - Before Waveform SCPI: :FUNCtion:WREPlay:FCURrent 100;:WAVeform:MODE NORMal;:WAVeform:FORMat BYTE;:WAVeform:STARt 1;:WAVeform:STOP 1200
0011 [07:57:50] DS1104Z - Waveform SCPI: :WAVeform:Source CHANnel1;:WAVeform:PREamble?;:FUNCtion:WREPlay:FCURrent?;:WAVeform:DATA?
0012 [07:57:55] Error: DS1104Z - The data could not be received. LibUsb::BulkTransfer: (-7) LIBUSB_ERROR_TIMEOUT - Operation timed out

Peter
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: PeDre on May 24, 2019, 07:15:07 am
DS1104Z-S, Software 04.04.SP4

Since the firmware update to 04.04.SP4, I cannot read waveform data with more than 10 MB via SCPI command.
The 6 MB work, the 12 MB data are aborted at 10 MB. The oscilloscope will then stop sending data. But you can read in data afterwards without any problems. The oscilloscope did not get stuck.
It worked with the previous software 04.04.SP3.

Can anyone confirm that?

Peter
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on May 24, 2019, 11:04:51 am
DS1104Z-S, Software 04.04.SP4

Since the firmware update to 04.04.SP4, I cannot read waveform data with more than 10 MB via SCPI command.
The 6 MB work, the 12 MB data are aborted at 10 MB. The oscilloscope will then stop sending data. But you can read in data afterwards without any problems. The oscilloscope did not get stuck.
It worked with the previous software 04.04.SP3.

Can anyone confirm that?

Peter

Does the same happen when using DSRemote?
At this moment I don't feel like upgrading the firmware of the scope...
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: RoGeorge on May 24, 2019, 11:41:18 am
Can anyone confirm this error?

No, because you gave no "Steps to reproduce" the error.



Can anyone confirm that?

No, because you still didn't give any "Steps to reproduce" the failure.
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: PeDre on May 24, 2019, 05:24:04 pm
Does the same happen when using DSRemote?
At this moment I don't feel like upgrading the firmware of the scope...

DSRemote works with the LAN connection, very fast even. The USB connection doesn't work for me. I did everything the way it says on your page. Also rebooted, but doesn't help. I am not a Linux user and don't know how to help me at the moment. I have Ubuntu 18.04 LTE 64-bit.

Edit: The recordings also work with more than 99 frames. However, when saving the memory data, an error message "YREF out of range" appears.

Edit2: The USB connection is present, but the *IDN? command is not received. In the terminal I can receive the answer from 'echo ":SYST:ERR?" > /dev/usbtmc0; cat /dev/usbtmc0', but not from '*IDN?'. '*ESR?' also works.

Edit3: I changed the code and inserted the IDN output into the code. But after connecting and a long series of 'tmc_dev write ...', the device reacts with relay clack, there is an error: 'Can not read from device'.
Messagebox: "An error occurred while reading screen data from device. File screen_thread.cpp line 769"

Peter
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on May 25, 2019, 07:05:16 am
DSRemote works with the LAN connection, very fast even. The USB connection doesn't work for me.

From the webpage of DSRemote:

Quote
Unfortunately, there's a bug in the firmware of the scope that causes connection problems
when your computer uses an xHCI host controller (USBv3.x).
Computers with an EHCI host controller (USBv2) will work fine.
Rigol has been informed about this firmware bug. They acknowledged the bug and said
they have no plans to fix it.
So, if DSRemote generates the error message "Can not read from device", check the following.
Open a terminal and enter

  echo "*IDN?" > /dev/usbtmc0; cat /dev/usbtmc0

If it response like this:

  RIGOL TECHNOLOGIES,DS1104Z,DS1ZA17040xxxx,00.04.04.SP3
  cat: /dev/usbtmc0: Connection timed out

the connection is ok. If not, there's a problem. Check the following:

  dmesg | grep -i xhci | less

This will show you if your computer has an xhci host controller.

  dmesg | grep -i ehci | less

This will show you if your computer has an ehci host controller.
Some computers have both. In that case use an USBv2 port, not an USBv3.x port (blue).

p.s.: not all xHCI host controllers causes connection problems. It depends on the brand and
model of the chip on the motherboard of your computer.
The cause is that Rigol presents itself as an USB 2.0 High Speed device but it uses a packetsize
of 64 bytes. The USB 2.0 protocol specification dictates that highspeed connections MUST use a
packetsize of 512 bytes. Now, some USB host controller chips are "forgiving" and accept the smaller
packetsize. Some USB host controllers are less forgiving and don't accept the too small packets.
You can see the packetsize protocol violation of Rigol when you type dmesg in a terminal after you
connected the scope:
Code: [Select]
  usb 3-2: new high-speed USB device number 4 using ehci-pci
  usb 3-2: config 1 interface 0 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
  usb 3-2: config 1 interface 0 altsetting 0 bulk endpoint 0x3 has invalid maxpacket 64
  usb 3-2: New USB device found, idVendor=1ab1, idProduct=04ce
  usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
  usb 3-2: Product: DS1000Z Series
  usb 3-2: Manufacturer: Rigol Technologies.
  usb 3-2: SerialNumber: DS1ZA17040xxxx
  usbcore: registered new interface driver usbtmc
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: PeDre on May 25, 2019, 07:19:26 am
Thanks Karel, all my USB2-Ports using xhci_hcd.
The same PC with Windows 7 has no problem with the DS1000Z.

Edit: I found another PC with EHCI, will test with it.

Peter
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: PeDre on May 25, 2019, 09:32:02 am
There is no problem with DSRemote and the DS1000Z software 04.04.SP4. Reading 12 MB of wavefrm data works, and playing the recordings over 99 frames. All with LAN and USB connection. The error must be in my program, I'm sorry for the noise.

Peter
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: PeDre on May 25, 2019, 10:38:01 am
I found a possible error, but it's unusual.

I send the following commands before downloading the records:
Code: [Select]
:FUNCtion:WREPlay:FCURrent 99;:WAVeform:MODE NORMal;:WAVeform:FORMat BYTE;:WAVeform:STARt 1;:WAVeform:STOP 1200

This works up to frame 99, then no longer, higher frames are not displayed.
But if I send the short form 'STAR' instead of 'STARt' it works.
Code: [Select]
:FUNCtion:WREPlay:FCURrent 123;:WAVeform:MODE NORMal;:WAVeform:FORMat BYTE;:WAVeform:STAR 1;:WAVeform:STOP 1200

So it seems to be better to always use the short form, even if it is less readable.

EDIT: It has nothing to do with the command, but with the length of the commands. There seems to be a limit!
I have now used the short form for all commands and everything works, including the 12 MB download.
The limit is apparently 110 characters. Sending data like ':SYST:SET #9000002081...' still works with more than 110 bytes.

But I am not sure if the error is still in my program.
EDIT2: I've recorded the USB traffic, and I'm sending the complete commands. It must have changed something in the new firmware 04.04.SP4, or I've never reached that limit before.

EDIT3: I don't know where the mistake is. I can also send commands with 439 characters, and all are executed correctly. It must also be the combination of the commands. But anyway, it's working now.
DSRemote sends the commands all individually, and therefore no problems.

Result: Only use the short form of the SCPI commands.

Peter
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on May 26, 2019, 07:28:59 am
I'm glad to hear that you found a solution/workaround.

If I may say so, the firmware of the DS1000Z is a big unreliable mess.
(But still, a great value hobbyists scope for an excellent price.)
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: RoGeorge on May 27, 2019, 11:46:15 am
SCPI commands takes time to execute.  Pushing too many commands at once, or too many one by one but too fast, might not work.

There are ready/busy and/or OK/error SCPI indicators, as words or as bits, that tells the status of the instrument.  The status indicators will tell whether the instrument is ready or not to process the next SCPI command(s).
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: PeDre on May 27, 2019, 02:56:49 pm
SCPI commands takes time to execute.  Pushing too many commands at once, or too many one by one but too fast, might not work.

There are ready/busy and/or OK/error SCPI indicators, as words or as bits, that tells the status of the instrument.  The status indicators will tell whether the instrument is ready or not to process the next SCPI command(s).

I wrote the USB-TMC protocol in my program myself and tested it against several devices. I also programmed it for a PIC18F, so that I can test everything as good as possible.
The Rigol DS1000Z does not stick to the standard. You can query status bits, but their value is not updated, or not supported at all. The status byte in interrupt transfer is always zero. The MAV bit is ignored and so on.
And that with all my five Rigol devices. There are even SCPI commands that behave differently, e.g. on the DSA815, depending on whether the LAN or USB connection is used.

Peter
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: Karel on May 27, 2019, 03:38:31 pm
SCPI commands takes time to execute.  Pushing too many commands at once, or too many one by one but too fast, might not work.

There are ready/busy and/or OK/error SCPI indicators, as words or as bits, that tells the status of the instrument.  The status indicators will tell whether the instrument is ready or not to process the next SCPI command(s).

I wrote the USB-TMC protocol in my program myself and tested it against several devices. I also programmed it for a PIC18F, so that I can test everything as good as possible.
The Rigol DS1000Z does not stick to the standard. You can query status bits, but their value is not updated, or not supported at all. The status byte in interrupt transfer is always zero. The MAV bit is ignored and so on.
 And that with all my five Rigol devices.

Peter

I can confirm that. Unfortunately...
Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: rob040 on August 12, 2019, 11:30:35 am
Not sure if every DS1000Z owner is following/reading all related threads, but to keep this one a little bit up-to-date, the latest SW is now:

v00.04.04.04.03  2019/05/30
- Fixed the wave error when STOP and changing Timebase


Title: Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
Post by: frozenfrogz on August 12, 2019, 11:34:29 am
Sorry, I have been pretty busy lately and did not follow the forums much.

I will update the OP with links to the latest firmware. Can someone tell what bugs have been fixed (that are still listed as bugs) so I can put it into the OP also?

Thank you!