The examples that demonstrate generating a clock at 16Mhz (and 8Mhz) seem to work OK. However generating output on other frequencies seem problematic. If you take example 1 and try to generate a clock at 17MHz clock, the output frequency is nowhere close. I am using CMOS output mode and a good freq counter to check output. Have also double checked with a general coverage radio receiver. Have used a SF Blackboard (QWIIC) and and a metro mini (3.3v), hardwired, to control the clockgen board with identical results. I’ve tried using the library routines to set Vco freq and clock freq and the lower level routines that set the integer and fractional dividers manually. Neither way produces clock frequencies that make sense. Please verify that this library works correctly for frequencies other than multiples of the 16MHz clock freq. Has anyone else run into this issue? If not, perhaps I have a flaky clockgen board.
Hello,
That is an odd behavior. Can you share any images of the frequencies that are not behaving?
In the meantime, you can also file an GitHub issue if you have detailed accounts of the behavior so our engineers could exam the issue in more detail. Issue Template: https://github.com/sparkfun/SparkFun_Cl … EMPLATE.md
Hello david.allen.metzler. That is strange behavior indeed, I wrote the library and made sure to test a range of frequencies but unfortunately I don’t have a Clock Generator here at home to test (shelter in place policy for our area). None the less I should be able to acquire a Clock Generator soon (next few days) to try to reproduce the behavior. I filed an issue on Github to make sure that I don’t forget.
When I run example 3 from the library, I get an output frequency or 22.9638 MHz instead of 22.00 MHz. Also, the calculated fractional divisor is 6039797 and that value is set in the example. It reads back 6039757. There seems to be some issue setting fractional divisors properly. There seems to be a problem setting a fractional divisor for the PLL as well. Maybe if I were a c/c++ programmer I could figure it out.
There’s always the possibility of a bad clockgen board, but it doesn’t seem so. Example 1 works fine and generates 16.00 MHz accurately. If both the PLL and FOD dividers use only integer dividers, things seem to work (frequencies generated accurately).
Thanks very much for looking into this.
We are on lockdown also. This is my sanity project.
There is some inherent rounding errors due to fractional → integer conversions, but that seems a bit off. I’ll double double check that the library is working as intended.
OK - many thanks!
Did some further investigation with a spectrum analyzer. Some of the “off” frequencies were not really there & some were there, but very unstable. Vco/PLL does not seem to be working on my board. Explains why I can only get a lock at 16MHz - the crystal freq (probably bleed thru). At this point, don’t if it’s a hardware issue or improper PLL setup in software. I did some library troubleshooting. I can write & read back the various 5P49V60 registers using the library routines. Just can’t get a stable PLL output no matter what. I’ll wait & see if wonder_boom can replicate this bad behavior before I order a replacement board.
Some more Vco (PLL) research. First - fractional divider is not getting written at all. Always reads back 0 and changing it does not change the output freq. Integer divider behaves weirdly: If I set it to be 102 for example, the output freq is what you would get for 101 as the divider. For the following examples, Fod One was set at 50/0 & left alone
Example1:
Set PLL Int divider to 100 - calc PLL freq = 16*100 = 1600 MHz
Calc Out freq = 1600/2/50 = 16 MHz
This works - we actually get 16.0 MHz stable ouput.
Example2:
Set PLL Int divider to 102 - calc PLL freq = 16*102 = 1632 MHz
Calc Out freq = 1632/2/50 = 16.32 MHz
We actually get 16.16 MHz (stable), which is what you would get for a PLL freq = 1616MHz = (16*101)!
This behavior is repeatable. Have not found the source of this behavior & its getting late.
All in good fun & keeps me busy.
Nice, thanks for digging in @david.allen.metzler and coming back with your findings. I found the bug for the fractional divider and have tested to make sure its’ consistently being applied now. So the registers are being set correctly with this fix. I’ll push to the Github repo today or tomorrow and link the fix here. I’m next digging into the hardware to confirm that it’s working correctly now that the software is working. Again, I truly appreciate the post - expect to hear back from me soon.
Ok so the fix has been pushed in release v1.01 - so you’ll see it in the Arduino IDE library manager a few minutes after my post. I posted an image of the behavior post fix here:
https://github.com/sparkfun/SparkFun_Cl … y/issues/3
Next, I’ll take a look at the hardware end of things to make sure things are acting as intended.
I forgot to mention it also fixes the PLL fractional division issue as well. I was dividing integer types and not getting a float type - go figure. =P As to the other fractional issue, I was dividing two number when I clearly should have been multiplying them.
Thank you! I’ll have a look & see how it works.
You have, indeed, killed the fractional divider bug! Many thanks. There is still an issue setting arbitrary frequencies, i.e. Example 3 still doesn’t work. There is strange granularity in setting the dividers. Refer to example 1:
Set the Vco to 1600 MHz and Clock 1 to 16.00 MHz - you actually get 16.00 MHZ out.
Set the Vco to 1600 MHz and Clock 1 to 16.10 MHz - you actually get 16.05 MHZ out.
Set the Vco to 1600 MHz and Clock 1 to 16.20 MHz - you actually get 16.10 MHZ out.
.
.
.
Set the Vco to 1600 MHz and Clock 1 to 16.60 MHz - you actually get 16.30 MHZ out.
Set the Vco to 1600 MHz and Clock 1 to 16.70 MHz - PLL seems to lose lock (counter reads 19.62, but that might not be real).
You get the same off by one-half behavior if you try tweaking the Vco freq. (See my previous post.) I used IDT’s Timing Commander software to generate the Vco (integer) divider registers and sent them to the chip directly with the _writeRegister function , but had to shift the MSB (0x17) one place to the left to get it to work (get close to the intended freq). You get exactly half the expected freq change. At this point, I’m becoming more convinced that this is a hardware issue. The library seems to be doing exactly what its supposed to. The IDT (Renesas) documentation doesn’t help much.
Arrgh - this beast is much more frustrating than a Si5351 or ADF4351.
Has anyone out there got this working for frequencies other than 16/8 MHz?
Have you (Sparkfun engineers) verified that the hardware works as intended? I’m trying to determine if I need to replace my board or not.