Author Topic: Rigol DS1000Z series buglist continued (latest: 00.04.04.04.03, 2019-05-30)  (Read 125690 times)

0 Members and 2 Guests are viewing this topic.

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
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)
« Last Edit: August 12, 2019, 11:57:57 am by frozenfrogz »
He’s like a trained ape. Without the training.
 
The following users thanked this post: lowimpedance, Fennec, evb149, willigo3, evzone, s8548a, wolfp, Paul Ed

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: FW 00.04.04.03.02)
« Reply #1 on: April 12, 2017, 08:56:47 am »
Here's my attempt to catalog the bugs and wish list items for the Rigol DS1000Z oscilloscopes.   This should apply to the regular and -s versions, but may not apply to the MSO versions)  I'll try to modify this top post as people add their found bugs and wish list items.  Hopefully Rigol will see this thread and respond to it.

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


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

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



Bugs:

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

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

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

3) The FFT function only works for channel 1.  However it will work for the other channels as long as channel 1 is turned on.  It's actually more complicated than that for more details see this thread: https://www.eevblog.com/forum/testgear/another-rigol-1000z-bug/msg568478/#msg568478

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).
He’s like a trained ape. Without the training.
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #2 on: April 12, 2017, 09:27:22 am »
I could not reproduce the waveform shifting bug in the latest firmware.
Please confirm.
He’s like a trained ape. Without the training.
 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7551
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #3 on: April 12, 2017, 10:07:19 am »
Subbed

Offline Gabri74

  • Regular Contributor
  • *
  • Posts: 112
  • Country: it
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #4 on: April 12, 2017, 10:35:00 am »
I could not reproduce the waveform shifting bug in the latest firmware.
Please confirm.

Confirmed, bug seems gone  :-+

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

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #6 on: April 12, 2017, 10:41:35 am »
7) RAW mode of data acquisition over USB returns garbage, rather than the waveform.

(Not tested)

I tested it and it works fine. Please remove it from the list of bugs.
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #7 on: April 12, 2017, 11:25:55 am »
Done.

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

*yay*

Also: I found the language menu to hold a lot of languages now. As far as I remember it was only chinese and english before. Or am I mistaken?
« Last Edit: April 12, 2017, 11:32:41 am by frozenfrogz »
He’s like a trained ape. Without the training.
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #8 on: April 12, 2017, 11:51:30 am »
Also: I found the language menu to hold a lot of languages now. As far as I remember it was only chinese and english before. Or am I mistaken?

Yes.  :popcorn:

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

Release notes say French was added in 2015.

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

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #9 on: April 12, 2017, 12:09:30 pm »
Strange. I could have sworn that when I first got my scope (00.04.03.xx software) it only showed two options. But then again I could easily confuse it with something totally different.  :-//
He’s like a trained ape. Without the training.
 

Offline kcbrown

  • Frequent Contributor
  • **
  • Posts: 896
  • Country: us
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #10 on: April 12, 2017, 03:21:08 pm »
4) Some users have reported scope lock ups when setting memory depth to AUTO, timebase to 1us, zooming in and changing the persistence from MIN something else. Apparently not all users experience this problem but those that do can reproduce it every time.  See this thread for much more detail: https://www.eevblog.com/forum/testgear/rigol-ds1054z-freeze-up-bug/

(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

 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #11 on: April 12, 2017, 03:27:20 pm »
That is unfortunate  :(
Thanks for testing and sharing.

Added Pass/Fail info on bug list.
« Last Edit: April 12, 2017, 03:33:29 pm by frozenfrogz »
He’s like a trained ape. Without the training.
 

Offline Fennec

  • Regular Contributor
  • *
  • Posts: 135
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: FW 00.04.04.03.02)
« Reply #12 on: April 12, 2017, 03:46:45 pm »
9) If the following settings are used:

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

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



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.   
« Last Edit: April 12, 2017, 04:24:40 pm by Fennec »
 

Offline kcbrown

  • Frequent Contributor
  • **
  • Posts: 896
  • Country: us
Re: Rigol DS1000Z series buglist continued (from: FW 00.04.04.03.02)
« Reply #13 on: April 12, 2017, 03:53:15 pm »
With this settings I change the persist time to anything the scope still freeze. So I have to turn it off (Power cycle and soft-button-reset) to make it usable again. ALL settings gone. Calibration too.

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

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

Also, what are the versions of the various things (CPLD, firmware, board, boot) on your scope?   Note that to get that detailed information, you need to first quickly hit, in the trigger area, MENU MENU FORCE MENU, and then you can go to Utility -> System -> System Info to get the details.
« Last Edit: April 12, 2017, 03:56:51 pm by kcbrown »
 

Offline Fennec

  • Regular Contributor
  • *
  • Posts: 135
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: FW 00.04.04.03.02)
« Reply #14 on: April 12, 2017, 03:56:43 pm »
Did you try a plain power cycle before doing a soft button reset?
Yepp, but most times it wouldn't work. I have to do a full reset, with the soft button. Maybe 8 of 10 times.
 

Online 2N3055

  • Super Contributor
  • ***
  • Posts: 7561
  • Country: hr
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #15 on: April 12, 2017, 03:57:18 pm »
4) Some users have reported scope lock ups when setting memory depth to AUTO, timebase to 1us, zooming in and changing the persistence from MIN something else. Apparently not all users experience this problem but those that do can reproduce it every time.  See this thread for much more detail: https://www.eevblog.com/forum/testgear/rigol-ds1054z-freeze-up-bug/

(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:
"Just hard work is not enough - it must be applied sensibly."
Dr. Richard W. Hamming
 

Offline kcbrown

  • Frequent Contributor
  • **
  • Posts: 896
  • Country: us
Re: Rigol DS1000Z series buglist continued (from: FW 00.04.04.03.02)
« Reply #16 on: April 12, 2017, 03:58:14 pm »
Did you try a plain power cycle before doing a soft button reset?
Yepp, but most times it wouldn't work. I have to do a full reset, with the soft button. Maybe 8 of 10 times.

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

What are the versions of the various things (CPLD, firmware, board, boot) on your scope?   Note that to get that detailed information, you need to first quickly hit, in the trigger area, MENU MENU FORCE MENU, and then you can go to Utility -> System -> System Info to get the details.
 

Online 2N3055

  • Super Contributor
  • ***
  • Posts: 7561
  • Country: hr
Re: Rigol DS1000Z series buglist continued (from: FW 00.04.04.03.02)
« Reply #17 on: April 12, 2017, 04:07:53 pm »
9) If the following settings are used:

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

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



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.

"Just hard work is not enough - it must be applied sensibly."
Dr. Richard W. Hamming
 

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #18 on: April 12, 2017, 06:23:09 pm »
Thanks for creating the new thread, frozenfrogz. Following.
TEA is the way. | TEA Time channel
 

Offline metrologist

  • Super Contributor
  • ***
  • Posts: 2300
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #19 on: April 12, 2017, 07:20:52 pm »
Mee two. I was wondering if you would use an ordered list for the bug list? It's just marginally easier to parse, but a heck of a lot harder to maintain and edit.
 
The following users thanked this post: garnix

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #20 on: April 12, 2017, 08:12:09 pm »
I was wondering if you would use an ordered list for the bug list? It's just marginally easier to parse, but a heck of a lot harder to maintain and edit.

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

@Fennec:

Please provide your long system info, thanks :)

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

Regards,
Frederik
« Last Edit: April 12, 2017, 08:17:48 pm by frozenfrogz »
He’s like a trained ape. Without the training.
 

Offline Fennec

  • Regular Contributor
  • *
  • Posts: 135
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #21 on: April 12, 2017, 08:41:48 pm »
Please provide your long system info, thanks :)

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



« Last Edit: April 12, 2017, 08:43:19 pm by Fennec »
 

Offline ankerwolf

  • Regular Contributor
  • *
  • Posts: 58
  • Country: at
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #22 on: April 12, 2017, 08:42:06 pm »
Hello,
I made update now on my DS1054Z (with Options now DS1104Z):
SW: 00.04.04.03.02 = 00.04.04.SP3
Board: 0.1.1
Boot: 0.0.1.3
FW: 0.2.3.11
CPLD: 1.1

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

LG Wolf
« Last Edit: April 12, 2017, 08:51:19 pm by ankerwolf »
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #23 on: April 12, 2017, 08:48:07 pm »
I post nothing. Since my last RESET my scope is complete ded. It boots up with this screen.

Damn.

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

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

Good luck!
He’s like a trained ape. Without the training.
 

Offline Fennec

  • Regular Contributor
  • *
  • Posts: 135
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #24 on: April 12, 2017, 09:04:35 pm »
Telnet still work. I check it tomorrow.
All knobs around the screen are ded. So Start or Exit wouldn't work. The screenshot takes a li'll less than 30 MIN. !

Never never again I buy those cheap crap from Rigol !

hf
"Pluses"

Thx for the PDF btw.


« Last Edit: April 12, 2017, 09:06:33 pm by Fennec »
 

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #25 on: April 13, 2017, 04:17:58 am »
Never never again I buy those cheap crap from Rigol !

hf
"Pluses"

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

Maybe if I sell some more of my stuff I can get a Keysight. But for now the Rigol does what I need it to. Hope you get yours running again.
« Last Edit: April 13, 2017, 04:19:29 am by bitseeker »
TEA is the way. | TEA Time channel
 

Offline ebastler

  • Super Contributor
  • ***
  • Posts: 7396
  • Country: de
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #26 on: April 13, 2017, 05:50:04 am »
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?
 

Offline alsetalokin4017

  • Super Contributor
  • ***
  • Posts: 2055
  • Country: us
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #27 on: April 13, 2017, 06:10:53 am »
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.
Quote

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.
The easiest person to fool is yourself. -- Richard Feynman
 
The following users thanked this post: ebastler

Offline Fennec

  • Regular Contributor
  • *
  • Posts: 135
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #28 on: April 13, 2017, 12:42:03 pm »
Easy way.
I made a new thumb-drive with the firmware, pluged it in and start the scope. And viola, the screen doesn't show the calibration failure screen anymore and want do a firmware update. NOW the buttons working. I have no idea what happens yesterday.

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

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

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

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

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

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

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

*Exsample Fluke. I send in a 30 years old Fluke 8840A for calibration. One Knob wouldn't work sometimes, not a real deal. It comes back with a complete new Front, new Knobs and a Letter "Thank you for using our Service". So what should I say ?!
« Last Edit: April 13, 2017, 01:44:48 pm by Fennec »
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #29 on: April 13, 2017, 12:47:56 pm »
On the positive side: I am glad you could revive your scope via reinstalling the firmware again.
He’s like a trained ape. Without the training.
 

Offline Fennec

  • Regular Contributor
  • *
  • Posts: 135
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #30 on: April 13, 2017, 01:08:07 pm »
On the positive side: I am glad you could revive your scope via reinstalling the firmware again.

Yepp, hope the new owner is happy with the scope. I don't like use it anymore.
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #31 on: April 13, 2017, 01:18:17 pm »
I totally understand your frustration. Could you please post the board/boot/fw version of the scope so I can put it in the buglist? Might be a good thing for others to not crash into that same wall as you did.

Thank you :)

