We've run into a little bit of a conundrum here at work. We're still going to do more testing, and I'm sure we'll be able to figure it out, but I thought I'd ask here to see if anyone has experienced something similar.

The overall test was for a multi-camera shoot using a SONY EX3 XD camera and a Canon 5D DSLR. The EX3 was feeding timecode wirelessly to a Zaxcom Deva 5.8, which is jamming continuously in Auto-Load mode (automatically starts running as soon as time code starts running at the camera). We were also using a Denecke TS-C slate which was hard cabled to the time code output of the Deva. Of course, the Deva was time code stamping all of the audio.

One of the issues is that we only had one semi-useful shot from the EX3 with the slate (it wasn't facing the camera, but at least was in frame), but this made sense as we were trying to give the 5D a valid sync point (since it doesn't generate time code when it takes video).

The recorder was definitely at least 1 frame behind the EX3, maybe 2. Again, wasn't on axis, so I'm not 100%, but am fairly confident it's only 1. I can see the wireless introducing this, but it's not supposed to. Definitely more testing there.

The slate was definitely 2 frames behind the Deva. We had the close of the sticks from the 5D to match with the timestamped waveform.

So there's the initial problem. It's the first encounter. So, I already plan to do more and far more rigorous testing. We also need to test our Sound Devices 744T in the same workflow; so, hopefully that will offer up additional useful data in the experiments. In the meantime, I thought I would appeal to the collective wisdom here. I'll of course share any and all results I think might be useful to others as well.

First nugget - avoid workflows with a DSLR. They're a pain in the butt.

  • Making some progress. Turns out those people telling me that time code slates have an offset (or delay) was correct. I've discovered that our slate has a "Plus 1 Frame" mode to account for that, so we've got another round of tests coming up with this function enabled. Commented Jul 27, 2010 at 18:31

4 Answers 4


You're sure that all of your frame rates were set properly? I know, stupid question, but I have to ask...

I've never had a problem syncing an EX3 to a Deva (I use the Deva 5, not the 5.8), but I've also never done it wirelessly. You wouldn't think the wireless would introduce that, but I can see why you might be concerned about it. What was the model of the wireless?

Being hard wired to the slate and being off leads me to believe that either you missed a setting on one of the devices or that your slate battery was less than optimal. Were you running on fresh batts?

Time code, no matter how much I learn about it, constantly frustrates me to no end. So many different standards and different ways to do things!

BTW, I've always noticed a bit of a drift problem with those Canons. Not sure why, but I agree, they're a pain...

  • Time Code rates matched, I made sure to verify that. I had considered the battery issue with the slate (yet another reason why I'm going to do more tests). The wireless transmission is a Horita WTS100M, at least that's how they were listed when we ordered them (turns out they just send you a pair of wireless Azden beltpacks). We've only used the wireless thing one other time so far, but I think it worked then. Of course, we weren't using a slate then either; and were using the 744T. Commented Jul 22, 2010 at 20:55

are there any tutorials out there on how to sync time code from a 744t to a slate? Also, is there any benefit to using a 744t with a slate running time code over a zoom H4n with regular slate if the camera is a Canon DSLR?

  • This is part of what we're testing. I've been getting reports from other sources that a slate is ALWAYS going to have some time code offset (supposedly it requires at least 1 frame to acquire), which TECHNICALLY is ok; as long as the offset remains consistent. As for getting the connection, it's as simple as connecting the slate to the timecode output of the 744T (if you like, I can put something together on my website...let me know). There is an advantage with the timecode over not on the DSLR, you'll have a time code stamp in the audio. So, you can sync anywhere before the slate is clapped Commented Jul 26, 2010 at 11:56
  • yes please put something on your site, that would be great.
    – Eric
    Commented Jul 26, 2010 at 23:08
  • @Eric - Will do, it may not be until tomorrow (7/28) though. My wife has me going to a basball game tonight. lol Commented Jul 27, 2010 at 11:18
  • enjoy & thanks Shaun, also what are the outputs to IFB's please.
    – Eric
    Commented Jul 27, 2010 at 15:57
  • @Eric - I had some time at the end of my work day here, so I spent that writing up a little guide. It's here dynamicinterference.com/2010/07/27/jamming-a-slate-to-the-744t . I've still got a few more elements that I want to confirm through testing, but that's for info that I'll add in the future. Also, we're not using IFB systems in production. We've already got too much gear for the size of our crew. lol. If you just meant where are the outputs, there are AES (BNC) and PCM (TA3) on the right and left panels of the 744T respectively. Commented Jul 27, 2010 at 19:15

So, here are a few things I've learned in the process of testing this workflow:

  1. Yes, time code slates do have an offset. The Denecke TS-C has a nice feature called "Plus 1 Frame Reader" which can counteract this offset.
  2. Daisy chaining time code through a recorder doesn't appear to affect the time code running to the slate (read - doesn't further offset timecode).
  3. The Deva 5.8's auto-load feature does something a little funny to the time stamp of the audio file, and the audio file will end up 1 frame early (even with the pre-record function turned off). There are a number of other, and better reasons, why I'm not going to use the feature though.
  4. The Sony EX3 has some wishy-washy time code stamping. Well, not wishy-washy, but somewhere in the neighborhood a one frame offset between digitization and file stamping. That, of course, affects the time code being output from the camera.
  5. Don't let non-technical coworkers near your bulk battery bin. While I can commend people's effort to be green and not waste slightly used batteries, they screw up my tests. ;)
  6. I've mentioned it before, but try to avoid workflows involving the 5D when possible (at least until it has its own time code functions).

Let me know if there are any other questions or clarifications that might be useful for anyone, and I'll address them the best I can.

Thanks for all of the help and earlier feedback too.


I just came across this post and figured I would throw in my two cents. In regards to transmission delay with wireless units: Analog wireless devices have no delay but digital devices do. My Zaxcom 900 series wireless units have a 1.5ms delay; it's just part of the reality.
My setup for time code is a Sound Devices 744t with time code output to a Sony UWP transmitter which has two receivers. One receiver is strapped to the back of my Denecke TS-3 time code slate and the other receiver is intended for whatever camera we're shooting with (assuming it has time code in/out capabilities). So, this ensures all devices are time code locked constantly (assuming the AC pays attention to the batteries on the camera receiver:)

I recently picked up the TS-3 slate so I have not had a chance to sit with an editor and check time code offset; I'll definitely do that soon. This is the first I've heard of a TC slate having an offset but, then again, I never really looked in to it.

Regarding the EX3: I've done a number of shoots with the EX3 and have frequently run in to time code issues with them. There is something about those cameras and their TC capabilities that I just don't trust. I've seen their time code jump around erratically, I've seen them completely lose sync, and I've seen them not receive a perfectly good time code in signal. Every once in a while they work. :)

One thing to check with various cameras is displayed time code on the video monitor vs. actual time code being recorded. The RED camera, for example, displays 1 frame behind actual time code being recorded (unless that has been fixed in a recent firmware upgrade). So...perhaps there is something similar going on with the EX3?

I completely agree with the work flow of a DSLR camera. They are nifty in the fact that they shoot video with swappable lenses (for the price point) but the lack of time code, the highly compressed video image, the heat issues, and the myriad of other real-world issues makes them a very risky option on location.

  • yeah, i've since learned that a LOT of cameras have a time code offset. it has to do with when they resolve the scan lines into a "frame" of data vs. the actual running of the time code. it's amazing that they get away with this crap on such a regular basis. Commented Nov 1, 2010 at 11:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.