Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.

O'Connor, Daniel darius at
Mon Aug 12 00:06:11 UTC 2019

> On 6 Aug 2019, at 00:12, Ian Lepore <ian at> wrote:
> On Mon, 2019-08-05 at 15:28 +0930, O'Connor, Daniel wrote:
>>> Most people are not worried about their kernel clock being 200
>>> microseconds off from UTC, even if they're using the PPS signal from a
>>> GPS receiver.  So I think most people should feel completely at ease
>>> using a USB serial adapter as the input device for a PPS signal.  
>> Does the USB clock derive from the 10MHz Rb clock? If so that would mean you would see a lot less jitter than a 'normal' user where the USB clock is not locked too GPS.
> No, usb is derived from the same 24mhz crystal that clocks the cpus.  I
> think usb and its need for clocks at 48 and 480mhz is why so many small
> arm systems use a 24mhz main clock.

OK, I thought when you used the external clock it was being used to derive the USB clock (eg via a PLL) hence the jitter would be low - if not that is even better.

>> Do you have a more detailed write up of things like the NTP configuration file? I think I could replicate your test here although I have a Beaglebone Black, not a Wanboard so I will need to check if it can take an external clock. (We have GPS modules & Rb oscillators at work to create reference clock for bi-static meteor applications).
> The same setup should be possible on a BBB.  There is a TCLKIN pin
> mentioned in the manual.  Some searching on the web yields a few clues
> that it might be possible to mux that to a pin on the P9 header [1]. 
> There is already a dmtpps capture driver for TI, but I'm afraid it may
> have bitrotted over the past couple years.  Also, even when it last
> worked, it just barely worked, because the reduction of kernel
> timecounters from 10 to 2 timehands causes the PPS capture to almost
> always get lost on single-core processors which are in cpu_idle() at
> the time the hardclock interrupt happens.  (But that's fixable by just
> increasing the number of timehands, I think at least 4 are required.)

OK, how do I increase the number of clock hands?
I have am335x_dmtpps setup from last year when I tried this previously :)

> So all in all, it's doable, but it'll take a bit of work.  I can help
> with the driver stuff.
> The ntp config is pretty simple, it uses instances of the "atom" clock,
> which is a bare-PPS refclock which needs to be paired with any network
> peer to operate.  The network peer is used to obtain the initial time
> of day, then the PPS signal is used to steer phase.  The network peer
> must be marked 'prefer' for some reason, it's just an ntp rule.  In my
> test setup I forced ntp to steer to the "perfect" pps signal by marking
> all the others as "noselect", otherwise any of the atom clocks would be
> eligible to be the system peer.

My current setup uses gpsd but I think that is complicating things unnecessarily so I'll try it without that and see if I can get it working.

Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum

More information about the freebsd-usb mailing list