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
Sorry, I meant that we discovered a new issue. You, Jared, and CLJ are having the issue and you all are using Linux.
Ah, I see with the Experimental in usbtop, it’s looking a lot better. Before it seemed like it was doing significant receiving, as well as sending (the host), but now it’s looking a lot better. Roughly 48-49 kb/s to device, and 3.2-3.4 kb/s from device (USB protocol acknowledgements).
So fundamentally the baud rate for the serial is immaterial, since the actual under the hood implementation in the RP2040 hardware is USB Full Speed 12 Mbps. Although there may be a software bit over top of that at both ends that still requires that to be the same value in order to function properly. Because 115200 baud, if 1 bit per signal, is 115 kbit/s is about 14.1 KByte/sec, which isn’t enough bandwidth to handle 60fps, which is what OpenRGB runs at by default.
1 Like
Ah, ok. Gotcha. Yeah, Experimental works great. Let me know if there’s a debug log thing that should be generated to create an issue on OpenRGB.
2 Likes
Might still be nice to track down why the issue occurs with 0.9 vs Experimental. Might be something that’s masked in Experimental, and not fundamentally solved.
1 Like