New Rigol DS1054Z oscilloscope

[Bud]

Can you post the same graph but with 6MHz span and 500kHz span?

[poida_pie]

Can you post the same graph but with 6MHz span and 500kHz span?

I'd be happy to. See attached.

[Bud]

Thanks poida_pie. The first close-up graph has poor resolution but still possible to reference some peaks from the second graph. The reason I asked for a 6MHz span graph was that I wanted to see if Rigol used the same 2.5MHz PLL phase frequency detector frequency they used in the Beta. Sure enough, 2.5MHz spikes can be seen to the left and to the right from the carrier at around 40dBc which is a horribly high level for a PFD frequency to leak into the carrier. The PLL I assembled has them at 75dBc (dBc stands for decibel below carrier).

Having said that PFD is 2.5MHz away from the carrier, other spikes can be seen in proximity to the carrier in the second graph, and that is an indication the PLL is unstable and may still be unlocked. These spikes are approximately at -35dBc which corresponds with measurements Dave just posted in the DS1000 jitter thread under Blog Specific section of the board.

https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg578859/#msg578859

So what Rigol appears to have done is they tried to reduce PLL modulation caused by the PLL being unlocked and that masked the jitter issue, however I am yet to see a good screenshot with a good ADC clock and I have not yet. Another person promised to crack open his DS1000 tomorrow and measure the ADC clock with his HP spectrum analyzer. Hopefully that will bring some clarity. I am saying some because it would be needed to also decode the PLL programming bytes on the SPI bus to see if idiotic PLL setup they did in the original and Beta firmware is still there.

[sanman]

Upgrade worked fine for me and did NOT kill the upgrades.

LOVE the new EXTRA LARGE measurement font O0

[netdudeuk]

EXTRA LARGE measurement font ?

I wonder why we don't get to see a firmware change log, like we do with many other upgrades of this type.

[Howardlong]

I guess Bud's never gonna let this one go then. 

[tautech]

I guess Bud's never gonna let this one go then. 

Nor should he, the proper design and component implementation in test equipment is in ALL of our interests, is it not?
Edit
A recent post sheds more light on the PLL issue:
https://www.eevblog.com/forum/blog/eevblog-699-rigol-ds1054z-oscilloscope-jitter-fix-testing/msg579692/#msg579692

[Howardlong]

I guess Bud's never gonna let this one go then. 

Nor should he, the proper design and component implementation in test equipment is in ALL of our interests, is it not?

While I agree that "the proper design and component implementation in test equipment", or indeed any device, is in everyone's interests, I felt that the nature of the continuous undermining subtext was rather unnecessary and added no value, in fact quite the opposite, and quite understandably the public feedback from Rigol became almost non existent as a result. There is more than one way to skin a cat, personally I prefer a positive approach. Just sayin'

[Johnny Electron]

Well I'm glad Rigol moved on this.  My new scope is set to arrive tomorrow and I feel a bit more confident in my decision now.  I'll have to update the fw right away.    Thank you Rigol and thank you members of this forum.  I'm glad I found this place!:)

[janoc]

Hello,

As I wrote in another thread, I did the update on my 1074Z and it fixed the trigger jitter for me. However, the scope seems to be booting a lot slower now - is that a normal behavior or something fishy going on?

[pickle9000]

Activations keys and jitter fix firmware DS1054Z.

For those interested. A few people have updated the firmware with the keys already installed. I did it as well and have had no issues all the keys are still there. The firmware 00.04.02.SP4 is the current one that in theory fixes the jitter issue. It did fix mine, so far I haven't seen any fails in this regard but it's early days.

My original firmware:

Software 00.04.02.SP3
Board 0.1.1

I used the activation code DSER and it worked on the first go. http://gotroot.ca/rigol/riglol/ A google search for "riglol" should find the key maker if the link dies. You will see others keys listed on the web page, the correct key is not listed you need to use DSER. You may want to download the source and store it in a safe place for future use.

Note that after the keys are activated your Model Number will change to DS1104Z this is normal.

I do not know if the keys will install correctly after the firmware update. I expect that it would but I did not do it that way.

Just a quick note about the firmware install.

- Use a good quality USB stick freshly formatted.
- Install time varies 2-5 minutes is typical but I did read a post that one that was close to 10 minutes. You need to allow the install to finish. Removing power or the stick during the update could cause issues.
- I ran the cal routine after the update. I don't know if that's a recommended procedure but as a general rule I do after a firmware update. Make sure the scope is up to temp so the cal is correct.

 

 

