Date: Mon, 05 Aug 2019 08:42:31 -0600 From: Ian Lepore <ian@freebsd.org> To: "O'Connor, Daniel" <darius@dons.net.au> 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: <bfd784f6ac9c939dbe6a243336bc3b6eab02d4f5.camel@freebsd.org> In-Reply-To: <B9EFA4D4-C1AD-4181-B421-F6BD53434FA5@dons.net.au> References: <f1d765814f722fb2c99c9870b3cc2607b4eca2d7.camel@freebsd.org> <B9EFA4D4-C1AD-4181-B421-F6BD53434FA5@dons.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org> 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 127.127.22.0 minpoll 4 maxpoll 4 fudge 127.127.22.0 stratum 0 refid gpt server 127.127.22.1 minpoll 4 maxpoll 4 noselect fudge 127.127.22.1 stratum 0 refid gpio server 127.127.22.2 minpoll 4 maxpoll 4 noselect fudge 127.127.22.2 stratum 0 refid usb1 server 127.127.22.3 minpoll 4 maxpoll 4 noselect fudge 127.127.22.3 stratum 0 refid usb2 [1] http://e2e.ti.com/support/processors/f/791/t/406121?AM335x-TCLKIN-on-Linux-3-19 -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bfd784f6ac9c939dbe6a243336bc3b6eab02d4f5.camel>