FYI:
Just had a talk with someone at Rigol EU here in Germany and on Tuesday 18th the technician in charge of handling bug reports is back in office. I am going to call to talk about the buglist and some other things. Don’t know what will happen, but you never know :)
Will keep you posted.
« Last Edit: April 13, 2017, 01:26:40 pm by frozenfrogz »
He’s like a trained ape. Without the training.
 

Offline Fennec

  • Regular Contributor
  • *
  • Posts: 135
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #32 on: April 13, 2017, 01:57:04 pm »
There's /was a RIGOL contributor here in the forum.
« Last Edit: April 13, 2017, 02:02:29 pm by Fennec »
 
The following users thanked this post: frozenfrogz

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #33 on: April 13, 2017, 03:38:20 pm »
Easy way.
I made a new thumb-drive with the firmware, pluged it in and start the scope. And viola, the screen doesn't show the calibration failure screen anymore and want do a firmware update. NOW the buttons working. I have no idea what happens yesterday.

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

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

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

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

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

« Last Edit: April 13, 2017, 04:43:29 pm by Fungus »
 

Offline Fennec

  • Regular Contributor
  • *
  • Posts: 135
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #34 on: April 13, 2017, 04:22:52 pm »
Luckily the 'scope has a recovery mode, all you had to do was insert a thumb-drive and it fixed itself. No need for all the anti-Rigol ranting, it can happen to any device with Flash memory.

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

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

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

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

Exsample again. Uni-T. I had a damaged Uni-T. I have sent it back to CHINA. Shipping was more than $US150. The device itself costs about $US90. I've got a new Device + my money back. Is that service or what ?
So don't say "i have to pay for service"
 

Offline kcbrown

  • Frequent Contributor
  • **
  • Posts: 896
  • Country: us
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #35 on: April 13, 2017, 04:25:46 pm »
Luckily the 'scope has a recovery mode, all you had to do was insert a thumb-drive and it fixed itself. No need for all the anti-Rigol ranting, it can happen to any device with Flash memory.

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

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

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


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

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

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

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

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

There ain't no such thing as a free lunch.
 

Offline Lightages

  • Supporter
  • ****
  • Posts: 4316
  • Country: ca
  • Canadian po
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #36 on: April 13, 2017, 04:31:41 pm »
Why are you guys polluting this thread which has a specific subject? I know that this is normal for the internet, but please stop trashing the thread with garbage.
 
The following users thanked this post: Fennec

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #37 on: April 13, 2017, 04:42:11 pm »
Why are you guys polluting this thread which has a specific subject? I know that this is normal for the internet, but please stop trashing the thread with garbage.

My messages removed.
 

Offline ankerwolf

  • Regular Contributor
  • *
  • Posts: 58
  • Country: at
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #38 on: April 13, 2017, 09:59:04 pm »
Hy Fennec,
what is the problem you have?

Why do you not read my post after your post?

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

Why all these violent words?

LG Wolf
« Last Edit: April 13, 2017, 10:09:21 pm by ankerwolf »
 

Offline ankerwolf

  • Regular Contributor
  • *
  • Posts: 58
  • Country: at
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #39 on: April 13, 2017, 10:48:34 pm »
Hello Fennec,
What's LG ?
My native language is german. Therfore my valediction is also in german: LG means "Liebe Grüße". Or if you want: Kind regards
« Last Edit: April 13, 2017, 10:50:51 pm by ankerwolf »
 

Offline Fennec

  • Regular Contributor
  • *
  • Posts: 135
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #40 on: April 13, 2017, 10:49:19 pm »
Why do you not read my post after your post?

Why you didn't read mine ?

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

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

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

what is the problem you have?

What's LG ?
 

Offline Fennec

  • Regular Contributor
  • *
  • Posts: 135
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #41 on: April 13, 2017, 10:50:42 pm »
Hello Fennec,
What's LG ?
My native language is german. Therfore my valediction ist also in german: LG means "Liebe Grüße". Or if you want: Kind regards

Thx

LG
 

Offline rsjsouza

  • Super Contributor
  • ***
  • Posts: 6117
  • Country: us
  • Eternally curious
    • Vbe - vídeo blog eletrônico
Re: Rigol DS1000Z series buglist continued (from: FW 00.04.04.03.02)
« Reply #42 on: April 13, 2017, 10:59:45 pm »
PNG screenshot with thumb-drive and printer button takes 2 1/2 MINUTES !
One detail: at a certain point in the firmware merry-go-round, the DS4000 series had the same issue. I found out that FAT32 pendrives were terribly slow while FAT16 was very fast. Perhaps you could try this with your DS1000Z?
Vbe - vídeo blog eletrônico http://videos.vbeletronico.com

Oh, the "whys" of the datasheets... The information is there not to be an axiomatic truth, but instead each speck of data must be slowly inhaled while carefully performing a deep search inside oneself to find the true metaphysical sense...
 
The following users thanked this post: bitseeker

Offline Fennec

  • Regular Contributor
  • *
  • Posts: 135
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #43 on: April 13, 2017, 11:34:40 pm »
Yepp, thats it. 3-4s only.
The downside is, FAT16 can handle 4GB only. So you have to use an old "pendrive" nice name btw. or you lost the rest of the partition. If the RIGOL can handle more than one partitions with FAT16 I didn't checked.
Maybe I find in da junk box an old small thumb-drive. All I have is much larger than 64GB  :(

But thx.

The 100 is cracked  :blah:  :blah:
« Last Edit: April 13, 2017, 11:42:42 pm by Fennec »
 

Offline ankerwolf

  • Regular Contributor
  • *
  • Posts: 58
  • Country: at
Re: Rigol DS1000Z series buglist continued (from: FW 00.04.04.03.02)
« Reply #44 on: April 13, 2017, 11:45:57 pm »
Hello,
PNG screenshot with thumb-drive and printer button takes 2 1/2 MINUTES !
One detail: ... I found out that FAT32 pendrives were terribly slow while FAT16 was very fast. Perhaps you could try this with your DS1000Z?

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

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

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

LG Wolf
« Last Edit: April 13, 2017, 11:52:25 pm by ankerwolf »
 

Offline Fennec

  • Regular Contributor
  • *
  • Posts: 135
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #45 on: April 13, 2017, 11:59:54 pm »
Which OS do you use ? Windows ? So try "hp_usb_disk_storage_format_tool" It works fine. Sometimes it can refresh older or damaged pendrives. /attached  (Change txt to exe.) Ya, it's clean.
On Linux it is easy formatt to FAT16. On Windows I am an idiot.

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

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

« Last Edit: April 14, 2017, 12:16:03 am by Fennec »
 

Offline ProBang2

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

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

There is (well hidden) on page 16-2 under point 8. (3) in the DS 1054Z Manual 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...   :-//
 
The following users thanked this post: ebastler

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #47 on: April 14, 2017, 10:12:46 am »
"The USB stick must be FAT32 format. If the device is not recognized, try reformatting or
another USB memory stick. We also recommend minimizing the number of folders, files,
and programs on the stick. Drives less than 4GB in total volume are also recommended."


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

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

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

Was it the exact same pendrive formatted both ways?

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

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

FAT16
FAT32 4Gb partition
FAT32 8Gb partition

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

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

(*) As anybody who's ever tried to make a bootable pendrive to install Windows can tell you.
« Last Edit: April 14, 2017, 10:37:55 am by Fungus »
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #48 on: April 14, 2017, 10:24:18 am »
If it can handle FAT32 then I don't see why the drive size would make any difference at all.  :-//

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

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


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

However, there is another issue: The timestamp is always 1st of November 2014
There is no difference, if connected to LAN via DHCP. But AFAIK the DS1000Z does not have an RTC.
« Last Edit: April 14, 2017, 10:37:49 am by frozenfrogz »
He’s like a trained ape. Without the training.
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #49 on: April 14, 2017, 10:39:40 am »
However, there is another issue: The timestamp is always 1st of November 2014
There is no difference, if connected to LAN via DHCP. But AFAIK the DS1000Z does not have an RTC.

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

1st of November 2014 is probably the design meeting when the DS1054Z was 'born' or something like that.
 

Offline rsjsouza

  • Super Contributor
  • ***
  • Posts: 6117
  • Country: us
  • Eternally curious
    • Vbe - vídeo blog eletrônico
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #50 on: April 14, 2017, 04:29:50 pm »
PNG screenshot with thumb-drive and printer button takes 2 1/2 MINUTES !
One detail: at a certain point in the firmware merry-go-round, the DS4000 series had the same issue. I found out that FAT32 pendrives were terribly slow while FAT16 was very fast. Perhaps you could try this with your DS1000Z?

Was it the exact same pendrive formatted both ways?
I don't own a DS1000Z and that was definitely an issue on the DS4000 at a certain point that manifested itself similarly to what was reported by Fennec - all bases covered (different brands, sizes and formats).
Vbe - vídeo blog eletrônico http://videos.vbeletronico.com

Oh, the "whys" of the datasheets... The information is there not to be an axiomatic truth, but instead each speck of data must be slowly inhaled while carefully performing a deep search inside oneself to find the true metaphysical sense...
 

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #51 on: April 14, 2017, 05:06:18 pm »
If it can handle FAT32 then I don't see why the drive size would make any difference at all.  :-//

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

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


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

There are definitely issues reading/writing some USB stick/thumb/pen drives. There was a bit of discussion about it back in 2015 having to do with media, allocation table, and cluster sizes: https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg782838/#msg782838
TEA is the way. | TEA Time channel
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #52 on: April 14, 2017, 05:14:21 pm »
I am aware of that and maybe I expressed poorly what I meant. This was more in regard to "32Gb should not be a problem if FAT32 works".

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

For know, the only work around seems to be trying out different brands and stick with one that gets the job done.
He’s like a trained ape. Without the training.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9974
  • Country: us
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #53 on: April 15, 2017, 02:17:27 pm »
I have been using an Imation 2 GB Clip device and I can save a .png image in about 5 seconds.  I'm pretty sure this is FAT16.
It also takes about 5 seconds on a Cruzer Glide 256 GB which is FAT32.

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

I have a much smaller stick that I use for software upgrades.  No reason, really, it's just that I don't want to get things confused so I have this stick dedicated to the purpose of upgrading.
 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7551
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #54 on: April 15, 2017, 02:26:35 pm »
From Rigol manual :


Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #55 on: April 15, 2017, 04:52:36 pm »
Yeah, the Rigol manual (which version is that from, BravoV?) says maximum 8GB formatted as FAT32. However, there have been problems reported that conflict with the manual. Rstofer just posted success with 2GB FAT16 and 256GB FAT32. Others have had failures with 2GB FAT32.

I upgrade my scope with a 512MB FAT16, which defaults to either 8KB or 16KB clusters 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.
« Last Edit: April 15, 2017, 05:02:38 pm by bitseeker »
TEA is the way. | TEA Time channel
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #56 on: April 15, 2017, 05:09:30 pm »
Testing out different allocation unit sizes might be worth trying.
BRB
He’s like a trained ape. Without the training.
 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7551
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #57 on: April 15, 2017, 05:10:24 pm »
Yeah, the Rigol manual (which version is that from, BravoV?) says maximum 8GB formatted as FAT32. However, there have been problems reported that conflict with the manual. Rstofer just posted success with 2GB FAT16 and 256GB FAT32. Others have had failures with 2GB FAT32.

I upgrade my scope with a 512MB FAT16, which defaults to either 8KB or 16KB clusters 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 ?  :-//

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #58 on: April 15, 2017, 05:54:08 pm »
I took two USB sticks, one with 32Gb and one with 2Gb and tried to get my Rigol fail on write due to unsupported allocation size. Everything passed.

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

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

But as I reported before, there have been no issues with USB drives on my scope (apart from the obvious: NTFS / ExFAT / OS X Extended formatted drives)
I would need an USB drive that is reportedly not working to further investigate...
« Last Edit: April 15, 2017, 05:57:00 pm by frozenfrogz »
He’s like a trained ape. Without the training.
 

Offline smithnerd

  • Regular Contributor
  • *
  • Posts: 120
  • Country: gb
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #59 on: April 15, 2017, 05:56:28 pm »
Yeah, the Rigol manual (which version is that from, BravoV?) says maximum 8GB formatted as FAT32. However, there have been problems reported that conflict with the manual. Rstofer just posted success with 2GB FAT16 and 256GB FAT32. Others have had failures with 2GB FAT32.

I upgrade my scope with a 512MB FAT16, which defaults to either 8KB or 16KB clusters 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


« Last Edit: April 15, 2017, 06:33:02 pm by smithnerd »
 

Offline ankerwolf

  • Regular Contributor
  • *
  • Posts: 58
  • Country: at
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #60 on: April 18, 2017, 04:57:01 pm »
Hello,
Bug #5 I can say:
Pass: Board Version: 0.1.1, Boot Version: 0.0.1.3, Firmware Version: 0.2.3.11, CPLD Version: 1.1

LG Wolf
 
The following users thanked this post: frozenfrogz

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #61 on: April 18, 2017, 05:03:56 pm »
Thanks ankerwolf :)
Sooo.. Maybe we can pin this on boot version <0.1.3?
(still needs a bigger dataset obviously)
He’s like a trained ape. Without the training.
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #62 on: April 19, 2017, 02:05:17 pm »
Thanks ankerwolf :)
Sooo.. Maybe we can pin this on boot version <0.1.3?
(still needs a bigger dataset obviously)

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

