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

[frozenfrogz]

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 (please read the first post to get some overview, thanks to the OP rolycat ).

Disclaimer

Because the original posting from kwass 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
Direct download link to last release that also contained boot version update file: V.00.04.00.00.00

Check this link 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:

• Pluses spelling fixed
• Login via LAN interface is now working, usr: rigollan pw: 111111
• Centering of all traces now spot on after self cal. procedure
• Font size selection is now kept on power cycle just as other settings
• Select item menu works on all font sizes
• FFT works on all channels, select channel via soft menu "Source"
• Large fonts push items up instead of covering, or other items are overlayed (intensity)
• MATH functions shows generic unit U instead of channel unit
• Waveform shift resolved (old buglist item 9)
• RAW mode of data acquisition over USB now returns sane data

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:

• NEW! The display of the scope does not represent the full ADC resolution. See this post by Karel and the follow ups for more information.
  
  
• There are reports on locking up after updating. However, it does not seem irrevocable and there are no reports of permanently bricked devices to date (2018-03-01). This might be due to board version 0.1.1 and older, but could also affect newer board versions. So far everyone running into a calibration fail was able to clear it by rebooting and running self cal. again – eventually it would work on second, or third try. However, the WHY is still unresolved.
  
  
  • Behavior is as follows: Update works fine, but after reboot additional soft buttons turn up next to »Self Calibration«. Self cal. routine quits with error and locks up the device. Power cycle resolves to a regular screen, additional soft buttons disappearing and being able to successfully run self calibration routine on board version 0.1.1, boot version 0.0.1.3, firmware 0.2.3.11, CPLD 1.1 and 2.2.
  
  
• 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.
  
  
  • Saving is still painfully slow. I don't think something changed here.
  
  
• The 20M Bandwidth Limit setting for each channel is not saved, it resets of OFF each power cycle.
  
  
  • Not resolved as of today.
  
  
• 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/
  
  
  • Pass: Board Version: 0.1.4, Boot Version: 0.0.1.4, Firmware Version: 0.2.3.11, CPLD Version: 1.1
  • Pass: Board Version: 0.1.1, Boot Version: 0.0.1.3, Firmware Version: 0.2.3.11, CPLD Version: 1.1
  • Pass: Board Version: 0.1.1, Boot Version: 0.0.1.2, Firmware Version: 0.2.3.11, CPLD Version: 1.1
  • Fail:  Board Version: 0.1.1, Boot Version: 0.0.1.2, Firmware Version: 0.2.3.11, CPLD Version: 1.1
  • Fail:  Board Version: 0.1.1, Boot Version: 0.0.1.2, Firmware Version: 0.2.3.11, CPLD Version: 2.2
  • Pass: Board Version: 0.1.1, Boot Version: 0.0.1.1, Firmware Version: 0.2.3.11, CPLD Version: 1.1
    
    
• Remote I/O menu will not allow selection of LAN if USB is ON.  You need to unplug the USB device first.
  
  
  • Needs to be tested.
  
  
• 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.
  
  
  • Needs to be tested.
  
  
• USB bug causes problems depending on PC / laptop hardware & driver, because of illegal packet size of 64 bytes instead of standard conform 512 bytes. DS1000Z registers as "high speed USB". This leads to detecting the device on the bus, but not being able to communicate. Possible workaround (?) get the device registered as "full speed USB" instead? USB reference material
  
  
• (needs evaluation) Some combinations of USB thumb drive, FAT16/32 file system and board version (?) lead to unbearable long times saving screenshots
  
  
• Remote control via LAN / telnet commands misbehaves
  Querying :FUNC:WREP:FMAX? returns the value of :FUNC:WREP:FEND, not the number of frames recorded in memory (set with :FUNC:WREC:FEND). More detailed post here.
  
  
• SCPI Syntax Error Handling Bug
  Oscilloscope won't respond to any other SCPI command, and it won't accept new TCP connections until the next power cycle.
  Please see detailed description here.
  
  

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)

[frozenfrogz]

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

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/

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)

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:



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/

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).

[frozenfrogz]

I could not reproduce the waveform shifting bug in the latest firmware.
Please confirm.

[BravoV]

Subbed

[Gabri74]

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

[Karel]

There's a bug missing in your list: https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg1178649/#msg1178649

[Karel]

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.

[frozenfrogz]

Done.

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

*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?

[Fungus]

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. 

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.

v00.04.03.01.05   2015/06/16
     - Added French in system language

[frozenfrogz]

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. 

[kcbrown]

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/

