The Work continues.
Last Weekend I did some soldering during my livestream, where I tried to figure out why the amplifier for the reference Input didn't work until I realized that I had put a 50 Ohm Terminator next to the PLL-Chip.
Obviously, this screwed up the current flow that was going through the resistor rather than the BFR93 transistor, screwing up the bias-point and everything else.
I ended up just removing the terminator since the signal looked clean enough.
I will have to address the PLL at some time in the future, but since it was pointed out that the master clock could have been implemented better, I've put optimizing this particular PLL on the waitlist for now.
Next I checked the clock-signals to the Chips again to make sure I didn't screw up anything there and found a few things:
- ADF4355 Clock had no DC Return-Path from the PL133 and through the BALUN, so I had to solder a 100 Ohm resistor across the two DC Block-Capacitors that isolate the local termination from the BALUN to make the signal look a lot better. Also the 3.3V Termination isn't really necessary at the 20 MHz I'm feeding into the chip. It would have probably been enough to just use the 50 Ohm resistors to ground to attenuate the signal enough to make it fall in the specified area of the ADF4356 Datasheet.
- AD9957 Clock-Input needs DC Block Capacitors (Oops) - Had to cut the clock-traces and solder in the caps. Not the clock-signal looks good. Also needed 1k Ohm additional series resistance to be within spec (2000mVpp)
After that, I turned my attention to the ADF4356 to get it running. For that I took an example for the ADF5355 and adapted it to the ADF4356 today. The library holds a mirror of the ADFs registers, which allows for easier debugging and all the values in the registers are easy to read and understand the way I organized them. Not very memory-efficient, but for debugging purposes it does the job very well.
Which brings me to the next topic: Debugging this bitch.
First of all: Communication is working! I verified that I can change configuration-values in different registers and the signal arriving at the chip looks really good on the scope. I also had no lockups of the chip that required a complete reset due to spikes on the data-lines like the old system.
BUT: The chip isn't working correctly! I did manage to get one or two frequencies to be more or less what I told the chip I wanted them to be, but most of the time the output is something entirely different from what I told the chip. When I look at the N-Counter output of the chip, which should match the R Counter-Output to be locked to the reference, the signal is also all over the place. Frequency is usually quite a bit lower than the PFD-Frequency and sometimes, at higher frequencies, the pulses even appear irregularly.
From my experiments over the last few hours, the most likely culprit is the automatic VCO Band-Selection and autocalibration inside the chip. I also found several Community-Posts over at Analog Devices, but all the threads were either abandoned, or ended in "I'll tell you how to fix via Email".
So far I have played around with basically all the settings but haven't managed to figure out how to get it to work. Changing the charge pump current changed behavior a bit, but didn't cause the chip to lock. Bleed current didn't do much either. Changing the Polarity of the Phase Frequency Detector only made things worse and enabling or disabling the Doubler or Divider of the Reference-Input didn't do jack either.
Anyone got any idea what's wrong or has some experience with this chip?
Btw. the values for the loop filter I have gotten from the ADIPLLSIM-Software are (rounded up to what I have in my parts bin):
C1: 47pF / R1: 4.7kOhm, C2: 440pF / R2: 12.1kOhm / C3: 6.5pF
According to the Software this gives a Loop Bandwidth between 42.5kHz (Phase Margin 9.25degrees) at 300uA Charge Pump-Current and 200kHz (Phase Margin 38.6 degrees) at 4.8mA Charge Pump-Current. Which, according to the software, should result in a lock-time of 2.92ms.
As far as I have checked my code, the values for the PLL Registers should be correct (Integer, Frac1, Frac2 match the values my pocket calculator gives me) and are being transmitted in the right order and as I said the chip is reacting correctly to setting bits like the configuration-bits for the MUXOUT.
In case you want to look at the code, I have updated the Github a few minutes ago.
Btw. I originally developed the driver for the ADF4355 and only realized later, during the debugging, that I have a ADF4356 on my board. Changing the Software (I don't use Register 13 right now, which the datasheet says you can do) didn't really change things however.