Edit: Here's my full info...


(Screenshot took about 8 seconds to complete)

« Last Edit: April 19, 2017, 07:06:28 pm by Fungus »
 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7551
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #63 on: April 19, 2017, 04:01:17 pm »
Big jump, just upgraded DS1104Z-S (with FG), from v04.00.00.00 straight to v04.04.03.02, so far no problem, at least at the upgrade process it self.

Just fyi, used an old 8GB USB flash drive with FAT32 and 4096 bytes allocation unit, freshly reformatted and just copy the single .GEL file at the root directory, no other files in it.
 
The following users thanked this post: frozenfrogz

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #64 on: April 19, 2017, 04:15:11 pm »
Thanks BravoV,

did you run self-calibration without problems?
That is where issues seem to be sticking their head out.
He’s like a trained ape. Without the training.
 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7551
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #65 on: April 19, 2017, 04:28:07 pm »
Thanks BravoV,

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

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

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

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

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

- Then power off the unit.

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

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

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

Thats all.

EDIT :

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

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

        4,096 bytes in each allocation unit.
    1,887,845 total allocation units on disk.
    1,886,686 allocation units available on disk.
« Last Edit: April 19, 2017, 04:32:51 pm by BravoV »
 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7551
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #66 on: April 19, 2017, 04:51:07 pm »
I did capture the screen using the print feature too, apart from taking the photo using camera.

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

Just watch this animation switching between these two versions. This is untouched PNG file saved using the print, size untouched and converted straight into animated GIF.
« Last Edit: April 19, 2017, 05:57:54 pm by BravoV »
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #67 on: April 19, 2017, 05:17:08 pm »
Also: You got a hardware upgrade via USB implant as it seems xD
He’s like a trained ape. Without the training.
 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7551
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #68 on: April 19, 2017, 05:19:36 pm »
Also: You got a hardware upgrade via USB implant as it seems xD

Yep , what a sharp eyes you got there.  :-+

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #69 on: April 19, 2017, 06:02:14 pm »
I added the direct link to last known firmware release that also contained a board / boot version update file to the opening post. (v.00.04.00.00.00)

Please: If any of you does the boot version update, or did the update already, can you leave some info on what version is included here? I would like to add this info as well :)
He’s like a trained ape. Without the training.
 

Offline ebastler

  • Super Contributor
  • ***
  • Posts: 7396
  • Country: de
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #70 on: April 19, 2017, 06:10:34 pm »
Also: You got a hardware upgrade via USB implant as it seems xD
Yep , what a sharp eyes you got there.  :-+

I noticed that the displayed board version has changed; assume this is what you are referring to?
But what's up with the "USB implant"? I must have missed something there... ???
 

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #71 on: April 19, 2017, 06:18:05 pm »
But what's up with the "USB implant"? I must have missed something there... ???

In other words, it's as if a hardware upgrade was physically implanted via the USB interface. That'd be a nice feature, indeed.
TEA is the way. | TEA Time channel
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #72 on: April 19, 2017, 06:20:09 pm »
I noticed that the displayed board version has changed; assume this is what you are referring to?
But what's up with the "USB implant"? I must have missed something there... ???

USB implant was actually a joke ;)

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

Edit: What bitseeker said
In other words, it's as if a hardware upgrade was physically implanted via the USB interface. That'd be a nice feature, indeed.
« Last Edit: April 19, 2017, 06:21:47 pm by frozenfrogz »
He’s like a trained ape. Without the training.
 
The following users thanked this post: ebastler

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7551
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #73 on: April 19, 2017, 06:23:49 pm »
LOL  :-DD, although I haven't thoroughly test all, I guess that big jump 0.1.1 to 4.1.1 probably has something to do with the FG board, at least for service engineer. Since it doesn't show additional field for the FG's firmware version at the screen. Its a DS1104Z-S , not a hacked DS1054Z which doesn't have it.
« Last Edit: April 19, 2017, 06:30:10 pm by BravoV »
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #74 on: April 19, 2017, 07:28:42 pm »
Thanks ankerwolf :)
Sooo.. Maybe we can pin this on boot version <0.1.3?
(still needs a bigger dataset obviously)
Nope. I've got boot version 0.0.1.1 and it doesn't happen here.

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

Hopefully we can resolve this :)
He’s like a trained ape. Without the training.
 

Offline rbino

  • Newbie
  • Posts: 4
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #75 on: April 21, 2017, 08:31:30 am »
Reporting in, since yesterday I've upgraded to 00.04.04.03.02 (starting from the version ending with SP1, I can't remember the precise version).

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

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

After the software upgrade, the additional buttons on the auto-calibration showed up, and the auto-calibration failed.
When I've rebooted, the buttons were gone, but the calibration failed again.
Both the times the only symptom was the calibration failing, the scope didn't lock-up and I could continue to use it.
I will now try another self-calibration, if it fails again I will try cleaning the memory as BravoV did.
 

Offline rbino

  • Newbie
  • Posts: 4
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #76 on: April 21, 2017, 09:01:57 am »
Ok, I've just finished the third self-calibration since the software upgrade and this time it didn't fail. :-+
 
The following users thanked this post: frozenfrogz

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #77 on: April 21, 2017, 09:15:55 am »
Thanks rbino for reporting in.
So basically the freeze bug can not be pinned down to any given device stats – strange.

Nice to hear that you could finally initialize/calibrate your scope.
Did it just work on the third try, or did you do some memory clean or alternative reset?
He’s like a trained ape. Without the training.
 

Offline szpila

  • Newbie
  • Posts: 8
  • Country: pl
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #78 on: April 21, 2017, 09:36:15 am »
Yesterday, I've updated my scope to latest firmware. After that calibration went smooth without any errors. I've noticed two more buttons on calibration screen.

Wys?ane z mojego 2014811 przy u?yciu Tapatalka

 
The following users thanked this post: frozenfrogz

Offline Sredni

  • Frequent Contributor
  • **
  • Posts: 746
  • Country: aq
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #79 on: April 21, 2017, 09:47:38 am »
Big jump, just upgraded DS1104Z-S (with FG), from v04.00.00.00 straight to v04.04.03.02,

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

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

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

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

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

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

« Last Edit: April 21, 2017, 11:52:36 am by Sredni »
All instruments lie. Usually on the bench.
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #80 on: April 21, 2017, 09:50:01 am »
Seems to be some hick-up weirdness issued on the page before.

Edit: I added the update procedure as recommended by BravoV to the OP. Anything else I missed to include?
« Last Edit: April 21, 2017, 10:19:24 am by frozenfrogz »
He’s like a trained ape. Without the training.
 

Offline rbino

  • Newbie
  • Posts: 4
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #81 on: April 21, 2017, 11:42:13 am »
Did it just work on the third try, or did you do some memory clean or alternative reset?

I just retried the calibration and it went well, without other special procedures.
Little note: the additional soft buttons were present when it succeeded (the third try). Now they're gone.
 
The following users thanked this post: frozenfrogz

Offline ProBang2

  • Frequent Contributor
  • **
  • Posts: 303
  • Country: de
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #82 on: April 21, 2017, 02:01:25 pm »
[...] Little note: the additional soft buttons were present when it succeeded (the third try). Now they're gone.

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

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

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

Offline Gary.M

  • Regular Contributor
  • *
  • Posts: 137
  • Country: nz
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #83 on: April 22, 2017, 06:31:14 am »
Key elements of my scope are:

Board version: 0.1.1
Boot version: 0.0.1.2

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

 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7551
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #84 on: April 22, 2017, 01:55:36 pm »
Big jump, just upgraded DS1104Z-S (with FG), from v04.00.00.00 straight to v04.04.03.02,

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


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

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



Ok, seriously ...

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

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

Again, this is just my guess, but it makes sense though.

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #85 on: April 22, 2017, 06:18:11 pm »
Sounds plausible to me.
TEA is the way. | TEA Time channel
 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7551
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #86 on: April 24, 2017, 12:36:59 pm »
Helped friend upgrade his DS1054Z from 04.03.02.03 to the latest 04.04.03.02, so far no problem in the upgrading process and also the self cal after that. Also all DSER options are still active in this new firmware.

Spotted minor screen's change, not as many as my previous DS1104Z-S as it was a big jump, but this time is just the right panel buttons, watch closely the minor shift at right side at the attached GIF animation.
« Last Edit: April 24, 2017, 12:39:13 pm by BravoV »
 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7551
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #87 on: April 24, 2017, 03:14:37 pm »
How to get in the "expanded mode"?
Fast pressing the hard buttons [Menu] [Menu] [Force] [Menu]
Then pressing the hard button [Utility]

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

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

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

Here are the steps :
  • 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 ...  :-DD


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

« Last Edit: April 24, 2017, 03:34:52 pm by BravoV »
 
The following users thanked this post: bitseeker

Offline ted572

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
  • Radio Communications Equipment/System Design Engr.
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #88 on: April 24, 2017, 07:19:19 pm »
The following procedure can be used to Sanitize Memory in the DS1000Z Series Oscilloscopes. This is similar to the procedure released by Rigol (Titled: Sanitization of memory with the DS1000Z series of oscilloscopes) with some additional details.

Edit Added -> Re-Calibration Requirement: Sanitization of the instrument's memory will of course erase the stored Self-Calibration values.  Therefore it is important to perform Self-Calibration following Sanitization.
« Last Edit: April 29, 2017, 06:15:59 pm by ted572 »
 

