Re: Is there any chance of a GPS locked "Si5351A Synthesizer"

Graham, VE3GTC


Agreed on all points.

I did figure out what was causing that periodicity in the frequency - there was a dehumidifier which was turning on and off causing minor changes in air flow and temperature. I thought it was of but I was mistaken.

I still don't understand why all the bumps and squiggles. So, I took a step backwards and started to work forward and be more careful in my tests.

I am using a Vectron 7mm x 5mm oscillator (not TCXO) CDTGCP-27MHz 3.3v 50ppm in lieu of the crystal on the si5351a synthesizer board. 50ppm is a pretty common stability value for these devices. There are 25 and 30 ppm parts available and also quite common and inexpensive, these just happened to be what was easily available at the time. Inexpensive TCXO's are pretty common and typically spec 2.5ppm (a 20x improvement over 50ppm)

First test was to do a reset of the Progrock to return it to a known state and then just applying power and monitor the 27MHz of the oscillator in order to better understand what it is doing (see attached). Started about 30Hz high which quickly decreased as the device (progrock, synthesizer, oscillator) warmed up until stabilizing about 55Hz low. It took about 45 minutes to reach that point and another 25 minutes or so to stabilize even further. After that the frequency remained stable to about +/- 1.5 Hz, remember, this is just the oscillator and is not the programmed output frequency.

This was encouraging so I continued on to step two.

I wanted the synthesizer board to use a 5v supply. A LP2950-3.3v regulator was used in place of the lm317 and supplied with 5v. Pin 18 of the synthesizer was removed to isolate the 3.5V from the progrock board, and the lm317 on the progrock was replaced with a 78l05.

Also, I repogrammed the attiny84 with the latest firmware 1.01a so that I would have the benefit of any improvements in the latest firmware and also on start up would be in a known default condition.

New firmware, regulator mods and all set to go. Programmed to 7400000Hz (a local quite frequency) and using GPS disciplining, monitoring on my GPSDO disciplined Icom R75 receiver and using Spectrum lab to measure and record, the test began.

Start up and skewing to frequency was pretty quick. About 40 minutes after startup, the progrock is seen to make and adjustment, and from then on frequency has slowing increased for a total of about 1.1Hz over 3 hours. 5 hours after startup the frequency is within about 0.2Hz (low) of the target frequency.

Quite impressive actually (well done Hans). Not GPSDO reference frequency stable but very good non the less. And this for a Progrock sitting on my workbench in the basement with a half inch or so of fiberglass insulation over top of the device (dehumidifier has been turned off!).

Test will continue overnight and probably for a couple of days.

You can see the spectrum lab screen grabs here:

there is also a text file with frequency measurements with more detail that the images.

My need for a LO to monitor CHU or WWV carrier doppler requires stability over accuracy. Typically my receiver is offset 1kHz but even that is not critical.

More tests to come. I am going to get some 25 and 27 MHz TCXO's (inexpensive types of about 2.5ppm) and give those a try.  I did find on that was 1 ppb (billion) but those small tiny devices are $100+ each.

cheers, Graham ve3gtc

On 2018-10-05 05:11, Hans Summers wrote:
Hi Graham

Several factors I think are at play. So I have several comments.

1) I have always said the expected accuracy of a GPS-disciplined ProgRock is better then 0.1ppm. That means 1Hz at 10MHz. So your +/-0.2Hz is well within specification.

2) ProgRock implements an adaptive correction mechanism, starting with large correction steps then fine-tuning it as it gets on frequency, until the steps are very tiny. If there is a sudden drift, ProgRock will increase the correction step size again in order to fix it quickly. For optimum results I think putting a small heatsink (e.g a nut) on the crystal, some thermal insulation around, and closing it to air currents.. these things help avoid sudden small drift. Essentially ProgRock is a control loop and the optimum loop characteristics will always be different in every case, and the systems adaptive correction is an approximation; so it is best to make its job as easy as possible by minimizing drift to start with.

3) The threshold register is important because it controls when corrections are made. For example if set to 5Hz, the firmware will internally perform the drift correction but NOT apply it to the actual output frequency, until the change in 27MHz reference since the last output frequency update, exceeds 5Hz. If you set it to 0, then there will be 1 micro-update per second, every second. This register lets you tailor the characteristics for particular applications. You exchange large infrequent jumps on the one hand, for tiny continuous ones.

4) In the end... the Si5351A register configuration in ProgRock uses the even integer MultiSynth divider principle, making all adjustments via the PLL feedback divider. It has fractional numerator and denominator resolution of 20 bits. This alone limits the accuracy of the output frequency to something like 0.3Hz. It would be possible to make ProgRock more precise, by
a) abandoning the even integer MultiSynth divider OR
b) a more advanced algorithm for register configuration optimization
Needless to say... trying one or both of these is on my list. But my list isn't short...

In conclusion as it stands, your ProgRock is performing to specification, the results are as expected; for reason of my comment #4 above alone, I don't think you can expect better than this at the moment.

73 Hans G0UPL

Join to automatically receive all group messages.