Over the last 12 months the global pandemic has given us the opportunity to develop plans on new parts of our business. Modules have always been a part of our business as our work in Crestron Custom means we often have to create modules for use in our own projects.
At the same time Crestron’s long term project to move to a standardized platform for driver development has come of age with the release of the v4 SDK. Lighting Control have been involved as a close development partner on both the SDK and Crestron Home (one of the supported operating environments).
The aim of the standardized model is that drivers will be compatible across the range of Crestron systems including Crestron Home, AV Framework , DM and NVX Endpoints and in the cloud as part of Crestron XiO Cloud.
Taking an active part in the pilot program for both the drivers SDK and Crestron Home has been a satisfying project as we have been able to contribute our piece to the progress of the ecosystem both in documentation, systems , processes and flushing out features.
Our project, to setup and launch our Drivers store for Crestron Home, has been a long term investment in the systems, processes and talent we require to be a serious b2b partner across the ecosystem in the years to come.
We had working drivers back in November of 2019 but I realized that we didn’t have all of the processes and tools in place to maintain, support and be agile in our approach to new requirements at scale.
We are excited to have Neil and the team at Lighting Control working on Crestron Drivers. We hope that their enthusiasm and investment in the program will prove beneficial to all Crestron partners going forward.
Ara Seferian | Sr. Product Manager , Digital workplace Crestron Electronics Inc
Implemented an Automated Build process for our Drivers
Common Functionality coded using best practices
Base Types allowing consistency of user experience and easier testability
Code Driven User interface
Automated Documentation Build
Build Updates production Downloads directly meaning updates are immediately available
Unit Testing of helper methods and hardware interfaces.
Implemented Integration Testing using dedicated hardware.
Implemented Internal Compliance Testing of Crestron Home Driver Packages.
Server move of our existing website and upgrades to back end systems
Addition of webstore and integration of our existing support systems
Addition of new Internal and External Knowledge base systems
Creation of a Library of “how to” guides, both video and print
Creation of a bespoke licensing system with self-serve functionality
So with this base in place we are now well positioned to offer continued additional items to our Crestron Home catalogue and we are already working with manufacturers who want a partner in this field to assist them with integration with this or other platforms. With exciting new developments looming in the other Crestron platforms in the coming months we look forward to developing partnerships in this area.
Times are not normal just now and I never expected to be writing a blog post about what my business is not doing!
Practical day to day and what the business isdoing!
With restrictions on movement, and due to the nature of most of our works being Lighting Control, we are currently operating a very restricted service.
All of our on-site works for non-essential sites/projects have stopped although we continue to provide some remote support to customers.
We have a small number of projects in the development phase which the relevant team-members continue to work on from home.
The AV industry and Software industry more widely
The AV industry, as part of the larger communication sector, is classed as an essential sector and we have seen in the mainstream media examples of AV at work as part of the Covid crisis response. Supporting the daily briefings, projects to add virtual support to government committees and indeed the main parliament chambers in Westminster and Holyrood and projects helping healthcare professionals collaborate with their peers and offer their services remotely to patients.
In the AV industry consultants, designers and integrators have always struggled with defining the functionality of systems.
I’m not talking about the process of gathering the requirement here but of documenting it.
We produce, mostly, great schematics which define the boundaries of the possible based on the hardware. The idea of these drawings containing black boxes which are highly configurable is not new.
Black boxes, by my definition, differ from other hardware items on a system drawing as although they may have a static number of input and output ports their core functionality is open to a high level of configuration.
A display has, potentially, a few functions. It’s a video switcher, a display, an amplifier with onboard speakers, it even has some control features including auto switching of the video switch and volume control of the amplified sound level.
Take for example a display with a single connected HDMI and RS232.
It’s reasonable to glean from a schematic alone that the functionality of this piece of hardware in this system is to display a video stream of the connected source and that power and input control will be using the RS232 port.
Contrast this with a control processor pre-Ethernet.
A control system processor does stuff.
Take a simple system with a two-button keypad and a display.
A Schematic showing a control system a content player and a display accurately describes the system. On functionality we can make some assumptions but without some additional information they are just that.
It is possible that: Button 1 turns system on and Button 2 turns system off.
However, it is also possible that: System turns on and off based on an internal timeclock and Button 1 raises volume and button 2 lowers volume.
To discover the actual requirement we need a functional scope which has hopefully been produced by some good needs analysis that informed the system design.
Control systems in the form of processors and touch panels with IO allowing control over 3rd party devices have been around since the 80’s and the discussion over how to specify their operation has produced little in the way of standards.
Infocomm, pre Avixa did some good work on this but this is not widely adopted across the industry. Crestron’s CAIP scheme and subsequently CSP (Crestron service providers) has, at its core, the requirement for programmers to produce a functional specification but even this is not standardised across the body of CSP’s.
DSP’s are common place in mid to large systems. Again these are of course by our definition black boxes.
traditional non Ethernet connected control systems DSP’s pre Dante and Digital
had fixed number of inputs and outputs. Even post Digital standard such as OBAM
proprietary hardware such as IO extenders also included on the schematic would
ultimately define the inputs and outputs of the system.
The Functionality of the processing going on in that DSP must be defined just like a control system. The language of this definition is often tied in with the control system which provides control IO to this audio processing however audio processing has a language of it’s own. These boxes provide room and system specific equalisation, gain structure, Acoustic Echo Cancelling along with VOIP functionality.
Often the DSP tools are graphical in their nature providing a schematic like trail which defines that dynamic functionality of the DSP. In our system functionality specifications we define all interactions between control system and the audio processor.
The new world “Not just black boxes but hidden lines”.
Although the change has been coming over the years for me the, “Dante Spoken Here”, sign at the ISE Show in 2018 all over the show were the sign that Audio over IP was now wide spread.
Schematics don’t just contain black boxes but hidden lines! The traditional
skill of tracing a signal path through a schematic from input to output becomes
a whole new skill.
LAN connection to a device can be obfuscating control, video and audio in that
single cable and potentially multiple routes to disparate locations.
One approach to this by engineers is to view the IO potential in a traditional way and connect it all up like a patch panel. I have found systems where all 64 Dante channels are connected from DSP to Audio Desk for “future use” but for me this misses the point.
It’s the same misunderstanding as coding an object oriented code in a single file monolith.
world of Dante in addition to the Schematic which shows the physical
connections between devices documentation showing the network routes must be
created intelligently based on the functional requirements of the system.
routes need to be well named for system maintainability and usability.
Having Multiple Dante 1, Dante 2 ,Dante 3 around a system dont mean anything. These should have a Name or Numbering convention just like cables.
These concepts of defining the routes apply to other types of audio over digital such as USB IO.
this video over IP in whatever flavour is being used or in some cases a mix of
encoders and video decoders on a drawing doesn’t tell you what routing
possibilities you might need to setup. Some devices in the market can be
configured to be Decoders and Encoders but the Fixed IO on the device doesn’t
always inform you on this without some further information.
devices to be matrixed or is the system designed as a one to many DA?
Are you using audio breakaway on the encoders / decoders?
And in a
final twist some of these products also in addition to all of the above speak
Dante so need to be included in your Dante routes.
challenges are real for us in our day to day business where provided with schematics
for a project we need to suck out the functional intent from the pre-sales
design engineers and the project engineers.
work with the designers explaining to them the additional documentation we need
to produce to clarify to the programmers and commissioning engineers what they
need to implement.
Virtual Matrix Drawings
VLAN Network Design Drawings
Dante Routing Naming Schedules
GUI Functional Requirements
Automation Functional Requirements
Audio System Functional Requirements
If you need help with filling in the gaps reach out to us to help!
Crestron Fusion Migration from Lotus Domino to Office 365.
Working as a consultant to the project team together with Zurichs managed service O365 provider and the on-site team we planned, tested and assisted with the migration of all the room scheduling across to the new scheduling provider.
AV Manufacturers: Cisco VC, QSYS DSP, Extron Switching
“An innovative environment that changes the way Deloitte clients solve business challenges. By taking participants outside of their everyday environments, Greenhouse sessions disrupt conventional thinking, spur creativity, bring about new perspectives, and lead to tangible solutions.” Deloitte
Working on these spaces for Deloitte is technically demanding but the results are highly satisfying.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.