But that does not matter, nobody cares.

• Not the market as it's big enough and everybody does it, unless somebody dumps.
• Not the users as more competition is good for them, unless it's garbage.
• Not the competitors as they have better things to do and rather focus on themselves, unless their patents or copyrights are infringed. Also, trade secrets are weird...^[1]

People will buy/consume/use stuff for a lot of reasons unconnected to originality:

• Because it's cheaper
• Because you're not the competitor
• Because you're local
• Because you're smaller
• Because you're on another platform

Or simply because they did not bother to look any further.
I mean, when was the last time you strayed from the safety of the first page of results?

So even just being placed better than someone else — whether out of luck, some kind of business practice or a gruesome sacrifice to a god — matters more than how original your work is.

The economic human being, the Homo economicus^[2], does not exist.

2. Aim for originality in both process and execution

While today you will seldom find something completely new, there are always ideas that mix and match old ones together in new ways.
Therefore I would argue the combination and remixing of something that already exists CAN be called an act of originality. So, there is a distinction to be made between original and originality.

2.1 But where do we find those new and/or improved ideas?

There is a saying, that innovation happens at the intersection of two or more fields.
So when you create a patchwork of ideas^[3] and recycle existing ideas you are innovating.
You take a lot of ideas someone else already created and made something cohesive and useful out of it, basically something worth more than the sum of their parts. What you combine and in what ways, that is your act of originality.

That means you are less of a creator and more a mad alchemist combining various substances until the philosopher's stone plops out and you have to secure it behind a big three-headed dog with a very inconspicuous name.^[4]

And even if two products are the same, the way they have been derived — the nuances between the processes — gives them their originality.

2.1 Look out into the world

I mean, take a look at games.

All those different multiplayer shooters, some may truly be exploring some interesting combinations of ideas, but others are more down to earth — you pull the trigger, bullets come shooting — they're all quite similar yet have taken different ways to the same goal.

Or if you take a look at those different space games up there, wouldn't you say EVE, No Man's Sky and Elite Dangerous are quite different, even though they have massive overlap when it comes to more general features?

Each one of them lures in a slightly different kind of user; has its own slightly different kind of market.

But there are some games out there that are exploring very interesting combinations.

BPM and Necrodancer are interesting for both rhythm gamers and fans of classical shooters or dungeon-crawlers respectively, while Sea of thieves makes being a pirate a multiplayer experience for entire groups of friends.

Even most works of fiction today build on top of age-old ideas.

The fables and tales of the olden days. Elves, Gnomes, Dwarfs. Even angels, demons and daemons^[5].
Some stories, like fanfictions or derivative works, reuse parts of the same world to tell entirely different stories. Exploring the yet untold stories of a world that already exists.

And a lot of people enjoy diving into stories that remind them of those they already read. They have a favorite genre. They want similar stories exploring different twists that create an entirely different experience.

And then there's… well… ever heard of Warhammer^[6]?

3. Final words

Oh well, my focus seems to have drifted rather heavily into the creative realm.

Nevertheless, my point still stands.

There might be nothing original left to create, but many patchworks of ideas are still undiscovered.
And even if a very similar one already exists, remember, no patchwork looks quite the same.

So just create what you want to create.
Will it work out? Well, you'll never know without trying first.

1.Look up the legality of trade-secret reverse engineering, it's wild
2.https://en.wikipedia.org/wiki/Homo_economicus
3.https://en.wikipedia.org/wiki/Personal_knowledge_management
4.https://en.wikipedia.org/wiki/Daimon
5.You're a wizard 'arry
6.https://en.wikipedia.org/wiki/Warhammer_40,000#Spin-off_games,_novels,_and_other_media

Today I want to showcase an easy upgrade applicable to most embedded devices that greatly increases the quality of your RGB(W) LEDs color output.

PWM - The basics

When first learning about controlling LEDs via, for example, Arduino, you will be introduced to PWM, Pulse Width Modulation, a technique to get the effect of dimming without actually changing the resistance in the circuit to get a specific voltage.

It tricks our eyes into thinking the light is at a specific brightness by turning it on and off very quickly(Pulse) within a time-frame where the Width of the changing signal(Modulation) is proportional to the amount of brightness wanted.

This also circumvents the problem of the differences in emission between LEDs(even if they are of the same color/type) which are especially large in the low-power range.^[2] But as that is out of the scope of this article, check out the corresponding source for more information on that.

Take a look at the following two graphs showcasing two different duty cycles, one at 50% and one at 75%. The duty cycle of a PWM signal describes the amount of time it is turned on within a specific time-frame and is therefore roughly equivalent to the brightness of a connected LED.

This time-frame is described by the frequency of the PWM signal, as the time it takes for the signal to turn on, off, and on again. Most of the time you will find this represented in the number of repetitions within a second, otherwise known as Hertz.
The size of the frequency has some influence on the artifacts you might encounter. But more on that later.

Within a time-frame, you could theoretically have an infinite amount of different duty cycles. But that is not the case.

We are sadly limited by physics, the devices we use, and our configuration.
And we are here for the last one of those.

The amount of Granularity that can be archived with the duty cycle in a given PWM System is controlled by its resolution. Which is either represented with its size in bits or the number of steps possible.

When working with PWM to control light you most certainly worked with 8 bits in form of a value between 0 and 255. This is the default for most systems and tutorials.

Yet most of those systems support even higher bit-rates with almost no drawbacks. In this case, I have chosen 16 bits for its high support, only minimal drawbacks, and because it is right at the edge where the increase of benefits becomes less noticeable with each increase in resolution.

Massive increase in steps

An increase in resolution allows us to have a lot finer dimming control of the different LEDs, as we have now about 65280 more steps of resolution(an increase of 256%).
Which is where the fun begins.

When it comes to mixing colors you get a massive increase in color fidelity, for RGB from 16 Million(256³) to 281 Trillion(65536³) and for RGBW from 4 Billion(256⁴) to 18 Quintillion(65536⁴).

Just don't try to imagine that, it's a lost cause.

With this high amount of granularity dimming without any visible jumps becomes possible, which is especially important in the low-power range as our eyes are more sensitive there.
Gamma correction is now also way easier, which is making the dimming more natural to the eye.^[1]

For gamma correction to work we are in essence mapping a quadratic function - as that is how our eyes(approximately) perceive changes in brightness - to our available granularity. And that is with 65536 steps just way easier(read: results in smaller errors) than mapping it to 256 steps.

The following two graphs show just that:

Feel free to zoom in
16 bit version is down-sampled to not overwhelm your browser
To toggle, press the above button and zoom again

And last but not least, we can now more precisely convert to other color formats without having huge jumps in the output color and brightness. I find the Hue-Saturation-*(HS*) family of formats to be a particularly good starting point.

You might know, that when you mix RGB(and W) colors you traverse the area of a cube along the axis R, G and B. From a technical standpoint, this is the optimal way to control an RGB(W) system, but when it comes to humans most of us do not have internalized color mixing in this way.

For us, a color wheel is a much better option, in combination with a way to control the amount of brightness and color(otherwise known as saturation).
In the case of the HS* family, we traverse either a cylinder, cone or bicone, where the rotation around the surface changes the Hue, traversing inwards changes the saturation and moving up/down changes the brightness.

The star in the name depends on the method chosen to calculate the brightness. And there are a lot of different methods, just find one that suits your needs. For more information about that you might wanna check out my stuff here as well as the awesome material at SaikoLED, which is where I get a lot of my references from.

The thing about the frequency

While there are some small obvious drawbacks like more use of CPU time and the need for bigger data types there is also one that I hinted at with the frequency.

As our device needs more time for higher resolutions to calculate and transmit them, this, in turn, decreases the maximum frequency that can be reached the higher in resolution we go.

That means with a frequency low enough you will be able to see the light flickering. But even before we reach that point this effect will show up on cameras as either flickering or visible color bands as the light is changing.
And not only cameras are able to notice this rapid flickering. Because even though we may not be able to consciously register it, it still affects us by inducing eye strain at lower frequencies.^[4]

And while I was not able to find a specific frequency for which this is true, the article in the footnote claims that anything above 400Hz should be fine. Which shouldn't be a problem with most devices. In case of the ESP32 you can calculate the maximum frequency of a given resolution like this:

$$\frac{timer\_clock}{2^{resolution}} \Rightarrow \frac{80\verb|MHz|}{2^{16}} \approx 1220\verb|Hz|$$

And last but not least, to fix the flickering issue with cameras you can simply adjust your shutter speed to be a multiple of the frequency of your LEDs.

All in all, I find the upgrade to 16 bits to be a seamless one, with a great increase in color fidelity and dimming resolution that leads to easier to control colors and the ability to correct for the human vision. And the drawbacks are for most use-cases, to put it frankly, non-existent.

Summary

Thank you for reading! If you liked this article please feel free to take a look around, like and comment and maybe even share it.

Benefits

• Smoother gradients
• Finer color control especially in the low-level range
• - > As our eyes are quite sensitive there and jumps are quite noticeable
• Better color correction -> quadratic mapping
• Allows HS* color formats to work more effectively
• Easy upgrade already supported by most devices

Costs

• General overhead
• the decrease in frequency that comes with an increase in resolution might cause visual artifacts as well as eye strain if the frequency is too low

Sources:

1. https://blog.saikoled.com/post/45630908157/implementing-arbitrary-color-correction-with-the
2. https://www.instyleled.co.uk/8bit-vs-16bit-led-control/
3. https://www.mothergrid.de/fachwissen/dimming-led-lights-basics-and-difficulties/ 4.https://www.led-professional.com/resources-1/articles/flicker-beyond-perception-limits-a-summary-of-lesser-known-research-results

For the last few weeks, I played around with controlling my LEDs over the network by mapping a MIDI keyboards dials to each of my color controllers settings.

Now I want to share my results and the code with you as well as some of the things I learned along the way.

Full HD version of the video above:

In this article, I will give an overview of the client software written in python, showcase a plug and play WiFi setup, how to announce and find the device in the network, and the basic principles of how to get an ESP32 to accept and act out some commands.

If you want to know more about the basic setup for the RGBW controller, check out this article.

And if you want to try this out yourself consider using this amazon affiliate link to get the same keyboard I have and help me pay my bills.

1. The Client

1.1 Reading data from the keyboard

To actually have something to send we need to have a client that reads the MIDI data, transforms it, and generates the command for the server.

We'll be reading the incoming data by parsing the incoming USB data and converting it into usable MIDI data using the midi subpackage of pygame.

