Re: SI5351 quadrature VFO

Hans Summers
 




Hi Jerry 

> I'm curious, have you measured the increase in jitter when going to a 
> fractional output msynth on the si5351?
> Not clear to me whether or not this is a significant consideration for the uBitx.

No, I have not measured it. In my opinion it is not likely to be a problem. As you mention, SiLabs do various tricks in the silicon that reduce jitter. I agree that the difference between the two modes may be a factor of 2 or less. Both of them are surely fine and better than the LC VFOs everyone was happy with for a century. Elecraft use the Si5351A as the VFO in the KX2, I'd like to hope that also confirms it can't be bad :-)

But still I prefer the use of the even integer divisor, and I have always used it this way. And it allows the quadrature mode if that is desired. 

> Another issue, the uBitx uses all three clocks out of the si5351, and with only 
> two PLL's available in the si5351 it's at least bothersome if not impractical to keep all three 
> output msynth's in integer mode. I agree that you must be in integer mode to use the phase 
> shift feature to get quadrature clocks, but that is not a requirement on the uBitx. 

Yes that's a very good point that I had forgotten. Not just bothersome or impractical; but in the general case impossible... there are three outputs (with three MultiSynth dividers) but only two PLLs. So if you want to use three outputs all on different frequencies, then the third MUST use fractional MultiSynth division. Unless you are lucky enough that your third frequency is somehow related to one of the others, such that it can use an integer division too. 

I do use the fractional division mode in my ProgRock kit http://qrp-labs.com/progrock which supports three independent frequency outputs. So I use even integer on two outputs and MultiSynth fractional division on the third. 

One other comment... 

Use of floating point arithmetic greatly increases the code size. And execution time - but generally I have found the execution time is not usually a constraint, neither is RAM or EEPROM... the biggest constraint I run into is the Flash program memory size. 64-bit arithmetic increases the code size even worse than floating point. Accordingly I use only 32-bit unsigned integer arithmetic in my Si5351A configuration routines in my firmware. It is possible to do all the calculations in 32-bit arithmetic without losing any precision (Floating point loses precision, 64-bit increases the code size too much). The result is compact code and accurate. 

73 Hans G0UPL

Join BITX20@groups.io to automatically receive all group messages.