> From: Attila Kinali <attila@kinali.ch> > Basically, all you have to do is use an SBC that runs linux and has > a GPIO with an interrupt to act as a PPS input. Attach a GPS receiver > and you are almost done. The cheapest option are probably the i.MX233 > based ones (go as low as €20). Thank you, Attila, this sounds like the way to go - perhaps I can repackage this solution in a smart attractive enclosure and market it as a high performance product. I was a bit behind the curve on recent developments - do you have a suggestion for the best linux running SBC and cheap GPS suitable for this? >> I am not measuring any frequencies - the whole device runs synchronously hard- >> locked to GPS time when it is available and freewheeling when not. > > You should have a control loop somewhere, which explicitly or implicitly estimates the frequency of the TCXO. > The time-nuts archives are full with discussions how to do such > control loops and improve hold over performance. Though there > weren't many in the last 2-3 years. John Vigs tutorial is also > a good start. OK, so I need to introduce additional TCXO and a control loop to improve the holdover performance? Thanks Leo

			Attila Kinali

On Wed, 1 Nov 2017 04:06:06 +0000 Leo Bodnar <leo@leobodnar.com> wrote: > > From: Attila Kinali <attila@kinali.ch> > > Basically, all you have to do is use an SBC that runs linux and has > > a GPIO with an interrupt to act as a PPS input. Attach a GPS receiver > > and you are almost done. The cheapest option are probably the i.MX233 > > based ones (go as low as €20). > > Thank you, Attila, this sounds like the way to go - perhaps I can > repackage this solution in a smart attractive enclosure and market > it as a high performance product. > I was a bit behind the curve on recent developments - do you have a > suggestion for the best linux running SBC and cheap GPS suitable for this? Depending on your expertise and the volume you expect, I would probably build my own board. Select a SoC that has fast 32bit timers so you can accurately measure the PPS. The OSD3358 I mentioned is a good compromise IMHO, as it allows you to build upon the Beaglebone community, without having to deal with a complex board design. And the PRU allows you to sample with 5ns precision. A simple interpolation like what Nick Sayer did would also be a good idea, IMHO. > > You should have a control loop somewhere, which explicitly or implicitly estimates the frequency of the TCXO. > > The time-nuts archives are full with discussions how to do such > > control loops and improve hold over performance. Though there > > weren't many in the last 2-3 years. John Vigs tutorial is also > > a good start. > > OK, so I need to introduce additional TCXO and a control loop to improve the > holdover performance? Not an additional TCXO, but model its behaviour. What you should do is basically system identification and adaptive control. The most common way to do that is a Kalman filter. Though Marek Peka wrote a paper on the problems of Kalman filters for clock modeling (mostly stability issues of the predicition) and presented it at IFCS/EFTF in Prague in 2013. > It is really puzzling why holdover has suddenly come into focus. Due to > NTP redundancy feature it is trivial to put several inexpensive time servers > around the local or campus network and let clients do the standard NTP sanity > checking and server selection. And those building an NTP system able to cope > with 24h+ global GPS outage know what they are doing anyway. Well, that was me guessing what your goal was. Seems like I was off. Attila Kinali -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil Stephenson