Q-SYS Corner

[Steve Guttag]

QDS 9.8.1 has been released. This seems to be a bug fix stop gap before the new-featured 9.9 is released in September. No word on any updates to the LTS path (recommended for Cinemas, for stability).

The 9.8.1 release notes:


What's New in 9.8.1

Version 9.8.1 includes these new features, updates, and resolved issues.

Platform

NV-21-HU Video Endpoint Series
SPA-Qf Amplifiers support Standalone Mode

Video

NV-21-HU AV Bridging Feature License
NV-32-H Status Component power addition
Network Test Screen

Control

E-mailer Component: Outgoing SMTP customization added
Loop Player supports Lua scripting

Resolved Known Issues

• Platform: An issue that caused 'Packet Too Late'/'Packet Missing' errors in Q-LAN & AES67 streaming designs has been resolved.
• Video: An issue that would cause NC-110 to not recall position when disabling privacy mode has been resolved.
• Video: An issue that would cause video distortions when HDMI output is connected between NV-32-H and 21:9 monitor has been resolved.

This is likely a worthy update to 9.8.0 for cinemas due to the Packet issue fixes (Q-LAN and AES67) or if you are using one of the NV-32-H boxes.

[Marco Giustini]

(recommended for Cinemas, for stability).

Thanks Steve.

What would be an application of Q-Sys which does not require stability?

[Steve Guttag]

A/V people that just want the latest features and wouldn't notice minor audio dropouts. Seriously, I recently saw one where they were running all of their networks on a single switch...not vlaned or segmented in any way. QoS miset and you could see the clock drifting back and forth. They were completely oblivious and commented that since their switch had such and such bandwidth, they didn't need to fuss with all of that stuff. Ignorance is bliss. They even have video running on that same switch...again as a flat network and wrong DSCP levels for QoS...Me thinks that when they get enough video going, they'll have audio issues.

Cinemas seem to be really notice any sort of audio issue. You have messed up images and nobody seems to care but if the sound hiccups, everyone's an expert in audio defects.

Me...I keep my QLANs as "blessed" as possible. QLAN-A is air gapped and only QLAN devices (or AES67, like Dolby Atmos) are allowed on it. There is no gateway for it. QoS is properly set as is IGMP. If I have a medium core like a 510 or 610, QLAN-B is the same. For smaller cores (110, Nano, 8 Flex), then I have LAN-B do dual duty of QLAN and control and there is a gateway with a suitable router to go between that network and the "management" or control network of the booth. But I have two networks going just for QSYS, almost always. I have an extremely low fault tolerance for audio issues.

[Marco Giustini]

Ignorance is bliss

"We've always done this way and we never had problems"?

Still, it feels like Windows Home and Windows Professional With Windows Home be an "advanced beta" basically!

[Steve Guttag]

QDS 9.8.2 has been released. This is a bug fix to 9.8.1, that was just released (the Resolved Issues section in bold). 9.8.1 was pulled from release since it caused harm.

What's New in 9.8.2

Version 9.8.2 includes these new features, updates, and resolved issues.

Platform

NV-21-HU Video Endpoint Series
SPA-Qf Amplifiers support Standalone Mode

Video

NV-21-HU AV Bridging Feature License
NV-32-H Status Component power addition
Network Test Screen

Control

E-mailer Component: Outgoing SMTP customization added
Loop Player supports Lua scripting

Resolved Known Issues

• Platform: An issue that may cause QIO, NL, and NM series devices to not reboot after upgrading has been resolved.
• Platform: An issue that caused 'Packet Too Late'/'Packet Missing' errors in Q-LAN & AES67 streaming designs has been resolved.
• Video: An issue that would cause NC-110 to not recall position when disabling privacy mode has been resolved.
• Video: An issue that would cause video distortions when HDMI output is connected between NV-32-H and 21:9 monitor has been resolved.

[Marcel Birgelen]

