Did anyone else notice after upgrading the DG,500uV,Power Ana and 100MHz show up as Official. they weren't listed at before.
The 1054Z does not have the 500uV front end hardware.
So no reports of the the fix NOT working so far?
Is it safe to say Rigol have fixed the issue yet?
"Fixed" is such a strong word.
I still want to do a little bit of temperature testing, but it appears Rigol has buried the 5us issue deep enough that no one is going to see it for routine use.Are you trying to NOT say it is fixed?
Is it safe to say Rigol have fixed the issue yet?
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.
Try this experiment:
- Start with an oscillator that you expect to be very clean, like an OCXO with sine wave output.
- Measure its spectrum on a spectrum analyzer you trust, using the same horizontal scale as the PLL output
- Then capture the oscillator output with the Rigol scope, and do an FFT on it
- Does the scope's FFT output show the same "shoulders" on the sides of the central spike as the PLL's spectrum?
- If so, you are seeing the unstable PLL affect the FFT output in a way that is indistinguishable from an unstable oscillator on the input
The shoulders are in the order of -70 dBc on a 100 MHz signal. The 12 Mpt FFT plot is in post #683. You'll not see them on the FFT the scope itself does. Certainly there was no way I could see them on the scope's FFT when I did those plots with Alessandro's program since the noise level on the scope's FFT was more like -40 dBc.
One thing that I'm pretty sure it worked before on the DS2000 series, was reinsertion of a memory stick.
Now I can insert it once but once you remove it it doesn't recognize re-insertions.
So, there ya go. PLL is still definitely not locked, but not wildly flapping either. I don't think we have any examples of it being completely unstable with the new firmware.
So as everyone is playing "What if?", let's try this one.
Hi Bud,
is your Scope (with the update) out of the Rigol product spec or not?
Are the 8 cylinders stated somewhere or just the 250 km/h top speed...
I do not have a 1054Z but made a mistake to buy a 2072A, which I have not opened because I consider getting rid of it. If I decide to open it will be another can of worms and another thread.
Often reading the datasheet does wonders. I will save you time and have attached a side by side picture of what MarkL measured, what I measured on a PLL I built, and what the Datasheet says. The screenshots are scale leveled to the same base line of -80dBc.
You can see my PLL (middle) follows the ADI picture (right) , and Rigol (left) is an utter garbage. I used the same ADF4360 chip with a proper loop filter. The PFD frequency was same as Rigols (2.5MHz)
The way how Rigol did it might be not the best and the PLL might create other issues, but right now you get what you've paid for.
And it's not proven that there are any other issues affecting the specified performance of the scope.
And it's not proven that there are any other issues affecting the specified performance of the scope.
Since the ADF4360-7 that the 1054Z uses is only rated for a maximum of 1.8GHz I would think they would need to use a different PLL chip for the 2072A.
The board photos that I've seen of the 2072A have the top of the PLL chip ground off so it is not clear exactly what IC they are using
So, there ya go. PLL is still definitely not locked, but not wildly flapping either. I don't think we have any examples of it being completely unstable with the new firmware.
MarkL, thank you for going into all these troubles to do this tests. If you still have access, can you try one thing for me: measure the SPI bus lines with no and with a 10K resistor connected between a line and ground. I'd like to see if in idle mode the logic High comes from the processor or from pullup resistors somewhere. If from the processor, the level would not drop much. If from pullup resistors, you should see a drop proportional to the resistor divider ratio. In case the processor SPI bus is in high impedance when idling, it should make it possible to highjack the bus with a external PIC and reprogram the PLL.
The SPI bus was probed. For comparison, here are the bytes from the beta for the AD4360-7 PLL registers:
You can see my PLL (middle) follows the ADI picture (right) , and Rigol (left) is an utter garbage. I used the same ADF4360 chip with a proper loop filter. The PFD frequency was same as Rigols (2.5MHz)
You can see my PLL (middle) follows the ADI picture (right) , and Rigol (left) is an utter garbage. I used the same ADF4360 chip with a proper loop filter. The PFD frequency was same as Rigols (2.5MHz)
Yeah but does it cause a problem with the scope sampling in any way?
The SPI bus was probed. For comparison, here are the bytes from the beta for the AD4360-7 PLL registers:THanks again, MarkL. Here is my analysis of it.
- no change in PFD frequency of 2.5MHz from Beta
- no change in lock detect setting of Digital Lock Detect (High), and as you said, the PLL is still not locked and as the result puts out garbage
- change in Band Select bits, now properly set. See my reply #575 earlier in this thread for details
- no change in Antiback slash pulse of 6nS from Beta, change from original firmware (3nS). Useless because only has effect when PLL is in locked state
-no change in charge pump current of 0.31mA. The part's specifications are based on 2.5mA current in the Datasheet, but Rigol did not read it anyway.
-change in Core Power Level from 20mA in Beta to 15mA back as it was in original firmware. Same as before, outside of the part manufacturer specification and could be the culprit of all this mess beside the invalid loop filter. See my reply #582 earlier in this thread for details. ADI treats this setting critical ("...In particular check the core power, it is critical that this be set to 5 mA") but that was of no meaning to Rigol.
Providing the Core Power Level was correctly set to 5mA, simulation shows that with the above settings and existing loop filter the phase margin value is 36 degrees which is a fair cry from recommended 45 degrees an most PLL book, the others recommend 50 degrees minimum. Therefore do not expect Rigol's PLL be stable to begin with. Cranking up the Core Power Level to 15mA makes all and any thing unpredictable, which is what we all are witnessing in this case.