Simplify Remote Testing for Remote Broadcasts
Dec 1, 2014 9:00 AM, By Doug Irwin, CPBE DRB AMD
Like many broadcast engineers, I”ve done countless remote broadcasts. I usually had an uneasy feeling right up until the time I would call the studio to make sure the remote was �coming through.� If the studio said they could hear me, I was able to relax for a bit. Otherwise, it was time to troubleshoot the problem quickly.
Back in the days when the station was staffed 24/7, there was always someone there to put the remote in cue and to listen to it as show time approached. As the years have gone by, however, there were more and more times when no one was at the other end.
Let”s talk about some ways to minimize the difficulty of testing remotes when there”s �no one home� on the far end.
This is the simplest way to carry out a remote; and the testing methods are the most simple as well. The �old school� way to test RPU shots was to hang a phone coupler on the RPU receiver audio at the studio and to leave the squelch open (or at least set to a lower threshold). Once out at the remote site, call the coupler, then minimize the noise coming out of the receiver by turning the directional antenna at the far end.
A variation: If the RPU receiver is at the transmitter site, find a signal strength indication such as receiver AGC voltage and connect that to an analog input on the remote control. Call the remote control and read the signal strength value while you adjust the antenna on the remote end.
A further variation: Build a simple voltage to frequency converter, feed it with the AGC voltage, and send the tone output to a phone coupler. As the voltage increases, make the tone frequency increase. Call the coupler from the remote end and adjust your directional antenna while listening to the pitch of the tone.
Marti portable RPU transmitter
ISDN codecs are great for many reasons, the first of which is that you can tell that the codecs are connected. However, since the transmit direction and receive direction can have different algorithms, sample rates and data rates, you can”t know for sure that anything is being heard at the far end just because you hear audio coming back to the remote site.
My old station back in New York (which was actually located in New Jersey�kind of like the Giants and Jets) had multiple ISDN codecs. One in particular rarely, if ever, was used. So, on that one I set both the appropriate receive and transmit configurations, then physically looped the audio from receive OUT to transmit IN. Thus when I was in the field, I could test my remote by connecting to that particular codec, at which point I would hear whatever audio I sent echoed right back to me. However, this wasn”t really much more than a �feel good� test because it didn”t eliminate the potential problem I mentioned: a codec mismatch. To be certain things are working requires a closer look.
Telos Zephyr XStream ISDN codec
In order to be test the system fully and make sure that a remote truly is ready to go, you need remote access to your studio rack room from the remote site. I”m not going to get in the merits of one method vs. another. They all work. Here are several options:
- � Public Internet access to a remote desktop through mechanisms such as VNC, LogMeIn or TeamViewer where you can then gain further access to devices remotely
- � Port-forwarding to the various devices from an external IP address
- � VPN access to the appropriate internal network at your facility
When my old station was consolidated with a cluster in Manhattan, a decision was made to �pool� all of the ISDN codecs. At first I objected based on previous negative experiences with this approach. However, the remote access software for the codecs worked so well that my initial concerns were rapidly forgotten. We were using a group of Telos Zephyr Xstreams, and software known as �Zephyr Remote� from Software Authority. This software allows you to see if you are truly connected on the far end, and to change the configuration if necessary.
Codec remote control software
The latest step in the evolution of remote broadcasts is the use of IP codecs. The full-duplex nature of the connection is great but again, as with ISDN, you”ll need a way to ensure that settings are matched and audio is really coming out of the codec on the far end. If you are using an IP codec, remote access shouldn”t be an issue. Most codecs have some form of web interface that you can look at to be sure that audio truly is emanating from the codec outputs on the studio end. Since the connection is via IP, you can likely also access this management interface on the far end codec from the remote site via the IP connection.
Tieline Bridge-IT IP audio codec
Irwin is RF engineer/project manager for Clear Channel Los Angeles. Contact him at [email protected].
We Need Your Tips
Tech tips may be suitable to earn SBE recertification credits. Send your tips to [email protected].