mungewell / pico-timecode

A budget friendly LTC/TimeCode device built from a RaspberryPi Pico - using the PIO blocks and MicroPython

Why am doing this? Primarily because it's a fun challenge. I've been interested in Timecode for a while and the PIO blocks on the Pico make it very possible...

DIY Timecode made real.

The Rev-1 PCBs arrived, and the first is assembled and working.

I have designed the first revision of hardware to be flexible, with the intent of being used in multiple ways and with different 'Pico Boards'. The schematic will show you how simple it is.

There is a fair bit of testing, and we'll need to select the optimum components. But did I say that it WORKS!!! :-)

The code now contains a 'calibrate' mode, where the incoming RX LTC is monitored and the XTAL frequencies are adjusted to match, these seems to work pretty well... but I am still working with the passive/stock XTALs on the PICO.

Not yet looked at using a more precise/temp compensated XTAL... but once 'calibrated' the stock XTAL performs OK on the bench (likely will have difficulties with changing temp).

Demo Video - Rev 1

The main.py has a menu which can be used to control the device, and to navigate the settings. The incoming LTC is now validated before Jam is performed, and the RX monitor has indicator bar to show the relative timing between RX and TX.

This 'code' is seven files; upload all seven if you have the same hardware.

PicoOled13.py is library of screen functions, umenu.py is menuing library, neotimer.py is timer library, pid.py is a PID controller and config.py holds the settings for the unit.

pico_timecode.py and main.py combine to make the GUI app.

The first 5 are from other projects, which I use permissively under their own licenses:

• https://github.com/samveen/pico-oled-1.3-driver (*)
• https://github.com/plugowski/umenu
• https://github.com/jrullan/micropython_neotimer
• https://github.com/m-lundberg/simple-pid
• https://github.com/aleppax/upyftsconf

(*) actually using my port, as some changes are not yet accepted upstream

I created a sub-directory for the 'libs' to clarify that they are not really part of this project.

The pico_timecode.py script is also self contained for use without a display, ie can be used on its own on a 'bare' Pico board.

Build Your Own

My intent is that the project could be used to build your own devices. The proof-of-concept script(s) can just be dropped onto a 'bare-bones' Pico.

There's some DIY suggestions

If you do use my code for a personal project, drop me an email/picture. If you make a device to sell, please send me an sample to test.

How it works

It's fair to say that this task should be far above a $1 MCU (chip).

All of the LTC decoding is done in the PIO blocks, each has it's own task. Communincation between the PIO is via their in/out pins, and with interrupts.

The pico_timecode.py script just needs to monitor the FIFOs, to keep them feed or emptied.

The main.py forms the user interface/application, and controls the OLED screen

There's an indepth description on the workings

So how good is it?

Time will still tell...

Given my interest (nee obsession) with TimeCode, I have already aquired some specialised test equipment. I have also purchased an UltraSync One to use as a reference, and see how well Pico-Timecode can interoperate.

My approach will be to get the code to a point where it will 'Jam' to incoming LTC and then 'free-run' it's output LTC. The code itself has the ability to monitor the RX LTC, however the display is not fast enough to display every frame (this does NOT affect the output though, as that's running from different core/thread).

For more details see testing

pico-timecode's Issues

Testing Rev-1 Hardware

I drew up a schematic and laid out a PCB for Rev-1 of the hardware, the audio interface is needed to amp/buffer the audio LTC signal into digital signals to/from the Pico.

This board is on order, and hopefully I will have 'hands on' in about a week...

The board is heavily dependent of the Pico footprint developed here, so a big thanks to that project:
https://github.com/ncarandini/KiCad-RP-Pico

The board is designed so that a Pico can be soldered directly (via castellated pins), or using pin headers. It's also zoned into 3 sections, where the battery/output and 'top of pico' can be removed to make a much smaller board. There are Fit/No-Fit resistors to route the LTC output to the Right Channel of the input jack when using the smaller board.

I'm 100% certain I'll need to change the BOM, hopefully the PCB layout is workable. :-)

'Phase' glitches with high precision TCXO - 12.8MHz

When monitoring an external device, with a Pico modified with high precision TCXO I see glitches.

These are not 'real' in the sense that (presumably) the relative phases of TX and RX are not changing for single cycles. Maybe there is something weird with TX and RX interrupts triggering at exactly the same time?

Calibration: missing time-stamp

In logging the data during the calibration process, I notice that sometimes the timestamp is missing... which caused glitches in the plotted data

[548.866017 0.988578] 02:27:30:01 0.0006966665 -3.433942e-05 -0.6695886 23.21196
[549.974362 1.108345] 02:27:31:04 -0.0008033332 -5.246907e-05 -0.6695886 23.21196
[550.956958 0.982596]  -0.0004733335 -2.879265e-05 -0.6695886 23.30559 <----- double space on this line
[551.936826 0.979868] 02:27:33:03 0.0003666663 -6.569061e-05 -0.6695886 23.30559
[552.918270 0.981444] 02:27:34:02 -0.0007733335 -6.301473e-05 -0.6695886 23.30559