Offline Gary.M

  • Regular Contributor
  • *
  • Posts: 137
  • Country: nz
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #89 on: April 26, 2017, 01:48:56 am »
Just did the update. I was a little cautious as my hardware and boot version seemed to be the troubled ones. However all went well. I did the full memory sanitise first.



 

Offline maxiq4

  • Contributor
  • Posts: 12
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #90 on: April 26, 2017, 05:33:12 am »
Im updated, ds1054Z, self cal is ok

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

« Last Edit: April 26, 2017, 05:34:44 am by maxiq4 »
 

Offline metrologist

  • Super Contributor
  • ***
  • Posts: 2300
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #91 on: April 26, 2017, 05:45:27 am »
Im updated, ds1054Z, self cal is ok

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

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

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

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

Offline maxiq4

  • Contributor
  • Posts: 12
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #92 on: April 26, 2017, 05:53:03 am »
thank you  :)
 

Offline video

  • Newbie
  • Posts: 7
  • Country: fr
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #93 on: May 01, 2017, 07:10:20 pm »
Hello,
sorry for my english, it's not my mother langage
It's my first message here, but i read sometimes this topic as i'm an new DS1054Z owner.
Just a remarq:
The second bouton "Output" could be named "WFCal" for "Write File Calibration" and of course the first hidden button (what is named "LFCal") seem to be "Load File Calibration".
But i didn't try to "Load" (if it's really a loading function..)..to much afraid..

Does anybody say if i'm wrong or right ?
 
The following users thanked this post: Gary.M

Offline Roeland_R

  • Regular Contributor
  • *
  • Posts: 62
  • Country: nl
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #94 on: May 01, 2017, 07:32:45 pm »
Hello,

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

 

Offline ebastler

  • Super Contributor
  • ***
  • Posts: 7396
  • Country: de
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #95 on: May 01, 2017, 07:36:59 pm »
The second bouton "Output" could be named "WFCal" for "Write File Calibration" and of course the first hidden button (what is named "LFCal") seem to be "Load File Calibration".
But i didn't try to "Load" (if it's really a loading function..)..to much afraid..

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

I can't figure out, however, what this would be used for. Why would one want to store and recall a calibration, rather that redo a fresh calibration (after some time has passed, or after a firmware upgrade, or...)? Well, I guess those to buttons are only meant for debugging or service purposes anyway. I don't think I will try an "LFCal" any time soon...
 

Offline video

  • Newbie
  • Posts: 7
  • Country: fr
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #96 on: May 01, 2017, 08:24:01 pm »
Yes, as is a hidden button, it's probably for development/debugging, but if it exists, there is a reason  :) even if it seems not logic to load a such file; but loading is quicker (fresh calibration can take an half hour), may be it's usable after some kind of reset or firmware update..i don't know
 

Offline Sredni

  • Frequent Contributor
  • **
  • Posts: 746
  • Country: aq
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #97 on: May 01, 2017, 08:58:49 pm »
I wonder what the calibration data is...
For example:

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


or

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

All instruments lie. Usually on the bench.
 

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #98 on: May 01, 2017, 09:02:55 pm »
I can't figure out, however, what this would be used for. Why would one want to store and recall a calibration, rather that redo a fresh calibration (after some time has passed, or after a firmware upgrade, or...)?

Perhaps to recreate a known state of the machine to reproduce particular results. It could also be useful if running a new self-cal didn't work properly for some reason.
TEA is the way. | TEA Time channel
 

Offline garnix

  • Contributor
  • Posts: 32
  • Country: ch
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #99 on: May 01, 2017, 09:36:06 pm »
That sounds neat - I always see some small offset after calibration. Perhaps with some editing and reloading that file we could tune it to get rid of that offset...
 

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #100 on: May 01, 2017, 10:12:22 pm »
That would be nice. The offset does aggravate the OCD. :-DD
TEA is the way. | TEA Time channel
 
The following users thanked this post: garnix

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7551
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #101 on: May 02, 2017, 07:19:20 am »
I don't think I will try an "LFCal" any time soon...

Definitely not me either.  :scared:

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

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

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #102 on: May 02, 2017, 08:03:34 am »
I can't figure out, however, what this would be used for. Why would one want to store and recall a calibration

Beats me.  :-//

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

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

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

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

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

« Last Edit: May 02, 2017, 08:44:17 am by Fungus »
 

Offline video

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

