ETC Ion flashing issue

[TobyKLight]

First off - thanks so much for making this. It's pretty impressive to get E131 running on a tiny ESP8266 and doing some wireless pixel goodness.

The issue I'm having is that everything worked fine with my test controller - a software solution called QLC+ (http://www.qlcplus.org/)

But when I connected it to an ETC ION lighting console (Running software v2.2.1) it works but there are intermittent random flashes.

Debugging revealed those flashes were e131.data[#] values jumping to 200 inexplicably.
For now I've made a hack solution where I've modified the sketch so it doesn't process pixels when the value is 200.

This could be an issue with the ION but it seems unlikely given ETC is on the working group that setup the E131 standard. You think they'd implement it properly.

I understand no-one can do much about this without an ION console handy, and I'm afraid I've run out of time to look at this problem. But I thought I'd open an issue and get it out there in case anyone else runs into it.

[nccwarp9]

for a while Ive been trying to get ws2811 work with esp8266 and am so happy I found this. I have also been getting random flashes but I think that's can be fixed by adding a 100p cap across GPIO0 to GND. I will try it later today.

[forkineye]

@finechap Do you have any packet captures from the network when this happens? The ION may be sending something that I shouldn't be processing as channel data.

@nccwarp9 If you're wanting to do WS2811, checkout my ESPixelStick project here - https://github.com/forkineye/ESPixelStick

[nccwarp9]

that is one seriously nice project. I got a question, I have a led panel with 288 leds. From what I read universe can take up to 170 rgb leds. Is it possible to set up 2 universes on a single esp? or will I have to add it in the code ?

[forkineye]

@nccwarp9 It'll handle it just fine via unicast. Here's my 720 pixel test matrix (just over 4 universes) being driven by one ESPixelStick - http://www.youtube.com/watch?v=perR5NHttQ4

[mkohler99]

I can confirm this issue as well. We have 8 boards running this library with an ETC element and we saw flashes of channels to 100. On a GrandMA2 with the same boards and code, the issue was not observed. I'm assured by my contacts at ETC that their ACN implementation is more correct but it seems to cause issues with this library

[jmusarra]

What you're probably seeing is DD start code data. Consoles can transmit this information to enable users of multi-controller systems to merge data sources on a per-channel basis. Normal dimmer data (DMX) has a start code of 00 - also referred to as Null Start Code data. Only this 00 start code information should be interpreted by receivers as dimmer level data. Other start codes should be handled according to this document: http://tsp.esta.org/tsp/working_groups/CP/DMXAlternateCodes.php , or simply dropped.

[peerstelter]

I don't know how to fix...
but the Problem with ETC Desks is that the code interpret the Priority of the ACN Stream.
If you set the Priority to 100, you get flashes off 100.
if you set the priority to 200 you get flashes off 200 and so on...

[ThomasH-W]

Thanks to this thread, I got the hint what to do.
My fix for this issue:

Update e131.h for two lines

1. add the declaration for ddStartCode (2nd line)
   public:
   uint8_t data; / Pointer to DMX channel data /
   uint8_t ddStartCode; / DD start code data*/
   uint16_t universe; /* DMX Universe of last valid packet */

2. function "inline uint16_t parsePacket() {" : add the 2nd line in order to set ddStartCode

            universe = htons(packet->universe);
            ddStartCode = *packet->property_values;
            data = packet->property_values + 1;
   

3. in the udp handler after receiving the package, you need to check the ddStartCode
   if (e131.universe == universe && e131.ddStartCode == 0)

[forkineye]

This completely slipped off my plate. I'll get a fix pushed this evening that ignores alternate start codes, just need some of you guys with those fancy console to test it :)

[forkineye]

Possibly fixed in b6c7071, but I'm unable to test it. Can anyone test it and report back? Thanks.

[forkineye]

Fixed - b6c7071