Full stack AV Developer

Developer , Programmer , configurator, engineer …

In the software world, the new wanna-be job title is a “Full Stack Developer”and following a recent quick discussion with a colleague in the AV Industry this got me thinking about what we call ourselves and what we read in what others call themselves in the AV Industry. In the ever changing world of tech it is interesting to think about how we stay relevant in the changing marketplace.

In the world of AV control, the term “programming” is used to describe a process in which a software developer (often referred to as the programmer) uses the system’s functional requirements to develop, install and test the user interfaces and automation software required to operate the control system appropriately

In Infocomm’s 2015 Whitepaper, Modern Approaches to Control Systems Design

Sounds like a full stack job to me! The description doesn’t include developing the user interface but in the industry, this is often carried out by the same ” programmer”.

The tasks within this definition can be broken down into smaller items.

  • Software Developer – Develop a software specification from the functional requirements
  • Programmer – Write the controller software based on the developer’s specification.
  • GUI Designer – Design and implement a touch panel design to fit the developer’s specification
  • Commissioning Engineer – Install and test the controller software and GUI Interface. ( not installing or programming the physical devices)
  • T&C Engineer – Verify the compliance based on the functional requirements.

I think it is helpful for the sake of this discussion to mention and then exclude installers traditional “Test and Commissioning Engineers”. For me, this role is part of the quality control process and indeed in other industries, the T&C engineer is an independent contractor who can objectively assess the compliance to the spec of an engineering system. Installers (ideally good ones) are crucial to the process,  just not what I am discussing today. I know some excellent T & C engineers who have no knowledge of how to write a DSP config or a control program but will tell you what it is not doing in a very detailed way!

So this leaves broadly two groups:

  • Commissioning
  • Programming

There has been debate (and a fair amount of snobbery) for years within the programming community online over the difference between a programmer and somebody who just carries out configuration on a pre-programmed system. It has generally been accepted in the past that configuring systems using a drag and drop software is not the work of a programmer. That line seems to be crossed only when your work involves writing custom code at some level.

The skills required by a good commissioning engineer have ramped up over the years. In the past a good commissioning engineer would be on the tools checking IR bugs, using RS 232 connections for firmware, tuning gains on amplifiers and pre-amps using a screwdriver and have a stock of RS232 crossovers in their bag. Its common now for the principle tool used by a commissioning engineer to be a laptop. Convergence of communications onto ethernet and the widespread use of DSP audio processing means that the commissioning engineer can update firmware, setup network configuration, ID Devices and tune the room audio from their laptop connected to the LAN. Commissioning engineers are likely to be certified on individual products and familiar with scripting and telnet as well as competent in networking.

To me, a Full Stack Developer is someone with familiarity in each layer, if not mastery in many and a genuine interest in all software technology

Laurance Gellert

So what does a programmer do? we defined above that they need to write custom code at some level.

However both in AV and in any software development, writing code is only one of the skill sets.

AV System

  • Video and Audio Distribution
  • Building / Room Data Collection
  • Functional requirements
  • Core Programming
  • GUI Design and Programming

Web Application 

  • Server Network and Hosting Environment
  • Data Modelling
  • Business Logic
  • Action Layer MVC
  • User Interface User Experience

Some focus on user interface design while some work in the processor coding that is the core custom logic of the system, others on writing the modules and interfaces that other programmers use within their core code.

There is also differentiation by sector with some focusing on offering their services to the residential sector or the commercial sector.

