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 :*see also pdf file provided by ted572 appended below
- 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.
[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
Here's my attempt to catalog the bugs and wish list items for the Rigol DS1000Z oscilloscopes. This should apply to the regular and -s versions, but may not apply to the MSO versions) I'll try to modify this top post as people add their found bugs and wish list items. Hopefully Rigol will see this thread and respond to it.
This list is for software version: 00.04.02 and 00.04.03 only, with the current hardware (possibly only board 0.1.1).
Rigol fixed the following bugs (according to their documentation between 4.02 and 4.03):
- Modified the method of key board test and screen test and optimized processing speed.
- The display of keyboard lights and the show of menu was wrong while switch the timebase mode between YT and ROLL in the Normal trigger mode.
- The saved data of REF waveform was wrong while STOP the system then open the channel.
- The output of AUX was wrong while the function of Pass/Fail was closed.
- The display of LA signal was wrong while adjust the delay calibration of LA signal.
- The position of LA wave and label of LA channel was wrong while load the file of LA waveform then RUN the system.
- The wave of channel1 can not be displayed while open the scan mode then switch the channel2 over and over again.
- The position of LA wave was wrong while load the file of LA waveform before change the position of the LA channel.
- The memory data of LA channel was wrong when use the remote command to read.
- Save the CSV file failed while the system stopped.
- Fixed the bug of unlocked the key board failure when save the file.
Bugs:
1) The new Large and Extra Large measurement fonts are nice, but they are reset to Normal on each power cycle. This should be retained like all the measurement settings are.
2) The Select Item sub-menu on the Measurement menu has 5 check boxes implying that it should be useable for Normal font too, but it's grayed out. The only way to remove a measurement from the screen using Normal font is a power off/on cycle.
One member has already suggested that the left side menu as a series of on/off toggles as the means for including/removing the measurement. This in conjunction with the Select Item sub-menu (which could turn on/off the display position of an item) might give maximum flexibility and ease of use.
3) The FFT function only works for channel 1. However it will work for the other channels as long as channel 1 is turned on. It's actually more complicated than that for more details see this thread: https://www.eevblog.com/forum/testgear/another-rigol-1000z-bug/msg568478/#msg568478 (https://www.eevblog.com/forum/testgear/another-rigol-1000z-bug/msg568478/#msg568478)
Also, the FFT cdisplay shows bad aliasing under most circumstances. See this thread for more details: https://www.eevblog.com/forum/testgear/rigol-ds1054z-fft-bug%28s%29/ (https://www.eevblog.com/forum/testgear/rigol-ds1054z-fft-bug%28s%29/)
4) The Large and Extra Large fonts cover up items that display at the bottom of the screen. For example the brightness indicator and the math equation.
5) Some users have reported that the zero line of the trace is not perfectly centered after doing a calibration. This is not an issue on all units, however, so might be more of a hardware variability item. Users expect that all traces along with their channel number indicator should perfectly centered on the display (on top of each other) after a calibration.
(See this post for some post-calibration screen shots: https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-%28ds1054z-ds1074z-ds1104z-and-s-models%29-bugswish-list/msg584977/#msg584977 (https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-%28ds1054z-ds1074z-ds1104z-and-s-models%29-bugswish-list/msg584977/#msg584977))
If it's not possible for the calibration routine to automatically do this, maybe allow the user to manually set the channel offset at the exact center and save that value until the next calibration.
6) Writing full memory to a CSV file takes an extremely long time. Write speeds seem to be about 0.15 MB/sec instead of the expected 10MB/sec or so.
7) When show measurements from the MATH trace the units don't match to the units selected (or computed) in the MATH function. For example: Ch 1= Volts, Ch 2=Amps, Math= Ch1 x Ch2 will show Watts on the trace but MATH measurements will show Volts, instead of correctly showing Watts.
8 ) The 20M Bandwidth Limit setting for each channel is not saved, it resets of OFF each power cycle.
9) If the following settings are used:
Input signal: probe compensation 1kHz square wave from the scope
Trigger: DC / CH1 / 1.5V
Aquisition: High Res / 120k mem. depth
Horizontal position: 0ps
Horizontal scale: 50us/div
The scope will display the waveform shifted by around 75us. See details in this picture:
(https://www.eevblog.com/forum/testgear/ds1054z-bug-(with-poll)/?action=dlattach;attach=153347)
10) Some users have reported scope lock ups when setting memory depth to AUTO, timebase to 1us, zooming in and changing the persistence from MIN something else. Apparently not all users experience this problem but those that do can reproduce it every time. See this thread for much more detail: https://www.eevblog.com/forum/testgear/rigol-ds1054z-freeze-up-bug/ (https://www.eevblog.com/forum/testgear/rigol-ds1054z-freeze-up-bug/)
11) Remote I/O menu will not allow selection of LAN if USB is ON. You need to unplug the USB device first.
12) Inside the CSV file, the scope stores the "increment", in the memory dumps that increment is 25X longer than it should be to correctly represent the expected sampling period. For example: if the increment is 10us, one has to set the time increment to 400ns (2.5MSPS) in order to get the correct plot of data.
13) RAW mode of data acquisition over USB returns garbage, rather than the waveform.
Wish List Items:
A) Full screen X-Y mode, the current display is tiny. Also, allow screen persistence to be set in X-Y mode.
B) Decoders should allow DATASRC to be either Trace or Memory. This is documented in the manual but apparently only Trace is implemented, so this might be a bug. Even the SCREEN option could be improved so that decoding starts at a start-bit not at the left edge of the screen.
C) When displaying a math function allow the underlying channels to be hidden.
D) Compress and move the waveform to the bottom of the screen when Measure All is on as is done, optionally, for FFT display. Also for measurement history.
E) Allow Measure All to be selected in the AUTO options menu.
F) Allow the user to hide the left and right side menus. Also the left side menu is often irrelevant and that screen space could be used for other display items.
G) When selecting a channel, show some corresponding channel color around the settings instead of having everything in just white. Maybe just change the color of the tiny CH1, CH2, CH3, CH4 label next to the Coupling setting.
H) Use a larger font for the popup keyboard.
I) Save the last few file names in the Storage menu for faster access. Maybe use the left side menu for this? Alternatively, just remember the last file name entered and allow the user to increment any trailing digits. So TEST0001 would go to TEST0002 automatically (or will a key press).
J) Allow the trace Display Persistence Time to be turned off -- instead of just MIN. The scope would then just show each waveform as it's captured and blank the display before showing the next. Even the MIN persistence level can hide some detail.
K) Allow larger fonts for certain items. For example: timebase, trigger level and channel gain (volts/div). Also use a larger icon showing the coupling (DC/AC/GND) next to the channel gain.
L) Use a different color for the math trace, something that stands out better, maybe red?
M) Allow the user to select a color for the A and B cursors, individually. Currently they are distinguished by a solid and dotted line both in white.
N) Allow for selectable FFT size (number of points: 128, 256, 512, 1024) calculation -- ie, trade off speed for accuracy.
O) Show the trigger type and coupling method (DC/AC/LFR/HFR) next to the trigger type icon in the upper right corner.
P) Consider moving the selection of the trigger coupling method to the top-level trigger menu instead of the Setting sub-menu. Same for the Holdoff.
Q) Allow for variable high and low pass filtering for each channel, as was done in the earlier 1000 series scopes.
R) Add boxes for Math and Ref to the bottom bar alongside the channel info. Color coding them and added relevant info such as gain or offset offset voltage.
S) Allow for a simple screen title. Maybe allow more text to be added via a PC connection, perhaps a query that could be responded to with a key press on the scope.
T) Hardware frequency counter shows "<15Hz" when the STOP button is pressed even though it had been showing a valid value. It would be best to freeze this value like other measurements are.
U) Ability to save a Recorded data to USB drive.
V) Consider checking the way the menu system works, as follows:
Push a soft menu button to open a menu, push the same button again to close the menu.
When a menu is open you can use the light blue up/down arrows to select an item in the menu, or use the multifunction knob if you prefer that. When you have the correct item highlighted in the menu, push the soft menu button again to select the item and close the menu (or push the multifunction knob if you prefer).
W) Change file file numbering scheme so that instead of using the first available file number simply use a sequential number (stored in persistent memory) until reset by the user.
X) Use a meaningful amount of decimals in the horizontal position display (e.g. '0.00000000 ps' should be something like 0.0 ns since the smallest step size is 0.1ns)
Y) Have the FFT function compute an average if the channel it's set to is set to "average" in Acquire menu. Other single-argument math functions seem to do this.
Z) Allow a push of the trigger level control to set the trigger level at the 50% level or at the 0% level - as it currently does.
AA) Improve the response of the vertical and horizontal position movements, they have quite a bit of lag.
AB) It would be helpful to be able to see the on-screen ASCII table when setting up an RS-232 trigger.
AC) Add (wired/wireless) USB keyboard support for navigating menus and character input.
AD) Add a menu option to allow the user to set the offset voltage (or whatever the current units are). This is in addition to the normal offset control knob.
AE) Allow MATH to be used in the X-Y mode. This means that instead of 6 options of what to display there would be 20 options (so that MATH can be either X or Y).
I could not reproduce the waveform shifting bug in the latest firmware.
Please confirm.
7) RAW mode of data acquisition over USB returns garbage, rather than the waveform.
(Not tested)
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?
v00.04.03.01.05 2015/06/16
- Added French in system language
4) Some users have reported scope lock ups when setting memory depth to AUTO, timebase to 1us, zooming in and changing the persistence from MIN something else. Apparently not all users experience this problem but those that do can reproduce it every time. See this thread for much more detail: https://www.eevblog.com/forum/testgear/rigol-ds1054z-freeze-up-bug/ (https://www.eevblog.com/forum/testgear/rigol-ds1054z-freeze-up-bug/)
(Could not be reproduced by me, please check if your unit was affected)
9) If the following settings are used:
Input signal: probe compensation 1kHz square wave from the scope
Trigger: DC / CH1 / 1.5V
Aquisition: High Res / 120k mem. depth
Horizontal position: 0ps
Horizontal scale: 50us/div
The scope will display the waveform shifted by around 75us. See details in this picture:
(https://www.eevblog.com/forum/testgear/ds1054z-bug-(with-poll)/?action=dlattach;attach=153347)
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.
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.
4) Some users have reported scope lock ups when setting memory depth to AUTO, timebase to 1us, zooming in and changing the persistence from MIN something else. Apparently not all users experience this problem but those that do can reproduce it every time. See this thread for much more detail: https://www.eevblog.com/forum/testgear/rigol-ds1054z-freeze-up-bug/ (https://www.eevblog.com/forum/testgear/rigol-ds1054z-freeze-up-bug/)
(Could not be reproduced by me, please check if your unit was affected)
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.
9) If the following settings are used:
Input signal: probe compensation 1kHz square wave from the scope
Trigger: DC / CH1 / 1.5V
Aquisition: High Res / 120k mem. depth
Horizontal position: 0ps
Horizontal scale: 50us/div
The scope will display the waveform shifted by around 75us. See details in this picture:
(https://www.eevblog.com/forum/testgear/ds1054z-bug-(with-poll)/?action=dlattach;attach=153347)
Works. But:
PNG screenshot with thumb-drive and printer button takes 2 1/2 MINUTES !
Cannel Mark out of Range
With this settings I can change the persist time to anything I want, the scope still freeze. So I have to turn it off (Power cycle and soft-button-reset) to make it usable again. ALL settings gone. Calibration too.
Since the last 3 updates the scope is still very very slow.
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.
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.
Never never again I buy those cheap crap from Rigol !
hf
"Pluses"
Did you try deep cycle / alternative reset?Do we know whether this applies to the DS1000Z series as well? The tech note only refers to the DS2000 series and up.
PDF from Rigol on alternate reset (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-02f4/1/-/-/-/-/file.pdf)
Also there is a memory clearing procedure: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?
PDF from Rigol on sanitizing memory (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-067a/1/-/-/-/-/Sanitize%20DS1000Z%20memory.pdf)
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.Did you try deep cycle / alternative reset?Do we know whether this applies to the DS1000Z series as well? The tech note only refers to the DS2000 series and up.
PDF from Rigol on alternate reset (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-02f4/1/-/-/-/-/file.pdf)
Also there is a memory clearing procedure: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?
PDF from Rigol on sanitizing memory (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-067a/1/-/-/-/-/Sanitize%20DS1000Z%20memory.pdf)
But for now the Rigol does what I need it to. Hope you get yours running again.
On the positive side: I am glad you could revive your scope via reinstalling the firmware again.
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.
*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 ?!
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.
Have you looked at the price of Flukes? :-//
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.
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.
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
Why do you not read my post after your post?
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?
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
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?
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?
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 :(
"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... :-//
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?
If it can handle FAT32 then I don't see why the drive size would make any difference 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.
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).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?
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.
Yeah, the Rigol manual (which version is that from, BravoV?) says maximum 8GB formatted as FAT32. However, there have been problems reported that conflict with the manual. Rstofer just posted success with 2GB FAT16 and 256GB FAT32. Others have had failures with 2GB FAT32.
I upgrade my scope with a 512MB FAT16, which defaults to either 8KB or 16KB clusters (https://support.microsoft.com/en-us/kb/140365) on Windows.(Unfortunately, Microsoft doesn't explicitly specify the size ranges. Grrr! e.g., 256 MB–512 MB has 8KB clusters; 512 MB - 1 GB has 16KB clusters. So, to which range does 512 MB apply?
It would've been helpful if Rigol published what maximum cluster size is supported.
| 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 |
Yeah, the Rigol manual (which version is that from, BravoV?) says maximum 8GB formatted as FAT32. However, there have been problems reported that conflict with the manual. Rstofer just posted success with 2GB FAT16 and 256GB FAT32. Others have had failures with 2GB FAT32.
I upgrade my scope with a 512MB FAT16, which defaults to either 8KB or 16KB clusters (https://support.microsoft.com/en-us/kb/140365) on Windows.(Unfortunately, Microsoft doesn't explicitly specify the size ranges. Grrr! e.g., 256 MB–512 MB has 8KB clusters; 512 MB - 1 GB has 16KB clusters. So, to which range does 512 MB apply?
It would've been helpful if Rigol published what maximum cluster size is supported.
The manual is dated Dec 2015, didn't aware if there is newer one. Downloaded it quite long ago though.
Looking at the USB flash drive fiasco, I suspected Rigol programmer probably either was using a really crappy FAT(32/16) library, or they screwed the library by forking/shrinking it too much, maybe to save flash size or RAM memory or even CPU cycles ? :-//
Thanks ankerwolf :)
Sooo.. Maybe we can pin this on boot version <0.1.3?
(still needs a bigger dataset obviously)
Thanks BravoV,
did you run self-calibration without problems?
That is where issues seem to be sticking their head out.
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.Also: You got a hardware upgrade via USB implant as it seems xD
Also: You got a hardware upgrade via USB implant as it seems xDYep , what a sharp eyes you got there. :-+
But what's up with the "USB implant"? I must have missed something 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... ???
In other words, it's as if a hardware upgrade was physically implanted via the USB interface. That'd be a nice feature, indeed.
Thanks ankerwolf :)Nope. I've got boot version 0.0.1.1 and it doesn't happen here.
Sooo.. Maybe we can pin this on boot version <0.1.3?
(still needs a bigger dataset obviously)
Big jump, just upgraded DS1104Z-S (with FG), from v04.00.00.00 straight to v04.04.03.02,
Did it just work on the third try, or did you do some memory clean or alternative reset?
[...] Little note: the additional soft buttons were present when it succeeded (the third try). Now they're gone.
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.
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?
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?
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..
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...)?
I don't think I will try an "LFCal" any time soon...
I can't figure out, however, what this would be used for. Why would one want to store and recall a calibration
I guess those to buttons are only meant for debugging or service purposes anyway.
:-[ 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 itsDrop 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 |
Has anybody looked at the file? Is it binary/ASCII? How big is it? If it's binary, have we got a hex dump?
Attached is the screencopy of "LFCal".
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.
:FUNCtion:WREPlay:FMAX?
Description Query the maximum number of frames can be played, namely the maximum number of frames recorded.
Who is actually communicating all these bugs to Rigol? Or is there a Rigol application engineer on this forum?
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.
Use the :FUNCtion:WRECord:FEND command to set the maximum number of frames
recorded.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?
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.
QuoteRecording 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?
:FUNCtion:WREPlay:FEND != :FUNCtion:WRECord:FEND !!
: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.
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.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?
...
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
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?
All of the features of the Keysight could easily be added to the 1054z.
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.)
"What if" .. the modded firmware is so bad that put the scope into infinite loop once booted ?The 'un-brick' option.
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"Someone snuck into my house and flashed dodgy firmware onto my 'scope!"fightdispute between seller and user on RMA ... and so on, you just need a little imagination to think of the next scenes.
"What if" .. the un-brick process only can be done if the initialization code also is not modded, and alas, because of the low cost constraints, design wise, protecting the init code is not possible. :-//Then those people 'hacking' this 'scope right now had better be careful. I am assuming that Rigol would know a bit more about their products than the people tinkering with the firmware, so would be able to make that call.
"What if" ... the modded firmware is so shitty, forgot to switch the front end relay to switch to less sensitive input level, while the screen is prompting its ok to plug and pump in high voltage signal ? :palm:The DS1054Z doesn't have a 50 Ohm input. I don't see how you could damage it through a firmware issue.
... another "what if" ... the over temperature mechanism is triggered, and the ISR for handling shutdown sequences is ignored or buggy ... >:DUn-bricking time again...
Too many "what ifs" ... and back to my previous post, its never about these "what ifs" scenarios anyway, the "fact" is, these scopes are selling like hot cakes, so why bother ? :-//To lure the adventurous / foolish into spending their cash on your now out-classed product while you prepare your next true competitor. Money in your business, rather than your competitor's.
Rather than sink deep in this fuss and mess, why not focus and concentrate on designing and making another new generation low cost scope, sort of DS1054Z successor, as DS1054Z is considered quite old now, and the new beast is specifically targeted to hit very hard to those new competing products. >:DOpening up an obsoleted code base costs you nothing. Every 'tech' site and blog will wibble excitedly about your awesome 'open' system, yada yada...
The 'un-brick' option.
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.You can tell the problem is resources -- processor power is definitely lacking, tight memory possibly.
They are strugling with it. Probably, the only way to improve the firmware is to throw out half of the features...
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.)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.
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.
: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)
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...
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?
it is already listed as Bug #8, however I could add more information on this.Hi frozenfrogz!
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.
So, to experienced folks out there, should I update (...) ?
regarding ""pluses" - did I missed something, but yesterday I updated and see this :-// :
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?
I'm not sure if this post is the best place to ask my question. I'm sorry if it's not!
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?
P.S. Please let me know if I should include more summarizing/general info regarding the scope in the opening post.
I am surprised that I could not find any reference to the following bug in the list yet:
I don't think the lack of it qualifies as a bug, since the documentation doesn't promise such functionality anywhere.
: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"
:WAV:STAR 1201
:WAV:STAR 120
:syst:err?
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.
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?
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. :-//
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.
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"
I want to add another bug. The DS1000Z series does not display the full vertical resolution, it clips it at 80%.
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).
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?
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?
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?
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.
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?
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.
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.
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.
So then, how did DSRemote get the info for the extra divisions? In normal mode, it would only receive the display data.
Since I was quite busy the last couple of days I added the ADC gain <-> display mismatch bug to the OP just today.
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?
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.
Perhaps the bug is DSRemote not using the same display range as 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?
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.
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.
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'
8 divisions on the vertical screen is not a bug.
Now, try this:Code: [Select]That's it, after the last ':SYST:ERR?' SCPI hangs, and no other SCPI commands will work until the next power on.:WAV:STAR 1201
:WAV:STAR 120
:syst:err?
Later edit:
It would be useful if anybody else can reproduce this, please. Does your DS1000Z hangs, too?
$ 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
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.
...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.
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.
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.
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.
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
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
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.
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
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:
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.
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.
QuoteIn 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
I hope some people in this forum might contribute...
...
I'm actually working on pushing lxi-tools and liblxi into the most popular GNU/Linux distributions. It is currently being packaged for Fedora/RHEL and soon I hope Debian/Ubuntu packages
Yep, I would like to contribute, but most of all I would like to see a generic implementation that does not require to install a few GB of closed source drivers, like e.g. NI-VISA for Windows does now. All the best wishes with that. It's pretty lame that a lot of people are wasting their time to implement their own software for sending SCPI commands (including myself, which I'm not a programmer), instead of just using some open source established library.
Regarding my personal hassle with the installation, I'm glad that I made the mistake of starting from the github repo, because that led me to new insights about building from sources. ^-^
Thank you for all the other clarifications as well, it all makes more sense now.
I noticed that you opened a topic about lxi-tools and liblxi: https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/ (https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/)
Since other questions related to lxi-tools might become offtopic here, would the above link be the right place for further eevblog talks about lxi-tools and liblxi?
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.
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.
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.
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.
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
This has had its own thread:
https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145 (https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145)
This has had its own thread:
https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145 (https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145)
That's the thread I started about it several months ago. I wasn't sure what the problem was then, but now I'm convinced it's a bona fide firmware bug that deserves Rigol's attention.
I still think it's a hardware limitation in the circuit that copies raw sample data to the display.
It simply can't apply a wide-enough filter to display it correctly (which is understandable - it would need to filter an awful lot of data for each screen pixel). As such, it can't be fixed by firmware.
I'd be interested to how other oscilloscopes deal with this problem (in theory they should all do it to some extent!)
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.
Looks like a quantization issue to me but that is just a wild guess.I agree 100%.
It is gone in hi-res and average mode, thus my suspicion for quantization through the ADC.
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).
@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
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.
It also seems strange to me that noise or anything else in this signal could alias into two lines like that without any points between them.
When I downsampled with Matlab, I did it in about the crudest way possible by just throwing samples away without any low-pass filtering. If downsampling were going to cause such aliasing with this signal, don't you think it would have happened then?
It also seems strange to me that noise or anything else in this signal could alias into two lines like that without any points between them.
So, you need to learn more about aliasing.
Look at texture mapping in 3D graphics where the same problem occurs. When an object is far away then one pixel on screen might cover hundreds (or even thousands!) of pixels in the texture map. There's no way to downsample/filter it in real time.
nb. In 3D graphics they solve it by using precomputed mipmaps for the textures but an oscilloscope can't do that.When I downsampled with Matlab, I did it in about the crudest way possible by just throwing samples away without any low-pass filtering. If downsampling were going to cause such aliasing with this signal, don't you think it would have happened then?
Nope.
What you see depends on the ratio of the high frequency components of the signal to the samples you kept.
In the post I linked to there's 4 different views of the same data, all views are completely different. The difference you see on screen comes purely from the selection of which points were thrown away and which were kept.
It's nothing to do with peak mode or anything else, that's a complete red herring. It's 100% due to the limits of the downsampling filter and it can't be fixed by a firmware update.
(more correctly: it can't be fixed without reducing the screen update rate to something unacceptable).
https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145 (https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145)
I downsampled by a factor of 2,000 to go from 2.4 million raw sample points to 1,200 like the oscilloscope presumably did to get the trace data but didn't get the aliasing. Would I perhaps see similar aliasing if I tried other downsampling ratios or different sampling phases?
How do you reduce 2000 points of data to a single point on screen?
I don't know what method the DS1054Z uses, sorry. I'm sure it's done in hardware though so expect it to be a compromise.
I downsampled by a factor of 2,000 to go from 2.4 million raw sample points to 1,200 like the oscilloscope presumably did to get the trace data but didn't get the aliasing. Would I perhaps see similar aliasing if I tried other downsampling ratios or different sampling phases?
You just described the problem perfectly: How do you reduce 2000 points of data to a single point on screen?
I don't know what method the DS1054Z uses, sorry. I'm sure it's done in hardware though so expect it to be a compromise. :popcorn:
(nb. The DS1054Z only displays 600 points on screen so there's a secondary 2:1 reduction somewhere...)
Anyway, this is just guessing. But I think it likely that, within the limitations of the existing DS1000Z hardware, there would be a better way to down-sample and display the signals at slow time bases.
Just don't use dot mode, problem solved! :-+
(why would you use dots to look at a signal like that?)
Or ... use dots but turn on averaging - also solved!
I would like to know what you guys think an analog CRT scope would show in these circumstances...
Namely, a slow time sweep and fast pulses... For instance, 10 ms/div and feed it 1 MHz signal....
Tadaaaa...
Anyway, this is just guessing. But I think it likely that, within the limitations of the existing DS1000Z hardware, there would be a better way to down-sample and display the signals at slow time bases.
Just don't use dot mode, problem solved! :-+
(why would you use dots to look at a signal like that?)
Or ... use dots but turn on averaging - also solved!
I would like to know what you guys think an analog CRT scope would show in these circumstances...
Namely, a slow time sweep and fast pulses... For instance, 10 ms/div and feed it 1 MHz signal....
Tadaaaa...
Read again, please, and go one page further back. The real discussion of the artefacts starts around post #237 or so. The demo signal is simply the 1 kHz square wave from the calibration output. And the problem is that the parts of the trace where the signal is stable appear either split in two (dot mode) or artificially widened, with inflated apparent noise (line mode).
The short pulses at large intervals, shown further down in the thread, only serve to show that peak mode actually works (and only works when enabled).
Anyway, this is just guessing. But I think it likely that, within the limitations of the existing DS1000Z hardware, there would be a better way to down-sample and display the signals at slow time bases.
Just don't use dot mode, problem solved! :-+
(why would you use dots to look at a signal like that?)
Or ... use dots but turn on averaging - also solved!
I just think it would be desirable for Rigol to include a fix in their next firmware update if this issue is fixable in firmware without any compromises. That might not be possible, as you've pointed out, but I don't think any of us knows for sure what's causing this effect. It would be nice to at least hear something from Rigol since they know exactly how the oscilloscope processes data.
Either way, I'm still satisfied overall with my DS1054Z. It's a fantastic oscilloscope for the price.
As for what you are saying, I made my comment on that before...
He needs to self cal scope first, and than not use software magnified input ranges..
Also, DS1000Z IS sensitive to external RF fields... It might as well be that he REALLY HAS high frequency interference injected... In that case noise is not artificially inflated....
Or his scope might really have some issue....
I am specifically commenting Reply #254.....
Put it in vector mode and it looks exactly as it should....
Well, it's most obvious in dot mode -- but the line mode suffers from an inflated noise (trace width) if it plots only the outliers and connects them with lines.
Averaging is fine if you want to look at a stationary signal, but pretty useless when looking for fluctuations or spurious events. So you will have to live with the inflated noise when you are after that. (And at the same time have to measure at the slower time bases, to be fair.)
I'm still happy with my DS1054Z; but it would be a pity if Rigol make the noise performance look worse than it is, just by careless digital processing.
I am specifically commenting Reply #254.....
Me too, and specifically on the first two screenshots in that post. ;)
As to the third image in #254, I agree that it is not a meaningful measurement setting. But it can serve as another test case for the assumed "unwanted peak detection": I would indeed expect to see the occasional dot inbetween those two extreme lines. (While the sine signal spends most of its time near the extrema, the transition time between them is certainly not negligible, and hence the probability to "catch" a sample inbetween should not be negligible either.)
Nah, they all do it (I think).
It's not noise, it's a high frequency sine wave. See my post in the other thread, the signal is very clear at maximum zoom:
https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145 (https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145)
I publish my attempt to correct some errors on DS1000Z firmware (2017).
Tempting. Somebody needs to test this. Where did you come from?
i don't change version, 00.04.04.03.02
Where did you come from?The city is listed in the profile. :)
can go back and forth between the regular firmware and your modfied version?Yes.
Actually, downgrde is also not a problem, it's enough to write a special signature on a flash drive.
Where did you come from?The city is listed in the profile. :)
I have no relationship to Rigol.
Actually, downgrde is also not a problem, it's enough to write a special signature on a flash drive.
This should definitely have its own thread with more info. People have been trying to do that for ages.
Keep the first post in the thread up to date with the latest version, installation info, etc.
I publish my attempt to correct some errors on DS1000Z firmware (2017).
The archive in this message contains the modified firmware.
In the next post is attached an archive with a library and tools for
make&load plugins. Two simple examples are included.
changes on firmware:
1) Ext port 6000 funcs - read/write/call (see rigolif programm)
2) pluses -> pulses
3) rnage -> range (decoder:conf:range)
4) Changed USB Buffer Size (40->200) - test, please. I don't use USB IF
5) Disabled set bandwidth to license maximum on start (BW20 fix)
directory in plugin archive:
rigolif sample programm for 6000/UDP
add_info mixed info
libb plugin library
patch port 6000/UDP patch sources
plugin_simple sample of simple plugin (single LED cycle and exit)
plugin_thread plugin with thread (permanent LED cycle)
!!!WARNING!!!
This is Beta version. Tested only in my Rigol
AS IS, AS IS, AS IS.....
P.S. The archive is divided into two parts, because I can not attach a file more than a megabyte.
I publish my attempt to correct some errors on DS1000Z firmware (2017).
The archive in this message contains the modified firmware.
In the next post is attached an archive with a library and tools for
make&load plugins. Two simple examples are included.
changes on firmware:
1) Ext port 6000 funcs - read/write/call (see rigolif programm)
2) pluses -> pulses
3) rnage -> range (decoder:conf:range)
4) Changed USB Buffer Size (40->200) - test, please. I don't use USB IF
5) Disabled set bandwidth to license maximum on start (BW20 fix)
directory in plugin archive:
rigolif sample programm for 6000/UDP
add_info mixed info
libb plugin library
patch port 6000/UDP patch sources
plugin_simple sample of simple plugin (single LED cycle and exit)
plugin_thread plugin with thread (permanent LED cycle)
!!!WARNING!!!
This is Beta version. Tested only in my Rigol
AS IS, AS IS, AS IS.....
P.S. The archive is divided into two parts, because I can not attach a file more than a megabyte.
Thank you very much, this is quite a nice surprise.
Can you please upload again the attachments DS1000ZUpdate.zip and DS1000ZUpdate.01.zip?
They can not be opened as zip archives. I tried to unzip them in both Win10 and Debian8. Also concatenate then unzip in Deb8, still doesn't work.
I agree, new thread, or added to the other one (whatever it was called, the FW hacking rewrite uber thread that has been going on since the beginning of time...)
I've been able to extract the GEL file with the unZIP tool integrated with "Total Commander". Flashed it and found it to be "very beta"...
python-3.6.1-embed-amd64\python.exe" unpack.py DS1000ZUpdate.GEL
instrument series: DS1000Z
firmware version: 00.04.04.03.02
updateType: 0x00070000
found 10 files
{'filename': '/sys/SparrowAPP.out', 'type': 1, 'start': 640, 'length': 1066438, 'crc': 1846034540, 'unknown': (0, 0, 0)}
{'filename': '/sys/SparrowFPGA.hex', 'type': 5, 'start': 1067078, 'length': 803698, 'crc': 1737700535, 'unknown': (0, 0, 0)}
{'filename': '/sys/SparrowDGFPGA.hex', 'type': 6, 'start': 1870776, 'length': 290564, 'crc': 3841850537, 'unknown': (0, 0, 0)}
{'filename': '/sys/logo.hex', 'type': 10, 'start': 2161340, 'length': 768024, 'crc': 1763548407, 'unknown': (0, 0, 0)}
{'filename': '/sys/guiResData.hex', 'type': 12, 'start': 2929364, 'length': 748076, 'crc': 4026022475, 'unknown': (0, 0, 0)}
{'filename': '/sys/guiPicData.hex', 'type': 17, 'start': 3677440, 'length': 124855, 'crc': 2240924515, 'unknown': (0, 0, 0)}
{'filename': '/sys/SparrowConfig.hex', 'type': 16, 'start': 3802295, 'length': 768024, 'crc': 2145407491, 'unknown': (0, 0, 0)}
{'filename': '/sys/SparrowWaveTable.hex', 'type': 11, 'start': 4570319, 'length': 8424, 'crc': 2957269910, 'unknown': (0, 0, 0)}
{'filename': '/sys/SparrowCalFile.hex', 'type': 15, 'start': 4578743, 'length': 144028, 'crc': 4225940020, 'unknown': (0, 0, 0)}
{'filename': '', 'type': 50, 'start': 4722771, 'length': 280, 'crc': 1792089006, 'unknown': (0, 0, 0)}
writing /header (640 bytes)
writing /sys/SparrowAPP.out.header (24 bytes)
writing /sys/SparrowAPP.out (1066414 bytes)
writing /sys/SparrowAPP.out.decompressed (3934200 bytes)
writing /sys/SparrowFPGA.hex.header (24 bytes)
writing /sys/SparrowFPGA.hex (803674 bytes)
writing /sys/SparrowDGFPGA.hex.header (24 bytes)
writing /sys/SparrowDGFPGA.hex (290540 bytes)
writing /sys/logo.hex.header (24 bytes)
writing /sys/logo.hex (768000 bytes)
writing /sys/guiResData.hex.header (24 bytes)
writing /sys/guiResData.hex (748052 bytes)
writing /sys/guiPicData.hex.header (24 bytes)
writing /sys/guiPicData.hex (124831 bytes)
writing /sys/guiPicData.hex.decompressed (4031460 bytes)
writing /sys/SparrowConfig.hex.header (24 bytes)
writing /sys/SparrowConfig.hex (768000 bytes)
writing /sys/SparrowWaveTable.hex.header (24 bytes)
writing /sys/SparrowWaveTable.hex (8400 bytes)
writing /sys/SparrowCalFile.hex.header (24 bytes)
writing /sys/SparrowCalFile.hex (144004 bytes)
Corrupt input data
Traceback (most recent call last):
File "unpack.py", line 160, in checkCreateDir
os.makedirs(os.path.dirname(filename))
File "os.py", line 220, in makedirs
FileNotFoundError: [WinError 3] The system cannot find the path specified: ''
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "unpack.py", line 173, in <module>
main()
File "unpack.py", line 109, in main
save(h["filename"],bFile)
File "unpack.py", line 166, in save
checkCreateDir(prefix + filename) #create missing directories
File "unpack.py", line 162, in checkCreateDir
if exc.errno != errno.EEXIST:
NameError: name 'errno' is not definedPallette got messed up so the screen looks somewhat funny now, see attached screenshot.
Probably in my converter pic <-> bmp (16bit / 24bit) is not quite correctly converted.
You could do an update of only the correction of the word pluses by pulses, which is the only thing that bothers me ;) ;)
Simply rename the .01.zip to .z01 and open the .zip with any packer (WinRAR, 7zip, ...).Yessss, that does the trick. Thanks!
When you turn to 200mV (and even lower), the trace will appear on the screen again (but it should have been close to the floor in your room!)
I can not reproduce that on my scope.settings.
RoGeorge, you get the problem when you set to 200mV, the trace will suddenly appear again.
Offset Range:https://www.batronix.com/pdf/Rigol/UserGuide/DS1000Z_UserGuide_EN.pdf (https://www.batronix.com/pdf/Rigol/UserGuide/DS1000Z_UserGuide_EN.pdf,), page 17-2
1 mV/div to 499 mV/div: ± 2 V
500 mV/div to 10 V/div: ± 100 V
Did you Set VerticalRef = Center before doing the test?No, but now: Normal action: left and right cursor changed if out of range. That ist absolut normal.
The 1GSa/s, or the full 24Mpts memory, are possible to select only for CH2 alone (or for no channels at all ;D ).
If CH1 alone is selected, the maximum sample rate is 500MSa/s, and the maximum memory is 12 million samples. My current SW version is 00.04.04.03.02
Is this a known bug, or I am missing something?
If it's a bug, is it still present in the latest SW v00.04.04.03.05, please?
It's not a bug. I can select 1GSa/s or 24Mpts with whatever channel I select (as long as there's only one channel active ofcourse).
If you select any single channel, no inputs, and with triggering set for that same channel you get the full 1GSa/s and 24M Mem depth available.
import visa
import numpy as np
import sys
import re
print(sys.version)
print("visa", visa.__version__)
#visa.log_to_screen()
GPIB = visa.ResourceManager()
GPIB_Resources = GPIB.list_resources()
for resource in GPIB.list_resources(): print(resource) # list instruments -- selects the 1054Z in the next line
DS1054Z = GPIB.open_resource([_ for _ in GPIB_Resources if re.search('^USB.*:DS.*INSTR$', _)][0])
print("DS1054Z:", DS1054Z.query("*IDN?"))
DS1054Z.write(":WAV:FORMAT BYTE;:WAV:MODE RAW;:SYSTEM:BEEPER OFF")
DS1054Z.write(":ACQUIRE:MDEPTH 30000")
DS1054Z.write(":STOP")
err=0
#for NPOINTS in range(20010,30100):
for NPOINTS in range(8200,30100):# fails at 8244 and increments of 64 beyond
print(NPOINTS, end='')
err+=1
DS1054Z.write(":WAV:START 1;:WAV:STOP %i;:WAV:DATA?" % NPOINTS)
print(">",DS1054Z.read_bytes(11),"<", end='') # Contains '#90000ddddd'
try:
CURVE1 = np.frombuffer(DS1054Z.read_bytes(NPOINTS), dtype='b')
except:
print("\nError at", NPOINTS, " after ", err)
err=0
print(len(CURVE1), "chars")
DS1054Z.read_bytes(1) # trailing '\n'
8241> b'#9000008241' <8241 chars
8242> b'#9000008242' <8242 chars
8243> b'#9000008243' <8243 chars
8244> b'#9000008244' <
Error at 8244 after 8243
8243 chars
8245> b'#9000008245' <8245 chars
8246> b'#9000008246' <8246 chars
8247> b'#9000008247' <8247 charsError at 8244 after 8243
Error at 8308 after 64
Error at 8372 after 64
Error at 8436 after 64
Error at 8500 after 64
Error at 8564 after 64
Error at 8628 after 64
Error at 8756 after 128
Error at 8820 after 64
Error at 8884 after 64
Error at 8948 after 64
Error at 9012 after 64
Error at 9076 after 64
Error at 9140 after 64
Error at 9268 after 128
Error at 9332 after 64
Error at 9396 after 64I have a new bug (I posted this as a separate topic earlier; I'll try to delete that post):
I am trying to read binary waveforms from my 1054Z using pyvisa over USB. Using sockets over LAN (not pyvisa) works. I have a problem when reading certain specific lengths of data from the instrument -- specifically lengths of 8244 and increments of 64 beyond; using MDEPTH of 30000. I don't know if the issue is in the instrument or pyvisa. I have filed a ticket at https://github.com/pyvisa/pyvisa/issues/354 also. I have tried pyvisa 1.9.1, 1.9.0 & 1.8. My 1054Z is unlocked to 1104Z. This is the *IDN? RIGOL TECHNOLOGIES,DS1104Z,DS1ZA20100****,00.04.04.SP3
It looks like you're trying to use a USB connection?
I don't know if it will have any effect. But, you could try changing the OS low level receive buffer size. The default size for a LAN connection would be different than a USB connection.
GPIB = visa.ResourceManager()
DS1054Z = GPIB.open_resource('TCPIP0::10.1.0.54::5555::INSTR')
print("DS1054Z:", DS1054Z.query("*IDN?"))DS1104Z-S, Software 04.04.SP4
Since the firmware update to 04.04.SP4, I cannot read waveform data with more than 10 MB via SCPI command.
The 6 MB work, the 12 MB data are aborted at 10 MB. The oscilloscope will then stop sending data. But you can read in data afterwards without any problems. The oscilloscope did not get stuck.
It worked with the previous software 04.04.SP3.
Can anyone confirm that?
Peter
Can anyone confirm this error?
Can anyone confirm that?
DSRemote works with the LAN connection, very fast even. The USB connection doesn't work for me.
Unfortunately, there's a bug in the firmware of the scope that causes connection problems
when your computer uses an xHCI host controller (USBv3.x).
Computers with an EHCI host controller (USBv2) will work fine.
Rigol has been informed about this firmware bug. They acknowledged the bug and said
they have no plans to fix it.
So, if DSRemote generates the error message "Can not read from device", check the following.
Open a terminal and enter
echo "*IDN?" > /dev/usbtmc0; cat /dev/usbtmc0
If it response like this:
RIGOL TECHNOLOGIES,DS1104Z,DS1ZA17040xxxx,00.04.04.SP3
cat: /dev/usbtmc0: Connection timed out
the connection is ok. If not, there's a problem. Check the following:
dmesg | grep -i xhci | less
This will show you if your computer has an xhci host controller.
dmesg | grep -i ehci | less
This will show you if your computer has an ehci host controller.
Some computers have both. In that case use an USBv2 port, not an USBv3.x port (blue).
p.s.: not all xHCI host controllers causes connection problems. It depends on the brand and
model of the chip on the motherboard of your computer.
The cause is that Rigol presents itself as an USB 2.0 High Speed device but it uses a packetsize
of 64 bytes. The USB 2.0 protocol specification dictates that highspeed connections MUST use a
packetsize of 512 bytes. Now, some USB host controller chips are "forgiving" and accept the smaller
packetsize. Some USB host controllers are less forgiving and don't accept the too small packets.
You can see the packetsize protocol violation of Rigol when you type dmesg in a terminal after you
connected the scope:Code: [Select]usb 3-2: new high-speed USB device number 4 using ehci-pci
usb 3-2: config 1 interface 0 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
usb 3-2: config 1 interface 0 altsetting 0 bulk endpoint 0x3 has invalid maxpacket 64
usb 3-2: New USB device found, idVendor=1ab1, idProduct=04ce
usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-2: Product: DS1000Z Series
usb 3-2: Manufacturer: Rigol Technologies.
usb 3-2: SerialNumber: DS1ZA17040xxxx
usbcore: registered new interface driver usbtmc
SCPI commands takes time to execute. Pushing too many commands at once, or too many one by one but too fast, might not work.
There are ready/busy and/or OK/error SCPI indicators, as words or as bits, that tells the status of the instrument. The status indicators will tell whether the instrument is ready or not to process the next SCPI command(s).
I wrote the USB-TMC protocol in my program myself and tested it against several devices. I also programmed it for a PIC18F, so that I can test everything as good as possible.
The Rigol DS1000Z does not stick to the standard. You can query status bits, but their value is not updated, or not supported at all. The status byte in interrupt transfer is always zero. The MAV bit is ignored and so on.
And that with all my five Rigol devices.
Peter
v00.04.05.01.00 2021/06/01
- Modify the vertical Display.??
-Modification of math problem ??
What did they modify? someone explain it to me! |O
I read the list from version 00.04.05.02.00 onwards, and it scares me to update, it corrects a lot of errors, but what it can create scares me more >:D, for something they still did not correct the 24bit deep, they do not want to think about what would happen !! :-//
I read the list from version 00.04.05.02.00 onwards, and it scares me to update, it corrects a lot of errors, but what it can create scares me more >:D, for something they still did not correct the 24bit deep, they do not want to think about what would happen !! :-//
I have loaded and tested the firmware, from calibration, to licenses (all active) to signal shapes compared with previously saved values, to measurement. I can tell that there are no visible regressions.
Cheers,
DC1MC
Friend, I installed the firmware, it was installed correctly, the yellow trace and the others were left above the marker, and it does not allow to calibrate, it gives an error at 5 minutes, how degraded?
...
Friend, I installed the firmware, it was installed correctly, the yellow trace and the others were left above the marker, and it does not allow to calibrate, it gives an error at 5 minutes, how degraded?
On the sixth try I calibrate, I really don't know what happened to the baby :(, gracias DC1MC :-+No hay de qué.
:-//
Don’t these have a Exclusive FFT mode that doesn’t show the source waveform ?
In fact, the FFT functionality in Rigol DS1054Z is unusable in practice. It works, but it's too cumbersome to operate the settings, too low resolution, and too slow to make any use of it, other than maybe a didactic demonstration.It could be better but I'm trying to be positive. Some niche areas, e.g. education..
In fact, the FFT functionality in Rigol DS1054Z is unusable in practice. It works, but it's too cumbersome to operate the settings, too low resolution, and too slow to make any use of it, other than maybe a didactic demonstration.
It does work, but it takes a LOT of fiddling with the parameters.I was of the same opinion, initially. But now I've to say that actually it's an efficient and elegant UI design, for given environmental constraints. I can't propose anything better (maybe the now popular touch screen technology provides more opportunities, but its advantages are offset by a scratched screen surface, dirty with fingerprints. Not everybody likes that). It's something like a scientific calculator, which uses stack-oriented input notation. Clumsy and inconvenient, but only to those without the idea. To all others, it's very convenient and super efficient.
According to me SW version 00.04.05.02.03 has not been published (yet).That's why I'd asked the local Rigol rep about the release notes. But he also has no information
According to me SW version 00.04.05.02.03 has not been published (yet).That's why I'd asked the local Rigol rep about the release notes. But he also has no information
Mine is one version behind, 00.04.05.02.02, and it doesn't have any icon on the 6th place. First 4 icons are the same, as in your pics, the 5th is called 'Variance', the last place is empty.Interesting.
What does the help function says about the 6th icon called "3", if you press 'Help' then '3'?It gives the help for AC.Vrms.