Garden LEDs

I installed LEDs in the garden over a year ago, on the fence and over the hot tub. It worked well.

This year things broke, and I have reinstalled, going for 12V working this time, and latest LED strips.

Overall, 12V LEDs can be much better.

• Controller is https://www.tindie.com/products/revk/sound-reactive-led-controller-strip-powered/
• Fence fairy lights https://www.amazon.co.uk/dp/B0B5D8T378
• Hot tub strip https://www.superlightingled.com/12v-ws2815-rgbw-96-ledm-led-strip-individual-lights-10mm-p-6854.html

WS2812

I have been using "WS2812" based LEDs for some years - both on PCB using tiny 1x1mm LEDs, and on LED strips, and fairly light chains and so on. These types of LEDs are becoming very popular, with a range of subtle variations (colour order, if RGB or RGBW, and all sorts of other attributes like voltage and backup data lines).

The key feature is they work by a serial data stream that is chained along the LED strip. Each LED eats its data bits and then acts as a passthrough for remaining data until a reset pause, when all LEDs apply the new value to the LED itself. A clever system really.

For use on PCBs, I have already blogged on use of 1.5mm x 1.6mm shallower version of the same Xinglight LEDs that are way nicer in many ways. I can litter a PCB with status LEDs in all sorts of styles, and have done so on various PCB designs, all using a single GPIO pin to drive them.

But even on a board with just one status LED, this still makes a lot of sense using just one GPIO.

This recorder board is a nice example, 7 LEDs on the board. Making rows of LEDs as a level indicator is great.

Drivers

The fun is drivers for this. You need a way to control the LEDs and what they show.

Thankfully Espressif have a driver, a managed component led_strip, which allows you to create a strip with LEDs in a variety of formats, update LED values, and send.

They use the RMT hardware, which is intended for generating pulse streams used for IR remote controls. This makes a lot of sense to generate the exact timing. Here is an example of timing needed for WS2812.

So, pulses 400ns and 850ns, and gaps 850ns and 400ns. Makes sense to use RMT.

But wait, here is another WS2812 data sheet...

This has pulses 400ns and 800ns, and gaps 850ns and 450ns! OK, both say ±150ns, but why different?

A similar chipset SK6812 has these...

This is rather oddly specified as 1.25us total, but pulses of 300ns and 600ns, but gaps of 900ns and 600ns. So very different, and also adding up to 1.2us not 1.25us.

On face value this does not overlap the spec for WS2812 (either one) quite. But close.

The LEDs I am using are Xinglight, and they have a data sheet of...

This is very different, it lists minimum pulses only, of 300ns and 900ns, and gaps 900ns and 300ns, and a longer reset time.

But the part number is XL-1615RGBC-WS2812B includes WS2812B in it, yet this is different to WS2812 timings (either of them). But this overlaps with WS2812, which is good, well sort of, 850ns fails a minimum 900ns, so sort of.

But let's look for the data sheet for that exact part again, and oh, now I see.

What the hell? This is a 1.75us bit timing, and not an overlap with WS2812. Also, note, they have max 0 280ns and min 1 650ns, so what happens between those - there has to be a decision to read as 0 or 1.

But surprise! They all work using the same driver. It really is an appallingly crap set of data sheets.

Using SPI

RMT is great for exact timings, but struggles with the amount of buffer you need (4 bytes per bit) and struggles to cope under heavy load - even when set to use DMA - so when re-flashing the LEDs go disco.

An alternative way to drive these LEDs, which the Espressif driver now handles, is to use the SPI bus, to clock data. This would not handle things like 450ns and 800ns, but can do nice round multiples like 400ns and 800ns pulses and gaps using 3x clock and coding 100 and 110 per bit.

In practice I have made my own SPI drivers now. This is because I want things the Espressif drivers will not do, such as multiple strips on same GPIO but with different RGB order, or RGB and RGBW stacked up. I also want switching one SPI between different GPIOs cleanly with no glitches. The earlier LEDs will quite happily pass on the controls for the later LEDs even if different order and format - clever isn't it.