A/V people that just want the latest features and wouldn't notice minor audio dropouts. Seriously, I recently saw one where they were running all of their networks on a single switch...not vlaned or segmented in any way. QoS miset and you could see the clock drifting back and forth. They were completely oblivious and commented that since their switch had such and such bandwidth, they didn't need to fuss with all of that stuff. Ignorance is bliss. They even have video running on that same switch...again as a flat network and wrong DSCP levels for QoS...Me thinks that when they get enough video going, they'll have audio issues.

In my experience, it really depends on the switches you're using and how they handle buffering and package scheduling by default. On trunked/multi-VLAN interfaces (when you run multiple datastreams from different VLANs side-by-side over the same ports), the behaviour greatly differenciates between switches, especially if you didn't configure any kind of QoS on those ports and/or VLANs. Stuff gets especially exciting if those ports run on a different MTU setting. Storage (e.g. iSCSI) and video often gets pushed to higher MTUs (e.g. 9000 v.s. the default 1500 bytes), to reduce packet-processing overhead, but larger MTUs also increase potential latency and ports running on higher MTU settings usually get bigger buffers assigned by the switch, increasing buffer-bloat... Another great source of general confusion, frustration and source of delayed and even lost packets are "trunked ports" running LACP, especially where one end is using a different load-balancing protocol than the other side. We once had an inter-site LACP construction, where one link had 3ms latency and the other about 10ms and "nobody" seemed to be able to figure out why real-time traffic got completely destroyed when it went over that link...

The thing is, this stuff usually works fine, until it doesn't, and nobody seems to be able to figure out where it went wrong, that's usually when my phone starts ringing...

[Steve Guttag]

QDS 9.9.0 has been released. Note, one MUST pass through 9.1 and 9.4 on their way to 9.9. As always, I still recommend the LTS branch for cinemas, which, as of this writing, remains 9.4.5.

With 9.9 and a CORE 610, one can apply a scaling license and get up to 384x384 channels (256x256 is its standard, out of the box, capability), which would cover just about any sized multiplex. That said, the scaling license is not cheap and not even related to cheap at about ½ the price of the CORE itself. However, with two CORE 610s in a primary/redundant configuration you have a rather robust system that is going to be cheaper than separate processors for each screen. And, don't forget, even the CORE NANO (or 8-flex) can also scale up to 128x128 to cover 3-4 screens for a lot less money (out of the box, they are 64x64), which may be enough to barely cover 3-screens, definitely 2 screens.

What's New in 9.9.0

Version 9.9.0 includes these new features, updates, and resolved issues.

Note: The requirements for the upgrade path have been updated; visit the Upgrade Path Requirements section to review the new pathway.

Platform

IO Monitor AES67 and Software Dante support
Deprecated: Media Browsing of Media directory
Q-SYS Designer Software Help Menu
Software Dante Optimization
Configurator: Added number of devices
Core 610 Scaling License
Core 610 Expanded Software Dante License Tier

Audio

CX-Q Front Panel Turn Off

Video

NV-32-H: Shift AV Support for Encoder and Decoder Modes
Camera Auto Framing

Control

Asset Manager: Tab views
Expanded CEC Functionality

Management

Enterprise Manager: Manual Backups and Restoring a Backup
Enterprise Manager: Quick Status View
Enterprise Manager: Webhook notifications
Enterprise Manager, Core Manager, and Peripheral Manager: Added product serial number
Core Manager and Enterprise Manager: Inventory Columns
Core Manager: Added UCI Links tab
Core Manager and Enterprise Manager: Export as CSV option

Resolved Known Issues

