Rigol DS1000Z series buglist continued (latest: 00.04.04.04.03, 2019-05-30) - Page 1
Forum section: electronics / testgear

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 12, 2017, 08:53:13 am
content: DisclaimerThis 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 toTHIS THREAD(please read the first post to get some overview, thanks to the OP rolycat).DisclaimerBecause theoriginal posting from kwasscan 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 VersionPressingMENU,MENU,FORCE,MENU, Utility, (soft button)System, (soft button)System Infoquickly one after the other will get you there.Direct download link to latest release:V.00.04.04.04.03Direct download link to last release that also contained boot version update file:V.00.04.00.00.00Checkthis linkfor 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.11The following bugs seem to be fixed in the latest firmware:Pluses spelling fixedLogin via LAN interface is now working, usr: rigollan pw: 111111Centering of all traces now spot on after self cal. procedureFont size selection is now kept on power cycle just as other settingsSelect item menu works on all font sizesFFT 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 unitWaveform shift resolved (old buglist item 9)RAW mode of data acquisition over USB now returns sane dataRecommended update procedureQuote from: BravoV on April 19, 2017, 04:28:07 pmBugs 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. Seethis post by Kareland 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.1Pass: Board Version: 0.1.1, Boot Version: 0.0.1.3, Firmware Version: 0.2.3.11, CPLD Version: 1.1Pass: Board Version: 0.1.1, Boot Version: 0.0.1.2, Firmware Version: 0.2.3.11, CPLD Version: 1.1Fail: Board Version: 0.1.1, Boot Version: 0.0.1.2, Firmware Version: 0.2.3.11, CPLD Version: 1.1Fail: Board Version: 0.1.1, Boot Version: 0.0.1.2, Firmware Version: 0.2.3.11, CPLD Version: 2.2Pass: Board Version: 0.1.1, Boot Version: 0.0.1.1, Firmware Version: 0.2.3.11, CPLD Version: 1.1Remote 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 screenshotsRemote control via LAN / telnet commands misbehavesQuerying :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 BugOscilloscope won't respond to any other SCPI command, and it won't accept new TCP connections until the next power cycle.Please seedetailed description here.Release notes supplied by RigolCode:[Supported Model] All the MSO/DS1000Z Series Digital Oscilloscopes[Latest Revision Date] 2015/05/30[Updated Contents]---------------------------------v00.04.04.04.03 2019/05/30- Fixed the wave error when STOP and changing timebasev00.04.04.04.02 2019/02/26- Add new encoder driversv00.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 displayv00.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 Filterv00.04.04.01.01 2016/09/14- Supported the multi-inteface of LXI- Fixed bugs about Measurev00.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 Measurev00.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 operationv00.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 formatv00.04.03.00.01 2015/05/05- Added DS1104Z Plus and DS1074Z Plus- Fixed pass/fail test- Fixed FFT operationv00.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 couplingv00.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 decodingv00.04.01.02.00 2014/07/28- Added traditional Chinese language for the measurement menu- Optimized the event table display- Pressed and held  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 functionv00.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 functionv00.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 formatv00.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 scalev00.02.00.01.00 2013/09/02- Optimized the brightness of waveform display- Optimized the waiting time for the slow sweep modev00.01.00.16.09 2013/08/14- Supported the remote access to memory datav00.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 sweepv00.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 operationv00.01.00.03.00 2013/05/21- Fixed bugs for the expiration of the trial optionsv00.01.00.02.00 2013/05/19- Added the display interface of the installed optionv00.01.00.00.05 2013/05/19- Released the first editionPlease 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,FrederikLatest changesUpdated firmware link to latest 00.04.04.04.03Added link to Pluses corrected versionStarted updating the post for FW 00.04.04.03.05Minor maintenance, release notes fixed / formattingAdded ADC gain / display mismatch bugAdded SCPI command bugSmall follow up on calibration fail after updateDisclaimer regarding general discussion threadAdded remote command frame size bugAdded more information on USB packet bugAppended PDF file with memory wipe instructionsAdded recommended update procedureUpdated info on calibration failAppended device to freeze bug (#5) tableAdded link and info on boot versionTypos and formattingAdded download link to latest software fileAdded saving to USB takes incredibly long bugAdded possible bricking bugReformated buglist as ordered list (as proposed by metrologist)

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 12, 2017, 08:56:47 am
content: Quote from: kwass on January 11, 2015, 12:48:37 am

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 12, 2017, 09:27:22 am
content: I could not reproduce the waveform shifting bug in the latest firmware.Please confirm.

author: BravoV
author_rank: Super Contributor
timestamp: April 12, 2017, 10:07:19 am
content: Subbed

author: Gabri74
author_rank: Regular Contributor
timestamp: April 12, 2017, 10:35:00 am
content: Quote from: frozenfrogz on April 12, 2017, 09:27:22 amConfirmed, bug seems goneSoftware Version: 00.04.04.03.02Board Version: 0.1.1Boot Version: 0.0.1.2Firmware Version: 0.2.3.11CPLD Version: 1.1

author: Karel
author_rank: Super Contributor
timestamp: April 12, 2017, 10:39:25 am
content: There's a bug missing in your list:https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg1178649/#msg1178649

author: Karel
author_rank: Super Contributor
timestamp: April 12, 2017, 10:41:35 am
content: Quote from: frozenfrogz on April 12, 2017, 08:53:13 amI tested it and it works fine. Please remove it from the list of bugs.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 12, 2017, 11:25:55 am
content: Done.And finally figured out how to escape BBcode to get 8) instead of*yay*Also: I found the language menu to hold a lot of languages now. As far as I remember it was only chinese and english before. Or am I mistaken?

author: Fungus
author_rank: Super Contributor
timestamp: April 12, 2017, 11:51:30 am
content: Quote from: frozenfrogz on April 12, 2017, 11:25:55 amYes.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

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 12, 2017, 12:09:30 pm
content: 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.

author: kcbrown
author_rank: Frequent Contributor
timestamp: April 12, 2017, 03:21:08 pm
content: Quote from: frozenfrogz on April 12, 2017, 08:53:13 amI'm able to consistently reproduce this with my unit with the current firmware.Software version: 00.04.04.03.02Board version: 0.1.1Boot version: 0.0.1.2Firmware Version: 0.2.3.11CPLD Version: 1.1

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 12, 2017, 03:27:20 pm
content: That is unfortunateThanks for testing and sharing.Added Pass/Fail info on bug list.

author: Fennec
author_rank: Regular Contributor
timestamp: April 12, 2017, 03:46:45 pm
content: Quote from: frozenfrogz on April 12, 2017, 08:56:47 amWorks.But:PNG screenshot with thumb-drive and printer button takes2 1/2 MINUTES !Cannel Mark out of Range. So the scope measures2.8Vppbut the signal is3Vpp. (checked with 2 other scopes too.) Fluke 8842A =>1,492VpWith 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.

author: kcbrown
author_rank: Frequent Contributor
timestamp: April 12, 2017, 03:53:15 pm
content: Quote from: Fennec on April 12, 2017, 03:46:45 pmWhat 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.

author: Fennec
author_rank: Regular Contributor
timestamp: April 12, 2017, 03:56:43 pm
content: Quote from: kcbrown on April 12, 2017, 03:53:15 pmYepp, but most times it wouldn't work. I have to do a full reset, with the soft button. Maybe 8 of 10 times.

author: 2N3055
author_rank: Super Contributor
timestamp: April 12, 2017, 03:57:18 pm
content: Quote from: frozenfrogz on April 12, 2017, 08:53:13 amCannot reproduce. Tried several times, different zoom, different persistence...Scope detail info attached:

author: kcbrown
author_rank: Frequent Contributor
timestamp: April 12, 2017, 03:58:14 pm
content: Quote from: Fennec on April 12, 2017, 03:56:43 pmHmm...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.

author: 2N3055
author_rank: Super Contributor
timestamp: April 12, 2017, 04:07:53 pm
content: Quote from: Fennec on April 12, 2017, 03:46:45 pmJust 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.

author: bitseeker
author_rank: Super Contributor
timestamp: April 12, 2017, 06:23:09 pm
content: Thanks for creating the new thread, frozenfrogz. Following.

author: metrologist
author_rank: Super Contributor
timestamp: April 12, 2017, 07:20:52 pm
content: 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.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 12, 2017, 08:12:09 pm
content: Quote from: metrologist on April 12, 2017, 07:20:52 pmTried to do some proper formatting, could not find a BBcode option to do an indent / tab stop that seems to work here, so for the moment it’s lists within lists@Fennec:Please provide your long system info, thanksAlso, 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

author: Fennec
author_rank: Regular Contributor
timestamp: April 12, 2017, 08:41:48 pm
content: Quote from: frozenfrogz on April 12, 2017, 08:12:09 pmI post nothing. Since my lastRESETmy scope is complete ded. It boots up with this screen.

author: ankerwolf
author_rank: Regular Contributor
timestamp: April 12, 2017, 08:42:06 pm
content: Hello,I made update now on my DS1054Z (with Options now DS1104Z):SW: 00.04.04.03.02 = 00.04.04.SP3Board: 0.1.1Boot: 0.0.1.3FW: 0.2.3.11CPLD: 1.1Warm up >30'Update ok > Power off > Power on1. SelfCal (I seem to recall there were two more SoftButtons: [... LF ...] and [... Output ...] ) >>>FAILED!!!Same screen as Fennec !!!> Power off > Power on2. SelfCal (now only two SoftButtons) >ok.LG Wolf

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 12, 2017, 08:48:07 pm
content: Quote from: Fennec on April 12, 2017, 08:41:48 pmDamn.Did you try deep cycle / alternative reset?PDF from Rigol on alternate resetAlso there is a memory clearing procedure:PDF from Rigol on sanitizing memoryGood luck!

author: Fennec
author_rank: Regular Contributor
timestamp: April 12, 2017, 09:04:35 pm
content: 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.

author: bitseeker
author_rank: Super Contributor
timestamp: April 13, 2017, 04:17:58 am
content: Quote from: Fennec on April 12, 2017, 09:04:35 pmYes, there are some minuses.Maybe if I sell some more of my stuff I can get a Keysight. But for now the Rigol does what I need it to. Hope you get yours running again.

author: ebastler
author_rank: Super Contributor
timestamp: April 13, 2017, 05:50:04 am
content: Quote from: frozenfrogz on April 12, 2017, 08:48:07 pmDo we know whether this applies to the DS1000Z series as well? The tech note only refers to the DS2000 series and up.Quote from: frozenfrogz on April 12, 2017, 08:48:07 pmThe 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?

author: alsetalokin4017
author_rank: Super Contributor
timestamp: April 13, 2017, 06:10:53 am
content: Quote from: ebastler on April 13, 2017, 05:50:04 amYes, 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.QuoteI 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.

author: Fennec
author_rank: Regular Contributor
timestamp: April 13, 2017, 12:42:03 pm
content: 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.Quote from: bitseeker on April 13, 2017, 04:17:58 amIt is NOT the scope, itsRIGOL!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.TheRIGOL Serviceis 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 ?!

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 13, 2017, 12:47:56 pm
content: On the positive side: I am glad you could revive your scope via reinstalling the firmware again.

author: Fennec
author_rank: Regular Contributor
timestamp: April 13, 2017, 01:08:07 pm
content: Quote from: frozenfrogz on April 13, 2017, 12:47:56 pmYepp, hope the new owner is happy with the scope. I don't like use it anymore.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 13, 2017, 01:18:17 pm
content: 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 youFYI: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 knowWill keep you posted.

author: Fennec
author_rank: Regular Contributor
timestamp: April 13, 2017, 01:57:04 pm
content: There's /was a RIGOL contributor here in the forum.

author: Fungus
author_rank: Super Contributor
timestamp: April 13, 2017, 03:38:20 pm
content: Quote from: Fennec on April 13, 2017, 12:42:03 pmUmmmm... 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 toanydevice with Flash memory.Quote from: Fennec on April 13, 2017, 12:42:03 pmHave you looked at the price of Flukes?

author: Fennec
author_rank: Regular Contributor
timestamp: April 13, 2017, 04:22:52 pm
content: Quote from: Fungus on April 13, 2017, 03:38:20 pmHow does it works, if I can not press any key ?Quote from: Fungus on April 13, 2017, 03:38:20 pmI 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"

author: kcbrown
author_rank: Frequent Contributor
timestamp: April 13, 2017, 04:25:46 pm
content: Quote from: Fennec on April 13, 2017, 04:09:18 pmYour 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.QuoteEverything, 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,somethingis more expensive because of it.There ain't no such thing as a free lunch.

author: Lightages
author_rank: Unknown
timestamp: April 13, 2017, 04:31:41 pm
content: 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.

author: Fungus
author_rank: Super Contributor
timestamp: April 13, 2017, 04:42:11 pm
content: Quote from: Lightages on April 13, 2017, 04:31:41 pmMy messages removed.

author: ankerwolf
author_rank: Regular Contributor
timestamp: April 13, 2017, 09:59:04 pm
content: HyFennec,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 okWhy all these violent words?LG Wolf

author: ankerwolf
author_rank: Regular Contributor
timestamp: April 13, 2017, 10:48:34 pm
content: Hello Fennec,Quote from: Fennec on April 13, 2017, 10:35:58 pmMy native language is german. Therfore my valediction is also in german: LG means "Liebe Grüße". Or if you want: Kind regards

author: Fennec
author_rank: Regular Contributor
timestamp: April 13, 2017, 10:49:19 pm
content: Quote from: ankerwolf on April 13, 2017, 09:59:04 pmWhy you didn't read mine ?Quote from: Fennec on April 12, 2017, 08:41:48 pmQuote from: Fennec on April 12, 2017, 09:04:35 pmQuote from: Fennec on April 13, 2017, 12:42:03 pmQuote from: ankerwolf on April 13, 2017, 09:59:04 pmWhat's LG ?

author: Fennec
author_rank: Regular Contributor
timestamp: April 13, 2017, 10:50:42 pm
content: Quote from: ankerwolf on April 13, 2017, 10:48:34 pmThxLG

author: rsjsouza
author_rank: Super Contributor
timestamp: April 13, 2017, 10:59:45 pm
content: Quote from: Fennec on April 12, 2017, 03:46:45 pmOne 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?

author: Fennec
author_rank: Regular Contributor
timestamp: April 13, 2017, 11:34:40 pm
content: 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 64GBBut thx.The100is cracked

