Constellation and Timecode

I'm not seeing accommodations for timecode embedding on the back of the Constellation mainframe like other ATEMs have. I'm assuming timecode embedding has been dropped for this model?

Correct. You can't jam sync timecode to it, which is a bit unfortunate.

It generates its own internal timecode and embeds that on all of the SDI outputs. Cameras like the Ursa Mini Pro (and soon the Ursa Broadcast — once the new firmware update comes out) can pick that timecode up and sync to it from their SDI inputs.

This is pretty slick overall when you've got all Ursas, as you were likely already running a second SDI (or fiber) to the camera for paint and tally. Now you've also got synced timecode for your switcher and cameras with zero extra effort.

When dealing with non-Ursas (or audio recorders, etc.), the Teranex Mini SDI to Audio (or SDI to HDMI, or SDI to Analog) has a feature to output the SDI timecode as LTC via XLR. And from there you can jam sync Tentacles or audio recorders or whatever.

I've tested this and it works reasonably well for my situation — it just requires a bit of a paradigm shift to consider the ATEM to be the timecode master for your production. Obviously this won't work for larger facilities or multiple switchers.

You can set the timecode in the GUI (to the second... which is close enough for roughly time-of-day, but not really close enough to be considered a jam sync). Also, there's no option to specify drop or non-drop, so it does drop for the 29.97-ish timecodes and non-drop for everything else.

With this tool ( Windows only) from Ian Morrish you can set the PC time as timecode source without you need it to punch it in. https://ianmorrish.wordpress.com/2019/0 ... o-pc-time/

But yes i would like to see that BMD would allow for the Analog input to be set as TimeCode input.
This would be very usefull for all those broadcast setups were we have to deal with external timecode/Tri-level sync generators as often in broadcast you need to sync to an external source.

Ans since you can have all audio by Madi now. It makes sense you can choose to set the Audio in as TC source.

While you can set the timecode of the ATEM using the ATEM SDK the ATEM Software Control Panel (on ATEM firmware version 8.0 or higher), setting the timecode this way is not as accurate as a true jam sync. The generated timecode tends to be off by as much as a second from the start time entered. So it isn't anywhere near accurate enough to do frame level matching of different sources.

I was hoping that even if the ATEM Constellation couldn't read continuous timecode, it would be possible to do a software jam sync of the ATEM via the SDK. So you could use an audio input of the computer to read LTC timecode and use it to do a onetime sync of the ATEM's internal timecode generator. And then depending on the accuracy of the internal timecode generator it could easily be several hours before there is a frame of drift.

Unfortunately setting the ATEM timecode via the SDK doesn't seem to be quick enough to make this work, as the initial sync right after setting the timecode is off by a variable amount, for reasons that are unclear. More on that here:
viewtopic.php?f=4&t=92836

I really wish they would allow using one of the audio inputs as a timecode source. This would be useful on all of the ATEM models that lack dedicated timecode inputs, not just the Constellation.

Yes i wish it would do TC in by audio input.

I dont see it happen unfortunately that all atems will get that option in the future Something to do with processing time and not sure how much they will go back on the atems to implement.
And if so. What to do with the 2ME and 4ME? Because they have TC IN and OUT. Which is very usefull in our production. So i dont understand WHY a beast like the Constelation, Which is our next Go to mixer for our OBV does not have it. 1 of the biggest main mixers in the lineup, the mixer that is MOST likely to be used in big OBV's studio's and bigger live broadcast gigs..

But yes it would be cool.

It boggles my mind why its 2022 and this is still not addressed?!?!?
Take TC on an SDI input or analogue please!? Come on BMD....

Yeah me too.. It's pretty fckd up as bigger productions it is a MUST instead of nice to have to sync to an external TC source.

I still love my 4ME Broadcast for it to have TC input.. And Some jobs we switch the Constellation out to our trusty old 4ME just because of the TC in..


I mean even if they would allow TC on the analog inputs.. That would be a live saver.. I mean TC is Audio.. And i can always input audio on Madi or SDI towards the mixer..

I would love TC on the Constellation, but I use the analog inputs...so I second the idea of using TC from an SDI source. I've just learned to "bypass" the switcher for all TC needs, going LTC direct to recorders and such. It's a shame.

Well Ben, Using audio from an SDI source would make up for a much cleaner better audio then from the analog inputs of the Constellation..

We compared the Audio from digital embedded and Analog and the Analog input stage of the Constellation and other Atem mixers is not really good with music..

So i would not mind to have the analog inputs be able to run TC.. Especially as TC embedded on SDI isnt audio.. So getting it from a TC source to Embedded TC in SDI would require an expensive converter.

Interesting! Tell me more. I mostly do music production, and this would be a big help to know the best way to mux the audio in the switcher (Audio to SDI converters?). Thanks!

Well our Audio tech did a comparison between analog audio, madi audio and Embedded by SDI.

He says the Analog inputs really lack bandwidth.. The bass is not as powerfull and there is a drop out in the high tones.. ( as we do Concert multicams with a lot of BASS, it's pretty important that the bass sounds strong and not weak.. )

Keep in mind they use a pretty mass production AD codec which is OK but not really optimized at all for quality audio ingest.

The best performance was trough Madi. As he almost had no difference between what was going out from his mix. And what came back after the Atem as PGM feed.

Thanks very much! The venue I work with most uses MADI, but at 96kHz. So it won't work with the Constellation. And as far as I have been able to tell there is no format converter to go from 96kHz to 48kHz. RME says they do not make such a thing. So I guess I'd have to buy a board like a SQ5 with the MADI card just to translate. I really wish BMD would just accept all flavors of MADI, but like all the other issues, I'm not going to hold my breath.

Thanks very much! The venue I work with most uses MADI, but at 96kHz. So it won't work with the Constellation. And as far as I have been able to tell there is no format converter to go from 96kHz to 48kHz. RME says they do not make such a thing. So I guess I'd have to buy a board like a SQ5 with the MADI card just to translate. I really wish BMD would just accept all flavors of MADI, but like all the other issues, I'm not going to hold my breath.

48 kHz is pretty standard for video applications, so I kind of understand that limitation. Even some of the newer audio for video formats like Dolby Atmos are still 24-bit @ 48 kHz. So I'd much rather that they worked on improving the ATEM multi-channel audio routing or timecode support personally, but that's just me.

In terms of sample rate converters, RME used to make the ADI-192 DD, but I believe it has been discontinued. And it also lacked MADI inputs and so would require converting to AES or ADAT first.

I believe the MADI-capable Appsys MVR-64 multiverter can do this kind of conversion with it's sample rate converter add-in module. Not exactly inexpensive, but a pretty flexible format converter:
https://appsys.ch/en/products/digital-f ... ter-mvr-64
https://appsys.ch/en/products/digital-f ... -in-module

Many thanks to you as well. I totally agree, I'd rather they put their efforts into SDI audio signal routing.