------------------????????---------------------
{
 {
  0,0x5b,1,1,
  0,0x4f,1,1,
 },etc..
------------------?????????---------------------
------------100M-----------
{
{//CH1
500       ,ATT_X1  ,G_X2    ,1  ,13 ,4154  ,
1000      ,ATT_X1  ,G_X2    ,1  ,13 ,2077  ,
2000      ,ATT_X1  ,G_X2    ,1  ,13 ,1038  ,
5000      ,ATT_X1  ,G_X2    ,1  ,10 ,1038  ,
10000     ,ATT_X1  ,G_X2    ,1  ,7  ,1038  ,
20000     ,ATT_X1  ,G_X2    ,1  ,5  ,1038  ,
50000     ,ATT_X1  ,G_X2    ,1  ,2  ,1038  ,
100000    ,ATT_X1  ,G_X0625 ,1  ,3  ,1362  ,
200000    ,ATT_X1  ,G_X0625 ,1  ,1  ,1362  ,
500000    ,ATT_X50 ,G_X2    ,1  ,7  ,1060  ,
1000000   ,ATT_X50 ,G_X2    ,1  ,5  ,1060  ,
2000000   ,ATT_X50 ,G_X2    ,1  ,3  ,1060  ,
5000000   ,ATT_X50 ,G_X0625 ,1  ,3  ,1390  ,
10000000  ,ATT_X50 ,G_X0625 ,1  ,1  ,1390  ,
},etc..
-------------????-------------
{
{
101.423302,101.811897,102.006195,ATT_X1  ,G_X2    ,10 ,1024  ,
332.540192,333.123077,334.094574,ATT_X1  ,G_X0625 ,10 ,1024  ,
},etc..
-------------??????-------------
------------100M-----------
{
{,32918,32885,32819,32821,32826,32833,32868,35007,37103,32841,32862,32910,35116,37377},
{,32937,32904,32839,32839,32841,32852,32859,34938,37030,32851,32866,32899,35018,37213},
{,32901,32869,32803,32805,32807,32812,32818,34776,36774,32815,32831,32857,34866,36993},
{,32930,32897,32831,32836,32842,32850,32898,34939,37130,32853,32875,32923,35078,37335},
},etc..
 

Offline video

  • Newbie
  • Posts: 7
  • Country: fr
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #104 on: May 02, 2017, 08:47:49 am »
 :-[ Sorry, but the chinese/japanese characters are changed by smiley in my post, i didn't check that by preview, so lock in your own file to see its
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 29931
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #105 on: May 02, 2017, 09:05:15 am »
:-[ Sorry, but the chinese/japanese characters are changed by smiley in my post, i didn't check that by preview, so lock in your own file to see its
Drop it into some document, Word, txt... and attach it in a post of try dropping it within the brackets for Insert Table (below Font Face) when you make a post. Like this:

FILE CONTENTS

Quote this post and you can see the syntax used.
Avid Rabid Hobbyist.
Some stuff seen @ Siglent HQ cannot be shared.
 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7551
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #106 on: May 02, 2017, 10:27:50 am »
Has anybody looked at the file? Is it binary/ASCII? How big is it? If it's binary, have we got a hex dump?

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

Please be reminded, also to others, this is from DS1104Z-S (with func gen), "NOT" a hacked DS1054Z.

Offline ebastler

  • Super Contributor
  • ***
  • Posts: 7396
  • Country: de
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #107 on: May 02, 2017, 10:34:58 am »
Attached is the screencopy of "LFCal".

Do you also get the error message when a USB stick with a previously saved calibration file is present?
 

Offline zbyr

  • Contributor
  • Posts: 23
  • Country: pl
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #108 on: May 02, 2017, 10:55:35 am »
I tried google translate with these chinese characters, and it seems ok.

Attached file with translated headers.
 

Offline video

  • Newbie
  • Posts: 7
  • Country: fr
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #109 on: May 02, 2017, 11:54:27 am »
Thanks for the  chinese-english translation zbyr, and my idea about "LFCal" for load file calibration wasn't good, ebastler was maybe more near to the truth.
I compared the 2 CalData files from the DS1104Z-S and the DS1054Z, the structure are similar, the 2 channels generator is probablely not concerned by this caldata file. PeDre, i can't find the [SCPI command for the "LFCal" function ":CALibrate:LFSTARt", and for the "OUTPUT" function ":CALibrate:OUTPut?"] in the Rigol programming guide: did you find it in an official doc ?
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #110 on: May 14, 2017, 02:48:35 pm »
In case somebody thought that most bugs have been solved, I have an unpleasant surprise:

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

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

 :--

Together with all other (resolved) bugs, it explains why their pc software is so shitty.
It's impossible to write good remote control software when the firmware doesn't work as documented.
« Last Edit: May 14, 2017, 02:51:23 pm by Karel »
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #111 on: May 14, 2017, 04:02:19 pm »
In case somebody thought that most bugs have been solved, I have an unpleasant surprise:

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

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

That's correct behavior.

Read the manual:



 

Offline metrologist

  • Super Contributor
  • ***
  • Posts: 2300
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #112 on: May 14, 2017, 04:14:24 pm »
maybe because that is the way they've written it, but I would expect the FEND? keyword. that stuff happens to the best anyway...
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #113 on: May 14, 2017, 04:34:28 pm »
I have read the manual and it's not correct behaviour. Thank you very much.

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


The maximum number of frames recorded is 5.

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

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

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

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

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

Offline pascal_sweden

  • Super Contributor
  • ***
  • Posts: 1541
  • Country: no
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #114 on: May 14, 2017, 05:04:26 pm »
Who is actually communicating all these bugs to Rigol? Or is there a Rigol application engineer on this forum?
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #115 on: May 14, 2017, 05:20:55 pm »
Who is actually communicating all these bugs to Rigol? Or is there a Rigol application engineer on this forum?

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

To my knowledge, no Rigol representative visits this forum.
If they do, they do it quietly.
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #116 on: May 14, 2017, 05:47:09 pm »
I have read the manual and it's not correct behaviour. Thank you very much.

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


The maximum number of frames recorded is 5.

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

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

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

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

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

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

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

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

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

PS: You can play back a subset of frames using the ":FUNCtion:WREPlay:FCURrent" function, or just start playing and monitor the current position.
« Last Edit: May 14, 2017, 05:51:04 pm by Fungus »
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #117 on: May 14, 2017, 06:16:17 pm »
I'm not talking about :FUNCtion:WRECord:FEND.

I'm talking about :FUNCtion:WREPlay:FMAX

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

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

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

What's so difficult  to understand about this?
 

Offline kcbrown

  • Frequent Contributor
  • **
  • Posts: 896
  • Country: us
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #118 on: May 14, 2017, 08:42:27 pm »
I'm not talking about :FUNCtion:WRECord:FEND.

I'm talking about :FUNCtion:WREPlay:FMAX

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

The documentation clearly claims otherwise.


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

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

What's so difficult  to understand about this?

If the documentation says that "function A reads value X, and function B sets value X", then how is it a bug when your use of B results in A reporting the value that you handed to B?
« Last Edit: May 14, 2017, 08:44:37 pm by kcbrown »
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #119 on: May 14, 2017, 10:00:16 pm »
I'm not talking about :FUNCtion:WRECord:FEND.

I'm talking about :FUNCtion:WREPlay:FMAX

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

The documentation clearly claims otherwise.

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

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

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

What's so difficult  to understand about this?

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

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

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

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

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

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

"Syntax :FUNCtion:WREPlay:FMAX?

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

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

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

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

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

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

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

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

 

Offline kcbrown

  • Frequent Contributor
  • **
  • Posts: 896
  • Country: us
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #120 on: May 14, 2017, 11:32:47 pm »
:FUNCtion:WREPlay:FEND != :FUNCtion:WRECord:FEND  !!

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




Sent from my iPhone using Tapatalk
 

Offline technogeeky

  • Frequent Contributor
  • **
  • Posts: 555
  • Country: us
  • Older New "New Player" Player Playa'
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #121 on: May 15, 2017, 02:50:59 am »
In case Rigol does ever visit: Rigol would, at this point, have nothing to lose and everything to gain by releasing/open sourcing the firmware.





  • 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
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #122 on: May 15, 2017, 03:56:14 am »
:FUNCtion:WREPlay:FEND != :FUNCtion:WRECord:FEND  !!
Ah.  Yes, you're right, those should be different.   My apologies.  So it appears the internals are confusing the two, which is a bug.

Oh, duh! Yes.  :palm:

 

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #123 on: May 15, 2017, 04:30:17 am »
I had to read through that a few times, as well, since the commands are very similar looking. Perhaps the bug arose from a similar confusion during coding of the functionality. Nice bug find, Karel.

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

Seriously, though, it would be nice to be able to fix things ourselves. But, alas, we're the minority. Hence, I'd be skeptical of it happening, but very pleased if it did.
TEA is the way. | TEA Time channel
 

Offline boggis the cat

  • Regular Contributor
  • *
  • Posts: 219
  • Country: nz
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #124 on: May 15, 2017, 05:41:40 am »
In case Rigol does ever visit: Rigol would, at this point, have nothing to lose and everything to gain by releasing/open sourcing the firmware.

...

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

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

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

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

(Another argument may be that more could be squeezed from older products, thus disrupting the 'upgrade cycle'.  I don't know how big a factor this is.)
 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7551
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #125 on: May 15, 2017, 06:50:31 am »
Can anyone else here come up with business arguments that would make this move a clear win? Is there something I'm missing, where they will be throwing away something that Rigol considers critical?

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

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

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

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

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

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


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

Also put some protection mechanism that is not easily to tamper, in order to detect if modded firmware was loaded even once, hence its easy to reject warranty claim. Not sure if this will increase the cost.  :-//
« Last Edit: May 15, 2017, 10:11:55 am by BravoV »
 
The following users thanked this post: JPortici

Offline boggis the cat

  • Regular Contributor
  • *
  • Posts: 219
  • Country: nz
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #126 on: May 15, 2017, 07:47:01 am »
You could make a software check / dump part of the support / RMA process.  'Put this on USB drive, insert in product, record information on display' type deal.  If the check fails to work, then a dump of critical software could be done to determine if the problem was due to 'official' software or not.  (Posting a process to 'un-brick' the 'scope for those who do manage to do so shouldn't be too hard.  It shouldn't be possible to physically damage a 'scope via firmware -- so far as I am aware.)

If you choose to modify something then you lose warranty, unless you stick to 'sanctioned' modifications such as updates from the manufacturer.  The manufacturer could choose to use better code that is released, or just stay with a buggy 'official' version and let customers decide whether they want to tinker or not.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #127 on: May 15, 2017, 07:47:06 am »
Thank you for confirming my findings related to this "new" bug. I thought it was me getting crazy...

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

Fortunately it's not an important bug and it's possible to workaround it.
Despite that, it should be added to the buglist...
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #128 on: May 15, 2017, 07:55:34 am »
All of the features of the Keysight could easily be added to the 1054z.

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

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

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

 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7551
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #129 on: May 15, 2017, 09:50:52 am »
You could make a software check / dump part of the support / RMA process.  'Put this on USB drive, insert in product, record information on display' type deal.  If the check fails to work, then a dump of critical software could be done to determine if the problem was due to 'official' software or not. 

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

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

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


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

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


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

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

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

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



Rather than sink deep in this fuss and mess, why not focus and concentrate on designing and making another new generation low cost scope, sort of DS1054Z successor, as DS1054Z is considered quite old now, and the new beast is specifically targeted to hit very hard to those new competing products.  >:D
« Last Edit: May 15, 2017, 10:13:23 am by BravoV »
 

Offline boggis the cat

  • Regular Contributor
  • *
  • Posts: 219
  • Country: nz
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #130 on: May 15, 2017, 10:11:05 am »
"What if" .. the modded firmware is so bad that put the scope into infinite loop once booted ?

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

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

Are there possible down-sides?  Sure.  Are they significant?  I don't think so, but Rigol would decide that, not me.
 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7551
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #131 on: May 15, 2017, 10:17:56 am »
The 'un-brick' option.

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

Do you even own or even ever used this DS1000Z scope ?  :-DD
« Last Edit: May 15, 2017, 10:23:40 am by BravoV »
 

Offline boggis the cat

  • Regular Contributor
  • *
  • Posts: 219
  • Country: nz
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #132 on: May 15, 2017, 10:20:35 am »
It's my impression that one of the reasons for the "shitty" firmware is that there's not enough space (memory/cpu-power) to implement all the features in the correct way.
They are strugling with it. Probably, the only way to improve the firmware is to throw out half of the features...
You can tell the problem is resources -- processor power is definitely lacking, tight memory possibly.

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

Perfectly sensible approach, but it does mean that you can't just compare feature lists then assert that this inexpensive 'scope can match another.  (Same issue as assuming that every 6000 count DMM with the same feature list is equivalent.  They really aren't.)
 

Offline boggis the cat

  • Regular Contributor
  • *
  • Posts: 219
  • Country: nz
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #133 on: May 15, 2017, 10:29:10 am »
The 'un-brick' option.

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

Perhaps you are assuming that by "un-brick" I mean a simple process.  I mean 'whatever it takes' -- what they would do in the factory.  You could provide a series of steps from firmware updates right through to flashing the chips via the headers -- or even replacing them.  Tell some YouTube techies how it works and let them produce your 'documentation' for the processes.
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #134 on: May 15, 2017, 11:19:45 am »
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
He’s like a trained ape. Without the training.
 

Offline Karel

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

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

Then I enabled the record function:

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

:FUNC:WREC:FEND 20

:FUNC:WREC:OPER RUN

:FUNC:WREP:FST?
1

:FUNC:WREP:FEND?
20

:FUNC:WREP:FMAX?
20

:FUNC:WREP:FEND 10

:FUNC:WREP:FMAX?
10

:FUNC:WREP:FEND 20

:FUNC:WREP:FINT?
5.000000e-01

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

:FUNC:WREP:FEND 10

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

:FUNC:WREP:FMAX?
10

:FUNC:WREP:FEND 20

:FUNC:WREP:FMAX?
20

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

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

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

Syntax
 :FUNCtion:WREPlay:FMAX?
Description
 Query the maximum number of frames can be played, namely the maximum number of
frames recorded.
 
The following users thanked this post: frozenfrogz

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7551
  • Country: 00
  • +++ ATH1
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #136 on: May 15, 2017, 12:19:22 pm »
@Frederik,

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

Its obvious this DS1000Z does and still create lots of troubles on competing brands.

Offline HoracioDos

  • Frequent Contributor
  • **
  • Posts: 344
  • Country: ar
  • Just an IT monkey with a DSO
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #137 on: May 15, 2017, 12:56:48 pm »
Hello
I recently tried to connect DSRemote via USB (USBTMC) in linux and found this bug. It seems it's NOT a Linux bug. Can it be included in the list?
(Rigol Firmware Version 00.04.04.SP3)

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

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

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

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

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

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

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

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

More details here:
https://github.com/Teuniz/DSRemote/issues/12#issuecomment-283940080
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #138 on: May 15, 2017, 01:31:42 pm »
Hello
I recently tried to connect DSRemote via USB (USBTMC) in linux and found this bug. It seems it's NOT a Linux bug. Can it be included in the list?

Hello Horacio,

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

Regards,
Frederik
He’s like a trained ape. Without the training.
 

Offline HoracioDos

  • Frequent Contributor
  • **
  • Posts: 344
  • Country: ar
  • Just an IT monkey with a DSO
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #139 on: May 15, 2017, 01:43:14 pm »
it is already listed as Bug #8, however I could add more information on this.
Hi frozenfrogz!
Ohh I'm sorry for the inconvenience. I checked the list before posting but obviously I've got it wrong. Thanks!!!
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #140 on: May 15, 2017, 01:49:38 pm »
No problem :)

The implications of this are not very self-explanatory.

Edit: Additional Info on USB behavior and new bug regarding telnet query has been appended to the OP.
« Last Edit: May 15, 2017, 02:15:35 pm by frozenfrogz »
He’s like a trained ape. Without the training.
 

Offline technogeeky

  • Frequent Contributor
  • **
  • Posts: 555
  • Country: us
  • Older New "New Player" Player Playa'
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #141 on: May 16, 2017, 03:26:25 am »
All of the features of the Keysight could easily be added to the 1054z.

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

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

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

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

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

 

Offline sandor626

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

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

Thanks Rigol !!


 
 
The following users thanked this post: frozenfrogz

Offline Nat

  • Newbie
  • Posts: 2
  • Country: kr
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #143 on: June 14, 2017, 08:01:13 am »
So, to experienced folks out there, should I update my DS1054z (Board Version: 0.1.4, Boot Version: 0.0.1.4, Firmware Version: 0.2.3.11, CPLD Version: 1.1) to the latest firmware, given that the only thing that bother me right now is the display mode Normal that merges with Peaks.

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

Thanks.

(This is my first post!, fantastic forum.).
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #144 on: June 14, 2017, 09:42:31 am »
So, to experienced folks out there, should I update (...) ?

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

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

Regards,
Frederik
He’s like a trained ape. Without the training.
 

Offline Nat

  • Newbie
  • Posts: 2
  • Country: kr
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #145 on: June 14, 2017, 10:27:49 am »
Make sens, this .gel loaded USB stick is burning my fingers anyway :)

Thanks.
 
The following users thanked this post: frozenfrogz

Offline grants225

  • Newbie
  • Posts: 4
  • Country: lt
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #146 on: July 07, 2017, 07:46:06 am »
regarding ""pluses" - did I missed something, but yesterday I updated and see this   :-// :
 

Offline ebastler

  • Super Contributor
  • ***
  • Posts: 7396
  • Country: de
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #147 on: July 07, 2017, 07:53:14 am »
regarding ""pluses" - did I missed something, but yesterday I updated and see this   :-// :

I think the "pulses" in the left-hand menu have always been correct. Please enable pulse measurement and check the label on the actual read-out, at the bottom of the screen.
 
The following users thanked this post: JPortici, Jacon

Offline psysc0rpi0n

  • Frequent Contributor
  • **
  • Posts: 347
  • Country: ar
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #148 on: July 07, 2017, 05:03:03 pm »
I'm not sure if this post is the best place to ask my question. I'm sorry if it's not!

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

Side note to @Fungus:
Thanks for correcting me! I am myself pretty demanding regarding language and gramar matters. But I can only be demanding in my own mother language which is Portuguese. I like to see when people actually cares about keeping their own language sane and don't let themselves deviate from the good spelling, writing and speaking!
« Last Edit: July 07, 2017, 08:01:04 pm by psysc0rpi0n »
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #149 on: July 07, 2017, 07:37:02 pm »
I'm not sure if this post is the best place to ask my question. I'm sorry if it's not!

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

No.

http://theoatmeal.com/comics/misspelling

 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #150 on: July 07, 2017, 09:05:49 pm »
I'm not sure if this post is the best place to ask my question. I'm sorry if it's not!

Everything not strictly bug related (factual and possible bugs) is being discussed in this thread 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.
He’s like a trained ape. Without the training.
 

Offline psysc0rpi0n

  • Frequent Contributor
  • **
  • Posts: 347
  • Country: ar
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #151 on: July 08, 2017, 09:30:16 am »

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

Was this to me? I didn't understood! Do you want to know the scope I own so that you add it to the 1st post, is that it?
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #152 on: July 08, 2017, 11:10:26 am »

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

Sort of...  I try to maintain the opening post as comprehensive and self explanatory as possible so that general discussions can take place in the thread mentioned before and bug related discussion has a dedicated space here. I am open to suggestions for making that more clear in the OP.
He’s like a trained ape. Without the training.
 

Offline PeLa

  • Contributor
  • Posts: 38
  • Country: gb
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #153 on: July 23, 2017, 12:27:12 pm »
I am surprised that I could not find any reference to the following bug in the list yet:

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

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

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

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

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

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

00.04.04.03.02 software
0.0.1.4 Boot version
0.2.3.11 firmware


 

Offline ebastler

  • Super Contributor
  • ***
  • Posts: 7396
  • Country: de
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #154 on: July 23, 2017, 04:39:29 pm »
I am surprised that I could not find any reference to the following bug in the list yet:

I am not.  ;)

I won't call it an arcane usage scenario, but is is certainly not a common one. And while I agree that it would be nice if there were a command to poll the number of averages taken, I don't think the lack of it qualifies as a bug, since the documentation doesn't promise such functionality anywhere.
 

Offline PeLa

  • Contributor
  • Posts: 38
  • Country: gb
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #155 on: July 23, 2017, 06:27:08 pm »
If a digitising scope is unable to tell me whether an acquisition has finished, so that I can go ahead and start the data transfer, that is a bug in my eyes. The number of averages is not required but might be the easiest way to implement as solution.
« Last Edit: July 23, 2017, 06:38:23 pm by PeLa »
 

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #156 on: July 23, 2017, 09:59:04 pm »
I don't think the lack of it qualifies as a bug, since the documentation doesn't promise such functionality anywhere.

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

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

Just a matter of semantics? Absolutely. The meanings are important.
TEA is the way. | TEA Time channel
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #157 on: July 23, 2017, 10:14:33 pm »
Sooo.. does it qualify for a wish list item?

I do not really use the remote interface and thus am a little ambivalent towards everything related to that :)
He’s like a trained ape. Without the training.
 

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #158 on: July 23, 2017, 10:17:18 pm »
It's a feature request, yes.
TEA is the way. | TEA Time channel
 

Offline PeLa

  • Contributor
  • Posts: 38
  • Country: gb
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #159 on: July 24, 2017, 11:02:27 pm »
Thanks for your help guys. I'll leave you to make the decision, whether it goes into any list. It does look like I am asking for a niche feature for this oscilloscope, since nobody else chipped in. What a shame.

It was one of the features that I just assumed every digitising scope has to have because it is (at least in my field) absolutely essential for data acquisition and transfer. I learned the lesson.
 

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #160 on: July 24, 2017, 11:49:34 pm »
Sure thing. Thanks for chiming in, PeLa. We can't all know about every industry's use cases.
TEA is the way. | TEA Time channel
 

Online RoGeorge

  • Super Contributor
  • ***
  • Posts: 7089
  • Country: ro
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #161 on: September 07, 2017, 11:27:36 pm »
NEW BUG (Software 00.04.04.SP3, Board 0.1.1): When a bad SCPI command is followed by at least one other command, then querying the error queue using ":SYST:ERR?" will lead to unresponsive (hang) SCPI over TCP/IP (LXI) until the next power cycle.
Note: This will not happen for any bad command, so far I found that commands that make the oscilloscope to display "Function Limited!" or "Invalid Input!" will trigger this kind of bug. I didn't test it for USB/SCPI commands.

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

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

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

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

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

Rigol, please fix it.
 :-BROKE



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

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

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

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

Later edit:
It would be useful if anybody else can reproduce this, please. Does your DS1000Z hangs, too?
« Last Edit: September 07, 2017, 11:47:39 pm by RoGeorge »
 

Offline zbyr

  • Contributor
  • Posts: 23
  • Country: pl
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #162 on: September 08, 2017, 11:44:39 am »
Yup. Bug also exist in SCPI with USB connection.

« Last Edit: September 08, 2017, 11:48:58 am by zbyr »
 
The following users thanked this post: RoGeorge

Online RoGeorge

  • Super Contributor
  • ***
  • Posts: 7089
  • Country: ro
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #163 on: September 08, 2017, 01:06:30 pm »
Thank you for testing it.

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #164 on: September 08, 2017, 01:32:07 pm »
Regarding the scpi command bug, is somebody going to report it to Rigol and post the date of reporting and contact details (Rigol NA/Europe/etc, name of Rigol contact person) here?
 

Offline SparkyM8

  • Newbie
  • Posts: 7
  • Country: gb
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #165 on: September 08, 2017, 01:50:51 pm »
So if I want to acquire a certain number of averages of an event that only occurs every now and then, I have no way to find out via a query sent to the scope.

PeLa are you checking the OPC bit?

OPC should not be set to 1 until the operation is complete. Certainly, whenever I have programmed Agilent spectrum analysers with averaging involved OPC does not go high until all averages have been collected.
This aspect is not only desirable, it is usually essential, because the connection will probably timeout and halt your program if you ask for a response before all the data are collected.
Normally you would put the program into a timer loop, checking OPC with every pass, and jump out when it goes high then collect the data.
« Last Edit: September 08, 2017, 01:54:51 pm by SparkyM8 »
 

Online RoGeorge

  • Super Contributor
  • ***
  • Posts: 7089
  • Country: ro
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #166 on: September 08, 2017, 02:02:19 pm »
Regarding the scpi command bug, is somebody going to report it to Rigol and post the date of reporting and contact details (Rigol NA/Europe/etc, name of Rigol contact person) here?

Not me.
Just in case more details about versions are required, I am attaching them here. The SN was partially deleted by me.

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #167 on: September 09, 2017, 11:50:59 am »
Original posting has been updated with info on SCPI lock up.

Regards,
Frederik
He’s like a trained ape. Without the training.
 

Offline rob040

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

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #169 on: October 10, 2017, 10:04:30 pm »
I also referred to the long existing typo "Pluses" and the answer on that was that it was first time reported to Rigol only 5 weeks ago.  :-//

Hmmm. Fascinating.
TEA is the way. | TEA Time channel
 

Offline Wall-E

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

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

So guys we need to get together and each chime in when a issue is found if we want to have any action taken.  Is this so unexpected.  We all need to do our share of bitching to get something done.  Don't just let it go because someone has submitted a technical support issue.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #171 on: October 11, 2017, 06:27:19 am »
That's not hard to understand for any progressive business organization with new designs in the works to enhance their product line.

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

"Uncompromised Performance… Unprecedented Value"

 

Offline ebastler

  • Super Contributor
  • ***
  • Posts: 7396
  • Country: de
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #172 on: October 11, 2017, 07:13:23 pm »
On the contrary, it is very hard to understand from a test & measurement company that claims:

"Uncompromised Performance… Unprecedented Value"

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

But, seriously: Of course Rigol will have to triage, and will not fix all issues. Otherwise they would never get around to releasing further new products once they have to sustain a few existing products in the market.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #173 on: October 21, 2017, 12:41:52 pm »
I want to add another bug. The DS1000Z series does not display the full vertical resolution, it clips it at 80%.
The 8-bit ADC produces 8-bit samples which have 2^8 = 256 possible values. Only 200 of them are visible on the display,
the rest is cut-off.
Downloading the waveform sample data will give you acces to the full vertical resolution.
Have a look at the screenshots, one is made internally in the scope and shows the clipped waveform.
By using DSRemote you can view the full dynamic range of the ADC. It's an increase of dynamic range of 25%!
 
The following users thanked this post: bitseeker, I wanted a rude username

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #174 on: October 21, 2017, 02:52:40 pm »
I want to add another bug. The DS1000Z series does not display the full vertical resolution, it clips it at 80%.

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

Edit: In case you did not notice: The screen of the 1054Z gives you 8 vertical divisions while the emulated 1104Z screen shows 10 vertical divisions, hence can show the full waveform without clipping at 2V/div.
« Last Edit: October 21, 2017, 02:57:38 pm by frozenfrogz »
He’s like a trained ape. Without the training.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #175 on: October 21, 2017, 03:40:55 pm »
I want to add another bug. The DS1000Z series does not display the full vertical resolution, it clips it at 80%.

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

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

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

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

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

 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #176 on: October 21, 2017, 04:43:13 pm »
So basically you are saying, that there is a mismatch between displayed divisions and actual ADC gain setting / range?

Namely:

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

*where true gain setting might have to be determined via experiments
« Last Edit: October 21, 2017, 04:46:48 pm by frozenfrogz »
He’s like a trained ape. Without the training.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #177 on: October 21, 2017, 05:36:43 pm »
Yes. Also, it's kind of a "documented bug". If you take a look at the programming guide 2 - 223 (page 239)
there's written that the "Yincrement" steps are verticalscale / 25.

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

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

 
The following users thanked this post: frozenfrogz

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #178 on: October 21, 2017, 05:42:35 pm »
Karel, this is interesting. I normally use the built-in screen and so never noticed the discrepancy. I wonder what they gained or saved by truncating the screen rather than scaling it to fit. Just a case of ease of implementation?
TEA is the way. | TEA Time channel
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #179 on: October 21, 2017, 06:29:52 pm »
Karel, this is interesting. I normally use the built-in screen and so never noticed the discrepancy. I wonder what they gained or saved by truncating the screen rather than scaling it to fit. Just a case of ease of implementation?

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

I would be interesting to know if any other 'scopes do this. It wouldn't be the first time somebody points a finger at the DS1054Z only to find out that many other 'scopes do it as well.
 

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #180 on: October 21, 2017, 07:13:39 pm »
Yeah, ease of implementation.
TEA is the way. | TEA Time channel
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #181 on: October 21, 2017, 07:51:32 pm »
Karel, this is interesting. I normally use the built-in screen and so never noticed the discrepancy. I wonder what they gained or saved by truncating the screen rather than scaling it to fit. Just a case of ease of implementation?

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

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

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #182 on: October 21, 2017, 09:40:00 pm »
Good question. I dunno.

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

I wouldn't think it's to avoid quantization error from fitting 256 values across 400 pixels. Scopes aren't so accurate for that to matter so much anyway.
TEA is the way. | TEA Time channel
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #183 on: October 21, 2017, 09:43:57 pm »
Then why didn't they do it with the 4000 series which uses the same resolution?

Bigger FPGA, more free gates?

Who knows...?

 

Offline technogeeky

  • Frequent Contributor
  • **
  • Posts: 555
  • Country: us
  • Older New "New Player" Player Playa'
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #184 on: October 21, 2017, 10:00:32 pm »
Karel, this is interesting. I normally use the built-in screen and so never noticed the discrepancy. I wonder what they gained or saved by truncating the screen rather than scaling it to fit. Just a case of ease of implementation?

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

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

 
The following users thanked this post: I wanted a rude username

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #185 on: October 21, 2017, 10:09:30 pm »
LOL, nice side effect, technogeeky. The down side, though, is that you sacrifice the resolution of your input to that math function by allowing the "hidden" signal to be small enough to fit within that small space up (or down) there.
TEA is the way. | TEA Time channel
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #186 on: October 27, 2017, 12:43:51 pm »
Since I was quite busy the last couple of days I added the ADC gain <-> display mismatch bug to the OP just today.

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

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

Regards,
Frederik
He’s like a trained ape. Without the training.
 

Offline metrologist

  • Super Contributor
  • ***
  • Posts: 2300
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #187 on: October 27, 2017, 02:05:43 pm »
Yes. Also, it's kind of a "documented bug". If you take a look at the programming guide 2 - 223 (page 239)
there's written that the "Yincrement" steps are verticalscale / 25.

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

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

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

Online RoGeorge

  • Super Contributor
  • ***
  • Posts: 7089
  • Country: ro
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #188 on: October 27, 2017, 02:58:58 pm »
The vertical resolution is 8 bits. It doesn't says all 256 values must fit on one screen.
As a parallel situation, it would be unfair to consider the time zoom feature as a bug, just because it doesn't fit all the samples in the same screen without scrolling, right?

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

One more thing, only 8 horizontal divisions instead of 10 is nothing when compared with only half resolution on some voltage ranges (as in 7 bits instead of 8 bits). I remember there were certain voltage ranges where the values were all odd when read by SCPI, which led me to the conclusion that some voltage ranges were just simulated in software by a x2 multiplication, instead of using a real voltage divider in the analog path of the measured signal.
« Last Edit: October 27, 2017, 03:01:30 pm by RoGeorge »
 

Offline metrologist

  • Super Contributor
  • ***
  • Posts: 2300
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #189 on: October 27, 2017, 03:08:30 pm »
But how do you qualify the vertical resolution as being 8 bits? It seems there is only one way to get the full 8 bits out of the device, via SCPI in RAW mode, which presents other limitations.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #190 on: October 27, 2017, 03:15:02 pm »
Yes. Also, it's kind of a "documented bug". If you take a look at the programming guide 2 - 223 (page 239)
there's written that the "Yincrement" steps are verticalscale / 25.

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

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

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

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

 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #191 on: October 27, 2017, 03:20:59 pm »
I see this 8 divisions instead of 10 as a display limitation, not as a bug. Yes, it could have been better, with 10 divisions drawn on the screen, but it's not.

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

« Last Edit: October 27, 2017, 03:23:11 pm by Karel »
 

Offline metrologist

  • Super Contributor
  • ***
  • Posts: 2300
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #192 on: October 27, 2017, 03:25:49 pm »
Yes. Also, it's kind of a "documented bug". If you take a look at the programming guide 2 - 223 (page 239)
there's written that the "Yincrement" steps are verticalscale / 25.

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

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

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

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

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

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #193 on: October 27, 2017, 04:08:51 pm »
Yes. Also, it's kind of a "documented bug". If you take a look at the programming guide 2 - 223 (page 239)
there's written that the "Yincrement" steps are verticalscale / 25.

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

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

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

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

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

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

 

Offline metrologist

  • Super Contributor
  • ***
  • Posts: 2300
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #194 on: October 27, 2017, 04:17:08 pm »
So then, how did DSRemote get the info for the extra divisions? In normal mode, it would only receive the display data.

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

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

And, how do we qualify 8-bit vertical resolution? I seem to recall that the measurements use display data for the calculations, so we actually do not have 8 bit resolution. Who's to quibble over a few (56) bits?
« Last Edit: October 27, 2017, 04:48:34 pm by metrologist »
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #195 on: October 27, 2017, 05:31:02 pm »
So then, how did DSRemote get the info for the extra divisions? In normal mode, it would only receive the display data.

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


 

Offline metrologist

  • Super Contributor
  • ***
  • Posts: 2300
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #196 on: October 27, 2017, 05:59:57 pm »
So then I don't understand the point of having a mode setting, at least not the RAW setting. Seems you could set the format to WORD and get the same information (range). Anyway, that's off topic now.

 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #197 on: October 27, 2017, 06:17:04 pm »
Since I was quite busy the last couple of days I added the ADC gain <-> display mismatch bug to the OP just today.


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

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

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

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

« Last Edit: October 27, 2017, 06:22:56 pm by Fungus »
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #198 on: October 27, 2017, 06:38:40 pm »
What happens if you freeze the display and move it up/down. Does the extra signal scroll into view?

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

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

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #199 on: October 27, 2017, 06:56:56 pm »
What happens if you freeze the display and move it up/down. Does the extra signal scroll into view?

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

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


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

Must be a hardware limitation. If 200 pixels are visible then they're obviously just dividing by two in the display logic instead of fully scaling the values. Maybe they ran out of gates in the FPGA or it would be much slower or something. Only Rigol knows for sure. The 4000 series will have a more powerful chipset.
 

Offline metrologist

  • Super Contributor
  • ***
  • Posts: 2300
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #200 on: October 27, 2017, 07:02:37 pm »
I'm not sure what to make of it. The example has a 20Vp-p signal with the graticule set to show 16V, 2V/div, but DSRemote has the graticule set to show 20Vp-p. Perhaps the bug is DSRemote not using the same display range as the scope? Of course, then you could argue that it would be using 1.6V/div, which also does not match the scope.

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

I guess since the data is there and can be moved into view, that is considered display data and is used for the measurements, and is therefore still 8 bits. You just don't get to see them all at once. That introduces some uncertainty since I generally try to maximize my signal for best accuracy, so do I now need to maximize it beyond the display region go get the highest accuracy?
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #201 on: October 27, 2017, 07:40:17 pm »
Perhaps the bug is DSRemote not using the same display range as the scope?

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

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

The 4000 and 6000 series show the complete waveform. At least they specify 32 steps per vertical division.
So, with eight vertical divisions, there are 256 steps on the scopes display. Exactly what fits in one byte and what should come out of the adc.
For obvious reasons, DSRemote shows exactly the same with the 4000 and 6000 series. There's no option to extend the vertical range.
 

Offline metrologist

  • Super Contributor
  • ***
  • Posts: 2300
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #202 on: October 27, 2017, 07:47:39 pm »
So DSRemote only shows 8 divisions with the 4/6000 series? The complete waveform would be clipped on the display, if you set it the same way as the 1054.
 

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #203 on: October 27, 2017, 10:04:52 pm »
Correct. The 4000/6000 series scale the 256 values to fit into 8 divisions. The 1054Z, on the other hand, clips values above and below the 200 that will appear on the screen. In other words, it's as if the screen had 10 vertical divisions, but the top and bottom division are simply not visible on the device.

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

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #204 on: October 28, 2017, 06:25:16 am »
Correct. The 4000/6000 series scale the 256 values to fit into 8 divisions. The 1054Z, on the other hand, clips values above and below the 200 that will appear on the screen. In other words, it's as if the screen had 10 vertical divisions, but the top and bottom division are simply not visible on the device.

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

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

I just wanted to bring it up here and will let it up to others if it should be added to the buglist or not.
 
The following users thanked this post: bitseeker

Offline TD-Linux

  • Contributor
  • Posts: 16
  • Country: us
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #205 on: October 28, 2017, 06:38:23 am »
I wouldn't think it's to avoid quantization error from fitting 256 values across 400 pixels. Scopes aren't so accurate for that to matter so much anyway.

Yeah, normally this would be nonissue - you increase precision when downsampling memory for display, or averaging for persistence, and can utilize it when drawing lines on the display and often you have at least 1 lsb of noise anyway. One possible reason is that they may be really trying to cheap out on the math - nearest downsampling, or quantizing the output of their filters back to 8 bits before processing for display. You'd think in this day and age that sparing a few extra bits in your adders and multipliers would be cheaper than throwing away 10% of your expensive ADC's dynamic range... alas, after seeing that pitiful FFT, maybe there's a stock shortage of multipliers at Rigol.
 
The following users thanked this post: frozenfrogz

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #206 on: October 28, 2017, 07:29:38 am »
My vote is that it's simply a consequence of minimizing cost (i.e., by design).

I'm just glad to know that there's more data above and below the display that I can access. Thanks for the revelation, Karel.
TEA is the way. | TEA Time channel
 
The following users thanked this post: frozenfrogz

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #207 on: October 28, 2017, 07:57:57 am »
I am going to keep it in the bug list and sort the issues later. I think it belongs into the "oddities" category, meaning »things you need to know about your scope« such as that the math / decode / ... functions use the screen data instead of the recorded memory.
He’s like a trained ape. Without the training.
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23102
  • Country: gb
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #208 on: October 28, 2017, 09:55:52 am »
I think that’s my biggest annoyance. In the math functions it defaults to using the display as a source. So if I want any resolution in the math functions, I have to change the memory depth and frig the math source every bloody time and then set it back to auto when I’m done.
 

Online RoGeorge

  • Super Contributor
  • ***
  • Posts: 7089
  • Country: ro
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #209 on: October 28, 2017, 10:34:56 am »
I am going to keep it in the bug list and sort the issues later.

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

Even more, do I want a grid of rectangles instead of squares, or fuzzy reticles, or a slower display because of the required interpolation? Probably not.

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #210 on: October 28, 2017, 10:48:34 am »
I wouldn't mix the 'bugs list' with the 'wish list'

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

The bug list will be reorganized by severity / urgency and quirky feature issues that are not real bugs have to be moved into a separate list - maybe as wish list items (that I had not touched yet :) )
He’s like a trained ape. Without the training.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #211 on: October 28, 2017, 12:34:22 pm »
8 divisions on the vertical screen is not a bug.

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

 

Online lundmar

  • Frequent Contributor
  • **
  • Posts: 443
  • Country: dk
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #212 on: October 28, 2017, 10:57:45 pm »

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

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

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

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

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

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

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

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

With nc/telnet you don't get any timeout management etc. - it is less robust and it results in locking up your instrument when you hit buggy commands.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Online RoGeorge

  • Super Contributor
  • ***
  • Posts: 7089
  • Country: ro
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #213 on: October 29, 2017, 08:50:44 am »
8 divisions on the vertical screen is not a bug.
The issue is/was that the scopes display isn't showing the complete waveform as captured by the adc,
i.e. the dynamic range is (unnecessary) limited.

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

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

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

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

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

Online lundmar

  • Frequent Contributor
  • **
  • Posts: 443
  • Country: dk
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #214 on: October 29, 2017, 09:19:55 am »
That's a very interesting finding, thank you for testing the hang!

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

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

If you do take lxi-tools for a test spin please install the latest versions of liblxi and lxi-tools from https://lxi.github.io - the latest versions contains new features and many bug fixes but it is now in a pretty good state. I'm quite happy with how it works. Finally we have a solid commandline tool for Linux to talk to our various instruments.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #215 on: October 29, 2017, 09:31:09 am »
That being said, the best way to fire SCPI commands to any LXI enabled device is to use tools that use the VXI11 protocol to communicate/handle the commands.

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

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

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

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

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

literature.cdn.keysight.com/litweb/pdf/5989-6717EN.pdf


 

Online lundmar

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

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

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

Here is an interesting raw TCP vs.VXI vs. HiSlip comparison made by R&S:


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.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Online RoGeorge

  • Super Contributor
  • ***
  • Posts: 7089
  • Country: ro
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #217 on: October 29, 2017, 03:15:42 pm »
If you do take lxi-tools for a test spin please install the latest versions of liblxi and lxi-tools from https://lxi.github.io

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

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

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

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

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

apt-get install libreadline-dev

./configure
make
make install

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

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

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

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

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

Offline Karel

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

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

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

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

Edit:

According to Keysight it is:

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


« Last Edit: October 29, 2017, 04:15:24 pm by Karel »
 

Online lundmar

  • Frequent Contributor
  • **
  • Posts: 443
  • Country: dk
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #219 on: October 29, 2017, 04:37:33 pm »
First, lxi-tools is a very nice and useful tool, thank you for making it available.  :-+

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

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

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

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

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

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

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

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

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

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

You can safely file a bug for that specific command sequence failing to respond. I think it is the command which is failing and not the communications channel, regardless of it being RAW/TCP or VXI/TCP.
« Last Edit: October 30, 2017, 02:30:37 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Online RoGeorge

  • Super Contributor
  • ***
  • Posts: 7089
  • Country: ro
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #220 on: October 29, 2017, 06:11:08 pm »
Quote
In 2000, the VXIplug&play Alliance added support for LAN-based instruments to its VISA specifications.
Two popular methods of instrument control via Ethernet were adopted by VISA:
VXI-113 and “direct” TCP socket communication

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

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

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

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

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

I noticed that you opened a topic about lxi-tools and liblxi: https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/
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?

Online lundmar

  • Frequent Contributor
  • **
  • Posts: 443
  • Country: dk
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #221 on: October 29, 2017, 06:45:26 pm »
Yep, I would like to contribute, but most of all I would like to see a generic implementation that does not require to install a few GB of closed source drivers, like e.g. NI-VISA for Windows does now. All the best wishes with that. It's pretty lame that a lot of people are wasting their time to implement their own software for sending SCPI commands (including myself, which I'm not a programmer), instead of just using some open source established library.

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

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

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

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

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

No problem. Learning new stuff is often fun.

I noticed that you opened a topic about lxi-tools and liblxi: https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/
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.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple serial device I/O tool
 

Offline TinkeringSteve

  • Frequent Contributor
  • **
  • Posts: 299
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #222 on: November 04, 2017, 07:28:27 pm »
I just installed the lates firmware on mine, thinking, they probably got most of the kinks out of there.

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

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

 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #223 on: November 04, 2017, 07:40:27 pm »
No problems using FFT in memory mode.
Does your scope freeze every time / is it reproducible?
If it is persistent: Please try re-uploading the firmware as you already mentioned and if the error still remains, please share the extended system info for reference.
He’s like a trained ape. Without the training.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #224 on: November 04, 2017, 07:59:37 pm »
Try resetting the scope: switch it off and then on again and press repeatedly the 5th grey button on the left.
The language will change to chinese but that's easily fixed in the menu at the left.
 

Offline TinkeringSteve

  • Frequent Contributor
  • **
  • Posts: 299
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #225 on: November 04, 2017, 08:02:07 pm »
Oh starting does work, the firmware apparently doesn't get to store that setting, it's back to "trace" when I start again.

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

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

« Last Edit: November 04, 2017, 08:04:43 pm by TinkeringSteve »
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #226 on: November 04, 2017, 08:30:21 pm »
My scope does not freeze - regardless of which channels are activated etc. I fiddled around with the active channels selection, input selection of FFT function, window mode, trace/memory both in auto and record/stop mode and single shot triggering. My scope does not lock up.
He’s like a trained ape. Without the training.
 

Offline TinkeringSteve

  • Frequent Contributor
  • **
  • Posts: 299
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #227 on: November 04, 2017, 08:47:21 pm »
My scope does not freeze - regardless of which channels are activated etc. I fiddled around with the active channels selection, input selection of FFT function, window mode, trace/memory both in auto and record/stop mode and single shot triggering. My scope does not lock up.

Funny. I can't reproduce it anymore either. I did a couple times before, only using Ch2 and restariting and going straight to "math" and changing the setting.
Now that I fiddled around a bit more, even restarting with only Ch2 active, going to math/fft and oing the memory setting, nah.
Weird.
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #228 on: November 13, 2017, 09:46:09 am »
Good news everyone!

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

This is just a heads up and while Rigol might be reading this: Thanks for taking us seriously and you are very welcome to chime in and get a part of this forum!
Lots of Rigol users to get in contact with around here!
He’s like a trained ape. Without the training.
 
The following users thanked this post: Payne

Offline bitseeker

  • Super Contributor
  • ***
  • Posts: 9057
  • Country: us
  • Lots of engineer-tweakable parts inside!
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #229 on: November 14, 2017, 02:38:20 am »
Excellent. Thanks for doing that. Hopefully, one day Rigol will pay attention to what goes on here. So far, they seem not to notice.
TEA is the way. | TEA Time channel
 
The following users thanked this post: frozenfrogz

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #230 on: March 01, 2018, 11:38:02 am »
Since the last firmware release some water has gone under the bridge and I am interested to see if some of you did check out what bugs still remain. I would like to keep the opening post up to date and as comprehensive as possible :)

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

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

