Page 1 of 1

Sync shift number incorrect?

Posted: Fri Jul 26, 2024 3:10 am
by calebstaines
Hi,

I've just entered a sync shift offset into an Alexa 35 body (on SUP 1.2.3) for a shot involving a video projector. Our project rate is 24fps and I've dialed in +400 HD lines of vertical offset. The number on the sync shift menu of the MVF says this is 228 800.000us but that can't be right, can it? Isn't 400 lines about 15 000us? Or am I misunderstanding something?

Thanks,
Caleb

Re: Sync shift number incorrect?

Posted: Mon Jul 29, 2024 3:18 pm
by Andreas Berkl
Dear Caleb,

after talking to our specialists, I can confirm you are right. The displayed units simply are nonsense. We will open a bug for this.

Thanks for bringing this to our attention and greetings to Aotearoa from
Andreas Berkl

Re: Sync shift number incorrect?

Posted: Thu Aug 01, 2024 1:31 am
by calebstaines
Hi Andreas,

Thanks for looking into it. Glad I could help in some tiny way.

I have another related question about the camera that perhaps you can help with. I don't have a good way to test this myself right now - is it possible to sync shift the sensor readout when using timecode as the genlock reference? And how accurate is using TC as a genlock reference? Does the camera actually use the external TC signal as a reference for sensor readout timing even when the camera is recording?

We have some days coming up working with a big LED screen at a location and I'm wondering if we can reliably use the Nano Lockits on camera (TC only, no trilevel sync) to genlock the camera and then provide trilevel sync to the LED processor from a trilevel-capable Lockit. All the Lockits would be slaved to the Sound Mixer's master Lockit over ACN. We can dial in a phase offset either in the LED processor or in camera (if sync shift is possible when syncing to TC) to eliminate double-exposures of the images on the wall. Does that sound like a reasonable approach or would you recommend I use trilevel sync into the cameras for this application?

I'd also love to hear from anyone else here about any experiences using TC as a genlock reference for virtual production-type situations.

Thanks (and greetings to München),
Caleb

Re: Sync shift number incorrect?

Posted: Sun Aug 18, 2024 11:13 pm
by calebstaines
I did a bit more testing of timecode as a genlock reference and thought I'd just answer some of my own questions in case anyone finds it useful.

Yes, the Sync Shift in the Alexa 35 does work when using timecode as the genlock reference. I guess the manual implies that it'll work but I wasn't 100% sure.

Using timecode (from an Ambient NanoLockit) as a genlock source seemed to keep the cameras within 1 HD line of each other which is accurate enough for me.

This last bit isn't about Alexas, it's about Lockits but maybe it'll help someone so here it is: I'd had problems in the past using a number of Lockits (204s) to keep cameras and LED processors in sync. The Lockits were supposedly keeping in sync over the ACN network with one acting as a master and the others slaved to it. But I had problems with things drifting out of sync, even when the Lockits claimed to be receiving ACN sync from the master Lockit. My testing last week turned up one Lockit (out of 5 in the kit I was using) which, while it jammed wirelessly from the master and said it was receiving the sync signal from the master, was actually drifting in relationship to the master by a line every few seconds.

So I think the Lockits are a great solution for VP applications (both the TC and trilevel outputs of each Lockit are within a line of one other) but it definitely pays to test all the units in prep with a Phabrix or something like that which can show you the phase difference between HD-SDI signals to confirm that they're all working as they're supposed to. Because it seems like they can fail without it being obvious.