• Audio: An issue that caused interruptions in the NM-T1 proximity sensor LED rings' fuel gauge functionality has been resolved.
• Audio: An issue where the NM-T1 Mute button was not being added in a Snapshot Bank has been resolved.
• Amplifiers: Designs that have a CX-Q amplifier no longer cause pilot tones to become disabled when choosing Save to Core & Run.
• Loudspeakers: An issue changing the name of a Custom Voicing that is currently mapped to the 70/100 Speaker component has been resolved.
• Loudspeakers: Designs that have Loudspeaker blocks (Tools>Group) no longer cause the Loudspeaker to disappear.
• Control: Designs with QIO-GP8x8 components with design file names longer than 52 characters no longer experience deploying issues.
• Control: An issue that would cause "Error 404 - File or directory not found" to pop up when dragging any QIO or NL Status component into the design, and pressing F1 has been resolved.
• Platform: The issue where QIO, NL, and NM Series devices experienced lockups when downloading log files from the QPM utility page with 802.1x enabled is now resolved.
• Platform: An issue that caused QIO, NL, and NM Series devices to lock up on bootup has been resolved.
• Platform: QIO, NL, and NM Series devices can now change the device name with 802.1x certificates loaded without SSL web page errors.
• Platform: An issue that caused QIO, NL, and NM Series devices to not work with Cisco ISE has been resolved.
• Platform: The issue with how Core MAC lookup was inaccurately managed on L3 networks for QIO, NL, and NM Series devices has been resolved.
• Platform: An issue that caused QIO, NL, and NM Series devices to show "Missing - In Use By Another Design" has been resolved.
• Platform: An issue that would cause QIO, NL, or NM series devices to get stuck on "Initializing" after deployment has been resolved.
• Platform: An issue that would cause the outputs of QIO devices added to a vCore to be unavailable has been resolved.
• Platform: Designs containing locked elements no longer experience the issue of being unable to be unlocked.
• Platform: An issue where pasting a text name from a text editor into Designer as a block name resulted in the name not being retained has been resolved.
• Platform: Distorted graphics that appeared in the Controls of a Matrix Mixer in the VCA groups and Cue Busses have been resolved.
• Platform: An issue that would cause an I/O USB Bridge to show an expired certificate has been resolved.
• Platform: An issue that would cause NodeJS log errors has been resolved.
• Platform: Designs using a Flattop Parametric Equalizer no longer mismatch the values when being copied between blocks.
• Platform: An issue that showed 'CorruptedGainComponent Fault' in the System Controller Log has been resolved.

[Ioannis Syrogiannis]

Now that I pay more attention to the developments, I can say what you've already seen on the Asset Manager: Barco updated its Series 4 DC Projector plug-in today.
More elaborate warnings and SNMP requests. Better overview.

[Steve Guttag]