Kind regards,
Frederik
He’s like a trained ape. Without the training.
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #231 on: March 01, 2018, 12:12:45 pm »
Since the last firmware release some water has gone under the bridge and I am interested to see if some of you did check out what bugs still remain. I would like to keep the opening post up to date and as comprehensive as possible :)

There's not much left. A typo in a menu, and... I can't remember any more.
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #232 on: March 01, 2018, 12:20:34 pm »
There's not much left. A typo in a menu, and... I can't remember any more.

That is my experience as well - the scope does what I expect it to do. I am no scope specialist though and most likely need just the basic functions anyway.
Personally, I hope Rigol does not fix the pluses spelling! I am feeling kind of attached to it by now :)
He’s like a trained ape. Without the training.
 

Offline Roeland_R

  • Regular Contributor
  • *
  • Posts: 62
  • Country: nl
Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #233 on: March 01, 2018, 12:26:45 pm »
For the wish list: Alternate triggering perhaps?
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #234 on: March 01, 2018, 12:55:17 pm »
Re. alternate triggering: There is this thread.

I’ll add it as a wish list item when going through the post :)
He’s like a trained ape. Without the training.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #235 on: March 01, 2018, 04:41:57 pm »
The USB protocol violation that causes a failing connection dipending on motherboard USB-controller chipset and operating system, is still present and Rigol has no plan to fix it.
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #236 on: March 01, 2018, 07:19:37 pm »
The USB protocol violation that causes a failing connection dipending on motherboard USB-controller chipset and operating system, is still present and Rigol has no plan to fix it.

