12 channel LED controller

A MQTT controlled 12 channel LED dimmer for home use

Similar projects worth following
In this project I design a board for controlling and dimming a number of conventional LED strips over a WiFi connection. The controller provides an MQTT client to the local network, which can be integrated into most home automation servers, like Home Assistant or OpenHAB, and used from there on.

This is my first electronics project of this kind, and currently WIP.

I've been looking for a project with a real use case for a while now, but most ideas I came up with didn't really make it far. A couple weeks ago it came to my mind that that room, which still has that makeshift lighting I installed years ago, could finally need some proper lighting, and I want to control it using HomeKit (or any home automation really), since that's what the cool kids do these days, right? And what better lighting is there than LED strips? So a project idea was born: Build a controller board for dimming a couple of light strips for the good part of an entire room, and have it controllable over WiFi. It should have enough channels to allow for a few independent RGB groups next to standard white lighting. I'm sure this is nothing groundbreaking, but great for learning and doing it as "proper" as I can.

The project is based around a STM32F1 microcontroller hooked up to a ATWINC1500 WiFi module. The choice of micro was a no-brainer, I've been fiddling with a dev board for a while now and it's a good time to actually use one of these chips. 

As for the WiFi module, I was kinda torn which direction I should go. Most would probably think of an ESP module as a first choice, but I dislike those various reasons. My first idea was to have a Raspberry Pi Zero W as a "daughterboard", which offers plenty of processing power and, of course, a working network/wireless stack, and can be hooked up using SPI. But the more thought went into this, the less I was convinced it's a good idea, first of all it's quite a chunky device which requires quite a bit of current, and it's overkill in almost every aspect, not to mention the possible instabilities with dying SD cards and whatnot. Then there was this module by Atmel, the ATWINC1500. It's a module which integrates both the WiFi and TCP/IP stack and can be hooked up via SPI to a relatively incapable host MCU. I actually had a look at this module a while back already, but never really had a use case.  So that's the route I went with, quickly ordered one from Mouser and built my project around that.

As a fan of industrial equipment, the board uses 3,81mm Phoenix Contact connectors all around. These are rated for 8A 150V, plenty for this use case. Only the main power connector could be a little bigger. A couple meters of LED strips, especially the RGBW ones I have, require quite a lot of current (4,5A@12V/5m at full brightness), but I guess it'll be fine for now. 

Each of the 12 outputs is individually controlled by a hardware PWM channel, which could theoretically provide up to 16 bit resolution. In practice, no more than 12 to 14 bit is realistic when trying to achieve decent frequencies. A switching frequency above 3kHz is recommended according to the Wikipedia article on the Flicker fusion threshold and an article by the IEEE Power Electronics Magazine to avoid any affects on humans. At a processor clock of 36MHz, 13 bits of resolution is the maximum to stay well above this threshold and provides a good amount of headroom (8,192 steps) for applying gamma correction:

As a little bonus, I also included an opto-isolated input terminal for attaching a switch, which will be equally exposed over MQTT for integration into a home automation system. Since I don't know any decently priced and technically adequate wall switches I thought this might be a nice addition, always pulling out your phone to turn the lights on might turn out to be a little annoying after a while.