I will be using pipenv for easier package management:

# Install pipenv
pip install --user --upgrade pipenv
# Install pygame
pipenv install pygame
# Enter virtualenv
pipenv shell

Now we can have the pygame.midi package print us out all midi devices:

import pygame.midi

def get_devices():
    devices = []
    for n in range(pygame.midi.get_count()):
        info = pygame.midi.get_device_info(n)
        if (info[2]): # Check if the device has the input flag
            print (n,info[1]) # (device id, device name)
            devices.append(n)
    return devices

pygame.midi.init()
print(get_devices())

We will then connect to the MIDI device of our choosing by its device id. Listening in, we will ignore any key-presses and only work with the dials and button presses:

buttons = [*range(16, 23 + 1), 64]
dials = [*range(1, 8 + 1)]

def readInput(input_device):
    while True:
        if input_device.poll():
            event = input_device.read(1)[0][0] # Strip away irrelevant data
            if (event[0] != 176): # Check if this is a change event for a mode/control (this is device channel 1 only, you might want to check 176 to 191)
               	if (debug or event[0] not in [144,]):
                    print (event)
                continue
            if (event[1] in dials): # Check if it's a dial
                dial_handler(event)
            elif (event[1] in buttons): # Check if it's a button
                button_handler(event)
            else:
                print (f"ID: {event[1]}, State: {round(event[2]/127,2)}")
        send_data()


my_input = pygame.midi.Input(device_id)
try:
    readInput(my_input)
except KeyboardInterrupt:
    my_input.close()

Let's take a look at the handler for the dials:

dialdata = {}

def dial_handler(event):
    pos = event[2] / 127 # Remapping to 0 to 1 
    print(f"Dial {event[1]} at position {round(pos, 10)}") # Mandatory print statement
    dialdata[event[1]] = pos # Take a guess.. event[1] is the dial id

Skipping the button code as it is only relevant for switching the color mode which is irrelevant for this article. Also removed some code that uses the second row of the dials for fine tuning purposes, for the same reason.

1.2 Compiling data to be send

The send_data function will now take the dialdata, transform it, and finally send it to the server:

stime = 0
last_fill = [-1, -1, -1, -1]

def send_data():
    global stime # I know I know global vars are ugly but this is not clean code 101
    global last_fill
    ptime = int(round(time.time() * 1000)) - stime
    if (cm and ptime > 10): # cm and ptime will be explained below
        fill = [-1, -1, -1, -1] # -1 represents a "keep value" state
        for i in range(1, 4 + 1): # Just filling the array with our dialdata
            fdata = dialdata.get(i, -1)
            if (fdata == -1):
                continue
            # I thought here was some fine tuning code somewhere...
            fill[i - 1] = fdata
        if (fill == last_fill): # Why would we send a new command if nothing changed?
            return
        last_fill = fill
        f = fill
        m = "manual" # For simplicity sake, check the source code for more interesting stuff
        bridge.send_command(cm, "set", [m, *f]) # "set" and the m, *f array are just the type of the command and it's respective data.. more on that later
        stime = int(round(time.time() * 1000))

First of all, what is this stime and what is it doing there?
Well, to not overwhelm the ESP by directly sending the status of the MIDI dials to it, causing it to queue up commands that will be overwritten by the newest one anyway,
we will have to limit the number of times we actually send the data.

In my case, I will wait 10 ms before sending the next command.
Which is coincidentally about the same time the ESP takes to update its color and become ready for the next command.

To be able to understand how we are sending data we need to understand what a command is first.

It is an identifier for the action that should be performed, followed by its respective options. It is then sent over a TCP connection to the server.
A command to turn on all LEDs looks like this:

set manual 1 1 1 1 \n
│   │      │ │ │ │
│   │      │ │ │ └> White value
│   │      │ │ └> Blue value
│   │      │ └> Green value
│   │      └> Red value
│   └> how should the parameters be interpreted?
└> set color to ...

Note the newline character on the end as it will be essential for performance later on.

1.3 Sending the data

To construct the command from its parameters, encoding it to be sent as bytes and actually sending it we will use this code:

def send_command(socket, command, options):
    socket.send(f"{command} {' '.join(str(x) for x in options)} \n".encode("utf-8"))

But how do we get this socket?

This socket or cs from the send_data function further up stands for command socket and is basically our command line that gets injected into the send_command function to make it stateless and therefore easier to use.

To open this socket we first have to find out the IP of the ESP.
Thankfully the ESP is constantly screaming into the endless void of the network that it indeed exists. (more on that later) And if we are willing to listen to its desperate screams by opening a specific port that it broadcasts to we can get its IP:

from socket import *

def open_listener():
    bclistener = socket(AF_INET, SOCK_DGRAM) # Some setup stuff
    bclistener.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1) # Some more setup stuff
    bclistener.bind(('0.0.0.0', 24444)) # Listening on port 24444
    return bclistener

def await_controller(bclistener):
    while True:
        message = bclistener.recvfrom(64) # Reading message from socket
        if (message[0] == b'ThatLEDController online!'): # Checking for specific message
            return message[1][0] # Returning ip


bc = open_listener()
ip = await_controller(bc)

Now that we got the IP we can plug that into a socket and open our command socket. Here is a handy function for that:

def open_sender(ip):
    cmsender = socket(AF_INET, SOCK_STREAM) # Some setup
    cmsender.connect((ip, 25555)) # Connecting to port 25555 at 'ip'
    return cmsender
    
cs = open_sender(ip)

Now that the client is implemented, let's build the server side, shall we?

2. The Server

2.1 Connecting to the network

The basic way to connect an ESP32 to the network would be to include the WIFI library, throw some (generally hardcoded) credentials against it and hope it connects:

#include <WiFi.h>
 
const char* ssid = "SSID";
const char* password =  "Password";
 
void setup() {
  Serial.begin(115200);
 
  WiFi.begin(ssid, password);
 
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.println("Connecting to WiFi..");
  }
 
  Serial.println("Connected to the WiFi network");
 
}

But luckily there is a library called WiFiManager that does this and much more for us with little to no configuration. It tries to connect to a predefined or saved network and when that fails, opens an AP on its own that that allows you to specify a network that it will then try to connect to:

#include <WiFiManager.h>
#include <WiFi.h>
#include <WebServer.h>

WiFiManager wifiManager;

void setup() {
  // Configure wifi
  WiFi.mode(WIFI_STA);
  
  // Set dark mode
  wifiManager.setClass("invert");
  
  // Set manager to not blocking
  wifiManager.setConfigPortalBlocking(false);
  
  // Automatically connect to saved network
  // or open network named "ThatLEDController"
  // You can also pass this function a predefined network
  wifiManager.autoConnect("ThatLEDController"); 
}

void loop() {
  // Non blocking process function
  wifiManager.process();
}

OK, WiFi connection check, now how about allowing the client to actually find us?

2.2 Finding the ESP

To reliably connect to the device without relying on a hardcoded IP address, we will let the ESP tell it to us on its own. Well, not just us but rather the entire network.  

We will use something called broadcasting for that, that allows you to send some data to a specific IP address in the network(most of the time something with 255 on the end) and it will be relayed to every client connected:

#include <AsyncUDP.h>
#include <WiFi.h>

// Non blocking wait helper
#define runEvery(t) for (static uint16_t _lasttime;\
                         (uint16_t)((uint16_t)millis() - _lasttime) >= (t);\
                         _lasttime += (t))

AsyncUDP udp;

void setup() {
  // Setup wifi
}

void loop() {
  runEvery(2000) { // Please don't spam the network
    if (WiFi.status() == WL_CONNECTED) { // Check if we are connected
      IPAddress broadcastip;
      broadcastip = ~WiFi.subnetMask() | WiFi.gatewayIP(); // Get broadcast address for current address range
      if(udp.connect(broadcastip, 24444)) { // Open connection to port 24444
        udp.print("ThatLEDController online!"); // Send message
      }
      udp.close(); // Close connection again
    }
  }
}

Moving on to the actual command server.

2.3 Setting up a basic server

Here is the basic setup for a simple single client TCP server running on port 25555:

#include <WiFi.h>

WiFiServer wifiServer(25555); // Open server on port 25555
WifiClient wifiClient;

void setup() {
  // Setup wifi
  
  wifiServer.begin(); // Start server
}

void CheckForConnection() {
  if (wifiServer.hasClient()) { // Check if there is already a client
    if (wifiClient.connected()) { // Check if the client is actually connected
      wifiServer.available().stop(); // Reject new client
    } else {
      wifiClient = wifiServer.available(); // Accept new client
      Serial.println("Client connected!");
      wifiClient.write("Hey there!"); // Send welcome message
    }
  }
}

void loop() {
  CheckForConnection();
}

You can test that it works using netcat:

nc 0.0.0.0 25555

Now there should be a server running that we can extend to accept some commands.

2.4 Receiving commands

First, we will have to read the command into a variable.
We will do this with a blocking function, as we have defined the commands to end with a newline which makes it faster than reading it in chunks. Add this part after the connection check:

if (wifiClient.available()) {
    std::string cm(wifiClient.readStringUntil('\n').c_str());
    Serial.println(cm.c_str());
}

We will now check if the first three characters are actually "set" and if that's true pass is on to the handler function:

if (wifiClient.available()) {
    std::string cm(wifiClient.readStringUntil('\n').c_str());
    if (cm.rfind("set ", 0) == 0) {
        setCmd(cm);
    }
}

The handler function will then split the command at the spaces and check if it is actually long enough. After that the respective values will be extracted and a new color is set:

std::string mode = "hsv";
std::array<int, 4> fill = {0, 0, 0, 0};
std::array<std::string, 4> modes = {"manual", "rgb", "hsv", "hsi"};

// Helper function to split string at delimiter
std::vector<std::string> split (const std::string& str, char delimiter) {
  std::vector<std::string> tokens;
  std::string token;
  std::istringstream tokenStream(str);
  while(std::getline(tokenStream, token, delimiter)) {
    tokens.push_back(token);
  }
  return tokens;
}

void setCmd(std::string str) {
  std::vector<std::string> tokens = split(str, ' '); // Split string at spaces
  
  if (tokens.size() <= 1) { // Return if the command is to short
    return;
  }
  
  // Get what could be the mode from the extracted tokens
  std::string tmode = tokens[1]; 
  
  // Loop over tokens and extract color, ignore if the data is negative
  // resolution_factor is the pwm range
  int tsize = tokens.size() - 2;
  std::array<int, 4> color;
  for (size_t i = 0; i < 4; i++) {
    color[i] = i < tsize ? atof(tokens[i + 2].c_str()) * config::resolution_factor : fill[i];
    color[i] = color[i] >= 0 ? color[i] : fill[i]; 
  }
  
  // Set mode to extracted mode, if extracted mode is valid
  if (std::find(std::begin(modes), std::end(modes), tmode) != std::end(modes)) {
    mode = tmode;
  }
  
  
  fill = color;
}

And now there be light.

3. Conclusion and a look into the future

For a single device, this setup works great, even though it has some problems with reconnecting to the device. But that can easily be fixed by allowing new devices to override the already connected one.

I also added a preprocessor flag to my light controller that allows to deactivate anything but the command server, network code, and basic pin setup. This should save some resources when the direct interface is not needed.

In the long run, however, I want to expand the system to allow for more devices in the same network and create an interface to control them. (electron-based maybe?)

Furthermore, I might even try to connect the MIDI keyboard directly to the ESP as it technically acts as a USB host. But having to handle the USB to usable MIDI data conversion myself might be a bit overwhelming.

Anyway, that's all, thanks for reading!

Check out my sourcecode for the >client< and >server<

I got the original idea for this project after watching a video by DIY Perks.

He shows how to extract the backlights of old monitors as well as TVs and explains the effects of the different layers build into them and how they make for a better light source:

I will start after the actual extraction process and explain how I created my own RGBW controller with an ESP32, some buttons, and a small display.

As I'm writing parts of this in retrospect I won't be able to show every step but rather the respective parts.

1. Preparing the backlight

The only thing I did after fully disassembling the backlight was to replace the build-in fluorescent lamps with an RGBW strip.

The strip was split into two and connected with some wires I had lying around. After that, I added some milky plastic in front of the strip for some additional diffusion and assembled the backlight again.

2. Designing the controller

2.1 The microcontroller

For the project, I wanted to prototype fast and without being too concerned about the limitations of the hardware.

That's why the ESP32 was such an easy choice, as it:

• is quite small
• has moderate ram and flash storage
• has integrated WiFi and Bluetooth
• is something I have experience with
• is fast enough for more complicated computations(animations or different color selections for example)

2.2 Choosing an IDE

For a development platform, I deliberately chose against using ArduinoIDE even though I'm using its framework and am experienced with the IDE.

What I did chose is the VSCode integration PlatformIO, which allows to easily build projects for Arduinos, ESPs, and the likes. And as it is integrated into VSC it can leverage all the other integrations and tools build into that.

In addition to that is PlatformIO more friendly for bigger and more structured projects and encourages them, as it's:

• creating a local lib folder for project-specific libraries
• creating a test folder to be used by the PIO unit test framework
• having project configurations in an extra file allowing for multiple devices and environments in the same project

2.3 Deciding on a framework

The last part of the puzzle was deciding on the actual framework to use.
Like I said above I chose Arduino, but let's see what frameworks I looked at and why I decided that way.  

I had to decide between the standard Arduino framework that works with almost every microcontroller under the sun and the ESP specific framework ESP-IDF provided by the manufacturer.

The standard Arduino framework has far more libraries than the ESP one, taking away lots of the work needed. ESP-IDF, on the other hand, allows to fully take advantage of all features the ESP provides, without any workarounds and loss of performance.

And while fully utilizing the capabilities of the ESP32 sounded like fun, I wanted to leverage as much of the already existing tools already written for Arduino, for example, the display library I'm using, without having to port everything to work with ESP-IDF.

In addition to that, I already had a lot of experience working with the Arduino framework.

3. Designing the board

3.1 Materials

As I did not want to build the additional periphery needed to work with a bare-bone ESP32 I opted for a devboard variant that already included those things and does not need to be surface mounted. And to save myself some headaches I also got some female headers as well to be able to swap out the board should I accidentally kill it, like I inadvertently would(already did.. twice..).

While I originally wanted the controller to be primarily used wirelessly, I soon realized that it would be much better to also have some way to directly interact with the device.
That would allow the device to be much simpler and much more immediate to control as well as allowing me to focus on the basic features of an RGBW controller without having to implement any WiFi or Bluetooth support from the get-go.
And that's why I added a small OLED display and three buttons.

Not wanting to power the controller with two different voltages I added an L7805 voltage regulator as well. The devboard I used directly supports 5V so there was no need to get a regulator that outputs 3.3V. As with most voltage regulators, there is one capacitor added between the input and ground and one between output and ground to increase stability. In my case, they're both 100uF electrolytic ones.

Lastly, to actually control my RGBW strip running on 12V I opted for some IRFZ44N MOSFETs that would allow me to switch the 12V using the 3.3V of the ESP32.
Additionally, there will be a 1k resistor between the gate of the MOSFET and the pin of the ESP to dampen unwanted oscillation.

That means in terms of electronic components, minus cables and connectors, we got:

• 1 x ESP32 devboard (amazon affiliate link)
• 1 x L7805 voltage regulator
• 2 x 100uF electrolytic capacitors
• 4 x IRFZ44N MOSFETs
• 4 x 1k resistors
• 1 x OLED display (amazon affiliate link)
• 3 x buttons
• 1 x RGBW strip (amazon affiliate link)

