SMPTE EB linear time cod generator.
ESP32 based SMPTE/EBU timecode generator, with NTP slaving, for Leitch and similar studio/broadcast clocks.
Background
So we have a few Leitch Illuminated 12 Inch SMPTE Timecode Analog Broadcast Studio Clocks and its more modern digital, 19" rack sized variant. The each take a typical studio time signal; a SMPTE/EBU style 'audio' signal (4V p.p., baud, 80 bits, 2400Hz/4800hz FM modulated sequences of 80 bits).
These are then connected to some ESP32's that pick up the time from the office its NTP serves; and provide these to the clocks.
It runs a small website to allow for a fiddle factor. E.g. to make sure people make their train.
Hardware
On the back of all clocks is a typical red/black two wire spring terminal. This is internally wired to a 2x6 IDC connector; pin 1 and 2. It turns out that pin 3 and 4 contain a nice 5V voltage. All in all these 4 wires are used to wire up the ESP32 (Wemos) boards.
The units seem to not always pick up a 3v3 Peak to Peak voltage generated by the GPIO. So we've added a small BC546 transistor (base tied to the GPIO through a 2k2 registor, E to ground, C with a 1k pullup) to raise the signal a bit.
Schematic: https://easyeda.com/dirkx/smpte-esp32-ltc-ntp
Note that the polarity on the internal IDC connector seem to differ between revisions/versions of the clock (or we were a bit careless putting the wires in) -- hence the diode to protect and top it off a bit.
We've intentionally wired the transistors resistor to the original voltage - to get enough Vpp.
RMT / pulse trains
Some of the clocks are very sensitive to timing that is lightly off; or when you skip a frame. The angry red error leds starts to flash accusingly for a few seconds then.
So we're using a careful double buffer approach with the hardwar based RTM pulse generator. As the latter will glitch when not fed multiples of 64 pulses we allow for 80 bit SMPTE/EBU frames to cross boundaries. This makes it a tad hard to figure out to 'set' the clock.
Caveats
The NTP is terribly primitive and lacks the usual long term phase locked loop that gives it nice, millisecond accuracy even when there are fluctuating network delays. Thus - we're not trying to aim for frame level accuracy. If that is of interest to you - the magic term is 'NTP clock discipline' and https://www.eecis.udel.edu/~mills/ntp/html/discipline.html is a good primer.
Also - the code is hardcoded for Europe, CET and its current daylight savings regimen.