author: ankerwolf
author_rank: Regular Contributor
timestamp: April 13, 2017, 11:45:57 pm
content: Hello,Quote from: rsjsouza on April 13, 2017, 10:59:45 pmI'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 ~4secBUT:Another bootable 2GB FAT32 USB-Stick: ... not a DOS Disk ...Another bootable 16GB NTFS USB-Stick: Saving failed!...LG Wolf

author: Fennec
author_rank: Regular Contributor
timestamp: April 13, 2017, 11:59:54 pm
content: 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.

author: ProBang2
author_rank: Frequent Contributor
timestamp: April 14, 2017, 05:08:21 am
content: Quote from: Fennec on April 13, 2017, 11:34:40 pmThat is probably the main problem. Even with the failed first update (flashing error).There is (well hidden) on page 16-2 under point 8. (3) in theDS 1054Z Manualthis text:"Make sure whether the capacity of the USB storage device is too large. It isrecommended that the capacity of the USB storage device being used withthis oscilloscope is no larger than8 GBytes."And it gets still much worse. In this description of the"DS1000Z Firmware Upgrade Procedure"they recommend this:"The USB stick must beFAT32format. If the device is not recognized, try reformatting oranother USB memory stick. We also recommend minimizing the number of folders, files,and programs on the stick. Drives less than4GBin total volume are also recommended."What should I say? My 8 GB USB stick, FAT32, worked and still works fine...

author: Fungus
author_rank: Super Contributor
timestamp: April 14, 2017, 10:12:46 am
content: Quote from: ProBang2 on April 14, 2017, 05:08:21 amIf it can handle FAT32 then I don't see why the drive size would make any difference at all.Quote from: rsjsouza on April 13, 2017, 10:59:45 pmWas 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.FAT16FAT32 4Gb partitionFAT32 8Gb partitionI'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.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 14, 2017, 10:24:18 am
content: Quote from: Fungus on April 14, 2017, 10:12:46 amActually it does and there is no problem at all writing to:USB Stick CNMemory "Spaceloop"PCI Device ID: 0x268cPCI Revision ID: 0x0009PCI Vendor ID: 0x808632Gb, FAT32 formatted via OS X Disk UtilityCan 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 2014There is no difference, if connected to LAN via DHCP. But AFAIK the DS1000Z does not have an RTC.

author: Fungus
author_rank: Super Contributor
timestamp: April 14, 2017, 10:39:40 am
content: Quote from: frozenfrogz on April 14, 2017, 10:24:18 amYep. 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.

author: rsjsouza
author_rank: Super Contributor
timestamp: April 14, 2017, 04:29:50 pm
content: Quote from: Fungus on April 14, 2017, 10:12:46 amI 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).

author: bitseeker
author_rank: Super Contributor
timestamp: April 14, 2017, 05:06:18 pm
content: Quote from: frozenfrogz on April 14, 2017, 10:24:18 amThere 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

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 14, 2017, 05:14:21 pm
content: 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-knowYesterday 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.

author: rstofer
author_rank: Super Contributor
timestamp: April 15, 2017, 02:17:27 pm
content: 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.

author: BravoV
author_rank: Super Contributor
timestamp: April 15, 2017, 02:26:35 pm
content: From Rigol manual :

author: bitseeker
author_rank: Super Contributor
timestamp: April 15, 2017, 04:52:36 pm
content: 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, whichdefaults to either 8KB or 16KB clusterson 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.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 15, 2017, 05:09:30 pm
content: Testing out different allocation unit sizes might be worth trying.BRB

author: BravoV
author_rank: Super Contributor
timestamp: April 15, 2017, 05:10:24 pm
content: Quote from: bitseeker on April 15, 2017, 04:52:36 pmThe 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 ?

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 15, 2017, 05:54:08 pm
content: 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 test2Gb / 32GbFAT1632 kbytePASS2Gb / 32GbFAT1664 kbytePASS2GbFAT32512 bytePASS2Gb / 32GbFAT321024 bytePASS2Gb / 32GbFAT322048 bytePASS2Gb / 32GbFAT324096 bytePASS2Gb / 32GbFAT328192 bytePASS2Gb / 32GbFAT3216 kbytePASS32GbFAT3232 kbytePASS32GbFAT3264 kbytePASS(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...

author: smithnerd
author_rank: Regular Contributor
timestamp: April 15, 2017, 05:56:28 pm
content: Quote from: BravoV on April 15, 2017, 05:10:24 pmThe 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

author: ankerwolf
author_rank: Regular Contributor
timestamp: April 18, 2017, 04:57:01 pm
content: 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.1LG Wolf

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 18, 2017, 05:03:56 pm
content: Thanks ankerwolfSooo.. Maybe we can pin this on boot version <0.1.3?(still needs a bigger dataset obviously)

author: Fungus
author_rank: Super Contributor
timestamp: April 19, 2017, 02:05:17 pm
content: Quote from: frozenfrogz on April 18, 2017, 05:03:56 pmNope. 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)

author: BravoV
author_rank: Super Contributor
timestamp: April 19, 2017, 04:01:17 pm
content: 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.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 19, 2017, 04:15:11 pm
content: Thanks BravoV,did you run self-calibration without problems?That is where issues seem to be sticking their head out.

author: BravoV
author_rank: Super Contributor
timestamp: April 19, 2017, 04:28:07 pm
content: Quote from: frozenfrogz on April 19, 2017, 04:15:11 pmYes, 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:The type of the file system is FAT32.Volume USB 8G created 4/19/2016 9:58 AMVolume Serial Number is 503E-347BWindows 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.

author: BravoV
author_rank: Super Contributor
timestamp: April 19, 2017, 04:51:07 pm
content: 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.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 19, 2017, 05:17:08 pm
content: Also: You got a hardware upgrade via USB implant as it seems xD

author: BravoV
author_rank: Super Contributor
timestamp: April 19, 2017, 05:19:36 pm
content: Quote from: frozenfrogz on April 19, 2017, 05:17:08 pmYep , what a sharp eyes you got there.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 19, 2017, 06:02:14 pm
content: 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

author: ebastler
author_rank: Super Contributor
timestamp: April 19, 2017, 06:10:34 pm
content: Quote from: BravoV on April 19, 2017, 05:19:36 pmI 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...

author: bitseeker
author_rank: Super Contributor
timestamp: April 19, 2017, 06:18:05 pm
content: Quote from: ebastler on April 19, 2017, 06:10:34 pmIn other words, it's as if a hardware upgrade was physically implanted via the USB interface. That'd be a nice feature, indeed.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 19, 2017, 06:20:09 pm
content: Quote from: ebastler on April 19, 2017, 06:10:34 pmUSB implant was actually a jokeThe 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 saidQuote from: bitseeker on April 19, 2017, 06:18:05 pm

author: BravoV
author_rank: Super Contributor
timestamp: April 19, 2017, 06:23:49 pm
content: LOL, although I haven't thoroughly test all, I guess that big jump 0.1.1 to 4.1.1 probably has something to do with the FG board, at least for service engineer. Since it doesn't show additional field for the FG's firmware version at the screen. Its a DS1104Z-S , not a hacked DS1054Z which doesn't have it.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 19, 2017, 07:28:42 pm
content: Quote from: Fungus on April 19, 2017, 02:05:17 pmMight be interesting if the freeze bug could then be pinned to only affecting boot version 0.0.1.2Hopefully we can resolve this

author: rbino
author_rank: Newbie
timestamp: April 21, 2017, 08:31:30 am
content: 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.02Board version: 0.1.1Boot version: 0.0.1.2Firmware version: 0.2.3.11CPLD version: 1.1Ican'treproduce the Zoom lock-up (issue number 5), so it's aPASSfor 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.

author: rbino
author_rank: Newbie
timestamp: April 21, 2017, 09:01:57 am
content: Ok, I've just finished the third self-calibration since the software upgrade and this time it didn't fail.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 21, 2017, 09:15:55 am
content: 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?

author: szpila
author_rank: Newbie
timestamp: April 21, 2017, 09:36:15 am
content: 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

author: Sredni
author_rank: Frequent Contributor
timestamp: April 21, 2017, 09:47:38 am
content: Quote from: BravoV on April 19, 2017, 04:01:17 pmHow 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.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 21, 2017, 09:50:01 am
content: 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?

author: rbino
author_rank: Newbie
timestamp: April 21, 2017, 11:42:13 am
content: Quote from: frozenfrogz on April 21, 2017, 09:15:55 amI 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.

author: ProBang2
author_rank: Frequent Contributor
timestamp: April 21, 2017, 02:01:25 pm
content: Quote from: rbino on April 21, 2017, 11:42:13 amThat´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    Then pressing the hard button 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 additionaltwo 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?

author: Gary.M
author_rank: Regular Contributor
timestamp: April 22, 2017, 06:31:14 am
content: Key elements of my scope are:Board version: 0.1.1Boot version: 0.0.1.2I'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?

author: BravoV
author_rank: Super Contributor
timestamp: April 22, 2017, 01:55:36 pm
content: Quote from: Sredni on April 21, 2017, 09:47:38 amLooks like lots of people are amazed by that.Its possible, by upgrading the latest firmware, it even popped out a new knob and new functionality.Ok, seriously ...Just to repeat just in case you missed it, its NOT DS1054Z , its a DS1104Z-S, watch "S" (highlighted) suffix, means it has a 25MHz function generator (FG) board that DS1054Z doesn't have, also its already 100MHz ready/capable from factory, not a hacked DS1054Z.My "speculation" on the instantaneous magically board/hardware upgrade is, since in the detail firmware's screen, those lazy programmers just don't want to add additional field to show the FG's firmware, so they just "duct-taped" it at the most significant digit at the board version number to indicate that, probably to aid Rigol's field engineer or their support staffs.Again, this is just my guess, but it makes sense though.

author: bitseeker
author_rank: Super Contributor
timestamp: April 22, 2017, 06:18:11 pm
content: Sounds plausible to me.

author: BravoV
author_rank: Super Contributor
timestamp: April 24, 2017, 12:36:59 pm
content: 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.

author: BravoV
author_rank: Super Contributor
timestamp: April 24, 2017, 03:14:37 pm
content: Quote from: ProBang2 on April 21, 2017, 02:01:25 pmThe 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" buttonIt will save a new file at root directory in the USB flash named "CalData.txt". (PS : It will not notify anything on screen when it saves that file, but it should be fast, say in few seconds)Now, the fun of decoding that CalData.txt file is started ...For those who still confused, attached below pictures of two versions of Self-Cal screens, the normal one and in the "Expanded" mode.

author: ted572
author_rank: Frequent Contributor
timestamp: April 24, 2017, 07:19:19 pm
content: 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.

author: Gary.M
author_rank: Regular Contributor
timestamp: April 26, 2017, 01:48:56 am
content: 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.

author: maxiq4
author_rank: Contributor
timestamp: April 26, 2017, 05:33:12 am
content: Im updated, ds1054Z, self cal is okbut why not show boot version etc?my system info menu short. have any body know why?

author: metrologist
author_rank: Super Contributor
timestamp: April 26, 2017, 05:45:27 am
content: Quote from: maxiq4 on April 26, 2017, 05:33:12 amQuote from: ProBang2 on April 21, 2017, 02:01:25 pm

author: maxiq4
author_rank: Contributor
timestamp: April 26, 2017, 05:53:03 am
content: thank you

author: video
author_rank: Newbie
timestamp: May 01, 2017, 07:10:20 pm
content: Hello,sorry for my english, it's not my mother langageIt'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 ?

author: Roeland_R
author_rank: Regular Contributor
timestamp: May 01, 2017, 07:32:45 pm
content: 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

author: ebastler
author_rank: Super Contributor
timestamp: May 01, 2017, 07:36:59 pm
content: Quote from: video on May 01, 2017, 07:10:20 pmThat'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...

author: video
author_rank: Newbie
timestamp: May 01, 2017, 08:24:01 pm
content: Yes, as is a hidden button, it's probably for development/debugging, but if it exists, there is a reasoneven 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

