Jump to content

LTC reading from a raspberry pi?

Neil Bliss

Recommended Posts

Denecke's TimeCode Toolbox on iOS can display and output LTC as well as accepting input of LTC signal and display it.


I tested it on an old iPhone SE and setting TC Toolbox to output LTC and then jam the USOne worked great.

But on the SE the app did not listen to anything else but the microphone as input.


Not sure why but it should work.

Will do some more tests.


Edit: might be I need to get a trs-trrs for this.

Link to comment
Share on other sites

I recently came across this:




Seems to fit the bill, as it claims to do LTC reading and generation, via audio input hat or AES67 on .


Also has some other interesting metering stuff. I haven't made one myself, but I am tempted to give it a try - just not quite enough use for it at the moment to devote the time.



Link to comment
Share on other sites

  • 5 weeks later...

I feel there’s too much to go wrong with running an entire Linux distro just to read and decode timecode.


I have a teensy with an audio hat lying around, I’ll give it a go with one of these libraries:



would then be easy to outputbto one of these:



Link to comment
Share on other sites

3 hours ago, Riley McCullagh said:

I feel there’s too much to go wrong with running an entire Linux distro just to read and decode timecode.

You are missing a few essentials:

The 'sync word', defines the END of a frame. Thus, you only know the TC AFTER it has passed.
You can state that the sync word defines the beginning of a new frame, but that only works on continuous TC, and you still need to compensate for the duration for the sync word.
Next, there is no checksum or whatever in the bits, so you need to do a bit of error checking and freewheel a couple of frames if there is a glitch.
This all takes time that has to be compensated for to get a proper 'sync' display.
(Let alone the latency in the display, and in the audio device.)
That can all be done in (cheap) hardware, but it's not as easy as in a normal computer environment, and will only pay off on large volume production.


Link to comment
Share on other sites

Excuse my ignorance. But with known quantity near bare metal hardware you can predict the latencies of a lot of these issues surely? Such as incrementing the frame counter by 2 from incoming, and then delaying output by inverse of combined measured latency of dac + 7 segment display chips. You could also sanitise incoming against errors, comparing expected to received. Not the same as running an actual clock, but seems at least similarly reliable to an rtc in a normal computer. 
But I’m just a dabbler in hardware!

Link to comment
Share on other sites

  • 11 months later...

I don't recommend anything special, but I DO recommend you test.
Since there can be delays close to everywhere (display, incoming / sending over Tx Rx, latency of an AD converter, silence before your clap sound etc), LTC convert accepts an offset (positive and negative) for everything.

Mind you, LTC is more than frame accrate. As it has a specific start / end of the bits in one frame, its possible to sync up to some 2 milliseconds. The display / visual slate TC should be no more than a last resort.




Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...