My code does allow for different chipset timings, with WS2812 being 400/800 and 800/400, SK6812 being 300/900 and 600/600, and Xinglight being 300/900 and 900/300. But I have found with a lot of testing that basically all of these work with various different types of chip. Crazy.

So I have settled on a simpler driver being 300/900 and 900/300 as that seems closest to being in spec for all formats. It makes encoding simple, 4 bits on SPI bus per bit of data on this, so coded as 8 or E per nibble.

I have no clue why so many subtle, but sort of overlapping, and sort of working specifications. What is crazier to me is the exact same chips seem to have multiple data sheets with different specifications.

In practice, it should be simple, a pulse below say 500ns is a 0, and over that is a 1. A gap of under say 50us is a gap to next pulse, and beyond is a reset. There is no need for a ± on any of these, just a clearly defined minimum and maybe a minimum pulse 100ns and recommendation to stay 50ns away from the limits to allow for rise/fall times on real wires.

I have found some cases of differences though. Initially my SPI code switching GPIOs caused a glitch before a gap (reset) then data. This worked on various LEDs, but one WS2811 fairy light strip failed with glitching and corrupted LEDs. I fixed the SPI glitch and it was fine. But it showed a clear distinction in how reset was handled and how a glitch was handled on some chipsets.

Punched paper tape

I decided to make a scalable LED panel, so a grid of LEDs, all full RGB (WS2812).

I can manage this at 2x2mm, using 1x1mm LEDs, but no space for decoupling caps or vias, or well, a lot, so can be stacked one way but not the other...

The alternative LEDs I am using, instead of 1x1mm LEDs, are 1.5mmx1.6mm. These are way better, lower profile, and do not get knocked off the PCB.

So spacing at 2.5mm grid is just about possible.

But in honour of my ASR33 teletype, the latest LED strip designs are like this...

This is 2.54mm spaced, 30x9 full RGB LED block. So can be stacked to make longer strips.

This is the exact size of punched paper tape, all 0.1" spaced stuff.

The 0201 caps are in-between, which is neat.

So, this may be on Tindie soon, if they work...

LED Strips

There a lot of options for colour LED strips.

I am talking pretty much entirely about 5x5mm individually addressable full colour LED modules on a 10mm wide flexible PCB with leads at each end. But even being that specific there are a lot of choices!

These things basically...

Covering/backing

Start with something simple - these strips often have options.

• Black or white strip supporting the LEDs.
• A domed flexible clear covering that is generally pretty waterproof.
• A rectangular sleeve enclosing the string, which is more waterproof.

This is really a simple choice. I have some on a door frame which are the domed covering, because the strip or chips would snag otherwise. I have some on a shelf (image above) with no covering, as out off reach. You need to consider this if putting in some sort of diffuser, e.g. an aluminium strip with plastic cover - where no covering in the strip itself helps much under the diffuser. A diffuser is usually a good idea.

Now, some do come in a diffuse housing, which can be a good compromise. Bear in mind that any covering or enclosure makes cutting to length and joining harder. The simplest is the bare strip with LEDs on it (and the pads between them) allowing easily soldered joints to another strip. There are clips you can get but I do not recommend them - soldier it.

Note - the adhesive backing is pretty universally crap, not bad on aluminium, but on wood, etc, not good. I'd think about some nice 3M tape.

Density

Again a pretty simple one - how close the LEDs are - and that varies.

1. Close together is great for sheer amount of light, and using inside any sort of diffuser strip as you can hide that there are individual LEDs.
2. Close together means more LEDs and so more power needed.
3. Close together adds to the cost.

Voltage

This is a bit more complex. The main choices are 5V, 12V or 24V. I am generally working towards 12V these days (with per pixel control on a WS2815).