(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

[frozenfrogz]

That is unfortunate 
Thanks for testing and sharing.

Added Pass/Fail info on bug list.

[Fennec]

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:

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.   

[kcbrown]

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.

[Fennec]

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.

[2N3055]

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/

(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:

[kcbrown]

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.

[2N3055]

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:

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.

[bitseeker]

Thanks for creating the new thread, frozenfrogz. Following.

[metrologist]

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.

[frozenfrogz]

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

@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

[Fennec]

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.

[ankerwolf]

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

[frozenfrogz]

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

Also there is a memory clearing procedure:
PDF from Rigol on sanitizing memory

Good luck!

[Fennec]

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.

[bitseeker]

Never never again I buy those cheap crap from Rigol !

hf
"Pluses"

Yes, there are some minuses.

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.

[ebastler]

Did you try deep cycle / alternative reset?
PDF from Rigol on alternate reset

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

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?

[alsetalokin4017]

Did you try deep cycle / alternative reset?
PDF from Rigol on alternate reset

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.

Also there is a memory clearing procedure:
PDF from Rigol on sanitizing memory

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.

[Fennec]

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 ?!

[frozenfrogz]

On the positive side: I am glad you could revive your scope via reinstalling the firmware again.

[Fennec]

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.

[frozenfrogz]

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.

[Fennec]

There's /was a RIGOL contributor here in the forum.

[Fungus]

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? 

[Fennec]

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"

[kcbrown]

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.

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.

[Lightages]

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.

[Fungus]

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.

[ankerwolf]

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

[ankerwolf]

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

[Fennec]

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 ?

[Fennec]

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

[rsjsouza]

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?

[Fennec]

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   

[ankerwolf]

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

[Fennec]

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.

[ProBang2]

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).   

There is (well hidden) on page 16-2 under point 8. (3) in the DS 1054Z Manual 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" 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...   

[Fungus]

"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.

[frozenfrogz]

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.

[Fungus]

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.

[rsjsouza]

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).

[bitseeker]

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

[frozenfrogz]

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.

[rstofer]

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.

[BravoV]

From Rigol manual :

[bitseeker]

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 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.

[frozenfrogz]

Testing out different allocation unit sizes might be worth trying.
BRB

[BravoV]

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 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 ? 

[frozenfrogz]

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...

[smithnerd]

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 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

[ankerwolf]

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

[frozenfrogz]

Thanks ankerwolf
Sooo.. Maybe we can pin this on boot version <0.1.3?
(still needs a bigger dataset obviously)

[Fungus]

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...


(Screenshot took about 8 seconds to complete)

[BravoV]

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.

[frozenfrogz]

Thanks BravoV,

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

[BravoV]

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.

[BravoV]

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.

[frozenfrogz]

Also: You got a hardware upgrade via USB implant as it seems xD

[BravoV]

Also: You got a hardware upgrade via USB implant as it seems xD

Yep , what a sharp eyes you got there. 

[frozenfrogz]

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

[ebastler]

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...

[bitseeker]

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.

[frozenfrogz]

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.

[BravoV]

LOL  , 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.

[frozenfrogz]

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

[rbino]

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.

[rbino]

Ok, I've just finished the third self-calibration since the software upgrade and this time it didn't fail.

[frozenfrogz]

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?

[szpila]

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

[Sredni]

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.

[frozenfrogz]

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?

[rbino]

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.

[ProBang2]

[...] 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?

[Gary.M]

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?

[BravoV]

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. 

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



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.

[bitseeker]

Sounds plausible to me.

[BravoV]

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.

[BravoV]

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 :

• While in the "Expanded" mode, insert an USB flash drive, and of course assuming its trouble free like you can save files without problem.
• Go to the Self-Cal menu, and then press the "Output" button
• It will save a new file at root directory in the USB flash named "CalData.txt".  (PS : It will not notify anything on screen when it saves that file, but it should be fast, say in few seconds)

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


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

[ted572]

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.

[Gary.M]

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.

[maxiq4]

Im updated, ds1054Z, self cal is ok

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

[metrologist]

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?

[maxiq4]

thank you 

[video]

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 ?

[Roeland_R]

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

[ebastler]

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...

[video]

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

[Sredni]

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},
},
...

[bitseeker]

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.

[garnix]

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...

[bitseeker]

That would be nice. The offset does aggravate the OCD.

[BravoV]

I don't think I will try an "LFCal" any time soon...

Definitely not me either. 

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. 

Probably those people who contribute at this thread ->  Rigol DS10xxZ firmware re-write

[Fungus]

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)

[video]

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..

[video]

  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

[tautech]

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.

[BravoV]

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.

[ebastler]

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?

[zbyr]

I tried google translate with these chinese characters, and it seems ok.

Attached file with translated headers.

[video]

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 ?

[Karel]

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.

[Fungus]

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:

[metrologist]

