开云体育

The data sheet of the AD8307 gives a supply filter circuit that is good enough to be used with the output of the arduino
Keep in mind the AD8307 goes to 500MHz, good shielding is important for the low end of the power range.
If the shield has a massive ground plane at the side of the arduino it may work but if its a thru hole shield without proper ground plane probably not.
--
HBTE Files section:?/g/HBTE/files
Erik, PD0EK

Hi, I am starting to build a 'specan' (?)

Mainly because I have a prototyping shield spare I will be using one.? It also has an SOIC 14 footprint.? I was wondering whether I could put the AD8307 on the shield.?

Would that introduce too much noise from the MCU?

What about if I were to shield the area of the board that contains the log detector?

Second Question:? Ashhar Farhan used an external 5v regulator for the arduino (separate from the regulator for the AD8307) but the arduino has a regulator on board.? Is there a good reason for by-passing the arduino's regulator?

thanks & 73

Ellis G7SAI

Sweet! You are the man! (Or whatever pronoun you're down with...)

I've got a couple of these component testers from a couple years back that I got off of eBay. They could probably use a fresh remake. Thanks

Here is a direct comparison between running the SI5351 with a XTal or a TCXO

TCXO frequency at 100th overtone (1GHz). Total width of the scan (100Hz) is 10e-7 of 10MHz



XTal frequency at 100th overtone (1GHz). Total width of the scan (100Hz) is 10e-7 of 10MHz



The difference in short term stability is very visible. The GPSDO is not able to keep the output frequency of the XTAL within +/-10e-8, its exceeding it with a factor 2.
The TCXO is within +/-10e-9 (+/- 1 Hz at 1GHz)

TCXO drift (blue trace) and corrections (red trace)? (below 10e-9)



XTAL drift (blue trace) and log10 of corrections (red trace)? (just below 10e-8)




The drift of the XTAL is about 50 times higher as the TCXO and you can clearly see the adaptive nature of the control algorithm as the time between measurements decrease when a lot of drift has been measured and the time between measurements increases when the frequency is more stable.
--
HBTE Files section:?/g/HBTE/files
Erik, PD0EK

Hope this topic does not overload your inbox.....

The SW on github:?
has been updated to automatically adjust for variations in the SI5351 XTal or TCXO frequency.
It has been tested with a 25MHz XTal and a 26MHz TCXO but will probably adjust for a much wider range. No need to change the source anymore for this, just swap your SI5351 module and continue
--
HBTE Files section:?/g/HBTE/files
Erik, PD0EK

And this is a short video of the phase detector in action using a TCXO and 10 seconds phase averaging.



Yellow line goes high after PPS up edge and goes down at up edge of the 2.5MHz clock. Maximum high time is 400ns
The blue line shows the charging of the capacitor supplying Vphase to the Arduino

If there is perfect lock and no fractional adjustments of the PPS the phase (width of the yellow pulse) does not change with each PPS.?
Sometimes you see the 22ns jump left or right when the PPS is adjusted with one cycle of the 48MHz clock
If there is no perfect lock you see a slow drift of the phase.
After each recalculation of the target frequency every 10 seconds the phase jumps to a totally new value because the VCO PLL is restarted.

With an XTal in the SI5351 the phase is considerably less stable but still sufficient for achieving a lock
--
HBTE Files section:?/g/HBTE/files
Erik, PD0EK

A photo of the setup
The white module at the left top is the thermally insulated SI5351 (just some foam tape wound around the module)
The black thing at the right top is the phase detector with the scope probes still connected
The 16x2 display shows debugging info:
Last measure phase | phase difference with previous PPS | time since start
Last applied frequency correction in 1/1000Hz | current interval | current frequency offset applied to 10MHz in 1/1000Hz



The latest code has been cleaned a bit and pushed to github:?



--
HBTE Files section:?/g/HBTE/files
Erik, PD0EK

Not sure if I have 360 degrees view. I'm using an active antenna and a 2m antenna wire between GPS antenna and GPS module to keep the noise from the SI5351 (which is considerable) away from the GPS antenna
Due to the averaging over 20 seconds the PPS jitter will average out anyway. And the NEO module have 22ns jitter because of their fractional time for the PPS
My GPS modul is a NEO7-M. It will even work with a NEO6 module
The latest version pushed to Github is for a 25MHz Xtal on the SI5351
Will need to tidy the source a bit. It shows it has been part of some experimentation.

You can start with the 2.5MHz into the Arduino (so no phase detector)

The SI5351 connections:

Clock 0: 2.5MHz into the Arduino pin 2 (ppsPin)
Clock 1: 10MHz output.

Clock 0 and 1 use the same fractional divider setting to ensure exact frequency relation, clock 0 uses a divide by 4 after the fractional divider
If you set the frequencies of clock 0 and clock 1 to 2.5MHz and 10MHz respective you are never sure there is no fractional error between the two.

Well that looks really good !

I'd connect the modules we have here and have a play with you (found them in various boxes). Only trouble is I've read that a clear 360 deg sky is needed for the GPS antenna in order to get a proper/accurate 1pps from the GPS module, I don't know if that's true or not, not tried it.

The GPS module is a cheap'ish NEO-M8N off ebay so for sure a fake - whether that matters or not don't know.

We made a normal size GPS antenna last year for another project (more efficient than the little ceramic antennas) that 'might' help but not sure.

The ultimate goal is not to use a TCXO but a stock SI5351 module with standard Xtal so I did some more tests using a standard SI5351 module with XTal and some thermal isolation.
Soon it became clear that changing the VCO frequency to minimize the fractional frequency error caused stability problems.
Changing the VCO PLL setting caused changes in the heat generated by the SI5351 causing an additional frequency drift after each change.
After fixing the VCO PLL frequency the stability became much better.
Two minutes after start the phase detector was able to lock and provided a correction every 20 seconds.


Here you can see the corrections happening. The spectrum analyzer shows the 100th harmonic of the 10MHz output at 1GHz with a span of 400Hz. The span at 10MHz is thus 4Hz so the deviations are below 0.4Hz (one grid)



The application for the GPSDO will determine if the corrections each 20 seconds are acceptable.
--
HBTE Files section:?/g/HBTE/files
Erik, PD0EK

The STM8S103 has at least a couple of 16-bit timers (one is an 'advanced' timer), so I think it might well be a little better than the ATMEL's. Plus they boot up using their won internal RC CPU clock, which you can then reconfigure to move to the CPU clock source to an external source such as the Si5351 or external OCXO.

You could maybe have a play with them using the little modules just like the Arduino nano's, here's one in the UK? ..



But you seem to be doing very well as is anyway, just thought I'd let you know about running the CPU from the clock you're trying to synch to the 1PPS.

Has anyone tried adding a little varicap (inc series cap to xtal and series resistor to control voltage) to the Si5351's xtal to have fine frequency control ?
I know it doesn't solve the temperature drift problem but it does offer another method of frequency control (after setting the Si5351 to it's lowest 6pf xtal loading), although VCO control is not what this little project is about I know.