author: Sredni
author_rank: Frequent Contributor
timestamp: May 01, 2017, 08:58:49 pm
content: I wonder what the calibration data is...For example:{//CH1500 ,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},},...

author: bitseeker
author_rank: Super Contributor
timestamp: May 01, 2017, 09:02:55 pm
content: Quote from: ebastler on May 01, 2017, 07:36:59 pmPerhaps 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.

author: garnix
author_rank: Contributor
timestamp: May 01, 2017, 09:36:06 pm
content: 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...

author: bitseeker
author_rank: Super Contributor
timestamp: May 01, 2017, 10:12:22 pm
content: That would be nice. The offset does aggravate the OCD.

author: BravoV
author_rank: Super Contributor
timestamp: May 02, 2017, 07:19:20 am
content: Quote from: ebastler on May 01, 2017, 07:36:59 pmDefinitely not me either.Dunno, I have a feeling that someone that will be brave enough to modify their cal file to certain extreme values at each entries, load it and compare the measurement results with previous loaded cal that was altered to "another" extreme values, just for the sake to decode that file alone.Probably those people who contribute at this thread ->Rigol DS10xxZ firmware re-write

author: Fungus
author_rank: Super Contributor
timestamp: May 02, 2017, 08:03:34 am
content: Quote from: ebastler on May 01, 2017, 07:36:59 pmBeats 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.Quote from: ebastler on May 01, 2017, 07:36:59 pmYep. 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 oris it a log file of the last calibration process? (which would make a lot more sense)

author: video
author_rank: Newbie
timestamp: May 02, 2017, 08:44:13 am
content: 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 usthis is a part of the CalData.txt:------------------??---------------------{{0,0x5b,1,1,0,0x4f,1,1,},etc..------------------???---------------------------------100M-----------{{//CH1500 ,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..

author: video
author_rank: Newbie
timestamp: May 02, 2017, 08:47:49 am
content: 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

author: tautech
author_rank: Super Contributor
timestamp: May 02, 2017, 09:05:15 am
content: Quote from: video on May 02, 2017, 08:47:49 amDrop 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 CONTENTSQuote this post and you can see the syntax used.

author: BravoV
author_rank: Super Contributor
timestamp: May 02, 2017, 10:27:50 am
content: Quote from: Fungus on May 02, 2017, 08:03:34 amHere 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.

author: ebastler
author_rank: Super Contributor
timestamp: May 02, 2017, 10:34:58 am
content: Quote from: PeDre on May 02, 2017, 09:02:14 amDo you also get the error message when a USB stick with a previously saved calibration file is present?

author: zbyr
author_rank: Contributor
timestamp: May 02, 2017, 10:55:35 am
content: I tried google translate with these chinese characters, and it seems ok.Attached file with translated headers.

author: video
author_rank: Newbie
timestamp: May 02, 2017, 11:54:27 am
content: 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 ?

author: Karel
author_rank: Super Contributor
timestamp: May 14, 2017, 02:48:35 pm
content: 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:FENDinstead 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.

author: Fungus
author_rank: Super Contributor
timestamp: May 14, 2017, 04:02:19 pm
content: Quote from: Karel on May 14, 2017, 02:48:35 pmThat's correct behavior.Read the manual:

author: metrologist
author_rank: Super Contributor
timestamp: May 14, 2017, 04:14:24 pm
content: maybe because that is the way they've written it, but I would expect the FEND? keyword. that stuff happens to the best anyway...

author: Karel
author_rank: Super Contributor
timestamp: May 14, 2017, 04:34:28 pm
content: 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 offersome arguments or reasoning why you think it is correct.The maximum number of framesrecordedis5.The maximum number of frames to beplayed backis set to3.The query to maximum number of frames that can be played back should be the number ofrecorded frames: 5.The query to maximum number frames set to playback is 3.QuoteWhen you set the end frame for playback, you don't change the number ofrecorded frames.

author: pascal_sweden
author_rank: Super Contributor
timestamp: May 14, 2017, 05:04:26 pm
content: Who is actually communicating all these bugs to Rigol? Or is there a Rigol application engineer on this forum?

author: Karel
author_rank: Super Contributor
timestamp: May 14, 2017, 05:20:55 pm
content: Quote from: pascal_sweden on May 14, 2017, 05:04:26 pmA 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.

author: Fungus
author_rank: Super Contributor
timestamp: May 14, 2017, 05:47:09 pm
content: Quote from: Karel on May 14, 2017, 04:34:28 pmMy "argument" is that on the very next line of the manual, under the one you're throwing around, it says this:Code:Use the :FUNCtion:WRECord:FEND command to set the maximum number of framesrecorded.So yes, itdoeschange the number of recorded frames.You may notlikethe function, but it's not a bug.PS: You can play back a subset of frames using the ":FUNCtion:WREPlay:FCURrent" function, or just start playing and monitor the current position.

author: Karel
author_rank: Super Contributor
timestamp: May 14, 2017, 06:16:17 pm
content: I'm not talking about :FUNCtion:WRECord:FEND.I'm talking about :FUNCtion:WREPlay:FMAXChanging 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?

author: kcbrown
author_rank: Frequent Contributor
timestamp: May 14, 2017, 08:42:27 pm
content: Quote from: Karel on May 14, 2017, 06:16:17 pmThe documentation clearly claims otherwise.QuoteIf 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?

author: Karel
author_rank: Super Contributor
timestamp: May 14, 2017, 10:00:16 pm
content: Quote from: kcbrown on May 14, 2017, 08:42:27 pmNo, it doesn't. Please show me where it does.Quote from: kcbrown on May 14, 2017, 08:42:27 pmIt 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 doesnotalter 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 berecorded.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 !!

author: kcbrown
author_rank: Frequent Contributor
timestamp: May 14, 2017, 11:32:47 pm
content: Quote from: Karel on May 14, 2017, 10:00:16 pmAh. 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

author: technogeeky
author_rank: Frequent Contributor
timestamp: May 15, 2017, 02:50:59 am
content: In case Rigol does ever visit: Rigol would, at this point, have nothing to lose andeverythingto 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 todo absolutely no product developmentand 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..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

author: Fungus
author_rank: Super Contributor
timestamp: May 15, 2017, 03:56:14 am
content: Quote from: kcbrown on May 14, 2017, 11:32:47 pmOh, duh! Yes.

author: bitseeker
author_rank: Super Contributor
timestamp: May 15, 2017, 04:30:17 am
content: I had to read through that a few times, as well, since the commands are very similar looking. Perhaps the bug arose from a similar confusion during coding of the functionality. Nice bug find, Karel.Regarding Rigol doing something because it would seem to make sense to, I have one word for it: "pluses".Seriously, though, it would be nice to be able to fix things ourselves. But, alas, we're the minority. Hence, I'd be skeptical of it happening, but very pleased if it did.

author: boggis the cat
author_rank: Regular Contributor
timestamp: May 15, 2017, 05:41:40 am
content: Quote from: technogeeky on May 15, 2017, 02:50:59 amI 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.)

author: BravoV
author_rank: Super Contributor
timestamp: May 15, 2017, 06:50:31 am
content: Quote from: technogeeky on May 15, 2017, 02:50:59 amFew 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.

author: boggis the cat
author_rank: Regular Contributor
timestamp: May 15, 2017, 07:47:01 am
content: 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.

author: Karel
author_rank: Super Contributor
timestamp: May 15, 2017, 07:47:06 am
content: 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...

author: Karel
author_rank: Super Contributor
timestamp: May 15, 2017, 07:55:34 am
content: Quote from: technogeeky on May 15, 2017, 02:50:59 amI 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 theusb stack from using 64 byte buffers to 512 byte buffers requires more memory.

author: BravoV
author_rank: Super Contributor
timestamp: May 15, 2017, 09:50:52 am
content: Quote from: boggis the cat on May 15, 2017, 07:47:01 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.When its time to RMA, and as usual, "few" userswill be pretending innocent, and as expected, thefightdispute between seller and user on RMA ... and so on, you just need a little imagination to think of the next scenes.Quote from: boggis the cat on May 15, 2017, 07:47:01 am"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.Quote from: boggis the cat on May 15, 2017, 07:47:01 am"What if" ... the modded firmware is so shitty, forgot to switch the front end relay to switch to less sensitive input level, while the screen is prompting its ok to plug and pump in high voltage signal ?... another "what if" ... the over temperature mechanism is triggered, and the part of the firmware that supposed for handling the shutdown sequences is ignored or buggy ...Too many "what ifs" ... and back to my previous post, its never about these "what ifs" scenarios anyway, the "fact" is, these scopes are selling like hot cakes, so why bother ?Rather than sink deep in this fuss and mess, why not focus and concentrate on designing and making another new generation low cost scope, sort of DS1054Z successor, as DS1054Z is considered quite old now, and the new beast is specifically targeted to hit very hard to those new competing products.

author: boggis the cat
author_rank: Regular Contributor
timestamp: May 15, 2017, 10:11:05 am
content: Quote from: BravoV on May 15, 2017, 09:50:52 amThe 'un-brick' option.Quote"Someone snuck into my house and flashed dodgy firmware onto my 'scope!"Yeah... Not seeing the big problem there. 🤔QuoteThen 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.QuoteThe DS1054Z doesn't have a 50 Ohm input. I don't see how you could damage it through a firmware issue.QuoteUn-bricking time again...QuoteTo 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.QuoteOpening 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.

author: BravoV
author_rank: Super Contributor
timestamp: May 15, 2017, 10:17:56 am
content: Quote from: boggis the cat on May 15, 2017, 10:11:05 amIf 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 ?

author: boggis the cat
author_rank: Regular Contributor
timestamp: May 15, 2017, 10:20:35 am
content: Quote from: Karel on May 15, 2017, 07:55:34 amYou 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.)

author: boggis the cat
author_rank: Regular Contributor
timestamp: May 15, 2017, 10:29:10 am
content: Quote from: BravoV on May 15, 2017, 10:17:56 amI 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.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: May 15, 2017, 11:19:45 am
content: Dudes!It would be really nice to keep the chatting in theNew Rigol D1054Z threadand 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

author: Karel
author_rank: Super Contributor
timestamp: May 15, 2017, 12:15:45 pm
content: Quote from: frozenfrogz on May 15, 2017, 11:19:45 amI connected the scope via LAN and opened a telnet connection.Then I enabled the record function:Code::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?DescriptionQuery the maximum number of frames can be played, namely the maximum number offrames recorded.

author: BravoV
author_rank: Super Contributor
timestamp: May 15, 2017, 12:19:22 pm
content: @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.

author: HoracioDos
author_rank: Frequent Contributor
timestamp: May 15, 2017, 12:56:48 pm
content: HelloI 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)Quote from: Karel on December 08, 2016, 06:12:08 pmMore details here:https://github.com/Teuniz/DSRemote/issues/12#issuecomment-283940080

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: May 15, 2017, 01:31:42 pm
content: Quote from: HoracioDos on May 15, 2017, 12:56:48 pmHello 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

author: HoracioDos
author_rank: Frequent Contributor
timestamp: May 15, 2017, 01:43:14 pm
content: Quote from: frozenfrogz on May 15, 2017, 01:31:42 pmHi frozenfrogz!Ohh I'm sorry for the inconvenience. I checked the list before posting but obviously I've got it wrong. Thanks!!!

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: May 15, 2017, 01:49:38 pm
content: No problemThe 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.

author: technogeeky
author_rank: Frequent Contributor
timestamp: May 16, 2017, 03:26:25 am
content: Quote from: Karel on May 15, 2017, 07:55:34 amI 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.

author: sandor626
author_rank: Regular Contributor
timestamp: May 20, 2017, 05:08:00 pm
content: 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 Rebbot7) 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 !!

author: Nat
author_rank: Newbie
timestamp: June 14, 2017, 08:01:13 am
content: 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.).

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: June 14, 2017, 09:42:31 am
content: Quote from: Nat on June 14, 2017, 08:01:13 amOf 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 thatIf it was my scope I would drop in the update.Regards,Frederik

author: Nat
author_rank: Newbie
timestamp: June 14, 2017, 10:27:49 am
content: Make sens, this .gel loaded USB stick is burning my fingers anywayThanks.

author: grants225
author_rank: Newbie
timestamp: July 07, 2017, 07:46:06 am
content: regarding ""pluses" - did I missed something, but yesterday I updated and see this:

author: ebastler
author_rank: Super Contributor
timestamp: July 07, 2017, 07:53:14 am
content: Quote from: grants225 on July 07, 2017, 07:46:06 amI 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.

author: psysc0rpi0n
author_rank: Frequent Contributor
timestamp: July 07, 2017, 05:03:03 pm
content: 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!

author: Fungus
author_rank: Super Contributor
timestamp: July 07, 2017, 07:37:02 pm
content: Quote from: psysc0rpi0n on July 07, 2017, 05:03:03 pmNo.http://theoatmeal.com/comics/misspelling

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: July 07, 2017, 09:05:49 pm
content: Quote from: psysc0rpi0n on July 07, 2017, 05:03:03 pmEverything not strictly bug related (factual and possible bugs) is being discussed inthis threadover 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,FrederikP.S. Please let me know if I should include more summarizing/general info regarding the scope in the opening post.

author: psysc0rpi0n
author_rank: Frequent Contributor
timestamp: July 08, 2017, 09:30:16 am
content: Quote from: frozenfrogz on July 07, 2017, 09:05:49 pmWas 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?

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: July 08, 2017, 11:10:26 am
content: Quote from: psysc0rpi0n on July 08, 2017, 09:30:16 amSort 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.

author: PeLa
author_rank: Contributor
timestamp: July 23, 2017, 12:27:12 pm
content: 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:RUNAs soon as triggers come in the "cnt" will be displayed in the statistics on the screen. However this value cannot be read. The only valid commands to read statistic items are MAXimum|MINimum|CURRent|AVERages|DEViation. No counts.I have interfaced HP/Agilent/Keysight and Tektronix scopes before in my day job. - I never came across a scope that wouldn't tell you how many averages it has acquired (Tektronix) or if the acquisition of a certain number of averages is complete (HP/Agilent/Keysight)00.04.04.03.02 software0.0.1.4 Boot version0.2.3.11 firmware

author: ebastler
author_rank: Super Contributor
timestamp: July 23, 2017, 04:39:29 pm
content: Quote from: PeLa on July 23, 2017, 12:27:12 pmI 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.

author: PeLa
author_rank: Contributor
timestamp: July 23, 2017, 06:27:08 pm
content: 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.

author: bitseeker
author_rank: Super Contributor
timestamp: July 23, 2017, 09:59:04 pm
content: Quote from: ebastler on July 23, 2017, 04:39:29 pmCorrect. It is adeficiency, as compared to other products, and a feature that seems logical to have for the use case described, but it's not a bug.By contrast, having a label that says "Pluses" instead of "Pulses" for pulse-related functionality is a bug.Just a matter of semantics? Absolutely. The meanings are important.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: July 23, 2017, 10:14:33 pm
content: 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

author: bitseeker
author_rank: Super Contributor
timestamp: July 23, 2017, 10:17:18 pm
content: It's a feature request, yes.

author: PeLa
author_rank: Contributor
timestamp: July 24, 2017, 11:02:27 pm
content: 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.

author: bitseeker
author_rank: Super Contributor
timestamp: July 24, 2017, 11:49:34 pm
content: Sure thing. Thanks for chiming in, PeLa. We can't all know about every industry's use cases.

author: RoGeorge
author_rank: Super Contributor
timestamp: September 07, 2017, 11:27:36 pm
content: 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 55553. In the NetCat, type:WAV:STAR 04. Now type at least one more SCPI command, good or bad, for example:WAV:STAR 15. 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.ExampleCode::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::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?

author: zbyr
author_rank: Contributor
timestamp: September 08, 2017, 11:44:39 am
content: Yup. Bug also exist in SCPI with USB connection.

author: RoGeorge
author_rank: Super Contributor
timestamp: September 08, 2017, 01:06:30 pm
content: Thank you for testing it.

author: Karel
author_rank: Super Contributor
timestamp: September 08, 2017, 01:32:07 pm
content: 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?

author: SparkyM8
author_rank: Newbie
timestamp: September 08, 2017, 01:50:51 pm
content: Quote from: PeLa on July 23, 2017, 12:27:12 pmPeLa 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.

author: RoGeorge
author_rank: Super Contributor
timestamp: September 08, 2017, 02:02:19 pm
content: Quote from: Karel on September 08, 2017, 01:32:07 pmNot me.Just in case more details about versions are required, I am attaching them here. The SN was partially deleted by me.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: September 09, 2017, 11:50:59 am
content: Original posting has been updated with info on SCPI lock up.Regards,Frederik

author: rob040
author_rank: Contributor
timestamp: October 10, 2017, 03:10:04 pm
content: 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.

author: bitseeker
author_rank: Super Contributor
timestamp: October 10, 2017, 10:04:30 pm
content: Quote from: rob040 on October 10, 2017, 03:10:04 pmHmmm. Fascinating.

author: Wall-E
author_rank: Contributor
timestamp: October 10, 2017, 10:51:14 pm
content: Quote from: rob040 on October 10, 2017, 03:10:04 pmRigol 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.

