Analog inputs on Windows

Ask a question about the usage of QLC+ with the Windows operating system
Post Reply
rickm
Posts: 6
Joined: Wed Oct 18, 2017 1:14 pm
Real Name:

Hi everyone,

I'm looking into using an Intel NUC or similar Windows device to run QLC+.
I need to be able to use analog signals as input triggers for functions. Those are 12V signals, but can be stepped down to e.g. 5V or 3.3V if needed.

What's the easiest way to get such signals working as inputs in QLC+ under Windows?
A bit like the GPIO on a Raspberry.

Happy to hear your thoughts,

Rick
User avatar
GGGss
Posts: 2989
Joined: Mon Sep 12, 2016 7:15 pm
Location: Belgium
Real Name: Fredje Gallon

You will at least need an interface to process the analog inputs. But I'm not aware of any interface that is supported by QLC+.
For the cost of the interface, you could invest in a Raspberry, use the GPIO's and use Artnet f.i. to tranfer the measured values.
All electric machines work on smoke... when the smoke escapes... they don't work anymore
janosvitok
Posts: 1307
Joined: Mon Apr 13, 2015 7:05 am
Location: Bratislava, Slovakia
Real Name: Jano Svitok
Contact:

If you are able to do some C++ coding, you may use arduino/raspberry pico as interface. It's more complicated to setup (since you have to write the plugin), but easier to maintain (no SD card,...)

Jano
rickm
Posts: 6
Joined: Wed Oct 18, 2017 1:14 pm
Real Name:

Thanks for your responses!
I'm not really able to code unfortunately. There are no off the shelf solutions for this?
janosvitok
Posts: 1307
Joined: Mon Apr 13, 2015 7:05 am
Location: Bratislava, Slovakia
Real Name: Jano Svitok
Contact:

Analog input to DMX is not very frequent usage, so I suppose those that need do it themselves. The other way is more frequent (DMX-> Analog output), the keyword here is DMX/Artnet relay/switch.

For your case, the raspberry seems to be the simplest way how to do it.
You can run the whole show on rpi, or leave rpi just for feeding the analog inputs to the nuc, and run the show there.

Jano
rickm
Posts: 6
Joined: Wed Oct 18, 2017 1:14 pm
Real Name:

Or maybe anyone sees another solution?
Let me explain the use case in a bit more detail :)

We're using QCL+ in our Carbage Run car to control a lot of lights and sound effects.
Some of these effects need to be coupled to the 'normal' controls of the car. E.g. the horn, indicators, main beam, etc.
We wired into those controls, so we get a ~12V signal when we use those.

Those 12V signals need to be used as inputs for QLC. They're basically on/off, nothing linear.
User avatar
GGGss
Posts: 2989
Joined: Mon Sep 12, 2016 7:15 pm
Location: Belgium
Real Name: Fredje Gallon

So binary inputs... now I surely would go the rpi way and have those signals schmid-trigger buffered and put onto the GPIO pins of the rpi.

[edit] a more ready-out-of-the-box solution could be this one: https://ultralightsound.co.uk/product/a ... convertor/ You will need 2 resistors per input to change 12V to 10V.
All electric machines work on smoke... when the smoke escapes... they don't work anymore
rickm
Posts: 6
Joined: Wed Oct 18, 2017 1:14 pm
Real Name:

Hi everyone!

I finally had some time to work on this :) But I don't yet know how to actually get the GPIO signal to ArtNet. The rest works.

My current setup:
- QLC4 on the NUC
- OLA (Open Light Architecture) on the Pi
Both connected with ethernet cables through a router with static IPs.

In OLA (on the Pi) I set up ArtNet output on Universe 1 (which corresponds to Universe 2 in QLC, as OLA starts counting at 0 and QLC at 1...).
On Universe 2 in QLC (on the NUC) I set input to the ArtNet device with the IP of the NUC. I already use a MIDI input on QLC Universe 1, so I had to use multiple universes just for input.
I can now in OLA manually set the level of a channel in OLA universe 1 to e.g. 255.
In the Virtual Console in QLC I then configured an External Input from Universe 2: ArtNet and the channel number that I set to 255 and toggle scenes and chasers with that.
So far so good.

The only thing missing now is mapping the GPIO inputs in the PI to a ArtNet output.
That's maybe more an OLA question than a QLC question, but maybe someone here knows how to do that.
With the GPIO plugin for OLA I can only set GPIO as an output it seems, not as input.

Any ideas?

Regards,

Rick
User avatar
GGGss
Posts: 2989
Joined: Mon Sep 12, 2016 7:15 pm
Location: Belgium
Real Name: Fredje Gallon

Depending on the image you use for the Pi, you must define whether a GPIO will be used as an in- or output. This has to be done system-wide (so it is not a setting in QLC+).
Once that is done, you can use the GPIO's inputs as a source for buttons on your Virtual Console. Whatever functions are bound to those buttons are equal. If you have some generic dimmers in your Artnet universe, you can send values by pressing the buttons and/or using the GPIO's.
All electric machines work on smoke... when the smoke escapes... they don't work anymore
rickm
Posts: 6
Joined: Wed Oct 18, 2017 1:14 pm
Real Name:

Thanks for your answer.
For some reason (didn't dive into it yet), I couldn't get QLC+ on the Pi to successfully send stuff through ArtNet to QLC+ on the NUC.
When I set QLC+ on the Pi to output a universe to ArtNet, it isn't discovered as an ArtNet node by QLC+ on the NUC.

So therefor I switched to using OLA on the Pi.
rickm
Posts: 6
Joined: Wed Oct 18, 2017 1:14 pm
Real Name:

Hi everyone,

I've got it working! At least on my desk, still have to test in the car.

In the end I needed to, for some reason unknown to me, not use 192.168.0.10 (which is the IP address of the ethernet port of the NUC) as the input ArtNet device but the rather strange IP address 169.254.30.166... Which is some IP address Windows assigns when DHCP is not successful. Might be the case, because I use static IPs.

Strange thing is that with e.g. The ArtNetominator discovery app, I do select the IP address of my ethernet adapter (192.168.0.10) as the device to listen to.

Anyhow, I hope Windows doesn't decide to change this 169.254.30.166 address to something else.
If anyone understands how this exactly works, I'm happy to hear more about it :)

Now I only have to really test it with the GPIO inputs, but that already worked on the Pi before so I'm quite confident it should be fine.

Thanks all!
Post Reply