[DanielS]

As I wrote in another thread, I did the update on my 1074Z and it fixed the trigger jitter for me. However, the scope seems to be booting a lot slower now - is that a normal behavior or something fishy going on?

I (still) haven't received my 1054Z so I cannot say anything about the pre/post-update boot time but depending on the nature of Rigol's PLL fix, maybe the firmware does some form of clock quality analysis during boot and goes through PLL parameter ranges to find the best parameters for individual PLLs. If that's the case, they should be saving those settings as a starting point for the next boot so the POST/BIST/Cal will not need to spend as much time searching afterwards, much like how cable modems store their last known-good configuration channel to avoid the blind 54-1000MHz scan to find it on subsequent power-ups assuming it has not changed.

[pickle9000]

Hello,

As I wrote in another thread, I did the update on my 1074Z and it fixed the trigger jitter for me. However, the scope seems to be booting a lot slower now - is that a normal behavior or something fishy going on?

I haven't noticed any boot delay. I'm getting 19 seconds.

[mamalala]

- I ran the cal routine after the update. I don't know if that's a recommended procedure but as a general rule I do after a firmware update. Make sure the scope is up to temp so the cal is correct.

Speaking of which... Is it just my scope, or do others see the same, uh, error in offset adjustment after a cal routine? It seems that the offset calculation takes the lowest value found in the noise and sets that to be the 0V, the result being that the trace sits "on top" of the center line. Unless i'm mistaken, i would expect the slightly noisy trace (when nothing is connected to the input) to be centered to the center line.

When manually selecting a smaller V/div setting it becomes more clear. While at the most sensitive setting(s) the noise goes well below the center line, it still is shifted upwards somewhat.

Greetings,

Chris

[pickle9000]

- I ran the cal routine after the update. I don't know if that's a recommended procedure but as a general rule I do after a firmware update. Make sure the scope is up to temp so the cal is correct.

Speaking of which... Is it just my scope, or do others see the same, uh, error in offset adjustment after a cal routine? It seems that the offset calculation takes the lowest value found in the noise and sets that to be the 0V, the result being that the trace sits "on top" of the center line. Unless i'm mistaken, i would expect the slightly noisy trace (when nothing is connected to the input) to be centered to the center line.

When manually selecting a smaller V/div setting it becomes more clear. While at the most sensitive setting(s) the noise goes well below the center line, it still is shifted upwards somewhat.

Greetings,

Chris

It looks to me like they are doing something to make the traces more visible when overlapped. If that's the case it would be nice to disable it. 

[mamalala]

It looks to me like they are doing something to make the traces more visible when overlapped. If that's the case it would be nice to disable it.

I don't mean the sometimes strange display if all channels are enabled and nothing is connected. Just the offset from a single channel relative to the 0V center line.