maybe because that is the way they've written it, but I would expect the FEND? keyword. that stuff happens to the best anyway...

[Karel]

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.

: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.

[pascal_sweden]

Who is actually communicating all these bugs to Rigol? Or is there a Rigol application engineer on this forum?

[Karel]

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.

[Fungus]

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.

: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. 

PS: You can play back a subset of frames using the ":FUNCtion:WREPlay:FCURrent" function, or just start playing and monitor the current position.

[Karel]

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?

[kcbrown]

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.

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?

[Karel]

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.

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  !!

[kcbrown]

: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

[technogeeky]

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.

• It would be easy for them to determine people who brick their scopes from firmware changes.
• Clearly there aren't companies even younger than Rigol trying to copy them.
• It would allow Rigol to do absolutely no product development and still increase their pressure on the competition

. 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].

• Rigol could even re-use the improvements in future scopes; allow customers to adapt features they like from competitor's scopes (like Rhode and Schwartz's amazing serial decode UI) and re-integrate these features into their scopes while being liability free...

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

[Fungus]

: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. 

[bitseeker]

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".

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.

[boggis the cat]

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.)

[BravoV]

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. 

[boggis the cat]

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.

[Karel]

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...

[Karel]

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.

[BravoV]

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  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 ?   

... 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 ...   

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. 

[boggis the cat]

"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.

When its time to RMA, and as usual, "few" users  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.  🤔

"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.

"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 ?   

The DS1054Z doesn't have a 50 Ohm input.  I don't see how you could damage it through a firmware issue.

... another "what if" ... the over temperature mechanism is triggered, and the ISR for handling shutdown sequences is ignored or buggy ...   

Un-bricking time again...

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.

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. 

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.

[BravoV]

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 ? 

[boggis the cat]

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.)

[boggis the cat]

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.

[frozenfrogz]

Dudes!

It would be really nice to keep the chatting in the New Rigol D1054Z thread 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, 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

[Karel]

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.

[BravoV]

@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.

[HoracioDos]

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

[frozenfrogz]

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

[HoracioDos]

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!!!

[frozenfrogz]

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.

[technogeeky]

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.

[sandor626]

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 !!


 

[Nat]

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.).

[frozenfrogz]

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

[Nat]

Make sens, this .gel loaded USB stick is burning my fingers anyway

Thanks.

[grants225]

regarding ""pluses" - did I missed something, but yesterday I updated and see this    :

[ebastler]

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.

[psysc0rpi0n]

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!

[Fungus]

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

[frozenfrogz]

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 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.

[psysc0rpi0n]

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?

[frozenfrogz]

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.

[PeLa]

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.

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

[ebastler]

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.

[PeLa]

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.

[bitseeker]

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.

Just a matter of semantics? Absolutely. The meanings are important.

[frozenfrogz]

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

[bitseeker]

It's a feature request, yes.

[PeLa]

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.

[bitseeker]

Sure thing. Thanks for chiming in, PeLa. We can't all know about every industry's use cases.

[RoGeorge]

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.
 



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?

[zbyr]

Yup. Bug also exist in SCPI with USB connection.

[RoGeorge]

Thank you for testing it.

[Karel]

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?

[SparkyM8]

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.

[RoGeorge]

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.

[frozenfrogz]

Original posting has been updated with info on SCPI lock up.

Regards,
Frederik

[rob040]

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.

[bitseeker]

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.

[Wall-E]

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.

[Karel]

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"

[ebastler]

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". 

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.

[Karel]

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%!

[frozenfrogz]

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.

[Karel]

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.

[frozenfrogz]

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

[Karel]

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.

[bitseeker]

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?

[Fungus]

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.

[bitseeker]

Yeah, ease of implementation.

[Karel]

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?

[bitseeker]

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.

[Fungus]

Then why didn't they do it with the 4000 series which uses the same resolution?

Bigger FPGA, more free gates?

Who knows...?

[technogeeky]

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!

[bitseeker]

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.

[frozenfrogz]

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

[metrologist]

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?

[RoGeorge]

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.

[metrologist]

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.

[Karel]

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.

[Karel]

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.

[metrologist]

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.

[Karel]

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.

[metrologist]

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?

[Karel]

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.

[metrologist]

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.

[Fungus]

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. 

[Karel]

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.

[Fungus]

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.

[metrologist]

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?

[Karel]

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.

[metrologist]

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.

[bitseeker]

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.

[Karel]

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.

[TD-Linux]

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.

[bitseeker]

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.

[frozenfrogz]

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.

[bd139]

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.

[RoGeorge]

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.

[frozenfrogz]

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 )

[Karel]

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.

[lundmar]

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.

[RoGeorge]

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.

[lundmar]

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.

[Karel]

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:

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

