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

Ian Lepore ian at
Mon Aug 5 14:42:38 UTC 2019

On Mon, 2019-08-05 at 15:28 +0930, O'Connor, Daniel wrote:
> Hi Ian,
> Firstly, this is a very cool test - thank you for running it :)
> > On 3 Aug 2019, at 06:46, Ian Lepore <ian at> wrote:
> > PPS(2) is an FTDI 232R, a USB 1.1 serial adapter, connected to a port
> > on a USB 2.0 hub that's connected to a USB 2.0 host port on the
> > Wandboard.  
> > 
> > PPS(3) is an FTDI 4232H, a USB 2.0 serial adapter, connected to a port
> > on the same USB hub as PPS(2).  
> <snip>
> > 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.

> 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.)

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.

server <any network peer>        iburst prefer

server              minpoll 4 maxpoll 4
fudge stratum 0 refid gpt

server              minpoll 4 maxpoll 4 noselect
fudge stratum 0 refid gpio

server              minpoll 4 maxpoll 4 noselect
fudge stratum 0 refid usb1

server              minpoll 4 maxpoll 4 noselect
fudge stratum 0 refid usb2


-- Ian

More information about the freebsd-usb mailing list