To the lower left, we got the 12V power jack as well as the connector for the display, in the center at the top we got the voltage regulator that takes in the 12V and converts it to 5V for the microcontroller.
To the right, we got the three buttons at the top and the four MOSFETs at the bottom.
And last but not least: that giant thing in the upper left corner is the devboard, unsurprisingly.

3.2 The perfboard prototype

This horrendous looking thing is the cobbled-together version of my initial idea of a simple RGBW controller to which I later added the display and buttons, as well as a cable for one of the internal touch sensors of the ESP that I later removed.

The stuff I fucked up:

• Wired the MOSFETs the wrong way and had to cheat to get them connected the right way
• Did not use any of the internal resistors you can activate from code(pulling down the buttons in this case)
• Tried to use an input-only pin for PWM output, had to rewire a fair bit
• The display is directly connected to the headers from below with some thin wires and is therefore easy to rip off accidentally

3.3 First PCB prototype

After finishing the prototype and the first iteration of the codebase I started to create an actual PCB design, trying to fix some of the issues mentioned above and get something better looking.

Yet I still made some mistakes, given my inexperience with designing PCBs or even designing circuits for that matter:

• Placing the MOSFETs in the lower right made them quite hard to route
• Why is the SPI connector to the left of the power jack?
• 12V wires are to thin to support the RGBW strip at its max current draw
• Lacking any kind of meaningful labels

4. The actual coding

4.1 Designing the interface

Designing the interface was actually quite a lot of fun. Having such a limited amount of pixels that you could, in fact, count them, but enough to not have to work that abstractly made it a manageable task.

The library I was using to control the display had some nice helper functions that made my life a lot easier. So I used my math skills to create a simple formula that could, given some amounts and spacing information, return the distance between two elements.

This allowed me to dynamically set the number of sections I wanted and place elements accordingly. And while my original idea to use circles was technically working but, let's say.. not that pleasant to the eye in terms of symmetry, replacing them with some rectangular bars that fill up accordingly from the bottom worked even better.

4.2 Adding HSV

After cleaning up my code somewhat and separating it into manageable chunks I started to add some more features.

To make it easier to select a specific color without having to know its RGB components and without needing to try too many times, I chose to add a second color model called HSV that represents a given color by its Hue, Saturation, and Value.

Hue is the actual color of the light.

Saturation is the amount of white mixed into the light.

Value adjusts the brightness of the light itself.

4.3 Calculating white color portion

To actually use the W in the RGBW strip we need to calculate how desaturated the color is and use that to set the amount of white. If you want some more in-depth explanation check out my other post.

But the simplest way to do this is just to get the smallest of the RGB values, set white to that and set the original value to zero.

You might have been able to see from the picture of the display above that I kept the ability to set a value for W. It now controls how much white of the RGB spectrum is converted to the white LED. 0(or 0.0) is no conversion and 255(or 1.0) is a full conversion.

4.4 Adding some unit tests

To catch some problems early on I followed my own advice and started adding some unit tests. They are currently only there to test that I didn't fuck up the color conversions but will be extended to other parts of the code in the future.

As I extracted the color code into its own library I can now test it natively without having a board to test it on lying around.

5. Conclusion and a look into the future

5.1 Conclusion

The process of creating the controller as well as playing around with the LEDs was a lot of fun that I want to continue with in the future.

And after transforming my spaghetti code into more manageable chunks and writing some actual unit tests working with the code became a lot easier and makes it actually extendable for features that I want to add in the future.

I learned a fair bit about color regarding the RGB color space as well as color mixing in general and how to use my white LED. More about that here.
In addition to that, I started to get better at working with microcontrollers in general and how to handle them. More about that here.

All in all a very enjoyable process.. not that I thought that while working at the project.. that consisted of a lot more swearing.

But as I do not want to stop the project yet, here is a look into the future:

5.2 Design a better board

Before I get some actual PCBs I want to clean a few things up and change some of the control elements. This is the second version of the design that also supports longer strips without melting the traces as well as some rotary encoders instead of the hard to control buttons.

This is the version of the board that I actually want to get professionally made. There might be one or two things that will change before that happens but it's the general idea.

Changes:

• Replaced buttons with two rotary encoders
• Adjusted trace width for the 12V wires(2mm width, 0.6mm clearance)
• Moved MOSFETs closer to the connector

Criticism:

• Still missing labels for the connectors

5.3 Continue working on the controller firmware

I'm working on a better way to control the connected display with some more "high-level" functions. In the future, I want to be able to add and remove different displays with ease and switch between them.

I also want to add support for RGB+CCT(that are strips with two different white LEDs) as well as strips with individually addressable LEDs.
That would mean that I have to add one more MOSFET for the extra white LED and expose some additional data pins for the data lines of the individually addressable LEDs.

To make the actual color experience even better I want to increase the resolution of the PWM used to dim the different colors from 8-bits to 16-bits.
That would allow for far smoother transitions as well as some leeway to add actual color correction without it looking choppy. If you want to learn more about that, check out this blog post by saikoled.

Check out my >sourcecode<

For my latest project, I wanted to use RGBW LEDs instead of just RGB ones.
As they have some interesting advantages over RGB that I wanted to explore:

• A more accurate representation of white
• A wider color spectrum