author: Karel
author_rank: Super Contributor
timestamp: October 11, 2017, 06:27:19 am
content: Quote from: Wall-E on October 10, 2017, 10:51:14 pmOn the contrary, it is very hard to understand from a test & measurement company that claims:"Uncompromised Performance… Unprecedented Value"

author: ebastler
author_rank: Super Contributor
timestamp: October 11, 2017, 07:13:23 pm
content: Quote from: Karel on October 11, 2017, 06:27:19 amWell, you know what "value" means in marketing-speak, right? It's a euphemism for "cheap".But, seriously: Of course Rigol will have to triage, and will not fix all issues. Otherwise they would never get around to releasing further new products once they have to sustain a few existing products in the market.

author: Karel
author_rank: Super Contributor
timestamp: October 21, 2017, 12:41:52 pm
content: 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%!

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: October 21, 2017, 02:52:40 pm
content: Quote from: Karel on October 21, 2017, 12:41:52 pmI 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.

author: Karel
author_rank: Super Contributor
timestamp: October 21, 2017, 03:40:55 pm
content: Quote from: frozenfrogz on October 21, 2017, 02:52:40 pmThe 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 displayingthe 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.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: October 21, 2017, 04:43:13 pm
content: 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 resolution10 div@2V: 20V/256 = 0.08V true resolution **where true gain setting might have to be determined via experiments

author: Karel
author_rank: Super Contributor
timestamp: October 21, 2017, 05:36:43 pm
content: 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.

author: bitseeker
author_rank: Super Contributor
timestamp: October 21, 2017, 05:42:35 pm
content: 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?

author: Fungus
author_rank: Super Contributor
timestamp: October 21, 2017, 06:29:52 pm
content: Quote from: bitseeker on October 21, 2017, 05:42:35 pmProbably 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.

author: bitseeker
author_rank: Super Contributor
timestamp: October 21, 2017, 07:13:39 pm
content: Yeah, ease of implementation.

author: Karel
author_rank: Super Contributor
timestamp: October 21, 2017, 07:51:32 pm
content: Quote from: Fungus on October 21, 2017, 06:29:52 pmThen why didn't they do it with the 4000 series which uses the same resolution?

author: bitseeker
author_rank: Super Contributor
timestamp: October 21, 2017, 09:40:00 pm
content: 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.

author: Fungus
author_rank: Super Contributor
timestamp: October 21, 2017, 09:43:57 pm
content: Quote from: Karel on October 21, 2017, 07:51:32 pmBigger FPGA, more free gates?Who knows...?

author: technogeeky
author_rank: Frequent Contributor
timestamp: October 21, 2017, 10:00:32 pm
content: Quote from: bitseeker on October 21, 2017, 05:42:35 pmThere 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!

author: bitseeker
author_rank: Super Contributor
timestamp: October 21, 2017, 10:09:30 pm
content: 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.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: October 27, 2017, 12:43:51 pm
content: 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 knowThe 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

author: metrologist
author_rank: Super Contributor
timestamp: October 27, 2017, 02:05:43 pm
content: Quote from: Karel on October 21, 2017, 05:36:43 pmThe specifications state that the vertical resolution is 8 bits. How does DSRemote get all 8 bits? Is it using Raw mode?

author: RoGeorge
author_rank: Super Contributor
timestamp: October 27, 2017, 02:58:58 pm
content: 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.

author: metrologist
author_rank: Super Contributor
timestamp: October 27, 2017, 03:08:30 pm
content: 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.

author: Karel
author_rank: Super Contributor
timestamp: October 27, 2017, 03:15:02 pm
content: Quote from: metrologist on October 27, 2017, 02:05:43 pmIt uses the ":WAVeform:DATA?" command as described in Rigols programming guide.

author: Karel
author_rank: Super Contributor
timestamp: October 27, 2017, 03:20:59 pm
content: Quote from: RoGeorge on October 27, 2017, 02:58:58 pmThe 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.

author: metrologist
author_rank: Super Contributor
timestamp: October 27, 2017, 03:25:49 pm
content: Quote from: Karel on October 27, 2017, 03:15:02 pmBut then must it issue :WAV:MODE RAW beforehand? Otherwise, YINC is /25.

author: Karel
author_rank: Super Contributor
timestamp: October 27, 2017, 04:08:51 pm
content: Quote from: metrologist on October 27, 2017, 03:25:49 pmNormal 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.

author: metrologist
author_rank: Super Contributor
timestamp: October 27, 2017, 04:17:08 pm
content: 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?

author: Karel
author_rank: Super Contributor
timestamp: October 27, 2017, 05:31:02 pm
content: Quote from: metrologist on October 27, 2017, 04:17:08 pmWhen 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.

author: metrologist
author_rank: Super Contributor
timestamp: October 27, 2017, 05:59:57 pm
content: 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.

author: Fungus
author_rank: Super Contributor
timestamp: October 27, 2017, 06:17:04 pm
content: Quote from: frozenfrogz on October 27, 2017, 12:43:51 pmIs 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.Quote from: RoGeorge on October 27, 2017, 02:58:58 pmWhat 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.

author: Karel
author_rank: Super Contributor
timestamp: October 27, 2017, 06:38:40 pm
content: Quote from: Fungus on October 27, 2017, 06:17:04 pmGood 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.

author: Fungus
author_rank: Super Contributor
timestamp: October 27, 2017, 06:56:56 pm
content: Quote from: Karel on October 27, 2017, 06:38:40 pmIt's a feature! R&S charge extra for their "virtual screen" function (which basically does the same thing).Quote from: Karel on October 27, 2017, 06:38:40 pmMust 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.

author: metrologist
author_rank: Super Contributor
timestamp: October 27, 2017, 07:02:37 pm
content: 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?

author: Karel
author_rank: Super Contributor
timestamp: October 27, 2017, 07:40:17 pm
content: Quote from: metrologist on October 27, 2017, 07:02:37 pmThere's a setting in DSRemote where you can change this behaviour. You can select to let DSRemote show exactly the sameas the scopes display with the same number of vertical divisions.With DSRemote you simply have theoptionto show more divisions and the complete waveform.Quote from: metrologist on October 27, 2017, 07:02:37 pmThe 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.

author: metrologist
author_rank: Super Contributor
timestamp: October 27, 2017, 07:47:39 pm
content: 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.

author: bitseeker
author_rank: Super Contributor
timestamp: October 27, 2017, 10:04:52 pm
content: 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.

author: Karel
author_rank: Super Contributor
timestamp: October 28, 2017, 06:25:16 am
content: Quote from: bitseeker on October 27, 2017, 10:04:52 pmCorrect. 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.

author: TD-Linux
author_rank: Contributor
timestamp: October 28, 2017, 06:38:23 am
content: Quote from: bitseeker on October 21, 2017, 09:40:00 pmYeah, 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.

author: bitseeker
author_rank: Super Contributor
timestamp: October 28, 2017, 07:29:38 am
content: 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.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: October 28, 2017, 07:57:57 am
content: 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.

author: bd139
author_rank: Super Contributor
timestamp: October 28, 2017, 09:55:52 am
content: 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.

author: RoGeorge
author_rank: Super Contributor
timestamp: October 28, 2017, 10:34:56 am
content: Quote from: frozenfrogz on October 28, 2017, 07:57:57 amI 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 isnota 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.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: October 28, 2017, 10:48:34 am
content: Quote from: RoGeorge on October 28, 2017, 10:34:56 amThat 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)

author: Karel
author_rank: Super Contributor
timestamp: October 28, 2017, 12:34:22 pm
content: Quote from: RoGeorge on October 28, 2017, 10:34:56 amThat 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.

author: lundmar
author_rank: Frequent Contributor
timestamp: October 28, 2017, 10:57:45 pm
content: Quote from: RoGeorge on September 07, 2017, 11:27:36 pmI 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:$ lxi scpi --address 192.168.1.210 --timeout 5 --script crash-test.scpiConnected to 192.168.1.210Running 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.SP3With 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.

author: RoGeorge
author_rank: Super Contributor
timestamp: October 29, 2017, 08:50:44 am
content: Quote from: Karel on October 28, 2017, 12:34:22 pm"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.Quote from: lundmar on October 28, 2017, 10:57:45 pmThat'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.

author: lundmar
author_rank: Frequent Contributor
timestamp: October 29, 2017, 09:19:55 am
content: Quote from: RoGeorge on October 29, 2017, 08:50:44 amNo 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 fromhttps://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.

author: Karel
author_rank: Super Contributor
timestamp: October 29, 2017, 09:31:09 am
content: Quote from: lundmar on October 28, 2017, 10:57:45 pmI 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:Quoteliterature.cdn.keysight.com/litweb/pdf/5989-6717EN.pdf

author: lundmar
author_rank: Frequent Contributor
timestamp: October 29, 2017, 11:53:18 am
content: Quote from: Karel on October 29, 2017, 09:31:09 amTrue, 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.

author: RoGeorge
author_rank: Super Contributor
timestamp: October 29, 2017, 03:15:42 pm
content: Quote from: lundmar on October 29, 2017, 09:19:55 amI just did, then sniffed the actual LAN data packets using Wireshark.First, lxi-tools is a very nice and useful tool, thank you for making it available.Second, I found it very hard to install, even if I'm familiar with Linux. By familiar I mean able to follow README instructions, and able to use the command line, but not being a Linux developer. The problem was that there were no binary, so I need to compile from sources. In the README file it says "./configure", "make", "make install", which won't work, because there is no "./configure". By looking inside various files I realized that I should generate the ./config file myself, then after a lot of googling I found out about autoreconf and so on.This is probably trivial for any Linux developer, but it was not for me. IMHO the build and installation instruction should have been something like these:Code:cd ~mkdir lxi-toolscd lxi-tools/git clone https://github.com/lxi/liblxicd liblxi/suapt-get updateapt-get install automakeapt-get install autogen autoconf libtool./autogen.sh./configuremakemake installcd ..git clone https://github.com/lxi/lxi-toolscd lxi-tools/./autogen.shapt-get install libreadline-dev./configuremakemake installexport LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/lib"lxiFor 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.

author: Karel
author_rank: Super Contributor
timestamp: October 29, 2017, 04:08:51 pm
content: Quote from: RoGeorge on October 29, 2017, 03:15:42 pmWhy 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

author: lundmar
author_rank: Frequent Contributor
timestamp: October 29, 2017, 04:37:33 pm
content: Quote from: RoGeorge on October 29, 2017, 03:15:42 pmI'm glad you like it. I try hard to make it a simple to use tool and libraryI 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.cQuote from: RoGeorge on October 29, 2017, 03:15:42 pmSorry 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 athttps://lxi.github.ioDon'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.shQuote from: RoGeorge on October 29, 2017, 03:15:42 pmThat 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.QuoteYou 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.

author: RoGeorge
author_rank: Super Contributor
timestamp: October 29, 2017, 06:11:08 pm
content: Quote from: Karel on October 29, 2017, 04:08:51 pmThank 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.Quote from: lundmar on October 29, 2017, 04:37:33 pmYep, 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?

author: lundmar
author_rank: Frequent Contributor
timestamp: October 29, 2017, 06:45:26 pm
content: Quote from: RoGeorge on October 29, 2017, 06:11:08 pmYes, 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 totalI 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.Quote from: RoGeorge on October 29, 2017, 06:11:08 pmNo problem. Learning new stuff is often fun.Quote from: RoGeorge on October 29, 2017, 06:11:08 pmYes, 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.

author: TinkeringSteve
author_rank: Frequent Contributor
timestamp: November 04, 2017, 07:28:27 pm
content: 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 theFFTfunction, played around with the options, and when I setModeto "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...)

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: November 04, 2017, 07:40:27 pm
content: 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.

author: Karel
author_rank: Super Contributor
timestamp: November 04, 2017, 07:59:37 pm
content: 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.

author: TinkeringSteve
author_rank: Frequent Contributor
timestamp: November 04, 2017, 08:02:07 pm
content: Oh starting does work, the firmware apparently doesn't get to store that setting, it's back to "trace" when I start again.Quote from: frozenfrogz on November 04, 2017, 07:40:27 pmAs to "does it always" - no - apparently not on CH1, but with at leastCH2, 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.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: November 04, 2017, 08:30:21 pm
content: 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.

author: TinkeringSteve
author_rank: Frequent Contributor
timestamp: November 04, 2017, 08:47:21 pm
content: Quote from: frozenfrogz on November 04, 2017, 08:30:21 pmFunny. 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.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: November 13, 2017, 09:46:09 am
content: 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!

author: bitseeker
author_rank: Super Contributor
timestamp: November 14, 2017, 02:38:20 am
content: Excellent. Thanks for doing that. Hopefully, one day Rigol will pay attention to what goes on here. So far, they seem not to notice.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: March 01, 2018, 11:38:02 am
content: 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 possiblePlease 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

author: Fungus
author_rank: Super Contributor
timestamp: March 01, 2018, 12:12:45 pm
content: Quote from: frozenfrogz on March 01, 2018, 11:38:02 amThere's not much left. A typo in a menu, and... I can't remember any more.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: March 01, 2018, 12:20:34 pm
content: Quote from: Fungus on March 01, 2018, 12:12:45 pmThat 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

author: Roeland_R
author_rank: Regular Contributor
timestamp: March 01, 2018, 12:26:45 pm
content: For the wish list: Alternate triggering perhaps?

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: March 01, 2018, 12:55:17 pm
content: Re. alternate triggering: There isthis thread.I’ll add it as a wish list item when going through the post

author: Karel
author_rank: Super Contributor
timestamp: March 01, 2018, 04:41:57 pm
content: 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.