1. 5V can mean notable voltage drop on long runs, meaning power feed in at extra points. 12V can run longer and typically the modules can work on much less than the full 12V if they are per pixel 12V.
2. 12V and 24V can be multiple pixels on one controller, e.g. 3 RGB pixels on one controller in a row are controlled together as the 12V is split over them. This is pretty shit, to be honest. It is not always the case, and WS2815 seem to be ideal with single 12V working pixels separately addressable.
3. Higher voltage is lower current and can be a smaller power supply and less heavy duty power leads.

Current

This is one of the big issues, and not as simple as it looks - the LEDs do not use a lot of power, but there are a lot of them. Higher voltage means you can work with lower current. But you have to be careful, even with 5V DC levels, if you have hundreds of amps available - that can be nasty stuff (not that is unlikely to electrocute you, but can burn and melt stuff - a short at that power can melt copper wires).

The other issue, apart from not wanting to handle large currents (for which higher voltages help) is the power supply itself. A high current power supply is bulky and expensive.

A big challenge is working it out - and this can easily go wrong. There are guides and tools and data sheets. But you can easily find you are massively over specifying your requirements. As with any modern electronics, LEDs are getting more efficient and so lower power - the guides for 10 years ago do not apply now.

You also have the option of not lighting all LEDs full white all the time. So depends what you want. In practice you probably do want almost any system to work at all LEDs on full - but not always!

In short, my recommendation is to test the strips you are using, get a current meter, a strip and set to full power all on. Measure it. Note if can change on temperature, so leave a little overhead. But that tells you what you need.

Bear in mind voltage drop is also a thing - all white on a long strip could have more than enough current from the supply but still fade and lose colours at the end due to voltage drop - sometimes you need extra power feed in along the strip(s) to fix that. This is were 12V can help if the pixels can work down to half that (as seems the case) you can tolerate a lot of voltage drop.

I have a fence where along side the chain of strips I have a thick copper power pair, which taps in at each strip join. That works a treat as the thick copper power cable is low resistance and allows the current to get to the whole strip. The same power supply, which clearly has enough power, could not work the whole chain from just one end as the voltage drop would kill it after about the second strip. Bear in mind, whilst the data has to connect at one end, the power could always connect in the middle of your set up.

Never forget - power ends up as heat and has to go somewhere.

Colour options

There are two main colour options.

• RGB - the simplest type - full colour using Red, Green, and Blue
• RGBW - an extra 4th White LED.

There are some RGBWW with two different shades of white as well, but rare.

the main advantage of RGBW is that the extra white LED is usually very bright (and often available in a specific shades of white), but is also one LED, using less power than combining RGB to make white. Yes you can go overkill and try RGB and W for even more bright and even more power usage.

The general idea is if the strip it to be functional lighting as well as pretty effects, RGBW helps allowing the white to be lighting. You also often want to consider higher density of LEDs in such cases.

Chip type

There are a few chip types, and many odd chips that are compatible. There seem to be some subtle differences in the data sheets but in practice they all work the same way.

• WS2812 is the main one, simple RGB 5V
• SK6812 is another one, typically the order of colours is different in the data sent
• WS2815 is the one that does RGB but using 12V
• There are new WS2815 that are 12V and RGBW

Timing

Rarely an issue, but worth considering - each pixel on a strip takes time. So the maximum update rate of a whole strip depends how many pixels. Each bit is approx 1us long, so each colour is 8, and each RGB is 24us. That means 100 RGB takes 2400us or 2.4ms. RGBW is 4 colours, so takes longer. As you can see, once you have hundreds of pixels the refresh rate can come down and start to be more noticeable. The answer is more separate strips working in parallel if your controller can do that. I'm practice, it is rare for many hundreds of pixels and rare that the refresh rate matters that much. But bear in mind on large installations. 

Duff pixels

One of the reasons to look at the chip type is the WS2815 has a backup data line. The way this works is the data daisy chains from one module to another - any break, or any failed module means the whole of the rest of the strip dies. The WS2815 has a cunning plan - a backup data that goes directly on to the next pixel. The idea is that if a module fails, the next LED picks up the backup line, and delays one pixel, meaning it works and so does the rest of the strip. Only if two adjacent modules fail does the rest of the strip die. This is an excellent innovation, and I definitely recommend it.

