EEVblog #683 - Rigol DS1000Z & DS2000 Oscilloscope Jitter Problems

[tautech]

The scope would not detect new FW on the USB stick at first. I formatted the stick and put only the FW file on it, then it picked it up. Perhaps it had an issue with a file present on the USB stick?

Thats pretty normal behaviour for firmware upgrades.
You should only use a empty, correctly formatted USB stick and then copy the unzipped firmware to the root of the stick.
Some equipment will let you select the firmware file from amongst others, many don't.

Did it not come with install instructions?
Or did you not RTFM?

[Teneyes]

I have started a new thread just for the DS2000 FW 00.03.03.01.00 Bugs and Comments Here

[sawmilkd]

Still doesn't fully lock at 140mV on chan 1 it locks at 160mV, not sure what it was before the upgrade since I never did an exhaustive check.

But that's only on rising edge, on falling edge it triggers fine.

On chan 2 it locks at 200mV on rising edge, works fine on falling edge as well.

Will do a Storage Default and self cal again after warming up a bit.

Edit: Reinsertion problem of USB thumb drive (not detecting it a 2nd time) persists still.

I am seeing similar odd behavior with both the rising and falling edge trigger threshold w/ the new firmware on my DS1054Z. This is DC triggering on CH1 using a 1X probe on the 1KHz calibration signal. I've just made some quick notes on where the trigger threshold must be to trigger on the waveform. It appears to be a function of the vertical scale as well.

The test waveform is 0V to 3V square wave @ 1KHz.

Rising edge trigger
200mV/div: 176mV
500mV/div: 100mV
1.0V/div: 240mV
2.0V/div: 480mV

Falling edge trigger
200mV/div: 2.6V   (-400mV)
500mV/div: 2.87V (-130mV)
1.0V/div: 2.82V (-180mV)
2.0V/div: 2.56V (-440mV)

Dependence on vertical scale makes sense given the A/D converter volts/bit can change, but this is undesirable behavior. I certainly don't remember observing this pre-patch and I think I would have noticed.

[pa3bca]

I am seeing similar odd behavior with both the rising and falling edge trigger threshold w/ the new firmware on my DS1054Z. This is DC triggering on CH1 using a 1X probe on the 1KHz calibration signal. I've just made some quick notes on where the trigger threshold must be to trigger on the waveform. It appears to be a function of the vertical scale as well.

The test waveform is 0V to 3V square wave @ 1KHz.

Rising edge trigger
200mV/div: 176mV
500mV/div: 100mV
1.0V/div: 240mV
2.0V/div: 480mV

Falling edge trigger
200mV/div: 2.6V   (-400mV)
500mV/div: 2.87V (-130mV)
1.0V/div: 2.82V (-180mV)
2.0V/div: 2.56V (-440mV)

Dependence on vertical scale makes sense given the A/D converter volts/bit can change, but this is undesirable behavior. I certainly don't remember observing this pre-patch and I think I would have noticed.

I just tested it on my 1074Z (spring 2014 version), old 00.02.03.SP5 firmware, no 5us trigger issue with this scope .
It shows the same/comparable trigger thresholds as you recorded above. So it looks like it is not a result of the new firmware.

[jkrichards]

The new DS1000Z FW fixes my extreme jitter issues too 

Update:

The scope would not detect new FW on the USB stick at first. I formatted the stick and put only the FW file on it, then it picked it up. Perhaps it had an issue with a file present on the USB stick?

Did the new firmware lock out the options and 100mhz bandwidth?

[sawmilkd]

The new firmware left all installed options untouched on my DS1054Z.

[Orange]

My DS1054Z had the 5uS jitter issue, the new firmware fixed the issue. AC trigger jitter issue is also fixed....
No keyboard lock-up or any other strange things..

  RIGOL 

[rf-loop]

My DS1074Z did not have "5us" jitter issue.

New firmware:  Time jitter & horizontal position issue when Triger AC coupling is selected.  = Fixed!

Add: After careful test for avoid any mistakes. Now I can see that least in my individual unit also long delay time jitter is fixed.
 (Tested with HP8644B what have very high stability owen as reference).

