Ah, gotcha. Good to know, and not a bad default time.
And it’s not the biggest deal, just a nice to have idea. And I agree, folks just need to realize it and plan for it. It’s not as if it’s difficult to swap it for a non-LED plate if you’re going to be unplugged for a long time!
It’s only on my mind because I have a RGB light up walking cane (don’t really need it, just faaaaancy) for an outfit, and it’s on my mind that it’d be great to be able to leave the MCU (ESP32) powered on, and enable/disable the strips (or the buck to the strips). But I do have a 4s2p Molicel 3500mAh pack loaded into it. Something like 99Wh nominal (can carry it on a plane!), so even with 264 pixels, it’ll last a loooooong time off, and lasts a pretty long time even with patterns going. Don’t hardly need it more than 10-15% brightness, and even then it’s varied colors at varied pwm amounts, and not every pixel is even on all the time. So it’s just my “must optimize” brain going.
The brightness of my modules is limited in firmware heavily. Each of the Framework Laptop 16 input module connectors only supplies 500mA at 5 volts. So, the max brightness you can set in OpenRGB is actually only 9.8% of the max brightness of the LEDs. I do have self-resetting fuses on the circuit board for 5 volts so you can only draw 500mA.
Nope, there isn’t. USB bus traffic goes to 0 when I disable the effect or shut of OpenRGB. I’m running the AppImage, not installed version. Although, I not notice it occasionally ticks up to 0.13 kb/s. After I shut down OpenRGB, it’s now down to 0 solid, so seems more like a keep alive signal. Although it seems to have shut off anyway after a minute, even though part of that minute that tiny bit of bus traffic was still going.
Also something I notice, I booted up v0.9 to see if I could replicate the issue, and it’s not. I’m wondering if it’s a application/kernel driver/device configuration/settings that Experimental sets properly, but v0.9 doesn’t, and it gets into a mode that’s OK for v0.9.
Yup. I shut down OpenRGB, pulled the module, put it back in, and now seeing the same thing.
Getting ~60-80 kb/s to device, 24-30 kb/s from device. I’m betting some kind of duplicate send or something that’s overwhelming the controller or controller buffers.
It never fails to amazing me how bright these pixels are, even at limited pwm brightness.
Speaking of which, might be useful to add “automatically sets to 0% brightness after 60 seconds” on the documentation page, since I’m sure others might end up wondering.
Tried the updated versions and no luck. They are listed in openRGB as version 1.0.0 instead of 0.9, but the glitching is still there for me. In fact, by my messing about, added udev rules for persistent device names and swapped them around a couple times and now BOTH are all glitchy on me. Must be something with openRGB. I’ll keep poking at it.
I’m referring to the OpenRGB udev rules, although I suspect mostly they don’t apply because they seem to mostly be for devices that we wouldn’t have. See OpenRGB - udev rules
If from distro package, then it probably includes the udev rules as part of the install.
Yup, that’s what it seems to be for the RP2040, from the bit I’ve read in a few spots. Including for the RP2040 a magic baud rate to put it into update/program mode.
The real USB<->UART like the FTDI (which ends up at ttyUSB devices) it really does matter, because behind the USB it really is UART, which requires those settings to actually talk to the device at the other end.
It’s the case for all of the virtual serial stuff I have dealt with (mostly stm32s and the odd atmega32u4), if it doesn’t become actual serial it just goes as fast as the actual interface goes.
This depends on the actual COM emulation in the downstream device. I don’t know what the difference is at the Linux end. I have seen this happen on other devices where an FTDI chip will show as a ttyUSB, but a firmware interface (such as is being used here) behind a USB peripheral will show as a ttyACM. In the end both types of port work as a serial port.
Not an issue per-se, just something different than I’m used to. I’m used to using the FTDI type serial adapters, so this is new information to me on how the RP2040 works, since I haven’t used one (in any form) before.
Yes, my understanding is that he was shipping them with tax prepaid. EU taxes are a similar percentage to the UK VAT, so I would suggest you go back to Joseph and clarify this.
I just looked up in my emails, it may have to do something with me saying it’s cheaper on your site than Etsy. So it’s probably on me! Unless on your site all required fees and taxes are also included, I think that was the problem.