Recommendation

The recommendation is simple...

• For density - decide what you need.
• For covering and strip PCB colour - decide what you need.
• Recommend WS2815 RGBW 12V strips - only now available in 2025.

The reasons are simple.

• 12V working is less current, so smaller power supply.
• 12V allows more voltage drop, so longer strips just work.
• WS2815 backup data allows a duff pixel.
• RGBW allows more powerful white at lower power.

(I have some of these latest strips on order).

Update:

I have the new WS2815 12V strips. 96 LED/m. They state 23W/m (so around 2A/m), but tests are fun.

I usually expect each LED (R/G/B/W) to use power, so red is half yellow and a third of RGB White, but same as W White. But now.

Measuring a 100 LED test gave me roughly 1A for red or green or blue, but also 1A for yellow, or cyan, or magenta, and even 1A for RGB white, and 1A for W white. I only got more (1.75A) for RGB+W double white.

This is interesting. I assume they balance the currency for multiple LEDs somehow, which sort of makes sense - you do not want yellow twice as bright as red or green really. It makes things simple as well.

Magic LEDs

There is a company called Xinglight that make some LEDs that I use. I call them magic LEDs because they are really so useful.

They cost 2p or less each, but they are RGB, so full colour LEDs. Now bear in mind some other single colour LEDs I use on some boards are more like 5p each, these are cheap.

So what makes them magic apart from they price?

• They work from 3.3V (datasheet says 3.5V min, but my tests, room temp, 3.3V just works)
• No need for extra series resistor as normally needed on an LED - no need for any extra component.
• Uses WS2812 serial coding so one can have one or more of these on a single GPIO pin.
• Full colour
• Tiny

So if I want a simple status LED on a board, this is a tiny, 1x1mm component on a single GPIO on the 3.3V supply, and just works. Yes, it is more complex than a simple on/off GPIO, but in some ways that is better is it cannot be on accidentally - it needs the correct code to send the correct sequence to light it up. If this status LED lights up the code is running, meaning it all works, boot loader, signature check on code, code running.

The small ones are 1x1mm, and are really so small. I have used for years on many designs, but it is time for a change.

Why?

These tiny 1x1mm LEDs can snag and come off the PCB very easily.

So what is the alternative? Well, they do a 1.6mm x 1.5mm version and a 2x2mm version.

My current plan is changing all my designs to the SMD1615 (1.6mm x 1.5mm) version.

It has castellated pads, so some chance of solder coming up the sides, and is not that much bigger really.

I usually pack the 1x1mm LEDs at 45 degrees, space at 2x2mm, and can do that both ways, just. The new LEDs can do 2mm spacing straight and neatly. They can fit closer, just, but not both ways if I want to make a grid.

So for single status LED - no brainer, takes about the same space, and easier as a track can run under it.

For a row of LEDs at 2mm spacing, perfect.

Indeed, almost all of my designs work, even the coaster which is 124 LEDs in rings!

Fun with... LED Strips

I am not late to the party here, honest. I have been playing with these for some time, and even design and make LED controllers.

The ubiquitous protocol is "WS2812", which is basically a serial data stream on one data line at a rate of around 1MHz with short or long pulses being 0 and 1 as data, and a long gap being end of sequence. The exact timing in the various data sheets do seem to vary slightly. SK6812 is similar.

The data sequence is binary values, 8 bits per byte, and the bytes that are each colour. The exact colour order varies depending on chipset it seems (patent/copyright/god knows why). In general it is Green, Red, Blue, but can be Red, Green, Blue, and I have seen others.

Each device consumes its data sequence for its colours, and passing on the remaining stream. Once the long gap comes all devices load the accepted colours to their LEDs simultaneously, which is cool.

There are also RGBW, which have four bytes not three, so include a "white" level. This is cool (or warm) as the white LED is often larger, and brighter, and the power of one LED but white (doing white with R+G+B is not as nice a white, and uses 3 times the power).

