Q Light Controller+

hello

i have recently started using QLC+ on the Raspberry Pi as a solution for some wifi based lighting needs. We are building a show which requires being able to talk to dmx addressable fixtures over wifi and this software seems to work really well. We are using Chamsys MagicQ as the lighting software and controller (it is integrated into a much wider show) and broadcast Art Net data to speak to QLC+ over a wifi network. It worked seamlessly in terms of broadcasting Art Net out of Chamsys into QLC the first time. However I find Art Net to be a bit laggy when broadcasting lots of data (i.e. strobing effect) and am keen to use E1.31 instead. We already use this for other parts of the show to drive WS2801 led pixels and it is lightning fast with zero latency for controlling thousands of pixels. However I cannot seem to get QLC+ to accept E1.31 data as an input. I select it as the 'input' and select my USB/DMX interface as the 'output' with the 'passthrough' box ticked but get no results..If i instead set the input to ArtNet (and change the output settings on Chamsys from ACN to ArtNet) it instantly starts working.. so they are both sat on the same network and can talk normally.. however i just cannot get the E1.31 implementation to work.. any suggestions? has anyone had any luck broadcasting E1.31 data to QLC+ and outputting DMX over USB?
any advice / suggestions would be really welcome

as a bit of an update - been prodding around and running some tests and have identified some strange behaviour..
using a simpe E1.31 tester ( http://www.da-share.com/software/da_e131/ ) i was able to get the QLC+ on the Pi 2 to respond to E1.31 commands (outputting dmx data on universe 1 via an usb=>dmx interface) but only when broadcast in Unicast mode with the ip of the raspberry pi specified in the settings. If I set the tester to broadcast in multicast - the QLC software did not respond. I tried this out with the sACN viewer also and found the same response .. am I right to assume that the E1.31 implementation on the QLC+ only work in Unicast?

Weirdly enough - if i try and broadcast the ACN signal out of Chamsys MagicQ set to unicast mode with the pi's ip address it still does not respond.. i can see the data going across the network with the sACN viewer but no joy out of the raspberry pi...

I need to test this out myself. Can't help for now.

One thing though is that I don't believe E1.31 will give you better performances over ArtNet. They both transmit UDP packets and moreover E1.31 has more payload overhead than ArtNet.
In general, also, I think it's a bad idea to use those network protocols via WiFi. In any case you will experience latencies and jitters.

Anyway, give me a couple of days to test E1.31 input. Since E1.31 is not so common, the only tests I've done were on the DMXking eDMX2 TX device. So basically E1.31 only in output mode.
Looking at the code, you might be right and could be that QLC+ listens on the network card IP address rather than a multicast address. In that case, I will fix the code.

thanks for your reply - and really grateful you will be able to have a look at this.
i was wondering if you had any suggestions for more suitable wifi friendly protocols? the application for this project requires to transmit the data wirelessly ( the lighting sculpture is spinning at 400 rpm) we have had some great results in the past using E1.31 with a pair of bridged wifi routers and one of these: http://www.j1sys.com/products/lighting/ECG-P2.html we were able to address over a 1000 pixels and speak to them with pretty much zero latency. we did not broadcast the SSID of the network and used fixed ip's to avoid any form of encryption / password protection as that did produce some noticeable delays. but was wondering if there is a better way of controlling lights over wifi?

Well, ArtNet and E1.31 are friendly network protocols if they provide a continuous stream of data, don't get me wrong.
What I am referring to are the issues specifically related to the WiFi stadanrd. You correctly named one which is the encryption, but there's also:
1- the signal strenght problem (walls in between ? Large metal objects ?)
2- channels overlapping problem (in case other wifi networks are present)
3- interference from radio signals in general (e.g. microwaves !)

I don't count the mixed mode issue (B/G/N) because I assume you will be in a controlled network where all the WiFi clients talk the same standard.
In general WiFi has a lot of weaknesses. The good old cable is not affected at all by the above.

I experienced a huge latency especially with smartphones, where the Android drivers tend to go into sleep mode to save battery. This causes a huge delay when transmitting changes of data, and it is not acceptable in a production environment.

Since I worked for 12 years in a telecommunication company, I remember we had a nice product dedicated to the video streaming. I believe it was based on some MIMO antennas, which are known to provide a better efficiency in terms of signal stability.
Could be something like this, but please have a deeper look than mine:
http://www.amazon.com/s/ref=nb_sb_ss_c_ ... nics%2C332

However, video streaming is not like ArtNet or E1.31. They both work on UDP (and most likely multicast) but the advanced codecs like H.264 have a lot of mechanisms to recover data loss, by interpolating pixels and applying some DCT smart algorithms.
This is not the case with ArtNet and E1.31. They don't provide any error recovery, so when you miss a few packets, the effect could be immediately visible with the eye (like a non smooth fade or a weird flash)

OK, enough writing. In the end I still believe ArtNet works fine. Maybe what you need is a more robust WiFi AP...so in the end it's just a matter of how much you spend on it

thanks for that - lots of food for thought. will keep on testing out results - keep finding other really useful features in the software! has made us totally reconsider how we can control our show.
Look forward to your results from the E1.31 input implementation and testing latency comparison between Art Net / E1.31 !

OK, I'm on the E1.31 code.
There's indeed something wrong as the input doesn't receive anything from a multicast address.
I already found the cause, but it's not an easy fix.

[EDIT] It's fixed now on GIT

that's great - thanks for looking into this. will take a look on github and have a play.