New Rigol DS1054Z oscilloscope

[bakerts]

I scraped a few dollars together and ordered a DS1054Z along with some other things from TEquipment using the discount code. It's coming tomorrow, and I'm pretty excited!

I have no friends, and wanted to tell someone...   

[TheSteve]

My DS1054Z arrived today, upgrade went great!

Came with 04.03.00 installed - I see the newest download update is 04.03.00.01 - Are they the exact same version and the scope just doesn't show the least significant digits or should I try an update?

[rolycat]

My DS1054Z arrived today, upgrade went great!

Came with 04.03.00 installed - I see the newest download update is 04.03.00.01 - Are they the exact same version and the scope just doesn't show the least significant digits or should I try an update?

Unless you know that a newer firmware version fixes one or more bugs which are an issue for you, I'd leave well alone.

[alsetalokin4017]

thanks for the reply's
 i was a bit on the fence about the bugs. wasn't sure if it was the glitchy brick people were making it out to be.  ill have to start hunting down a supplier. Ive seen it mentioned that there is some sort of discount for EEVblog members, is that true? could i get some details if anyone knows.

ill look into getting a LA too

cheers all 

The major bug at the moment is that with a specific time base setting, AND a longer than minimum persistence setting, AND the memory depth set to auto, SOME scopes lock up. It is a major bug because the scope should NEVER lock-up, but it's so easy to avoid that it's completely a non-issue.  Believe me, with all the hair pulling, cursing and face palming I've had to do over the years to track down and make workarounds for bugs in various pieces of equipment, I'd kill to have this be the worst I'd ever have to run into!

I would almost agree with you if _every_ DS1054Z had the bug. A known issue, relatively easy to work around, possibly fixable in later software revisions.

But ... the fact seems to be that _some_  units do, and some don't, have the bug, with slightly more than 50 percent of units tested having the bug. (In the other thread discussing this bug, 46 users have reported testing their scopes and 24 have been able to reproduce the lock-up.) This means that there is something seriously wrong at Rigol. The only thing I can think of is that _some_ DS1054Z units have some defective, or at least "differently abled" hardware that made it into the scopes. (For newcomers: This bug happens in susceptible units regardless of whether or not the scope is "virgin" unhacked, and regardless of firmware 4.02 or 4.03.) So _some_ DS1054Z scopes are better than others.... the ones that don't lock up are obviously better.
Who knows what other "bugs" may be associated with whatever fault is causing the Lock-Up (or Freeze) bug? The scopes that suffer from it are, in some sense of the word, defective. If it's a hardware issue, or a construction issue, then how long will it be before something else associated with the defective hardware or construction raises its head and bites?

I still use mine every day, I still love it, and I have no intention of returning it _unless_ Rigol issues a recall... which I think is very unlikely. But it is definitely defective.... since around 50 percent or slightly fewer of the total DS1054 units tested _do not_ behave this way.

It's this half-and-half distribution that is most distressing to me. I'm in the "losing" group, having a scope that is subject to the bug. So I can't use certain legitimate settings that other DS1054Z users can use.

[vk6zgo]

Another day, and other 5 minutes of test:

The first image is of a 130MHZ signal (50% AM modulated by 1khz sine)  just to push the scope to its limits.
The second is about the trigger out jitter time (3nS) measured from the rear output.

Moreover following results are measured by a calibrated 5334B and 1MHZ square wave:

• in dot mode the best wfps i saw was 52.8k @50nS/div 600 pts memory.
• in vector mode it was 28.8k @50nS/div 600 pts memory.

The acquistion modes doesn't affect the wps rate.

These results simply make me sad because now I have to get one! 

If you really want to see the limitations of your instrument,look at the 130MHz modulated signal at the modulation frequency.
Set the time/div to something like 5mS/div to give you a reasonable number of modulation cycles.
Older DSOs would always fail this test,even with much lower carrier frequencies than you are using,because they reduced the sample rate radically at such time/div settings.

Modern DSOs don't seem to reduce the sample rate so much,but it would be interesting to see if the DS1054Z can pass this test with such a high carrier frequency.

[John Coloccia]

This means that there is something seriously wrong at Rigol. The only thing I can think of is that _some_ DS1054Z units have some defective, or at least "differently abled" hardware that made it into the scopes. (For newcomers: This bug happens in susceptible units regardless of whether or not the scope is "virgin" unhacked, and regardless of firmware 4.02 or 4.03.) So _some_ DS1054Z scopes are better than others.... the ones that don't lock up are obviously better.

