TCXO + Beaglebone Black

I've added support for an external clock (TCLKIN) to the Beaglebone Black timer driver.

Setup

I used what I had on hand to test it. I setup a Navspark microcontroller to send a ~1MHz PWM (code here). Since it's a GPS reciever, the Navspark uses a TCXO. This makes it much less sensitive to temperature changes.

Pin "GPIO20/PWM" from the Navspark was connected to pin P9-41 on the BBB (the yellow jumper). The Navspark was powered via the BBB's USB.

Switching to this as the system's time keeping clock:

[  106.434375] pps-gmtimer: timer(timer4) switched to tclkin, rate=1364000Hz
[  106.437739] pps pps0: new PPS source timer4
[  106.437803] pps-gmtimer: clocksource: timer4 at 1364000 Hz
[  112.357353] Switching to clocksource timer4

Results

This resulted in a much better local clock.

The local clock frequency error was within a 33ppb range 98% of the time, and the absolute error was under 100ppb. This is pretty normal performance for a TCXO, and a large improvement over a normal crystal.

The clock offsets (phase error) were inside +/-20ns 50% of the time, and +/-290ns 98% of the time. This is also an improvement.

Looking at the frequency error vs temperature graph, there's an obvious relationship between the two. I've turned off chrony's tempcomp for this test, but it looks like turning it back on with this new data would reduce the frequency error by around 10ppb.

Problems

This setup is pretty hacky to start with, but there's an additional problem.

On day 31, there was a USB hiccup with the BBB:

[667586.701386] CAUTION: musb: Babble Interrupt Occurred

This turned off power to the USB system, which stopped the microcontroller's PWM signal. This resulted in the wall clock time stopping, but amazingly the system continued running. Things calling sleep would hang, but ssh and the shell continued working. Running "date" returned the exact same second. The reboot command never finished, and the reset button wasn't enough as the bootloader hung. I had to power cycle it before it booted.

Another problem is that since this is a 1.364MHz clock, the clock's precision is limited to 733ns. This is much less precise than what the hardware could do (41ns).

See also: Part 2