author: Fungus
author_rank: Super Contributor
timestamp: March 01, 2018, 07:19:37 pm
content: Quote from: Karel on March 01, 2018, 04:41:57 pmBummer!(I guess I"ll have to use an Ethernet cable instead...)

author: Porcine Porcupine
author_rank: Contributor
timestamp: March 04, 2018, 06:15:49 am
content: Bug report:Some DS1000Z units display inpeak detectacquisition mode while set tonormalacquisition 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 inpeak detectacquisition mode when set tonormalacquisition 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 inpeak detectmode whether it is set topeak detectornormalmode.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 indotsorvectorsdisplay mode, but the separation between thepeak detectpoints becomes obvious indotsmode.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.02Board Version: 0.1.4Boot Version: 0.0.1.4Firmware Version: 0.2.3.11CPLD Version: 1.1I 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 innormalacquisition mode:The downsampled raw data and on-screen trace data are represented by blue and red dots, respectively. I think these plots make itvery clearthat the oscilloscope is stuck inpeak detectmode. 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 indotsmode and a fat trace invectorsmode 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.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: March 04, 2018, 09:17:18 am
content: 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

author: Porcine Porcupine
author_rank: Contributor
timestamp: March 04, 2018, 10:17:50 am
content: Quote from: frozenfrogz on March 04, 2018, 09:17:18 amYou 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

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: March 04, 2018, 11:03:29 am
content: I could not reproduce it at that time, but maybe I did not try hard enoughWould be interesting to see if it can be tracked down to certain behavior / sequence of operation.

author: Fungus
author_rank: Super Contributor
timestamp: March 04, 2018, 11:12:38 am
content: This has had its own thread:https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145

author: Porcine Porcupine
author_rank: Contributor
timestamp: March 04, 2018, 11:36:42 am
content: Quote from: Fungus on March 04, 2018, 11:12:38 amThat'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.

author: Fungus
author_rank: Super Contributor
timestamp: March 04, 2018, 11:52:32 am
content: Quote from: Porcine Porcupine on March 04, 2018, 11:36:42 amI 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!)

author: Porcine Porcupine
author_rank: Contributor
timestamp: March 04, 2018, 01:09:02 pm
content: Quote from: Fungus on March 04, 2018, 11:52:32 amOne thing that convinced me it's stuck inpeak detectmode 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'snormalacquisition 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 inpeak detectmode is the traces in bothnormalandpeak detectmodes look the same.Here's a trace captured innormalmode:And here's one captured inpeak detectmode: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.

author: Fungus
author_rank: Super Contributor
timestamp: March 04, 2018, 03:53:40 pm
content: Quote from: Porcine Porcupine on March 04, 2018, 01:09:02 pmCorrect.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).

author: 2N3055
author_rank: Super Contributor
timestamp: March 04, 2018, 04:35:58 pm
content: @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

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: March 05, 2018, 10:20:19 am
content: 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.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: March 05, 2018, 10:29:41 am
content: 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.

author: Fungus
author_rank: Super Contributor
timestamp: March 05, 2018, 11:36:37 am
content: Quote from: frozenfrogz on March 05, 2018, 10:20:19 amI agree 100%.Quote from: frozenfrogz on March 05, 2018, 10:20:19 amie. If you choose sensible display settings it vanishes. Not an issue.

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: March 05, 2018, 12:03:40 pm
content: That "inverse brightness coagulation" (as per my second post above and resembling what PP is referring to) behavior is interesting. I would count that as an unexpected rendering issue that does not actually spawn from the ADC.

author: metrologist
author_rank: Super Contributor
timestamp: March 05, 2018, 03:27:22 pm
content: I can report a more potentially benign bug. I enabled FFT and was setting the Center, Hz/Div, and Offset. I adjusted the Offset and then went to adjust the Center or Hz/Div. With either of those values outlined with the blue box (indicating that was my current parameter selection), the twiddle knob was still adjusting the Offset valueI could recover this by selecting different parameters and the scope would release the Offset setting, but it came back again after changing something in the second menu and returning to the first. I reset (Default) the scope and set it up again without an issue, so I did not test the issue further.I have the latest FW and probably one dot down from the latest hardware.

author: Porcine Porcupine
author_rank: Contributor
timestamp: March 06, 2018, 05:39:03 am
content: Quote from: Fungus on March 04, 2018, 03:53:40 pmWhen 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.

author: Porcine Porcupine
author_rank: Contributor
timestamp: March 06, 2018, 05:44:35 am
content: Quote from: 2N3055 on March 04, 2018, 04:35:58 pmI haven't been able to find satisfactory documentation about how Rigol's peak detect mode works, but I assumed it does what you described plus a second stage of downsampling. The second stage is needed because there are still too many points to show on the screen.My thinking is it first stores the result of the downsampling you described in the acquisition memory. Then it downsamples again just like the first time: it divides points stored in the acquisition memory into the same number of time bins as points shown on the screen, and then alternately selects a maximum or minimum point from each bin. I could be be wrong about this, but this is the most sensible way I can think of to do it.If it does do it in two stages, then peak detect mode would still be different than normal mode because the second downsampling stage still happens even though there's no first-stage downsampling to do. It seems to me it has to do a second stage of downsampling this way to ensure the peak points make it to the screen trace.I don't think this problem is caused by ADC offsets, because I didn't see any obvious sign of that in the raw data before or after downsampling.The effect I see on my oscilloscope is easily seen at 500 V/div. It's possible your oscilloscope isn't affected by the same problem as mine, and you're seeing a different effect at those low V/div ranges. Maybe what you see is the ADC offset you mentioned.Edit: It just occurred to me that there is likely a third peak detect mode downsampling stage to go from the screen trace buffer to what is actually shown on the screen. If the screen trace buffer has 1,200 points stored in it, it would have to be downsampled again with the peak detect downsampling algorithm to preserve the peaks on the displayed trace, which doesn't even cover the full 800-pixel width of the screen.

author: Porcine Porcupine
author_rank: Contributor
timestamp: March 06, 2018, 05:59:15 am
content: I played with my oscilloscope some more and got a couple more results I think are interesting.I fed it train of 5-V, 70-ns-wide pulses spaced at 1-ms intervals and set the time base and memory depth appropriately to test peak detect mode. I changed from dots to vectors for this so the pulses are lines instead of hard-to-see dots.First in normal mode:As expected the pulses were captured erratically and unreliably in normal mode. Each sweep showed a different number of pulses in different spots.Then in peak detect mode:Peak detect mode worked beautifully and did exactly what it's supposed to do. So now I know turning on peak detect mode does something, and the unit isn't simply stuck in peak detect mode.I'm wondering now if that second stage of peak detect mode I speculated about in my last post might be stuck on, meaning that turning peak detect mode on and off is only controlling that first stage of downsampling. I know that scenario might sound a little farfetched, especially since I'm guessing about how peak detect mode works exactly. However, I think that scenario would be consistent with what I'm seeing. The double line with nothing in the middle and the points all displayed at the extremes of the noise amplitude looks so consistent with what I would expect out of peak detect mode that I'm still not satisfied a peak detect bug isn't somehow behind this.I also fed a 4-Vpp, 1-MHz sine wave into the oscilloscope while in normal mode. With the time base set very slow compared to the signal's period, this is what I got with dots:It looks like the envelope of the signal, which is what I would expect to see under these conditions with peak detect mode enabled. Nothing changed on the screen when I varied the frequency around 1-MHz, so I don't think this effect is caused by aliasing. As in the other examples of double lines, it looks like the fog you'd expect to see if displaying vectors because of the lines connecting the two lines of points.Could this be a more extreme example of this double line issue?

author: Porcine Porcupine
author_rank: Contributor
timestamp: March 06, 2018, 07:25:23 am
content: Quote from: frozenfrogz on March 05, 2018, 10:29:41 amIn your screenshot with the point cloud, I believe it is displaying 600 points (50 ns * 12 divisions * 1 GSa/s = 600 samples) of raw data directly from the acquisition memory with no downsampling or other processing. The traces in all the other images you posted were downsampled, and I think something Rigol didn't intend is happening during that downsampling at some time base settings to create that gap in the trace. It looks like peak detect mode finding the minimum and maximum noise points to me, but it shouldn't be happening whatever it is.

author: Fungus
author_rank: Super Contributor
timestamp: March 06, 2018, 08:00:25 am
content: Quote from: Porcine Porcupine on March 06, 2018, 05:39:03 amSo, 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.Quote from: Porcine Porcupine on March 06, 2018, 05:39:03 amNope.What you see depends on theratioof the high frequency components of the signal to the samples you kept.In the post I linked to there's 4 different views of thesame data, all views arecompletely 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

author: Porcine Porcupine
author_rank: Contributor
timestamp: March 06, 2018, 10:05:55 am
content: Quote from: Fungus on March 06, 2018, 08:00:25 amThanks for the explanation, but I'm still a little confused about how such aliasing is happening. I'm interested in replicating the aliasing in Matlab from the raw data to understand it better. Do you have any suggestion on how I might do that?I downsampled by a factor of 2,000 to go from 2.4 million raw sample points to 1,200 like the oscilloscope presumably did to get the trace data but didn't get the aliasing. Would I perhaps see similar aliasing if I tried other downsampling ratios or different sampling phases?

author: Fungus
author_rank: Super Contributor
timestamp: March 06, 2018, 10:30:53 am
content: Quote from: Porcine Porcupine on March 06, 2018, 10:05:55 amYou just described the problem perfectly: How do you reduce 2000 points of data to a single point on screen?I don't know what method the DS1054Z uses, sorry. I'm sure it's done in hardware though so expect it to be a compromise.(nb. The DS1054Z only displays 600 points on screen so there's a secondary 2:1 reduction somewhere...)

author: ebastler
author_rank: Super Contributor
timestamp: March 06, 2018, 10:57:34 am
content: Quote from: Fungus on March 06, 2018, 10:30:53 amObviously we don't know how it is implemented by Rigol. But I can't see a good reason for always showing the extreme data points, and hardly ever showing one with medium amplitude. That does hint towards an unintended peak-detect like algorithm, as postulated by porcupine.And, not to forget: At just slightly faster time base settings, where the scope still has to do massive down-sampling, the effect disappears and the curves or point clouds look reasonable. Something must go "wrong" at those slow time bases. Maybe some histogram counter overflowing or whatever?Anyway, this is just guessing. But I think it likely that, within the limitations of the existing DS1000Z hardware, there would be a better way to down-sample and display the signals at slow time bases.

author: Porcine Porcupine
author_rank: Contributor
timestamp: March 06, 2018, 06:27:01 pm
content: Quote from: Fungus on March 06, 2018, 10:30:53 amIn the image below, taken from one of my previous posts, I plotted the points stored in the oscilloscope's 1,200-point trace buffer in red and the raw data I downsampled from 2.4 million raw points to 1,200 points in blue. So the effect happens before that final 2:1 reduction.This is making me want an oscilloscope with open source hardware and software so I can peer inside the black box. But guessing what the black box is doing is sort of fun too in its own way.

author: Fungus
author_rank: Super Contributor
timestamp: March 06, 2018, 06:59:53 pm
content: Quote from: ebastler on March 06, 2018, 10:57:34 amJust 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!

author: ebastler
author_rank: Super Contributor
timestamp: March 06, 2018, 07:32:21 pm
content: Quote from: Fungus on March 06, 2018, 06:59:53 pmWell, 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.

author: 2N3055
author_rank: Super Contributor
timestamp: March 06, 2018, 07:39:45 pm
content: Sorry but i have a question:I would like to know what you guys think an analog CRT scope would show in these circumstances...Namely, a slow time sweep and fast pulses... For instance, 10 ms/div and feed it 1 MHz signal....Tadaaaa...You would get solid block, from left to right, vertically sized to P-P amplitude of signal....Depending of waveform, parts of that "band" would be darker or brighter, depending on statistical distribution of signal amplitude over time ....It works only in what a DSO crowd would call "Peak mode"....I don't know who started dot mode fetish, but it is not optimal mode that shows signal best... Vector mode is your friend. Dot mode is used only sometimes, for specific reasons.Also, unless you want to specifically filter out higher frequencies (by using BW limit, average or HiRes mode), you want a Peek mode pretty much always...You don't want to miss super short interference bursts because you are looking at slow timebase..I don't know what are you measuring but from my practice...Regards,Sinisa

author: ebastler
author_rank: Super Contributor
timestamp: March 06, 2018, 07:52:04 pm
content: Quote from: 2N3055 on March 06, 2018, 07:39:45 pmRead 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).

author: Porcine Porcupine
author_rank: Contributor
timestamp: March 06, 2018, 07:56:45 pm
content: Quote from: Fungus on March 06, 2018, 06:59:53 pmI 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.

author: 2N3055
author_rank: Super Contributor
timestamp: March 06, 2018, 07:59:25 pm
content: Quote from: ebastler on March 06, 2018, 07:52:04 pmI am specifically commenting Reply #254.....As for what you are saying, I made my comment on that before...He needs to self cal scope first, and than not use software magnified input ranges..Also, DS1000Z IS sensitive to external RF fields... It might as well be that he REALLY HAS high frequency interference injected... In that case noise is not artificially inflated....Or his scope might really have some issue....

author: 2N3055
author_rank: Super Contributor
timestamp: March 06, 2018, 08:06:21 pm
content: Quote from: Porcine Porcupine on March 06, 2018, 07:56:45 pmPut it in vector mode and it looks exactly as it should....On the other hand I do agree that I would like for Rigol (and everybody else) would exactly explain how they massage data before handing it to us...I'm all for it...Regards,Sinisa

author: Fungus
author_rank: Super Contributor
timestamp: March 06, 2018, 08:08:35 pm
content: Quote from: 2N3055 on March 06, 2018, 07:59:25 pmNah, 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

author: ebastler
author_rank: Super Contributor
timestamp: March 06, 2018, 08:10:24 pm
content: Quote from: 2N3055 on March 06, 2018, 07:59:25 pmMe 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.)

author: ebastler
author_rank: Super Contributor
timestamp: March 06, 2018, 08:13:24 pm
content: Quote from: 2N3055 on March 06, 2018, 08:06:21 pmQuote from: ebastler on March 06, 2018, 07:32:21 pm

author: 2N3055
author_rank: Super Contributor
timestamp: March 06, 2018, 08:21:50 pm
content: Quote from: ebastler on March 06, 2018, 08:10:24 pm@ebastler, I apologize, I meant specifically to that last third image...In non peak detect mode at slow timebase and dot mode, with decimation, signal would get very VERY few dots vertically in between... At that sampling ratio, it does spend negligible time going up and down...That is why you have to use vector interpolation....Regards,Sinisa

author: Porcine Porcupine
author_rank: Contributor
timestamp: March 06, 2018, 09:15:59 pm
content: Quote from: Fungus on March 06, 2018, 08:08:35 pmAh, I think I see now why you were saying it's aliasing and I had a hard time understanding how it could be aliasing. I was assuming the noise is a spectrum of high frequencies, and I think you had that single-frequency sine wave in mind.The time segment you zoomed into isn't indicative of the noise over a full cycle of the square wave on my oscilloscope. When I zoom all the way into the trace on my oscilloscope, I can find time segments that look like a single sine wave as in your example. But I can move around and find other segments that look very different and obviously have other frequency components. This is why I didn't think it was aliasing.