Bummer!

(I guess I"ll have to use an Ethernet cable instead...)
« Last Edit: March 01, 2018, 07:30:13 pm by Fungus »
 

Offline Porcine Porcupine

  • Contributor
  • Posts: 35
  • Country: us
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #237 on: March 04, 2018, 06:15:49 am »
Bug report: Some DS1000Z units display in peak detect acquisition mode while set to normal acquisition mode.

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

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

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.
« Last Edit: March 04, 2018, 09:50:05 am by Porcine Porcupine »
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #238 on: March 04, 2018, 09:17:18 am »
Thank you for the detailed report! I will add it to the list and try to recreate the issue on my device.

Kind regards,
Frederik
He’s like a trained ape. Without the training.
 
The following users thanked this post: Porcine Porcupine

Offline Porcine Porcupine

  • Contributor
  • Posts: 35
  • Country: us
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #239 on: March 04, 2018, 10:17:50 am »
Thank you for the detailed report! I will add it to the list and try to recreate the issue on my device.

Kind regards,
Frederik

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

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

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #240 on: March 04, 2018, 11:03:29 am »
I could not reproduce it at that time, but maybe I did not try hard enough ;)
Would be interesting to see if it can be tracked down to certain behavior / sequence of operation.
He’s like a trained ape. Without the training.
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
« Last Edit: March 04, 2018, 11:50:13 am by Fungus »
 

