Flickering SK6812's in random areas [Raspberry PI + Dig Uno as level shifter setup]

[stickmanbrad]

Hi there,

Hoping you can help. I've been experiencing some extremely frustrating issues surrounding flickering led's in random patchy areas when watching any type of content. I have a bit of a different setup which I mimicked from another project.

Setup specification:

• 217 Leds (Cool White SK6812's) around all 4 corners of my television
• Raspberry Pi 4 8GB (GPIO 18 passing to dig uno - used for level shifting and fuse protection, ground pin connected to ground wire from LED's)
• Meanwell 5V, 18A open power supply - Have tried powering both raspberry pi and led's, but since separated them with shared ground wire with pi having it's own power supply)
• The run from the Raspberry Pi to the Dig Uno is very short less than 5cm, but from the Dig Uno to the Led's is about 2m for the output positive, negative and data wire
• Zasluke Capture Card 4K 60 passthrough

Overall in most situations I have found the effect to be very pleasing. However, I do often get this flickering effect in random areas and it can be very distracting. I have tested all connections round the TV, of which appear to have good continuity. I have insured that the Dig Uno is set to 33Omhs (as a level shifter). It's very hard to figure out what the problem is as I can often see an LED just flickering. That appears to be the norm. But that moves to different led's. I have even replaced sections of LED's thinking maybe they were faulty.

Attached is the performance data and other pages from the dashboard. I did wonder what the high number in red next to the bin icon meant.

I would be really grateful for any insight into what might be causing this issue. I did even wonder whether I just need to move the PI, dig uno (used as level shifter) and capture card up by the tv for a shorter direct run to the LED's. Maybe that would help? But I was under the impression you can carry out a fairly long run up to 10m. I am using 12AWG which ensures there isn't much voltage drop.

I can provide logs if need be, but to tell you the truth there are not any errors that I can see.

Kind regards in advanced :)

[stickmanbrad]

*Just a little update as I've been playing with some of the settings.

I went into the 'Image Processing' tab and came across the 'Anti-flickering threshold value'.

I then had a read and saw that it suggested a value of 32. I looked at the Led's behind my TV and found a Led that happened to be flickering. Applied the setting of 32 and it instantly went solid - No flicker. Now I'm not sure yet if that is the whole solution as some additional options then appeared ('Anti-flickering minimal step' & 'Anti-flickering timeout' - Will attach screenshot). Could this be related? - And why would it be required?

Although I do now get this in the logs: 'High resolution clock is NOT STEADY!'

Again, I'm not holding my breath that this is the solution and am still expecting flickering when I test more tonight. But thought I'd add this into the post.

[awawa-dev]

Hi
2m data (voltage drop & EMI noise) and power cable (voltage drop) is definitely not a good thing. I would move at least the LED power supply and ESP32(HyperSerialESP32) closer to the LED strip. You can still have your Rpi 2m away from the ESP32, because such distance is perfectly safe for USB using good cable. Of course you still need a common ground between ESP and the LED strip. Unfortunately, the latest version of QuinLED-Dig-Uno has such an unfortunate construction and the fuse blocks the USB socket, so this ESP version cannot be used here.

Try to enable 'continues output' If it still works then anti-flickering filter is the solution and the problem in your case is the video source. Read more about this here: https://www.hyperhdr.eu/2021/04/how-to-set-up-hyperhdr-part-i-basic.html#chapterFlickering

[stickmanbrad]

Hi 2m data (voltage drop & EMI noise) and power cable (voltage drop) is definitely not a good thing. I would move at least the LED power supply and ESP32(HyperSerialESP32) closer to the LED strip. You can still have your Rpi 2m away from the ESP32, because such distance is perfectly safe for USB using good cable. Of course you still need a common ground between ESP and the LED strip. Unfortunately, the latest version of QuinLED-Dig-Uno has such an unfortunate construction and the fuse blocks the USB socket, so this ESP version cannot be used here.

Try to enable 'continues output' If it still works then anti-flickering filter is the solution and the problem in your case is the video source. Read more about this here: https://www.hyperhdr.eu/2021/04/how-to-set-up-hyperhdr-part-i-basic.html#chapterFlickering

Hiya,

Thank you so much for the quick reply. Yes - I had a feeling that what I've done might not be ideal.. And that option is still on the table at last resort. In regards to the 'continues output', would I still leave those anti-flickering settings as mentioned in previous screenshot? Or disable that, and enable 'continues output'?

