Distribution & Delivery Global Viewpoint – December 2020

Progressing GPI

GPIs have been with us since the dawn of television. As old as coil-relays themselves, the humble GPI has been the mainstay of broadcast systems the world over. But should we now be looking more to IP?

It doesn’t really help that we can’t really seem to agree on which acronym to use. Is it GPI, GPO or even GPIO? I don’t think it really matters as we’re referring to the same type of concept, that is, the ability to trigger connected equipment using a voltage independent interface.

Camera tally lights were probably the first GPI application for broadcasters as red lights needed to be automatically triggered from the vision switching device in the gallery. A simple interface solution that continues to be with us today. But it still amazes me that the latest designs of broadcast hardware contain GPIs. Why?

IP systems allow us to distribute messages across networks with speed and reliability and this has even been standardized by AMWA with their NMOS IS-07 specification. But what is really telling, is that NMOS refer to this message as an “event and tally mechanism”. Digging a bit deeper into the message structure we can see that there is provision for timestamped events.

I realize that GPIs are easy to use but they do have the potential to add much complexity in terms of cabling and configuration to broadcast infrastructures. Every GPI trigger even needs its own control cable! A one-baud (or less) control system.

Alternatively, distributing and aggregating IP messages is incredibly efficient, processing is readily available and with the introduction of the timestamps in IS-07, we can now schedule events with microsecond accuracy when working in combination with PTP. It’s worth remembering when a relay closes it takes about 20ms for the voltage to stabilize due to the noise induced on switching the contacts, and that’s before we start thinking about the response time of the software in the connected peripheral equipment.

If we pre-send timestamped events, then they can be scheduled with microsecond accuracy in the receiving equipment. Admittedly this level of accuracy may not be needed for switching tally lights on a camera, or dimming an external loudspeaker on an intercom panel, but there are many other areas where these levels of timing accuracy are a necessity.

My personal preference would be to make every device in a broadcast facility ethernet compatible with an inbuilt TCP/IP stack to facilitate processing of messages such as IS-07, almost like an “internet of things” for broadcast infrastructures. But in reality, I know this is a pipe-dream due to the amount of legacy equipment already in use and the simplicity with which GPI operates.

In conclusion, I would suggest that GPIs are going to be with us for a long time yet, but they will be distributed more over IP networks and not dedicated cables. The actual GPI control will be pushed to the locality of operation as in the intercom panel example, with the GPI control information being distributed over networks using GPI-to-IP interface systems, and precision timing will play a more important role. However, to help us with our IP migration, we really need to start thinking in terms of accurately timed PTP software triggered events.