I've been tinkering around with reading SMPTE time code using the code on this topic: SMPTE timecode reader with LCD display. I have the Arduino reading the code the way I like, but I want to do something a little different now. I want to develop a SMPTE jam-sync device. Basically, I want the Arduino to read the time code, decide if the frame is valid (contains all 80 bits and has the proper sync pattern), and then regenerate the frame on an I/O pin. If the frame is invalid, the last valid frame should be sent until a new valid frame is detected. I realize that this would result in the data being one frame behind what it should be, but that's fine. Usually, SMPTE jam-sync devices don't regenerate duplicate frames, rather they continue counting up, but for my particular application, its better for duplicate frames to be made.
My questions are: How should I approach this? Should I keep using an ISR? How do I read and generate time code at the same time? If the time code slows down or speeds up a little, will the output data follow the same clock rate (I'm hoping yes)?
If anyone needs clarity, please ask, especially if you think will help me get the ball rolling on this project!
From Wikipedia it looks like the highest rate is 30 frames per second. I assume that means 30 time codes per second. If that's true then your choice makes little difference. 30 things per second comes out to about 533,333 processor clock cycles per thing; lots of processing available.
Bear in mind the author of that code makes no attempt to protect the shared data. If you choose to use an interrupt service routine you need to understand "critical sections".
Actually, the frame rate is typically 24/25/29.97/30 fps at run speed, if the code is coming in faster than that - a wide band reader will resolve as many frame/fields as it can recover from the bitstream, purely for display.
This is usually only used in spooling/shuttle - to identify the media position, and if the clock is more than (?10%) off the play speed, the data is only displayed but no comparators or other actions are executed - to avoid erroneous chase or sync attempts.
line_code:
My questions are: How should I approach this? Should I keep using an ISR? How do I read and generate time code at the same time? If the time code slows down or speeds up a little, will the output data follow the same clock rate (I'm hoping yes)?
When you say slow down or speed up are you referring to LTC generated by a VTR when your using jog/shuttle to move through material? It is difficult to have a timecode reader that can dynamically read and adjust the bit length timings to accommodate this.
I had written my own SMPTE timecode reader and started on a timecode generator as well. The reader code was finished and tested but I cannot remember the state of the generator code. The code does not set the Bi-phase mark bit so is not fully functional but you welcome to have it and expand on.
For the longer term, I’d stay with the incoming interrupt - then you can identify the average bit duration, and adjust the bit parser to match.
(This could also optionally be used to determine the ‘normal’ input framerate and remember that for the current generator session.)
For output timing, I’d stay with a constant ‘carrier’ frequency so the generated output code is ‘standard’ rate for the required frame rate.
Then the generator output only gets updated once per frame - based on the most recently decoded input time.