Help with understanding how to approach realtime en-/decode...

[tilllt]

Hi,

like so many other people that posted here, i'd like to make an attempt to realtime encode / decode. I am very unexperienced with programming and electronics so this project has a huge learning curve for me. Platform will be a Teensy 3.2 and i think the onboard ADC / DAC are sufficient for the timecode signal purposes. I am in the process of figuring a way to condition the signal electrically to use the full ADC range but in parallel i am starting some experiments reading audio from the ADC.

With my rudimentary programming knowledge i tried to read trough the code and examples of libltc but there are some things i couldnt really get. For example:

• What is the minimum sample number that libltc needs to be fed to read a timecode? (i guess it depends on the FPS and Samplerate as well, so lets assume 25fps @ 44.1khz). Wouldnt be as easy as 44100/25, or is it, 1764 samples? If so, the longest buffer that would be required to read timecode would be that for [email protected], so 1840 samples (rounded)?

• Timing question: I have a #DS3231 TXCO module connected to the Teensy, the ultimate goal is to "discipline" this from a GPS signal for TC Generation or to sync it to the incoming Timecode Signal for freerun operation. If i can have a time source more precise than seconds (i.e. the DS3231 has a 32khz and a frequency configurable squarewave output, i.e. 1024hz) ... can i libltc make use of that - or would it not be of any advantage anyways?

• Clipping: Given the amount of output signals that one might encounter for TC Input (headphone level, -10db level, +4db level) i wonder how complicated the condition circuit needs to be. i was considering to use some auto gain to raise everything to 5v peak-to-peak (also to have a common voltage bias i can predict and move) and then bring it down to reasonable ADC levels. But i am just wondering: given the nature of the SMPTE signal, i guess that timecode signal is pretty solid even when clipping, right?

Cheers,
T.

[x42]

What is the minimum sample number that libltc needs to be fed to read a timecode?

One complete LTC frame, sync-word to sync-word. Worst case sample-count is 2 * sample_rate / fps, best case sample_rate / fps.

Clipping...

If clipping just rails the signal to min/max without further artifacts, then yes it'll work. Even though SMPTE-spec has speficied rise-times, the LTC is just a square wave after all.

The analog input stage can indeed be crude. If you don't need to be compliant with any regulations, just a resistor to GND before the ADC can do the trick (I did that with an Arduino for a test-setup).

Regarding bias: Internally libltc has a crude HPF to track DC offsets, if any.

As for the timing question. libltc is only concerned with en/decoding timecode. The problem boils down to synchronize the TimeCode Module with your DAC. An LTC frame has 80 bits, e.g. 30 [fps] * 80 [bits/f] = 2400 bits per second. You need at least twice that as sample-rate for the DAC. but 8kHz or more is highly recommended.

1. receive time from GPS, convert to timecode "now = HH:MM:SS:FF"
2. add 1 frame HH:MM:SS:(FF+1)
3. encode this frame to audio using LTC using sample-rate SR
4. start playing the audio using the sample-rate SR
5. when the data is played back, exactly "1 frame" worth of time has passed (assuming the DAC is clocked by the GPS).
6. jump to (2) -- no need to query GPS again

If you cannot clock the DAC using GPS, some adaptive re-sampling or a PLL is needed.