Hey folks! Here we are well into November, there’s snow reported in northern latitudes and at higher elevations further south and yours truly has wrapped up the 2018 convention/travel season. It’s been an incredibly busy year, I have had the opportunity to meet a lot of you in person and several more by phone or email – thank you all for your support!
As with the last issue, this will cover a couple of things that have come to mind during various site visits or conversations and emails that occurred over the past few months. Every now and then, somebody will say something that gets me thinking (at least as much as I am capable of after several months of almost continuous road time)!
First, a note about software updates. While we currently have a couple pending, it seems that more and more, I am seeing systems that are running software that is several iterations old. I cannot stress this enough – while a lot of updates are to add new features that you may not need, or to fix potential bugs with features that you do not use, we also use updates as a means of implementing improvements to equipment reliability. Back in the day, we used to send out ZipLoc™ bags with an assortment of parts and a sheet of instructions to “replace this part with that part, cut this trace, install this jumper, etc.” Today, we can frequently accomplish the same with a software upgrade – adjusting a bias level to improve amplifier reliability, increasing power supply fan speed to improve cooling, changing a protection threshold, or the like.
Also back in the day, I used to walk into the occasional transmitter site and see a cardboard box with an orderly collection of ZipLoc bags, full of field upgrades that had never been installed – this is very similar to that. From a support perspective, it can be extremely frustrating to get a call on an equipment failure, only to discover that the means to prevent that failure had been delivered months (or years) ago and never implemented!
Another thing that I continue to see a lot of is totally open and unprotected equipment – less so for our gear, but there are still a lot of codecs out there running audio sources which are using default (or no) passwords and are totally accessible to anybody with nefarious purposes. Folks, let’s get these things locked down! If I do an IoT search for Nautel, my happy day will be the day that the search returns zero results. Changing passwords from factory defaults is a good start, but if the equipment is still visible on a basic search, it is still a target for somebody to run a password cracking app and try to take over the equipment, or what airs on it.
Figure 1 – Current Software is not just about bells and whistles!
There are so many ways to “hide” equipment – at the very least, a firewall with any unused ports blocked is a requirement. For something mission critical (which in broadcast is virtually everything), the extra step should be taken and it should be hidden behind a VPN. A year or so ago, techradar (www.techradar.com) did an article about the best free VPNs. They updated that a few months ago – you can find it here. Given the availability of inexpensive, or even free, VPNs and how easy they are to configure these days, even for the technically impaired, there is really no reason to have an unprotected piece of equipment anywhere in your facility. At the very least, an audit should be done, identifying everything in the facility (studio AND transmitter site) that has an IP address, whether that piece of equipment is connected to a network and whether that network has internet access. If that risk assessment hasn’t been carried out, then it is impossible to gauge the level of risk to which you may be exposed. I think we can all agree that having a signal on the air that is NOT the signal you want to be on the air is not the best situation to be in!
Yet another item I still get a lot of calls on is RDS. A lot of folks understand that our VS Series does not (yet) generate dynamic (scrolling) RDS. However, there is a misconception here – if you have an automation system that can spit out artist and song title data, the VS transmitter can certainly put that data on the RDS display of a receiver. What it cannot do is generate a static 64 bit scrolling display internally – however, passing dynamic artist and song title is not an issue but does involve some configuration.
Figure 3 – RDS setup tab in preset menu
Figure 3 shows an example of a transmitter configured for artist and song title, generated by an external source (an automation system, in this case). The automation system needs to be configured to send the data to the transmitter, either via RS232 (serial) connection, or via an IP link over a network. In the automation system, you need to specify the transmitter IP address and the port number for RDS data (7005). Beyond that, you need to be sure that your network is properly configured to allow that data to reach the transmitter.
One final caveat – many automation systems are configured to send the RDS data repeatedly at very short intervals. This can cause the transmitter to get overwhelmed with data and garble, miss or otherwise mess up the displayed data. In the automation control engine, make sure the data is sent as infrequently as feasible – for example, the station I am involved with sends the data once per cart change, so once at the beginning of each song, spot, liner, etc. If that isn’t an option, set the automation to send the data at the widest interval possible – 20 seconds seems to be a viable setting in a lot of situations. Obviously, this will depend to an extent on the reliability of the link (more lost packets equals more chance of garbled data). For more information on how to access/change this setting, you would want to talk to your automation system provider, but there are a lot of VS transmitters running dynamic PS and RT data directly from automation with no additional pieces required. Note that some radios will display PS only, some display RT only and some display both, so definitely your mileage may vary!
The last thing I want to discuss is airflow. Jim Heim, retired engineer for several stations on the west coast, provided a couple of examples of the benefits of positive air pressure in a transmitter site. In one case, he mentioned, “I went to the station and the first clue was that the door to the transmitter room was difficult to pull open. Like two hands difficult. Inside was the transmitter, a long row of cooked triodes, and three wall-mount air conditioners set to recycle. There was no provision for air to enter the room… It doesn’t matter how cold the room is if no air moves.”
Figure 4 – blowing air past the transmitter instead of through it doesn’t work!
Jim makes a good point – and I have mentioned this before. It is possible to have lots and lots of cooling or airflow in a room, but if that cool air is not being directed through the equipment, all it does is make the room more comfortable to be in while you are repairing the burned-up transmitter!
He also provided an example of a TV station with good airflow, positive pressure and a clean air room. I know I have written about that before – the difference that properly directed, positively pressurized, clean air can make is huge!
That wraps it up for this issue. Remember to keep things cool, keep them clean and keep them well grounded! It doesn’t matter what equipment (or whose logo is on it), those three things will go a long, long way toward helping you get the maximum life out of any piece of electronics! If they are connected to the world wide web, also make sure they are protected. Stay safe, and happy engineering!
Jeff Welton, has worked with Nautel for 25+ years. He is currently the Nautel Sales Manager for U.S. Central Region but previously he spent 16.5 years as a Nautel Customer Service Technician.
Submissions for this Tips ‘n Tricks column are encouraged and if published you’ll receive a Nautel T-shirt. Submissions should be typed and emailed, with high resolution photos, to [email protected] using the subject line Tips ‘n Tricks.