DMX2-24 - Interesting Flickering

[Skymaster]

Hi all,

I'm encountering an interesting flickering issue with one particular string set on a DMX2-24 board.
Basically, if I set the DMX channel for one half of the string on, with the other channel off, 99% of the time, it's lit up correctly.
However, there is flickering to the other channel for a few 10's of milliseconds every 5 or so seconds, but it's random.

It's not an issue with the controller or DMX input, as it happens on every output, but only with this particular string. Other string do not exhibit this issue.
Additionally, if I parallel this string with another string, the issue does not occur.

Video of what's happening - the Yellow/Green channel is set to on, the Blue/Red is set to off. You can see the B/R channel illuminating a couple of times very quickly. Note the pulsating on the GY channel is to do with the video capture, it's not occurring in person.



The scope output of the channel (in respect to gnd) when it flicks is showing the polarity reversal for two or three cycles:



Has anyone seen this behaviour before, and can account for it? I'm thinking it might be load related, but I'm not sure.

Cheers
M.

 

[AAH]

I have no idea why it could be doing this but obviously I'd like to get to the bottom of it. Out of curiosity does it do the same with the polarity of that string reversed?
I might need to organise to borrow that string of leds to see if I can work out the cause.

 

[Skymaster]

I'll run a test - however this also occurs when I light up the opposing channel- turning on the red/blue channel only flickers to the G/Y leds at a similar (random) frequency as the above video.

For the moment, GY is Ch3, and RB is Ch4 - test above was with Ch3 lit up. If I enable Ch4 only, the reverse occurs.
Note that with both channels for the string switched on, it behaves normally, likewise with both disabled.

It's not a huge issue, buying a replacement string from Bunnings isn't difficult, but it'd be curious to know why it occurs.

 

[Skymaster]

Alright, so it appears I was completely wrong in my assumptions & testing. It's not string related - the issue occurs no matter the string.

The problem is across every second pair of outputs. It just so happened to be that I was using the first 3 pairs, and I moved string from 3+4 to 7+8 when the issue occurs. I'm not sure why I didn't notice it on 3+4 with a different set connected yesterday.
So the affected pairs are 3+4, 7+8, 11+12, 15+16, 19+20, 23+24
The other pairs are all working fine.

I hooked up two strings, one to 19+20, and one to 23+24. I set channels 20 and 23 being on. Both strings flickered simultaneously.

I also notice that there is a flicker (just minor deviations in intensity, not completely out) that is timed with the blinking of the LED on the DMX output - I had originally thought this was because of the switching between the polarity - but when I disconnect the DMX, the lights go solid for a few seconds before going out (due to lack of DMX). This occurs across all outputs & no matter whether it's one or both halves of the string lit up.

At this point, I'm now no longer ruling out dodgy DMX data / decoding. The setup is the USB DMX plugged into a Pi with FPP, a 15cm ethernet cable connected to the DMX2-24. Termination is enabled. Testing is being done using the light test function within FPP outputting the channel data. I'm testing with full white / 255.

 

[Skymaster]

Next round of testing - definitely DMX related.
Plugged the USB dongle into a Windows machine I had lying around and fired up da_tester from David_AVD.
Points to note:

- On initial startup, the frequency of issue was lower, but the flicker time was longer.
- With the one channel dimmed, and the other channel at 100%, the values would swap - the dimmed channel would become bright, and the bright channel would go dim during the issue

- Modifying the "Idle DMX Packet" setting - how long between sending DMX packets when not changing values - modified the behaviour.
- By default, the software sends idle packets at 100ms. The data LED is flickering slower than when FPP is outputting data, so I'm assuming FPP is sending data as fast as possible. (every 22msec at a guess based on DMX standards)
- Increasing this above 250-300ms caused the problem to disappear.
- Decreasing to 30ms (lowest possible in da_tester) brought back similar behaviour to FPP.

Also - reducing the number of DMX packets (increasing idle updates to say every 1 sec) reduced the overall flickering mentioned in the second last paragraph of the update above, the display was rock solid with this set.

 

[AAH]

I was actually going to get you to test at 20fps and 40fps sequence speed in xlights but you've gone beyond that.
I will dig into the code and put the scope on a board in a few days. I'm currently thinking that it's an interrupt related issue with the incoming dmx causing a glitch every now and then while the data is being written to the outputs.

 

[Skymaster]

Awesome, thanks Alan - let me know if you'd like me to perform any more tests to assist.

 

[Jonesy928]

Hi guys, did you end up finding the cause for this? I have the dmx2-24 setup and when turning the channel on linked to my blue & green leds I will get the red & oranges ones flicking on randomly.

 

[Skymaster]

FPP DMX timing it appeared to be for me. I ended up driving the board from the DMX output on the Falcon controller rather than via a USB-> DMX adapter.

 

[Jonesy928]

I’m currently running direct from the DMX on a f16v4. At the moment I’m testing outputting directly from xlights.

 

[Skymaster]

Oh wait, maybe it's still occurring. I remember what I did initially which is still in place......rather than using 1-2/3-4/5-6/7-8 for my 4 strings, i used 1-2/5-6/9-10/13-14 - which were the unaffected outputs

 

[Jonesy928]

Hopefully there is an easy solution. I’ve got 2 dmx2-24 and planned to use all the ports.

 

[Skymaster]

Just following this one up. I've now rewired my board to use all the outputs with extra strings this year. Still seeing the behaviour driven from the Falcon.

Seems by USB->DMX has crapped out too which got me spinning my wheels for a few days wondering what I did when I switched the board into a new enclosure.

Right now I'm going to try driving it from am ESPixelstick, and slowing down the E1.31 data to it, see if that helps any.

 

[AAH]

Just following this one up. I've now rewired my board to use all the outputs with extra strings this year. Still seeing the behaviour driven from the Falcon.

Seems by USB->DMX has crapped out too which got me spinning my wheels for a few days wondering what I did when I switched the board into a new enclosure.

Right now I'm going to try driving it from am ESPixelstick, and slowing down the E1.31 data to it, see if that helps any.

I'll shoot you a fresh board to see if it's something peculiar happening with that board.

 

[Skymaster]

I'll shoot you a fresh board to see if it's something peculiar happening with that board.

Thanks mate. Will dig in deeper and definitely let you know results. It's an interesting one for sure.