Analog clock & bar graphs using RGB LEDs in the C-ring of a Tron disc
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
CPU-temp_load-average.mp4Red=CPU temp, Green = system load average while running "stress -c 1" to create a cpu loadMPEG-4 Video - 1.57 MB - 10/01/2018 at 06:26 |
|
|
60x.mp4Accelerated time to show more motion.MPEG-4 Video - 1.90 MB - 10/01/2018 at 06:25 |
|
|
Color-blending.mp4Red (second-hand) with a width of 1 -- so it blocks out the underlying color unless it is only partially overlapping the hour or minute hands. A "thinner" second hand would show more color mixing, and appear less bright. (viewed through a sheet of paper to reduce brightness and show color blending)MPEG-4 Video - 2.77 MB - 10/01/2018 at 06:19 |
|
|
code.zipx-zip-compressed - 2.52 kB - 10/01/2018 at 06:18 |
|
When I was previously working on this project, I somehow jumped to an incorrect conclusion that SPI0 (pins 19,21,23) could not be used at the same time as SD1 (pins 13-18,22) -- so I got really off-track trying to find an alternative (I was extremely stressed out at my previous job -- by a hostile takeover, and new CEO firing and burning out loads of people)
I decided to switch from EL-wire to LEDs in the C-ring. I hand wired LEDs into groups of 4, and used short thin wires to connect to a larger power bus wire.
I had a huge amount of LED failures, maybe from a too-hot soldering iron (maybe bad parts?). I also had a wire failure (even though it wasn't open -- it broke the LED data chain)
(those 60 LED rings are nearly perfect width and radius for the C-ring -- but their board is too thick for the power switch board, and possibly would also hit the RPI -- and would also need cutting)
The DMA on SPI0 prevents most glitches on WS2812b LEDs, but is not perfect. A potential fix may be for the SPI kernel driver to support adjustable transfer bits. Current code can only inefficiently send 2 led-bits per byte and that exhausts the 32 bit SPI buffer very quickly.
(or the driver should detect an LED timeout and resend the whole LED frame)
(I'm interested in building a kernel driver, but that is a steep learning curve)
Since the LED data is not using the PWM system -- sound output is available, and sound visualizations should be possible.
A major problem in my current code, is the subpixel rendering is very slow. The subpixel resolution can be set by changing the size of bytearray "mix". Full resolution would be 256 -- smaller numbers limit blending to that many steps.
With just 3 or 4 objects (x 3 for RGB), it was taking seconds to render 256 steps. For now I settled on 32 to match up the FPS and number of steps. To go a bit faster, the code only renders subpixels at the edges of lines.
Not sure why it is so slow: might be a bug in my code, or maybe bytearray is slow?
An alternative might be to use pygame or some other canvas provider -- but it may be difficult to find anti-aliasing / subpixel rendering. Ideally, the color mixing should also be gamma adjusted.
Wire WS2812b to SPI0 MOSI - pin 19, and power and ground
(SPI0 has DMA - but still occasionally has glitches)
(WS2812b will run off of 3.7V from a LiPo battery, do not connect it to RPI 3V3 out)
Create an account to leave a comment. Already have an account? Log In.
Become a member to follow this project and never miss any updates