IR LED controllers

I ordered a couple of LED controller remotes.

Now to work out how they work.

The first (big one) is simple 32 bit NEC coded (i.e. address, inverted address, code, inverted code) with address 00. Laid out as follows for the code:-

5C 5D 41 40

58 59 45 44

54 55 49 48

50 51 4D 4C

1C 1D 1E 1F

18 19 1A 1B

14 15 16 17

10 11 12 13

0C 0D 0E 0F

08 09 0A 0B

04 05 06 07

As you see, this has some pattern to it, but why not literally a proper grid or sequence, why this. But OK, I can cope. I plan to make my LED controller boards have IR receivers and understand this in some sane way - with extra keys like DIY1 do device automation to Home Assistant.

But what of the smaller one?

Well this is special, it is 32 bits, just like an NEC remote, but the first bytes are 00 EF not address and inverted address. I mean, it is distinctive, and consistent on all keys, but not quite standard. The code is still code and inverted code though. The codes are then:

00 01 02 03

04 05 06 07

08 09 0A 0B

0C 0D 0E 0F

10 11 12 13

14 15 16 17

This is way more logical key codes.

Simpler

For completeness, this is a nice simple IR from Amazon.

Which is address 00 and codes:

45 46 47

44 40 43

07 15 09

16 19 0D

   18

08 1C 5A

   52

Which, as you can see, is all over the place! 

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

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.

Dialling the gate

People will know I am a slight Stargate fan (!), and I like making PCBs. So, well... Latest is...

LEDs

First off, the LEDs. There is a very popular LED format, a WS2812B chip and RGB LEDs in a package. These use a serial daisy chained control channel allowing 256 colours of each of Red, Green, and Blue, to be loaded individually to a whole chain of LEDs. This design has 372 LEDs.

There are standard libraries to drive these, but I have discovered the ESP32 S3 is better as it uses DMA for the "remote control" hardware that is used to drive the data for these LEDs.

You can get these on tapes, and rings, and so on, usually 5mm x 5mm, or 4mm by 4mm, and I had even seen some 2mm x 2mm, but was surprised to find they are now available in these tiny 1mm x 1mm format. This ring design has a 100mm diameter centre hole.

They also usually need 5V power, but amazingly these small 1mm x 1mm modules work on 3.3V (or 5V), which is impressive (Blue is usually the voltage hog).

They are also very cheap. Part XL-1010RGBC-WS2812B, LCSC Part C5349953.

Alignment

My first mistake with the LEDs was making the layout simple, so a grid of these LEDs were one way up on one row, and the other way up on the next row. This allowed GND to be between two rows, then VCC between two rows, and so on. I put caps at the ends of the rows (which works well). This allowed me to pack them at 1.6mm spacing.

This was impressive, but I missed the (apparently well know) issue that the LEDs are placed within the 1mm x 1mm space, so for example Red is one side, and hence an all grid red looks like this, not evenly spaced.

They have to all be the same way around to avoid such issues.

Diamonds

I tried doing the same way and really a pain to track. The trick is to actually place them at 45 degrees, diamond style. This makes tracking really simple.

This allows a track at the top for GND, and at the bottom for VCC, and a link from LED to LED corner to corner for the daisy chained data line. Shown here I have vias for extra power. With thin tracks between the pads of the capacitors (expected to be one per LED) it makes for a really neat layout.

Grids

Grids were easy, and grids of LEDs like this are simple, with 2mm spacing (no caps), which is not bad. Caps added at end of row or column.

Apart from tracks joining VCC and GND top and bottom, or side and side, I actually created zone fills to make for thicker overall power tracks.

The latest design at 2mm spacing is 10mm x 18mm for a 5x7 grid, and allows them to be placed next to each other for a whole row at 2mm spacing, LEDs at the top and bottom of each column.

Rings

The other thing to do was rings of LEDs.

The principle is pretty simple, tracks (this time arcs) for GND, data, and VCC. Some zone fill for VCC and GND, again arcs (well polygons and lots of points).

Adding vias is fun, and I ended up with code that puts them off to one side if diodes and caps too close together (as above image) or in line in the GND/VCC tracks when enough space.

A simple ring with evenly spaces LEDs and caps is easy, but then I decided I needed some grouping of LEDs together with specific tighter spacing (the chevrons in the top image).

I also had to cater for the fact that power vias from one ring could clash with some of the next ring, and so omit some that were too close.

C code

If you have tried doing this in KiCad, it is far from easy - even with the grid locking and simple spacing like 2mm, it is hard, and making a ring with 39 LEDs, i.e. 4.6153846 degrees between LED and cap and LED, is, well, totally impossible. No chance doing it manually at all.

So, obviously, I ended up making C code, parsing in the PCB file, and moving LEDs and caps and making tracks and vias and fill zones. I have code for grid layout and ring layout now.

The gate

Working out the exact animation for the gate will need a bit of trial and error I expect - I cannot actually spin the symbols, so some poetic licence involved, but easy to "spin" the rings of 117 LEDs.

I have actually gone for a number of rings...

• 117 inner rings, this is 3 per gate symbol, so makes for a nice "1 in 3" spin effect and allows the inner to be lit up and made sparkly for the gate open.
• 39 gate symbol ring, so I can light individual symbols during dialling (seeing as they don't spin).
• 18 ring for bottom of engaged chevrons (9 chevrons, so 2 per chevron).
• 117 outer ring, again for spinning, but also can be two for chevron when engaged, and 3 for chevron end when not.
• Two 18 rings for chevrons getting wider.
• A 45 ring, so 5 per chevron, for the lights at the edge of the gate when selected.

I think making it dial will be cool. PCBs ordered, so a week or so (maybe more, some holiday in China), and I can post video of the real thing.

Open source

This is all open source, PCB designs and code, but if you want to buy one of these, and a driver, let me know. I have 5 on order.