Watch out on that new plugin. I tested it today and it would not connect. It will light the System Ready LED but it wouldn't connect to the projector. I checked at two sites with both 9.4.5 and 9.9.0. I've reported same to QSYS. I suspect it will be a quick fix...I did beta testing on it (so I'm surprised that the release had a bug...something must have changed).

A big improvement on it is how it handles the Presets. From 10 to 100, one can use drop-down boxes to select macros and set up a traditional preset list/buttons rather than being limited to just 9. And, unlike the original plugin, where macros are listed in alphabetical order (which they still are), which are subject to reordering when new macros are created (e.g. F-200)...once one assigns a macro to a preset button, it will stay so your UCI will be remain consistent and Named Controls will remain consistent. The Errors, Warnings, Notifications let the S4 plugin have the same information that the S2 plugin has. This can be turned into a "Taillight."

Once the S4 in release checks out as good, I'll do a review.

[Steve Guttag]

Just released, an updated version of the Barco S4 plugin. Please note, yesterday, QSYS released a version that would not connect (1.2.0.0). Today's release is 1.2.0.1. So, if updated Asset Manager yesterday, get today's version.

In my opinion, this is the first Barco S4 version that is useful. Key improvements over version 1.0.0.0:

• Status for Notifications, Warnings and Errors (Blue, Yellow and Red Taillight type issues, respectively)
• The ability to create your own "Preset" buttons for buttons beyond Private Messages

For whatever reason, Barco has decided that they are going to track 9 preset buttons (not to be confused with macros...macros are assigned to presets). The problem with just using Macros within a UCI is that they are sorted alphabetically. So, if you add a new Macro that is alphabetically in the middle, it will push all of the macros after it to a higher macro number.

Using this list:

MacrosCapture.jpg

"SCOPE" is macro 13 by virtue of being sorted alphabetically 13th. If one were to decided that they needed an "HDMI_A_200" macro, that would push everything from macro 10 to a 1-higher number with Scope becoming 14. So, other than seeing the full list of available macros, at that instant in time, I don't personally, see this as all that valuable. Perhaps others really like it that way and just let the use see a newly created macro show up and manually select it.

The BIG change is on the Presets page. The new plugin will poll the projector for the 9 presets that are configured on the projector but one can then populate presets from 10-100 (that should be enough!) with any available macro in any available order and it will stay that way. Thus, you can set up cues and scripts that will consistently call known presets/macros.

To configure a preset, merely click on the white space for that preset and choose the macro you want to assign to it:

PresetsCapture.jpg

The familiar Barco blue buttons are both status (what is active) and also buttons for selecting the preset/light/dowser.

If you want to create a virtual taillight, you'll need to do so via turning on some pins to monitor the warning counts and triggering "LEDs" but it is all doable.

Now, where things go a bit wonky is when the projector goes into its form of "ECO" mode/sleep. While you can still "Ping" the projector, it shuts off all of its SNMP communication so the plugin cannot retrieve status. Furthermore, it takes 3 minutes from when one wakes up the projector before SNMP traps start working again so the plugin will be in a state of limbo until then. I plan to experiment some with a ping component to see if one can accurately know if the projector is in ECO mode or not. The reason is that the last known states/errors will remain until the plugin gets a solid connection and re-populates the various fields.

Overall though, a good plugin and a vast improvement to version 1.0.0.0.

[Harold Hallikainen]

To make the position not change when a new macro is added due to the alphabetic sort, you might be able to add a numeric prefix to each name. For example,

01_Flat
02_Scope
03_ Flat200

etc.

Harold

[Steve Guttag]

Yes, that would work. However, since Barco uses the macro name as the means to recall it. So, all other equipment (servers, automations...etc.) would need to be updated with the name changes. All to overcome a plugin deficiency. Then, if you create a new maco that should, logically, fall somewhere other than the last named macro, you have to rename all of the existing macros to get them to sort right and, again get all peripheral equipment updated for the new names

[Ioannis Syrogiannis]

Just a note, in case that helps anyone on a similar situation.
My goal was to control lights and microphones from a DSS200i through serial. In return, I wanted to use the projector/server for A/V, so I needed to be able to change presets and inputs (server/HDMI1/HDMI2) from the UCI.

For some reason that is beyond me, or Dolby's help desk, until now, I couldn't do that through Ethernet Automation. That would have solved the problem from the first moment.
The root cause is that even with the configuration as it should, I was not getting any open port for that. But that is for another thread.

I did use a Ser2net adaptor to send whatever command I needed from the DSS to the core, but that worked well only one way.
The next logical step (or, maybe the previous) was to use the serial port of the core. (110f)
I had to familiarize myself a bit (and only a bit) with scripting first.
Then, to make the serial connection work, I physically connected the two machines. I used a straight connection (not a null modem one), knowing that if that didn't work, I could keep the soldering on the DB9 and swap the cables on the core's side. So, TX to pin 3, RX to pin 2, GND to pin 5.

I then used the component that I found here: https://qsc.my.site.com/selfhelpport...ore-via-serial

That was set and worked O.K., but I still didn't have any cues working from the core to the DSS.

So, what I did was to copy the entire LUA code from the component that I downloaded and paste it on a text controller, that I named Ser2NET and gave it Script Access.
Then, created all buttons and text boxes that the original component has, with the same names, so the script won't shoot blanks.

Then, I added two things. On the starting variables of the script, I added one to make it easier:

S2command = "" -- Text to be sent to Screen 02 Serial

Then, I added a series of 6 trigger buttons, and named them SerialOut.

I created a function that, depending on which button changes its state, a corresponding command would be sent to the DSS (through serial).
I had already set on serial input commands the proper cues.

function serial2Out()
 for i = 1,6 do
 Controls.SerialOut[i].EventHandler = function()
  if i == 2 then S2command = "HDMI1input\r"
  elseif i == 3 then S2command = "HDMI2input\r"
  elseif i == 4 then S2command = "play\r"
  elseif i == 5 then S2command = "pause\r"
  elseif i == 6 then S2command = "stop\r"
  else S2command = "SERVERinput\r"
  end
 sp:Write(S2command)
 print(S2command)
 end
end
end
​

Finally, for the function to work, I called it at the end of the script.

serial2Out()

I know that this method does nothing for a booth with more than one Dolby DSS, but I would like to know about it a few months ago.
So, if someone finds himself on the same peculiar path, this is one way to go.

[Steve Guttag]

I've developed a "Taillight" component for use with the current Barco S4 plugin (version 1.2.0.1). In addition to providing taillight status, it also intercepts the normal status of the S4 plugin, if the projector is in an ECO or waking up state. The QSYS developed plugin uses SNMP to get some of the status for their plugin (information that isn't available through their REST API, at this time). Unfortunately, after the projector is told to wake up, SNMP does not respond for 3-minutes, leaving the plugin in a state of limbo...showing stale data and reporting incorrect status.