[lundmar]

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:


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.

[RoGeorge]

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.
 
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.

[Karel]

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:

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

[lundmar]

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 

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.
 

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.

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.

[RoGeorge]

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/
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?

[lundmar]

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/
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/ 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.

[TinkeringSteve]

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...)

[frozenfrogz]

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.

[Karel]

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.

[TinkeringSteve]

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.

[frozenfrogz]

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.

[TinkeringSteve]

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.

[frozenfrogz]

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!

[bitseeker]

Excellent. Thanks for doing that. Hopefully, one day Rigol will pay attention to what goes on here. So far, they seem not to notice.

[frozenfrogz]

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

[Fungus]

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.

[frozenfrogz]

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

[Roeland_R]

For the wish list: Alternate triggering perhaps?

[frozenfrogz]

Re. alternate triggering: There is this thread.

I’ll add it as a wish list item when going through the post

[Karel]

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.

[Fungus]

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...)

[Porcine Porcupine]

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/

Reddit post by someone with the same problem: 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:

• Software Version: 00.04.04.03.02
• Board Version: 0.1.4
• Boot Version: 0.0.1.4
• Firmware Version: 0.2.3.11
• CPLD Version: 1.1

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):



Here's the raw acquisition memory data plotted:



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:



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.

[frozenfrogz]

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

[Porcine Porcupine]

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

[frozenfrogz]

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.

[Fungus]

This has had its own thread:

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

[Porcine Porcupine]

This has had its own thread:

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.

[Fungus]

This has had its own thread:

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!)

[Porcine Porcupine]

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:



And here's one captured in peak detect mode:



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.

[Fungus]

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).

[2N3055]

@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

[frozenfrogz]

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.

[frozenfrogz]

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.

[Fungus]

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.

[frozenfrogz]

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.

[metrologist]

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.

[Porcine Porcupine]

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.

[Porcine Porcupine]

@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.

[Porcine Porcupine]

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:



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:



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:



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?

[Porcine Porcupine]

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.

[Fungus]

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

[Porcine Porcupine]

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

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?

[Fungus]

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. 

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

[ebastler]

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.

[Porcine Porcupine]

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. 

(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.

[Fungus]

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!

[ebastler]

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.

[2N3055]

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

[ebastler]

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).

[Porcine Porcupine]

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.

[2N3055]

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....

[2N3055]

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

[Fungus]

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

[ebastler]

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]

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.

[2N3055]

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

[Porcine Porcupine]

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

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.

[konnor]

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/

[ebastler]

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?

[metrologist]

Tempting. Somebody needs to test this. Where did you come from?

[konnor]

Tempting. Somebody needs to test this. Where did you come from?

i don't change version, 00.04.04.03.02

[Fungus]

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.

[ebastler]

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?

[konnor]

Where did you come from?

The city is listed in the profile. 
I have no relationship to Rigol.

[konnor]

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.

[Fungus]

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.

[konnor]

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.

[metrologist]

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...)

[rob040]

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?

[RoGeorge]

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.

[Daruosha]

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.

[Fungus]

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.

[TurboTom]

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

[RoGeorge]

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?

[Adrian_Arg.]

You could do an update of only the correction of the word pluses by pulses, which is the only thing that bothers me

[konnor]

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.

[DC1MC]

Quick naive question @konnor, is this firmware suitable for the MSO1000Z series ?

 Thanks,
 DC1MC

[ebastler]

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! 

[Wirehead]

Awesome work being done 

[janekivi]

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

[Adrian_Arg.]

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

[konnor]

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.

[janekivi]

We did it exactly the same way but finally we like to make new footer and test more
before we release something reliable.

[ankerwolf]

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

[rob040]

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

Yessss, that does the trick. Thanks!

[Payne]

New bug found?

Hi all,

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

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

Rigol DS1054z
SW: 00.04.04.SP3
Board: 0.1.4

[frozenfrogz]

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

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

Boot: 0.0.1.4
FW: 0.2.3.11

[Payne]

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

[Fungus]

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

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

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

[frozenfrogz]

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

[RoGeorge]

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

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

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

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

[Payne]

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

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

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

[JohnPen]

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

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

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

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

[Fungus]

I can not reproduce that on my scope.settings.

Nor me.

[ebastler]

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

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

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

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

EDIT: fixed the link

[ankerwolf]

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

LG Wolfgang

[JohnPen]

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

[JohnPen]

Hi ankerwolf,

Did you Set VerticalRef = Center before doing the test?

[ankerwolf]

Hi,

Did you Set VerticalRef = Center before doing the test?

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

LG

[frozenfrogz]

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

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

[tv84]

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

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

[RoGeorge]

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

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

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

[Karel]

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

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

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

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