There is another level of differentiation based on the technical skillsets of the individuals or companies. In Crestron alone, it is possible to program a system in four different ways (AVFramework, Studio, Simpl or Simpl#) four different software platforms with different possibilities.

We all program at some level of abstraction and different software tools offer different levels of abstraction with the associated loss of detail and reliance on the abstracted code.

Indeed the scale of abstraction and quality of the tools available means that highly custom systems can be created without writing any code at all.

Is it time for the “AV Programmer” to establish a new identity? Perhaps the current term “AV Programmer” is a misnomer. We might consider that a new name be given—one that better identifies and describes the value an AV programmer provides

Steve Greenblatt Control Concepts

[blockquote][/blockquote]

AV converging with IT has also meant it has mearged with software development. Systems can be written or include sections that use open languages such as Python, C # or javascript and open hardware for control and of course there arespecialist AV programmers who can also excel in these open languages.

In the AV industry we need to learn to write clean code, loosely coupled  or systems and API’s so that we can all work on our specialisms! In the future the role of the real code writers may well be to write the code to allow other less skilled users to use more abstracted solutions and have confidence in their tools and the supporting modules.

We have in my opinion a problem In the AV industry where some integrators lean on new eager individuals in the industry to be a jack of all trades and become their sole and complete technical resource.

Indeed I have done my own share of this type of work in the past. I think of it like a Hollywood movie ‘mission impossible’ where the hacker has to control a building system and shut down the lifts and the alarms before Tom Cruise gets caught.

This unsustainable expectation leads to systems which are poorly documented, difficult to maintain, impossible to fully test and lead to a bad user experiance. In addition, these new starts into the industry have no-one to look up to in the business,  no technical mentor and no team to support them.

I think programmers new and old should look to the wider world of software development where collaboration with other professionals is encouraged. Meet-ups and Hackathons for example bring together technical and non-technical individuals to collaborate on projects and new ideas.

AV professionals can stay relevant and play a major role in the ongoing AV/IT convergence by doing what we have always done. Keep learning.

Patrick Murray-Controlhaus

So as you can see programmers do many different things for many different clients. I think as Programmers we must make sure we speak to your customers about where we specialise and use the network of our peers to deliver better solutions.

I think Integrators planning project make sure you talk about which skills you need before selecting the right team.

Further reading:

Testing of RS232 control cables for installers

Summary:

Despite the increase in control via ethernet the use of RS232 is widespread in integrated AV systems and the connection of these control cables and testing of the falls within the remit of the installation engineer. However many AV engineers lack the knowledge to test and fault find these connections and hence cabling problems are the number one cause of problems at the programming stage. The testing of Video and Audio signal routing throughout a system is common and more widely understood and this article attempts to provide a toolbox of methods for simple testing of RS232 cabling within a system.

The methods below require no control system training and are applicable to any RS232 system.

Pre-amble:

To effectively install and test a cable for RS232 control you need to know what the pin out specification for the device that is being controlled and the pin out specification for the controller.

This information may have been found by the system designer in which case you might find it in your job specific method statement, cable listing or schematic drawing. If you don’t have this information you cant install the RS232 cabling and can either install a standard straight through RS232 cable and rely on adaptors at the controlled device end, speak to the system designer to clarify this information or find out the information yourself from the manufacturer documentation.

Method 1:  Voltage test on RX / TX

It is possible to carry out a simple test on the GND, TX and RX of a connected RS232 link with both the controller and the controlled device connected.

e.g.

And AMX NI2100 controlling a Panasonic Projector.

AMX Module documentation provides the following cable specification:

AMX NI (DB-9 Female)       – Panasonic (DB-9 Male)

5(GND)———————5 (GND)

2 (RXD)———————2 (TXD)

3 (TXD)———————3 (RXD)

Testing at the projector end (Male db9)

With both devices connected:

We should see a negative voltage on pin 2 and 3.

If both pins remain at 0V it is likely that RX and TX are incorrectly crossed.

With the projector disconnected:

When the projector is disconnected we would see only a voltage on pin 3.

Method 2: Loopback Test

Using a loopback is a great way of testing installed RS232 wiring. Put simply by connecting the RX and TX pins at the remote end we can test the continuity and correct pin wiring of the cabling throughout its length of installation.

A loopback connector should be a Female DB9 with pin’s 2 and 3 connected and pin’s 7 and 8 connected.

A loopback test is carried out simply by sending some data from a terminal software running on a pc. As the RX and TX pins are connected if the wiring is continuous then the transmitted data loops back onto the rx pin of the PC and the data sent is received back by the PC.

A detailed tutorial of this simple test can be found here http://www.ni.com/tutorial/3450/en/#toc3

This test is however limited in that it will not show up errors of RX and TX being crossed over incorrectly.

Method 3: Testing cabling using Manufacturer Software tools

This involves testing communications by using a manufacturer provided software to communicate with the device hence proving the control cabling.

Not all devices have a software application but most do and I have included some of the common ones below:

Software can be found on the manufacturer’s website and is often provided on disc when a product is shipped.

BARCO Projector Toolset

http://www.barco.com/en/Products-Solutions/Display-management-software/All-in-one-remote-projector-management-software.aspx

NEC Screens

PD Comms tool  http://www.necdisplay.com/support-and-services/pdcommstool/downloads

Samsung Screens

MDC Multiscreen Control Software

multiscreen.sharewarejunction.com

Kramers Switchers

Protocol 2000

http://www.kramerelectronics.com/support/download.asp?f=35567

Protocol 3000

http://www.kramerelectronics.com/products/model.asp?pid=2870

Extron Switchers

http://www.extron.com/download/dltrack.aspx?file=MATRIX_SW_v8x4.exe&id=67589

AMX Switchers

APControl 3.0.1.1

Method 4: Simple device control

When no manufacturer tool exists using a simple command terminal is the only way of proving correct wiring from AV controller to 3rd party device.

To do this test a computer running a terminal program should be connected temporarily in place of the AV controller this way the installed cabling is tested entirely. The object of the test is to demonstrate 1 way control over the controlled device over RS232 by seeing visual feedback on the device. Where 2-way control is required the test should also prove that the controlled device has responded with some data on the terminal.

Example:

LG Screens:    RS232 Setting 9600,0,8,1

Command: ASCII    ‘ka 1 1’      Action:  Turns screen on from standby

Command:ASCII     ‘ka 1 0’     Action:  Turns screen off to standby

You can download the pdf version here

Select currency
GBP Pound sterling