It doesn't mean that at all, and I explained at least once or twice in the other thread how "identical" hardware can exhibit different behavior, especially if you're dealing with some sort of race condition (and I would bet that we are).

[alsetalokin4017]

This means that there is something seriously wrong at Rigol. The only thing I can think of is that _some_ DS1054Z units have some defective, or at least "differently abled" hardware that made it into the scopes. (For newcomers: This bug happens in susceptible units regardless of whether or not the scope is "virgin" unhacked, and regardless of firmware 4.02 or 4.03.) So _some_ DS1054Z scopes are better than others.... the ones that don't lock up are obviously better.

It doesn't mean that at all, and I explained at least once or twice in the other thread how "identical" hardware can exhibit different behavior, especially if you're dealing with some sort of race condition (and I would bet that we are).

I'm afraid that I don't agree with that. If we cannot expect identical hardware to behave identically in identical situations, how are we to design anything with confidence?

How do you think Dave would have reviewed this scope, if he had managed to make his freeze up while making his "review" or "teardown" videos? Starting up non-responsive and requiring a "factory reset" to work at all?  I can just imagine the descriptive rhetoric he may have emitted.

How would you feel if the next time you took an airplane flight, the flight failed to take off, due to "some sort of a race condition" in the flight management software?

Personally, I feel rather annoyed that my scope locks up _under any conditions_, but more so when I know that other users have the same model scope that _does not lock up_ under those same conditions.

[John Coloccia]

I'm afraid that I don't agree with that. If we cannot expect identical hardware to behave identically in identical situations, how are we to design anything with confidence?

Because you design your system to work with plenty of margin, so slight differences don't matter.  When you have a bugs, they can operate in ways that there is NO margin....because it's a bug.  Come on, do you really think that there is such a thing as "identical" hardware.  You'll never be able to design anything but the most trivial of systems if you depend on all of your design parameters being identical from unit to unit.

Obviously, I don't have the code in front of me, but I don't have any reason to believe that this isn't just a software bug, and that they'll fix it without much trouble.  I've tracked down a great many software bugs over the years that are practically impossible to reproduce on some units, and happen every time on others.  Sometimes, it's actually a hardware problem on the WORKING units that is actually masking the software bug, and it's the "broken" units that are actually doing it right.  That happens.

[Howardlong]

There was a similar feature when the interim beta fix to the infamous jitter problem was released late last year. Although the jitter thing was apparently resolved, the front panel locked up about 50% of the time on some units when cold booted, but the display itself still appeared fine. Fix was to cold boot again. While the fix isn't the same, the symptoms, of an apparently locked panel, are.

It would be reasonable to expect that there is a standalone MCU running the front panel switches, LEDs and quadrature encoders, and that talks with the main unit's processor. It's also quite reasonable also that they lose comms for a variety of reasons, most likely due to a timing related problem. Although the main processor will be crystal controlled, for a realtively low end front panel MCU it'll quite likely be using a simple RC oscillator, either internal or external, with the tolerances associated with such, and so sometimes you'll see the interprocessor comms break. This seems to be exacerbated under high primary processor load, which could easily affect the inter-processor timing.

Equally, there are a number of different versions of board versions inside these scopes. That too could help explain it away. Testing firmware against a number of seemingly benign hardware differences may seem unnecessary, but it is, I do exactly that on my products, and sometimes you need to put in slightly different code paths for different board versions. Those different code paths, if not fully regression tested across all hardware configurations, may inevitably lead to such bugs.

This is of course conjecture as to the actual underlying problem, but hopefully it explains how some apparently superficially identical units, aren't actually the same in subtle ways not immediately evident.

[rbino]

Hi everybody, this is my first message here!
First of all, I just wanted to thank you for all the useful info that you put here, I received my DS1054Z today after lurking for weeks before deciding. This is my first scope so I'm very excited!
I've already unlocked it and it all went smooth at the first try, mine came with firmware 00.04.02.SP4, do you think that I should update to the latest one or "If it works, don't touch it"?

[MarkF]

I see that the Rigol upgraded firmware is now sporting version 00.04.03.SP1 inside the posted zip file