Furthermore, the part where you mentioned about being able to have the raspberry Pi apart from the dig uno, power supply and Led's, wouldn't be possible because I'd still need gpio 18 (data) and the ground as you mentioned nearby? There are no USB's involved other than for the capture card. I have taken the ESP32 off of the dig uno so that the raspberry pi is purely running things through the built in level shifter and fuse protection. That's the only reason i'm using the dig uno.

In regards to those performance figures, are you able to also let me know what the red number next to the bin means? - I've also noticed the data numbers that get pushed don't seem to be coming back with the same amount. So does it seem likely that the long run is having an effect on that? - Because i've seen some users have say 3000 go to the Led's and then 3000 come back.

Again, huge thanks in advanced.
Brad

[idarius]

hello @stickmanbrad,

Sorry to dig up an old post but i've some questions for you if you don't mind.

• Have you still your flickering issue with this setup ?
• Can you post a picture of your wiring between the Rpi, esp, dig uno and your power supply ?

I have a dig uno that i want to use for the fuse and level shifter, but i don't find any exemple.

Thank you !

[awawa-dev]

Thank you so much for the quick reply. Yes - I had a feeling that what I've done might not be ideal.. And that option is still on the table at last resort. In regards to the 'continues output', would I still leave those anti-flickering settings as mentioned in previous screenshot? Or disable that, and enable 'continues output'?

Antiflickering filter may reduce refresh rate (because it eliminates noise, minimal changes on dark park are not updated on the led strip,) so to make sure I asked you to enable 'continues output' that forces maximum refresh rate on the LED strip to confirm that antiflickering is the real solution. You should disable 'continues output' (it sends a frame even if it is not changed) when you finish testing.

wouldn't be possible because I'd still need gpio 18 (data) and the ground as you mentioned nearby?

in my proposed solution you should use Adalight driver in HyperHDR which communicates with the ESP32 (HyperSerialESP32 firmware should be uploaded on ESP32) over USB. The common ground is between ESP32 and the LED strip ground in such case (it will be forwarded over USB to Rpi also...but it is not important).

In regards to those performance figures, are you able to also let me know what the red number next to the bin means? - I've also noticed the data numbers that get pushed don't seem to be coming back with the same amount. So does it seem likely that the long run is having an effect on that? - Because i've seen some users have say 3000 go to the Led's and then 3000 come back.

Not sure which HyperHDR version from which date you are using: there was a problem with statistics when the LED device 'Refresh time' was set. But it should be fixed in the latest. Regardless of the statistics problem: 'Refresh time' should be set to 0 for better performance of ws281x or adalight awa driver because these are high performance drivers. It generates unnecessary delay only.

[awawa-dev]

