Date: Mon, 12 Aug 2019 09:09:44 +0930 From: "O'Connor, Daniel" <darius@dons.net.au> To: Ian Lepore <ian@freebsd.org> Cc: "usb@freebsd.org" <usb@FreeBSD.org>, "freebsd-arm@FreeBSD.org" <freebsd-arm@FreeBSD.org> Subject: Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is. Message-ID: <61B1AAF3-40F6-47BC-8F05-7491C13BF288@dons.net.au> In-Reply-To: <bfd784f6ac9c939dbe6a243336bc3b6eab02d4f5.camel@freebsd.org> References: <f1d765814f722fb2c99c9870b3cc2607b4eca2d7.camel@freebsd.org> <B9EFA4D4-C1AD-4181-B421-F6BD53434FA5@dons.net.au> <bfd784f6ac9c939dbe6a243336bc3b6eab02d4f5.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 6 Aug 2019, at 00:12, Ian Lepore <ian@freebsd.org> 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. =20 >>=20 >> 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. >>=20 >=20 > 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). >>=20 > 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].=20= > 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. >=20 > 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. Thanks. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?61B1AAF3-40F6-47BC-8F05-7491C13BF288>