[Bud]

If MarkL is still here and still can do it, I would wait for him to look at the ADC clock spectrum and get the PLL programming values from this firmware revision, when he has time.

[pickle9000]

So I just popped in the update and it did fix the issue for me. The update took about 90 seconds on my machine, and of course you have to do a cal afterwards. All options intact.

@Dave ... I was thinking Dave should do a "quick" before, how to update, cal and test afterwards. Possibly show the panel as you hit the buttons for people new to scopes. I know you don't normally do step by step but it could bring people to the forum.

[MarkL]

If MarkL is still here and still can do it, I would wait for him to look at the ADC clock spectrum and get the PLL programming values from this firmware revision, when he has time.

I'm still here, but I sent my unit back because the 30-day eval period ran out before any solution appeared from Rigol.  In general, I don't make purchases based on bug fix promises or feature expectations, no matter how sincere.  Been there, lesson learned.

I will, however, have an opportunity to do some indirect testing on someone else's DS1054Z in a couple of days before and after new firmware.  But since it's not mine, I'm not in a position to open it to do a direct measurement on the ADC clock.  I will ask the owner, but I think I already know the answer.

[MarkL]

Thanks again to all the engineers, beta testers, customers, community members, and worldwide Rigol team members who have contributed to the discussion, validation, and solutions over the last month for the MSO/DS1000Z and MSO/DS2000A FW updates that we are now ready to release. It has been a great example of working together to make instruments even better. Thanks also for your patience as we worked through the proper process for evaluating, updating, and testing solutions that work for all of our customers. You can now find the firmware updates here:

MSO/DS1000Z Firmware

 MSO/DS2000A Firmware

Feel free to update at your convenience and let your local Rigol office know if you have any questions, issues, or problems. Happy New Year!

Chris, thank you for the firmware upgrade.  I will re-ask my question:

Has it been verified that the ADF4360-7 PLL is now locked on the DS1Z?  (I.e., the LOCK status bit is now set?)

[EEVblog]

I'm trying to run AlessandroAU's software (want to do a video on it), but it does not detect either the 32bit or 64 labview Runtime driver.
What am I doing wrong?

[MarkL]

If MarkL is still here and still can do it, I would wait for him to look at the ADC clock spectrum and get the PLL programming values from this firmware revision, when he has time.

Another thought...

I think there's not a large intersection between people buying the DS1054Z and people who have the equipment to do the measurement.

Dave: Perhaps you'd be interested in doing this measurement?  You've already taken apart your DS1054Z and you could use that nice mailbag E-field probe to look at the spectrum of the PLL clock output.  You're going to upgrade the firmware anyway, so why not make it a little more interesting.

And digging out the PLL programming values with a logic analyzer (or MSO) might make for a follow-on reverse engineering video.

