Introduction to Q-SYS Control (Part 2)

Welcome back! Let’s walk through the two directions of serial communication.

First, incoming serial communication from a 3rd party controller are received by a Serial-to-TCP Script,

and then the script talks to Q-SYS virtually via Ethernet.

Alternatively, when Q-SYS needs to send control commands out to a 3rd party device,

the control component in your design can connect directly to the serial port on your Q-SYS system.

In terms of establishing or troubleshooting an outgoing serial control connection,

there are a few different elements to look for.

Start by downloading the controlled device’s Serial protocol or API documentation that details specific

Serial port settings and the proper command and response formatting for the device.

Next, we verify the wired connection.

You've probably all used Serial control enough to know that if at first you don't succeed,

flip transmit and receive and try again.

Jokes!

Here we have a design example.

I have a serial port of a Core 110f wired to the serial port of the I/O-8 Flex which is acting as our controlled

device so I can control and monitor both ends of a serial connection independently.

A controlled device will require very specific Serial port settings that we will need to match to our Core

in order to establish any Serial control communications starting with the baud rate.

I need to verify that the baud rate of the Core’s Serial port matches that of the controlled device.

If these are set differently, you'll either I'll get some weird unprintable character of what was received,

or you'll see no response at all.

We will also need to verify if we have identical settings for the number of data bits and the stop bit,

otherwise the last bits of the Serial transmission will not be received correctly.

Next, we need to check that we have the proper Parity setting required by the controlled device.

One other aspect we need to include is the required delimiter,

also known as an End of Line or EOL character a device expects at the end of each command.

In this example, the controlled device is looking for a Carriage Return, or Hexadecimal 0D,

at the end of each line, so if we do not include this, these two devices will never understand that

they have received the entire line of the submission.

Once we have these settings configured to match the controlled device,

the communication will be interpreted correctly.

And so the final thing for us is to verify we are sending correctly formatted commands.

Now we can test our control command.

We can send a command strings to the controlled device, which will then in turn,

send a feedback response acknowledging the command was executed.

So as I can send commands 1 through 8, the controlled device will then provide feedback responses that these

commands have been received correctly which is demonstrated by our feedback LED’s.

Next, let’s look at the example of incoming Serial control from a third party control system

connected to the Serial port of a Q-Sys Core.

As we mentioned earlier, to utilize the External Control Protocol or ECP will require a Serial to TCP Script to

receive the Serial commands and then forward them to the Core over a loopback IP connection.

Like in our previous example, we will need to verify that the Serial communication parameters

are identical for both the Q-Sys Core and the control system.

We will also need to add the Q-Sys component to the Named Control with a custom name

that will be referenced in the command strings.

In this example, we are receiving gain level control commands from a control system.

When a gain command is received by the Core, the gain level is adjusted and an acknowledgement

is returned to the control system.

This communication can be seen in detail in the Debug Console of the Serial to TCP Script.

To ramp the Gain level, the control system sends a sequence of gain commands with increasing or

decreasing values and the Gain fader should ramp up accordingly.

Alright, that’s about it for Serial Connections.

We’ll pause right there, and pick up with GPIO connections when we get back.