The low level drivers are open source on my github.
For apa102, I wrote my own simple SPI based bufferless driver so that I could drive more LEDs than the esp8266 had memory for. The other advantage is that rendering and transmitting can be easily pipelined without a buffer. The next pixel is calculated while the previous pixel is being sent, so the frame rate is improved. To do the same for a buffer approach, a double buffer is needed so transmit can happen from one buffer as the next frame is rendered to another buffer.
Later I added WS2812 for Pixelblaze V2, originally using a UART, just like NeoPixelBus had done. It could be buffered or unbuffered. Unbuffered can pipeline, but itâs too easy to underfeed WS2812 and cause an early latch between 2 pixels, and requires using a slow data rate that ends up being the bottleneck. For most purposes buffered mode is best.
For V3 WS2812 support I switched to using the RMT peripheral based on a fixed fork of the driver used in fastLED (which was broken at the time). There are 2 options for using RMT for ws2812, one is using DMA to the RMT but this is incredibly memory intensive since RMT needs 32 bits for every bit sent. Thatâs 96 bytes for every RGB pixel, 490KB of ram to support the same 5k pixels max which is more than the entire ESP32 has. That buffer wouldnât be useful for any pixel rendering engine frame buffer since it has to be in the RMT peripheral timing format. The other option is to feed RMT via interrupt a little at a time, so no giant 32x buffer is needed, just a normal pixel buffer to ensure the pixel data is always available when the interrupt needs it.
I am also mostly a hardware guy. So I quickly hacked together a basic line driver circuit to drive strings of WS2811 controlled pixels down 60 feet of power cable (over 2000pF of capacitance between data and power lines). It just worked, and to be honest, I would have been disappointed if it hadnât. And the oscilloscope also told me I had got it about right.
But I am also still getting my head around the various strategies for pattern generation. I just about manage with arrays versus maths, but when 2D mapping gets involved (never mind 3D) it all gets a bit sketchy, and the transition from a structured approach to a trial and error approach occurs all too quickly. But Iâll get there, I am sure.
I shall post a little video of my efforts when I get a chance (too much rain this evening).
I am curious why do you need 60ft lines for the control signals.
The controller itself (specifically PicoBlaze) is small enough to
be mounted right next to the strip. Plus the communication it is WiFi.
I have all my Strip Lighting Controllers mounted within 1-2 inches
from a correspondent strip. This way I am OK with Signal Integrity
for the control signals.
As far as strip power I am using 24V Strips as a RGB(W,W) Strips
but I will replace all of them with WS2812b (or similar).
Higher voltage is very preferable because of a voltage drop across
the strip itself. WS2812b strips are only 5V and could draw up to
18A if entire strip is turned on 100% White. In my experiment strip
was powered from the beginning and connected right to the 5V PS
terminals. But measured voltage at the end of the strip was below 3V.
Surprisingly strip still worked but brightness at the end significantly
dropped and color at the end became almost orange instead of white.
No surprise there.
So, my power strategy for the low voltage strips is to use local
24-12V-to-5V @15A local down converter also mounted right next
to the strip. Since voltage input is 12-to-24V the size of this converter
is only 2x2x0.75 inches. Plus I can run relatively long power line from
main 24V@6A power brick. In this case I really donât care about
voltage drop across 24V power line plus this is very safe voltage to
run anywhere I want.
In addition strip must be powered from the both ends.
I am running 16 gage flat audio cable alone the entire strip.
The result is - the entire strip lights up very clear. Every single pixel
is bright white with no noticeable brightness difference. I expected
some in a middle but did not notice any. Strip is silicon wrapped,
so I cannot measure voltage in a middle of the strip.
To answer your question⌠Mostly, it was a case of the fact that I already had a nice weatherproof box for the AC to 12 supply, that already had a 5V regulator as well. It also had all the power and signal cables already mounted. This was used for my pre-Pixelblaze efforts in previous years. That box sits on one side of a locked gate right by the house with no public access, but the tree that features the lights is right by the pavement at the front of the house. Low voltage wires are OK, but I did not want anyone to get curious and start messing with boxes (unlikely, really, I know). If I had been starting from scratch I suppose I might have done things differently. But, as mentioned, hardware guy here, so a quick hand-wired circuit board to implement a line driver or two was for me the easier solution. Also, I was not so confident about the wi-fi signal at that location in front of the house compared to where I am able to put the weatherproof box.
As for the rest - I am using 300 C9 sized pixel bulbs in six series connected strings of 50 (mine came from Holidaycoro.com in the US before they stopped shipping to the UK due to our Brexit nonsense). These are 12V devices, and so I inject power at 100, 200 and 300. I have another string of 50 on a separate Pixelblaze, also driven in the same way from the same box. It all works well.
For next year I want to improve the range of patterns that I am using as well as explore the possibilities of synchronisation. But I have time for that. I am recently retired, so I have a bit more time for toys.
Youâre not alone. One of the biggest goal of my âtutorialâ series is to help people understand how this all works. @zranger1 added yet another âlayerâ when he connected GPU shader thinking to the PB, on top of the already existing methods we had (of which, there are quite a few). Itâs still evolving, and weâre all still learning and sharing tips and tricks.