http://beyondmeasure.rigoltech.com/acton/fs/blocks/showLandingPage/a/1579/p/p-0019/t/page/fm/0

Has any one tried this newest upgrade?

[bitwelder]

I see that the Rigol upgraded firmware is now sporting version 00.04.03.SP1 inside the posted zip file

That SP1 makes me think they found some important regression from the 00.04.03.0x, so indeed it would be good to know what was fixed.

[TurboTom]

Seems like the new firmware fixes the "freeze" bug. At least on my DS1054Z (hacked) after I installed the update, the problem appears to have vanished.

Cheers,
Thomas

[JohnPen]

I have updated my DS1054Z to this latest firmware version and find the freeze problem with 1usec, 100msec persistence and horiz delayed mode is still there.  The panel controls all lock up as before.  However there is one difference a reboot always restores the scope to normal every time no more fifth button pressing.  Also another funny is that pressing the Auto button (already flashing Auto), after a few relay clicks, returns a message saying 'Auto detected none'.  I need to refresh my mind on what pressing Auto should do and when to do it.  Back to the manual watch this space.

John

[JohnPen]

'Auto detected none' only applies when there is no signal input so that is OK although  I would have preferred  'no signal input' perhaps.  However the 'freeze' is definitely not fixed by this latest f/w build on my particular DS1054Z but at least it works every time on just a reboot.  I await the next f/w update.

John

[alsetalokin4017]

Unfortunately... even after installing the 04.03.SP1 firmware just now... I am still able to get the scope to lock up, and even start up locked, just as before. And the "horizontal position of the Math trace" bug is still there too.




ETA: But now the nonfunctional window button that had appeared in the X-Y menu is gone.

[TurboTom]

That's awkward. The first attempt to reproduce the lock-up after I flashed the new firmware (after reboot of course) didn't show the bug. Now I experimented some more and was somewhat able to freeze the thing but yet not completely - the o'scope responded to inputs but it did so only with a huge delay. Finally, it appeared to have locked up completely. After a power cycle, the instument booted right into frozen state. After that, I power cycled the device again (without applying the F5 reset) and -- surprise, surprise -- it reset all by itself to factory configuration, with chinese language set.

After that, I ran a self calibration which ended up with a message "Calibration failed"... Currently, the claibration is running a second time, if this also fails, I'll re-install the previous firmware to see if this is causing the problem.

Probably I should rather use the instrument for what it's ment for and not tinker around with it ;-)

Cheers,
Thomas

[JohnPen]

Further information on the 'freeze' condition.  I have tried a few other checks on recovery from a 'freeze' see below.

Start conditions: 1khz calibrate signal on CH1,  120kpts, normal display, 100msec Persistence

Timebase in usec.         Time taken for Delayed to go to ON state.

500                                      ~1 sec
200                                      ~2-3 sec
100                                      ~4 sec
50                                        ~6-7 sec
20                                        ~30 sec
10                                        ~40 sec *
5                                          ~35 minutes
1                                          I hate to think!

* Incidentally the screen display highlight for the button takes some 10 secs to appear followed another 30 sec to become active again.  The highlighting always precedes the becoming active condition.

It would appear that wherever the f/w goes it recovers but whatever looping condition is involved the timebase period is impacting on the termination time of the loop.  Each timebase increment increases the sampling rate and presumably extends the data storage requirements in some way,perhaps there are many 100 msec persistences, being stored!  Until that all completes and says ok nothing further happens!  I will try some more thoughts out later.

John

[TurboTom]

Some more findings with the new firmware: After the self calibration routine kept failing, I attempted to revert to firmware 04.03 - which also returned a failure message. So as yet, I would recommend not to install the new firmware! Of course, these are all findings with my particular DS1054Z, others may behave differently. If the problems persist, I will wait for the next firmware revision and if this wouldn't sort the difficulties, undo the hack and return my o'scope to the distributor for repair.

Add-On: The calibration procedure finally terminated successfully -- at the fourth attempt! I guess I'll be a little more reluctant when the next update is available :-)

Cheers,
Thomas

[JohnPen]

From my previous post it would seem that a relationship between the Sampling rate and the 'freeze' condition does exist see below:

TB usec         Sampling Rate Msa/s     Delayed ON secs

500                     10                         ~1
200                     25                         ~2-3
100                     50                         ~4
50                      125                        ~6-7
20                      250                        ~30
10                      500                        ~40
5                       1,000                      ~35 minutes

John

[alsetalokin4017]

Some more findings with the new firmware: After the self calibration routine kept failing, I attempted to revert to firmware 04.03 - which also returned a failure message. So as yet, I would recommend not to install the new firmware! Of course, these are all findings with my particular DS1054Z, others may behave differently. If the problems persist, I will wait for the next firmware revision and if this wouldn't sort the difficulties, undo the hack and return my o'scope to the distributor for repair.

Add-On: The calibration procedure finally terminated successfully -- at the fourth attempt! I guess I'll be a little more reluctant when the next update is available :-)

Cheers,
Thomas

Whew, that's pretty scary ... so I just ran the self-cal routine on my scope. It took 18 1/2 minutes, same as before the new firmware update, and completed successfully without problems.

Does anyone have a "change log" for this latest firmware update? 00.04.03.01.05, identified as 00.04.03.SP1 on the System Information screen when installed.

Does anyone know if it is even possible to roll back to an earlier firmware version than the one currently installed on a DS1054Z?

[blat]

Does anyone have a "change log" for this latest firmware update? 00.04.03.01.05, identified as 00.04.03.SP1 on the System Information screen when installed.

It's available at the same URL as the previous one. The first four are "enhancements" the rest "modifications". Here's what it says:

Version:00.04.03.01.05
Date:2015-06-16

1. System menu adds support for French.
2. Added the remote command and function for inter-connection with DG4.
3. The module of Math increase the function of filter.
4. Added the remote command which can set the invert and format of picture (:DISP:DATA? {<color>,<invert>,<format>})

5. Optimized the algorithm of LF calibration and self-calibration and increase the prompt of failure.
6. Turned on delay scanning and force stop the system,then the trigger position of waveform changed.
7. In scanning mode,turned on the Zoom display and setted the AC as the trigger coupling,then adjusted the timebase of Zoom zone and the waveform display error.
8. In mixed mode,use logic channel as trigger source and turn off the logic channel and stop the system,then adjust the timebase to the minimum,the part of analog signal disappeared.
9. In mixed mode,use logic channel as trigger source and turn off the logic channel,then the analog signal shifted.
10. The wave of channel1 can not be displayed while open the scan mode then switch the channel2 over and over again.
11. The waveform will be move downward while change the trigger type from the pattern type to the edge type.
12. In scanning mode,turned on the delay scan,the display of the first waveform is wrong.
13. It can not display the waveform of trace when load the file of trace data in “STOP” mode and math module is on.
14. Adjust the timebase offset can make the system crashed when run the “I2C Decoder”.
15. Save the waveform when turned on FFT function and use the momery data to operate and turn on split display,then load the waveform of saved,but the display of waveform is error.
16. Save the waveform when turned on the delay scan and only the logic channel turned on and trigger source is logic channel,then default the system setting and load the waveform of saved,but the display of waveform is error.

[sigsegv11]

New owner of a DS1054Z here, my first 'scope!

I'm beginning to understand the relationship of memory depth to screen update speed, as well as persistence.

One thing I don't understand is why does the scope drop down from 1GSa/s to 500MSa/s even in single shot mode when I switch from 500us to 1ms timebase?

It's clearly not that some memory is slower than the rest, as if I force memory depth to 24M points and capture a single shot at 500us timebase, and then I can zoom out to 2ms timebase with a 1GSa/s sample. If I do the same capture starting with a 2ms timebase I get 250MSa/s.

Is there a good reason for this? I can't figure it out.

[tech5940]

I had upgraded to 00.04.03.01.05 and my scope failed self cal first time around as well. Second time it did pass though. Just a heads up for those thinking of upgrading the firmware you might want to wait!


Sent from my iPhone

[TheSteve]

Having a great time with my DS1054Z, had it for a few days now. The -3db point for all 4 channels is 117 MHz which seems pretty decent(my scope thinks it is a DS1104Z for some reason). The built in hardware frequency counter is rock solid to about 99.5 MHz, the software counter seems to keep going to about 400 MHz if you only need a rough estimate of the frequency(near MHz). If I could change anything I'd make the case black, and probably lay out the keys a little bit more like a Tek scope. Overall I am extremely impressed, I sold a Tek THS720 to finance the purchase and have $$ left over.
This is my first Rigol product, I imagine there may be a DSA815-TG in the shack very soon as well.