SOMETHING NEW … COMING SOON … FROM THE FACTORY
That’s right – very soon, we will be able to reveal to you our very latest production tool – created on demand. It is called QuickTC and, it’s all about ‘that timecode stuff …’
As always, there will be Fact Sheets, specs, and information on where to buy (all the usual) but for now, you will have to be satisfied with the gibberish below … tech talk from the Engineering Department … trying to be meaningful and relevant in the world of Tweeting … good thing there is a restricted word count rule at Twitter! Well, we are sure they will find a way to get around that one (!) … so, please enjoy the first glimpse of “QuickTC” as you read its first White Paper … even though it’s not white and it isn’t printed on paper … Stand by for everything you need to know (right now, anyway) about “QuickTC” …
What’s all this timecode stuff, anyhow?
You may have seen it used for synchronizing audio with video. Perhaps you jammed it for multi-camera shoots. Or just set the camera to free-run from internal generation. Maybe you’ve seen it being fed into a multitude of devices on a virtual production? You may know timecode from the SMPTE ST 12-1:2014 spec, which tells us it’s a Manchester biphase encoded audio signal- yeah, who has time to read those things?
Timecode is ubiquitous whenever you have multiple devices that need to be synchronized on a time of capture basis. Different from genlock/sync, which only provides the timing pulse, timecode will provide you with time of day, or some random clock time that is coming from your master clock.
Time of day is possible, if your master clock is tied to GPS or maybe you have a way to connect to the NIST F1 atomic clock, thru things like NTP. In any case, timecode is a way to get you reference time, in hours, minutes, seconds and frames. Assuming you configure your timecode generator to match your video frame rate and your frame rate happens to be less than 30. If you are shooting more than 30 frames per second, well, you will get double stamped timecode on your captures or your system can recognize the higher frame rate and will recount it for you, for example turning 0-24 into 0-49 for 50 hz video.
We work with it all the time. The truth is, it’s a pain and a risk to use. A timecode clock generator can have lots of options (most don’t):
- Frame rate (23.98, 24, 25, 29.97 or 30)
- Time source
- Time of Day
- GPS
- NTP
- IEEE1588 PTP to your local grandmaster clock
- Sundial?
- Free Run
- User sets it to their watch
- Device sets time to be random (midnight) just after powering up
- Device has a real time clock and maintains time with a drifty clock
- Time of Day
- Drop Frame or Non Drop Frame
- Output signal voltage levels
- An analog signal output of +4dBm to +8dBm at 600Ω drive impedance is SMPTE spec
After that, you might have equipment that allows you to fan-out the signal from your generator and more equipment that helps distribute the signal everywhere. You might be adding distribution amplifiers (D/As), range extenders, fiber optic systems, RF (ACL) and tin-can phonic communication system.
Now, did I mention that timecode is an analog signal?
Perhaps you are of the mindset that everything is analog. If you think digital is just clipped analog, you wouldn’t be wrong. But analog signals are suspect to lots of influence as it passes thru cables and devices.
- Noise – it’s everywhere
- Level change (who messed with the gain trim on the analog D/A?)
- Reclocking – turning those nice low-pass filtered audio-friendly waveforms into hard edge square waves, with those nasty high frequency oscillations on the sharp edges
So, by the time you get a signal on the end of a cable, it can be distorted to the point where the device is not happy with the signal. Or worse, it works for a while, then stops, then works. Now you find yourself with one device that is not happy while the others seem to be OK.
Or maybe it’s coming in clean, but one or two frames late. Did someone embed the timecode into the audio feed, then run it through a frame shaker and de-embedded it? It could happen.
Generally, timecode is robust and fairly reliable, and it works, until it doesn’t. At which point you need to do some timecode debugging …
So … where do you begin?
Typically, you start at the source (timecode generator) and work your way to the device that is being fed timecode. Then what? Look at the cables, are they plugged in. Do you have a bad cable? You can’t tell by looking at it before just swapping it out? Does anyone on the show have an oscilloscope and know how to use it? Maybe the DIT or AC has a mobile oscilloscope that connects to their iPhone, just in case something like this pops up. They haven’t used it since they bought it, need to download the app, re-read the instructions. But they are super-excited to have the opportunity to try it out. And when it’s working, you might see a waveform but do you have any idea what is considered good or bad by looking at it? Chances are, you won’t recognize the problem. And you certainly can’t discern what in the heck the bits are telling you.
This is where “QuickTC” comes in. It’s a simple go/no go tester for timecode. It’s small enough to fit on your keychain. It is powered by a rechargeable battery which plugs into USB-C for charging. It is always ready to plug into your BNC and tell you what’s coming in. It will not only read-out the timecode, but it will also let you freeze it momentarily as you read it out. Additionally, it will provide a 1hz LED blink at :00 frames, allowing you to look across the stage and see all cameras blinking in perfect sync. It will tell you what the signal voltage levels are and the timecode format, including DROP FRAME.
It will even readout the userbits.
It pretty much does everything – except drive Uber … you’ll have to arrange for your own ride back to the airport … and stop along the way to grab something to eat … because “QuickTC” won’t buy your food for you either … but it’ll do just about everything else …