My user component looks to see if the projector is there (pings) and if SNMP is responding. Based on those two states, it should display the appropriate status. Additionally, it has the logic to change the taillight between Red, Blue, Green and Yellow.



Inside of the Taillight logic is the user component and the logic for the taillight colors:



Barco S4 Taillight Only 231009.quc.zip

Barco S4 with Taillight 231009.quc.zip

[Steve Guttag]

Hmm...something must have happened to the images in my post above. It used to be there.

Anyway, I've been working on a project that has Dolby DSS200 servers and Dolby CP750 processors. As such, the client has been accustomed to using the DSS server's built in "Volume" cue and assigning a value. As most know, when working with the DSS server, if you don't have a Dolby processor, the volume field on the control screen reads "Disconnected" as a reminder that you didn't buy a Dolby product (really, that should have been hidable from the get-go, or allow for configuration with other brands). So, what to do when integrating QSYS as the replacement sound processor to the CP750?

I developed an "emulator" for QSYS such that it will respond to the DSS server's queries so it thinks it is talking with a CP650. To use it, one has to change or make sure that their DSS200 is configured to have a Dolby CP650 processor (it seemed like the simplest one with the most limited command set). I then used an Ethernet to Serial converter by Lantronix (UDS1100). The converter is set to the IP of the original CP750 (but it can be set to any desired IP that the DSS server can reach) and the port of 61412 (CP650 control port). I then brought the serial portion in via the DCIO-H's serial port (again, any serial port will do). The serial speed is not critical as nothing speedy is going on here. I used the old standard of 9600, N, 8, 1.

At that point, the user component can satisfy the DSS 200's queries (it will shut that port down if it doesn't get the responses it is expecting) as well as pass volume and mute information. I've elected to not pass sound formats as they would not match up. One would need to provide the user a cheat sheet of what "01-Mono" really means...the same for the rest of the 8 buttons of a genuine CP650. That can certainly be added, if need be but this client wasn't using any direct CP750 control of the formats so they were not necessary.

Someone who is good with LUA could script a direct Ethernet conversion (look for communication on port 61412 but sine I often have multiple screens on one CORE, that would trip you up as you would need to know which server wanting information. The serial to Ethernet converter allows for unique IPs so there is a 1:1 communication.

Now, to finish the job, your design should already have a means of converting between Linear (0-10) and dB scale volumes. Only crazy people present the user with a dB scale volume. I believe, elsewhere, I've posted one of mine.

So, here is the user component:

Screen Shot 2023-10-15 at 10.54.08 AM.png

Screen Shot 2023-10-15 at 10.56.08 AM.png



CP650EmulatorForDSS231014.quc.zip