Attached are three (lousy, since i don't have it connected to the computer) images of what i mean. The amount of offset changes slightly depending on what V/div setting is used, but generally the offset is never so that the trace, when no input is applied, is centered around the 0V center line.

Am i wrong in thinking that it should be indeed centered? I'd say it should be centered, since i would expect the noise to be distributed equally above and below 0V.

Greetings,

Chris

[janoc]

I haven't noticed any boot delay. I'm getting 19 seconds.

I have just measured the boot time on mine from pushing the power button to trace on screen it takes 34 seconds here ...

The 19 seconds you have sounds more like what I had before. The scope seems to be functional otherwise, but the long startup time had me worried that the thing was hanging on boot!

[janoc]

As I wrote in another thread, I did the update on my 1074Z and it fixed the trigger jitter for me. However, the scope seems to be booting a lot slower now - is that a normal behavior or something fishy going on?

I (still) haven't received my 1054Z so I cannot say anything about the pre/post-update boot time but depending on the nature of Rigol's PLL fix, maybe the firmware does some form of clock quality analysis during boot and goes through PLL parameter ranges to find the best parameters for individual PLLs. If that's the case, they should be saving those settings as a starting point for the next boot so the POST/BIST/Cal will not need to spend as much time searching afterwards, much like how cable modems store their last known-good configuration channel to avoid the blind 54-1000MHz scan to find it on subsequent power-ups assuming it has not changed.

That sounds reasonable, but it is weird that they wouldn't store those values. For me it hangs a long time with the Rigol logo on the screen, then the LED next to the menu/intensity knob illuminates. Then it "thinks" for a while again and slowly the individual channel LEDs start to come on. Then I hear some relays clicking, the panel LEDs blink and I finally get a trace.

I guess I can live with that, but it is a weird issue.

[pickle9000]

I haven't noticed any boot delay. I'm getting 19 seconds.

I have just measured the boot time on mine from pushing the power button to trace on screen it takes 34 seconds here ...

The 19 seconds you have sounds more like what I had before. The scope seems to be functional otherwise, but the long startup time had me worried that the thing was hanging on boot!

Very different, is it constant? Was the firmware update time excessive? Mine firmware install was under 2 minutes.

[DanielS]

Am i wrong in thinking that it should be indeed centered? I'd say it should be centered, since i would expect the noise to be distributed equally above and below 0V.

I would definitely expect calibrated grounded or unconnected input to follow the channel's vertical position reference marker - centered on the noise's DC value, if any.

I would not consider it a deal-breaking issue since it is easily subtracted out but it would certainly nag me a little - like any known defect in any product.

[mamalala]

Am i wrong in thinking that it should be indeed centered? I'd say it should be centered, since i would expect the noise to be distributed equally above and below 0V.

I would definitely expect calibrated grounded or unconnected input to follow the channel's vertical position reference marker - centered on the noise's DC value, if any.

I would not consider it a deal-breaking issue since it is easily subtracted out but it would certainly nag me a little - like any known defect in any product.

Agreed, it's not a big issue and can be corrected manually quite easy, if needed. It's more of a "WTF were they thinking?" thing.

Greetings,

Chris

[janoc]

Very different, is it constant? Was the firmware update time excessive? Mine firmware install was under 2 minutes.

Yes, it is constant, same thing on every boot. The firmware update was fairly smooth and quick, no problems.

I am going to try to reset all the options and re-install them, perhaps the new firmware doesn't like something there.

EDIT: Even after resetting of the all options the boot time is the same - it takes about 19-20s just until the first LED comes on, sitting there with the RIGOL logo on the screen. Then it takes still some 14-15s until the trace comes up.

For the record, it is a board 0.1.1, DS1074Z, fw. 00.04.02 SP4 shown by the System Info.

[pickle9000]

It looks to me like they are doing something to make the traces more visible when overlapped. If that's the case it would be nice to disable it.

I don't mean the sometimes strange display if all channels are enabled and nothing is connected. Just the offset from a single channel relative to the 0V center line.

Attached are three (lousy, since i don't have it connected to the computer) images of what i mean. The amount of offset changes slightly depending on what V/div setting is used, but generally the offset is never so that the trace, when no input is applied, is centered around the 0V center line.

Am i wrong in thinking that it should be indeed centered? I'd say it should be centered, since i would expect the noise to be distributed equally above and below 0V.

Greetings,

Chris

On mine channels 1 and 4 are similar sitting slightly above center (but still on) the zero graticule. Channels 2 and 3 are the same but slightly below center. I've run the cal 3 times and each time it varies slightly but the pairings are the same. Coupling does not matter nor does a grounded bnc or probe.

I used the cursor to locate the zero graticule and just left it in place.

All I can say is that it varies after each cal.

You would expect it to hover around the zero graticule perfectly just after a cal. That's not to say that will stay that way for a significant time.

Even so, good to know.   

I did do one cal with some shielded bnc caps. Although you could probably argue a slightly (very slightly) better result visibly I wouldn't call it that way. 

[pickle9000]

Very different, is it constant? Was the firmware update time excessive? Mine firmware install was under 2 minutes.

Yes, it is constant, same thing on every boot. The firmware update was fairly smooth and quick, no problems.

I am going to try to reset all the options and re-install them, perhaps the new firmware doesn't like something there.

Did you use DSER?

[janoc]

Did you use DSER?

Yep, actually DSFR - including the buggy 500uV option, that's why I wanted to try to get rid of all the installed options and reset it back as it was. I didn't realize that I had that on originally.

But even after removing all the options using the :SYSTem:OPTion:UNINSTall command, rebooting, reflashing the firmware again the scope still boots in the same ~35 seconds, with just the default trial versions of the options.

As I said before, it is not a big deal, but it is certainly an unexpected thing to find after a firmware update!