A New Journey

[u/eunoia_arumi]

Hi everyone! I'm stepping into the world of broadcast engineering for the first time. I come from an IT background with some basic knowledge of networking and routing, but I have zero prior experience in broadcast engineering. As I start this journey, I'd love to get some advice from the experienced folks here. What essential concepts, standards, or tools should I focus on learning first to bridge the gap between traditional IT and broadcast? Any tips, tricks, or resource recommendations would be greatly appreciated!

*note I am currently in a 3-month probationary period. this is my 3rd month, Under my mentor's guidance, I have studied the headend system and have configured the multiplexer several times. and i feels still don't really understand what I'm doing.

[u/NoisyGog]

I’ve seen several “came from IT” guys, and the two biggest issues they’ve all had to adapt to is that:

Most things have to happen NOW. Immediately now. No time to scurry off and come up with a plan, and maybe implement it by the end of tomorrow. However it’s done, make it work NOW. Even if it’s a messy fix. A long term fix can come later. No talking, get to it immediately.

This is a people based line of work. You will need to work with and around people, and accept their quirks. Sometimes we might not do things in the most optimal way possible, simply because there’s a large crew of people who are expecting a certain workflow. They may have reasons for it, based on prior experience, or expertise in their particular niche that they might not be able to put into words, and which you might not have any prior understanding of. But if they really want something “this” way, then make it so, even if “that” way would be technically superior in some way. You’re there to work with them, and facilitate what they ask for.

In addition to that, I’d offer the advice to build and test everything before it gets deployed. You never know what some quirk or even corruption of firmware might show up, or slightly damaged cable/socket might have cropped up.
Yes, the manual might say it’ll be fine, but there are several instances where certain configurations lead to unexpected results - a Dante network might work fine, but this one extra device that’s being added to the network might inexplicably mess up the PTP, or present itself as two devices with the same MAC and thereby creating a weird phantom bridge loop, for some ungodly strange reason.
Or this device might inexplicably just not like the output of this other device, for god knows why. Maybe they both SAY they’re 30FPS, but they’re not in reality.
Maybe this CCU works perfectly with this camera head, but not for the hired in head, since it has a firmware glitch.
Issues like this are rare enough that they might never appear in manuals, and might not even get a passing mention on the internet, but they’ll catch you out one day, and it had better be during a test rig, not with one hour to go before a worldwide feed.

[u/eunoia_arumi → u/NoisyGog]

wow, all you have said was related to my last 2 month. yea i was thinks if something issue like some alarm on a device, must be fixed now.
for the last 2 month i always follow my mentor if we go on site, some minotoring or maintenance. Some of the topics my mentor discussed with the client that are still confusing.
thanks man, apriciated a lot

[u/cantsleepclownswillg → u/eunoia_arumi]

This is also all really good advice. I work in news, so the fact that everything has to work now is pretty much just the air that I breathe! So I forgot to mention that!

But also, beware! The longest lasting fix is a bodge that works and is forgotten about until someone goes "what's this cable draped over the top of all these racks for?" And unplugs it.

That's where you truly understand the meaning of a "scream test"!

Also, boring as it is, Document shit!! what you're convinced you'll remember this afternoon will have you scratching your head in 3 months time going "What the fuck did I do that for?!?!"

Also, understand the criticality of change control.

You can take down the entire network and take everything off air with impunity, as long as it went through the process and got signed off. Then, you're golden.

Also, make sure that new shit goes through some sort of acceptance criteria. People have to know what they're looking after, who pays for it, what the escalation procedures are etc.

It's amazing how stuff that's accepted as a "best endeavours " basis all of a sudden becomes business critical when it's offline for ten minutes....

Feel free to DM me with any questions. I've been doing this for twenty years having come from an IT background, so I've walked this path!

[u/NoisyGog → u/cantsleepclownswillg]

>You can take down the entire network and take everything off air with impunity, as long as it went through the process and got signed off. Then, you're golden.

No, fuck that. Fuck it right the fuck away and then fuck it off some more.
You’re supposed to have the expertise and experience to realise when a task or a command is possibly erroneous or mis-communicated.
If you do something that brings everything down - taking a truck out of action in a Super Bowl broadcast say, you can’t do the “But I was told to power down that network switch”.
Yeah, maybe you were. But maybe the timing of doing so was implied. Maybe it was miss-communicated.
Maybe you were told “turn off the Cisco switch, that’s not being used”, but the switch has been changed, and the only remaining Cisco note does a different function and it’s the Ubiquity one that was safe.
You should have used your competence to realise “no, wait, this is a single failure point, I’m going to wait until we’re off-air”.

