Am I the only one experiencing this?
To help others reproduce the issue, you may try to save the scope setup on a file, and post it (or link it) here.
Is there a bugzilla tracker for rigol bugs yet?Sure there is, our very own Katie started this thread:
Seems like we are spotting a lot of bugs.
Sure there is, our very own Katie started this thread:
https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/ (https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/)
Yes, I see that happening, too but I didn't consider it a bug since it only happens at the very slow timebases; somehow it seemed logical that it would act that way at very slow timebase settings. Also, my "freeze" bug does _not_ seem to happen at these very slow timebases. I don't know where the threshold is but setting to 1 microsecond/division definitely works on mine to cause the freeze bug.
Sure there is, our very own Katie started this thread:
https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/ (https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/)
I'd love to record this bug as soon as I'm able to reproduce it, I always check them myself before adding to the list. For the life of me I can't reproduce this no matter what I do. I'm a bit reluctant to load the settings files that alsetalokin4017 attached in case there's a corruption in there that's causing this lockup issue.
Is there anyone else that can't reproduce this problem?
One other related thing to check: When not zoomed in and showing the DISPLAY menu do you see the Persistence setting gray-out and switch to MIN when the timebase setting is 200ms and longer? The return to normal (still at MIN) when you're back under 200ms?
FW 4.0.3 - can't reproduce the bug. Tried different persistence settings. Don't remember having this issue on 4.0.2 either.
Nope, same result at 1uS/div. UI does seem less responsive, but no lock-ups.
It might be interesting to see if you could access the scope from the PC when it freezes.
Maybe the reproduction steps can be tried after a factory reset, to confirm that it is not related to a customer specific configuration in the scope.
Hmmm... this is pretty strange indeed. We have at least one other person who IS able to reproduce the freezeup, but several others who cannot.
Well, now that I know it can be avoided by using full memory depth, it's not really much of a problem for me, but it certainly is strange that some (at least two!) scopes have the bug and others don't.
Another short video illustrating the issue:
https://www.youtube.com/watch?v=pSTYrMzNzZw (https://www.youtube.com/watch?v=pSTYrMzNzZw)
Just a note: if you touch the screen of the scope with the stylus, don't you scratch the screen? :)
I am usually very careful in touching the screen of my scope, multimeter or laptop.
When you are using a PDA, then of course the screen is designed for using a stylus, that's a different case :)
Hmmm... this is pretty strange indeed. We have at least one other person who IS able to reproduce the freezeup, but several others who cannot.
Well, now that I know it can be avoided by using full memory depth, it's not really much of a problem for me, but it certainly is strange that some (at least two!) scopes have the bug and others don't.
(video linked up above)
What's the date of calibration for your scope? Mine's March 4, 2015, and I only took delivery of it yesterday. It's the closest thing I can think of to a "build date", something we could use to determine roughly when these were made.
My DS2000 was also freezing all the time when I first got it, it was really annoying I would get a lock up every 20 minutes on average, firmware upgrade to 3.0.3 solved the issue. The version that was buggy was 3.0.0. Since I upgraded to 3.0.3 I only had one lock up of the UI in 3 months.
Same on my brand new DS1054Z (4.02.SP4 as yet un-hacked). Mine will freeze after changing Persistence setting at anything faster than 20uS with Mem-Depth at Auto when put into Zoom mode. Changing from Auto to the maximum 24M (why is my unhacked 1054Z saying 24M? [edit: oh yeah - it's still on the Trial - doh!]) stops it freezing as reported above.
Oddly, it took me several tries before I was able to make it freeze, but it does it every time now.
I have also just made it freeze by changing the Persistence value while it was in Zoom mode @ 1us/div.
And again @ 20us - but this time I had to change the Persistence twice - it froze when I hit the button the second time to change it...
I think I'll let Rigol sort out the actual issue! Will just have to remember to keep it at 24M as suggested until Rigol sort it out (assuming it is firmware which I guess is most likely).
Is there no soft-reset for the scope - a combination of key-presses?
Cheers, Bob.
Hmmm... this is pretty strange indeed. We have at least one other person who IS able to reproduce the freezeup, but several others who cannot.
Well, now that I know it can be avoided by using full memory depth, it's not really much of a problem for me, but it certainly is strange that some (at least two!) scopes have the bug and others don't.
(video linked up above)
What's the date of calibration for your scope? Mine's March 4, 2015, and I only took delivery of it yesterday. It's the closest thing I can think of to a "build date", something we could use to determine roughly when these were made.
The cal cert says 16 Jan 2015.
I don't know if you've read about the "saga". We ordered the scope in early February, and due to backorder and longshoreman's strike, I didn't have a delivery until the first week of April. (I don't remember the exact dates offhand). This was "scope 1" which turned out to have a bad glitch on CH4. So after consulting with a Rigol tech and the folks at TEquipment I sent that one back and was shipped a "new" one from TEquipment. But... some alarms went off about the replacement "scope 2".
First, the packaging. There was only one box, it was not double-boxed like the first one and like the ones you see "unboxing" on YT videos. What happened to the outer box?
Second, the serial number. The "new" scope had an _earlier_ SN than the one I returned, by quite a bit of numbers. This didn't make sense to me, as all of TEquipment's stock at that time should have been from the container they received at the end of March.
Third, there were some minor differences in how the "feel" (control response timing) was compared to my memory of what the first scope felt like. Later I put that down to my imagination but now I'm not so sure any more.
And as we see now, the calibration date was in January, which fits with the early SN.
So I'm wondering what to make of all this. Is the scope I got as the "replacement" a lemon, not too bad to toss out like the first one but still not quite 100 percent "right"?
...
I think I'll let Rigol sort out the actual issue! Will just have to remember to keep it at 24M as suggested until Rigol sort it out (assuming it is firmware which I guess is most likely).
...
Thanks for that report, Bob! Now maybe Rigol will notice, especially if others can report the same bug.
...
I do remember reading a few lock up complaints on the 2000 but nothing like I experienced. I have a DS2072A so maybe it was just limited to that revision and the firmware it shipped with.My DS2000 was also freezing all the time when I first got it, it was really annoying I would get a lock up every 20 minutes on average, firmware upgrade to 3.0.3 solved the issue. The version that was buggy was 3.0.0. Since I upgraded to 3.0.3 I only had one lock up of the UI in 3 months.
Did other 2000 owners also have the same problem? I'm still waiting for more reports of this bug, most people don't seem to be reproducing it. If it's down to just mine, or a few from a short production run maybe, then I don't expect Rigol would fix it in a firmware update.
I'm also having trouble understanding how this could be a hardware fault, though. The first scope's glitching was obviously in hardware, but this one's a lot more difficult to call. Still, I've now reinstalled the 04.03 firmware again, and tested both with Options "installed" and "uninstalled". (I hate to use the "h" word.) Still the same problem happens.
Well, the closest thing to a "factory reset" is what comes up when one repeatedly presses the 5th dark grey left menu key during bootup, right? The scope comes up in Chinese. So I set English. The 1 us/div and Auto memory depth are set by default already. So I set Persistence to 100 ms, then enter Zoom mode... and it freezes.
I've tried everything suggested in this thread and still can't lock up my 1054z with firmware 4.02. And since we're sort of 50-50 for responders in this thread I'm going to guess that this is somehow due to a hardware variation -- however unlikely that seems.
I'll record this in the bug thread as "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."
Actually... by my count in this thread I am counting 5 who have reproduced the bug (including me) and 4 who have tried and can't reproduce it (including you). So instead of "some users" you could be saying "over half of the users who tried..."
;)
Actually... by my count in this thread I am counting 5 who have reproduced the bug (including me) and 4 who have tried and can't reproduce it (including you). So instead of "some users" you could be saying "over half of the users who tried..."
;)
Oh no, it sounds like we need another poll!
Plus another option: I haven't got a 1054Z but I want to see the results.Actually... by my count in this thread I am counting 5 who have reproduced the bug (including me) and 4 who have tried and can't reproduce it (including you). So instead of "some users" you could be saying "over half of the users who tried..."
;)
Oh no, it sounds like we need another poll!
Heh.. OK I put up a poll, and voted in it. Please everybody check it out and put your vote in!
Heh.. OK I put up a poll, and voted in it. Please everybody check it out and put your vote in!Plus another option: I haven't got a 1054Z but I want to see the results.
Thanks, it was included in another poll recently, that's why I asked.Heh.. OK I put up a poll, and voted in it. Please everybody check it out and put your vote in!Plus another option: I haven't got a 1054Z but I want to see the results.
The forum software has taken care of that; the "View Results" button is right below the actual poll. No need for a "fake" voting option ;-)
What are the exact steps you need to follow from Factory Defaults to reproduce the bug.
You cannot have a bug that only happens with some scopes, that smells like a hardware bug.
I just shot Dave a PM explaining it. We'll see if he has a chance to try it. If he can get it to lock up too, I thought it'd make a fun little video. It really is kind of a strange setup, though. I could see getting in there by accident, but I'm not sure why I'd ever do it on purpose. Maybe looking for a glitch in some comm protocol, or something like that?
Although I voted for "don't have the bug", I do agree that there is something seriously wrong with this mode. I noticed some minor graphical glitches while changing trigger settings, so I tried to take a screenshot of these glitches. It took about 6 minutes to write the image on a usb-stick and the images were corrupted. Tried different usb-sticks - same result.
After the first reboot I did not play around for long but just tried to select Delayed Timebase the persistence had remembered it was 100ms. However on selecting Delayed the screen changed to part display view ie 2 traces but no 'blue - space -blue window' but did not show Delayed ON. This first time everything then froze and no buttons did anything.
After the Fifth button boot up and Chinese start up all worked OK again. Following your suggestion I Set up the 'Frozen mode' again 100ms persistence and 1us Timebase then selected Delayed again. Once again it froze showing the 2 traces as above and Delayed apparently OFF. But this time I left it for some time. After some 10 minutes, I didn't keep watching, the full blue- space-blue window appeared and Delayed suddenly showed up as ON. The scope then continued to operate normally again. It would appear that the s/w has a bug such that it goes through a rather long s/w loop or perhaps it waits for the Memory to Fill up (Currently 24M at 12.0kpts 1GSa/s).
So your thoughts of a long slow response are correct.
Mines been on for quite a while too, now. I'm just going to leave it run while I'm soldering up some products. We'll see if it ever comes back. The fact that the slow ups are occurring, and that it sometimes comes back after a while, might help Rigol track down the problem. Given that people are seeing different behavior depending on the signal going in might even suggest it could have something to do with triggering.
Wow... that is really weird. I have seen some unreasonably long delays in writing a picture to the USB stick if I try to save while the scope is running. Sometimes it is pretty fast but usually not. So now I generally Stop the scope before I save a picture, this seem to work to make it save much faster. If you Stop the scope, do you still get outrageously long delays saving, and corrupted files?After pressing 'Stop' screenshots are saved without problems, graphical glitches disappear as well. Glitches appear on 1uS/div when I change trigger level (notice the blue line at the bottom of the screen).
After pressing 'Stop' screenshots are saved without problems, graphical glitches disappear as well. Glitches appear on 1uS/div when I change trigger level (notice the blue line at the bottom of the screen).
So what is happening here? We have a real mystery.
..
A hardware issue? Some difference at the component level somehow?
[Rigol #$%§ ... !!!]Bad day?
So you've not studied Bud and MarkL's analysis of the 1054z then? :-//[Rigol #$%§ ... !!!]Bad day?
So you've not studied Bud and MarkL's analysis of the 1054z then? :-//[Rigol #$%§ ... !!!]Bad day?
Some of the "nitty gritty" is here and the following page/s:So you've not studied Bud and MarkL's analysis of the 1054z then? :-//[Rigol #$%§ ... !!!]Bad day?
Link please ?
Some of the "nitty gritty" is here and the following page/s:
https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg563330/#msg563330 (https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg563330/#msg563330)
REMEMBER these guys uncovered the design flaws for us all to see. :-+
My sympathy to all who are still in agony about this...:-DD
Thanks for your report. Just to be completely clear.... you did try the following?
1. Display a signal on CH1 from the probe Calibrator, at 1V/div, trigger type Edge, trigger level 2.00 V, sweep mode Auto
2. Set Horizontal Scale to 1 us/div
3. Select "Auto" from Acquire>Mem Depth menu
4. Select "100 ms" from Display>Persis. Time menu
5. Enter Horizontal Zoom mode by pressing the Horizontal Scale knob
Thanks for your report. Just to be completely clear.... you did try the following?
1. Display a signal on CH1 from the probe Calibrator, at 1V/div, trigger type Edge, trigger level 2.00 V, sweep mode Auto
2. Set Horizontal Scale to 1 us/div
3. Select "Auto" from Acquire>Mem Depth menu
4. Select "100 ms" from Display>Persis. Time menu
5. Enter Horizontal Zoom mode by pressing the Horizontal Scale knob
Yeah, checked it again using that exact sequence and all I can notice is a slight hesitation on the screen update when going into H Zoom mode. I did it 5-6 times and the behaviour seems consistent.
Looking at your video, using that sequence, it seems all the controls goes unresponsive but the scope it self is continuing to operate and updating the display with the waveform. So is something triggering the KeyLock feature? and is the KeyLock feature otherwise working normally? just a thought...
-- and the scope freezes, stops responding to the Telnet connection, and requires a reboot. But it still shows a live waveform !!So more of a lockup than a freeze?
-- and the scope freezes, stops responding to the Telnet connection, and requires a reboot. But it still shows a live waveform !!So more of a lockup than a freeze?
Just a guess: the processor encounters some critical exception, but FPGA keeps operating as usual. That might explain why the waveforms are still updating and the rest of the scope is unresponsive.
In regards to your hardware issue guess, it well may be the case. I have opened my 2072a to fix the ADC clock problem and what I found beside that problem was bunch of other hardware related problems all over the board, along and across. In one instance reviewing a circuit that occupied 1 square inch of space on the PCB I counted 10 design errors! Wrong component selection, wrong design, wrong circuit layout. 10 errors per sq inch,
...
So where is Rigol on this issue? Where's Dave? Based on our sample we can expect _half_ of all the DS1054 units out there to have this problem.
...
(Hello, Rigol.... are you out there? Dave? Earth to Dave, come in please...... over.......)
Are you aware of this problem? It seems to affect about half of the DS1054Z scopes that have tested for it (over 25 as I write this, with at least 13 affected). The problem occurs in scopes running firmware 04.03 and also in scopes running 04.02.
The scope "locks up" and does not respond to any user input (buttons, knobs, SCPI commands over LAN) and requires a power-cycle reboot. To reproduce the condition reliably, start with CH1 probe connected to Calibrator for a signal (although any signal or even no signal will also work). Set Horizontal timebase to 1 us/div or faster. Set Memory Depth to AUTO. Set Display Persistence Time to 100 ms, or any value other than "min". Enter Horizontal Zoom (Delayed) mode by pressing the Horizontal Scale knob or by using the menu item button. Scope locks up at this point. Or do the steps in different sequence, like have Mem Depth set at some value other than Auto, enter Horizontal Zoom then select "Auto" Mem Depth... scope locks up. The scope continues to show a live waveform but is completely unresponsive to any knobs or button presses. In this state, it also does not recognize attempts to connect over the LAN using Telnet. If the LAN connection is already established before the scope freezes, it stops responding to SCPI commands (connection is dropped).
The only way to restore function is to power-cycle the scope. Sometimes even power-cycling results in continued lockup and then the scope needs to be reset using the "5th Left Menu Button" reset technique which results in the scope coming up in Chinese (but operational.)
Please check the EEVBlog thread here:
https://www.eevblog.com/forum/testgear/rigol-ds1054z-freeze-up-bug/ (https://www.eevblog.com/forum/testgear/rigol-ds1054z-freeze-up-bug/)
And my videos demonstrating the bug:
https://www.youtube.com/watch?v=D7gziboPoHI (https://www.youtube.com/watch?v=D7gziboPoHI)
https://www.youtube.com/watch?v=pSTYrMzNzZw (https://www.youtube.com/watch?v=pSTYrMzNzZw)
Thank you for your attention to this matter. A perfectly legitimate combination of user settings should never cause an instrument to lock up completely requiring a hard reboot, and the fact that the "bug" appears in approximately half the units tested, using 04.02 and 04.03 firmwares equally, is very strange.
...
So where is Rigol on this issue? Where's Dave? Based on our sample we can expect _half_ of all the DS1054 units out there to have this problem.
...
(Hello, Rigol.... are you out there? Dave? Earth to Dave, come in please...... over.......)
I'll repeat it again, did anyone reported the issue to Rigol? or do you really need Dave to do the work? or hope Rigol finds this thread?
http://www.rigolna.com/tech-support/ (http://www.rigolna.com/tech-support/)
Well, one of the "gotchas" seems to be that the scope _sometimes_ doesn't remember the Mem Depth setting between power cycles, even if you have Utility>System>Power Set to "Last".
I haven't tracked down the full set of circumstances to repeat _this_ bug yet. But it appears that if I have just one channel turned on, Acquire Mode Normal with Mem Depth set to 24M, and cycle the power, the scope keeps the 24M setting. But if I have all four channels turned on, with Mem Depth set to 6M (max for 4ch operation) and cycle the power, the scope comes up with "Auto" Mem Depth. But since the scope comes up with the "Utility" menu displayed, the user might not notice that the Mem Depth setting isn't where it was left, and inadvertently enter the Freeze-Lock condition.
If anyone cares I've had my DS1054Z freeze but can't reproduce it. I haven't tried to reproduce it though. Firmware was 4.02 I think, I upgrade to 4.03 fine.
Bug not present with original firmware 4.01.SP2, nor after upgrade to 4.03. No apparent slowdown in the UI either. No "upgrade" codes entered.
Please try to use the steps outlined above and in my videos to see if yours will lock up under those conditions.
The easiest way to do it is first to go to Storage>Default (press the button) and this will reset most everything to the basic settings, with CH1 on.
Then:
Connect the probe to the Calibrator to show a signal (Do you recommend x1 or x10 probe setup? )
Verify that the Horizontal Timebase is set to 1us/div.
In Display>Persis Time, set 100ms.
In Acquire>Mem Depth, set Auto.
Enter the Horizontal Zoom mode by pressing the Horizontal Scale knob. Or by selecting Delayed ON in the Horizontal menu.
If you've got the Bug, the scope will freeze now.
Please try to use the steps outlined above and in my videos to see if yours will lock up under those conditions.
The easiest way to do it is first to go to Storage>Default (press the button) and this will reset most everything to the basic settings, with CH1 on.
Then:
Connect the probe to the Calibrator to show a signal (Do you recommend x1 or x10 probe setup? )
Verify that the Horizontal Timebase is set to 1us/div.
In Display>Persis Time, set 100ms.
In Acquire>Mem Depth, set Auto.
Enter the Horizontal Zoom mode by pressing the Horizontal Scale knob. Or by selecting Delayed ON in the Horizontal menu.
If you've got the Bug, the scope will freeze now.
I think we are not paying sufficient attention to the signal appearing on the scope's input, when attempting to reproduce this bug.
You originally stumbled upon it when doing some nanopulse shit ...didn't you?
Are all calibrating signals the same across all models?
Do all bug replicators bother to apply the same signal to the scope's input?
Try as I might, I can't get the scope to freeze following the posted steps. The scope's responsiveness does become sluggish while in zoom mode with the persistence set to anything other than min. (This is my second post, so I've already been counted. I wanted to see if a cold start might affect the outcome.)
Please try to use the steps outlined above and in my videos to see if yours will lock up under those conditions.
The easiest way to do it is first to go to Storage>Default (press the button) and this will reset most everything to the basic settings, with CH1 on.
Then:
Connect the probe to the Calibrator to show a signal (Do you recommend x1 or x10 probe setup? )
Verify that the Horizontal Timebase is set to 1us/div.
In Display>Persis Time, set 100ms.
In Acquire>Mem Depth, set Auto.
Enter the Horizontal Zoom mode by pressing the Horizontal Scale knob. Or by selecting Delayed ON in the Horizontal menu.
If you've got the Bug, the scope will freeze now.
I think we are not paying sufficient attention to the signal appearing on the scope's input, when attempting to reproduce this bug.
You originally stumbled upon it when doing some nanopulse shit ...didn't you?
Are all calibrating signals the same across all models?
Do all bug replicators bother to apply the same signal to the scope's input?
It would be nice to know what the difference is between the two populations.Are all DS1054Z of Board Version 0.1.1? If so, no other h/w designator on the scope (perhaps hidden as part of S/N)?
Are all DS1054Z of Board Version 0.1.1? If so, no other h/w designator on the scope (perhaps hidden as part of S/N)?
The easiest way to reproduce this is probably like this:
Disconnect all the probes. Go to Storage>Default (press button) and the scope will reset to most all defaults, with CH1 turned on. Verify that it is at 1.00 us/div.
Now turn on all the other channels. The traces will overlay in the center of the screen, that's OK.
Set Utility>System>Power Set = Last.
Set Display>Persis Time = 100 ms.
Set Acquire>Mem Depth = 6M (or highest available).
Now enter Horizontal Zoom by pressing the Horizontal Scale knob. Everything still works, right? Not frozen, because you have 6M set instead of Auto in Mem Depth. Fine.
Now _exit_ horizontal zoom, and cycle the power. When the scope boots up, see if the Acquire>Mem Depth has changed to Auto. If it has... then you've got that little bug too.
So change it back to 6M.
Now enter Horizontal Zoom mode. Everything still works, right? Not frozen.....
Now cycle the power again, while still in Horizontal Zoom. If you've got the bug like I do, the scope will start up _in the frozen state_ and you can't even do anything about it. This happens because the Mem Depth has forgotten you set it to 6M and has reset itself to Auto, hence fulfilling all the conditions for lock-up.
The boards are the same, just with more bits populated.Therefore the boards are _different_.
Thanks for your report. Just to be completely clear.... you did try the following?
1. Display a signal on CH1 from the probe Calibrator, at 1V/div, trigger type Edge, trigger level 2.00 V, sweep mode Auto
2. Set Horizontal Scale to 1 us/div
3. Select "Auto" from Acquire>Mem Depth menu
4. Select "100 ms" from Display>Persis. Time menu
5. Enter Horizontal Zoom mode by pressing the Horizontal Scale knob
Blimey, I'd try getting out of the other side of the bed tomorrow!I do apologize for being terse.
I'd have thought there was enough similarity such that the input is worth noting down. They use the same firmware releases.
The -S is a daughter board and an extra button on the front panel. The MSO is a few extra populated parts on the main board, and an extra button and connector on the front panel.
The price differential is because they can get away with it, the raw cost in parts is less than $20 between a DS1054Z and an MSO1100Z. Similarly, the -S daughter board plug in is about $30.
Should you also discount DS1074Z(-S) and DS1100Z(-S) users too?
I'd still like to know if those who have the Bug can reproduce the "start-up-frozen" state after shutting down an _unfrozen_ scope, as I show in the video above. It's quite easy to do, since the fact that the Mem Depth automatically resets to "Auto" means that one of the bug conditions is set for you by the scope when you start up. All you need is the three other conditions: Persistence other than Min, main timebase 1us/div or faster, and Delayed timebase (horizontal zoom) engaged. Shut down (with "last" as your power-on setup setting) in that state and when you restart... your scope is locked from the get-go.
I'd still like to know if those who have the Bug can reproduce the "start-up-frozen" state after shutting down an _unfrozen_ scope, as I show in the video above. It's quite easy to do, since the fact that the Mem Depth automatically resets to "Auto" means that one of the bug conditions is set for you by the scope when you start up. All you need is the three other conditions: Persistence other than Min, main timebase 1us/div or faster, and Delayed timebase (horizontal zoom) engaged. Shut down (with "last" as your power-on setup setting) in that state and when you restart... your scope is locked from the get-go.
I have reproduced that issue as well.
OK initially I was not able to cause my DS1054Z upgraded with 4.03 to freeze but now I can using all four channels as described.
In addition to the original freeze issue, my scope will reset the Mem Depth to Auto when I power cycle it.
Narrowing down the exact conditions is problematic as it always resets to Auto if Channel 3 or 4 are selected on power down, but sometimes Chan 1 and/or Chan 2 alone or together will do it too... Also always resets to auto if no channels are selected.
:scared:
Cheers, Bob.
OK with 3 channels it does not lock up but the Memory Depth going to AUTO when restarted.
I just got this unit from Tequipment.net about 1 week ago and I am trying to decide whether to keep it or return it. I am a hobbyist/Ham that likes to experiment and repair my equipment and my first digit oscilloscope. Not sure I should keep it, I am sure Rigol will come out with a fix but maybe upgrading this unit has pushed it a little beyond it capabilities.
And.... just in case anyone was wondering....
https://www.youtube.com/watch?v=q3qLx1PYXyw (https://www.youtube.com/watch?v=q3qLx1PYXyw)
Your FFT display is exactly what I would expect.In the two images I showed, the input signal (from the Calibrator) is exactly the same 1kHz square wave, BW limiting is on in both cases, fft Blackman windowing with Center Frequency at 3kHz is used in both cases, trigger level is set the same in both cases, memory depth is the same in both cases, all other signal and scope parameters are the same, except Acquire Mode. The only difference between the two shots is that in one case the Acquire mode is set to Normal, and in the other case the mode is set to High Precision. The FFT of a 1KHz square wave should consist of peaks at the fundamental (1 kHz) and the odd harmonics (3, 5, 7, etc kHz) without the secondary peaks that show up at the _even_ harmonics that are seen in "normal" acquisition mode. But I'm sure you know this already.
Why would you not expect the FFT computation to be dependent on the acquired dataset and the filtering/windowing imposed?
I sincerely hope that this bug does not discourage hobbyists from purchasing this scope. I bought the scope last week and immediately put it through the paces of debugging a relatively sophisticated amateur radio application I designed using both SPI and I2C data busses. Never a problem and very impressive performance. I also have an Agilent 7014B right beside it and the only fault I can find is somewhat sluggish operation with everything enabled (triggering/decoding), and the smallish fonts. Yes, there are few other things with persistence (forgetting settings when powered on e.g. measurement font) but for $380 (Tequipment with eevblog discount and free shipping), this thing could lose three channels and I would still be thrilled.
Indeed, it is the best thing going for the hobbyist. I am thinking of purchasing three more for the robotics class I teach. What a bargain!
dan W7NGA
Sure, but as we asked in another thread... which display is "more correct" then? If you expect to see some "even harmonic energy" due to the slow risetime, why does that show up in the "Normal" mode but not in the "High Resolution" mode? Would one not expect it to be the other way around?
I get the feeling you'll be seeing plenty of used units up for sale soon.
Thank you for posting those spectra. Indeed, the spectrum analyzer tells the tale. The even-numbered peaks in the Rigol's FFT of its Calibrator signal when in "Normal" acquisition mode are spurious.
Well, that's clear enough.... now. Is that "feature" mentioned in the User's Manual somewhere? "Thrown away sample data" causing peaks to appear where none exists.... That's interesting. I would have expected that "thrown away data" would cause peaks that _should appear_, to be missing or attenuated, not the other way around. Would you call this an aliasing problem.... which isn't affected by the "anti-aliasing" setting at all..... ?Thank you for posting those spectra. Indeed, the spectrum analyzer tells the tale. The even-numbered peaks in the Rigol's FFT of its Calibrator signal when in "Normal" acquisition mode are spurious.
In "Normal" acquisition at 5Msps when you are only set to 120Ksps sample rate it means you are throwing away 97.6 percent of the sample data so it's producing peaks where none exists.
You really need to set your scope to high-res for FFTs.
In "Normal" acquisition at 5Msps when you are only set to 120Ksps sample rate it means you are throwing away 97.6 percent of the sample data so it's producing peaks where none exists.Well, that's clear enough.... now. Is that "feature" mentioned in the User's Manual somewhere?
You really need to set your scope to high-res for FFTs.
Tips
- You can use HORIZONTAL SCALE to adjust the center frequency
and horizontal scale at the same time.
- Signals with DC components or deviation would cause error or deviation of
the FFT waveform components. To reduce the DC components, set the
“Channel Coupling” to “AC”.
- To reduce the random noise and aliasing frequency components of
repetitive or single pulse, set the “Acquisition Mode” of the oscilloscope
to “Average”.
Can reproduce the freeze bug on .04.02 SP4 board 0.1.1 with all options (except 500microvolt/d) enabled. The mem setting is saved with 1 channel on, but reverts to auto if the scope is powered off with 4 channels enabled and set to power on last.
Edit: Just upgraded to .04.03, and somewhat the same problem. Inputting a 1MHz sine wave instantly locks up the scope after switching the persistence. But inputting a 1KHz sine wave does not. I can change the persistence to all the different settings. I can also increase the frequency to 1MHz again and change the persistence around. But if I exit the zoom mode and enter it again at 1MHz it locks up. Basically, if the scope does not initially crash after switching the persistence mode in zoom mode, I can change the frequency to whatever I want, 5Hz and 25MHz for example, and also change the persistence to whatever I want. Tried to enter at 500KHz and it locked up, seems to be a specific frequency and up that it locks up.
In "Normal" acquisition at 5Msps when you are only set to 120Ksps sample rate it means you are throwing away 97.6 percent of the sample data so it's producing peaks where none exists.Well, that's clear enough.... now. Is that "feature" mentioned in the User's Manual somewhere?
You really need to set your scope to high-res for FFTs.
Yes:QuoteTips
? You can use HORIZONTAL SCALE to adjust the center frequency
and horizontal scale at the same time.
? Signals with DC components or deviation would cause error or deviation of
the FFT waveform components. To reduce the DC components, set the
“Channel Coupling” to “AC”.
? To reduce the random noise and aliasing frequency components of
repetitive or single pulse, set the “Acquisition Mode” of the oscilloscope
to “Average”.
Well, that's clear enough.... now. Is that "feature" mentioned in the User's Manual somewhere? "Thrown away sample data" causing peaks to appear where none exists.... That's interesting. I would have expected that "thrown away data" would cause peaks that _should appear_, to be missing or attenuated, not the other way around. Would you call this an aliasing problem.... which isn't affected by the "anti-aliasing" setting at all..... ?
Thanks for doing that comparison. Yes, I agree that the DS1054Z is a great bargain, an excellent scope for beginners like me.
Hopefully you will make up a handout to notify your students about the conditions for lock-up and what settings are "poison" on your new ones, and how to recover from a locked-on-startup condition. Or maybe you can select new ones that don't lock up, from your vendor's stock. After all, you have slightly less than a 50 percent chance of getting scopes that don't show this bug. Or maybe Rigol will have issued another firmware update that fixes this bug by the time you return to your classes.
Just curious ... is it possible to get the Tek TDS 2014B to start up "frozen" and unresponsive to all controls, after being shut down in a running, fully operational state?
I use it daily, several hours every day or more. How do you think I found the bug in the first place? I also apparently use mine for more complex setups and in more ways than ....well... anyone else I've seen reporting on the scope. I've made several videos showing how to use some of the advanced features of the scope. At the moment I have _eleven_ different experimental setups stored in the scope for working on different projects. Do you think that scopeshots like the one below are somehow deliberately set up to show some severe bug in the instrument? No, this shot is from an actual circuit that I am developing and testing, and when the scope locked up on me, and even started up "locked"... that was from a legitimate combination of settings encountered while trying to get data on an actual circuit.Thanks for doing that comparison. Yes, I agree that the DS1054Z is a great bargain, an excellent scope for beginners like me.
Hopefully you will make up a handout to notify your students about the conditions for lock-up and what settings are "poison" on your new ones, and how to recover from a locked-on-startup condition. Or maybe you can select new ones that don't lock up, from your vendor's stock. After all, you have slightly less than a 50 percent chance of getting scopes that don't show this bug. Or maybe Rigol will have issued another firmware update that fixes this bug by the time you return to your classes.
Just curious ... is it possible to get the Tek TDS 2014B to start up "frozen" and unresponsive to all controls, after being shut down in a running, fully operational state?
Maybe you should consider selling your DS1054Z -- or start using it, to work on some nice, cool projects?
Spending all your electronics hobby time searching for flies in the ointment can't be good for you... ::)
So I reject your comment and its implied accusation.
Rigol has ack'ed the bug (thank you) , and there is "no more soup, to cook on this fish"
I filed a report through the Rigol website, including a full description, links to this blog thread and to my videos describing the problem,Rigol has ack'ed the bug (thank you) , and there is "no more soup, to cook on this fish"
I must have missed that... was it in this thread? What did they say?
Hello,I responded with the information he asked for and emphasized that the problem happens with the DS1054Z, not the MSO series as far as I know. I have heard nothing back since June 8th. It is June 22nd as I write this.
My name is Jason Chonko and I am an Applications Engineer at Rigol Technologies USA. Thank you for writing in.
We are aware of the problems with the MSO and are investigating the issue further.
Can I get the following information from your instrument?
- Serial number?
- Purchase date and vendor?
- Shipping address and phone number?
I am going to write up a bug for your account. When it is fixed, you will be emailed the solution.
Sincerely,
Jason
I agree... mostly. The end user should be informed "up front" though as to how to recover from a locked-up scope by using the "Alternate Factory Reset" technique, and should be warned that this condition is quite likely to occur when a simple, legitimate combination of user settings is input to the scope.
It's a shame that the Display>Persistence feature isn't implemented without causing problems though. Say you are looking for jitter and have some persistence time set. Then you want to look at an FFT of your signal. On my scope the FFT comes to a dead halt (although the scope isn't frozen) if any persistence time is set other than "min".
Also, look at the FFT display itself, even when it is running properly. How is one to know whether one is getting a proper computation of the FFT for a complex signal? The result you get depends on Acquire mode, Mem Depth and Trigger level, as Anand has discovered.
Yes, the scope is definitely still the best "bang for bucks" in terms of price and capability. It also seems to have the most "bugs per bang"! I'm not trying to discourage anyone from buying the scope, but I do think that the various bugs, and how to avoid or recover from them, should be "officially" made clear to the owners, and of course should be fixed by Rigol as soon as possible.
In "Normal" acquisition at 5Msps when you are only set to 120Ksps sample rate it means you are throwing away 97.6 percent of the sample data so it's producing peaks where none exists.Well, that's clear enough.... now. Is that "feature" mentioned in the User's Manual somewhere?
You really need to set your scope to high-res for FFTs.
Yes:QuoteTips
? You can use HORIZONTAL SCALE to adjust the center frequency
and horizontal scale at the same time.
? Signals with DC components or deviation would cause error or deviation of
the FFT waveform components. To reduce the DC components, set the
“Channel Coupling” to “AC”.
? To reduce the random noise and aliasing frequency components of
repetitive or single pulse, set the “Acquisition Mode” of the oscilloscope
to “Average”.
Thank you. This indeed does produce a better FFT display, of the Calibrator signal anyway.
The shot below is using "Average" acquisition mode, 16 averages, Auto memory depth, AC coupled input with BW limit on, Blackman window for the FFT. And "persistence time" set to "min" of course. I hope Anand is reading here!
Can't reproduce the freeze up bug.
I'm running the defaults on start up and no probes.
Set Persis. Time to 100ms
Enter horizontal zoom mode
Still responsive to button presses.
Software Version
00.04.03
Board Version
0.1.1
Serial Number
DSA1ZA17140XXXX
For reference here is alsetalokin4017's
Serial Number
DAS1ZA17030XXXX
I won't bother reading this whole thread but that jump in serial numbers looks like a hardware revision to me or at least somethings changed for Rigol to jump in serial numbers.
Can't reproduce the freeze up bug.SN's do not normally include HW versions, only model series and build date.
I'm running the defaults on start up and no probes.
Set Persis. Time to 100ms
Enter horizontal zoom mode
Still responsive to button presses.
Software Version
00.04.03
Board Version
0.1.1
Serial Number
DSA1ZA17140XXXX
For reference here is alsetalokin4017's
Serial Number
DAS1ZA17030XXXX
I won't bother reading this whole thread but that jump in serial numbers looks like a hardware revision to me or at least somethings changed for Rigol to jump in serial numbers.
SN's do not normally include HW versions, only model series and build date.
Generally.SN's do not normally include HW versions, only model series and build date.
You talking about serial numbers in this specific case or serial numbers generally? As I'm meaning in this specific case there seems to be a pattern.
Can't reproduce the freeze up bug.
I'm running the defaults on start up and no probes.
Set Persis. Time to 100ms
Enter horizontal zoom mode
Still responsive to button presses.
Software Version
00.04.03
Board Version
0.1.1
Serial Number
DSA1ZA17140XXXX
For reference here is alsetalokin4017's
Serial Number
DAS1ZA17030XXXX
I won't bother reading this whole thread but that jump in serial numbers looks like a hardware revision to me or at least somethings changed for Rigol to jump in serial numbers.
Model:DS1xxxZ
SN:DS1ZA170xxxxxx
Manufacturer:RIGOL TECHNOLOGIES
Board Ver:0.1.1
Firmware Ver:0.2.3.11
BOOT Ver:0.0.1.2
CPLD Ver:1.1
SoftWare Ver:00.04.03.SP1
What do you get in the file when you ask the scope to save a "Param" file?What about Power cycles # ?
Storage>Storage>Param and Save to USB stick
The file should contain more information about the software, firmware and board numbers.
Memory Depth set to "Auto" ? This appears to be one of the conditions for freezing.
What do you get in the file when you ask the scope to save a "Param" file?
Storage>Storage>Param and Save to USB stick
The file should contain more information about the software, firmware and board numbers.
like:Code: [Select]Model:DS1xxxZ
SN:DS1ZA170xxxxxx
Manufacturer:RIGOL TECHNOLOGIES
Board Ver:0.1.1
Firmware Ver:0.2.3.11
BOOT Ver:0.0.1.2
CPLD Ver:1.1
SoftWare Ver:00.04.03.SP1
What about Power cycles # ?
Or is this something Rigol doesn't see as important info? :-//
Param from my DS1054Z which does NOT freeze.
Model:DS1xxxZ
SN:DS1ZA1716xxxxx
Manufacturer:RIGOL TECHNOLOGIES
Board Ver:0.1.1
Firmware Ver:0.2.3.11
BOOT Ver:0.0.1.3
CPLD Ver:1.1
SoftWare Ver:00.04.03.SP1
So, only the BOOT Ver is different, and SN of course.
You can apparently read out the operation time with a SCPI command.
:SYST:INFO? BTIME
Result: "May 26 2015 08:38:06 | 0 0:4 / 9 0:49"
Firmware build time: "May 26 2015 08:38:06"
Current operating time 'day hour:minute': "0 0:4"
Total operating time 'day hour:minute': "9 0:49"
Is just a guess.
Peter
You can apparently read out the operation time with a SCPI command.
:SYST:INFO? BTIME
Result: "May 26 2015 08:38:06 | 0 0:4 / 9 0:49"
Firmware build time: "May 26 2015 08:38:06"
Current operating time 'day hour:minute': "0 0:4"
Total operating time 'day hour:minute': "9 0:49"
Is just a guess.
Peter
Yes, I think that's right. But it still doesn't give the number of power cycles. The total "on" time is nice to know though, and is probably just as important as the number of power cycles.
Memory Depth set to "Auto" ? This appears to be one of the conditions for freezing.
What do you get in the file when you ask the scope to save a "Param" file?
Storage>Storage>Param and Save to USB stick
The file should contain more information about the software, firmware and board numbers.
Model:DS1xxxZ
SN:DS1ZA170xxxxxx
Manufacturer:RIGOL TECHNOLOGIES
Board Ver:0.1.1
Firmware Ver:0.2.3.11
BOOT Ver:0.0.1.2
CPLD Ver:1.1
SoftWare Ver:00.04.03.SP1
For my information please, why is the number of power cycles important? :-//
Exactly.For my information please, why is the number of power cycles important? :-//
Not so important in this case aside from determining how much use it's had or the potential for data corruption, but it's a metric in failure analysis.
If you sold an oscilloscope that had a days use on it and a thousand boots it would look very suspicious. Manufacturers love to know this as users often say "I used it now and again now it's broken (sad face)" when they actually drove it into the ground 10hrs a day every day for 5 years straight.
Thank you for the answers. I understand that the total runtime is important, but not the number of boots.
When I buy a car, I want to know the total km or miles, but not how many times the car has been started.
Thank you for the answers. I understand that the total runtime is important, but not the number of boots.
When I buy a car, I want to know the total km or miles, but not how many times the car has been started.
I understand your point, but it's still important information despite your analogy, the hobbyist or the "average car buyer" might not care, at least until their new oscilloscope/car engine freezes.
Memory Depth set to "Auto" ? This appears to be one of the conditions for freezing.
What do you get in the file when you ask the scope to save a "Param" file?
Storage>Storage>Param and Save to USB stick
The file should contain more information about the software, firmware and board numbers.
Model:DS1xxxZ
SN:DS1ZA170xxxxxx
Manufacturer:RIGOL TECHNOLOGIES
Board Ver:0.1.1
Firmware Ver:0.2.3.11
BOOT Ver:0.0.1.2
CPLD Ver:1.1
SoftWare Ver:00.04.03.SP1
Memory Depth is set to "Auto" by default on bootup on mine. I did also toggle it at least once while testing and could not reproduce it. I suggest setting your scope to full defaults and trying, as well as doing this next time you complete a firmware update.
Model:DS1xxxZ
SN:DS1ZA17140xxxx
Manufacturer:RIGOL TECHNOLOGIES
Board Ver:0.1.1
Firmware Ver:0.2.3.11
BOOT Ver:0.0.1.3
CPLD Ver:1.1
SoftWare Ver:00.04.03
Boot code is different, does it get updated at all by a firmware update?
Well, when I do that I get exactly the same screen.
No, my scope was delivered with 00.04.02 "firmware" (what the scope calls "SoftWare"), and I have since updated it several times.
What is this supposed to prove?
Has anyone tested firmware 00.04.03.01.05 ?
https://www.dropbox.com/sh/ph4ff16d9s85tkt/AAA3UeuWQsdGbA_OfDkqiBlVa?dl=0 (https://www.dropbox.com/sh/ph4ff16d9s85tkt/AAA3UeuWQsdGbA_OfDkqiBlVa?dl=0)
Glad I read around, I was about to buy a 1054Z. It seems to be a complete firmware fuckup, though. Random freezes are not a sign of good code qualityThe freezing isn't random, it's a particular set of circumstances.
But now he does.
Glad I read around, I was about to buy a 1054Z. It seems to be a complete firmware fuckup, though. Random freezes are not a sign of good code qualityThe freezing isn't random, it's a particular set of circumstances.
You probably won't see it in normal use (I never have).
I wouldn't stop buying one because of that.
We believe that this firmware release addresses the reported lock up and math bugs.@Alsetalokin4017
We believe that this firmware release addresses the reported lock up and math bugs.@Alsetalokin4017
I tried this release and I don't have the feezebug.
How about you?
Executive summary:
Screen display of Software Parameters re Jason's instructions: NO.
Freeze Bug: STILL PRESENT.
Trigger Errors: Fixed.
Math Error: STILL PRESENT.
Er...ahem.... OK..... has anyone tried that procedure described by Jason above, to show all that information on the screen?
Ah.... I finally got mine to do it (and with Mem Depth Auto, too!)
You have to push the buttons _fast_. If it doesn't work, push them even faster!
Why do we have to fill out this ridiculous form just to download a firmware update
Ah.... I finally got mine to do it (and with Mem Depth Auto, too!)
You have to push the buttons _fast_. If it doesn't work, push them even faster!
Heh... look at my screen up above. Mem depth 12k points (Auto) !
I had to push the buttons very fast.
To display the full version information:
- In the trigger area on the front panel, press MENU > MENU > FORCE > MENU
- In the menu area, press UTILITY > SYSTEM > SYSTEM INFO
- Save a copy of the display by inserting a USB memory device (FAT32 format) into the front panel USB slot and press the Quick Print icon
To display the full version information:
- In the trigger area on the front panel, press MENU > MENU > FORCE > MENU
- In the menu area, press UTILITY > SYSTEM > SYSTEM INFO
- Save a copy of the display by inserting a USB memory device (FAT32 format) into the front panel USB slot and press the Quick Print icon
Jason, it appears there are two versions of boot firmware sitting on customers scopes (BOOT Ver:0.0.1.2 and BOOT Ver:0.0.1.3). My oscilloscope shipped with 0.0.1.3 boot and 00.04.03.00.01 software, I don't have the freeze issue.
Since firmware update 00.04.00.00.00 there doesn't seem to have been an update provided that contains a boot firmware update. I have not tried to unpack that specific version so I cannot see what boot firmware that update contains, however it seems that the software may use the software version in first line of the boot firmware .GEL file to see if it's a valid newer update.
If there have been no hardware refreshes, could it be possible that during manufacturing old boot firmware on oscilloscopes was present but failed being updated because the software had already been updated?
There has got to be some reason why people are on BOOT Ver:0.0.1.2.
The thing is that even with these firmware features, the DS1054Z remains by far the best value DSO there is. What would be an alternative DSO? If it makes you feel any better, here is my brand new Tek MDO3000 crashing, it's far easier to achieve!Well, I would assume that Tek by now has resolved the crashing MDO3000 issues. It was perhaps 1 or 2 years ago, when I saw the MDO3000 on a trade show in Holland, and the guy demonstrating the scope was apologizing for the crashes. Within 10 seconds of demoing the thing was hanging. He replied to me very silent 'I just have loaded new firmware from Tektronix' (from the opposite booth) . Very embarrassing, and certainly not expected for such an expensive scope.
If these anomalies are of key concern, then the answer is to go for an older unit with more mature firmware, but with fewer features. Or stick to CROs of course, I still keep a few around but rarely use them nowadays.
https://www.youtube.com/watch?v=qduFQOmzU8I (https://www.youtube.com/watch?v=qduFQOmzU8I)
Well, I would assume that Tek by now has resolved the crashing MDO3000 issues. It was perhaps 1 or 2 years ago, when I saw the MDO3000 on a trade show in Holland, and the guy demonstrating the scope was apologizing for the crashes. Within 10 seconds of demoing the thing was hanging. He replied to me very silent 'I just have loaded new firmware from Tektronix' (from the opposite booth) . Very embarrassing, and certainly not expected for such an expensive scope.
At least I know what to look for now as soon as I get it so I can send it right back. :-+
The thing is that even with these firmware features, the DS1054Z remains by far the best value DSO there is.
The thing is that even with these firmware features, the DS1054Z remains by far the best value DSO there is.
ANd none of the problems are showstoppers. They're very specific and you'll probably never see them in general use.
And I was just about to order a Rigol DS1074Z. |O Is this freeze bug on the newer ones also?I got mine 4 months ago. It also has the 0.0.1.3 boot-board 0.1.1 and I've been running SP1 without any issues. I've tried several time to reproduce this freeze up but and can't.
At least I know what to look for now as soon as I get it so I can send it right back. :-+
Why take the risk? Much safer to spend $1500 on a "professional" 'scope. (which will also have bugs).
Mine also came single boxed after they got stock back in, that's when I bought it. I remember another glitch with an oscillating interference back then, but SP1 fixed it.
But what about the Math error, which makes me have no faith in the Math, and isn't fixed, for me at least, by the new firmware? Is that also related somehow to the earlier Boot Version?
And is there really no way to uninstall the SP2 and roll back to the SP1 firmware? That's really a foul thing if true.
I don't want to try SP2 because of the sluggishness, sorry.
Have a look on this info screen, it has boot version 0.0.0.13 !!! (It was one of the early scopes)
Is your new scope received before September 2015 ?
I noticed that the Build Date in your screen is September 2015 (same as Fennec)but based on your posts (not sure) it was received in April. If so, you have received a scope from FUTURE? :)
Here's my older unit. Still going strong. Firmware not required. :-+
(http://www.stevenjohnson.com/web-pics/tek-465.jpg)
Now to find a buyer for the DS1102E. Should be able to get a few bucks for it.
The build date is the firmware build date. It has nothing to do with the scope itself.
I'm using the same firmware and the build date is May 2015. :-//I believe you have 00.04.03.00.01 (May/5/2015) and not the actual firmware. Pls make a pic of your settings with MENU > MENU > FORCE > MENU > UTILITY > SYSTEM > SYSTEM INFO
Have a look on this info screen, it has boot version 0.0.0.13 !!! (It was one of the early scopes)
So, Orange have 0.0.0.13 version , while l84coffee have 0.0.1.3 version .
Does these looks the same for you guys ?
Also, if anyone has an locked 100Mhz scope, please post your boot version here please.
I got a feeling that the Boot Version is changed once the 100Mhz option is unlocked
@alsetalokin4017
Is your new scope received before September 2015 ?
I noticed that the Build Date in your screen is September 2015 (same as Fennec)but based on your posts (not sure) it was received in April. If so, you have received a scope from FUTURE? :) Confusing. Am I missing something here?
But the 2 traces have different amplitude?
What would cause that
I see you have Boot Ver 0.0.1.3, lucky you.
- No Freeze
- No Math issue
- No noticeable slow-down with SP2
- I can live with the spelling error :)
I'm a happy camper. :D
There has been a change in some of the hang times in the first list. Most noticeable it has decreased for the 20usec TB to 22 secs and the 10usec TB to 35 sec. The second list for 20usec drops to 10 sec response and the 5usec drops from 35 minutes to 3 min 30sec. I agree Auto is the real problem the other tests were just to see how things changed with various sample rates and with a fixed memory depth. My boot is 0.0.1.2 like yourself. My recent resets seem to have cancelled the extended System Info list and so far I haven't got it back. Originally I managed it almost the first time! Also my freeze never needed more than a single channel just the 100ms persistence, Auto memory management and into 'Delayed/Zoom' . I have the MATHs issue and the spelling.
Jason, it appears there are two versions of boot firmware sitting on customers scopes (BOOT Ver:0.0.1.2 and BOOT Ver:0.0.1.3). My oscilloscope shipped with 0.0.1.3 boot and 00.04.03.00.01 software, I don't have the freeze issue.
So how does it feel when rigol is wasting your time that you could otherwise spent working on your projects. Still think your purchase was "best for the buck" ?
So how does it feel when rigol is wasting your time that you could otherwise spent working on your projects. Still think your purchase was "best for the buck" ?
So how does it feel when rigol is wasting your time that you could otherwise spent working on your projects. Still think your purchase was "best for the buck" ?
So how does it feel when rigol is wasting your time that you could otherwise spent working on your projects. Still think your purchase was "best for the buck" ?
The real question is, if you are one of the un-fortunate ones that do have the freeze problem. In day to day usage of the scope how many times do you think you would be using the scope in the parameters that would cause it to freeze?
For me even though I don't experience the freeze problem, I would have never experienced it as I doubt I would have set up my scope in such a way to experience it.
Warts and all I still think it's a great scope for the price point.
Stan.
So how does it feel when rigol is wasting your time that you could otherwise spent working on your projects. Still think your purchase was "best for the buck" ?
The real question is, if you are one of the un-fortunate ones that do have the freeze problem. In day to day usage of the scope how many times do you think you would be using the scope in the parameters that would cause it to freeze?
For me even though I don't experience the freeze problem, I would have never experienced it as I doubt I would have set up my scope in such a way to experience it.
Warts and all I still think it's a great scope for the price point.
Stan.
So how does it feel when rigol is wasting your time that you could otherwise spent working on your projects. Still think your purchase was "best for the buck" ?
The real question is, if you are one of the un-fortunate ones that do have the freeze problem. In day to day usage of the scope how many times do you think you would be using the scope in the parameters that would cause it to freeze?
For me even though I don't experience the freeze problem, I would have never experienced it as I doubt I would have set up my scope in such a way to experience it.
Warts and all I still think it's a great scope for the price point.
Stan.
I've just shot a new video showing how easy it is to encounter the Freeze Bug in actual usage. It should be up and ready to view in an hour or so (after processing and uploading to YT).
Situation: Looking at a mosfet Gate signal on one channel and the Drain signal on the other channel, just 2 channels in use. Acquire mode normal, mem depth auto, timebase set appropriately for the 10 kHz signal to display a train of around 5 pulses (50 us/div). Trigger on falling edge of Gate pulse. Drain signal has a spike and ringdown. Enter Zoom mode to see the spike and ringdown at higher resolution. Notice that there is a little jitter on the Drain signal, so it would be nice to add a little persistence to see the extent of the jitter. Select Display>PersisTime>100 ms... and boom, scope is frozen.
Now what is unreasonable, unusual or otherwise not normal about that usage? Should one not use the normal operating features of the scope for fear of the dreaded Freeze Bug?
Jason, it appears there are two versions of boot firmware sitting on customers scopes (BOOT Ver:0.0.1.2 and BOOT Ver:0.0.1.3). My oscilloscope shipped with 0.0.1.3 boot and 00.04.03.00.01 software, I don't have the freeze issue.
I have boot version 0.0.1.1 :-//
(https://www.eevblog.com/forum/testgear/rigol-ds1054z-freeze-up-bug/?action=dlattach;attach=179550;image)
I completely agree with that last part!
But don't you remember Dave's great videos about this scope, where he was ecstatic about the great intensity graded display variable persistence feature? It's one of the things that makes this scope such a good value. Why not use it when you can? Unless of course it makes the scope freeze up in normal (my normal) use of the scope.
I followed EXACTLY the instructions mentioned above and my DS1104Z (true 100 MHz) does not show the freeze and/or the math bug. It also did not show these bugs with earlier software versions.
The software Version is the newest 00.04.03.02.03 (= 04.03 SP2)
Board Version: 0.1.1
Boot Version: 0.0.1.0 (!)
Firmware Version 0.2.3.11
CPLD Version: 1.1
I did not check the "pluses"-error because it would not bother me. I use the scope only for my own service and maintenance purpose (mostly audio gear) and not in a commercial way for clients, so i am not upset about the spelling error. (By the way, how many EE´s, who use their scopes for commercial tasks an for clients will use only such a little and inexpensive scope like the DS1000Z? I guess, they would prefer normally much more expensive and feature rich scopes like LeCroy, Keysight etc.)
For example. U buy a brand new car, a $US 15.000 Honda maybe and the ash tray is damaged, u are not smoking.. What are u doing ? I bet you go to a Honda customer and let fix this. And now you won in the lottery and buy a Bentley with the same cheap broken ash-tray.... What u do ? Live with it ? I bet not.
I see you have Boot Ver 0.0.1.3, lucky you.
- No Freeze
- No Math issue
- No noticeable slow-down with SP2
- I can live with the spelling error :)
I'm a happy camper. :D
For the Math error, did you follow my directions exactly? Do you have "Average" Acquire mode set?
Does your "Pluse" counter miscount when you have 500 ns/div, ten "pluses" displayed and three or four channels turned on?
Would you be happy showing the "Pluses" spelling error on a data screen to a client who is paying you money to do some work for him?
Good for you. I don't think anyone has ever accused the DS1104Z of having the bugs we have been talking about here, though. See the title of this thread? Did you vote in the poll, even though you don't have the right scope to do so, I wonder?
Good for you. I don't think anyone has ever accused the DS1104Z of having the bugs we have been talking about here, though. See the title of this thread? Did you vote in the poll, even though you don't have the right scope to do so, I wonder?
How could it not have the same bugs as the DS1054Z? Isn't the hardware and firmware exactly the same? :-//
Or maybe I'm wrong about that... maybe the actual intended purpose of the scope is just to sit next to the computer monitor and make pretty colored squiggly lines.
Sometimes I get the feeling that I'm the only one who is actually trying to _use_ the scope every day for its intended purposes.
Or maybe I'm wrong about that... maybe the actual intended purpose of the scope is just to sit next to the computer monitor and make pretty colored squiggly lines.
I think it doesn't matter how much a scope cost. If it's a cheap DS1000Z series or an one million bucks LeCroy. It has to work, simple.
For example. U buy a brand new car, a $US 15.000 Honda maybe and the ash tray is damaged, u are not smoking.. What are u doing ? I bet you go to a Honda customer and let fix this. And now you won in the lottery and buy a Bentley with the same cheap broken ash-tray.... What u do ? Live with it ? I bet not.
Why nobody should use this DS1054Z as a "prfessional" ? If you repair Tape-Decks, Recorder and something like that you can do it with this cheap DS1054Z absolutly professional. You don't need a one million LeCroy for that. But the Scope has to work correctly. With a damaged one million LeCroy nobody can repair the Tape-Deck, but you can do it with a working cheap Rigol.
Cheap or expencive, it has to work correctly, thats all.
Pls can you post a screenshot with all the Infos. Thx.
So how does it feel when rigol is wasting your time that you could otherwise spent working on your projects. Still think your purchase was "best for the buck" ?If you're willing to buy me a Keysight or Tek as a gift, I'll gladly take it. But don't put down and look down upon people who've chosen a cheaper product, you never know what their reasons are. (For example, electronics is what I've been doing to pass the time while taking a health related leave from employment and deciding what my next career might be. With zero income, buying top of the line test gear is perhaps not the best use of my money.)
So how does it feel when rigol is wasting your time that you could otherwise spent working on your projects. Still think your purchase was "best for the buck" ?
To display the full version information:
- In the trigger area on the front panel, press MENU > MENU > FORCE > MENU
- In the menu area, press UTILITY > SYSTEM > SYSTEM INFO
- Save a copy of the display by inserting a USB memory device (FAT32 format) into the front panel USB slot and press the Quick Print icon
Jason, it appears there are two versions of boot firmware sitting on customers scopes (BOOT Ver:0.0.1.2 and BOOT Ver:0.0.1.3). My oscilloscope shipped with 0.0.1.3 boot and 00.04.03.00.01 software, I don't have the freeze issue.
Since firmware update 00.04.00.00.00 there doesn't seem to have been an update provided that contains a boot firmware update. I have not tried to unpack that specific version so I cannot see what boot firmware that update contains, however it seems that the software may use the software version in first line of the boot firmware .GEL file to see if it's a valid newer update.
If there have been no hardware refreshes, could it be possible that during manufacturing old boot firmware on oscilloscopes was present but failed being updated because the software had already been updated?
There has got to be some reason why people are on BOOT Ver:0.0.1.2.
If you are experiencing the issue, I would like to ask that you please follow the directions below:Why should people have to go through this silly dance to get the full system information? Why isn't full information the default?
To check and display the full system information:
- In the trigger area on the front panel, quickly press MENU > MENU > FORCE > MENU
- In the menu area, press UTILITY > SYSTEM > SYSTEM INFO
- Save a copy of the display by inserting a USB memory device (FAT32 format) into the front panel USB slot and press the Quick Print icon
The latest release of firmware for the DS1000Z series can be requested from this registration page:Why don't you provide the actual download link? Other Rigol employees don't seem to have a problem doing so. No one wants to fill out that stupid form.
http://beyondmeasure.rigoltech.com/acton/form/1579/001e:d-0001/0/-/-/-/-/index.htm? (http://beyondmeasure.rigoltech.com/acton/form/1579/001e:d-0001/0/-/-/-/-/index.htm?)
QuoteThe latest release of firmware for the DS1000Z series can be requested from this registration page:Why don't you provide the actual download link? Other Rigol employees don't seem to have a problem doing so. No one wants to fill out that stupid form.
http://beyondmeasure.rigoltech.com/acton/form/1579/001e:d-0001/0/-/-/-/-/index.htm? (http://beyondmeasure.rigoltech.com/acton/form/1579/001e:d-0001/0/-/-/-/-/index.htm?)
The full system information is useful in providing additional build details about the specific instrument in question. There can be multiple differences on the same platform and having those details can help the Engineers find the root of the problem more quickly.
The full system information is not displayed normally because it is generally not required for day-to-day operation. The normal system info screen is designed to provide just enough detail to solve any pertinent questions that may arise (does this firmware version have a particular feature, for example).
Some situations require more information to help isolate a particular cause or incompatibility. That is why there is a more detailed view available.
In this case, this lock up bug appears to be intermittent. Since it is not tied solely to a specific firmware revision, we need more information to isolate the cause and find a solution.
QuoteThe latest release of firmware for the DS1000Z series can be requested from this registration page:Why don't you provide the actual download link? Other Rigol employees don't seem to have a problem doing so. No one wants to fill out that stupid form.
http://beyondmeasure.rigoltech.com/acton/form/1579/001e:d-0001/0/-/-/-/-/index.htm? (http://beyondmeasure.rigoltech.com/acton/form/1579/001e:d-0001/0/-/-/-/-/index.htm?)
Your answer is on the form: To request an upgrade please fill out the information below and we will contact you. Upgrade compatibility may depend on the serial number, hardware revisions and current firmware of your instrument. Not all instruments may be upgradable to the latest firmware.
If they just provided links you can bet some would try to upgrade when they shouldn't and that could be a problem. Of course the upgrade should check for compatibility but who knows.
So what do we know at this point...
1. The scopes with Boot Version 0.0.1.3 do not seem to have the Freeze Bug.
Any comments or additions?
I think you best have another look at this supposed newbies profile.QuoteThe latest release of firmware for the DS1000Z series can be requested from this registration page:Why don't you provide the actual download link? Other Rigol employees don't seem to have a problem doing so. No one wants to fill out that stupid form.
http://beyondmeasure.rigoltech.com/acton/form/1579/001e:d-0001/0/-/-/-/-/index.htm? (http://beyondmeasure.rigoltech.com/acton/form/1579/001e:d-0001/0/-/-/-/-/index.htm?)
Your answer is on the form: To request an upgrade please fill out the information below and we will contact you. Upgrade compatibility may depend on the serial number, hardware revisions and current firmware of your instrument. Not all instruments may be upgradable to the latest firmware.
If they just provided links you can bet some would try to upgrade when they shouldn't and that could be a problem. Of course the upgrade should check for compatibility but who knows.
This is just not true for the DS1054Z. There is only one version of the firmware, which is compatible with all of the units that have been shipped. That's why other Rigol employees do post the download link, just not our new poster Mr. Anonymous RigolUS_Apps.
Hello edavid,
The full system information is useful in providing additional build details about the specific instrument in question. There can be multiple differences on the same platform and having those details can help the Engineers find the root of the problem more quickly.
The full system information is not displayed normally because it is generally not required for day-to-day operation. The normal system info screen is designed to provide just enough detail to solve any pertinent questions that may arise (does this firmware version have a particular feature, for example).
Some situations require more information to help isolate a particular cause or incompatibility. That is why there is a more detailed view available.
In this case, this lock up bug appears to be intermittent. Since it is not tied solely to a specific firmware revision, we need more information to isolate the cause and find a solution.
We are collecting this information and forwarding it to our Engineering department for review.
But, before all these, please RIGOL, give us a solution to update Boot Vers to : 0.0.1.3
1. The scopes with Boot Version 0.0.1.3 do not seem to have the Freeze Bug.We need a new poll to confirm that.
It does have the skew in timebase (result is 1 div to the right) if averaging is set. Seems more like a cosmetic mistake; as the actual calculation is correct.You must be joking! Are you a disciple of superiority of amplitude over phase beliefs?
In this case, this lock up bug appears to be intermittent. Since it is not tied solely to a specific firmware revision, we need more information to isolate the cause and find a solution.The word "intermittent" implies a random low frequency of occurrence all other things being equal.
1. The scopes with Boot Version 0.0.1.3 do not seem to have the Freeze Bug.We need a new poll to confirm that.
BTW: Do you know of the video that shows how quickly the buttons need to be pushed to get the full system info ?
3. As far as the "pluses" counter goes, I showed that the counter counts pulses correctly when two channels are on but miscounts when a third channel is on, using _exactly the same_ signal. So this can't be a result of "ringing" or whatever, it's a result of turning on the third channel. Again, please see the scopeshots below. And again, the conditions for this are fairly specific. I can count manually when there are ten pulses on the screen, but can I rely on the "Pluses" counter to be correct in all cases when there are thirty or fifty "pluses" on the screen and I have three channels in use? So really, why should I use the pulse counter at all if it's going to give me a different count depending on how many channels I have turned on?
Silly question, but how did you invoke the pulse counter? ThxIt's found on the second page of options in the Horizontal Measurment Menu accessed via the soft keys on the left side of the screen.
Gonzo, I'm glad someone is paying attention.
1. The Freeze Bug is NOT intermittent.
I declined this "kind" offer, and suggested that they simply provide a way to update the Boot Version on those scopes with 0.0.1.2, up to 0.0.1.3a) Maybe boot isn't updateable
I'm prepared to believe that scopes with Boot Ver 0.0.1.3 don't have the Freeze Bug. But I'm confused as to why some people with Boot Ver 0.0.1.2 can't reproduce it either.
Here are simple instructions, again, that always work for me.
1. Power on scope. When it has finished booting up:
2. Go to Storage and press Default (at bottom of first Storage menu page) to load the Default setup. This should turn on only CH1, 1 V/div, 1.00 us/div, etc.
--This step is just to make sure we are all starting from the same place.--
3. Go to Acquire and make sure that Normal mode is set and Mem Depth is Auto.
--This should already be set by the Default setup but check anyhow.--
4. Turn on all 4 channels.
--It is not necessary to separate the traces vertically.--
5. Go to Display and set Persis. Time to 100 ms.
--Actually any Persis.Time other than "min" will also cause freezing.--
6. Press the Horizontal Scale knob to enter Horizontal Zoom mode.
--- my scope freezes here 100 percent of the time. ---
It just crossed my mind that the boot code could also set CPU operating flags and settings, like memory access time etc. These settings are then used to make hardware properly operating, I'm thinking on RAM and wait states for certain board revisions.Gonzo, I'm glad someone is paying attention.
1. The Freeze Bug is NOT intermittent.
I've been saying that for ages. If it's not intermittent and some people have it and some don't then it's hardware related, not just software.I declined this "kind" offer, and suggested that they simply provide a way to update the Boot Version on those scopes with 0.0.1.2, up to 0.0.1.3a) Maybe boot isn't updateable
b) Why would that fix it? "Boot" suggests that it's only there to get the 'scope started. Once the firmware is loaded then maybe boot does nothing at all.
If more people with 0.0.1.2 have the bug than 0.0.1.3 then it could be related to date of manufacture.
The boot code is located inside the CPU, at least on a Blackfin CPU, not sure on a ARM processor.
Mine doesn't freeze either, Boot Ver 0.0.1.1I'm prepared to believe that scopes with Boot Ver 0.0.1.3 don't have the Freeze Bug. But I'm confused as to why some people with Boot Ver 0.0.1.2 can't reproduce it either.
Here are simple instructions, again, that always work for me.
....
--- my scope freezes here 100 percent of the time. ---
Cannot reproduce using this exact sequence. Tried multiple times :-//
Latest update with bootloader 0.0.1.2
It depends on what version of arm processor. And even versions deviate if a company just buys the royalties, then they can take that basic recommended version royalty and add/change the design. Sometimes for the better "iPhone A8/A9" and sometimes for the worse.It just crossed my mind that the boot code could also set CPU operating flags and settings, like memory access time etc. These settings are then used to make hardware properly operating, I'm thinking on RAM and wait states for certain board revisions.Gonzo, I'm glad someone is paying attention.
1. The Freeze Bug is NOT intermittent.
I've been saying that for ages. If it's not intermittent and some people have it and some don't then it's hardware related, not just software.I declined this "kind" offer, and suggested that they simply provide a way to update the Boot Version on those scopes with 0.0.1.2, up to 0.0.1.3a) Maybe boot isn't updateable
b) Why would that fix it? "Boot" suggests that it's only there to get the 'scope started. Once the firmware is loaded then maybe boot does nothing at all.
If more people with 0.0.1.2 have the bug than 0.0.1.3 then it could be related to date of manufacture.
The boot code is located inside the CPU, at least on a Blackfin CPU, not sure on a ARM processor.
I've worked with Jason in the past, he can be reasonable.
4. The Rigol USA tech Jason sent me email offering to exchange my scope for a new one that doesn't have the bug, with them paying the shipping both ways. I didn't ask for this, he offered it. So I emailed him back and said OK, fine, send me the new scope and I'll put mine in the box and send it right back to you. He came back and said.... No, I have to send them my scope _first_, with all accessories and etc. and after they receive it _then_ they will send me a new one. Since I use the scope every day, I declined this "kind" offer, and suggested that they simply provide a way to update the Boot Version on those scopes with 0.0.1.2, up to 0.0.1.3 and maybe this will fix it for all of us who have the bug. I mean, what happens if I send them my scope, and then they send me a new one, and it turns out to have unacceptable bugs, or a hardware glitch or something? Then I'm out the use of a scope for _weeks_ perhaps, and I can't abide that. I use my scope every day in my work and I can generally work around the various bugs and annoyances. I also pointed out that I've spent tens of hours tracking down and explaining and demonstrating the various bugs and that my time is worth something. Heck, if I actually billed Rigol for my time finding problems with their product that they didn't even know about, it would be for a lot more than the cost of a brand new 1054z. So I'm not sending mine back unless they send me a new one FIRST. At which point I will examine it and test it for the various bugs and annoyances, and if it works as it should, THEN I'll box mine up and ship it back to them. And I'll post how great Rigol Customer Service is and make a YT video extolling the virtues of Rigol and its CS
Silly question, but how did you invoke the pulse counter? ThxIt's found on the second page of options in the Horizontal Measurment Menu accessed via the soft keys on the left side of the screen.
Hit either +Pulses or -Pulses, and it will display for the active channel/s that are setup for measurement display. You set the channel/s to show measurements by hitting the MEAS menu key, then choose Source on the soft key menu, and select the channels you want (CH1, CH2, CH3, CH4, or Math).
Not sure, I've never had access to a DS2000 series.Silly question, but how did you invoke the pulse counter? ThxIt's found on the second page of options in the Horizontal Measurment Menu accessed via the soft keys on the left side of the screen.
Hit either +Pulses or -Pulses, and it will display for the active channel/s that are setup for measurement display. You set the channel/s to show measurements by hitting the MEAS menu key, then choose Source on the soft key menu, and select the channels you want (CH1, CH2, CH3, CH4, or Math).
Thanks
Perhaps these two (+Pluses and -Pulses) are measurement features unique to the 1054 that are not found in the Rigol DS2000 series?
including the bugs ;)Not sure, I've never had access to a DS2000 series.Silly question, but how did you invoke the pulse counter? ThxIt's found on the second page of options in the Horizontal Measurment Menu accessed via the soft keys on the left side of the screen.
Hit either +Pulses or -Pulses, and it will display for the active channel/s that are setup for measurement display. You set the channel/s to show measurements by hitting the MEAS menu key, then choose Source on the soft key menu, and select the channels you want (CH1, CH2, CH3, CH4, or Math).
Thanks
Perhaps these two (+Pluses and -Pulses) are measurement features unique to the 1054 that are not found in the Rigol DS2000 series?
But FWIW, the DS1000Z series just got another page of measurements added to that particular menu in the latest firmware release. So it may get added in the near future. :-//
But FWIW, the DS1000Z series just got another page of measurements added to that particular menu in the latest firmware release. So it may get added in the near future. :-//
On the other hand, I have not experienced the "LAN freeze" when using Telnet or DSRemote from my Linux computers. DSRemote saves a complete screenshot very fast too, and shows a "partial" display of the scope's screen and controls in near-real-time over the LAN.
ETA: I just realized I have not tried the DSRemote LAN connection since "upgrading" to SP2. I hope the "upgrade" didn't break this remote-control and screensave capability.
The comments about saving to a USB stick are interesting. Minutes? Mine takes about three seconds in 'stop' and five-six in 'run'. Are your USB sticks actually vegetables with USB ports glued on?
To be fair, it seems like you're constantly trying to download firmware, testing lockups and things like that. I'm really not surprised that something minor like a startup counter may not be 100% accurate.
I think you've probably locked up, reset, upgraded, tried to downgrade and otherwise fiddled with their scope more than anyone, so I have to think you're exercising paths in the software that no one ever considered and you're probably going to see some funkiness that no one else will.Normally employees or subcontractors (a.k.a. beta testers) get paid good money for exercising all of the paths in a software, so the programmers can get their act together and users get a usable product without surprises.
By following the guide lines, I have tested my ds1054z scope and the results are as below:
My Scope sys info:
Software version 00.04.03.00.01
Board version: 0.1.1
Boot version 0.0.1.3
Firmware version: 0.2.3.11
CPLD version 1.1
(A) Freezing test:
Unable to repeat with many tries and never occur luckily ;D.
(B) Math error: yes and it does occur with the below conditions: :(
1) Scope Must be set to 500ns/div (otherwise, No error)
2) Acquire-->mode must be set to “Averages” (otherwise, No error)
3) It must have at least three channels or more to be turning on. (I used A and B for the math (A+B) and C/D just connected to nothing.). If only turning on A and B, the error won’t occur.
(NOTE: the above three conditions MUST be met at the same time in order to have the math error occurred)
BTW, input frequency, voltage and waveform do NOT contribute to the error.
You get what you pay. Cheap price, crappy stuff.
Even I had to soften up on it after getting one and seeing how nice it was. ::)
Really, it's very functional, and I really like Rigol's UI design (I find it even more intuitive to use than the Agilents I've interacted with). It's got a few quirks - I could have some fun with the source code! - but overall it's an excellent scope, and IMNSHO, not even just "for the money".
Even I had to soften up on it after getting one and seeing how nice it was. ::)
Really, it's very functional, and I really like Rigol's UI design (I find it even more intuitive to use than the Agilents I've interacted with). It's got a few quirks - I could have some fun with the source code! - but overall it's an excellent scope, and IMNSHO, not even just "for the money".
The only thing which annoys me is the probe's 1x/10x switch. It likes to switch to 1x each time I look at it. Maybe I should put some tape over it.
This has been discussed in another Rigol-related thread (can't find it right now). There is a burr -- a "flash" from the injection molding process -- on either the yellow switch lever or the window in the probe's body. While this did affect my probes, I forgot which part it was... Anyway, this burr prevents the switch from fully reaching the end position. After popping out the yellow bit and removing the burr with a sharp blade, reliability of the switch has much improved for me.
So Rigol should provide a boot update for the ones running previous version.You assume that boot is updateable.
So Rigol should provide a boot update for the ones running previous version.You assume that boot is updateable.
(Also that boot is causing the problem - unlikely...)
Well, as far as I can tell nobody with Boot 0.0.1.3 has reported having the Freeze bug.
Only scopes with version 0.0.1.2 have had it.
No, I did experience of the freezing issue while saving screen to usb. My scope is running 0.0.1.3Yes, but that's not the same Freeze bug that we are talking about here. We are talking about the freezing when the Horizontal Zoom mode is entered, Auto memory depth and Display Persistence is set to anything other than Min. You are describing a different bug, I think.
Pls refer to post #367
Sent from my iPhone using Tapatalk
Well, as far as I can tell nobody with Boot 0.0.1.3 has reported having the Freeze bug.
Anybody...?Only scopes with version 0.0.1.2 have had it.
But we know that some people with 0.0.1.2 don't have it.
(also some people with 0.0.1.1 don't have it, eg. me)
Do we really know that some with 0.0.1.2 don't have it?
Right now I'm more worried about this issue of the Measurements stopping after a random time interval. By using the Statistics option and the "Difference" setting, you get a count of how many measurement samples are taken. With 5 measurements going, it takes about 3 samples per second. My New Scope's measurements just now stopped after 896 samples. Just before that it went to slightly over 3000 samples before stopping. And just before that it went to only about 30 samples before stopping.
There is no way to get the measurements going again without power-cycling. This is really Really annoying.
We'll, I'm glad they finally showed a bit of common sense and are grabbing your specific scope to play with! Geez, how long did that take?? I had a feeling they were just guessing and couldn't actually reproduce the problem on their end.
Post specific instructions how to reproduce the math freeze-up if you can. (basic settings, etc)
Right now I'm more worried about this issue of the Measurements stopping after a random time interval. By using the Statistics option and the "Difference" setting, you get a count of how many measurement samples are taken. With 5 measurements going, it takes about 3 samples per second. My New Scope's measurements just now stopped after 896 samples. Just before that it went to slightly over 3000 samples before stopping. And just before that it went to only about 30 samples before stopping.
There is no way to get the measurements going again without power-cycling. This is really Really annoying.
The measurements stopping sounds like the application daemon crashing, should be an easy fix if the developers turn on debug consol and capture the error log. Or just put a watch dog on it so it restarts when it fails, hopefully fast enough not to impact the measurement sample rate. But the watchdog is more of a patch work around and not a true fix.
So question, now that you have the new scope. Does the SP2 still cause drastic slow down when you tried to simulate the freeze? I only ask since your now running what seems to be the same as what I have.
And as far as I know the SP2 is still not reversable.
The pastBy following the similar steps, my scope measurements stop working at count 1k3 [emoji19]. Other functions are still working like changing time base, v/d except measurement function that can't be resumed unless rebooting the scopetwothree times I've done it the measurements stopped working at 846 counts, and 1k10 counts, and 373 counts.
But you may have to wait as long as 3k counts or more. If it hasn't stopped working by 4k counts you may not have the bug, or maybe you just need to wait even longer.
Hi,
okay, the same with my scope.
I load the measurement settings from **4017, feed in 2x 10MHz sinewave ~5Vpp (rubudium vs GPS test setup) CH1 x10 (probe) CH2 via RG58 direct x1, trigger set CH1. It stops counting at 1k81. All funktions are working, but without counting forward. I tried it few times. Only the counter time is different.
"Measure all" also hangs. I tried to restart the counter with "statistic on/off, math on/off, reset... the couter set to "0" but still wouldn't count or restart. The only way (seems) cycle the power button.
Latest firmware (SP2) on boot version 0.0.1.2
Maybe Rigol can find an "internal procedure" like flash a new firmware / boot version via JTAG or something like that. I would try that. Better we can fix this issues little complicated as I send my scope back, become a new one with 0.0.1.3 and have the same failures again ;(
If RIDOL needs a DS1054Z with boot version 0.0.1.2. to test it, I got one.. ;(
@ alsetalokin4017
* MeasureFail.zip (0.86 kB - downloaded 6 times.) :--
Looks like most here are not really interested in a working scope. Maybe you are right, they have buy it, to watch the beautiful colorized traces the whole day. :-//
I see some people are calling this a "counter bug". It is important to note that _ALL_ measurements stop working, every single one, whether you have them selected currently when the bug hits or not.Ya, with "counter" I meant the measurements in all windows. It's my bad english.
Well, I suppose the "workaround" for this one is just to keep Math set up but turned OFF until you are ready to actually record some Math values or traces, then turn Math ON for as short a time as possible, then turn it OFF again, so that the measurements don't crash while you are working.
I did this last night on some work, and the scope went for like 17k sample counts with Math off, then I turned Math ON and the measurements crashed after another 763 counts. So .... work fast and you might be able to avoid having to reboot every few minutes.
Have you tried to turn the "measure->all" on and it may helps to avoid freezing. For me, it works well and I could reach 30k count more and still no measurement freezing by turning on the "measure-All".
kalvenk, your scopeshot is very interesting. You are showing two nice symmetrical sine waves that are perfectly in phase and of the same displayed amplitude, as nearly as I can figure. And you would agree, I hope, that 0 x 0 = 0. Yet, that is not what the Math trace says.Oops, yes you are right that the math multiplication output is incorrect. I didn’t pay much attention on the actual math result; instead, my eyes were much focusing on whether the counting is freezing or not. Thanks for finding this error. One thing, the input signal was fed from FY3224s signal generator running sweeping mode between 1Mhz~10Mhz 10v. Have posted here also my scope’s info.
You didn't position your channel zero-voltage baselines precisely on graticule lines, but I've marked up your scopeshot to show the baselines and the zero-crossings of the two sine waves, as precisely as I could, and I've also indicated the corresponding time points on the Math trace. Only in a couple of places does the Math trace come close to agreeing with what we would get by multiplying the traces by hand or in a spreadsheet from a data dump.
I've noted the very severe horizontal error that happens to the Math trace when the timebase is set to 500 ns/div, but here you are using a different timebase, and still getting a significant horizontal error in the Math. Congratulations! You've actually discovered Yet Another horizontal Math error bug, I think ! :palm:
I can see that you are running the SP2 firmware (by the fact that your Horizontal Measurement Menu has 4 page-dots instead of three). So I don't know why you have been able to run to 30k measurements without stopping. I don't think it's because of the All Measure table being up, as that doesn't work for me or for others who have tried it and reported. Maybe there is some other setting or option that is helping your scope run along, or maybe the random nature of the bug means you just haven't waited long enough on this particular test run.
I have duplicated kalvenk's set up with the same frequency and a parallel feed from my FY3200S of a 5 volt sine wave. I agree that the MATH trace is displaying a second harmonic of the 6.04981 Mhz but in my scope's case I do not see any horizontal displacement. To clarify the MATH trace is definitely locked to the original waveform but it displays a peak when CH1 and 2 are at a minimum and has 2 cycles to the 1 cycle of the original waveform. However there is a cyclic ~2 nsec twitch in the MATH trace position of the MATH trace , that I haven't pinned down yet. I really must sort out uploading screen prints!Sorry for the confusing, my setup signal was sweep mode running between 1Mhz~10Mhz 10v generated from FY3224s. Possibly the math trace (ch1Xch2) was unable to catch up the change of input frequency and that was why the horizontal displacement happening during my screen capture.
I have duplicated kalvenk's set up with the same frequency and a parallel feed from my FY3200S of a 5 volt sine wave. I agree that the MATH trace is displaying a second harmonic of the 6.04981 Mhz but in my scope's case I do not see any horizontal displacement. To clarify the MATH trace is definitely locked to the original waveform but it displays a peak when CH1 and 2 are at a minimum and has 2 cycles to the 1 cycle of the original waveform. However there is a cyclic ~2 nsec twitch in the MATH trace position of the MATH trace , that I haven't pinned down yet. I really must sort out uploading screen prints!Sorry for the confusing, my setup signal was sweep mode running between 1Mhz~10Mhz 10v generated from FY3224s. Possibly the math trace (ch1Xch2) was unable to catch up the change of input frequency and that was why the horizontal displacement happening during my screen capture.
... I think that if you repeat the same setup but use a fixed ~ 6Mhz signal there might be a better correspondence between the Math trace and a manual multiplication of the input signals. Except at 500 ns/div... the bug that happens there is from some other cause.
I just receive DS1000Z Firmware Released version: 00.04.03.02.03 with Release Date: 10/20/2015 from Rigol.Any changelog?
I just receive DS1000Z Firmware Released version: 00.04.03.02.03 with Release Date: 10/20/2015 from Rigol.Darn, you beat me to it. I was reviewing the change log and got a phone call.
I just receive DS1000Z Firmware Released version: 00.04.03.02.03 with Release Date: 10/20/2015 from Rigol.Darn, you beat me to it. I was reviewing the change log and got a phone call.
I noticed this version ends in .03
I think the one posted in the thread for testing was .01
So I'm shure they have a few fixes maybe now that they have a scope that doe the freeze, and the change log spells pluses correctly, so hopefully also the firmware does :-BROKE
So for those that will be trying this firmware I only have 2 questions.
1. Does it still cause a slow down like in .01?
2. Can this one be backed out and reversed back to SP1 if need be?
Marcos:The SP2 that was released in this thread I think was build .01 and this one ends in .03 with a few fixes.
It is the same, I made a mistake here. I'm sorry for the False Alarm. :palm:
Marcos:The SP2 that was released in this thread I think was build .01 and this one ends in .03 with a few fixes.
It is the same, I made a mistake here. I'm sorry for the False Alarm. :palm:
I think that they have a scope now that freezes I hope they fixed that, and maybe the spelling of pluses.
And no, there is still apparently no way to back out to an earlier version of a firmware once a later one has been installed. At least no way that I know about, and I've asked Rigol USA about this too, several times, and haven't gotten any kind of answer.
If anyone knows of a way to roll back to earlier firmware PLEASE post the information here !!
Note that freeze up bugs are also present in the Tektronix MDO3000, for the Tektronix aficionados out here :)
https://www.youtube.com/watch?v=qduFQOmzU8I&feature=player_detailpage#t=51 (https://www.youtube.com/watch?v=qduFQOmzU8I&feature=player_detailpage#t=51)
Well that's it, I have lost all confidence in Tek. I can't believe they let such a major bug out into the public. I guess these things will be appearing on eBay for pennies now.What's more important is how long they allow the bug to thrive.
It sure is hard to keep track of all these differences in the "firmware" or software suite. I wonder what other undocumented features exist in the 1000z series scopes
Can confirm that i can reproduce this bug.
Screen cap of version details attached.
Not en expert scope pilot yet, is there any other data i can provide that helps?
The significant bit is that your scope has the earlier Boot Version. The Freeze Bug is apparently fixed on scopes with Boot Version 0.0.1.3. Unfortunately I know of no way to change/update your Boot Version; installing new "firmware" updates from a GEL file only changes the "Software Version".
The significant bit is that your scope has the earlier Boot Version. The Freeze Bug is apparently fixed on scopes with Boot Version 0.0.1.3. Unfortunately I know of no way to change/update your Boot Version; installing new "firmware" updates from a GEL file only changes the "Software Version".
Unfortunately for your theory, plenty of people have boot 0.0.1.1 with no bug (eg. me).
Total count 6 people confirmed reproducible on boot code 0.0.1.2 and 6 people not reproducible on boot code 0.0.1.2.
Not everyone is good at following instructions either which skews numbers.
The significant bit is that your scope has the earlier Boot Version. The Freeze Bug is apparently fixed on scopes with Boot Version 0.0.1.3. Unfortunately I know of no way to change/update your Boot Version; installing new "firmware" updates from a GEL file only changes the "Software Version".
Unfortunately for your theory, plenty of people have boot 0.0.1.1 with no bug (eg. me).
Does anyone know of any scope that does _not_ have Boot Version 0.0.1.2 and that _does_ have the Freeze Bug?
Now imagine what a piece of junk is inside this scope. Use the scope with time base bigger than 1 sec and it will take ages to refresh the screen.you can either...
Hopefully peoples will stop buying this crap forever and Rigol will be sued to feel the customer frustration about their products.i'm frustrated with my Rigol because it cannot make coffee for me..
maybe he will use it just as a decoration inside his lab :)if he doesnt know how to use it, then that it will become... are you spammer from Siglent or gwInstek guy?
Hopefully peoples will stop buying this crap forever and Rigol will be sued to feel the customer frustration about their products.
Thanks God I sold mine but I feel sad about new owner, maybe he will use it just as a decoration inside his lab :)
Now imagine what a piece of junk is inside this scope. Use the scope with time base bigger than 1 sec and it will take ages to refresh the screen.
Hopefully peoples will stop buying this crap forever and Rigol will be sued to feel the customer frustration about their products.
Thanks God I sold mine but I feel sad about new owner, maybe he will use it just as a decoration inside his lab :)
Now imagine what a piece of junk is inside this scope. Use the scope with time base bigger than 1 sec and it will take ages to refresh the screen.
Hopefully peoples will stop buying this crap forever and Rigol will be sued to feel the customer frustration about their products.
.. are you spammer from Siglent or gwInstek guy?
Why in Poland they still sell this "buggy" version?
Why in Poland they still sell this "buggy" version?
Why should them stop selling those models in Poland, if they don't assume the fault, and keep selling in other countries? Why is Poland special?
Apply the hack to upgrade trial options to Official and see the magic. Board version will change from 0.1.1. to 0.2.3 from time to time.
Now imagine what a piece of junk is inside this scope. Use the scope with time base bigger than 1 sec and it will take ages to refresh the screen.
Thanks God I sold mine but I feel sad about new owner, maybe he will use it just as a decoration inside his lab :)
Avoid this scope
While the scope itself is not bad, it has two major deficiencies for anyone wanting some serious work
1) The date in it cannot be changed. As crazy as it sounds in 2015..... it has a default date of December 31, 1969 at 4:00 PM and every single one of the saved files will have exactly the same date and time stamp. Imagine having a few days worth of data that no longer can be correlated to the conditions you were experimenting with
2) The file saving process is borderline useless. Sometimes it picks it's own names. overwrites data files etc. It can take 3 to 4 minutes to enter a name. The file saving system is likely based on DOS software and feels like it is indeed from 1969 like the permanent date stamp in the system
3) The voltage scale that you put prior to taking a reading has a tremendous influence on the actual reading. For example, if you had it at 100 mV per division and you were reading something in the 1-3 V region, you will definitely get the wrong reading (drastically different). If you are one scale away, then it is able to adjust in time. ie if you had it in the 500 mV per division and reading something in the single digit, then it will scale accordingly and you get more real data. What this means is that most times, you have to take the data twice to confirm you have real data
In any case, knowing what I know now, I would definitely keep looking for another brand. The thing that irritates me the most is that they gloat about having 20 M of memory when in reality this memory is borderline useless. I would rather have 1 M of memory that is useable that 20M that is useless
BUYER BEWARE!!!! Don't make the mistake I made and regret it
You have no idea how DSOs work, don't know how to use them, nor did you do your research on the product. You should remove this review because it's got no bearing on the quality of the product.
It doesn't have a real-time clock, nor does it claim to. The files don't have timestamps at all: The file creation timestamp you're seeing is the beginning of the UNIX date epoch (1/1/1970 at midnight), adjusted for the time zone and DST status of your computer.
The sample memory isn't for long-term logging, it's for pre- and post-trigger review of a signal.
The vertical scale absolutely has an effect on measurement, since that sets the gain of the input amplifiers, so if you set a low range and then measure a signal that exceeds the range, it will clip. Every oscilloscope works this way. Most DSOs (including this one) use 8-bit sampling, which means just 256 signal levels. Consequently, it's essential that the input range matches the signal you're looking at. If the 256 levels had a fixed mapping to the maximum input range (10V/div, 8 divs vertical, so 800V peak-to-peak), so that it never clips, it would only be able to resolve 3V steps, regardless of range.
I would rather have 1 M of memory that is useable that 20M that is uselesssounds like a Siglent/Instek fanboy who got sucked up by the 1Mpoints FFT brainwash stuff (https://www.eevblog.com/forum/blog/eevblog-845-oscilloscope-fft-comparison/msg856896/#msg856896). or a blind faith believer of Dave's Chapter 845 (17:45) (https://www.eevblog.com/forum/blog/eevblog-845-oscilloscope-fft-comparison/) ;D
So what is the current status of the Freeze Bug and the Math Bug ?
Did Rigol acknowledge them?
Did the latest software update fix them?
If "not" - when is the next version due ?
There does not appear to be any way for the user to update the Boot Version -- that I know of. I have asked Rigol USA several times about this but never got a real answer.
Yet there was at least one firmware release with a boot update and instructions on how to do it. Perhaps there is one specific firmware version out there that would allow an update.
Measurements Fail bug: I reported this to Rigol USA as soon as I found it, and they were able to reproduce it immediately on their scopes. This one seems to have been introduced by the update to latest firmware SP2; at least I never noticed it on earlier versions. It may also be related to Boot Version 0.0.1.3.
I have boot version 0.0.1.2 and I can reproduce this bug. So it looks loke it's not boot-related for me.
Firmware v00.04.04.00.07 no more freeze up bug
Before update
Nothing connected to inputs and persistence on any setting than min would freeze up scope when horizontal zoom enabled
After update
Any persistence setting and horizontal zoom enabled works now :-+
Well... it's nice to know that this "hardware bug" is finally fixed for early Boot Versions, with a software update.
Firmware v00.04.04.00.07 no more freeze up bug
Before update
Nothing connected to inputs and persistence on any setting than min would freeze up scope when horizontal zoom enabled
After update
Any persistence setting and horizontal zoom enabled works now :-+
Model DS1104Z(1054Z enabled all options)
SW 00.04.04.00.07
Board version 0.2.1
Boot version 0.0.1.2
FW 0.2.3.11
CPLD Version 1.1
Model | DS1104Z |
SN | (ommitted) |
Software Version | 00.04.03.02.03 |
Board Version | 0.1.4 |
Boot Version | 0.0.1.4 |
Firmware Version | 0.2.3.11 |
CPLD Version | 1.1 |
Build Date | Sep 11 2015 09:42:... (ommitted) |
F:\zscan\original\RIGOL\DS1000\DS1000Z-00_04_04_01_01\DS1000ZUpdate_NAND.GEL / CRC32: 4C2EF338
00000000 - File Type: DS1000Z
00000010 - Software Branch/Version: 00.04.04.01.01
00000020 - Bitmask: 00000F00
00000024 - # Sections: 11
Offset Section Name SectiSz StartAdr CRC32 Type
00000028 /sys/SparrowAPP.out 00107791 000002BC 865DD4FE 00000001 [000002BC-00107A4C] CRC OK
00000064 /sys/SparrowFPGA.hex 000C4372 00107A4D C72D7DD0 00000005 [00107A4D-001CBDBE] CRC OK
000000A0 /sys/SparrowDGFPGA.hex 00046F04 001CBDBF AD60366F 00000006 [001CBDBF-00212CC2] CRC OK
000000DC /sys/SparrowBootloader.sb 000503B0 00212CC3 E62EF3EE 00000008 [00212CC3-00263072] CRC OK
00000118 /sys/logo.hex 000BB818 00263073 1F2E52B7 0000000A [00263073-0031E88A] CRC OK
00000154 /sys/guiResData.hex 000B6B34 0031E88B 9C2E4FC0 0000000C [0031E88B-003D53BE] CRC OK
00000190 /sys/guiPicData.hex 0001E6BF 003D53BF 10D74A0D 00000011 [003D53BF-003F3A7D] CRC OK
000001CC /sys/SparrowConfig.hex 000BB818 003F3A7E 09D39C43 00000010 [003F3A7E-004AF295] CRC OK
00000208 /sys/SparrowWaveTable.hex 000020E8 004AF296 B1CE7C07 0000000B [004AF296-004B137D] CRC OK
00000244 /sys/SparrowCalFile.hex 00022EFD 004B137E 91673CA7 0000000F [004B137E-004D427A] CRC OK
00000280 00000118 004D427B 00000000 00000032 [004D427B-004D4392]
Offset CRC32 Flags Filesize Endianes Branch/Version
000002BC 82AC1341 00000003 00107779 AA5555AA 00.04.04.01.01 [000002D4-00107A4C] CRC OK
00107A4D C9AF5D56 00000000 000C435A AA5555AA 00.04.04.01.01 [00107A65-001CBDBE] CRC OK
001CBDBF 138E13B9 00000000 00046EEC AA5555AA 00.04.04.01.01 [001CBDD7-00212CC2] CRC OK
00212CC3 -------- -------- -------- -------- -------------- [00212CC3-00263072]
*** Bootloader Header ***
00212CC3 Header SHA-1: 49D6C3738FA6FD2AE905AAF7E090E7EF79BA5463 [00212CD7-00212D22] HASH OK
00212CD7 Signature 1: STMP MAGIC OK
00212CDB Format Version: 1.1
00212CDD Flags: 0x0000
00212CDF Image Size: 000503B0
00212CE3 1st Boot Tag Offset: 00212D53
00212CE7 1st Boot Section ID:
00212CEB # Encryption Keys: 1
00212CED Key Dictionary Start: 00212D33
00212CEF Header Size: 00000060
00212CF1 # Section Headers: 1
00212CF3 Section Header Size: 16 bytes
00212CF5 Random Padding: 0x5EBD
00212CF7 Signature 2: sgtl (Sigmatel?)
00212CFB Creation Time: 27-04-2015 14:28:39
00212D03 Product Version: 999.999.999
00212D0F Component Version: 999.999.999
00212D1B Drive Tag: 0x0000
00212D1D Random Padding: 0x8F9A3D11874A
*** Sections Table ***
00212D23 ID: | Ofs: 00212D63 | Len: 000502F0 | Flg: 00000001 - ROM_SECTION_BOOTABLE
*** Key Dictionary ***
00212D33 OTP Key0 Hash: DB4E7528C0F9A5207DD91E755303EC2B CBC-MAC_AES OK
*** Session Key (decrypted) ***
00212D43 Key: 46A9672A461903686222309F13ED6302 (using OTP Key0)
*** Sections (decrypted) ***
00212D53 TAG | 0001 | Sect ID: | Len: 000502F0 | Flg: 00000001 - ROM_SECTION_BOOTABLE
00212D63 LOAD | 0000 | Adr: 00000000 | Len: 0000003C | CRC: 408DF430 CRC OK
00212DB3 LOAD | 0000 | Adr: 00000400 | Len: 00003548 | CRC: DAE63C06 CRC OK
00216313 FILL | 0000 | Adr: 00018000 | Len: 00000960 | Ptn: 00000000
00216323 LOAD | 0000 | Adr: 00008000 | Len: 00000020 | CRC: 4D3C6D73 CRC OK
00216353 CALL | 0001 | Adr: 00008000 | Len: 00000000 | Arg: 00000000
00216363 LOAD | 0000 | Adr: 00000000 | Len: 00000040 | CRC: A9978A44 CRC OK
002163B3 FILL | 0000 | Adr: 00007FFC | Len: 00000004 | Ptn: 00000000
002163C3 LOAD | 0000 | Adr: 41000000 | Len: 0004CC10 | CRC: 2AE4A733 CRC OK
00262FE3 FILL | 0000 | Adr: 41300000 | Len: 00001900 | Ptn: 00000000
00262FF3 FILL | 0000 | Adr: 41301900 | Len: 00003B44 | Ptn: 00000000
00263003 FILL | 0000 | Adr: 41900000 | Len: 00300000 | Ptn: 00000000
00263013 LOAD | 0000 | Adr: 00008000 | Len: 00000020 | CRC: DF5BA493 CRC OK
00263043 JUMP | 0001 | Adr: 00008000 | Len: 00000000 | Arg: 00000000
*** File SHA-1 Hash (decrypted) ***
00263053 File SHA-1: C0274B0B57C7687849AB8D042F3E3C23142D9D42 [00212CC3-00263052] HASH OK
Block Processed OK
00263073 9B4EA177 00000000 000BB800 AA5555AA 00.04.04.01.01 [0026308B-0031E88A] CRC OK
0031E88B 271E3AB5 00000000 000B6B1C AA5555AA 00.04.04.01.01 [0031E8A3-003D53BE] CRC OK
003D53BF 01873014 00000001 0001E6A7 AA5555AA 00.04.04.01.01 [003D53D7-003F3A7D] CRC OK
003F3A7E 5DEF7058 00000000 000BB800 AA5555AA 00.04.04.01.01 [003F3A96-004AF295] CRC OK
004AF296 27F4C06F 00000000 000020D0 AA5555AA 00.04.04.01.01 [004AF2AE-004B137D] CRC OK
004B137E 1E61A8F6 00000000 00022EE5 AA5555AA 00.04.04.01.01 [004B1396-004D427A] CRC OK
File Processed OK
Sorry for reviving this but just want to inform that I have a GEL with version 4.4.1.1 that has a bootloader version > 0.0.1.2 (for sure) .
Model:DS1xxxZ
SN:DS1ZA17140xxxx
Manufacturer:RIGOL TECHNOLOGIES
Board Ver:0.1.1
Firmware Ver:0.2.3.11
BOOT Ver:0.0.1.3
CPLD Ver:1.1
SoftWare Ver:00.04.03
Btw if you read this post linked below it says it will nuke your scope if you have lower than a version 0.0.13 bootloader and apply that update. So yeah beware about giving that specific version to someone to apply. It's probably a typo and applicable to versions below 0.0.1.3 (makes more sense to me anyway).
My goal was to help. You guys know better.
But, what I think it says there is that you shouldn't have 4.4.1.1 with bootloaders < 0.0.1.3.
So, this GEL that I shared solves that problem because it will, besides upgrading the APP, also upgrade the bootloader to >= 0.0.1.3.
What I can't understand is why Rigol didn't make it public!
Just my 50 cents...
Hi,
I have a Rigol DS4000 series scope, the DS4024. It's obviously not the 1054, but maybe they are much the same. Had it for a few years and it has been absolutely fine, until today. It behaves something like the original owner of this thread describes. It locks up on booting and shows only "Rigol" on the screen and a bunch of LED's are lit. Stays like this forever. The trick with pressing the fifth left button on power up doesn't work. If I press the "Help" button on power up, it doesn't even say "Rigol". The screen is black. The only sign of life now is the "Single" button is lit.
Anybody having a clue?
I would be very happy.
Rudy