[BravoV]

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

+1 , same here at my DS1104Z-S.

[JohnPen]

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

[metrologist]

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

[RoGeorge]

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

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

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

Thank you all for taking the time to test this.

[JohnPi]

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

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

Code: [Select]

import visa
import numpy as np
import sys
import re

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

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

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

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

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

Code: [Select]

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

Code: [Select]

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

[Karel]

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

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

[JohnPi]

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.

[MarkF]

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.

[JohnPi]

@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

[JohnPi]

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.

[Hauke]

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:

• Connect to the scope via http://[IP-Address]
• Select "Security"
• Enter as old password: 111111
• Enter as new password again: 111111 (twice)
• Confirm --> Success message
• log in with any username with four or less letters, pw 111111 --> Works!

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

[ankerwolf]

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

[Hauke]

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

[Karel]

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...

[RoGeorge]

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.

[Karel]

DSRemote works with the LAN connection, very fast even. The USB connection doesn't work for me.

From the webpage of DSRemote:

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


[Karel]

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.)

[RoGeorge]

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).

[Karel]

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...

[rob040]

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

[frozenfrogz]

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!

[BravoV]

Add here for future reference, a broken DS1054Z gets repaired. Also its posted in a non DS1054Z thread.

Problem

-> https://www.eevblog.com/forum/testgear/rigol-red-screen-of-death/msg2847804/#msg2847804

How its repaired

-> https://www.eevblog.com/forum/testgear/rigol-red-screen-of-death/msg2847918/#msg2847918

-> https://www.eevblog.com/forum/testgear/rigol-red-screen-of-death/msg2848050/#msg2848050

[rob040]

The latest update was already on the Chinese website for some time, but now also available in the US, version 00.04.05.02.00!

v00.04.05.02.00  2021/07/24
     - Version Updated.

[History]
-------------
v00.04.05.01.00  2021/06/01
     - Modify the vertical Display.
   
v00.04.05.00.00  2020/12/29
     - Add and modify some measurement functions
     - Modification of math problem
     - Modify some SCPI instruction errors
     - Modify some trigger problems.

I haven't tested it yet.

Edit: On the Chinese website it's already v00.04.05.02.02... 

[Adrian_Arg.]

v00.04.05.01.00  2021/06/01
     - Modify the vertical Display.??

    -Modification of math problem ??

What did they modify? someone explain it to me!

[MarkF]

v00.04.05.01.00  2021/06/01
     - Modify the vertical Display.??

    -Modification of math problem ??

What did they modify? someone explain it to me!

More detailed change history:
https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg3745558/#msg3745558

[Adrian_Arg.]

I read the list from version 00.04.05.02.00 onwards, and it scares me to update, it corrects a lot of errors, but what it can create scares me more  , for something they still did not correct the 24bit deep, they do not want to think about what would happen !!

[DC1MC]

I read the list from version 00.04.05.02.00 onwards, and it scares me to update, it corrects a lot of errors, but what it can create scares me more  , for something they still did not correct the 24bit deep, they do not want to think about what would happen !!

I have loaded and tested the firmware, from calibration, to licenses (all active) to signal shapes compared with previously saved values, to measurement. I can tell that there are no visible regressions.

 Cheers,
 DC1MC

[Adrian_Arg.]

I read the list from version 00.04.05.02.00 onwards, and it scares me to update, it corrects a lot of errors, but what it can create scares me more  , for something they still did not correct the 24bit deep, they do not want to think about what would happen !!

I have loaded and tested the firmware, from calibration, to licenses (all active) to signal shapes compared with previously saved values, to measurement. I can tell that there are no visible regressions.

 Cheers,
 DC1MC

Friend, I installed the firmware, it was installed correctly, the yellow trace and the others were left above the marker, and it does not allow to calibrate, it gives an error at 5 minutes, how degraded?

[DC1MC]

...
Friend, I installed the firmware, it was installed correctly, the yellow trace and the others were left above the marker, and it does not allow to calibrate, it gives an error at 5 minutes, how degraded?

I've installed it on a MSO1074Z (I can provide pictures if needed), I was having exactly zero issues: the procedure was:
Installing -> Power Cycling -> Factory Reset -> Calibration -> Other tests regarding the the behavior.

Everything went A-OK

EDIT: The firmware was taken from here: https://www.rigolna.com/firmware/ and I've used the DS1000Z version, suitable for my scope.

DC1MC

[Adrian_Arg.]

On the sixth try I calibrate, I really don't know what happened to the baby , gracias DC1MC

[DC1MC]

On the sixth try I calibrate, I really don't know what happened to the baby , gracias DC1MC

No hay de qué.

[Njk]

Greetings!

