Between two vendors

I worked for a TV station that was part of a group run by a common owner. One of the stations in the group used a system known as production automation, which allowed a single operator to control all of the equipment in the control room during newscasts. That would include the video switcher, audio console, camera robotics, video playback, lighting, and graphics generators. The computer system in the newsroom takes the scripts written by reporters and producers, generates a sequence called a rundown, and transmits and updates it in real-time to the automation system.

Do you have a memorable experience solving an engineering problem at work or in your spare time? Tell us your Tale

While performing a major update to one of the systems, communication stopped. Head scratching ensued for a while, and then the two vendors decided the problem must be something in the network that was blocking the IP packets. The station’s engineers pointed out that nothing had been changed in their network, and in any case, there was no internal routing or filtering going on. Not good enough, say the vendors. Prove to us it’s not your fault before we continue. Their advice was to install a copy of Wireshark, analyze the packets, and show us that the path between the systems is clear.

That’s reasonable as far as it goes, but Wireshark is a mighty powerful tool, and it is not for the faint of heart. At the local TV station level, the IT staff generally does not have the expertise needed to fire it up quickly and interpret its results. The station group’s central IT networking folks do, but getting them involved would have taken a good deal of time, and if they had to travel to the site, expense.

I was just a bystander to this. My own station was one of those with the same systems, so I was included in all of the emails flying back and forth. As it happens, not long before this incident, I had written a small one-trick pony Windows utility. All it did was send IP packets from one computer to another via a specific port. As seen in Figure 1, if the path is clear, the receiving computer replies, and the arrows move. Simple as that.

Figure 1 A demonstration of the Windows utility written by the author, sending IP packets from one computer to another via a specific port.

I sent the program to the station’s IT director, and in less than half an hour, he installed it on both systems, checked all of the ports the vendors specified, and found them all clear. With no more finger-pointing at the customer, the vendors had to get to work to find the actual cause of the problem, which turned out not to be network-related.

A few notes about the program. The image shown is just a demonstration, with both ends running on the same machine. In real life, one copy would be on each of two machines on the network, across the room, or across the world. Also, to be honest, I probably spent more time getting the ballistics of the arrow movement looking good than on the rest of the program.

Robert Yankowitz retired as Chief Engineer at a television station in Boston, Massachusetts, where he had worked for 23 years.  Prior to that, he worked for 15 years at a station in Providence, Rhode Island.

Related Content

• The mysterious MS-DOS reboot
• TV transmitter trouble
• A network-protocol primer
• IP Resilient Network Fundamentals–Part III

The post Between two vendors appeared first on EDN.