Anyway, sorry to butt in, just adding possible suggestions for playing with in the future. You're current method is more than good enough for adjusting a transceivers internal clocks/osc's/pll's, very good !

Thanks for the suggestion OneofEleven! The STM chip probably also has a better counter without the resampling to the CPU clock done in the ATMEL.

To understand the source of the noise I measured the phase delta every PPS, no averaging done in below plot. Just the raw measurement of the phase delta per PPS in nano seconds.


The plotted value is forced to 40 when the frequency of the SI5351 is adjusted. The segment from 0:02:53 to 0:03:30 shows very nicely the actual noise in the phase measurement is very small (below 5ns) . What remains are the excursions when the NEO7-M does the fractional PPS correction by inserting or removing one 48MHz period (22ns). Averaging these phase measurements over at least 10 seconds is thus needed to get reasonable accurate frequency corrections.
--
HBTE Files section:?/g/HBTE/files
Erik, PD0EK

All very good, well done !

To improve the resolution/stability you could clock the CPU directly from the Si5351, that way the CPU is phase locked to the clock of interest rather than using it's own drifty xtal clock. That way all internal computations at the moment of interest (the 1PPS) could be phase synchronized, you wouldn't need to count the 2.5MHz clock, you remove the CPU clock from the equation together with the +/- 1 CPU clock cycle time resolution.

I use the STM8S103F3 rather than the ATMEL chips now (clock source reconfigurable on the fly, 3V to 5V supply etc).