Offline Porcine Porcupine

  • Contributor
  • Posts: 35
  • Country: us
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #242 on: March 04, 2018, 11:36:42 am »
This has had its own thread:

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

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.
« Last Edit: March 04, 2018, 11:40:40 am by Porcine Porcupine »
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #243 on: March 04, 2018, 11:52:32 am »
This has had its own thread:

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

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

Offline Porcine Porcupine

  • Contributor
  • Posts: 35
  • Country: us
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #244 on: March 04, 2018, 01:09:02 pm »
I still think it's a hardware limitation in the circuit that copies raw sample data to the display.

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

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

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

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

Here's a trace captured in normal mode:



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.
« Last Edit: March 04, 2018, 01:10:36 pm by Porcine Porcupine »
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 17593
  • Country: 00
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #245 on: March 04, 2018, 03:53:40 pm »
One thing that convinced me it's stuck in peak detect mode is that I was able to produce a trace with MATLAB that looks exactly as it should by simply downsampling the raw data to the same number of points displayed on the screen.

Correct.

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

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

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

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

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

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

Online 2N3055

  • Super Contributor
  • ***
  • Posts: 7561
  • Country: hr
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #246 on: March 04, 2018, 04:35:58 pm »
@Porcine Porcupine,

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

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

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


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

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

Just something to think about...

Regards,

Sinisa
"Just hard work is not enough - it must be applied sensibly."
Dr. Richard W. Hamming
 
The following users thanked this post: Fungus

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #247 on: March 05, 2018, 10:20:19 am »
After some fiddling I could get to show the double tracing on my scope. It is very dependent on the time base and magnification setting though.
Looks like a quantization issue to me but that is just a wild guess.
It is gone in hi-res and average mode, thus my suspicion for quantization through the ADC.

« Last Edit: March 05, 2018, 10:24:58 am by frozenfrogz »
He’s like a trained ape. Without the training.
 

Offline frozenfrogzTopic starter

  • Frequent Contributor
  • **
  • Posts: 936
  • Country: de
  • Having fun with Arduino and Raspberry Pi
Re: Rigol DS1000Z series buglist continued (from: 00.04.04.03.02)
« Reply #248 on: March 05, 2018, 10:29:41 am »
Btw. if you are on the low end, say 10mV per unit, you are seeing all the noise.
If you zoom in per time base, the "double trace" resolves into a scattered point cloud, showing kind of a rendering issue.
The black area between the top and bottom "trace" should actually be all yellow in this case, but for some reason the individual dots add up to *null* when merged closely together.
He’s like a trained ape. Without the training.
 

Offline Fungus

  • Super Contributor