Thanks. I must have missed seeing that.
But am I correct on the Adalight protocol, where I can go to get that info?
1 Like
Yes, it does use the Adafruit Adalight protocol. You can see in this Adafruit repository how they interact with the hardware using a Processing program.
Great, thanks.
I haz LIGHTS!
Some feedback on the setup:
Something interesting for Linux folks to know (maybe make a note on your start page), it comes in as a ttyACM device, not a ttyUSB device as I would have thought it would have.
Expecting everybody to have python installed on their system, especially Windows, is unfortunate. Especially with a hardcoded filename, would be nicer to have it as a parameter. Even better, for the rest of the folks, would be a static HTML + JS page on your website that’d let them upload the Map file, and spit out a modified/fixed Map file to load up.
When I tried an effect other than Color Wheel, I get some bad behavior. Or correction, when I try it at less than 100% brightness. I tried Rainbow Wave, and at 100% brightness it’s fine, but when I lower the brightness, especially down around 11-15% or so, it starts to glitch the colors. And when I switch back to Color Wheel, I get a bit of glitching at the very bottom.
Glitching for rainbow wave at low brightness.
So when I put it back at 100%, it mostly works, with a little glitching at the bottom. But after a time it de-glitches and goes back to correct. If I didn’t capture it on camera before, I’d be very confused.
I tried restarting and when I started OpenRGB back up, loaded the modified Map, even at full brightness I was getting some wonky flashing/corruption.
And I’m not sure that it’s a bandwidth issue. I see in Serial Ports (USB and UART) — Arduino-Pico 3.6.0 documentation that while it accepts a baud rate, it ignores it, so should be at the full 12 Mbps Full Speed data rate then, right? So even at 9216 + header bits per frame, at 60 fps that’s only ~0.5 Mbps, so the USB bus would have to be REALLY loaded up with other stuff to really have any issues.
So I think we’re left with something in the firmware, which seems pretty simply “receive, validate, write out” which the RP2040 should be plenty fast enough, unless you have the clock set way low. Or it’s OpenRGB, which according to system monitor is only using 0.6% CPU, and ~61MB of memory. And overall, the CPU usage is basically nothing, so unless it’s something in the Linux kernel drivers being really inefficient or the Linux version of OpenRGB being really inefficient, not sure what the issue could be. Thoughts on troubleshooting?
I am using the AppImage version, not .deb installed of OpenRGB, so maybe that’s it?
2 Likes
Huh, that’s strange with the glitching behavior. I can set the brightness to the minimum in OpenRGB on Windows 11 and I don’t have that issue.
The firmware communicates over Serial at 115200 baud.
1 Like
So it’s hooked up to the Serial UART pins on the RP2040, not the USB-Serial pins?
1 Like
You could try the experimental release of OpenRGB. Version 0.9 which is their latest stable version is 9 months old.
You’re using 0.9 or experimental?
1 Like
I am using v0.9 without issues on Windows 11. But, I did not test 0.9 on Linux.
It’s connected to the USB pins on the RP2040. That way you can reprogram the RP2040 with UF2 or with Arduino.
That seems odd, unless the baud is a lot more bits/sec than I think it is.
header + (288 pixels * 32 bits per pixel) = ~9216 bits
60fps = 552960+header bits
If 115200 baud == 1 bit/sec, 115200 bit/s, not going to work.
If 115200 baud == 4 bit/signal, 460800 bits/sec not going to work
If 115200 baud == 8 bit/signal, 921600 bits/sec OK
1 Like
I was about to ask. One of my two modules is glitching like this. I’ll upload a video in a bit. I’m going to swap them around and try some things to confirm if it’s the one module or something else.
EDIT: Here is a video of it happening on mine:
The glitchy gets much worse as the brightness is reduced. Right module appears fine. Note, this happens with any color effect, not just the one I am demonstrating.
1 Like
Ok, great. I’d think then it’s connected at Full Speed, regardless of baud rate set. It’s just because it appears to be a serial device in the OS, that a baud rate makes sense in the applications trying to access it.
Interesting thing is it appears as an ACM, not USB serial What is the difference between /dev/ttyUSB and /dev/ttyACM?
Is this a RP2040 thing? Or is this a setting that you did? Or an Arduino setting behind the scenes?
1 Like
Are you also using Linux?
Take a look at the firmware. It sets up a serial port to receive data from the computer running at 115200 baud.
If you are not using that baud rate in your control software. Then, the module might be receiving garbage serial data.
I wouldn’t try forcing 60 fps. I tested with OpenRGB which I believe attempts the highest refresh rate it can.
Yes, Arch Linux in my case.
Note on fps, adjusting it all the way down to 10fps does not effect the glitching. It still happens.
I’m going to set up some udev rules to get persistent device names and then I’ll mess around with swapping them around.
1 Like
Ah ok, this seems to be an issue with OpenRGB 0.9 on Linux.
Can you please try the experimental OpenRGB release that I mentioned here?
1 Like
Using usbtop, I see about 14.4 kb/s at 10fps, which I’m not sure if it’s kbit or kbyte. kbyte/sec makes more sense, which that’s in the vicinity of 11400 bit/sec.
1 Like
Yup, that seems to work well. So it’s an OpenRGB issue. What’s the link to the issue in OpenRGB that you found on Linux? Out of curiosities sake.
1 Like