Using GPIO and Data

Using GPIO & Data with iPort High Density

As multiple audio signals are encoded in iPort High Density and distributed over a WAN or other network, their associated GPIO information needs to travel with them. Zephyr iiPort High Density makes this happen by embedding GPIO events in the coded audio stream.

Zephyr iPoiPort High Density has a GPIO capacity of 20 contact closures per codec channel, and per transmit direction. GPIO events always travel from the encoder to the decoder. To establish a two-way exchange of GPIO events, a duplex codec link is required.

The GPIO functionality of Zephyr iPoriPort High Density represents a significant upgrade over that of the original iPort. It is not possible to describe every drop down menu and permutation that is available. Instead, we will describe the four operation modes for GPIO. And, with a bit of experimentation, you should be able to develop a solution that works for you. If you're still having difficulties, remember that Telos Alliance 24/7 tech support is just a phone call away.

Audio and control functions aren't the only things running around the data stream. There are “associated data channels,” too. We’ll cover these options near the end of this chapter.

GPIO Operation Modes

Zephyr iiPort High Density supports four operation modes, which are selected individually on the dropdown menus, per GPIO ports and transmission direction.

On the Livewire interface side, the Virtual Endpoint and Transit Point modes are TCP/unicast-centric. Zephyr iPort High Density provides individual point-to-point event transportation channels, which repeat the configuration model and behavior of the "GPIO snake" as implemented in Axia GPIO devices.

In the "emulation" modes, Zephyr iPort High Density communicates with other devices over the GPIO multicast channel and repeats the behavior of the controller (e.g. Axia console) or I/O device (GPIO xNode) respectively. It allows you to create a "virtual presence" for devices physically located on separate networks.

The four operation modes are:

Virtual Endpoint

Transit Point

I/O Emulation

Controller Emulation

First, a Few Definitions

As with most IT technologies, Livewire uses acronyms. You don't need to know these in order to set up the GPIO functions, but there are a few terms that will be used frequently in the following explanations:

LWRP – LiveWire Routing Protocol

GPIO - General Purpose Input-Output

GPI – General Purpose Input

GPO – General Purpose Output

LWCH – LiveWire CHannel number

Virtual Endpoint

The virtual endpoint mode serves for forwarding the GPIO events between clients (PC applications, Axia consoles) connected on the local side of the ZephyriPort High Density, and the codec link. In the endpoint mode, the decoder terminates the snake, therefore in the decoder the GPI events received from the codec link are translated to virtual GPO states. This is functionally equivalent to the snake mode of the Axia IP driver.

Snake between virtual endpoints in Zephyr iPort High Density

There is a set of virtual GPI pins associated with each encoder and a set of virtual GPO pins associated with each decoder. When two iPorts are connected via a codec link, GPO states in the decoder automatically follow the corresponding GPI states of the connected encoder.

LWRP (LiveWire Routing Protocol) clients can set and read the states of both GPI pins in the encoder and GPO pins in the decoder, as well as receive change notifications in the standard way. Axia consoles can set the states of GPI pins in the encoder and receive state change notifications about GPO pins in the decoder. GPI states set in the encoder using any of the two methods above would be forwarded over the codec link to the decoder. GPO states set directly in the decoder and states received over the codec link would override each other on the last-arrived basis.

To enable interfacing with an Axia console, a Livewire channel number must be assigned to the corresponding GPIO port of an encoder or decoder, by means of the configuration UI. The iPort’s encoders monitor the common GPIO multicast transport channel, to receive events from consoles. The events are reported using multicast command messages and addressed to a specific Livewire channel.

Similarly, the iPort’s decoders use multicast event reports to report to consoles about events that were received from the codec link.

Both encoders and decoders monitor the GPIO multicast transport channel to receive GPIO state read requests, and they use multicast messages to report the states requested.

If no Livewire channel number is assigned, the console commands will not be received by the iPort, and notifications will not be generated, while the LWRP interface operations will not be affected.

Transit Point

The Transit Point mode serves for forwarding GPIO events between a GPIO node connected on the local side of the Zephyr iPort High Density, and the codec link. The transit point mode differs from the endpoint mode by the following:

Zephyr iPort High Density - encoder: On the hardware GPIO node connection it acts as a client, not server

Zephyr iPort High Density - decoder: The snake is not terminated in iPort, therefore GPI events received from the codec link are forwarded to client connections

It functions as GPI, rather than being translated to GPO.

Snake between GPIO nodes

There is a set of virtual GPI pins associated both with each encoder, and with each decoder. When two iPorts are connected via a codec link, GPI states in the decoder automatically follow the corresponding GPI states of the connected encoder.

This mode requires specifying an address of a GPIO event source to be followed - port of a GPIO node connected on the local side of the encoder.

The address is entered into encoder's configuration interface in URL format:

This configuration determines the association between the source GPIO port number n in the node and the GPIO port number m in the iPort- encoder. The iPort-encoder (client) would set up a snake connection ("CFG GPO" command) with the specified GPIO node/port (server) that it has to follow. Further, port numbers found in GPI events received from the GPIO node will be automatically translated, and events will be accordingly directed to the linked GPIO ports of the encoder.

LWRP clients can inject GPI events directly into the encoder instance m, bypassing the GPIO port number translation that is applied to server events. Further these logic states would be memorized and forwarded over the codec link identically with those received from a node.

Similarly, LWRP clients can inject GPI events directly into the decoder, overriding the states received via the codec link from the connected encoder. These GPI events would be memorized in the decoder and indicated to other LWRP clients identically with those received from the codec link.

LWRP clients can read the logic states from encoders or decoders using the GPI command, or they can subscribe (ADD GPI) to receive automatic GPI change notifications in the standard way. The following exceptions apply:

GPI state changes in the encoder, initiated by the locally connected GPIO node that is acting as a server (snake origin), do not trigger event reports back to the server.

GPI state changes in the decoder, initiated by the codec link, do not trigger event reports back to the codec link.

I/O Emulation

In this mode, iPort emulates local presence of a physically remote I/O device, e.g. GPIO node.

In brief, this mode is "symmetric" to the controller emulation mode in the following way:

Use of console messages for command and response are swapped - encoder is listening to command and decoder is issuing response.

Virtual GPI's and GPO's are swapped – the encoder has GPO and decoder has GPI.

Console to GPIO node, emulation

Controller Emulation

In this mode, iPort emulates local presence of a physically remote controller device, such as an. Element or iQ console.

The ZephyriPort High Density encoder is listening to console event reports on the Livewire side. The logic states from the received console messages are applied to virtual GPI and over the codec link forwarded to the decoder.

iPort decoder receives logic states from the codec link, applies them to virtual GPO, and forwards to Livewire side in command messages.

Alternatively, LWRP clients can set and read the states of both GPI pins in the encoder and GPO pins in the decoder, as well as receive change notifications, in the standard way. GPI states set in the encoder are forwarded to the decoder the same way as those received with event reports.

When GPI or GPO states are modified via different interfaces (LWRP, console or codec link) concurrently, the state arriving later in time overrides the former, regardless of the interface of origin.

GPIO node to Element, emulation

Using the Associated Data Channels

Configuring the Data Channels

Zephyr iPort High Density provides three unidirectional user data channels per each audio direction. These are provided typically to transport metadata (artist, song title, album and related info) associated with each audio stream.

To configure these channels, go to the Codec Configuration page, click Options for the channel being set up. Scroll to the bottom of that page and click Data Channels.

Set the Protocol dropdown for TCP Server, TCP Client or UDP.

Enter the IP address along with the correct port on your computer where the metadata connects from your automation system or other source.

Do the same for the other two channels if needed, and don't forget to click Apply when you're done. If everything is working correctly, you should see the status change from Not Established to Established.

Data is sent in between audio pacets and is limited to 128 bytes per packet. If you send more than 128bytes this will be transmitted as multiple packets across the link. Customers will often ask how many "characters" can be sent. In ASCII one character = 1 byte. Some languages like Japanese, Korean, and Chinese have double byte characters in those cases each character counts as two bytes.

What's Next?

This chapter has introduced you to the fundamentals of ZephyriPort High Density GPIO. The next chapter will cover configuration and usage of the Zephyr iPort High Density Content Delay option.