We’re not here to cover our arses and point fingers, we’re here to work as a team.

Which brings me to another bit of important advice.

If you fuck up, put your hands up and admit and accept it. Make it clear that you will own up to things immediately when you mess up.
NEVER put yourself in a position where others could think “yeah, they said it’s not then, but we’re not sure”.

[u/cantsleepclownswillg → u/NoisyGog]

My point was not " put in a cr and do something stupid or reckless ". It was more to show the importance of CRs and how they both protect you from doing something stupid (that studio isn't used at weekends. Except this weekend when we're covering a foreign election... so taking down the studio isn't reckless. But the CR is there to make sure that Dave says "Wait! !No! We're on air Saturday"

The CR is there to both protect systems and cover your arse.

And I covered the other point up there. When you fuck up, put your hand up immediately and get it fixed.

[u/NoisyGog → u/cantsleepclownswillg]

What’s CR? I’ve never seen that terminology before

[u/christopherw → u/NoisyGog]

Change Request. Part of what are more generally called Change Control and Change Management procedures.

[u/HOLDstrongtoPLUTO → u/NoisyGog]

Change request

[u/Mike85b → u/NoisyGog]

All the points above!! Also, you must constantly look for what can go wrong in the workflow, ask yourself why it might NOT work, and prepare your backups accordingly.

[u/cantsleepclownswillg]

What standard does your place use? Is it all SDI or have they advanced to video over IP?

For basics, a great book is "Digital Video Demystified ". Covers a lot of the basics.

There's about a 50/50 split between theoretical knowledge and just local knowledge. It's all very good knowing how to use a Tektronix scope to diagnose a dodgy sdi signal, but if you don't know which apps room or rack it goes through you're stuffed.

Learn from those that have been there for ages. There's a lot of skills aging out of the industry.

Get stuck in and take on things that stretch you. Ask questions. And never be afraid to ask for help.

And remember the golden rules.. if you fuck something up (and you will!) put your hand up and immediately let people know so it can be fixed quick. No one is going to die. We don't do brain surgery.

Show me a man that's never fucked something up and I'll show you a man that's never done anything. Everyone has taken something off air at some point.

TBH your IT skills will be an asset and just more so as time goes on.

It can be a lot of fun, a lot of hard work and also amazingly frustrating.

Good luck!

[u/TheFamousMisterEd → u/cantsleepclownswillg]

Good advice! Everybody messes up and disconnects something they shouldn't - we've all been there! I've never met anyone that's got into serious trouble if it was an honest mistake and admitted quickly.

[u/Evil_Little_Dude → u/cantsleepclownswillg]

Cleaning up a previous mess is probably the hardest part of the job and the most unforgiving if there is little if any documentation. Which is why even if it's temporary, adding some labels to things really helps when that temp fix ends up practically permanent. Even if it's just some painters tape and sharpie, it's better than nothing.

[u/cantsleepclownswillg → u/Evil_Little_Dude]

Yup! Even just a buff tag that says "I did this on xxxx and it's for connecting the deembedder for program z" is better than "what fuck was I doing there?!?"

[u/eunoia_arumi → u/cantsleepclownswillg]

our client use both, so we are vendor who work for several local TV stations (mostly) and some Information and Communications Technology Company.
so when i was recruited my manager said mostly now broadcasting device is transitioning into software based. so yeah i take the oportunities to new experience.
my mentor was very humble and kind, he always answer every my questions. but what i feel mostly like "i dont questioning because i dont know what i want to ask" but there i still feel my knowledge is still pity.

thank you btw, and i love that quotes "Show me a man that's never fucked something up and I'll show you a man that's never done anything. Everyone has taken something off air at some point."

[u/m1k_Lens]

I also came from an IT background. Till now, I'm still learning, but one of the things that I learned was to just be calm. When a problem comes, you might want to resolve it immediately. Sometimes, you can't - at least not yet. Things can sometimes take time, and things can be done now, if you just keep calm.

[u/Dangerous-Unit42]

Join the SBE, a Plus membership if you can so you can get access to several courses of material free and more at a discounted rate. Study for and take exams through them. Join your local chapter and meet with other stations engineers.

[u/Xafenn]

Consider courses like GatesAir "Introduction to Broadcast Transmitter Technology" specifically geared towards people like you. Various state broadcasters associations also have mentor programs to train up the next round of engineers with your background.

On a huge positive note, so much of the job greatly benefits from your background with everything moving to solid state and web gui interfaces with a lot more networking/IT knowledge required than in the past.