author: konnor
author_rank: Regular Contributor
timestamp: March 30, 2018, 07:33:32 pm
content: 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 formake&load plugins. Two simple examples are included.changes on firmware:1) Ext port 6000 funcs - read/write/call (see rigolif programm)2) pluses -> pulses3) rnage -> range (decoder:conf:range)4) Changed USB Buffer Size (40->200) - test, please. I don't use USB IF5) Disabled set bandwidth to license maximum on start (BW20 fix)directory in plugin archive:rigolif sample programm for 6000/UDPadd_info mixed infolibb plugin librarypatch port 6000/UDP patch sourcesplugin_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 RigolAS IS, AS IS, AS IS.....Update: Archive with color-bug firmware removed, see update in new topic:https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/

author: ebastler
author_rank: Super Contributor
timestamp: March 30, 2018, 07:36:52 pm
content: Quote from: konnor on March 30, 2018, 07:33:32 pmWow, that is quite amazing! But I am reluctant to try it...What version number did you give the new firmware? If I want to go back to a standard firmware, can I do that? (To which version?) I seem to recall that Rigol does not allow "downgrades" of the verion number, so can one ever go back?

author: metrologist
author_rank: Super Contributor
timestamp: March 30, 2018, 07:38:10 pm
content: Tempting. Somebody needs to test this. Where did you come from?

author: konnor
author_rank: Regular Contributor
timestamp: March 30, 2018, 07:42:25 pm
content: Quote from: metrologist on March 30, 2018, 07:38:10 pmi don't change version, 00.04.04.03.02