The entire schematic and board layout was created in KiCAD and is available under the TAPR Open Hardware License on GitHub. The firmware is built on the LGPLv3 licensed libopencm3 library and is also available on GitHub. Both are linked on the left site of this project page.

  • 1 × STM32F101C8T6 Microprocessors, Microcontrollers, DSPs / ARM, RISC-Based Microcontrollers
  • 1 × ATWINC1500 WiFi module w/ integrated TCP/IP stack

  • It's not dead

    Markus Kasten05/27/2018 at 11:17 0 comments

    I haven't been writing updates for months now .. great. I'm currently quite busy with university and other projects, so there is not a whole lot of time left to work on the LED controller sadly. 

    I recently implemented some basic functionality to read and write configuration to the EEPROM. While this works quite okay, I noticed a significant flaw in my hardware design: There is no way to detect a powerdown and save to the EEPROM then, so the only way to save the current configuration is to do periodic or event-based writes. Depending on how this is implemented, it can wear the EEPROM quite a lot more than I'd like. I'll have to put a few more thoughts in how I'll accomplish that. 

    The next "bigger" task is to improve the reliability of the WiFi and MQTT connection. Currently the behaviour on a WiFi or MQTT disconnect is rather unknown, it might reconnect, or maybe not, or might flood the network with reconnects, I don't really know. Ideally the MQTT just tries to reconnect every X seconds when the connection is gone, and when the WiFi is gone I'd like it to behave like a Chromecast. Try to reconnect, otherwise create a provisioning access point to set up a new connection.

    Basic MQTT functionality is working quite good so far, I can control individual channels or groups of channels with Home Assistant, and the controller is reporting back on what the current values are. 

    I hope I can find a little more time in the future, but the next weeks aren't looking promising. We'll see.

  • A quick update

    Markus Kasten03/17/2018 at 21:15 0 comments

    Haven't written an update in a week, so here I am reporting progress.

    The PCB is fully assembled now, I also updated the project pictures with a few shots of the finished board. It really does look awesome I think, but maybe I'm a little biased :-)

    One smaller issue I found so far is the noise this thing makes when the outputs are switching heavily, i. e. PWM duty cycles around 40-60%. There is a super annoying, quite loud tone at high frequencies, a quick sound spectrum analysis showed peaks at 4, 9 and 13kHz. Its obvious these come from the switching current draw, and are likely caused by the inductor of the step down supply. I'll investigate the exact cause of this later when the project is in a mostly working state, it's not really a show stopper at this point.

    There is also some great progress on the firmware side of things. MQTT is now connecting, and after a couple of fixes also staying connected for longer periods. I implemented a few topics the controller is subscribed to today and pushing some messages from Home Assistant (and therefore from HomeKit) is working and even controlling the LEDs. Seeing that really was a big relief after all the trouble I had with Atmels API and getting it hooked up to the MQTT library I'm using. There was a point where I was thinking about ditching the entire MQTT idea, but luckily I kept investigating and finally got it working. I think I'll write a blog post (or should I say rant? Nah it's not that bad) on my experiences with the ATWINC module when I'm mostly done with the project and have some more experience with it, because there were some very interesting gotchas and marketing wanks in there probably worth writing about. 

    All the code is now pushed to GitHub, but the codebase is neither complete nor stable nor clean at this point. There is still a lot of unused, incomplete, hacked or error-prone code in there. I'm working hard on getting it all into a usable and maintainable state, but it'll take its time. I probably underestimated how much time and effort it takes to get all these different things working together properly. My lectures start again next week, so time will be limited starting from then but at least I got it into a state where I can show it off beforehand :-)

    I'll update the project with a video and a little more information once I can find the time.

  • First assembly

    Markus Kasten03/10/2018 at 20:26 0 comments

    Just a quick update on the PCBs. My parts arrived yesterday and I began assembling and testing the first PCB today. So far there were no major issues with either the parts or the boards. The only small problem I have found so far is my optocoupler footprint, which is a millimeter or two too short, but thats fixable by bending the pins slightly inwards.

    All soldering was done using a normal soldering iron with a range of tip sizes and 0.5mm solder, no fancy solder paste and reflow process for now. 

    I started with populating the buck converter/power supply. I never worked with this particular regulator chip before, so I was quite happy it worked on the first try. My design and layout was mostly based on whats recommended in the datasheet, giving it a good chance of working. I made some very basic ripple, load and efficiency measurements while no other parts were soldered to the PCB, which all gave satisfying results. I got around 80% efficiency, which is slightly below the datasheet values, but my measurements weren't the most precise ones either. 

    Further on, I soldered the microcontroller and all it's passives on the board. I must have made a slight mistake on one side of the QFP as I broke a couple of it's pads when removing some excess solder afterwards. Luckly all those pads traces went under the chip rather than outwards, and straightening out the loose pads with a sharp needle seemed to have mitigated the problem so far. 

    With the most essential components in place I started getting my firmware compiled and flashed for the STM32F1. There were a couple of gotchas with the pin remappings for the JTAG, SPI and PWM outputs, but I guess I was lucky it worked out in the end. I didn't went all too deep in the datasheet when assigning the pins in the schematic, and haven't worked with an F1 before, so I was a bit surpised it was that different from an F3.

    Getting the WiFi module soldered on with it's thermal pad on the bottom was a little tricky, but after a few tries I actually got it in place and without any shorts between the pins. I reused the one I made the adapter since I only ordered one so far, nice to see it survived being soldered multiple times.

    At this point, everything that worked on my dev board works in the real board by now. I think I can call myself super lucky there were no fatal shorts, on the first PCB I ever had manufactured :-) Most output MOSFETs aren't fitted yet, I left that open for later when I know there aren't any showstoppers left. Getting the firmware into a usable state is the only big remaining todo now. Having the whole stack of WiFi + MQTT + hardware work properly and avoiding a big spaghetti mess in the meantime turned out to be a bit harder than I initially thought (hoped), but it'll get there. Hopefully next week (I said that like a month ago..).

  • And they arrived!

    Markus Kasten03/07/2018 at 11:29 0 comments

    Beautiful, aren't they? That was really quick from Elecrow, awesome! I couldn't spot any shorts or other problems yet, fingers crossed.

    Unfortunately I don't have any components yet, and didn't really find the time to make any significant progress on the firmware side. Hopefully there is more to come this and next week.

  • PCBs ordered!

    Markus Kasten02/26/2018 at 19:47 0 comments

    The day has come, I finally ordered my first PCBs today! 10 boards were ordered from Elecrow, now I can't wait to have them arrive. Fingers crossed there aren't too many serious goofs left in the design. In the meantime its time to order all the parts I'm still missing, which is quite a long list actually.

    While the boards are in manufacturing, I hope to find the time to get the firmware in a usable state, with MQTT working and all. The IRQ issues I was having yesterday are fixed by now, bit of a stupid mistake. I had two scopes hooked up and was scratching my had why on earth the ISR isn't being called, just to find it's a falling edge instead of the rising edge I have to trigger on. What an obvious mistake that was, but you never stop learning :-)

  • Getting the WiFi module to work

    Markus Kasten02/25/2018 at 19:48 0 comments

    I finally received my ATWINC module last week, that means I'm one step closer to finishing off the board design. I tested the module against a print of the footprint I came up with, and to my surprise, it actually fits perfectly. There was just a little problem in the symbol I noticed later, which resulted in VCC not being connected, but that was sorted out quickly. While I was at it I also added an extra bypass cap to buffer the huge current spikes this module might produce when transmitting, it's never a bad idea to have some headroom for bypass caps on your board I guess.

    Next task is to get the module to actually talk to me, or my access point at home. Boy, what a mess it's been so far (well, to be fair, it could've been worse).

    ATWINC adapter board, dead bug style

    First of all I had to make an adapter board to get it hooked up to my dev board. I chose to solder it upside down, dead-bug style on a piece of perfboard and have all important connections available on a .1 inch header, plus add a couple of passives that are needed for proper operation. Soldering all these flimsy wires was a lot easier than I thought it would, with the exception of the ground pin which sucks all the heat away and makes soldering on wires a bit of a challenge. The board was done in two hours or so and didn't even show any fatal shorts upon checking it.

    I had the firmware prepped to a point where I thought it would just connect up to my WiFi, and I could see what works and what doesn't from there on. Turns out, nothing all. The board was so silent with anything I thought I killed it upon soldering. At least half a day of debugging later it turns out, my BSP (board support package) I wrote for the ATWINC driver wasn't returning a status after handling bus (SPI) transactions, which resulted in huge amounts of error messages and complete silence on the module site. 

    Next the driver greeted me with a pleasant "Firmware version mismatch" message, great. While updating the modules internal firmware isn't hard, the way of getting there had more hurdles than I would like. Most of the documentation and application notes only use the module with Atmels official dev board, which I don't have, so figuring how to get it to work without the board was one challenge. Luckily it can be updated over the internal UART after performing the reset sequence, which puts it in bootloader mode. The real frustrating part was getting the damn updater to update the module. Atmel only supplies the necessary tools for Windows, as binaries, without source code. I don't have a Windows machine, and I don't really want one. I tried to find how on earth these tools work to maybe make my own, but I couldn't find any documentation whatsoever on that. After probably spending another half day or so there wasn't really any other chance left than bite the bullet and find a Windows VM and update the firmware from there. Once all the undocumented options for the updater tool were figured out the updating was actually done rather easily, which is at least something positive in that experience. 

    With those problems sorted out, it was time to finally have it connect to my WiFi. Actually no, there were more problems. Talking to the module worked so far, but anything RF related resulted in all sorts of weird bus errors, again. I was expecting that it may be a power problem, but some measurements showed there wasn't any significant dip in supply voltage. To cut the story short, it was a faulty SPI implementation on my part. I basically built my SPI code on what was provided in an example in the SDK, turns out that particular example was different from all the other ones and resulted in really weird behaviour from the module on the SPI part. I don't really know what the problems was 'til this day, but at least I got that sorted. What a relief it was when the module debug UART finally showed a beautiful "(220)(M2M)WIFI Connected" message.

    But hey,...

    Read more »

  • Current status

    Markus Kasten02/20/2018 at 20:10 0 comments

    I'm currently waiting for some parts to arrive, mainly the WINC module. Since I never had one on hand I'd like to evaluate it works the way I think it does and fits my footprint before sending the design off to the PCB fab. I also haven't done a final check to make sure there are no errors left in the design, I'll do that once I know all my footprints are fine.

    The firmware is also work in progress, but I can only do so much without the module connected. The basic stuff is done, but all the interesting bits are still missing.

    I also decided today that I'll be licensing the hardware design files under the TAPR Open Hardware License, this license seems like a good mix between openness and still preserving some control over what happens with your project to me.

    My goal is to get the PCBs ordered next week or so and have a board assembled to a point where basic functionality works by the end of March, but well, Murphy is gonna get me anyway.

View all 7 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates