-
-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pll not recalculated ( 150 MHz boundary ?? ) #65
Comments
What verson of the library? I'm not able to reproduce.
AVR or ARM? there may be a compiler issue here. I have only tried on ARM.
FWIW, I have not had any issues with signals above 150MHz, the chip works
quite ok to 225MHz, where a internal register overflows.
Jason is away for a week or so, he will probably reply when back.
Thomas.
Den ons. 11. jul. 2018 kl. 11:47 skrev gartnl <[email protected]>:
… Right after initializing ( so with default values for pll-source, plla )
Consider:
si5351.set_freq(8000000000ULL, SI5351_CLK0);
si5351.set_freq(15600000000ULL, SI5351_CLK0);
si5351.set_freq(8000000000ULL, SI5351_CLK0);
The second 80 MHz is not put out. Some debugging ( looking at the pll
value ) showed that the pll is not recalculated.
Now this:
si5351.set_freq(8000000000ULL, SI5351_CLK0);
si5351.set_freq(15600000000ULL, SI5351_CLK0);
si5351.set_freq(14300000000ULL, SI5351_CLK0);
si5351.set_freq(8000000000ULL, SI5351_CLK0);
This works. The 143 MHz triggers recalculating the pll.
Workaround:
si5351.set_freq(8000000000ULL, SI5351_CLK0);
si5351.set_freq(15600000000ULL, SI5351_CLK0);
si5351.set_freq(8000000000ULL, SI5351_CLK0);
si5351.pll_reset(SI5351_PLLA);
Pll is recalculated and the 80 MHz is put out.
I can live with it, but took me some time to figure out.
Is this the si5351 or a glitch in the pll calcualtion?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#65>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEOGvIRrkI-9HqpKldmfQ1y-d-T81PL8ks5uFcnGgaJpZM4VK00r>
.
--
With Best regards, Thomas S. Knutsen.
Please avoid sending me Word or PowerPoint attachments.
|
2.1.2 , so the latest. But other versions before that had the same problem. Looking at set_freq where the function checks if F > 100:
So if F >100 new pll-values are calculated , the 150 MHz boundary is checked and the pll is reset. IMO what happens is: as I set F > 150 the pll/multisynth are recalculated using div_by_4, and the PLL is reset. When I switch back to a freq below 100 div_by_4 is 0 by default and the multisynth set accordingly. But the pll_reset is commented out. The si53515 cannot put out this freq now . I removed the comment before reset_pll and indeed it works as expected. update: not quite that simple, I found there are other settings that do require a pll recalc, all
would require recalcullation of PLL for instance. I'll wait for Jason's response and in the mean time read up on the documentation. And still consider the fact that my si5351 might be of the Chinese variant ;-) |
@ Jason The first part about needing a pll-reset when doing a switch from F>150 to F<100 stands. The second part is rather strange, and seems not to involve the library, so you can forget about it. Just FYI:
does not work for CLK2, but
is just fine. Turns out that whenever the multisynth divider is between 6 and 6.8 my si5351 does not output a signal, or a strangely mutilated signal. An integer value of 6 is ok however. eg If I set a pll of 600 , 100 MHz is ok, but 98 is not ? Even when according to AN619 any divider between 6 and 1800 should be ok. |
Right after initializing ( so with default values for pll-source, plla )
Consider:
The second 80 MHz is not put out. Some debugging ( looking at the pll value ) showed that the pll is not recalculated.
Now this:
This works. The 143 MHz triggers recalculating the pll.
Workaround:
Pll is recalculated and the 80 MHz is put out.
I can live with it, but took me some time to figure out.
Is this the si5351 or a glitch in the pll calcualtion?
The text was updated successfully, but these errors were encountered: