Jump to content

LTC reading from a raspberry pi?


Recommended Posts

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.)

 

 

Link to comment
Share on other sites

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:

 

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

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:

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

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

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.

Guest
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.

 Share

×
×
  • Create New...