Hiya,
What I did was I re flashed the esp32 which comes with the dig uno with that firmware. The led output is typically on gpio 16 (hence why I changed the config. I then ran that into the led pin in the dig uno. I also put a ground lead from that esp32 to the LEDs. It did work but still had to put the anti flickering settings on it..
Do you agree that it’s probably best I still move everything closer to the tv with shorter runs?
Kind regards

To keep it in one place I move it to the HyperHDR discussion.
It may help other users also.

To clarify: your problem was caused by the your video source because the anti-flickering filter solves it.
It was not caused by high refresh rate and/or EMI interference of data signal on long cable, because even if you enabled the 'continues output' it still worked for you.

If you are happy with the current result you can leave it as it is. It's good that you dropped that GPIO18 and direct driving ws218x from Rpi and you are using Adalight now, because generating signal on Rpi is not a cheap thing: it takes a lot of real time resources which other drivers or applications (including HyperHDR) need. Still 2 meters data & power cables is not a good thing.

[stickmanbrad]

It's important. Try to increase Backlight threshold to 2 or 3 and test it again. Probably 1 is too low for your setup and real black color RGB(0,0,0) disables anti-flickering filter.

Hiya,

So increased to ‘2’, and did the RGB(0,0,0) test and still no lights. Then went to ‘3’, which then provided a low white glow. Is that what we are looking for?

Apologies I’m not quite understanding what this means.

Kind Regards

[awawa-dev]

Yes, stay with Backlight threshold at 3 and re-test anti-flickering filter. Previously if some RGB value from the video source was fluctuating around RGB(0,0,0) the anti-flickering filter could not prevent it from changing rapidly.

[stickmanbrad]

Yes, stay with Backlight threshold at 3 and re-test anti-flickering filter. Previously if some RGB value from the video source was fluctuating around RGB(0,0,0) the anti-flickering filter could not prevent it from changing rapidly.

Thank you, I’ll test that and see how we get on. I use the HA hyperhdr app to turn down the brightness of the LED’s as I usually find them too bright. I do this pretty much every time I boot up. Will the lower brightness change what is needed here for the backlight threshold. The reason I say this is I notice it tends to default to much brighter quite frequently (like a brightness reset or something).

Also in regards to the latency, I mentioned that splitter above. Would that be something I should be looking at, or is the loop-out going to behave just the same?

Initial indications suggest that the ‘Backlight threshold’ has helped with the latency problems, but might not be related at all.

Kind regards

[awawa-dev]

One thing I did want to run by you (which may help others), obviously you requested I set the ‘Refresh Time’ to 0.

Make sure your refresh rate in the smoothing is set to reasonable value. I really don't know what happens to that unsupported LED driver: like I said it's not a cheap thing to emulate Neopixel signal on Rpi. There is no such problems with highspeed AWA Adalight or HyperSPI which work without setting additional delays. I consider at least this subject as closed and I won't come back to it.

[stickmanbrad]

One thing I did want to run by you (which may help others), obviously you requested I set the ‘Refresh Time’ to 0.

Make sure your refresh rate in the smoothing is set to reasonable value. I really don't know what happens to that unsupported LED driver: like I said it's not a cheap thing to emulate Neopixel signal on Rpi. There is no such problems with highspeed AWA Adalight or HyperSPI which work without setting additional delays. I consider at least this subject as closed and I won't come back to it.

Hiya,

Apologies for posting on this again. I was still continuing to have issues with the ESP32. I managed to find a different ESP32. In fact I had actually managed to find a CH9102x, and I noticed this could work over 4MB speed. So I changed the config for that speed and off to the races I went.

Plugged it all in, and it works but I'm getting that dreadful 'Could not detect HyperSerialEsp8266/HyperSerialESP32 device' in my logs. But it does seem to be working on the 4MB speed. I'll attach logs below and if this needs moving I can do so. I wondered whether maybe that error message is specifically related to go off if it's not 2MB? Could It be at all possible it is working? Even running the 'stty -F' command on the port says 4MB.

Thanks again

Logs Beginning

2023-01-19T19:23:35.913Z [LEDDEVICE_ADALIGHT] Opening UART: ttyACM0
2023-01-19T19:23:35.913Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:183) _rs232Port.open(QIODevice::ReadWrite): ttyACM0, Baud rate [4000000]bps
2023-01-19T19:23:35.957Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:188) portName: ttyACM0
2023-01-19T19:23:35.957Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:189) systemLocation: /dev/ttyACM0
2023-01-19T19:23:35.958Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:190) description: USB Single Serial
2023-01-19T19:23:35.958Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:191) manufacturer: 1a86
2023-01-19T19:23:35.958Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:192) productIdentifier: 0x55d4
2023-01-19T19:23:35.958Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:193) vendorIdentifier: 0x1a86
2023-01-19T19:23:35.958Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:194) serialNumber: 5377014907
2023-01-19T19:23:36.214Z [LEDDEVICE_ADALIGHT] Could not detect HyperSerialEsp8266/HyperSerialESP32 device
2023-01-19T19:23:36.215Z [LEDDEVICE_ADALIGHT] (LedDevice.cpp:329) Switch on
2023-01-19T19:23:36.215Z [LEDDEVICE_ADALIGHT] (LedDevice.cpp:405) Power On
2023-01-19T19:23:36.215Z [COMPONENTREG0] LED device: enabled
2023-01-19T19:23:38.045Z [WEBSOCKET] (JsonAPI.cpp:1250) log streaming activated for client ::ffff:192.168.1.84
2023-01-19T19:24:29.938Z [V4L2:USB3.0 HD VIDE] Video cache: enabled, size: 8, hits: 3582, needed: 1, cleanup: 0, limit: 8
2023-01-19T19:25:29.930Z [V4L2:USB3.0 HD VIDE] Video cache: enabled, size: 8, hits: 3596, needed: 0, cleanup: 0, limit: 8
2023-01-19T19:25:29.936Z [PERFORMANCE] [USB capturing: FPS = 59.94, decoding = 11ms, frames = 3596, invalid = 0], [INSTANCE0: FPS = 59.94, processed = 3596], [LED0: FPS = 50.00, send = 3000, processed = 3000, dropped = 0]
2023-01-19T19:26:29.927Z [V4L2:USB3.0 HD VIDE] Video cache: enabled, size: 7, hits: 3596, needed: 0, cleanup: 1, limit: 8
2023-01-19T19:26:29.941Z [PERFORMANCE] [USB capturing: FPS = 59.94, decoding = 11ms, frames = 3596, invalid = 0], [INSTANCE0: FPS = 59.94, processed = 3597], [LED0: FPS = 50.00, send = 3000, processed = 3000, dropped = 0]
2023-01-19T19:27:19.227Z [SMOOTHING0] Clearing queued colors before: disabling
2023-01-19T19:27:19.227Z [SMOOTHING0] Smoothing queue is cleared
2023-01-19T19:27:19.228Z [LEDDEVICE_ADALIGHT] (LedDevice.cpp:138) Disable device
2023-01-19T19:27:19.229Z [LEDDEVICE_ADALIGHT] (LedDevice.cpp:355) Switch off
2023-01-19T19:27:19.229Z [LEDDEVICE_ADALIGHT] (LedDevice.cpp:313) Set LED strip to black/power off
2023-01-19T19:27:19.232Z [WEBSOCKET] (JsonAPI.cpp:1259) log streaming deactivated for client ::ffff:192.168.1.84
2023-01-19T19:27:19.232Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:123) Flush was successful
2023-01-19T19:27:19.234Z [COMPONENTREG0] LED device: disabled
2023-01-19T19:27:19.235Z [PERFORMANCE] [USB capturing: FPS = 59.94, decoding = 11ms, frames = 3596, invalid = 0], [INSTANCE0: FPS = 59.94, processed = 3597]
2023-01-19T19:27:19.240Z [LEDDEVICE_ADALIGHT] Received: '
HyperHDR frames: 50 (FPS), receiv.: 49, good: 49, incompl.: 0, mem: 3268, heap: 315380
RGBW => Gain: 255/255, red: 128 , green: 128 , blue: 128' (146)
2023-01-19T19:27:19.241Z [LEDDEVICE_ADALIGHT] (ProviderRs232.cpp:106) Close UART: ttyACM0
2023-01-19T19:27:20.376Z [WEBSOCKET] (JsonAPI.cpp:1250) log streaming activated for client ::ffff:192.168.1.84
2023-01-19T19:27:29.935Z [PERFORMANCE] [USB capturing: FPS = 59.94, decoding = 11ms, frames = 3597, invalid = 0], [INSTANCE0: FPS = 59.94, processed = 3596]
2023-01-19T19:27:29.936Z [V4L2:USB3.0 HD VIDE] Video cache: enabled, size: 7, hits: 3597, needed: 0, cleanup: 0, limit: 8
2023-01-19T19:28:29.932Z [PERFORMANCE] [USB capturing: FPS = 59.94, decoding = 11ms, frames = 3596, invalid = 0], [INSTANCE0: FPS = 59.94, processed = 3596]
2023-01-19T19:28:29.932Z [V4L2:USB3.0 HD VIDE] Video cache: enabled, size: 6, hits: 3596, needed: 0, cleanup: 1, limit: 8
2023-01-19T19:29:29.924Z [V4L2:USB3.0 HD VIDE] Video cache: enabled, size: 6, hits: 3596, needed: 0, cleanup: 0, limit: 8
2023-01-19T19:29:29.938Z [PERFORMANCE] [USB capturing: FPS = 59.94, decoding = 11ms, frames = 3596, invalid = 0], [INSTANCE0: FPS = 59.94, processed = 3597]
2023-01-19T19:29:41.470Z [IMAGETOLED0] Total index number is: 240640 (memory: 240640). User sparse processing is: disabled, image size: 1280 x 720, area number: 217
2023-01-19T19:30:29.937Z [V4L2:USB3.0 HD VIDE] Video cache: enabled, size: 4, hits: 3597, needed: 0, cleanup: 1, limit: 8
2023-01-19T19:30:29.939Z [PERFORMANCE] [USB capturing: FPS = 59.94, decoding = 14ms, frames = 3597, invalid = 0], [INSTANCE0: FPS = 59.93, processed = 3596]
2023-01-19T19:31:29.930Z [V4L2:USB3.0 HD VIDE] Video cache: enabled, size: 4, hits: 3596, needed: 0, cleanup: 0, limit: 8
2023-01-19T19:31:29.930Z [PERFORMANCE] [USB capturing: FPS = 59.94, decoding = 14ms, frames = 3596, invalid = 0], [INSTANCE0: FPS = 59.94, processed = 3596]

Logs ending