Coding for this is simple, and ESP has ways to do it - typically using the "remote control" system for IR remotes, but can also be done using SPI bus with a little fun with the logic. This allows working with many devices as a serial stream via SPI is very simple.

They also get smarter with some designed to take a backup data which is a connection of the data in to the previous pixel. If the backup comes in without the expected data, it can accept the backup, one pixel later, as its own data, and pass on as such. As such a single dead module does not break the chain.

So, we have many choices, the exact chipset, the order of colours, if white included (which flavour of white such as cool, warm, natural, etc), if backup line, and voltage.

The voltage is a fun one - commonly 5V, the voltage drop over a long strip is too much and you lose blue, then green, so have to inject 5V at multiple points in some cases. But 12V has options - one is 12V drives three sets of RGB LEDs in a chain, so 3 "pixels" the same, but another is 12V works one "pixel" (the WS2815 range do this). I have, however, some that work on 3.3V (impressive for blue) for on board LEDs, and I use these all the time on my PCBs - they would not work on a "chain" of LEDs off the board.

What would be nice, and I am not sure I am quite seeing yet (please say if not), and seems the logical conclusion here would be.

• 12V supply (working all the way down to 5V or less)
• Per pixel control (not sets of 3 pixels together)
• Backup data line
• RGBW option so white on the pixel (in choice of colour temperature)

It looks like the last point is the sticking point from what I read, as WS2815 does the rest, but when finally common place, that will be the ideal solution. The 12V working allows long strips on single supply. The W allows lower power and brighter "white" as functional lighting. The per pixel control is obviously better. The backup is obviously prudent. It would be extra cool if it can run from 5V on the same chipset, just obviously suffering the voltage drop issues over a long run.

For extra fun, I tested the WS2815 (12V) modules and they work very happily from 5V, so allow a hell of a lot of voltage drop. The data sheets say +9~+13V

Fencing

Bit of fun...

We usually put up some Christmas lights on the house - some fairy lights on the metal fencing at the front, but a pain as means a cable out of a window. They are usually just normal fairy lights.

But with my new found expertise in WS2812 style LED strips, and my controllers, I decided to do better.

11m of wooden fence at the front of the house on the road. So let's do this properly. The key point is I have outside power at the end of the fence for the hot tub. So I was able to install, under cover, a 20A 5V power supply.

I then got 4 strings of fairy light style water proof 5V WS2812 LEDs.

I drilled nearly 200 holes, carefully measuring each to be level and evenly spaced. That is surprisingly hard work, LOL. James followed me poking LEDs through the holes. We were both expecting to fall off the damn wall, and James's main concern is I would fall off whilst he was not videoing!

But it is not quite so simple. Just in case you don't know, there are two common issues with LED strips.

Current limit

One issue is max current draw can be too much for power supply. To test you can either work it out, or, simply set all LEDs full white. 200 LEDs is too much for a typical small 5V USB charger plug. Hence the 20A 5V supply.

I actually also did 663 (11m) RGBW LEDs on nice 45 degree extruded trunking with diffusers for the hot tub as well, from same supply. Now that used a lot of current - just one 5m strip is too much for a USB 5V charger when white.

Voltage drop

This is slightly harder to solve. Along the strip the current draw means voltage drops as you go along. Different LEDs need different voltages. First you lose some blue making it yellow, and then some green, making red/pink. And even before that, when white still, you lose some brightness.

So with this 50 LED strip - one strip works. Two strips work but losing brightness at end. Three strips means going distinctly yellow at the end. I wanted four strips!

The solution

The solution is power feed in - the strips even have extra tails for power as well as the three wires for power and data. You feed in extra power at each strip end, so for my 4 strips I feed in at 5 points.

But how do you feed in power? In some cases you could simply power your longer strip at both ends and not have enough drop to the middle to notice. But I don't have power at the other end.

