Blackmagic Forum

I found out something new yesterday. As part of most mini-rigs I've been a part of building (4-12U), we've put in an Apple Airport Express to do service as a router to interface with the local LAN/WAN on location. In one of these rigs, we've been getting reports of blinking inputs during production, and so we thought "oh, are they using too long/bad cables, are they using cheap cameras with bad SDI outputs, +++", the whole spiel.

Every component of the system checked out fine individually though, including having BMD check out the switcher and us verifying the cables with a known good system.

After some serious fault finding when the system finally ended up in our hands, it seems the issue is related to the use of fairly long (but within spec!) cables, and keeping the Apple Airport too close to the mixer.

Typical symptoms are heavy blinking of an input signal and popping and peaking on the audio line of that input, in time with Wi-Fi usage. Connecting a new laptop to the wifi, for instance, made the blinking occur extremely often.

We pulled power to every unit in the rack individually, and when the Airport was out, the signal became rock solid. As such, I guess the added EMI of Wi-Fi decreased the noise margin of the input chips to be just too bad.

Just a hint for the other system integrators out there

We're also doing this in several systems with an old 1M/E, where we've registered no problems, so I guess this is more apparent in the newer units.

I’m going to check into this with my racks. Very typical to have a Airport or some kind of WiFi router on top of my engineering racks out on shows.

If the quality of the signal is already bad becaus of long cables, any kind of radio signal can make the last step from working to not working. I had the same problem with a walkie talkie. every time i used it, I lost the signal, but only the channel with the longest cable.
2 metres away there werent any problems.

"me too": problem with walkie talkies...but only with one make/model (Cobra); Midland G5XT talkies no problem; both regular PMR but wireless spectrum analyzer revealed a much narrower bandwidth utilization on the Midlands...Cobra obviously uses cheaper filters.

Markus Leodolter wrote:If the quality of the signal is already bad because of long cables, any kind of radio signal can make the last step from working to not working.

Is there any way to avoid this? We tape football games with a 3 camera set-up (20-100ft coax cables to ATEM switcher). Sometimes coaches use a Hudl video system that apparently uses a really strong signal and as soon as that's turned on our video from the cameras drop in and out. Prior to that being turned on everything works fine. I'm wondering if maybe a better shielded cable might mitigate this. Thinking of trying Belden cables (4794R) because I don't think that the cables that we are using are properly shielded (I asked for Belden, person purchases other cables because they were cheaper, but they don't work).

Thanks

Thanks for sharing the issue.
I was planning to install small network router/switch into my rack in order to connect different BMD devices to one laptop. I guess I should run few test, before working on field.
Can you see the drops very clear?

btw, I use 4 100-meter camera cables (Belden 1855ENH) and didn't have problems with them so far.

Alexander Kinov wrote:Thanks for sharing the issue.
I was planning to install small network router/switch into my rack in order to connect different BMD devices to one laptop. I guess I should run few test, before working on field.
Can you see the drops very clear?

btw, I use 4 100-meter camera cables (Belden 1855ENH) and didn't have problems with them so far.

Yes, the drops are _very_ noticeable. If it flickers, it's not usable. One workaround is to turn the Airport Express on it's side - it seems to have a very directional radiation pattern.

40cm in the air was far enough away for us to remove all flickering with 100m cables.

Asgeir Hustad wrote:Yes, the drops are _very_ noticeable. If it flickers, it's not usable. One workaround is to turn the Airport Express on it's side - it seems to have a very directional radiation pattern.

40cm in the air was far enough away for us to remove all flickering with 100m cables.

Thanks!

In general I found that the newer ATEM models (the 4k ones) are more sensitive to long cables or bad signals. This could be due to the fact that they are able to do 4k on their SDI inputs which need higher bandwith and therefore higher frequencies.

The solution is to use good shielded cables that are certified for HD, 3G, 6G or even 12G SDI signals. If you use standard RG59 or cheap home depot cable, you will get all kinds of problems. There is a reason why dedicated SDI cables are way more expensive.

Cheers

Robert

guys just curious here what the purpose of the router is in regards to the atem or the rack for that matter ???

simple network switch and static addresses is significantly better practice

if you need a device connected via wifi we use a poe injector in the rack and an external access point typically ubiquity

so it's 1 cable to both send signal and power and you can remote the access point to an ideal location to both service a large area and dissipate rf levels in the rack.

How to avoid dropouts? User shorter cables, user better cables, reclock your signal in the middle (bm micro converter can do this job), put your wifi router two metres away from your atem.

Brian Hancock wrote:guys just curious here what the purpose of the router is in regards to the atem or the rack for that matter ???

simple network switch and static addresses is significantly better practice

if you need a device connected via wifi we use a poe injector in the rack and an external access point typically ubiquity

so it's 1 cable to both send signal and power and you can remote the access point to an ideal location to both service a large area and dissipate rf levels in the rack.

This is extremely compact racks, about 8-10RU, where the router is used as the gateway to the local house network for streaming purposes. The Wi-Fi-part of it is not really in use, which was why this issue wasn't discovered during testing. Of course, we're on static IP, running NAT between any external network.