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 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).
>
>
>
> > 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 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
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