This only works with somewhat desaturated colors. But at the end of the post I have some ideas that might help to work around that.

This would allow for better lighting of surfaces as well as more natural-looking colors.

Why that is and how we get there is what I will try to explain below:

What is color exactly?

Light and color

Light or visible light to be precise is a form of electromagnetic radiation with a wavelength of 400-700 nanometers. Electromagnetic radiation means that the wave got a magnetic as well as an electric field which both oscillate at the same time. Such a wave is emitted when an electron transitions from a higher to a lower state of energy, releasing the difference in the form of a photon. The length of one of the wave segments is used to identify the waves corresponding wavelength.

What the wavelength got to do with spectral color

Relevant for us are the colors red, green and blue(RGB anyone?) that can be found at ~700 nm, ~530 nm, and ~470 nm respectively. At those wavelengths, they are considered (near-) spectral colors. That means that they are composed of only one wavelength or a relatively narrow band of wavelengths. Which means that they can be used to efficiently mix different colors.

Mixing colors

Additive mixing

When different waves of light intersect and bundle up before they reach the eye, they can be perceived as a different color that appears lighter than the colors used to mix it. A light source will appear as white if enough colors are added up that way.

And as an example for mixing, if you get a red and a green light to combine, the resulting light will appear yellow.

Subtractive mixing

This type of color mixing determines how an object looks in a specific light. The surface of an object is composed of one or many pigments. A pigment only reflects a specific wavelength and absorbs the rest. Mixing enough pigments will result in all light being absorbed, creating a black surface.

For example, a red surface illuminated by white light looks red because it absorbs all but the red light. But if you would use a blue light instead, the same surface would look black.

Wavelength spectra of RGB and white LEDs

Let's take a look at the emission graph above that shows what the possible spectrum of an RGB LED might look like.

Given a temperature of 25 °C, the x-axis describes the wavelength and therefore the perceived color of the light and the y-axis describes the actual intensity of that wavelength.
And as you can see, their actual colors are intense but have a quite narrow range of emitted colors with some gaps in between.

If we now look at the spectrum of a white LED, you can clearly see that there is a wider range of wavelengths.

To understand how this is archived we first need to understand what a Stokes shift is.
Quoting Wikipedia:

When a system (be it a molecule or atom) absorbs a photon, it gains energy and enters an excited state. One way for the system to relax is to emit a photon, thus losing its energy (another method would be the loss of energy as heat). When the emitted photon has less energy than the absorbed photon, this energy difference is the Stokes shift.

In the case of the white LED this means that some of the photons of the underlying blue LED are absorbed by the phosphor(or a similar substance) and are (re-)emitted with a longer wavelength, thereby broadening the spectrum.

Now we can discern the problems of mixing RGB in the light(heh) of additive and subtractive mixing:

• Additive mixing works quite well, just needs some proper balancing to account for the  capabilities of the different LEDs
• Subtractive mixing produces wrong colors because of missing wavelengths between the three color

But if we now add the white color into the mix we will be able to mitigate those problems at least for less saturated colors:

• By mixing on top of white we do not need to be concerned about having a perfect white to desaturate the color
• Using a white LED gives us a wider and natural spectrum, making our colors illuminate surfaces more natural

Mixing in the white

To grasp how to use the white while mixing you will have to understand that in RGB only two colors are actually needed to mix a pure hue, while the third color is used solely to control the saturation. Take a look at the following graphic:

If we have a lot of red and blue and we add a little bit of green the resulting color is only shifted towards the white point D65.

That means we can easily swap the color with the lowest value with white and get almost the same result. Let's take a look at some code for that:

// red = 200
// green = 150
// blue = 250
std::array<int, 3> rgb = {200, 150, 250};

// checking for the index of the smallest of the three values
// green is the smallest
// becomes index = 1
int index = std::min_element(color.begin(), color.end()) - color.begin();

// storing value for later
int value = rgb[index];

// setting green to 0
rgb[index] = 0;

// creating the RGBW output
// becomes rgbw = {200, 0, 250, 150}
str::array<int, 4> rgbw = {rgb[0], rgb[1], rgb[2], value};

As already explained in the code the green would become zero and the white 150, hopefully resulting in a slightly desaturated purple.

Adjusting the ratio

To compensate for the difference in luminosity between the colored LEDs and the white LED I don't just replace the color with white but allow a specific factor to be used.
In my case, the factor is adjustable at runtime using a simple interface and some buttons.

In actual code that could look something like this:

// some arbitrary factor between 0 and 1
float factor = 0.6;

std::array<int, 3> rgb = {200, 150, 250};
int index = std::min_element(color.begin(), color.end()) - color.begin();

// getting 60% of green
int value = rgb[index] * factor;

// setting green to 40% of itself
rgb[index] = rgb[index] * (1 - factor);

// creating the RGBW output
// becomes rgbw = {200, 60, 250, 90}
str::array<int, 4> rgbw = {rgb[0], rgb[1], rgb[2], value};

In this case, the white to green ratio(or pure white to barely white if you want) is 60% to 40% or 90:60 to use the actual numbers.

Conclusion

Using the white LED when mixing desaturated colors is fairly easy and can be achieved by just simply replacing all or some of the amount of white created by the third color with actual white.

The more desaturated the color is, the more are we able to reap the benefits of the wider color spectrum. The problem is, that on full saturations we have no white at all.
But I can think of at least two ways to increase the quality even in that case:

• Using more than three spectral colors(tetra-, pentachromatic LEDs)
• Always adding some tiny amount of white(and maybe increase the resolution from 8-bit(256 steps) to 16-bit(65536 steps))

And as I am already working on implementing the aforementioned 16-bit RGB resolution I might be able to try the last one out for myself.

I’ve had never really come into contact with embedded programming, working mostly in python or C#, until a friend of mine asked me for some help with programming a simple controller for RGB strips using Arduino Nanos.

We'd, of course, fail spectacularly.

Not only did our hardware not work quite like intended and a few Nanos died in the process(but that’s a story for another time), but I actually learned a lot from this and similar projects.

And I want to tell you some of my mistakes, what I learned by making them and how to prevent them.

Understanding pinouts

Let’s start with something that is a little bit hard to read if you don't know what you are doing: pinouts.

Let me show you how to use them by taking a look at the pinout above and help you to understand some of the more interesting types of pins there are and from which ones you should stay away.

Some additional stuff to look out for

First of all, and this is especially true for the esp32 and its variants, there are a lot of similar pinouts for nearly the same board.‌‌ Doing the extra step and verifying that you are using the right pinout is crucial.. unless you like the smell of burned electronics.

And while you're at it, try looking up the name of your actual board and research the pin definition of the platform/firmware you are using because it may contain some useful pieces of information about the pins included.‌‌

This is quite important as the pinout itself may not contain all the information needed to work with a specific board, for example the limitations some of the pins may have.
In my case, the pins I wanted to use were input only.. good luck trying to control a mosfet with those.

Types of pins and how to use them

Let's return to the topic at hand about what types of pins there are and when and how one should use them.

The most basic pins are digital pins, they can only either be on or off. You would, for example, use them to check if a button is pressed. Or if you use them as output, turning a led on or off.

But if you need finer control you have to use an analog pin. By utilizing a analog to digital converter(ADC) they are able to read analog signals. But their accuracy is somewhat limited by their resolution, the esp32, for example, is limited to 4096 different levels(12 bit).

And while those pins cannot output a true analog signal, they can use a technique called PWM to approximate one by only switching the signal on for some time.
Analog pins are usually used to get accurate data from sensors(a hall sensor for example) or to dim leds(rgb anyone?).

Then there are communication pins that allow the device to communicate. There are several interfaces to choose from, for example UART for direct communication, I2C for on-board internal communication and SPI and 1-Wire for inter device communication, just to name a few.

Beware of pins that are used by the device itself or are used to control the device, they may exhibit unexpected behavior(send signals in regular intervals or in an event for example) and using them could fry the chip.
This are, for example, the control pins as well as some of the pins described in the interlude above. Some of them are not as bad as others like sometimes lighting up the internal led is better than frying the on-board flash memory.

In the case of the esp32 there are also two more types of pins that are interesting for us, for one there are the touch pins which, as the name suggests, allow the board to detect human touch. But there are also two DACs(Digital to Analog Converter) that are able to output a true analog signal, which means instead of generating 1.65V on a 3.3V pin by turning it off half of the time, the pin has actually 1.65V.

Limited flexibility

While it is still easy to just switch out some part of the program with something new on the software side, its not always that easy for the hardware side. Not only do you have to potentially reassemble the whole device, but you also have to make sure it is really compatible and doesn’t do any damage.

With the availability of tools like easyeda and the possibility to use actual breadboards to plan, explore and test such options beforehand this is only a real problem if there has been no actual planning.‌‌And use PIOs build-in unit testing engine if you can, it allows running tests on your local host machine as well as the connected devices.

Which in turn allows you to catch a lot of bugs beforehand.

On that note, if you are not using PIO currently, you really should, it’s integration in Visual Studio Code and Atom makes it really easy to use. And you can extend it feely with VSC or Atom extensions.

Also,  if you split your build into parts as well and connect them using cables/sockets/etc. you can swap them out in the future(stepper motor drivers are a great example of this).

Consequences of mistakes

Speaking of doing real damage, when was the last time your software project caused your PC to start burning?

Never, unless you were working in C and put some pointers in some really unfortunate places while simultaneously convincing your os you are really allowed to do this.

Now let us take a look at the hardware side of things. ‌‌Using the wrong input for a pin? Using the wrong pin in general? ‌‌Switching a relay at the wrong time? Not switching a relay at the right time?‌‌Forgot that a specific component needs to be slowly shut down?

Does not sound great, does it? I for my part killed loads of components over the years and I know that I will kill loads of them in the future.

And while there's not always a good solution to prevent this, only can use careful planning and the addition of fuses in front of expensive and/or important parts to reduce the risk drastically.‌‌ And if you know that some parts are prone to breaking, give them some sockets and save yourself some soldering time.

Conclusion / TL;DR

There are a lot of things one can do wrong when approaching embedded programming from a pure software programming standpoint.

But here are the things that helped me not produce as much magic smoke as I used to:

• Read your specification
• Read the right specification
• Check connections thoroughly
• Plan your stuff
• Split your hardware into parts
• Don’t hardwire everything
• Prototype and test on breadboard
• Ever heard of fuses?

If you want to support me please use my Amazon affiliate link below:‌‌Link

Photo by Harrison Broadbent / Unsplash