DS1054Z is a new instrument to me. Owned Tek TDS3054B previously. In comparison, Rigol seems noisy but it also has more memory, more SW candies so it has its pros and conrtras, as usual. The scope is of its latest HW generation (I presume), board version 0.1.4.
I've enabled all the options, including 500 uV/div (which works fine, BTW, taking its limitations into account) and installed the firmware of the day, v.00.04.05.SP2.

Now I'm evaluating the FFT capabilities. It's not essential feature for a scopes but anyway.

In DS1000Z, the FFT function can operate in two modes, the Trace mode and the "Memory*" mode. The Trace mode looks like a finished product, At least, it works in a consistent manner. But it's actually a legacy mode, with poor resolution in the frequency domain. The user's manual for MSO5000 series provides better coverage for the matter.

FFT resolution = (FFT sampling rate) / (points number)

In the Trace mode, the FFT function fetches a points from the display memory, so the FFT sampling rate is actually equal to the beam sweep data rate, 100/(T scale) in points/s, and the points number is equal to 1200 (12 horizontal grid divisions, 100 two-pixel point images per division). From that, max. theoretical FFT resolution bandwidth for each T scale can be calculated. For instance, on the smallest T scale:

5 ns/div -> 20 GPts/s -> 16.666 MHz, while the finest FFT F scale setting is 20 MHz/div.

On the largest T scale (not considering the slow sweep scales):

100 ms/div -> 1 kPts/s -> 0.83 Hz, while the finest possible F scale is 1 Hz/div.

So in the Trace mode, on each T scale, the FFT resolution is almost equal to the smallest F scale. Not good, but it would be pointless to try to increase the resolution adding some AI rather than more data, because that would likely result in even more poor spectrum plot. Instead, Rigol finally decided to implement fetching a points from the acquisition memory in their entry level scopes, adding the "Memory*" mode in DS1000Z. In that mode, FFT sampling rate is equal to the instrument's current sampling rate, and the max. points number is equal to 16K, which is about 14 times greater, allowing for a much more accurate FFT.

Specifically, there are two features in DS1000Z, that sources their input data in the acquisition memory, the Frequency Counter, and the FFT function. The Counter works fine, but my experience with FFT in the Memory mode is mixed. I've a feeling that there is a large room for improvement in the SW.

For instance, the book reads "You can adjust the center frequency and horizontal scale at the same time using the horizontal scale knob". It's natural for a user to expect that the displayed readings for the frequency and sampling rate FFT scales will change accordingly. In the Trace mode, that's in fact so. In the Memory mode, when the instrument's sampling rate has changed by the T scale knob rotation, the readings does not change. More precisely, sometimes they changes, sometimes not and sometimes they changes in wrong way. It's not consistent, and the only reliable way to update the readings is to turn the FFT function off and on again, losing all the cursors, configured for the Math window.

But that's the most innocent defect, though it's annoying. On rare occasions, the spectrum trace does not appear at all when the function has cycled on/off/on. Typically, it does, and in that case I've noticed similar inconsistency trying to control the FFT settings. With the same combination of sample rate, mem depth and T scale, sometimes it's possible to configure FFT for desired center frequency and scale, sometimes not, because of too high granularity or because the banner "Parameter Limited!" pop-ups.

I'm failed to figure out a pattern so far. Perhaps it depends on how lucky the scope was at the boot time or how long the user played with the buttons and knobs. Once I witnessed the "Memory leak in FFT" pop-up message. Something is definitely wrong there. Poor software, but it's good enough to make a problems difficult to report because of the sometimes keyword.

I'm hoping someone here who has more experience with that instrument can provide more insights so we can work out a meaningful communiqu to Rigol's attention.

---
WBR

[Njk]

Ok, found a way to navigate around the defects and use the feature.

The trick is in proper sequence. When you'd initially switched to the Memory mode, it's necessary to set the Center frequency at zero, and then set the F scale as desired. Then you can set desired center frequency. Otherwise, it could not be possible because of high granularity of allowed center frequency values. Pretty weird. Looks like missing initialization.

A post without images looks boring now. This is the FFT plot for 1 V 1.1 kHz sine wave signal (img0.png):
" alt="" class="bbc_img" />

Notice the discrepancy in measured amplitude values between the FFT and the RMS item. It's a pure sine wave from a pure analog high quality signal generator, there are no other harmonics, why the 3 dBv difference?, Actually, it's also weather-dependent, could be 0 dB on another day. Perhaps a calibration issue, that's Rigol, never mind.

It's interesting the amplitude value calculated by the FFT can be more accurate, probably because it uses data from the acquisition memory (img1c.jpg):
" alt="" class="bbc_img" />

The Frequency counter also seems working fine for that frequency (img2c.jpg):
" alt="" class="bbc_img" />

