Q-SYS Corner

[Steve Guttag]

QDS 9.13.1 (LTS) is now available for download. See my previous post for the long list of bug fixes. This is THE new LTS version and the last stop for many legacy Q-SYS devices. It is also a way-station on any upgrades to QDS 10 and above. That is, you will need to pass through QDS 9.13 on your way to QDS 10. However, if you decide to go back to a lower QDS, QDS 9.10 is required for downgrading (a Core) back to 9.9 or below (e.g. 9.4.8 LTS). Complicated? Read the release notes on upgrading/downgrading.

Upgrade Path

Downgrade Path

[Steve Guttag]

Correction. When upgrading from below 9.10, you need to pass through 9.10 on your way to 9.13...which is required on your way to 10.0 and above. For downgrading, you do need to do it incrementally (and we're talking the Core). From 10.x to 9.13. Then from 9.13 to 9.10, which requires one to open Core Manager to "allow old authentication method."

So, downgrading is something that is a bit cumbersome. Hopefully, 9.13.1 LTS will be a winner and the upgrade path will just be a 1-way exercise. As usual, I plan to sit back a few weeks to see if "others" find problems before putting my toe in the water. My initial checks on my designs are showing that 9.13.1 is similar, if not the same resources as 9.4.8 LTS when using Check Design. So, if 9.4.8 (LTS) works for your design, so should 9.13.1 (LTS).

Just note what peripherals may no longer be supported. If not, stay on 9.4.8 LTS. It has been solid for me. I think the I/O Fram 8s (the one that holds 8 cards like a Core 510) is the only piece that might be in a cinema that isn't supported in 9.13.1 but is in 9.4.8 LTS. Core wise, any on Core 250i or Core 500i should stop at 9.4.8 LTS.

[Tj Hopland]

Has anyone used the QIO-IR-1x4? Its basically an endpoint that has 1 IR in and 4 IR outs. You connect those universal IR 'bugs' that you then stick on the front of mostly consumer gear allowing Qsys to send IR codes as if it was coming from the remote control. An example of how this may be used is if there was a cable/satellite box being used as a video source. There doesn't tend to be 'pro' versions of those, you kinda got to take what ever the local provider provides so mimicking the IR remote may be the only control option.

My question is how easy is this product to deal with? I'm well aware of the gotchas of consumer gear like toggle controls rather than direct discrete commands. What I want to know is how did QSC implement this? If there is some sort of published codes can those just be entered? Or if the codes are some sort of digital file can those be imported? If you have a IR receiver connected and the original IR remote can you 'learn' the command as a manual setup so to speak in designer? If learning is possible could you build that option into a UCI?

I'm not entirely sure why you would want to at least in a cinema type of environment but I'm assuming if you wanted to use any random IR remote to control things under the control of Qsys you could as long as you wired in a IR receiver to the in port? I guess one reason would be zoning and security. IR has to be fairly close(ish) line of sight so you would not have any interference from other auditoriums and would not need a specific remote for a specific auditorium. Since its line of sight can't be 'hacked' unless the hacker is in the room. I wonder if you had a reciever in a typical auditorium and were using a USL/QSC/MIT HI/VIN/caption panel if it would pick up that signal and possibly overload it? I would imagine the frequencies are different but since that's not a problem you would often run into did anyone design filters to only 'listen' for the proper range of signals?

[Steve Guttag]

Correction to the Correction...when downgrading from 9.13 and above, you need to pass through 9.10 to get to versions below 9.10. I have done several, now, 9.4.8 LTS to 9.13.1 LTS and they all went well and in just the one step.

I have not use the QIO-IR-1x4. I have used the Global Cache equivalent (and came out before the QIO, hence I used it) and they have worked fine. The use-case was to control things like "cable boxes" or TVs and other gear that does not have Ethernet or RS232 support. There is a pretty extensive library (Tower) of known IR commands already figured out. That doesn't mean everything will always work but if you are considering either solution, check to see if the thing you want to control is already listed.

[Leo Enticknap]

I've also used IP2IRs for exactly the same use case, and like Steve, have found that they integrate with Q-Sys well. Even if the device you want to control isn't in the library, Global Caché has a separate Windows app that will enable it to learn commands from the remote that came with the device.

Meanwhile, I wondered if anyone had tried to use NV-21-HUs as USB endpoints to enable DCP ingestion from a USB CRU reader in a rack (the rack also contains most of the Q-Sys hardware) to an IMS3000 in a projector pod about 100 feet away. This is a perennial problem we've been having in multiple installations with projectors in pods. To ingest from physical media you have to go into the server's USB port (or mess around with FTP from a PC somewhere else, and the technical hurdles involved in doing that are unrealistic for someone who isn't an IT professional to get involved with). To avoid the need for the end user to have to climb up a ladder every time they want to ingest a DCP, a long USB connection is needed to be able to put the CRU reader a significant distance away.

USB2 over Ethernet cable extenders are a dime a dozen, reliable, but slow. The only USB3 extenders we've been able to find are hellish expensive and flaky. We've had trouble whenever we've installed one, usually with it locking up and requiring both endpoints and the IMS3000 to be rebooted before an ingest can be done.

I therefore wondered if it would be possible to use the USB functionality of Q-Sys video endpoints to enable a USB3 over Q-LAN connection for ingest. You can with the Visionary Solutions endpoints, but again, for USB2 only, and in most systems you're lucky if you get 20 MBPS.

So on an install earlier this week, I tried, as so:

image.png

...and had absolutely no luck. I tried every possible permutation of the USB bridging options (highlighted), and the connections at both ends using the USB C and USB 3.1 A jacks. Connecting the USB C jack of the projector decoder to the USB 3 input of the IMS3000, I got a green light on the Q-Sys status indicator, but with a USB flash drive containing DCPs (known good; confirmed by connecting it directly to the IMS3000) connected to the rack encoder, Q-Sys did not recognize a connection, for either port.

Does anyone have any idea if this was simply me doing something stupid, or if Q-Sys doesn't allow this sort of connection, and will only let you use USB bridging for video, audio, and/or HIDs (i.e. not for data transfer between USB storage devices)?

[Ioannis Syrogiannis]

I haven't ever used a peripheral, but based on the fact that the USB-A port provides 0.9 A and the only mention (other than A/V) is about HID control, it seems more probable to be around the area of USB 2.0 and to target keyboards and mice. Let us know, if you find otherwise!

Edit: I wonder what that ingest speed of USB 3.0 would do to the traffic of the Q-SYS network.

[Steve Guttag]

I've had luck with Tripplite's USB3 (and USB2) extenders but they were the wired kind...more of an active cable, not networked or using TP cable. The use case was a projector over the A/V booth (museum) and needed to be able to ingest from the booth.

Extron has USB extenders but if you want to be in the 5Gb/s range, you need to go fiber with them. For copper, 480Mb/s. I general, if I need something to work, I trust Extron.

To answer your question. No, I have not used the NV endpoints for even video, let alone USB. From what I can gather, NV can look awesome and you can get full-motion video on your preview (touchscreens)...but it does not handle bitstream audio, you get limitations if you are transporting 4K, it leaves you with overhead on dealing with multichannel audio. Another thing that concerns me is how Q-SYS will discontinue support for their products within QDS. Most of those concerns are simply not there with Visionary Solutions.

[Leo Enticknap]

This system has a Netgear AV switch that can handle several gigabits of throughput and several HDMI encoders squirting 4K at 750 MBPS into the Q-LAN, so I'd have thought that the 50-100 MBPS needed for a USB3 ingest wouldn't have been a problem. With a cheaper switch, or across multiple switches with uplink or LAG chokepoints, though, I'd have been more reluctant to try it.

[Marcel Birgelen]

My problem with Q-Sys is that they're rolling their own proprietary stuff for everything and now also video (Q-Sys Shift), instead to conform to open standards like SMPTE 2110 or something considered to be a de-factor standard like NDI...

[Leo Enticknap]

It wasn't my decision to use QSC video endpoints for this project, and for a whole slew of reasons I'd always prefer Visionary Solutions. That having been said, the video side of things seemed to work well this time, without the HDCP and EDID problems I ran into the last time I tried to install them. I suspect that the software/firmware changes between whatever 9.x version I was using last time (about a year and a half ago) and 10.0 (this time) successfully fixed a lot of bugs and stability issues.

[Marcel Birgelen]

Visionary Solutions is pretty affordable actually, especially compared to e.g. Crestron. The thing is, those AV/Audio over IP solutions all tend to cook their own protocols. If you go Crestron, you go Crestron all the way... Something like that will never fly in live productions.

I like Visionary Solutions, even though they're also rolling their own protocols, but their APIs are pretty open and good, compared to the rather cumbersome Q-Sys APIs, at least the documented ones.

[Steve Guttag]

Then again...even within Visionary Solutions...Series 4 is not compatible with Series 5. An advantage with proprietary is there isn't any finger pointing when things don't work. I spend more time arguing with various companies as to who is at fault when things like AES67 don't work as it should or even within Digital Cinema...why didn't the caption show on the screen when everyone is DCI compliant? When transporting via twisted pair and using a reasonably common HDBaseT...it always works until a critical show. The reason I often jump to Extron and a proprietary format (though they are often quasi-compatible with HDBaseT on their DTP series) is that it always just works. It removes variables. So I'm good with proprietary in some situations.