Skip to content

Calibration

mungewell edited this page Jul 27, 2026 · 5 revisions

Calibration

Clock sources

Effectively this project is just a counter, it counts passing time in frames, seconds, minutes and hours. It takes this, adds in some meta data and encodes it into a LTC stream that can be recorded onto tape, or decoded by other devices.

The accuracy of the output is reliant on the accuracy of the CPU clock, which is multiplied-up from the XTAL input. The stock Picos use a XTAL which can be 'iffy', it's possible (recommended) that the XTAL is replaced with a TCXO which will give a more accurate/stable source.

Calibration Process

That said, both 'PT-Papa' and 'PT-Thrifty' have the ability to calibrate to incoming LTC - for example if you have a commercial unit you want to match... or even pick one of your DIY uints as the master. Once triggered through the menu the calibration process will monitor the incoming LTC and figure out the correction needed to produce a matching output, this is then automatically written to the config file for future operation.

Calibration values are an offset from the nominal/ideal divider needed to clock the PIO state-machines. Each frame rate needs to be calibrated separately.

The check_calibration.py script reverses the calibration into a calculated value of what the boards XTAL must be (assuming RX is 100% accruate). Here we can see that there's not much difference in these calibrated values

-8.0:
Checking 30.0 fps
Ideal divider 1562.500000 (at 30.000000 fps)
Calculated divider 1562.5312
Calculated XTAL freq 12000241.0

-8.5:
Checking 30.0 fps
Ideal divider 1562.500000 (at 30.000000 fps)
Calculated divider 1562.5332
Calculated XTAL freq 12000255.0

Absolute Calibration

The above process is matching the LTC rate to another device, I am investigating how to do a 'absolute calibration' which likely would be with some lab equipment, or against a high quality GPS.

Acceptable drift/accuracy

I've heard it said that the industry accepted drift would be in the '1 frame in 8hrs' region. But what does that mean?

I think that it means that the output Timecode should be closest to the True time for at least 8hrs, so a drift of not more than 1/2 the frame period - ie a 'phase' of less that +/-0.5.

Clone this wiki locally