Using the phase measurement to measure every 10 seconds the averaged PPS error in nanoseconds (ignore the graph title) gave this result
It seems there is still some noise on the phase measurement but the pulse counting and the phase measurement converge nicely
Now I need to switch to phase measurement for frequency corrections once the counting is sufficiently stable.


--
HBTE Files section:?/g/HBTE/files
Erik, PD0EK

This project has really moved far from its roots now, and I mean it in a positive way. It’s hardly a version of the F2DC Gpsdo any longer with its variable measurement gate for faster convergence, and in many respects closer to W3PM’s original version since it no longer depends on the Etherkit library in order to improve accuracy (at least that’s my understanding from browsing the code). And now with possible phase comparison elements from the Lars (SK) Gpsdo. Even without the latter, it has become a unique PD0EK design in my view!


Sverre
LA3ZA

The Vphase can be input into the Arduino using analogRead(A0)
With the integration time reaching 128 seconds the frequency error is below 1e-8 when the count error is 2 or less.
Using the Vphase subtracting consecutive Vphase gives also the frequency error. In average the phase error is in agreement with the pulse counting error but the NEO7-M is making life difficult as it can only change the duration of the PPS in?
1/48MHz steps and its thus increasing/decreasing the PPS time with +/-21ns steps which is far more than the average phase drift.
This implies that even with a very linear relation between Vphase and the phase measurement being available every second (compared to the count during 128 seconds) it will be required to do some averaging to get rid of the +/-21ns correction steps. Measuring the phase changes and averaging over 20 seconds should bring the accuracy close to 1e-9, which is much faster than counting pulses during 1000 seconds.
--
HBTE Files section:?/g/HBTE/files
Erik, PD0EK

The phase comparator can? actually be build from a single 7474.
The 7474 has inverted Set/Reset but in?below spice mode the Set/Reset are not inverted so an inverter was added for the simulation only


C1 is charged after the rising edge of the PPS through? D1 and R2 depending on the length of the pulse and slowly discharges after the rising edge of the 2.5MHz clock via R1 during the rest of the second.
VPhase should be measured shortly after 400ns (maximum pulse duration) after the rise of the PPS to capture the actual phase.

Many thanks to Lars for the inspiration.

Erik, PD0EK

After building a phase comparator using a 7474 and a 7400 it became possible to observe every second the phase delta between the PPS and the 2.5MHz clock on a DSO
The maximum phase comparator pulse duration is 400ns (2.5MHz clock) , minimum is zero.?
The TCXO seems to be very stable. When the arduino SW is "in lock" you see the phase drift slowly depending on the remaining frequency error.
With an error of 1e-8 the phase changes with 10ns every second but when in lock the shift per second is much less then 10ns.
A possible problem is the corrections to the PPS being made which cause a phase jump of 20ns. Not sure yet how to deal with these jumps. Probably some form of intelligent averaging will be required
Using the pulse duration to voltage translator as used in Lars GPDSO it should be possible to observe the phase changes by the arduino SW every second and use these phase changes over a certain time duration to correct the SI5351 more often then when using the 400s or more pulse measurement time.
A clear disadvantage of the SI5351 (instead of using a true VCXO) is loosing the phase after each frequency update so you have to restart the phase measurement after each frequency update.
--
HBTE Files section:?/g/HBTE/files
Erik, PD0EK

After updating the SW to allow setting the 10MHz from the SI5351 with a true accuracy of? 1/1000 Hz versus the TCXO the 3 hour trace looked like



Measurement time fluctuated between 512 and 2048 seconds where the latter is clearly too long given the variations.

There are some things to investigate:
- Is it possible to isolate the SI5351 module with the TCXO better to reduce temperature swings? or is 1e-8 the best accuracy you can get from such a cheap TCXO?
- Is it possible to count in an adaptive way so not to wait for the full time when there is clearly a drift happening to shorten reaction speed when a step change in temperature happens?
--
HBTE Files section:?/g/HBTE/files
Erik, PD0EK

An updated SW has reduced fractional spurs to an acceptable level (see github??)

Stability is great:


Will test if further increasing the measurement time is useful but the remaining thermal changes of the TCXO due to environment temperature changes may now be the limiting factor.

Erik, PD0EK