Jump to content

Zaxcom, timecode issues...


Timlin

Recommended Posts

Hi all

 

I'm having trouble in establishing 100% confidence in how my Zax IFB100 receives TC from my 788 along with a L/R audio mix and then sends the signals to various ERXTC units.

 

When setting this system up I've been using REC/RUN TC from my 788 so I can see if/when the IFB100 senses the TC signal, jams it and starts transmitting. As soon as I hit REC I assumed that the IFB100 would jam/sync instantly and then the REC/RUN TC would be seen on both the IFB100 and therefore the ERXTC. And then when I hit STOP the TC on the 788 stops as it should, but the TC on the IFB100 and the ERXTC continues on rolling...?? They don't cut rolling TC at all, ever it seems! Until powered off anyway!

 

The assumption that the IFB100 senses the incoming TC instantly is wrong. It sometimes takes up to 2-5 minutes before it'll jam/sync with the 788 - however, in that lapsed time, its been sending a false TC as the IFB100/ERXTC never stopped rolling on the last cut - they both continued rolling from when my 788 stopped....

 

Now this is a major problem. As the IFB/ERXTC units have now been sending the WRONG TC at the start of the next roll! The units DO NOT jam/sync instantly at all - it can take MINUTES!  

 

WTF is that about??

 

So now if the job cuts & rolls often - as is often the case these days - all the transmitted TC will be out of sync with my 788 - that is until it catches up and jam/syncs in the middle of a take!

 

Won't we be popular in the post-prod departments!

 

What am I doing wrong here? Surely its some setting somewhere that I've missed...?

 

Please advise ASAP!

 

 

Rgd's

 

 

 

Andrew

Link to comment
Share on other sites

It puzzles me that they are asking for record run timecode in post with this camera set up. I could understand it with a varycam or other tape-based camera. There are a lot of shows I do that still use varycams with record run time code. But with digital media delivery, time of day all the way seems to be my experience. Did you try contacting post just to clarify why?

Ken

Link to comment
Share on other sites

Post is wrong for requesting Rec/Run Timecode.  You can't have REC/RUN timecode if you have more than a single device recording.

Since they all don't start and stop at the same exact frame unless something is set as a master and it controls the start and stop of everything else.(and that is a real crap shoot with recorders/cameras  from different manufacturers)   Otherwise you end up with overlapping time code or non-running time code which jams the other units which can't be resolved automatically in the editing process.

 

You need to use Time of DAY TC.

Link to comment
Share on other sites

I would recommend getting an RF explorer to also make sure your range isn't getting jammed by some wifi device. Just as any wireless device certain frequencies will be better than others.

Also, what tx power is the ifb set too? Range to cameras could be an issue if it's set too low. Also, check that your antenna isn't busted. I've had a problem before where the pin in the connector for the antenna got pushed in and therefor got horrible range.

If you need to reliably do TC over a long range a comtek or ifb would probably be a better choice for rec run TC

Link to comment
Share on other sites

It's pretty obvious that this is not the right toolset to do Rec/Run timecode. Post has absolutely no reason to use Rec/Run timecode, and even less reason since your equipment is not capable of meeting the request. They are shooting DSLR and should be perfectly fine taking TOD timecode. Every single dual system job I've worked with Timecode uses TOD timecode, and your editors will get along just fine. One shot with timecode that's off and they will change their request ASAP.

Link to comment
Share on other sites

Thanks guys! Issue resolved, TOD TC as audio on ch 2 and mixed guide audio on ch 1. Which is what I asked for from day 1, but theres evidently some "whiz kid" in the post department who knows everything - about everything too!

 

I'm still using V7:20 on the IFB and V1:22 on the ERX's. I'm kinda cautious about firmware updates if the kit is still working as it says on the box, but, this time its seemingly not doing that anymore, so I guess updates across the board are in order!

 

AT

Link to comment
Share on other sites

I guess thats probably the safest way, but the post house wants sound files on REC/RUN... Sadly the camera is a DSLR, which as you'd well know just adds to the problem!

 

Rec/Run timecode is very, very stupid, especially with a DSLR. These people do not know what they're doing.

 

Tell them from me the only time to use Rec/Run is with a single videotape camera shooting news or docos and if they're partying like it's 1999. It's very old-school and backwards, in my opinion. It'll also create timecode issues with file-based sound that provides pre-roll, since now you'll have duplicate timecode for the first few seconds of the new file. 

 

If they're shooting a file-based camera like a DSLR, just use time of day. And in truth, I don't know of a single DSLR that will recognize and use timecode correctly (particularly phase-locked and referenced to video), because they're toy cameras

 

Rec/Run should just die and go away. New T-Shirt!

Link to comment
Share on other sites

Timlin, I feel your pain! I've had trouble trying these kinds of setups with my Zaxcom gear too. Trying to chase a camera's REC/RUN TC for transmitter backup or TC MP3s via their IFB system. It just doesn't work like you would expect it to. I think there are some longtime bugs that never got sorted and it's no longer a priority. 

 

Odd things I've experienced when trying to use REC/RUN features with ZaxNet gear:

 

- TC stopping on the wrong numbers compared to camera

- Not chasing camera REC.

- Sometimes chasing camera REC

- Many very short clips made even though camera did one long take.

- Short static bursts at the tails of recordings made.

 

I've stopped using any of the "Auto-Load" features on my QRX, TRX, and Maxx because it just doesn't work. Maybe I've been doing something wrong all this time but it doesn't really matter now. It's too bad because it's one of the features that, on paper, seemed like it would be useful.

 

And yes, I have emailed with Zax about it.

Link to comment
Share on other sites

Timlin, I feel your pain! I've had trouble trying these kinds of setups with my Zaxcom gear too. Trying to chase a camera's REC/RUN TC for transmitter backup or TC MP3s via their IFB system. It just doesn't work like you would expect it to. I think there are some longtime bugs that never got sorted and it's no longer a priority. 

 

Odd things I've experienced when trying to use REC/RUN features with ZaxNet gear:

 

- TC stopping on the wrong numbers compared to camera

- Not chasing camera REC.

- Sometimes chasing camera REC

- Many very short clips made even though camera did one long take.

- Short static bursts at the tails of recordings made.

 

I've stopped using any of the "Auto-Load" features on my QRX, TRX, and Maxx because it just doesn't work. Maybe I've been doing something wrong all this time but it doesn't really matter now. It's too bad because it's one of the features that, on paper, seemed like it would be useful.

 

And yes, I have emailed with Zax about it.

Derek

Have you tried this recently with recent software? There were some bugs in the past that have since been sorted out 

Link to comment
Share on other sites

I've been using camera record run TC and Nomad autoload extensively and successfully with transmitted TC recently with a Sony HD 750 tape camera. The production company prefers the look of tape HD over disc HD cameras, and tape ingest into Avid with ToD or freerun timecode is problematic, hence record run specified.

 

I'm curious about Zaxcom autoload timecode stops and starts for sequential shots, where sometimes the TC jumps back, sometimes matches, and sometimes jumps forward.

On SD machines the stops and starts are always 00 frames by cleverly using preroll which is nice, but Zaxcom can't make their machines do this, and so with Nomad sequential files, matching sequential shots, sometimes the timecode jumps back by a variable number of frames, sometimes matches, and sometimes jumps forward also by a variable number of frames so then there's a gap.

 

Anyone know why this should be?

 

Example -

post-2842-0-22316800-1398981960_thumb.jp

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.

×
×
  • Create New...