author: Fungus
author_rank: Super Contributor
timestamp: March 30, 2018, 07:43:13 pm
content: Is it possible to 'downgrade' to standard firmware after installing this, or install newer versions?(ie. has your firmware's version check been disabled?)This should maybe have its own thread.

author: ebastler
author_rank: Super Contributor
timestamp: March 30, 2018, 07:44:24 pm
content: Quote from: konnor on March 30, 2018, 07:42:25 pmOK, thanks. I assume you have tested that one can upgrade to the same version number multiple times, and can go back and forth between the regular firmware and your modfied version?

author: konnor
author_rank: Regular Contributor
timestamp: March 30, 2018, 07:45:10 pm
content: Quote from: metrologist on March 30, 2018, 07:38:10 pmThe city is listed in the profile.I have no relationship to Rigol.

author: konnor
author_rank: Regular Contributor
timestamp: March 30, 2018, 07:51:13 pm
content: Quote from: ebastler on March 30, 2018, 07:44:24 pmYes.Actually, downgrde is also not a problem, it's enough to write a special signature on a flash drive. But very different firmware may have compatibility problems of the settings.

author: Fungus
author_rank: Super Contributor
timestamp: March 30, 2018, 07:52:42 pm
content: Quote from: konnor on March 30, 2018, 07:51:13 pmThis 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.

author: konnor
author_rank: Regular Contributor
timestamp: March 30, 2018, 08:01:07 pm
content: I did not know that this was a big problem. It is more difficult to find the algorithm for generating keys at times.The only problem with the distribution of this signature is that it opens other additional functions that make it easy to kill an oscilloscope. And it is not tied to either the serial number or the firmware version.

author: metrologist
author_rank: Super Contributor
timestamp: March 30, 2018, 08:19:14 pm
content: Quote from: konnor on March 30, 2018, 07:45:10 pmYes, well there is more to that...Quote from: Fungus on March 30, 2018, 07:52:42 pmAges, yes. And this out of the blue, it falls from the sky, like candy.I agree, new thread, or added to the other one (whatever it was called, the FW hacking rewrite uber thread that has been going on since the beginning of time...)

author: rob040
author_rank: Contributor
timestamp: March 30, 2018, 08:44:34 pm
content: Thanks Konnor for sharing this firmware.I am not able to unzip both files into one .GEL file. Get an error. Anyone else tried it?

author: RoGeorge
author_rank: Super Contributor
timestamp: March 30, 2018, 10:08:59 pm
content: Quote from: konnor on March 30, 2018, 07:33:32 pmThank you very much, this is quite a nice surprise.Can you please upload again the attachmentsDS1000ZUpdate.zipandDS1000ZUpdate.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.

author: Daruosha
author_rank: Regular Contributor
timestamp: March 30, 2018, 11:41:25 pm
content: Quote from: RoGeorge on March 30, 2018, 10:08:59 pmSame here, I couldn't unzip the files.

author: Fungus
author_rank: Super Contributor
timestamp: March 30, 2018, 11:48:48 pm
content: Quote from: metrologist on March 30, 2018, 08:19:14 pmIt really needs to be a thread where konnor can edit the first post and keep it updated.ie. A completely new thread.

author: TurboTom
author_rank: Super Contributor
timestamp: March 31, 2018, 12:40:32 am
content: I've been able to extract the GEL file with the unZIP tool integrated with "Total Commander". Flashed it and found it to be "very beta"... Pallette got messed up so the screen looks somewhat funny now, see attached screenshot. Since it's quite late already over here, I didn't do any serious testing - this will have to wait until tomorrow. But I can confirm the "Pluses" spelling error is corrected. Kudos to @konnor for all the effort -- I guess this might be the starting point for some serious improvements! Thanks a lot.Cheers,Thomas

author: RoGeorge
author_rank: Super Contributor
timestamp: March 31, 2018, 12:51:17 am
content: Quote from: TurboTom on March 31, 2018, 12:40:32 amI've extracted a GEL, too, but it seems to be a corrupt file. When I try to unpack it, I get this output (Corrupt input data):Code:python-3.6.1-embed-amd64\python.exe" unpack.py DS1000ZUpdate.GELinstrument series: DS1000Zfirmware version: 00.04.04.03.02updateType: 0x00070000found 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 dataTraceback (most recent call last):File "unpack.py", line 160, in checkCreateDiros.makedirs(os.path.dirname(filename))File "os.py", line 220, in makedirsFileNotFoundError: [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 mainsave(h["filename"],bFile)File "unpack.py", line 166, in savecheckCreateDir(prefix + filename) #create missing directoriesFile "unpack.py", line 162, in checkCreateDirif exc.errno != errno.EEXIST:NameError: name 'errno' is not definedDid you tested the checksum for the GEL file you extracted with Total Commander?

author: Adrian_Arg.
author_rank: Frequent Contributor
timestamp: March 31, 2018, 03:03:32 am
content: You could do an update of only the correction of the word pluses by pulses, which is the only thing that bothers me

author: konnor
author_rank: Regular Contributor
timestamp: March 31, 2018, 06:34:49 am
content: Quote from: TurboTom on March 31, 2018, 12:40:32 amThanks, I somehow did not notice this. I will correct. Most likely the error is not in the palette. Probably in my converter pic <-> bmp (16bit / 24bit) is not quite correctly converted. This error should not influence the operation of the device.

author: DC1MC
author_rank: Super Contributor
timestamp: March 31, 2018, 06:43:13 am
content: Quick naive question @konnor, is this firmware suitable for the MSO1000Z series ?Thanks,DC1MC

author: ebastler
author_rank: Super Contributor
timestamp: March 31, 2018, 06:43:36 am
content: Quote from: konnor on March 31, 2018, 06:34:49 amSo you seem to have gone deeper into the firmware than just patching bytes in the binary, right? I would love to learn a bit more about your approach. Could you open a new thread and describe how you did this, please?(Also, as others have mentioned above, being able to "trick" the scope into accepting any firmware versions, including downgrades to older versions, would be a feat of its own. And you mentioned something about generating keys independent from serial numbers, which I'm sure would also interest quite a few people here...)Thank you for the work you have done, and for sharing the results with us. And thank you in advance for sharing some of the background!

author: Wirehead
author_rank: Regular Contributor
timestamp: March 31, 2018, 04:37:44 pm
content: Awesome work being done

author: janekivi
author_rank: Frequent Contributor
timestamp: March 31, 2018, 07:20:05 pm
content: Quote from: Adrian_Arg. on March 31, 2018, 03:03:32 amYou definitely haven't seen our thread...https://www.eevblog.com/forum/testgear/rigol-dsxxxx-gel-firmware-file-format/msg1453156/#msg1453156

author: Adrian_Arg.
author_rank: Frequent Contributor
timestamp: March 31, 2018, 07:40:39 pm
content: my English is not good, so I understand you have to do it yourself, but I do not understand that, that's why I asked Konnor if he did not have the latest firmware version of the rigol ds1054z with the correction of the word pulses

author: konnor
author_rank: Regular Contributor
timestamp: March 31, 2018, 07:47:09 pm
content: I did not engage in the reverce-engineering of those 8 kilobytes of operations with long integers. I use the original firmware signature and adjust the firmware so that the codes match. The current firmware is laid out in a separate thread.

author: janekivi
author_rank: Frequent Contributor
timestamp: March 31, 2018, 07:59:09 pm
content: We did it exactly the same way but finally we like to make new footer and test morebefore we release something reliable.

author: ankerwolf
author_rank: Regular Contributor
timestamp: March 31, 2018, 08:03:40 pm
content: Simply rename the.01.zipto.z01and open the .zip with any packer (WinRAR, 7zip, ...).

author: rob040
author_rank: Contributor
timestamp: March 31, 2018, 08:21:35 pm
content: Quote from: ankerwolf on March 31, 2018, 08:03:40 pmYessss, that does the trick. Thanks!

author: Payne
author_rank: Newbie
timestamp: April 09, 2018, 06:56:40 am
content: New bug found?Hi all,When I do the following, something weird happens with the vertical position of the signal line:Set VerticalRef = Center (Utility, System)No probes connectedSet vertical sensitivity to 5VCenter the vertical line to 0VCenter the trigger point to 0VSet vertical to -5VSet trigger point to -5VNow turn the vertical sensitivity knob to 2V, 1V, 500mVWhen you turn to 200mV (and even lower), the trace will appear on the screen again (but it should have been close to the floor in your room!)I can reproduce this error also with other settings for the Y-axes sensitivity and other channelsRigol DS1054zSW: 00.04.04.SP3Board: 0.1.4

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 09, 2018, 07:42:06 am
content: I can not reproduce that on my scope. The trace leaves the screen (yellow line glued to the bottom) in all Vscale settings.Edit: Same board revision by the way, Rigloled DSER.Boot: 0.0.1.4FW: 0.2.3.11

author: Payne
author_rank: Newbie
timestamp: April 09, 2018, 07:53:47 am
content: Try to set the probe for CH1 at 1x, then it should be there!

author: Fungus
author_rank: Super Contributor
timestamp: April 09, 2018, 08:02:13 am
content: Quote from: Payne on April 09, 2018, 06:56:40 amYou hear that click as you go to 200mV? That's a clue that the 'scope switched ranges there.If the line is in the wrong place in those ranges it means you need to run calibration on your scope.

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

author: RoGeorge
author_rank: Super Contributor
timestamp: April 09, 2018, 08:17:00 am
content: At the beginning, the trace is in the middle of the screen.When setting the trace to -5V, the trace is displayed one division lower than the middle of the screen.When scale is set to 2V, the trace is 2.4 divisions lower than the middle of the screen.When scale is set to 1V, the trace is at the bottom of the screen.When scale is set to 500mV, the trace is still displayed at the bottom of the screen. Is this "the bug"?This is expected, because when the trace is supposed to be out of screen, the oscilloscope still displays the trace as a line at the most upper or lower side of the display area. For example, if you signal is "out of the screen" only some areas, you will not see an interrupted trace. The displaying of a trace is always bounded by the upper or by the lower screen area.Other said, if a trace should be represented "1 meter under the display", the oscilloscope will still draw a continuous line at the most lower pixels of the display. It is not like on an analogue display where the trace completly dissapear when it is too high or too low. This is not a bug, it was always like that, it was debated before and many people prefer to see a line at the extremes of the display rather than seeing the trace completely disappearing.To be sure a waveform is correct, never let the trace to touch the most upper or the most lower pixels.

author: Payne
author_rank: Newbie
timestamp: April 09, 2018, 08:28:42 am
content: RoGeorge, you get the problem when you set to 200mV, the trace will suddenly appear again.Yeah, I know the problem maybe is a bit academically, but still it is strange and confusingActually, you can go out of the borders, and still have a nice trace, because the DS1054z works internally with 10 vertical divisions but only show/zoom into 8 divisions

author: JohnPen
author_rank: Regular Contributor
timestamp: April 09, 2018, 08:43:44 am
content: I am not able to reproduce the problem on my scope. (No probe connected and X1 setting). As mentioned by Fungus there is a relay click when changing sensitivity to the 200 mV range and the trace stays glued to the bottom of the graticule.Whilst typingthis comment and having let the scope warm up fully I now get a different effect! On switching to the 200 mV range the trace now reappears in the middle of the screen and then progresses positively towards the top of the graticule. Increasing the sensitivity to 20 mV the trace glues to the top of graticule and remains there for further increases of sensitivity.Strange that it was different from initial startup but behaviour not unreasonable for for offsets hitting the stops of the ADCs. Presumably the F/W could have covered these extremes by covering <=200 mV ranges in the same way as 500 mV.If it is off the screen usually you turn the sensitivity down until you see the trace again but I suppose one could be confused under some circumstances.

author: Fungus
author_rank: Super Contributor
timestamp: April 09, 2018, 08:46:40 am
content: Quote from: frozenfrogz on April 09, 2018, 07:42:06 amNor me.

author: ebastler
author_rank: Super Contributor
timestamp: April 09, 2018, 08:59:53 am
content: Quote from: Payne on April 09, 2018, 08:28:42 amIt has been mentioned before: For ranges of 200mV and below, the offset range is only +- 2V. As you have set a larger offset, the scope must do "something" to get back into the available operating range. Not sure what it does exactly, since I don't have the scope in front of me. Does it reset the offset to zero? In any case, not a bug.Quotehttps://www.batronix.com/pdf/Rigol/UserGuide/DS1000Z_UserGuide_EN.pdf, page 17-2EDIT: fixed the link

author: ankerwolf
author_rank: Regular Contributor
timestamp: April 09, 2018, 09:11:21 am
content: Hello,what ist the problem?Beginning at 5V/div, open BNC, set trace to -5V >> 1 div under middle.Changing to 2V, 1V, ...nothing happens, the trace ist stable 1 div under middle!LG Wolfgang

author: JohnPen
author_rank: Regular Contributor
timestamp: April 09, 2018, 09:22:11 am
content: A little more detail on the display readings for <200 mV. On my scope the 200 mV range the display shows plus 100 mV with the aforementioned -5 volt offset input. Increasing sensitivity to 100 mV doubles on the display similarly for 50 mV the display implies reading 100 mV. 20 mV as referred to in my previous comment hits the top of the graticulecorrectly. So I suppose one could get confused. Incidentally if one has a signal on the input it reappears as well for <=200 mVbut no chance of triggering.

author: JohnPen
author_rank: Regular Contributor
timestamp: April 09, 2018, 09:25:51 am
content: Hi ankerwolf,Did you Set VerticalRef = Center before doing the test?

author: ankerwolf
author_rank: Regular Contributor
timestamp: April 09, 2018, 11:28:36 am
content: Hi,Quote from: JohnPen on April 09, 2018, 09:25:51 amNo, but now: Normal action: left and right cursor changed if out of range. That ist absolut normal.LG

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: April 09, 2018, 12:22:34 pm
content: As already stated by ebastler, offset ranges are restricted.From the manual you can see: 1mV/div .. 499mV/div: +/- 2V500mV/div and above: +/- 100VI would not consider it a bug but more of a user error though one might argue what the proper representation of "hey, that setting does not compute" could be.

author: tv84
author_rank: Super Contributor
timestamp: May 12, 2018, 04:24:36 pm
content: The decrypted release notes of the new firmware Rigol DS1000Z 00.04.04.03.05 2018-05-09 is here:https://www.eevblog.com/forum/testgear/new-firmware-ds1000z-00-04-04-03-05-2018-05-09-(2018-02-28)/msg1534916/#msg1534916

author: RoGeorge
author_rank: Super Contributor
timestamp: May 17, 2018, 11:51:54 am
content: The 1GSa/s, or the full 24Mpts memory, are possible to select only for CH2 alone (or for no channels at all).If CH1 alone is selected, the maximum sample rate is 500MSa/s, and the maximum memory is 12 million samples. My current SW version is 00.04.04.03.02Is 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?

author: Karel
author_rank: Super Contributor
timestamp: May 17, 2018, 12:02:55 pm
content: Quote from: RoGeorge on May 17, 2018, 11:51:54 amIt'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).

author: BravoV
author_rank: Super Contributor
timestamp: May 17, 2018, 12:40:00 pm
content: Quote from: Karel on May 17, 2018, 12:02:55 pm+1 , same here at my DS1104Z-S.

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

author: metrologist
author_rank: Super Contributor
timestamp: May 17, 2018, 06:03:09 pm
content: You may want to use a channel for triggering but not care to see the triggering signal. You are still using the channel, just not displaying the data.

author: RoGeorge
author_rank: Super Contributor
timestamp: May 17, 2018, 06:25:21 pm
content: Quote from: JohnPen on May 17, 2018, 05:50:55 pmThat was it, the trigger source must be on the same channel (or on AC Line). Didn't know that.I noticed that the trigger still works even when set on a disabled channel, so it might be useful to trigger on a rare event from another channel, then sample a different signal with full 24 Mpoints, but I wouldn't call that a bug. I think that was a design choice. In my case it just happened that my trigger was left on CH2 from some previous measurements. My bad, sorry.Thank you all for taking the time to test this.

author: JohnPi
author_rank: Regular Contributor
timestamp: September 02, 2018, 08:05:51 pm
content: I have a new bug (I posted this as a separate topic earlier; I'll try to delete that post):I am trying to read binary waveforms from my 1054Z using pyvisa over USB. Using sockets over LAN (not pyvisa) works. I have a problem when reading certain specific lengths of data from the instrument -- specifically lengths of 8244 and increments of 64 beyond; using MDEPTH of 30000. I don't know if the issue is in the instrument or pyvisa. I have filed a ticket athttps://github.com/pyvisa/pyvisa/issues/354also. 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.SP3If anyone has the same setup, perhaps with different software/firmware versions, I would appreciate if you could run this example and report:Code:import visaimport numpy as npimport sysimport reprint(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 lineDS1054Z = GPIB.open_resource([_ for _ in GPIB_Resources if re.search('^USB.*:DS.*INSTR$', _)])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 beyondprint(NPOINTS, end='')err+=1DS1054Z.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=0print(len(CURVE1), "chars")DS1054Z.read_bytes(1) # trailing '\n'This tests reading lengths from 8200 on in increments of 1. I see fails like this:Code:8241> b'#9000008241' <8241 chars8242> b'#9000008242' <8242 chars8243> b'#9000008243' <8243 chars8244> b'#9000008244' <Error at 8244 after 82438243 chars8245> b'#9000008245' <8245 chars8246> b'#9000008246' <8246 chars8247> b'#9000008247' <8247 charsand filtered, the patterns looks like:Code:Error at 8244 after 8243Error at 8308 after 64Error at 8372 after 64Error at 8436 after 64Error at 8500 after 64Error at 8564 after 64Error at 8628 after 64Error at 8756 after 128Error at 8820 after 64Error at 8884 after 64Error at 8948 after 64Error at 9012 after 64Error at 9076 after 64Error at 9140 after 64Error at 9268 after 128Error at 9332 after 64Error at 9396 after 64Has anyone seen anything similar to this ?

author: Karel
author_rank: Super Contributor
timestamp: September 03, 2018, 10:56:33 am
content: Quote from: JohnPi on September 02, 2018, 08:05:51 pmAre you claiming that you have found a new bug in the scope's firmware?I'm asking because DSRemote seems to work fine when downloading binary waveforms via USB.

author: JohnPi
author_rank: Regular Contributor
timestamp: September 03, 2018, 12:36:03 pm
content: I looked through that code (I don't have a convenient system to build/run it on)-- it appears to download either 1200 or 250000 bytes. My problem is when downloading 8244+n*64 only -- 250000 is not an issue in that.My problem arose when I was specifically downloading different lengths in the range below 30000; it arose from old habits of being frugal with memory. I changed my own code to download 8000 byte chunks, but I guess I could just download a single 30000 byte block and truncate it.In the end, I don't know if this ia Rigol or a pyvisa bug.p.s. I updated my example above to select the USB instrument more easily.

author: MarkF
author_rank: Super Contributor
timestamp: September 03, 2018, 12:54:33 pm
content: 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.

author: JohnPi
author_rank: Regular Contributor
timestamp: September 03, 2018, 04:19:50 pm
content: @PeDre - thanks for checking. I see it works for you at 8244. What is that program you used ?When I run my pyvisa program with different values for chunk_size:DS1054Z = GPIB.open_resource([_ for _ in GPIB_Resources if re.search('^USB.*:DS.*INSTR$', _)],chunk_size=3000)it doesn't appear to fail as often, but there are definite slow downs at some points (watch the results scroll by) -- they appear to be at 64-count intervals. In my case, starting at 8200:for NPOINTS in range(8200,30100):# fails at 8244 firstgives a slowdown (but not a fail) at 8226.3.6.5 |Anaconda, Inc.| (default, Mar 29 2018, 13:32:41) [MSC v.1900 64 bit (AMD64)]visa 1.9.1

author: JohnPi
author_rank: Regular Contributor
timestamp: September 03, 2018, 04:42:22 pm
content: Quote from: MarkF on September 03, 2018, 12:54:33 pmYes, USB. I have tried with the LAN with longer lengths with no problems. I haven't tried this code over the LAN -- will do (it appears you have to reboot the scope to switch from USB to LAN).-- update: - I can't get my pyvisa to work over the LAN. Anyone know the magic resource name ? IP = 10.1.0.54, port = 5555Code:GPIB = visa.ResourceManager()DS1054Z = GPIB.open_resource('TCPIP0::10.1.0.54::5555::INSTR')print("DS1054Z:", DS1054Z.query("*IDN?"))failsDon't know how to change the OS buffer size. There is a chunk_size option in pyvisa which has an impact -- it moves the starting point of the issue around, but doesn't eliminate the issue.

author: Hauke
author_rank: Newbie
timestamp: December 29, 2018, 07:15:48 pm
content: Hi all,for me the password login rigollan/111111 or test/111111 never worked, and since the headline post of this thread states that this problem should be gone with the current firmware version, I updated and tried again; no success. But this finally worked for me:Connect to the scope via http://[IP-Address]Select "Security"Enter as old password: 111111Enter as new password again: 111111 (twice)Confirm --> Success messagelog in with any username with four or less letters, pw 111111 --> Works!So I used as username test, blah, 1234, a - all worked. 12345 or rigollan or rigolan did not work.No idea why my scope behaves differently as others, but from the forum I find others that used test and blah also successfully.Whatever - /me is happy now.CheersHauke

author: ankerwolf
author_rank: Regular Contributor
timestamp: January 01, 2019, 03:39:47 pm
content: Hello,I posted sometimes:With the last Version 00.04.04.03.05 the login is now working with:username:rigolanpassword: 111111LG Wolfgang

author: Hauke
author_rank: Newbie
timestamp: January 04, 2019, 06:17:15 pm
content: Hi Wolfgang,sorry to say: But not for me. It is as I write: any four letter (or shorter) username works, anything 5 digits plus: No success.Or are we talking about different logins? I refer to accessing http://[IP of the scope]/, and then hitting "Network settings". Where do you refer to?CheersHauke

author: Karel
author_rank: Super Contributor
timestamp: May 24, 2019, 11:04:51 am
content: Quote from: PeDre on May 24, 2019, 07:15:07 amDoes the same happen when using DSRemote?At this moment I don't feel like upgrading the firmware of the scope...

author: RoGeorge
author_rank: Super Contributor
timestamp: May 24, 2019, 11:41:18 am
content: Quote from: PeDre on May 21, 2019, 05:51:29 amNo, because you gave no "Steps to reproduce" the error.Quote from: PeDre on May 24, 2019, 07:15:07 amNo, because you still didn't give any "Steps to reproduce" the failure.

author: Karel
author_rank: Super Contributor
timestamp: May 25, 2019, 07:05:16 am
content: Quote from: PeDre on May 24, 2019, 05:24:04 pmFrom the webpage of DSRemote:Quote

author: Karel
author_rank: Super Contributor
timestamp: May 26, 2019, 07:28:59 am
content: I'm glad to hear that you found a solution/workaround.If I may say so, the firmware of the DS1000Z is a big unreliable mess.(But still, a great value hobbyists scope for an excellent price.)

author: RoGeorge
author_rank: Super Contributor
timestamp: May 27, 2019, 11:46:15 am
content: 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).

author: Karel
author_rank: Super Contributor
timestamp: May 27, 2019, 03:38:31 pm
content: Quote from: PeDre on May 27, 2019, 02:56:49 pmI can confirm that. Unfortunately...

author: rob040
author_rank: Contributor
timestamp: August 12, 2019, 11:30:35 am
content: Not sure if every DS1000Z owner is following/reading all related threads, but to keep this one a little bit up-to-date, the latest SW is now:v00.04.04.04.03 2019/05/30- Fixed the wave error when STOP and changing Timebase

author: frozenfrogz
author_rank: Frequent Contributor
timestamp: August 12, 2019, 11:34:29 am
content: Sorry, I have been pretty busy lately and did not follow the forums much.I will update the OP with links to the latest firmware. Can someone tell what bugs have been fixed (that are still listed as bugs) so I can put it into the OP also?Thank you!

author: BravoV
author_rank: Super Contributor
timestamp: December 28, 2019, 08:30:05 pm
content: Add here for future reference, a broken DS1054Z gets repaired. Also its posted in a non DS1054Z thread.Problem->https://www.eevblog.com/forum/testgear/rigol-red-screen-of-death/msg2847804/#msg2847804How its repaired->https://www.eevblog.com/forum/testgear/rigol-red-screen-of-death/msg2847918/#msg2847918->https://www.eevblog.com/forum/testgear/rigol-red-screen-of-death/msg2848050/#msg2848050

author: rob040
author_rank: Contributor
timestamp: October 29, 2021, 04:03:51 pm
content: The latest update was already on the Chinese website for some time, but now also available in the US, version 00.04.05.02.00!v00.04.05.02.00 2021/07/24- Version Updated.-------------v00.04.05.01.00 2021/06/01- Modify the vertical Display.v00.04.05.00.00 2020/12/29- Add and modify some measurement functions- Modification of math problem- Modify some SCPI instruction errors- Modify some trigger problems.I haven't tested it yet.Edit: On the Chinese website it's already v00.04.05.02.02...

author: Adrian_Arg.
author_rank: Frequent Contributor
timestamp: October 30, 2021, 12:30:01 am
content: 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!

author: MarkF
author_rank: Super Contributor
timestamp: October 30, 2021, 01:59:45 am
content: Quote from: Adrian_Arg. on October 30, 2021, 12:30:01 amMore detailed change history:https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg3745558/#msg3745558

author: Adrian_Arg.
author_rank: Frequent Contributor
timestamp: October 30, 2021, 02:54:55 pm
content: I read the list from version 00.04.05.02.00 onwards, and it scares me to update, it corrects a lot of errors, but what it can create scares me more, for something they still did not correct the 24bit deep, they do not want to think about what would happen !!

author: DC1MC
author_rank: Super Contributor
timestamp: October 30, 2021, 03:10:58 pm
content: Quote from: Adrian_Arg. on October 30, 2021, 02:54:55 pmI 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

author: Adrian_Arg.
author_rank: Frequent Contributor
timestamp: October 30, 2021, 03:49:56 pm
content: Quote from: DC1MC on October 30, 2021, 03:10:58 pm

author: DC1MC
author_rank: Super Contributor
timestamp: October 30, 2021, 03:55:29 pm
content: Quote from: Adrian_Arg. on October 30, 2021, 03:49:56 pmI've installed it on a MSO1074Z (I can provide pictures if needed), I was having exactly zero issues: the procedure was:Installing -> Power Cycling -> Factory Reset -> Calibration -> Other tests regarding the the behavior.Everything went A-OKEDIT: The firmware was taken from here:https://www.rigolna.com/firmware/and I've used the DS1000Z version, suitable for my scope.DC1MC

author: Adrian_Arg.
author_rank: Frequent Contributor
timestamp: October 30, 2021, 04:21:05 pm
content: On the sixth try I calibrate, I really don't know what happened to the baby, gracias DC1MC

author: DC1MC
author_rank: Super Contributor
timestamp: October 30, 2021, 04:56:46 pm
content: Quote from: Adrian_Arg. on October 30, 2021, 04:21:05 pmNo hay de qué.

author: Njk
author_rank: Frequent Contributor
timestamp: November 22, 2022, 12:25:02 pm
content: Greetings!DS1054Z is a new instrument to me. Owned Tek TDS3054B previously. In comparison, Rigol seems noisy but it also has more memory, more SW candies so it has its pros and conrtras, as usual. The scope is of its latest HW generation (I presume), board version 0.1.4.I've enabled all the options, including 500 uV/div (which works fine, BTW, taking its limitations into account) and installed the firmware of the day, v.00.04.05.SP2.Now I'm evaluating the FFT capabilities. It's not essential feature for a scopes but anyway.In DS1000Z, the FFT function can operate in two modes, the Trace mode and the "Memory*" mode. The Trace mode looks like a finished product, At least, it works in a consistent manner. But it's actually a legacy mode, with poor resolution in the frequency domain. The user's manual for MSO5000 series provides better coverage for the matter.FFT resolution = (FFT sampling rate) / (points number)In the Trace mode, the FFT function fetches a points from the display memory, so the FFT sampling rate is actually equal to the beam sweep data rate, 100/(T scale) in points/s, and the points number is equal to 1200 (12 horizontal grid divisions, 100 two-pixel point images per division). From that, max. theoretical FFT resolution bandwidth for each T scale can be calculated. For instance, on the smallest T scale:5 ns/div -> 20 GPts/s -> 16.666 MHz, while the finest FFT F scale setting is 20 MHz/div.On the largest T scale (not considering the slow sweep scales):100 ms/div -> 1 kPts/s -> 0.83 Hz, while the finest possible F scale is 1 Hz/div.So in the Trace mode, on each T scale, the FFT resolution is almost equal to the smallest F scale. Not good, but it would be pointless to try to increase the resolution adding some AI rather than more data, because that would likely result in even more poor spectrum plot. Instead, Rigol finally decided to implement fetching a points from the acquisition memory in their entry level scopes, adding the "Memory*" mode in DS1000Z. In that mode, FFT sampling rate is equal to the instrument's current sampling rate, and the max. points number is equal to 16K, which is about 14 times greater, allowing for a much more accurate FFT.Specifically, there are two features in DS1000Z, that sources their input data in the acquisition memory, the Frequency Counter, and the FFT function. The Counter works fine, but my experience with FFT in the Memory mode is mixed. I've a feeling that there is a large room for improvement in the SW.For instance, the book reads "You can adjust the center frequency and horizontal scale at the same time using the horizontal scale knob". It's natural for a user to expect that the displayed readings for the frequency and sampling rate FFT scales will change accordingly. In the Trace mode, that's in fact so. In the Memory mode, when the instrument's sampling rate has changed by the T scale knob rotation, the readings does not change. More precisely, sometimes they changes, sometimes not and sometimes they changes in wrong way. It's not consistent, and the only reliable way to update the readings is to turn the FFT function off and on again, losing all the cursors, configured for the Math window.But that's the most innocent defect, though it's annoying. On rare occasions, the spectrum trace does not appear at all when the function has cycled on/off/on. Typically, it does, and in that case I've noticed similar inconsistency trying to control the FFT settings. With the same combination of sample rate, mem depth and T scale, sometimes it's possible to configure FFT for desired center frequency and scale, sometimes not, because of too high granularity or because the banner "Parameter Limited!" pop-ups.I'm failed to figure out a pattern so far. Perhaps it depends on how lucky the scope was at the boot time or how long the user played with the buttons and knobs. Once I witnessed the "Memory leak in FFT" pop-up message. Something is definitely wrong there. Poor software, but it's good enough to make a problems difficult to report because of the sometimes keyword.I'm hoping someone here who has more experience with that instrument can provide more insights so we can work out a meaningful communiqu to Rigol's attention.---WBR

author: Njk
author_rank: Frequent Contributor
timestamp: November 24, 2022, 12:15:39 am
content: Ok, found a way to navigate around the defects and use the feature.The trick is in proper sequence. When you'd initially switched to the Memory mode, it's necessary to set the Center frequency at zero, and then set the F scale as desired. Then you can set desired center frequency. Otherwise, it could not be possible because of high granularity of allowed center frequency values. Pretty weird. Looks like missing initialization.A post without images looks boring now. This is the FFT plot for 1 V 1.1 kHz sine wave signal (img0.png):" alt="" class="bbc_img" />Notice the discrepancy in measured amplitude values between the FFT and the RMS item. It's a pure sine wave from a pure analog high quality signal generator, there are no other harmonics, why the 3 dBv difference?, Actually, it's also weather-dependent, could be 0 dB on another day. Perhaps a calibration issue, that's Rigol, never mind.It's interesting the amplitude value calculated by the FFT can be more accurate, probably because it uses data from the acquisition memory (img1c.jpg):" alt="" class="bbc_img" />The Frequency counter also seems working fine for that frequency (img2c.jpg):" alt="" class="bbc_img" />Finally, let's increase the amplitude above the channel's clipping level to see the harmonics (img3.png):" alt="" class="bbc_img" />Edit: actually, the interdependency of Center frequency and F scale settings is documented, but in the user's manual for DS2000A series: "Note: Setting the horizontal position can changing the center frequency of the FFT operation results indirectly."---WBR

author: Njk
author_rank: Frequent Contributor
timestamp: November 27, 2022, 01:35:54 pm
content: Another puzzle. What prevented Rigol from (optionally) dismissing the input signal trace for full screen FFT plot? Displaying both of them can result in total mess on the screen.Found a workaround. Switch the display in the Dots mode and reduce the beam intensity down to zero. Fortunately, the intensity control does not affect a math traces. For better effect, play with the acquisition mode setting (seemingly it does not affect FFT when it's at the Memory mode). The result: a nice full-screen view." alt="" class="bbc_img" />My apologizes if that trick is long time obvious.---WBR

author: tautech
author_rank: Super Contributor
timestamp: November 27, 2022, 01:40:51 pm
content: Don’t these have a Exclusive FFT mode that doesn’t show the source waveform ?

author: RoGeorge
author_rank: Super Contributor
timestamp: November 27, 2022, 02:01:32 pm
content: That's a nice trick, I don't think DS1054 has the option to display FFT only.In fact, the FFT functionality in Rigol DS1054Z is unusable in practice. It works, but it's too cumbersome to operate the settings, too low resolution, and too slow to make any use of it, other than maybe a didactic demonstration.The most useful trick with FFT on DS1054Z is to avoid the FFT entirely.

author: Njk
author_rank: Frequent Contributor
timestamp: November 27, 2022, 02:04:04 pm
content: Quote from: tautech on November 27, 2022, 01:40:51 pmNo and that's the problem---WBR

author: Njk
author_rank: Frequent Contributor
timestamp: November 27, 2022, 02:15:35 pm
content: Quote from: RoGeorge on November 27, 2022, 02:01:32 pmIt could be better but I'm trying to be positive. Some niche areas, e.g. education..---WBR

author: Fungus
author_rank: Super Contributor
timestamp: November 27, 2022, 02:42:21 pm
content: Quote from: RoGeorge on November 27, 2022, 02:01:32 pmItdoeswork, but it takes aLOTof fiddling with the parameters.Then if you change the timebase for a different signal you pretty much have to start over.The DS1054Z isn't the 'scope for you if FFT is something you use a lot. This has never been a secret.

author: Njk
author_rank: Frequent Contributor
timestamp: November 29, 2022, 02:36:42 pm
content: Quote from: Fungus on November 27, 2022, 02:42:21 pmI was of the same opinion, initially. But now I've to say that actually it's an efficient and elegant UI design, for given environmental constraints. I can't propose anything better (maybe the now popular touch screen technology provides more opportunities, but its advantages are offset by a scratched screen surface, dirty with fingerprints. Not everybody likes that). It's something like a scientific calculator, which uses stack-oriented input notation. Clumsy and inconvenient, but only to those without the idea. To all others, it's very convenient and super efficient.What is really missing is the documentation. Every new user have to learn how it work. BTW the similar situation is in open source. Looks like the OSS guys are playing their game preventing the things from easy commercialization by competitors. But the Chinese are not dumb, they're thinking in they own way. Perhaps it's as difficult for them to explain something to a westerner, as it was for me to locate an affordable restaurant with casual European kitchen in Taipei. So omission is they favorite game as well.Concerning the FFT function, the problem is how to configure the two numerical values, the frequency scale (Fscale) and the central frequency (Fc). The latter ranges from zero to the FFT sampling frequency divided by two. It's quite a bandwidth and if you want to achieve high precision and to avoid inconvenience and excessive mechanical wear, two tuning methods are requited, coarse and fine. But there are two controls in all, one is for Fscale and the other is for Fc. Instead of adding one more control, Rigol had decided to overload the existing controls with tuning method selection.For each FFT sampling frequency, six Fscale values are available. Each Fscale value is associated with unique Fc increment/decrement (step) value. Consider 1 GSa/s sampling frequency as an example:Fscale = 1 MHz -> Fc step is 20 kHz;Fscale = 2.5 MHz -> Fc step is 50 kHz;Fscale = 5 MHz -> Fc step is 100 kHz;Fscale = 10 MHz -> Fc step is 200 kHz;Fscale = 25 MHz -> Fc step is 500 kHz;Fscale = 50 MHz -> Fc step is 1 MHz.The Fc value can be set in the range of 500 MHz with 20 kHz precision. The procedure is as follows:1. Select the highest Fscale value. Coincidentally, pressing the multi-function knob for Fscale does just that.2. Tune close to desired Fc. That's coarse tuning.3. Select the finest Fscale.4. Tune exactly to desired Fc. That's fine tuning.5. Finally, set Fscale at desired value.That's it.---WBR

author: Njk
author_rank: Frequent Contributor
timestamp: December 06, 2022, 11:39:57 pm
content: That's funny, my FFT experiments resulted in the scope's death. The RSoD syndrome. Definitely I'm not the first one. There is an advisory note of Aug 1, 2022 at the Rigol NA web site with the procedure the user is advised to follow in that case before service application. Did not worked. The Rigol FAE guy was confident that the problem will be easy to fix. Then he realized that in my case they have to order a replacement main board from China.In the thread about MSO5000 the users reported that the scope is quite hot when operating. It was not like that, butInevertookthe unit apart to check how hot theparts are. So it might be a coincidence---WBR

author: Njk
author_rank: Frequent Contributor
timestamp: February 27, 2023, 08:29:00 am
content: The scope is back after main board replacement.State of the art version data, for reference.Board version: 1.0.4Extended information (menu menu force menu):SW version: 00.04.05.02.03Boot version: 0.0.1.9FW version: 0.2.3.12CPLD version: 1.1Build date: Feb 15 2022 15:54:18 | 0 0:0/ 0 0:30At first glance, it works not worse, not better. Failed to get release notes for this SW version.

author: rob040
author_rank: Contributor
timestamp: February 27, 2023, 11:13:15 am
content: According to me SW version 00.04.05.02.03 has not been published (yet).Latest was/is: 00.04.05.02.02.

author: Njk
author_rank: Frequent Contributor
timestamp: February 27, 2023, 12:57:41 pm
content: Quote from: rob040 on February 27, 2023, 11:13:15 amThat's why I'd asked the local Rigol rep about the release notes. But he also has no information

author: Adrian_Arg.
author_rank: Frequent Contributor
timestamp: February 27, 2023, 01:28:57 pm
content: Quote from: Njk on February 27, 2023, 12:57:41 pmHello, see if this problem was corrected, with the new virmware that you installed. there I give you the linkhttps://www.eevblog.com/forum/testgear/rigol-1054z-and-1074z-timing-problems-at-500ms-timescale-and-24m-memory-depth/

author: Njk
author_rank: Frequent Contributor
timestamp: February 27, 2023, 01:58:33 pm
content: No miracle. With that version, I was able to reproduce it

author: Ben23
author_rank: Newbie
timestamp: May 09, 2023, 03:46:11 pm
content: My apologies if this has already been mentioned, but I've skimmed several threads and couldn't find any mention of it, and it's not an easy one to search for.I've just bought the DS1054Z, its software is up-to-date (00.04.05.SP2, or 00.04.05.02.03 in the expanded info view).The bottom two vertical measures in the left sidebar last page are weird."AC.Vrms" does indeed turn on AC.Vrms, but the Help page brought up by that button is "Variance".And then there's "3". What is that supposed to be? The Help for "3" says it's AC.Vrms, but what it actually turns on is Period, which isn't even a vertical measure! The icon suggests it should be some other sort of RMS measurement? Or should it be the missing "Variance"?Also AC.Vrms and a bunch of the horizontal measures don't appear in "Measure All", but I guess they just have a loose definition of "All"...

author: RoGeorge
author_rank: Super Contributor
timestamp: May 09, 2023, 04:09:55 pm
content: Mine is one version behind, 00.04.05.02.02, and it doesn't have any icon on the 6th place. First 4 icons are the same, as in your pics, the 5th is called 'Variance', the last place is empty.What does the help function says about the 6th icon called "3", if you press 'Help' then '3'?

author: Ben23
author_rank: Newbie
timestamp: May 09, 2023, 05:50:35 pm
content: Quote from: RoGeorge on May 09, 2023, 04:09:55 pmInteresting.QuoteIt gives the help for AC.Vrms.

author: Njk
author_rank: Frequent Contributor
timestamp: May 09, 2023, 11:12:38 pm
content: Yep. I confirm the "3" icon with the 02.03 version. Pressing on it results in "Period=" item appearance in the bottom. It's so innocent problem I was not sure it's specific to this version.BTW, my progress in finding the difference is very limited. But from what I've found so far, I think that v.04.05.02.03 is a build dedicated to system stability improvement. With the previous versions, the best way to demonstrate frozen UI was to use FFT. With this version, it does not hang there. That does not mean any FFT defect is fixed. Instead of hanging, the FFT trace just disappears while the scope remains responsive. But after that, the whole math trace "channel" is lost, it's not possible to get a data from the scope (points data, screenshot, etc.), and who knows what else stopped working properly. The scope is not trusted any more and it needs to be power cycled anyway. I don't know what is better. Looks like they don't have access to the low-level FFT code. Perhaps it was received in the binary form with OS/SDK/BSP from Infineon or a third-party vendor. So they can't fix it but the attempt to control the damage is evident.Overall, no news from them over long time. According to the press release, they recently went public. So new leadership, new vision, new priorities, a lot of empty positions in the local office. Add to this the international unrest, the covid scam, the ship shortage. Seems now they have something more interesting to do rather than just to make the things.

author: RoGeorge
author_rank: Super Contributor
timestamp: May 10, 2023, 07:17:06 am
content: My DS1054z is used rather rare, but I don't recall any hangs with the firmware it has, 00.04.05.02.02. Used FFT a couple of times, no hangs. Maybe downgrade back to 00.04.05.02.02 if you find 00.04.05.02.03 to be faultier.For now, I wouldn't upgrade to 00.04.05.02.03, thanks for the warning.