Precision Clocking the PIO, and adjustments without stopping block

[mungewell]

I have a project which requires very accurate clocking, in my initial testing I have confirmed the 120MHz on one board does not match 120MHz on another. I am synchronising via 'LTC' and counting video frames, after ~5hrs one Pico is off by 1 frame.

Q1. Is it possible to bias the clocking of the PIO so that inaccuracies can be made in real time, but only by adding or subtracting clock pulses every so often?

The initial set-up of the PIO block takes a frequency, but this is limited to an integer value. For example

    sm_freq = int(fps * 80 * 32)
    sm.append(rp2.StateMachine(0, start_from_pin, freq=sm_freq,
                               jmp_pin=machine.Pin(21)))        # Sync from RX LTC

My frame is 80 bits long, and I sub-split this by 32. These are the rates I need:

Q2. Since (due to TV history) I need the 'wacky' frame rate of 29.97, how can I achieve this... since the call can only be an integer frequency.

Q3. How does one understand the fractional bit of the CPU clocking? Is it just a case of adding up the bits to get the closest value??

[mungewell]

In the above, I was confused about the System clock, which is a PLL/Multiplied version of the Xtal. Nominal this is 125MHz, however the PLL can be adjusted. The following script is helpful in working out values to use:
https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/hardware_clocks/scripts/vcocalc.py

For example 120MHz is desired:

$ python vcocalc.py 120
Requested: 120.0 MHz
Achieved: 120 MHz
REFDIV: 1
FBDIV: 120 (VCO = 1440 MHz)
PD1: 6
PD2: 2

This, and the other 'light-bulb' moment that 29.97 is actually '30.0/1001.0 = 29.97002997003', gives me a much nicer target.

Questions still remain how I can get the non-integer value through the rp2.StateMachine() function. Can I use the function, but then overwrite multiplier values directly in memory before the StateMachine is started?

[mungewell]

BTW, my project is open-sourced... if anyone wants to follow along:
https://github.com/mungewell/pico-timecode

[mungewell]

RP2040 datasheet says:

So this code

    # Print out Freq multipliers
    for base in [0x50200000, 0x50300000]:
        for offset in [0x0c8, 0x0e0, 0x0f8, 0x110]:
            print("0x%x : 0x%x" % (base + offset, machine.mem32[base + offset]))

Gives (when my fps is set to 30, with default 125MHz system clock)

0x502000c8 : 0x65b9a00
0x502000e0 : 0x65b9a00
0x502000f8 : 0x65b9a00
0x50200110 : 0x65b9a00
0x503000c8 : 0x65b9a00
0x503000e0 : 0x65b9a00
0x503000f8 : 0x10000
0x50300110 : 0x10000

0x065b = 1627
0x009a = 154

Which matches my spreadsheet :-)

[mungewell]

I've also noticed that the 12MHz XTAL could be replaced with something more precise:
https://github.com/dorsic/PicoPET#hw-modification

There seem to be a number of high precision (temp controlled) XTALs, but 12.8MHz seems to be more common than 12.0MHz.

For example, quoting a Frequency Stability of ±280ppb:
https://www.digikey.ca/en/products/detail/txc-corporation/7N-12-800MBP-T/5222401

$ python vcocalc.py 120 -i 12.8
Requested: 120.0 MHz
Achieved: 120.0 MHz
REFDIV: 1
FBDIV: 75 (VCO = 960.0 MHz)
PD1: 4
PD2: 2

If this hardware modification is done, would that then mean that the USB connection would not function (without adjustments)? USB is not important for the project, but I still need to be able to upload code...

[rkompass]

Q1. Is it possible to bias the clocking of the PIO so that inaccuracies can be made in real time, but only by adding or subtracting clock pulses every so often?

You may change the divider in real time, including its fractional part. This will result in some single clock pulses introduced in the effective PIO clock so that the PIO clock effectively has the f_sys / (integer_div + fractional_div/256) frequency.
If the resulting frequency resolution is not precise enough you might regularly switch between different dividers, preferably between neighboring fractional values of the divider.
The resulting PIO clock will be effectively (i.e. in the long run) more precise and adjustable in finer steps, but it will not be a perfectly synchronous/regular clock. That means its clock periods will vary by a value of 1 from time to time, to achieve the fractional frequency on average. I f you do not accept that you have to avoid the fractional dividers completely (let them be 0).

[mungewell]

Interesting....

Firstly, I absolutely will need the fractional dividers to get to (close to) the right frequency.

Working the math for 30fps with a CPU clock at 120MHz, I'd want a divider of 1562.5. The next possible value up is +1/256, 1562.50390625, which would be the same as working with a CPU clock of 12000300 Hz... a change of +0.78125%.

With my observed drift, I saw a delta of 1frame in around 5hrs. At 30fps, 5hrs is 540000 frames. A 0.78125% increase would be 544218.75 frames. So in order to get in the range of 1 frame adjustment I would need to correct by increasing divider for around 1/4000th of the time.

Have to think whether this is actually possible, or practical.

[mungewell]

I was able to use a timer (https://github.com/jrullan/micropython_neotimer) to create a duty factor approaching the resolution needed, though this is somewhat dependent of the chosen period. 60s seems to work OK...

micro_adjust.py.txt

Where cduty is the measured duty of the last cycle, and rduty is an average of the last 10 cycles. now is ticks_us(). I think that the correction value is biased, as the code takes time to notice that the timer has finished and call the function itself.

print("Duty check:", now, cduty, rduty/len(rcache), correction)
--
Duty check: 166058128 0.0002493296 0.0002508874 1.00355
Duty check: 226059156 0.000251529 0.0002509224 1.00369
Duty check: 286060167 0.0002504124 0.0002508475 1.00339
Duty check: 346061275 0.000250612 0.0002510307 1.004123
Duty check: 406062199 0.0002510295 0.000251109 1.004436
Duty check: 466063180 0.0002502126 0.0002509707 1.003883
Duty check: 526064161 0.0002509792 0.0002509624 1.00385
Duty check: 586065178 0.0002513458 0.0002509157 1.003663
Duty check: 646066235 0.0002512956 0.0002509856 1.003943
Duty check: 706067141 0.0002513629 0.0002508107 1.003243
Duty check: 766068274 0.0002512452 0.0002510023 1.004009
Duty check: 826069191 0.0002497462 0.000250824 1.003296
Duty check: 886070129 0.0002502961 0.0002508124 1.00325
Duty check: 946071183 0.0002512622 0.0002508774 1.00351

[mungewell]

Marked your comment as the solution. I was able to code up a solution, which temporarily increases (or decreases) the PIO clock divider value in a 'duty factor over period' fashion. On the receiving device the 'error bar' show the timing mismatch changes, noted 10mins after Jamming/Synchronizing the LTC between devices.

With a couple of Picos with mismatched clocks, various duty factors of +0.1, -0.1 and -0.5 show that the output LTC rate is slightly altered when compared to LTC output on the other device.