But actually it is possible to feed in even with just power from one end. The reason is the resistance of the wires, these are classic Chinesium™thin wire. If you actually have some thick good quality copper wire you can run and extra power lead the whole length and feed in at each strip end. This is what is in the WAGO boxes in the image.

Merry New year!

P.S. my son sells the controllers and stuff, https://hiwtsi.uk/

Update: Measuring resistance on the 50 LED strip power lines showed 1Ω but the leads were 0.1Ω, so 0.9Ω. A similar length of copper wire registered 0.4Ω, so 0.3Ω, so ⅓ of the resistance.

James did a video :-)

Playing with microphones

The latest LED board designs have included a TDK PDM I2S microphone - the idea was to make sound reactive LED strips.

It is tiny (3.5mm x 2.65mm x 0.98mm) and cheap(ish) $0.76. But it is digital.

Now, this was a can of worms for which I was ill prepared. I2S is not like I2C, it seems, and there are a number of ways of doing it.

This particular device is PDM based, so has just a clock and data line - the clock to the microphone, and data comes back. The concept is that you have two of these, one set for right and one set for left channel, on the same clock and data. The left and right are on the rising or falling edge of the clock. It is fixed 16 bit per channel, and works at a specific (wide) range of frequencies of clock and hence sample rates.

But other I2S devices work in a different way, with extra pins.

I went through some stages for this...

• Simple analogue microphone (cheaper) - realised that was a daft idea.
• This mic, set to right channel, and it did not work.
• This mic, set to left channel, and it did not work.

What did not work was using WLED, a common LED driver package which works nicely on our LED modules. We realised it wanted I2S, and then realised it only did PDM on left channel, hence the different iterations, but no joy. Hopefully we can get some feedback in to that project so it does work as TDK is likely a good brand. It is amazing how sensitive it is.

My guess is it is not clocking at a rate the device will handle when using WLED, sadly.

So time to do it myself, as always!

I coded I2S as per ESP32 library, and, well, it worked, I got raw data. I could even tell it I want mono only and which channel. Amusingly using the wrong channel works too as the data floats for the other channel - though I picked up some high frequency noise that way. So best to set it correctly (I nearly said "right").

The next step was a simple FFT function - I have not gone for anything fancy or uber efficient, as it keeps up well enough, especially when I went for some simple oversampling on its input. I cannot clock the microphone as slow as I would like for normal working. But even at 30k samples/sec I could keep up with FFT 30 times a second, just, all done with floats. These ESP32s are impressive.

I have made the working audio range configurable, and averaged the FFT down to a small number of bins (24) which are log of frequency to fit better with musical scales (options for linear).

This has led to some simple audio responsive LED schemes - a simple brightness based audio spectograph - smoothing from 24 bins to however many LEDs you have in a chain. And also a simple overall volume based bar graph, and one that is RGB for three levels of sound.

Lessons learned.

Some automatic audio gain was pretty simple.

The next lesson was the log scale on frequency. That was not hard. But made an option.

I reduced the full FFT result to a small number of bands, 24.

Also I needed to make it do a peak level per band and damping (configurable) to give anything that looks nice.

The frequency range is configurable, but log based causes gaps if you go too low, so ended up 100Hz to 4kHz for now, log spread over the 24 bins from a sample rate at a typical 25 blocks/sec and actually sampling over 50-60ks/s down graded (average of oversample) to 12-15ks/s for the FFT giving results to 6-7.5kHz which is more than enough for the bands I am using.

I also ended up making the samples fit the LED update rate synchronously, typically 25 or 30 per second (configurable) to avoid any extra jitter/aliasing effects.

Oh, and when using RGBW, with a colour band for spectograph, before automatic gain kicks in you can have over 1 on a band, so I made that push in to turning on the W, which worked well.

The result

Update: I have now tweaked and got cleaner response across the range, putting 50Hz to 6.4kHz in to 42 log based frequency bins. See youtube for frequency tests.

Now for use with a live band at the pub!

And HIWTSI (my son's business) is doing LED system installs now.