Finally, let's increase the amplitude above the channel's clipping level to see the harmonics (img3.png):
" alt="" class="bbc_img" />



Edit: actually, the interdependency of Center frequency and F scale settings is documented, but in the user's manual for DS2000A series: "Note: Setting the horizontal position can changing the center frequency of the FFT operation results indirectly."
---
WBR

[Njk]

Another puzzle. What prevented Rigol from (optionally) dismissing the input signal trace for full screen FFT plot? Displaying both of them can result in total mess on the screen.

Found a workaround. Switch the display in the Dots mode and reduce the beam intensity down to zero. Fortunately, the intensity control does not affect a math traces. For better effect, play with the acquisition mode setting (seemingly it does not affect FFT when it's at the Memory mode). The result: a nice full-screen view.

" alt="" class="bbc_img" />

My apologizes if that trick is long time obvious.

---
WBR

[tautech]

 
Don’t these have a Exclusive FFT mode that doesn’t show the source waveform ?

[RoGeorge]

That's a nice trick  , I don't think DS1054 has the option to display FFT only.

In fact, the FFT functionality in Rigol DS1054Z is unusable in practice.  It works, but it's too cumbersome to operate the settings, too low resolution, and too slow to make any use of it, other than maybe a didactic demonstration.

The most useful trick with FFT on DS1054Z is to avoid the FFT entirely. 

[Njk]

Don’t these have a Exclusive FFT mode that doesn’t show the source waveform ?

No and that's the problem

---
WBR

[Njk]

In fact, the FFT functionality in Rigol DS1054Z is unusable in practice.  It works, but it's too cumbersome to operate the settings, too low resolution, and too slow to make any use of it, other than maybe a didactic demonstration.

It could be better but I'm trying to be positive. Some niche areas, e.g. education..

---
WBR

[Fungus]

In fact, the FFT functionality in Rigol DS1054Z is unusable in practice.  It works, but it's too cumbersome to operate the settings, too low resolution, and too slow to make any use of it, other than maybe a didactic demonstration.

It does work, but it takes a LOT of fiddling with the parameters.

Then if you change the timebase for a different signal you pretty much have to start over. 

The DS1054Z isn't the 'scope for you if FFT is something you use a lot. This has never been a secret.

[Njk]

It does work, but it takes a LOT of fiddling with the parameters.

I was of the same opinion, initially. But now I've to say that actually it's an efficient and elegant UI design, for given environmental constraints. I can't propose anything better (maybe the now popular touch screen technology provides more opportunities, but its advantages are offset by a scratched screen surface, dirty with fingerprints. Not everybody likes that). It's something like a scientific calculator, which uses stack-oriented input notation. Clumsy and inconvenient, but only to those without the idea. To all others, it's very convenient and super efficient.

What is really missing is the documentation. Every new user have to learn how it work. BTW the similar situation is in open source. Looks like the OSS guys are playing their game preventing the things from easy commercialization by competitors. But the Chinese are not dumb, they're thinking in they own way. Perhaps it's as difficult for them to explain something to a westerner, as it was for me to locate an affordable restaurant with casual European kitchen in Taipei. So omission is they favorite game as well.

Concerning the FFT function, the problem is how to configure the two numerical values, the frequency scale (Fscale) and the central frequency (Fc). The latter ranges from zero to the FFT sampling frequency divided by two. It's quite a bandwidth and if you want to achieve high precision and to avoid inconvenience and excessive mechanical wear, two tuning methods are requited, coarse and fine. But there are two controls in all, one is for Fscale and the other is for Fc. Instead of adding one more control, Rigol had decided to overload the existing controls with tuning method selection.

For each FFT sampling frequency, six Fscale values are available. Each Fscale value is associated with unique Fc increment/decrement (step) value. Consider 1 GSa/s sampling frequency as an example:

Fscale = 1 MHz   ->  Fc step is 20 kHz;
Fscale = 2.5 MHz -> Fc step is 50 kHz;
Fscale = 5 MHz    -> Fc step is 100 kHz;
Fscale = 10 MHz  -> Fc step is 200 kHz;
Fscale = 25 MHz -> Fc step is 500 kHz;
Fscale = 50 MHz -> Fc step is 1 MHz.

The Fc value can be set in the range of 500 MHz with 20 kHz precision. The procedure is as follows:

1. Select the highest Fscale value. Coincidentally, pressing the multi-function knob for Fscale does just that.
2. Tune close to desired Fc. That's coarse tuning.
3. Select the finest Fscale.
4. Tune exactly to desired Fc. That's fine tuning.
5. Finally, set Fscale at desired value.

That's it.

---
WBR

[Njk]

That's funny, my FFT experiments resulted in the scope's death. The RSoD syndrome. Definitely I'm not the first one. There is an advisory note of Aug 1, 2022 at the Rigol NA web site with the procedure the user is advised to follow in that case before service application. Did not worked. The Rigol FAE guy was confident that the problem will be easy to fix. Then he realized that in my case they have to order a replacement main board from China.

In the thread about MSO5000 the users reported that the scope is quite hot when operating. It was not like that, but I never took the unit apart to check how hot the parts are. So it might be a coincidence

---
WBR

[Njk]

The scope is back after main board replacement.

State of the art version data, for reference.

Board version: 1.0.4

Extended information (menu menu force menu):

SW version: 00.04.05.02.03
Boot version: 0.0.1.9
FW version: 0.2.3.12
CPLD version: 1.1
Build date: Feb 15 2022 15:54:18 | 0 0:0/ 0 0:30

At first glance, it works not worse, not better. Failed to get release notes for this SW version.

[rob040]

According to me SW version 00.04.05.02.03 has not been published (yet).
Latest was/is: 00.04.05.02.02.

[Njk]

According to me SW version 00.04.05.02.03 has not been published (yet).

That's why I'd asked the local Rigol rep about the release notes. But he also has no information

[Adrian_Arg.]

According to me SW version 00.04.05.02.03 has not been published (yet).

That's why I'd asked the local Rigol rep about the release notes. But he also has no information

Hello, see if this problem was corrected, with the new virmware that you installed. there I give you the link

https://www.eevblog.com/forum/testgear/rigol-1054z-and-1074z-timing-problems-at-500ms-timescale-and-24m-memory-depth/

[Njk]

No miracle. With that version, I was able to reproduce it

[Ben23]

My apologies if this has already been mentioned, but I've skimmed several threads and couldn't find any mention of it, and it's not an easy one to search for.

I've just bought the DS1054Z, its software is up-to-date (00.04.05.SP2, or 00.04.05.02.03 in the expanded info view).

The bottom two vertical measures in the left sidebar last page are weird.
"AC.Vrms" does indeed turn on AC.Vrms, but the Help page brought up by that button is "Variance".

And then there's "3". What is that supposed to be? The Help for "3" says it's AC.Vrms, but what it actually turns on is Period, which isn't even a vertical measure! The icon suggests it should be some other sort of RMS measurement? Or should it be the missing "Variance"?

Also AC.Vrms and a bunch of the horizontal measures don't appear in "Measure All", but I guess they just have a loose definition of "All"...

[RoGeorge]

Mine is one version behind, 00.04.05.02.02, and it doesn't have any icon on the 6th place.  First 4 icons are the same, as in your pics, the 5th is called 'Variance', the last place is empty.

What does the help function says about the 6th icon called "3", if you press 'Help' then '3'?

[Ben23]

Mine is one version behind, 00.04.05.02.02, and it doesn't have any icon on the 6th place.  First 4 icons are the same, as in your pics, the 5th is called 'Variance', the last place is empty.

Interesting.

What does the help function says about the 6th icon called "3", if you press 'Help' then '3'?

It gives the help for AC.Vrms.

[Njk]

Yep. I confirm the "3" icon with the 02.03 version. Pressing on it results in "Period=" item appearance in the bottom. It's so innocent problem I was not sure it's specific to this version.

BTW, my progress in finding the difference is very limited. But from what I've found so far, I think that v.04.05.02.03 is a build dedicated to system stability improvement. With the previous versions, the best way to demonstrate frozen UI was to use FFT. With this version, it does not hang there. That does not mean any FFT defect is fixed. Instead of hanging, the FFT trace just disappears while the scope remains responsive. But after that, the whole math trace "channel" is lost, it's not possible to get a data from the scope (points data, screenshot, etc.), and who knows what else stopped working properly. The scope is not trusted any more and it needs to be power cycled anyway. I don't know what is better. Looks like they don't have access to the low-level FFT code. Perhaps it was received in the binary form with OS/SDK/BSP from Infineon or a third-party vendor. So they can't fix it but the attempt to control the damage is evident.

Overall, no news from them over long time. According to the press release, they recently went public. So new leadership, new vision, new priorities, a lot of empty positions in the local office. Add to this the international unrest, the covid scam, the ship shortage. Seems now they have something more interesting to do rather than just to make the things.

[RoGeorge]

My DS1054z is used rather rare, but I don't recall any hangs with the firmware it has, 00.04.05.02.02.  Used FFT a couple of times, no hangs.  Maybe downgrade back to 00.04.05.02.02 if you find 00.04.05.02.03 to be faultier.

For now, I wouldn't upgrade to 00.04.05.02.03, thanks for the warning.