Repository navigation
Feature Requests
Page to document requests, and assess whether they are achievable
Unfortunately due to the project architecture this is not possible. The CPU has no direct control, or knowledge, of the precise timing of the LTC output. Technically the PIO blocks can sync to a rising (or falling) edge on a logic pin, if this is derived from a BT/WiFi connection it might be possible to sync wirelessly... but this is not something that I have a desire to implement myself.
It might be possible to offer some WiFi interface to the configuration, ie changing FPS without the using the on-device menu or connecting a USB cable.
I also found this other project which has reversed engineered the BT-LE protocol of the Tentacle-Sync devices:
PT-Thrifty functions OK, but could be better. The (very cheap) implementation 'looks' a little odd with some recorders. I added an additional Op-Amp in the next PCB design and it appears to function correctly.
One side-effect of this is that we can output LTC which simultaneously receiving LTC. This would be useful in the Sony-MI implementation, where PT-Thrifty is connected to the hot-shoe of a camera.
The PIO on the RP2040 is completely full, but the RP2350 adds another block of 4 PIO engines. This could be used for additional output(s).
A 48KHz (or similar) WordClock, locked to the framerate of the LTC, should be simple. It may be possible to create a 'black burst' video pattern, or maybe a tri-level signal... but this would be considerably harder. PIO can stream data via DMA, so perhaps it can just play out a previously 'rendered' image (including the sync portions).
In the investigations around Sony MI (https://github.com/mungewell/pico-timecode/issues/7) we determined that some cameras can ONLY take a digital audio feed. It's not know what format that this takes, but (like above) maybe something can be rendered using the addition PIO of a RP2350.
We may be able to achieve, but I suggest that we use an incoming 1PPS from the RTC as 'truth'. We should also have some way of setting the clock.
Note: this would only be 'valid' for integer FPS (30, 25, 24) and none-drop frame. The others have weird timing wrt a wall-clock.
Found some links to suggest how the higher framerates are encoded into re-purposed bits within the LTC frame. Still a 'future' consideration.
Does this also need 59.96, drop-frame, etc?
I found some explanation of how to encode the high framerates, but this might be problematic.
This should be a simple change: https://smittytone.net/docs/ht16k33_segmentbig.html
This would be more complicated: https://smittytone.net/docs/ht16k33_matrix.html