(I need to leave the SW question to AlessandroAU.  I don't know.)

[leppie]

I'm trying to run AlessandroAU's software (want to do a video on it), but it does not detect either the 32bit or 64 labview Runtime driver.
What am I doing wrong?

Same happened to me after trying 64-bit driver.

Solution was to uninstall everything. Install UltraSigma again, make sure it is working, then only install the 32-bit runtime.

[Bud]

Installing Labview runtime killed LAN capability on my UltraSigma and RUU. USB still works.

[Bud]

I support MarkL's idea, that would give the problem more exposure so it will be more difficult for Rigol to get away with a half-baked fix.

[poida_pie]

If MarkL is still here and still can do it, I would wait for him to look at the ADC clock spectrum and get the PLL programming values from this firmware revision, when he has time.

Another thought...

I think there's not a large intersection between people buying the DS1054Z and people who have the equipment to do the measurement.

Dave: Perhaps you'd be interested in doing this measurement?  You've already taken apart your DS1054Z and you could use that nice mailbag E-field probe to look at the spectrum of the PLL clock output.  You're going to upgrade the firmware anyway, so why not make it a little more interesting.

And digging out the PLL programming values with a logic analyzer (or MSO) might make for a follow-on reverse engineering video.

(I need to leave the SW question to AlessandroAU.  I don't know.)

Yes, that would be a good use of the SA you have in the TEK MDO scope. Easy peasy.
Plenty of scope (urg..) for new videos. So what you reckon?

[orin]

Installing Labview runtime killed LAN capability on my UltraSigma and RUU. USB still works.

I lost LAN capability too, but I thought it was due to having Agilent's VISA installed when I installed the NI runtime.

I ended up installing the NI 32 bit runtime, then UltraSigma, then whatever it wanted to update.  USB is working.  I've not tried LAN since.

All the screenshots I've posted have been taken by Alessadro's program - it's working for me over USB.

However: Alessandro, I use a relatively low resolution laptop for instrument control and the FFT is mostly offscreen at the bottom.  I'd like scrollbars or the FFT in a separate tab.

Edit: fixed typo

[Bud]

Indeed, even on my 1680x1050 screen the program takes all space. The last version even starts on my second screen - not sure Alessandro if you are using a huge monitor or two of them.
 
Would be good to have resize ability if possible.

[orin]

If MarkL is still here and still can do it, I would wait for him to look at the ADC clock spectrum and get the PLL programming values from this firmware revision, when he has time.

Another thought...

I think there's not a large intersection between people buying the DS1054Z and people who have the equipment to do the measurement.

Well I can - if I'm given the go-ahead to open up my unit.  I have an 8568A* spectrum analyzer and RF probe.

I did put the final release version of the new firmware on my scope and I've not seen the 5us jitter since.  I'll let it cool down overnight and test again in the morning.

Orin.

*I have access to an 8658B RF unit too, but I like the 8568A better.

[EEVblog]

Confirmed fixed 5us and AC coupling jitter on my unit.
Here are before and after PLL output shots.
Have done a video on it.

[Bud]

Sorry to tell you Dave, the clock is still junk. The 68.3kHz spurs just at 35dBc is a garbage PLL. 
That is assuming your spectrum analyzer which is also happened to be of Rigol brand, is a trusted one.

I have attached the reference shots done using my 4360-7 PLL at 1GHz with a proper loop filter. Note my RBW was wider than your 300Hz, and still my screenshots are much better. In the 1MHz span shot: the pedestal is at 60dBc. The 10MHz span shot: PFD spurs +/-2.5MHz from the carrier are at 75dBc.

Sadly, does not seem Rigol is ever going to get it right. They should hire a year 1 electronics college  student to redesign the PLL for them.

I hope in your video you did not say the problem is now fixed. Please feel free to use the attached pics in the next revision of your video to inform people what a good PLL spectrum should look like. Side by side with Rigol's they could help deliver a message to Rigol in visual if they have difficulties reading.


EDIT: I took a liberty to make and added a side-by-side picture of Dave's and my PLL screenshots, scaled to the same 10dB/ vertical scale.

[EEVblog]

Sorry to tell you Dave, the clock is still junk. The 68.3kHz spurs just at 35dBc is a garbage PLL. 

Yes, but is it adequate for the task in a $399 scope?
The jitter is gone on first inspection, and unless other people can find issues with their scopes (there could still be hardware tolerance issues), I think anyone would have a real hard time arguing that it's a real practical problem.
Perhaps this is the best compromise Rigol could up with for the fix barring a total recall of all scopes?
I suspect Rigol might do a hardware fix on future scopes without telling anyone. Their problem at present is the scopes already out there and having a fix available for it.

[tggzzz]

Yes, but is it adequate for the task in a $399 scope?

I suspect Rigol might do a hardware fix on future scopes without telling anyone. Their problem at present is the scopes already out there and having a fix available for it.

By definition, a "bad" scope is one that does something unexpected, so that you lose faith in it. The price is irrelevant.

(Old HP-Way story from the 70s. HP shipped a minicomputer and some customers justifyably complained. The project manager got a memo from Bill/Dave "Please do not ship a product before it meets its specification". The project manager blushed and said "ouch" - and then framed the memo and put it on his wall).

If they fix future scopes without changing the number, then if you order a scope it will be pot luck as to whether you get a "good" or a "bad" scope.

Their problem in the future will be their reputation.