This is moderately common, and thus a pain to edit out...

contact info for the creator?

I can't find the email you've said to contact you at. I'm planning on building a few of these and have questions :)

Direct connection to Sony Multi-Interface Shoe?

I have a couple of Sony cameras without an audio jack, so I was wondering.... and ended up going down a massive rabbit hole.

The Multi-Shoe is described:
https://en.wikipedia.org/wiki/Multi_Interface_Shoe

It seems that (at least for simple devices) that the function is 'encoded' on the first 3 pins, as pull up/downs. It looks like for analogue audio that there are connections on:

• pin 4 - Mic GND
• pin 5 - Mic Right
• pin 6 - Mic Left

also

• pin 7/15/21 - Power GND
• pin 13 - Regulated power (3.1V)
• pin 14 - Mic Center(?)
• pin 17 - Un-reg Power (6.1-8.4V)

There are also some Digital Mic, with a digital connection to the camera(s), I presume that's the GVIF_SDATA_N / GVIF_SDATA_P alternate signals on the same pins.

There is a database of mics, and what they are supported on:
https://support.d-imaging.sony.co.jp/www/cscs/accessories/products.php?lang=en&area=gb&mnt=29

The real question is whether there's a cheap/easy way to get a compatible connector? Can we re-arrange the pins on a
Sony ADPMAA adapter?

Suggestions for Rev-2 Hardware

As development moves forward, I'll 'open the floor' to suggestions from every/anyone.

The following are on my list:

• Button footprints for displays without buttons
• Connections for I2C 7-seg display and switches, to assemble as Digi-Slate
• Battery holder, connector footprint and diode footprint
• Diode footprints for 'Bias-Power' (from camera audio input).

(I'll update list as suggestions come in).

Can a camera Mic port provide enough 'Phantom' power for RP2040?

Thought crossed my mind, can we power the Pico (or other board) from the 'phantom power' provided via camera's mic port?

If so, we could make 'pico-timecode' into a dongle to plug directly in. Once sync'ed it could remain attached to/power by camera.

There is this small variant of a Pico board, which can also run micro-Python....
https://www.pishop.ca/product/tiny-2040-2-mb/

Micro Adjust to compensate for XTAL inaccuracies

I have been looking at how we can bias the XTAL, to compensate for any inaccuracies between it and the 'other' devices in use.

We have a scheme where the PIO clock divider is toggled up/down by 1/256 fraction at a defined duty factor. This means that the clocks are slight faster/slower for a fraction of the time. With two Picos connected together we can see values of +0.1, -0.1 and -0.5 affect the synchronization (error bar) 10 minutes after Jamming.

The question is how do we measure the inaccuracy to figure out the correction....

Replacing XTAL with a more accurate one

It would seem that the stock XTAL (with current code implementation) is not meeting the timing accuracy required - less than 1frame drift in 8hours.

Fortunately we can replace the XTAL with a more accurate TCXO module. I have 2 candidate parts:

• 12.0MHz - https://www.digikey.ca/en/products/detail/ilsi/i538-2o7-12-000-mhz/13682056
• 12.8MHz - https://www.digikey.ca/en/products/detail/txc-corporation/7N-12-800MBP-T/5222401

The 2nd is more accurate/precise, but with a slightly different frequency it might mean more work. The Pico's SDK has a override for building at different frequencies, so a custom build of microPython is likely needed. The boot-rom also expects 12.0MHz, so using this part might mean that USB is not functional - and 'we' might have to rely on the SWD interface to program the board.

2nd part is also bigger....

Calibration: off by 1 error

As mentioned on #4 we have a way to assess the XTAL accuracy by performing a calibration process, and logging the results.

I have/am writing scripts to automate this process and previously noted that a unit could settle on calibration values which differ by 1 unit - which represents 1/256 fractional division of the CPU clock.

I previously though that this was a set-up issue (ie only at start), but now I have a couple of logs where the calibration value changes during the process to 'jump' between the two values. This suggests that there is something wrong with the way the code monitors/tracks the input (from UltraSync)...

and

Note: Multiple units monitoring the same input signal, so I don't think that this is the UltraSync glitching.

Jamming/Processing RX data - relative to the start of frame.

In my world Frame XX starts with the first bit of the frame, but when we're receiving the (same) data we can't process it until the end of the frame - just before the sync word.

So in-order the Jam correctly we need to automatically increase the Frame number, and apply to the TX engine.

Most of the time we would want to increase by two, as we're likely before the end of the frame. However there is a chance that we're between end of frame and start of next. We'll have to look at the timing of these points (relative to CPU clock) to see if we increase by one or two.

If we're in the 'Danger Zone', then perhaps we should just defer the Jam for another Frame/time.

'Include Icon/IIR' should be hidden before 'connect'

The new tick boxes are showing by default, before the pedal is connected.

After a disconnect they are (correctly) hidden.