Re: Si5351 Programming Flowchart


there is a windows program on the adafruit website that will give you the parameters after you enter the frequency..I am using a nano($3) and one of the adafruit si5351break out boards($8) with a low pass filter9$5) for a QRSS 20mW xmtr I plan to release with a cost under $20
Brian K9WIS

---- Pavel Milanes Costa <> wrote:

Hi to all.

The flowchat is a instructive guide for the curious of how to doit
without float point math and an expression of the KISS principle.

It's just a cheat sheet to learn from.

The trick is to understand the way he (like Gerry) find a, b and c not
needing floating point math. (for the PLL/VCO Msynths case is)

a = int(Fvco/xtal)

b = Fvco % xtal (module, aka: rest of the division)

c = xtal

For example Gerry do a do..while to find a value of b/c that match the
allowed size of c, he need it because he is working with the output
Msynth dividers not the PLL/VCO Msynth, in his case c = fout and is

In the later case (moving the PLL/VCO Msynth, output Msynth dividers are
fixed) c is fixed and equal to the Xtal and we know it already then we
can do a simple x >> 5 to both b/c to retain maximum accuracy and make
it fit on the register. If we do that just set the output Msynth divider
to a integer & even value to minimize jitter or phase noise.

In Gerry routines he fixes the VCO and moves the output divider Msynth
and that make some jitter or phase noise (almost negligible in real
applications, I know) and makes 3 outs from just one fixed VCO and does
not handles the R values or the DIV_BY4 feature limiting the full range
of output frequencies (not needed on his target application, I know).

This is just another way of doing things, a way that can be better
understood because it uses a simple and elegant image (flowchart), to
make life (& code) easier (& smaller)...

BTW I found a possible bug that can haunt more than one in the routines
of computing MSx_P2. A tip for the "math" experts... and a common fault.

As per the data:

MSx_P2 = 128 * b - c * floor (128 * b / c)


It's very tempting to reduce it but the floor functions is in there...
let see... floor is the lower integer for that float number, hum...

Floor is on the C of Gcc the compiler used by the arduino project but it
implies the use of floating point math hence bigger code, just eliminate
it and do the math, let try to reduce it...

MSx_P2 = (128 * b) - (c * 128 * b / c)
MSx_P2 = (128 * b) - (128 * b) ---> (c is eliminated as it's * and /  in
the expression)
MSx_P2 = 128 * (b - b) ---> ( hum....)
MSx_P2 = 128 * 0 ---> (HUMMMM!!!)
MSx_P2 = 0 ---> (WTF !!!!)

Doing some math and wall head-hiting you can conclude that the floor
function is instructing you to IGNORE the use of fractions and then you
get a value in MSx_P2 that it related to the amount of error or rest of
division of doing things (math) with integers... hence the floor
function... forcing you to use just integers... nice.

For example Gerry users in his code this:

msxp2 = 128 * msb - 128 * msb / msc * msc;

If you play that same function with human and integer rules it play well
and result is different from zero, but if you use floating point math it
always equals to ZERO!

Let's play it with me in full integer math

let's say msb = 900 and msc = 1000

msxp2 = 128 * 900 - 128 * 900 / 1000 * 1000;
msxp2 = 115200 - 115200 / 1000 * 1000;
msxp2 = 115200 - 115 * 1000;   // <<<<=== here is the floor in action
(result in float is 115.200 we get it down to 115, all with the magic of
integer math)
msxp2 = 115200 - 115000;
msxp2 = 200;

In this case 200 is a relation of the error of using integer math...
interesting, mind you how the chip use it internally

For correctness and just to be sure to maintain the best accuracy you
must get sure the compiler do the 128*b/c * c in the correct order, that
is as per Gerry code fragment:

msxp2 = 128 * msb - 128 * msb / msc * msc;

Must be forced to execute in the correct order by placing some
parenthesis to maintain more accuracy.

msxp2 = 128 * msb - ((128 * msb) / msc) * msc;

Firmware size impact is unchanged, compiled code is the same (sha256sum)
with and without the parenthesis so GCC compiler is doing he job right,
beware of others...

I mentioned this because I have a ham fellow in university (freshman)
that hit his head against this wall a few times, "that's impossible,
that has no sense.... MSx_P2 is always zero..." he said...

Just my two cents for other that may be in troubles like this
understanding the chip.

Cheers, Pavel.

El 12/02/18 a las 12:07, JuanCarlos Berberena Gonzalez escribió:
Hi Guys
A weeks ago Josué Marin-CO7RR- sent me this information to share with
my group.
I am only try to be a good 'USER" testing some interesting project I
can get on the web and afterward share it with my group.
Now Pavel-CO7WT- sent me this link and I think is a good idea to share
with all of you.

It is a Josué Marin email address
73's Jc

Join to automatically receive all group messages.