LTC reading from a raspberry pi?

[Neil Bliss]

Have any of you fine folks tried reading LTC from a raspberry pi?  I'm mildly curious to see if I could make a timecode display driven by a Nanolockit.

[Bouke]

Have never worked with it, but since it's able to run Python, my code 'should' run on it.
But why the hassle? Get a tablet running Win10 and run this:
LTC reader

It can act like a smart slate (Play clap sound and freeze display.)

 

 

[Display Name]

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.

[Dalton Patterson]

I was just making a trrs cable, it needs to be padded down to mic level

[Allen Rowand]

Haven't done it, but I've thought about it. Found this in my research:

 

http://www.raspberrypi-dmx.org/orange-pi-smpte-timecode-ltc-reader-converter

[Dalton Patterson]

Bouke on the code, Neil on the design/concept, Allen on the case/chassis, I’m on the cables. Display does the beta test. 
 

Anyone else wanna make a prototype? 

I suggest adding in a way to check frames and sync. 

[James Bull]

I recently came across this:

 

https://github.com/martim01/pam

 

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.

 

James

[Riley McCullagh]

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:

https://github.com/FrankBoesing/LinearTimecode-Decoder
https://0110.be/posts/LTC_-_SMPTE_Decoder_on_Teensy

 

would then be easy to outputbto one of these:

 

https://core-electronics.com.au/gravity-8-digital-led-segment-display-module-red.html?utm_source=google_shopping&gclid=Cj0KCQjw_dWGBhDAARIsAMcYuJxotl_6SXlm8klcWeddKJa-Xs7MdwfT0HCEhnYsP5Pl5oq83kAYy70aAmk5EALw_wcB

[Bouke]

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.

 

[Riley McCullagh]

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!

[Bouke]

13 hours ago, Riley McCullagh said:

But I’m just a dabbler in hardware!

 

And I'm not 🙂

 

 

[AoteaRohan]

Hi @Bouke What hardware do you recommend to get the most frame-accurate display of LTC using your app?  2nd priority is portability.  Is it a Windows 10 tablet that you recommend earlier in this thread?

[Bouke]

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.

 

hth,
Bouke