Forum - Recent Threads

Light o'clock - Preface - OUTATIME

Anthocyanina — Thu, 22 Jan 2026 01:39:12 GMT

Oh, life, you and your ways...

When I saw the announcement for this challenge, I thought it would be the best opportuity to bring an old project idea to life, and so I wrote my application, and entered the selection process; when I was selected as one of the official applicants, I got really excited and started preparing for it, but I didn't expect a different challenge to present itself and take over everything!

Back in 2024 I experienced a sudden vision change, where halos started appearing around lights, even faint ones, and my photophobia, which was already annoying, became much worse. A visit to the doctor resulted in them sending me to the ER and me having an MRI brain scan done (which thankfully came out normal) and then being sent to all the eye exams. For most of 2025, as this was being studied, the exams came out normal, but then, around october I had an electroretinogram done, and that one didn't look good. With that, and being sent to genetic testing for vision related pathologies, and that some form of cone-rod distrophy became what they were (and still are) looking for, and what i could find about that was just no good, and everything became overwhelming, and working on a project centered around light felt icky at best, knowing i would be working on somehing i could possibly not enjoy, yeah, I removed myself completely from this, and basically put my life on pause while i dealt with all that.

My vision hasn't worsened, at least not significantly, since october 2024, and now, seeing things more calmly, and also, good news! genetic test came out negative for anything known related to vision pathologies, I think it's time to resume this project as well as to take on some others.

So! what is this project going to be about?

I have a really old computer keyboard which doesn't have backlit keys, so keyboarding in the dark is a bit cumbersome, especially when i need to use characters which aren't in my daily repertoire so they're also not in my muscle memory (also, darkness isn't great for dealing with typos), so I wanted to make a keyboard light. Another minor inconvenience I come across often is not having a visible clock all the time, and when I'm playing a full screen game, and for some reason I want to quickly know what time it is, alt-tabbing then hovering the cursor at the bottom of the screen to make the task bar come up to see the time isn't the most convenient thing, so I also wanted to make the keyboard light into a clock.

My idea is to make a binary clock (trade one minor inconvenience for another, isn't that the maker way?) with the keyboard light, which at the press of a button (maybe a mouse button so it's always there?) displays the time, and then goes back to its keyboard light duties after a short period.

How will it work?

To count to 24 in binary we need at least 5 bits, so that makes the number of light zones easy to figure out: 5. But, that would only allow for hour representation, there would be no granularity, so I thought to represent 5 minute intervals with color, so that needs 12 colors, 12 colors which have to be distinct enough from each other to quickly tell qhich 5 minute interval they are in. Let's get an idea of how it would work:

Let's say it's 17:45, so, 17 in binary is 10001:

and the 45? let's make it blue for now:

This example made me think of even more granularity, to be able to have a resolution of 1 minute by having the hour be solid white, the minute being color, but also blinking, and also using the 5 light areas to represent the minutes within the 12 chunks of 5 minutes that the different colors allow.

Let's consider 17:47 now:

The LSB is on the right, so we have 17 from the white lights, we see a blue light so we know we're in the 17:45 to 17:49 region, and we see the blue in the third light area, so we know it's 17:47. But how do we know there isn't a white light hiding under the blue one? The minute indicator will blink, so it will be on, like above, for one second, and off, like below, for another second:

Is reading this clock more complicated than alt-tabbing then hovering over the task bar? maybe. Is it more fun? definitely!

So, with no time left in the challenge's clock, posting this preamble is a way to motivate myself to continue working on this project, and keep you all updated!

Finisher Prize for Light Up Your Life Design Challenge

misaz — Tue, 13 Jan 2026 22:45:42 GMT

Hello Element14 Community,

Right before leaving to Christmas holidays, I receive my finisher prize for participating in Light Up Your Life Design Challenge sponsored by Würth Elektronik. Before digging into reward, let’s rewind what I did as part of challenge. I joined as non-sponsored challenger with intention to make device for automated analysis and testing of RGB LED strips. Most likely it was not the coolest contest entry, but I like it. As part of challenge, I dig into interesting topics like fault tolerant LEDs, described various types of interfaces, tried combine multiple types of LEDs on single chain, and so on. After all, I combined all these and made prototype of automated testing tool. For more details, you can read over forum and project posts which I wrote as part of challenge:

I did not win any of main prize. It was obvious considering very high quality of entries of others (and their fun and cool ideas, compared to my pretty boring helper technical tool). But participation still qualified me for at least finisher prize and this post is about it. Helping hands, magnifier and shrink tubes were offered as finisher prize, but because I all of these already have, I asked Element14 for replacement prize and they did their best to get it. So, instead, I’ve got brand new Arduino Uno Q which cost slightly less than originally offered kit.

Arduino Uno Q (2GB)

While you probably heard about it, let’s briefly explain it. It is new board from Arduino. On a single board it combines MPU running Linux with MCU running Zephyr. Main processor is no longer MCU clocked in range of MHz, but rather CPU clocked in range of GHz. The idea is not completely new concept, for example Latte Panda do the same on many of their x86 boards for years, but it is still quite unique on the market.

This combination allows completely new applications. While most people speak about AI, Machine Learning, Computer Vision etc, I would like to mention that it also allows many “conservative” applications like logging to hard drives, much better HMI displays with reasonably well working 3D GPU, full featured networking stack in Linux and many other while still somehow remaining most properties of Arduino.

But none of these was actually my motivation for getting it. My motivation was mainly opportunity to dive into Qualcomm platform. While the platform is very closed source similarly to Broadcom on Raspberry Pi, there is huge amount of “documentation” available online which come from long-term running reverse engineering efforts. Compared to Broadcom chips which originally designed for TV Set Top Boxes and similar, these Qualcomm chip targeted smart phones primarily, and obviously, there was much bigger demand on reverse engineering these. In fact, it is obvious for example from pinout. On pin header near power button there are two signals called Volume+ and Volume-. I think you have idea what device typically has these buttons. Despite acquisition of Arduino by Qualcomm is kind of shady, I think, community will enjoy hacking this device for several next years.

Power-up and first thought

You can use it as “normal” Arduino by connecting it to PC using USB cable, but this one you can use in Single Board Computer mode and you can use it as a standalone computer. For SBC mode, you need USB-C Hub. It may sound quite weird at the first look, but technically it does not restrict this Arduino to some predefined list of connectors which Arduino think that they should be enough for everybody. Instead, you can use any set of ports you need – you just buy hub which satisfy your requirements. If you need 2 USB you buy hub with 2 USB, if you need 5 USBs, you buy hub with 5 USBs, etc. While there are many options, for using it “as PC”, you need at least HDMI for display, PD for powering and at least one USB for mouse/keyboard. Especially, do not forget about powering, otherwise you will likely need to power it through pin headers.

Considering CPU is not flagship and there is quite low of memory, system is surprisingly fast and responsive. It is obviously not as seamless as my i7-9700K desktop, but compared to the older generations of Raspberry Pi with similar processors, it is quite good and I was very surprised. Software is quite optimized as well. It uses decent mix of Arduino modifications with otherwise standard Debian system. You can find modifications on Arduino Github.

While feeling is generally good, it has some limitations, for example, Chromium can very quickly trigger Out of Memory killer. 2GB is not much memory for Chromium. It is quite limiting when searching for documentation, forums, etc directly on device.

First Sketch

Considering it is reward for RGB LED Design Challenge organized by Würth Elektronik, first electronic part which I connected to this Arduino was RGB LEDs from Würth. Little bit challenging was that FastLED library is not ported to new Uno Q yet and fails to compile, but after design challenge I am experienced enough to quickly write my own driver. I did not want to bother with complex Arduino-Zephyr-STM32HAL environment, so I write my own driver for generating properly timed signal using STM32 timer. I controlled it manually controlled by directly writing and reading registers. It makes sketch quite long, bot work nicely.

https://youtu.be/KGyR_OAy9og

#include <Arduino.h>
#include <Arduino_RouterBridge.h>
#include <ArduinoGraphics.h>
#include <Arduino_LED_Matrix.h>

#define LEDS 4
uint32_t buff[LEDS * 3];

ArduinoLEDMatrix matrix;

void setup() {
  Monitor.begin();
  matrix.begin();
  for (int i = 0; i < LEDS * 3; i++) {
    buff[i] = 0x88888888;
  }
  pinMode(5, OUTPUT); // PA11
  float scaleR = 0.07;
  float scaleG = 0.01;
  float scaleB = 0.12;
  setLED(0, (uint8_t)(scaleR * 40), (uint8_t)(scaleG * 101), (uint8_t)(scaleB * 181));
  setLED(1, (uint8_t)(scaleR * 51), (uint8_t)(scaleG * 71), (uint8_t)(scaleB * 186));
  setLED(2, (uint8_t)(scaleR * 115), (uint8_t)(scaleG * 140), (uint8_t)(scaleB * 216));
  setLED(3, (uint8_t)(scaleR * 130), (uint8_t)(scaleG * 90), (uint8_t)(scaleB * 238));
  Monitor.println("Init done");
}

void loop() {
  delay(1000);
  showLEDs();

  matrix.beginDraw();
  matrix.stroke(0xFFFFFFFF);
  matrix.textScrollSpeed(50);
  matrix.textFont(Font_5x7);
  matrix.beginText(0, 1, 0xFFFFFF);
  matrix.println("   Thank you");
  matrix.endText(SCROLL_LEFT);
  matrix.endDraw();
}

void setLED(int index, uint8_t r, uint8_t g, uint8_t b) {
  if (index >= LEDS) {
    return;
  }

  uint32_t data[3] = { g, r, b };
  for (int i = 0; i < 3; i++) {
    uint32_t bitmask_rd = 0x80;
    uint32_t bitmask_wr = 0x60000000;
    
    while (bitmask_rd) {
      if (data[i] & bitmask_rd) {
        buff[index * 3 + i] |= bitmask_wr;
      } else {
        buff[index * 3 + i] &= ~bitmask_wr;
      }

      bitmask_rd >>= 1;
      bitmask_wr >>= 4;
    }
    
  }
}

void showLEDs() {
  noInterrupts();
  
  RCC->APB1ENR1 |= (1 << 4);
  TIM6->PSC = 14; // 13.3333 MHz
  TIM6->ARR = 3; // ie. 4 but STM32 need one more clock cycle to update
  TIM6->CNT = 0;
  TIM6->CR1 = 1;

  for (int i = 0; i < LEDS * 3; i++) {
    uint32_t bitmask = 0x80000000;
    while (bitmask) {
      uint32_t bssr;
      if (buff[i] & bitmask) {
        bssr = (1 << 11);
      } else {
        bssr = (1 << (16 + 11));
      }

      while ((TIM6->SR & 1) == 0) {}
      TIM6->SR = 0;
      GPIOA->BSRR = bssr;

      bitmask >>= 1;
    }
  }
  
  TIM6->CR1 = 0;
  interrupts();
}

Bonus: USB Type-C Hub Disassembly

I bought cheapest USB Type-C hub which satisfy my requirements: PD, 1xHDMI, 1xUSB 3.0, >=2xUSB 2.0. There is quite a lot of hubs with these parameters, so I chose one which supports 4K@60Hz display output on HDMI, and it was surprisingly one of the cheapest while there are many more expensive supporting only 30Hz display at 4K resolution. (I am in Czech Republic, in your country, offering likely differs)

But buying cheapest sometimes is not the best idea. While hub satisfy everything I need, it broke when plugging HDMI cable for first time. Mechanical design is not good. I basically pushed cable into it, but I pushed whole PCB including USB cable from the back side of case. While it is easy to fix, I took that opportunity, pulled it out completely first and took a look to PCB before fixing it:

It is quite smart design, I thought there would be single SOC which will handle everything, but this has several chips for various purpose. After observing differential pairs, I think it is connected in this way:

Such diagram nicely shows possible bottlenecks of the devices but unluckily nowadays sellers typically show beautiful photos and visualization instead of technical description. I like that important signals and paths (USB 3.0) and PD (claimed as “up to 100W”) are almost direct paths and there are no possibly bugy or limiting chips on their paths. While I like it from electronics design point of view, mechanically it is disaster.

Closing

At the end I would like to say thank you to Würth Elektronik for sponsoring challenge and Element14 for organising it. I would like to thank all who spend time by reading contest forum posts. For me it was nice opportunity to test various Würth LEDs and play with them. They were on my wish list for long time and this challenge was perfect opportunity to buy them and play with them.

Finally, I would like to mention that if you are interested in getting free Arduino Uno Q which I briefly described in this article, there is still open RoadTest (at the time of writing this post) where you can get one for free. If you join and get selected, you get one free Arduino Uno Q for review.

Runners-up price for Light Up Your Life arrived

embeddedguy — Thu, 11 Dec 2025 08:34:50 GMT

Hello,

I am happy to share that today morning I received the parcel with Element14 stickers, and I realized that it is the runners up price for the Light Up Your Life design challenge.

It was indeed a real surprise to me as there was no tracking or idea that it is going to arrive this soon. I am happy that it arrived before holidays are going to begin so that I can use it for my holiday and post full reviews.

But here is first glimpse. Glad to share as I am the first one to receive it as it seems.

RGB MATRIX 3D printing parts arrive

embeddedguy — Mon, 01 Dec 2025 14:23:02 GMT

It was a quite interesting to take part in Light Up Your Life challenge and now the deadline for project submission is over I am still doing something that I did not have time to do during the challenge.

First thing I thought that I am really missing an enclosure for the device. So, I have created a 3D printing object and sent it to robu.in.

For the design I used open source tinkercad.io.

Today, I received the 3D printed enclosure. Here are some photos.

I am still waiting for the missing LEDs to arrive and thanks to Arvind SA for sending me these LEDs.

{gallery}My Gallery Title
IMAGE TITLE: 3D enclosure with transparent top

IMAGE TITLE: THEN IMAGE DESCRIPTION
IMAGE TITLE: THEN IMAGE DESCRIPTION
IMAGE TITLE: THEN IMAGE DESCRIPTION
IMAGE TITLE: THEN IMAGE DESCRIPTION

{gallery}My Gallery Title

IMAGE TITLE: 3D enclosure with transparent top

IMAGE TITLE: THEN IMAGE DESCRIPTION

Couldn't continue with my project due to health issues

sunnyiut — Wed, 19 Nov 2025 11:05:09 GMT

Hello everyone,

I am sorry to inform you all that I have been suffering from sciatica pain for the last one month. It was due to a disc bulge at lower back. I was in complete bed rest for three weeks, after that I started physiotherapy in limited manner. Unfortunately I developed dropped foot condition which is a neurological deficit and surgery is the only option. I was supposed to have the surgery after 21st November. However, observing my improvement (a very little though) doctor suggested to wait for a couple of weeks to decide whether I need to go for surgery or not. Therefore, I was totally out of the design challenge.

I am sorry. However, I wish you would consider that and I would love to carry on my project again once I get better. Though I couldn't follow others' projects, I would like to congratulate everyone for participating here. Please pray for me.

AuraAlert - Part 6 - Improvement Discussion (Post Deadline)

arvindsa — Wed, 19 Nov 2025 04:07:22 GMT

Hey, I wanted to share couple of more information regarding my project. I am posting this post the deadline FYI.

Fixing the Boost Converter Noise

In my Part 4 - Post I mentioned that i made a mistake while laying out the PCB and i did not go as per the TI's Recommended Guidelines due to which the following issues happened

The Power supply was noisy with a Vpp of 320mV
There was a audible hum, an irritating one emanating from the circuit

So in my Final PCB i corrected it

Here is the before

This is the after

You should be able to note

Only Ground has planes both on Top and bottom stitched by Vias. And it is PWR GND Net not The regular GND
I did add a Low ESR Electrolytic capacitor
No Pours under inductor and switching element
PWR GND, AGND (For feedback Resistors) and GND are joined at a single Star Point. Star point is a single point where the PGND and GND is connected. It is achieved using NET Tie symbol in KiCAD. This reduces the noise in the main circuit and internet says it keeps the return path of the switching element isolated in the PGND net itself. The Pout of PGND and GND are not joined anywhere. They are two different Nets. (Look around the rectangular silk screen)

The ripples came down to 105mV measured as Vpp (Peak to Peak) without the electrolytic capacitor and 60mV measured as Vpp (Peak to Peak) with the electrolytic capacitor of 680uF. and The audible hum was gone

Improving the Light Throughput

The LED Is projecting the light on to a white surface which i use as a diffuser, but then some percentage of light reflects off the walls of it and makes it back to the PCB where it gets partially absorbed. So i added some reflective coating. That improved the uniformity of the light even more, Sadly it is only visible for the naked eye and my phone is not able to capture the difference

Sounds Recording

I started recording sound events for Edge impulse Training. I am collecting Washing machine, Pressure Cooker, microwave, fire alarm, door knock, door bell and baby crying. I put it in a share drive and asking Friends and Family to contribute. My Target is 50 per sound. if anyone is interested in contributing do DM me.

Do Comment, I hope i have not made my posts boring.

RGB Flashlight: Final Project Summary & Future Plans

CADi_Master — Sun, 16 Nov 2025 21:57:14 GMT

I'd like to wrap up my blog entries for this contest on a hopeful note. While I acknowledge I didn't do great with soldering the LEDs and that prevented better progress on the project, along the way I've learned a lot about how RGB LEDs work and their potential applications. I'm looking forward to catching up on reading about all the other projects! I should have spent more time practicing the soldering instead of assuming my prior experience would get me through it.

Thanks to Element 14 and Würth Elektronik for providing the components to use. Everything works fine, I just need more soldering practice before I can realistically move much further except on paper. That said, I have some cool ideas on paper for how to move forward with this project :)

At first I just wanted an RGB flashlight that could do any color (essentially a light box but more portable). But along the way I started wondering about how it might be useful as a colorblindness / color vision deficiency (CVD) assistance device. The RGB LEDs we were sent for the contest are great on their own but I've been wondering if combining them with a few other elements might enable some degree of improved color discernment for users with CVD. In short, this would sort of be like a light bulb version of those Enchroma glasses (see here: https://enchroma.com/pages/how-enchroma-glasses-work)

^ Visible light spectrum with square wave valleys at problematic CVD wavelengths (from Enchroma glasses website)

I'd like to try combining a set of 6 or 7 narrow-band LEDs with various subtractive elements such as gel filters or painted tubes that absorb problematic wavelengths. In theory this could produce output light that has more peaks & valleys of brightness than normal RGB light. While this would sacrifice some color rendering index (CRI), it would have more internal brightness contrast between some colors and their immediate neighbors. The output light spectrum could sort of resemble a comb with many peaks & valleys instead of only 3 from standard RGB. If the LEDs and subtractive elements are carefully chosen and controllable through physical design and software via the Arduino, it could be a handy lamp / work light that can dynamically swap between lighting profiles to improve color discernment for various types of CVD as needed, such as for those with red-green colorblindness vs. yellow-blue.

To be clear, this design would not in any way enable colorblind users to see new colors, but it (theoretically) should create enough brightness contrast changes in whatever wavelengths are desired that some previously indistinguishable colors could go brighter or darker and thus become distinguishable. If this was a work lamp or desk lamp, maybe it could be handy for electronics to see differences in resistor colors better. Or it might have some artistic applications. Who knows!

That's the direction I want to take this project over the coming months. I'll elaborate on theory of how it will work in later posts. Not sure whether to continue posting about this in this forum or somewhere else after the contest ends, but I'll figure that out later.

I wouldn't call my Light Up Your Life project a great success, but it led to a lot of great learning opportunities, some of which I wasn't expecting at all when the contest started. I'm going to continue learning electronics and optics design, and see how far I can take this project. I have no idea how well it'll actually work, but I'm looking forward to finding out.

Thanks for reading, and thanks again to E14 and Würth for supporting contests like these!

RGB Flashlight #03: Soldering Woes

CADi_Master — Sun, 16 Nov 2025 20:56:30 GMT

Soldering... didn't go great for me. It's not the fault of the LEDs, I'm just not very experienced with components this small. I'll keep trying past the scope of this contest but for now I'll invite you to mock my attempts! Boxes of rotten tomatoes will be distributed shortly.

I'd like to thank Gough Lui for sharing an excellent video on soldering techniques for this kit! Check it out if you haven't already: https://www.youtube.com/watch?v=33HIijhpB6g&list=PLrY3-lLxuZfWh8_cyZcIyZ4jRthiEd6oG&index=14

My lack of working results is my own fault rather than not having a good example to follow. Just had a hard time getting the PCBs to stay steady enough as I was working. I think I really need a new work clamp to use. Looking forward to using the magnifying glass thing from the finisher prize.

Trusty Weller brand solder 0.5mm worked the best overall. 0.3mm was too finicky for me. Not that it made much difference in the final results though.

I've seen cleaner joints in footage of Chernobyl.

Second batch went better than the first, but not by much.

Forgive me, Element 14, for I have sinned...

Here lies LED #13, who rode a cloud of magic smoke across the RGB bridge on 11/02/2025. He was only one PWM cycle away from retirement.

Tried all the LEDs I managed to get fully soldered up with the Arduino and breadboard, but didn't get any light output from it. Need to spend more time practicing really. The Arduino Zero works fine with some other sample code so it doesn't seem to be anything faulty. Either my solder joints aren't sound, or I'm just frying the LEDs without realizing it. Neither would surprise me. Time will tell, but that's as far as I could get by today. My final project post will summarize the future direction I'd like to try taking this project before I commit too much time to trying to get the breadboard prototype working. Should be done later today.

tl;dr I am bad at soldering but want to get better. Happy to hear any advice.

Desk LED Towers - The Demo - RGB for RadiantGoofyBulbs

navadeepganeshu — Sun, 16 Nov 2025 18:35:31 GMT

After builds and iterations for a while now, through this blog, I'd like to display a demo of the project RadiantGoofyBulbs - custom LED bars built to use with displays or generally as ambient lights using Wurth 1315050930246 and 1315050930002 parts.

The setup includes two pairs of LED towers, each built with 12 LEDs of each parts and the control unit with ESP8266 NodeMCU board. The system is powered through 5V/3A USB via a generic wall adapter.

The test codes used during the intermediate steps of build are linked here https://github.com/ngu25/LightUpLife-Element-14. Thank you very much for reading through and following this project in the build journey. Happy to hear your feedback and ideas. Cheers :)

RGB Flashlight #02: Arduino integration attempt / misc planning

CADi_Master — Sun, 16 Nov 2025 18:32:44 GMT

Last time I settled on using Würth Elektronik LED #1315050930002 for my prototype flashlight since it had the best balance of easy soldering and brightness output. Unfortunately I still had some trouble getting the soldering down. Overall my progress for this contest was more on paper than on PCB. But thankfully the paper progress led to a cool new project idea, which I'll describe in my summary post at the end.

The complexity of my project lies more in the physical design and software control of the LEDs than advanced use cases of the LEDs themselves. If each of the 1315050930002 LEDs can output roughly 1 candela of light, there will be limited useful range for this as a flashlight. Thinking about it as more of a desk lamp now. But that's fine!

I'd like for my light to be able to store specific lighting color profiles to switch between at the press of a button rather than just using dials or something for inexact values. Luckily the LED itself (DIN → internal controller → actual colors) does most of the heavy lifting. The challenge is figuring out:

How should the human user tell the light what to do?
How can the Arduino interpret those human decisions?
And what “modes” make sense for a small handheld RGB flashlight or desk lamp?

Thus began my journey into control architecture.

Würth Elektronik LED #1315050930002 is basically a tiny NeoPixel/WS2812-style smart pixel with 4 pins (VDD, VSS, DIN, DOUT).

1 - VSS: Ground pin, will connect to Arduino Zero pin GND.

2 - DIN: Data In. Will connect to Pin ~6 on Arduino (PWM).

3 - VDD: Power supply. +5V pin on Arduino.

4 - DOUT: Data out. Would go to the next LED in series (I think) but I'm starting with only one LED for now.

This is about all I'd need (save for the memory card, power input, and the optional capacitor). My soldering skills are unfortunately not up to par, so I wasn't able to actually get this working even with sample code from Arduino.

I found in interesting learning about all the different pins on the Arduino, and the differences between PWM and SPI. The Neopixel library by Adafruit has all kinds of great tools built for controlling these LEDs. I wish I had gotten the physical construction down better in time. I'll keep progressing with this though. I tried running this sample code but didn't get any output from the LED: https://github.com/adafruit/Adafruit_NeoPixel/blob/master/examples/simple/simple.ino.

Regarding the controls for the device, I'll need more time to test options. Not sure whether dials are better than buttons for what I need. Ideally I'd also like a way for users to calibrate their profiles to their particular vision needs. More planning needed! I've seen plenty of RGB flashlights on the market but they all just let you use a single LED at a time. I want something more robust.

To any readers: What features would you like in an RGB flashlight or desk lamp?

I'll document my soldering attempts more in my next post. I shall prepare now for my public shaming.

AuraAlert - Part 5 - Final PCB Design

arvindsa — Sun, 16 Nov 2025 15:28:50 GMT

With things i learnt from my mistakes and experimentation of test pcb documented here i ventured into designing the 3 pcbs needed to complete the project. I started feeling if i bit more than i could chew, but commitment is a commitment, lets get it done

Tile-able Wall Hex mounted Design

This device can be daisy-chained for grabbing attention in large halls or rooms etc. I got the inspiration from Nano Leaf product. The components are exactly as in the test pcb except for the PCB. I decided to put the LEDs on one side and the rest of the components on the other. I wanted to arrange the LED's in a way to light up the acrylic and diffuser sheet evenly at-least everywhere except the edges. So Math comes to my rescue. Let us say the gap between two LED is "s" and the distance between the LED and the plane where the diffuser sheet will be is "d", With a FOV of 120degree, a bit of trigonometry will tell me that it should be s=3.46*d. But at 120 degree edge, the intensity is going to be only 50% therefore i should reduce the distance s to make it even. i've opted for s=1.15d. This is an empirical formula from experimentation. So I proceeded with s=30mm. I also added 3 Pin connector on each side of the hexagonal PCB so that it can be tiled using wires.

Based on this i designed a two piece casing. I used white PLA for the casing, and 3mm acrylic sheet with diffusion sheet pasted on top as the front part.

Wall Mounted Halo Design

The largest PCB with LED around the edges to create a halo effect turned out to be a challenge to place my wireless components, ESP32-S3 and NRF24. Usually i place it on the edge as far as away from each other, but in this case, the LED's come in the way, so i had to innovate. Perusing the best practices for wireless modules, i made a cutout and a no-copper zone atleast 20mm around the antenna. The placement almost every component was on the same side. Then i found, i couldnt put the USB port exactly on the bottom. I had only the Through hole version and since the LED was on top, i had to offset the USB-C towards the side. I hope it won't trigger anyone.

The casing was also extensive for this.I tried to keep it simple but I thought that if the LED's light is not channeled towards the halo then it is gonna be losing intensity. so, i 3D printed white cylinders which will help bounce back some of the light towards the halo ring. Rest of the case i wanted to be in Black to achieve maximum contrast. The Laser cut acrylic sheet was quite fragile and i had to be extra careful, as I had to work with minimum materials available on hand and i couldn't to afford (in time) to make extras. I managed to install it without any difficulty and it turned out quite nice and robust once the super glue dried. The buttons took me few iterations to get the smoothness right.

Hand Held Device PCB

This had to be as small as possible, I thought of a while to use a 4 Layer board board, but decided against it as time was running short. One thing that bugged me is that the Buck booster's TPS6123 required me to have a large space for the Power Ground and the inductors. Squeezing them as efficiently as possible in the wall mounted devices required at-least 22mmx12mm of space, not to mention that the inductor was quite high, So i dived into element14, to choose the smallest yet cheapest buck booster and i settled on Renesas ISL9113ER7Z-T which was only half a dollar and with this i was able to get the size down to 8mmx7mm. Soldering this was also a breeze. I also went for Wurth's Side Tactile switch WS-TASU for the switch. For the NRF24, i did not want to put my own Antenna, again just to save time, so i got myself an SMD version of the NRF24 Module. I arranged the sideways Wurth's LED 1313210530000 (12 nos) on the bottom layer in a ring fashion 1312121320437and the three 1312121320437 on top, considering the FOV for as much as uniform lighting as possible. I even opted for TXS0104E instead of TXS0108E to save space. It has only 4 channels instead of 8.

Unlike the previous devices, low power is one of the thing i was looking for and so it is STM32L051 as the main CPU here along with DRV2605L for haptics control along with a 128x32 pixel monochromatic OLED Panel.

The casing was designed as a 3 part design. One cut from transparent acrylic as a light pipe for the light strip, and rest made from White PLA.

4th PCB - Hand held device charger

Again, to squeeze more space, i opted not to use the USB-C and bought two pin pogo pin connector.I designed the PCB in such a way that i can use one copy of PCB as desktop dock connected to USB-C and i can use another copy, break it at the neck as a daughter board with the mating pogo pin to be connected to the hand-held device via JST-SHR series connector. You won't believe it that i had the connectors lying around in some box which i have not touched for around 8 years.

PCB Manufacturing

I had very less time to get this manufactured and this is where things got fun deciding whom to go with. My Fav PCB way is in China, i have couple of local manufacturers. I opted for PCBWay mainly because they get it manufactured within 18:00(UTC+7:30) on day 1 if i submit the order by 08:00 on day 0. Then only factor was Fedex and Customs, again something I've experienced it well in the past. in Total, 2 days for mfg and 6 for shipping and custom's I've got it in my hand. This time while ordered, i noticed a new option, not sure if was there before, but there is an option where you can opt-in for free upgrade to ENIG Finish. It is not guaranteed but I wish i had it got it.

TXS0108E Issues

This I've noticed in the Test PCB that twice i popped the magic smoke of TXS0108E. I spent almost half a day and it turned out that the Enable PIN when low keeps the pin in High Impedance state and should be enabled only if the high side VCC power is stabilized if not then it can damage the chip. So for all the three PCB's i had to connect a microcontroller pin to turn it on/off. In the hand held device, i forgot to attach it to a micro-controller and so I had to adjust it with a jumper wire. Has anyone faced TXS0108E issue?

Soldering

The Soldering of Hex PCB was easy, as this part has the largest LED with the minimum number of pins.

Halo PCB Soldering was hard as it couldn't be accommodated in any of the PCB holder i or my university had. My decision to have every component one side turned out to be good one after all. When i tried assembling it i realized i forgot to put an hole for the USB-C port. Oh well, fixed it by some flush cutters.

The soldering of hand held device took time as i had to omit all component reference silkscreen to cram it all into a small PCB but it was fun working on such closely spaced components. I felt so happy that i had invested in these Precision Straight Tweezers - Rhino SW-11 from adafruit in the past . One thing i have to let you know, it is not immune from bending from dropping as adafruit claims in the videos.

https://youtu.be/cVwvmbtG7Zg

Testing the PCB's

I decided only to test the Microelectronic, Boost converter, Battery charging, LED control along with level translator. Only a video can give proper justice to the result

https://youtu.be/tJC0WC0ZbTI

Now off to the project

Build Continues with Mechanicals and Integration - RGB for RadiantGoofyBulbs

navadeepganeshu — Sun, 16 Nov 2025 07:21:09 GMT

After testing the LEDs initially and pivoting on the Prismatic tool for display colour extraction and encoding LEDs, the custom LED bar is soldered and tested with the control unit discussed here Building Custom LED Bar and Control Unit - RGB for RadiantGoofyBulbs . Now is the time to do final integration by bringing together mechanicals (cutting, filing, spray paints). End of the blog, we'll see a short demo of how it all work in sync.

This blog gives a little extra attention to the aesthetics with the objective of creating diffuser bars with good light distribution and mechanical stability.

Materials and Tools Used

Aluminum LED Diffuser Bars (standard off the shelf, cut into custom size)
1. Type 1: 35mm × 35mm profile
2. Type 2: 25mm × 12mm profile
Light Diffuser Covers
Black Spray Paint
MDF Board, cut to pieces of custom size
JST Connectors and Wires
Cutting Tools + Sandpaper + Measuring scale
Standoffs and Screws for Mounting

Step1: Cutting Bars to required size

Chopped bars into uniform lengths for the project design
Ensured smooth edges using sanding
Goal: 20cm height for each bar - 4 total bars (2 of each type)

Step2: Painting the Bars

Bars bought from Amazon came with chrome finish and to match the overall aesthetics, it is spray painted
Painted matte black for and sleek modern look and reduced unwanted reflections
Allowed proper drying before next steps

Step 3: Creating Stands/bottom plates Using MDF

Designed simple wooden bottom plates to hold smaller pair of bars upright
Precise spacing to later mount LED strips inside
Mounted a JST connector on the stand base for easy plug-in to the Control Unit

Step 4: Cable Assembly

Made 2 pairs of wires for powering each LED bar pair
Total cables created are 4 with 4-pin, 2.54mm JST to JST socket ends
Clean modular design to connect LED bars to the Control Unit

7. Final Assembly and Dry Fit Check

Inserted LED strips (from previous blog) inside diffuser bar channels
Positioned stands and checked stability and spacing
Confirmed cable reach and connector fit

That's all about assembly and integration. Here's a short demo video 🙂

community.element14.com/.../sneekpeek_5F00_full_5F00_rgb.mp4

Misaz’s WL-ICLED experiments: Counting LEDs on bus

misaz — Sun, 16 Nov 2025 00:19:03 GMT

Hello. I welcome you to my last experiment before I publish final project. In this forum post I want to explain how you can determine LED strip length without knowing it’s length in advance.

Idea on this is not my own. I first time read about it here: A Nifty Tool For Counting Neopixels

It works in a way that you measured power consumption of LED strip. You hold most LEDs off except one. Idea is that you enable one LED at a time and test if power consumption grows or not.

For demonstration let’s consider 10^th LED to be the selected one. You send bright white colour to 10^th LED while remain others off. Then you measure power consumption of whole strip and compare it to idle state (all LEDs off). If it grows, it obviously must be caused by 10^th LED present in chain and now emitting light with cause increase of power consumption. Now you know that strip is at least 10 LEDs long. If power consumption does not grow, there is no 10^th LED on LED and you know your strip is shorter than 10 LEDs. Depending on this observation you try it again with higher or smaller LED index and sooner or later you find boundary when turning LED on increases power consumption while one LED later it does not. This is the length of LED strip.

It is more complex in strip with BI pin where you may hit possibly broken LED in the middle of chain. I will take this into account in final project, but for simplicity, I will omit it this time.

For measuring current, I used MAX40080 Click Board. It is the same Current Sense Amplifier which I used in Experimenting with Current Sense Amplifier back in 2022. If you are interesting for more detail details about it, you can follow my long series of blog posts which I wrote at that time. For my current experiments with LEDs, I ported my library to PSoC6 which I used for all experiments as far. I wrote slightly more robust error recovery, because I was hitting quite a lot of I2C errors.

Firmware is written in a way, that it measures idle current first. Then it compares to it. It is because of compensating quiescent current which flows even when all LEDs are off. I implemented slightly more efficient algorithm than was used in referred article. I do not go linearly over LEDs, instead I go over powers of two which allows me to find end of LED strip in O(log(n)) time instead of O(n). After finding end, using binary search, I find the exact boundary. Binary search is also O(log(n)) complexity.

For experimenting I did not implement super sophisticated output. After strip length is known, I print its value in binary using first LED on “input” chain. Red means binary zero, Green means binary one. On video bellow, you can see that my first testing strip has 4 LEDs and device blink RRRRRRGRR (R means Red or 0, G means Green or 1) which when converted back to decimal is 4. Then I tried with longer strip of WS2812 (not a Würth LEDs this time) and device determined strip as RRRRGRRRR, which is 16 and it is correct. This strip has 16 LEDs.

https://youtu.be/OKF3Wqe2SiM

Next steps

Now I need to just complete my proposed project: tool for diagnosing strip. I want to implement automatic strip detection, not only length but also types of LEDs. Support strips with broken 48-bit LEDs and identify them. Technically it should be mostly combination of experiments which I already wrote about. I already started working on it and have good progress. Need to finish it and write blog post about it before deadline. Hope you enjoy reading this blog and find method to automatically determine strip length at least somehow interesting. See you in next blog post.

Link to final project post: RGB LED Strip Diagnostics Tool

RGB Flashlight #01: The Actual Unboxening (or: Welcome To The Diode-dome)

CADi_Master — Sat, 15 Nov 2025 23:14:10 GMT

~ Intro ~

Welcome to another edition of Diode-dome!

Which LED will prove their worth (or should that be their Würth?) to become Champion of the Breadboard Realm?

Six LEDs enter, one LED leaves!

1. Kit review & selection criteria

I wanted to spend some time reviewing the contest LEDs and how I chose which one to use for my prototype flashlight. I'm not very experienced with soldering, especially not with very small components like some of these LEDs, so at least for the scope of the contest I had to prioritize how easily I would be able to solder these. All the LEDs provided for the contest are great quality and I'm looking forward to using them on future projects. I've been happy with the other provided components as well like the breadboard and power supply and level translator, but they're also a little more straightforward so I don't have as much to say about them for the moment. Will talk about the Arduino Zero in another post too.

Here are the criteria I considered for the LEDs:

Number of pins: An LED with fewer pins should be a bit easier to solder.
Footprint (mm ^2): A larger footprint gives more spacing between the pins and should be easier to solder.
5050 PCB compatible: Prefer using these options since they're intended for breadboards and rapid prototyping.
Viewing angle: A wider viewing angle (>= 120 degrees) is preferred for my flashlight to get better color uniformity.
Lens color: Diffused preferred over waterclear for better uniformity.
Luminous intensity (mcd): The brighter the better unless it introduces heat dissipation problems.

I was going to make a quantified decision matrix for this determination, but as you'll see it became clear which LED is best for my project without going into much further detail.

2. Würth Elektronik 1315050930002

One of the 5050 PCB-size LEDs, which is a big plus. Also has 4 pins instead of 6, so soldering is a bit easier. Nice and bright output, much more than just a basic indicator LED. Diffuse plastic lens color and viewing angle 120 degrees. All signs point to this being a great option for what I need.

3. Würth Elektronik 1313210530000

I love the physical design of this one with the bubble dome lens. That said, anyone who can solder this correctly on their first try is a wizard and not to be trusted. 4 pins is nice but the footprint is so tiny I just wasn't able to get this to work without bridging when I tried. Will try again after I've had more practice and prototyping time.

4. Würth Elektronik 1312020030000

Just simply too small for what I can realistically solder right now. And the brightness level is lower than what I was hoping to use for illumination.

5. Würth Elektronik 1312121320437

Surprisingly bright output, but still awfully small footprint and 6 pins instead of 4. Props to Würth for getting such good output from such a small component.

6. Würth Elektronik 1315050930246

The only other 5050 PCB-size option. It's brighter than the first which is great for a flashlight, but also has 6 pins each instead of 4, so soldering would be more difficult. I would say this is a close second place.

7. Würth Elektronik 1311610030140

Just too small and dim for what I need for this project, but might be my preferred option for a denser multi-LED bulb later.

8. Final Selection

LED #	# Pins	5050 Compatible?	Footprint (mm^2)	Viewing angle (deg)	Lens color	Luminous intensity Red (mcd)	Luminous intensity Green (mcd)	Luminous intensity Blue (mcd)
1315050930002	4	Yes	27	120	Diffused	450	1300	260
1313210530000	4	No	3.2	120	Waterclear	80	120	50
1312020030000	4	No	4	120	Waterclear	80	120	50
1312121320437	6	No	4.8	110	Diffused	600	1000	240
1315050930246	6	Yes	26.8	120	Waterclear	800	1800	400
1311610030140	6	No	2.6	120	Waterclear	80	120	50

After reviewing the LEDs for these criteria, I settled on using the #1315050930002 LED for my project. It's 5050 PCB-compatible, and has fewer pins than the other similar size one (#1315050930246) so soldering should be a bit easier. Also I like that it has a diffused lens color, which hopefully will give a more uniform output color for my flashlight. It's less bright than the other 5050 one but I'm willing to accept a lower output for a breadboard-level design.

I'm going to try to get my remaining blog posts done before the deadline tomorrow. Been making some fun progress with learning needed for the kit, but life got in the way of productivity. Next posts will include soldering woes, general Arduino noob learning, and physical design options.

~ Epilogue ~

The champion has been crowned! All hail Gladiator #1315050930002!

Note: The funny 'LED arena' renderings in this post were made with ChatGPT.

Single LED test (#2)

ZephyrusBlaze — Sat, 15 Nov 2025 16:31:04 GMT

Single LED test: color cycle update

Hey everyone, I finished the first tiny milestone with the sponsored kit and wanted to share how it went. I tested one 5050 breakout LED to make sure the board and the code talk to each other, and it worked way better than I expected. Feels nice to see a pixel light up after all the waiting.

Quick setup I used

I soldered one LED onto a breakout and wired it up to the Arduino Zero. For the test I powered the LED from 5 V, tied grounds together, and used a single data pin from the Zero. The LED cycled through red, green, and blue so I could confirm colors and timing.

Wiring summary: VDD to 5 V, VSS to GND, DIN to Arduino pin 6, DOUT left unconnected.

Code I used

#include <Adafruit_NeoPixel.h>

Adafruit_NeoPixel strip(1, 6, NEO_GRB + NEO_KHZ800);

void setup() {
  strip.begin();
  strip.show();
}

void loop() {
  strip.setPixelColor(0, strip.Color(255,0,0));
  strip.show();
  delay(500);
  strip.setPixelColor(0, strip.Color(0,255,0));
  strip.show();
  delay(500);
  strip.setPixelColor(0, strip.Color(0,0,255));
  strip.show();
  delay(500);
}

What happened

The LED came alive exactly like in the code: red, then green, then blue, repeating. I recorded a short video so you can see the colors and the timing. There was a tiny flicker the first time I powered it because my wiring was loose, but reseating the jumper fixed it. Overall it was a quick win and a good confidence booster.

Video

community.element14.com/.../20251114_5F00_163809-1.mp4

Next steps and plans

Solder a column of 5 breakouts and test chaining DOUT to DIN.
Compare one clocked LED column against a non-clocked column to see timing differences and more stable updates.
Work out power distribution for the full 10x5 grid so I do not get brownouts.

I will post another update after the 5-LED chain test with pictures and another clip.

Misaz’s WL-ICLED experiments: Combining LEDs of multiple types

misaz — Sat, 15 Nov 2025 13:13:34 GMT

Hello. I welcome you to forum post describing my next experiment with Würth Elektronik WL-ICLEDs. In this forum post I will look at opportunity to combine 24-bit and 48-bit LEDs on single chain. It can be quite useful if you work on project which has several types of LED like some LED matrix and diagnostic LEDs. In such project it makes sense to make LED matrix from more advanced 48-bit LEDs (Würth number 1312121320437) while diagnostics RGB LEDs can be just simple classic 24-bit LEDs (Würth number 1315050930002). Normally you would need to control two buses, but if you read datasheets carefully, you notice that timing of the signal is almost the same. Just amount of data transferred per LED and data encoding differs. For classic LEDs (like 1315050930002), the timing requirements for signalling are:

For 48-bit LEDs like 1312121320437, signalling requirements are:

They use different unit, so it may look confusing at the first look, but actually times are very similar. Actually, it is not possible to find any single value, which satisfies all minimum and maximum when implementing using SPI peripheral. But class 24-bit LEDs are much more tolerant. I stick to following typical values for 48-bit LEDs and slightly violate 24-bit signalling because they are more tolerant. In practice, it works.

I experimentally tested it by simple “snake”. It works. Let’s see:

www.youtube.com/watch

On video above, I have two PCBs with different LEDs. Left one is PCB with 48-bit LEDs. Right, one is PCB with 24-bit LEDs. On my PCB for 48-bit LEDs I exposed DOUT signal from last LED. This I interconnected on breadboard to DIN of next PCB. It does not need to be in this order necessarily, but on my older PCB for classic LED I did not expose DOUT from last LED. You can also switch between types of LED as many times as you want. You will just need write them in firmware properly.

Little bit more complicated it is on firmware side. But since I make my own library, it is manageable. If you remember my second forum post Testing BI pin, I designed my library in a way that I have following functions:

void LEDS_Init();
void LEDS_SetLed24(size_t index, uint8_t r, uint8_t g, uint8_t b);
void LEDS_SetLed48(size_t index, uint8_t rI, uint16_t rPWM, uint8_t gI, uint16_t gPWM, uint8_t bI, uint16_t bPWM);
void LEDS_Transmit();

Important part is to properly maintain indexing and take in account that every 48-bit takes 2 slots in internal buffer. Firmware for moving green on video look as follows:

int main(void) {
    cy_rslt_t result;

    result = cybsp_init();
    CY_ASSERT(result == CY_RSLT_SUCCESS);

    __enable_irq();
    cyhal_system_delay_ms(100);
    LEDS_Init();

    int led = 0;
    while (1) {
        int iGain = 1;
        LEDS_SetLed48(0, iGain, 0, iGain, 0, iGain, 0);
        LEDS_SetLed48(2, iGain, 0, iGain, 0, iGain, 0);
        LEDS_SetLed48(4, iGain, 0, iGain, 0, iGain, 0);
        LEDS_SetLed48(6, iGain, 0, iGain, 0, iGain, 0);
        LEDS_SetLed48(8, iGain, 0, iGain, 0, iGain, 0);
        LEDS_SetLed48(10, iGain, 0, iGain, 0, iGain, 0);
        LEDS_SetLed24(12, 0, 0, 0);
        LEDS_SetLed24(13, 0, 0, 0);
        LEDS_SetLed24(14, 0, 0, 0);
        LEDS_SetLed24(15, 0, 0, 0);

        if (led < 6) {
            LEDS_SetLed48(led * 2, iGain, 0, iGain, 255, iGain, 0);
        } else {
            LEDS_SetLed24(led + 6, 0, 15, 0);
        }

        LEDS_Transmit();
        cyhal_system_delay_ms(100);

        led++;
        if (led >= 10) {
            led = 0;
        }
    }
}

At the beginning there is some system initialization. Led variable is counter holding index to active LED. But it is physical index, it does not worry about underlaying LED type. In every iteration of infinite loop, I reset all LEDs to zero. First, I reset 48-bit LEDs first because they are first in chain. I need to increment index by two for every LED because 48-bit LEDs occupies 2 slots. Then I reset 24-bit LEDs. In this case index increment by one. After turning all off, I enable one depending on counter value. If the value is less than 6, I enable some of first 48-bit LEDs. Again, I need to index them with taking into account that they occupy two slots, so physical led index is actually multiplied twice. In case of later 24-bit LEDs, I need to index them with offset. They start at position 12, but because there is additional 6 “unwanted” entries before that, 12 – 6 is 6 and this is offset which I add to led index counter passed to LEDS_SetLed24. Finally, after buffer is setup, I send the new data to strip suing LEDS_Transmit() and then there is just some delay for defining speed of animation and incrementation of physical led counter.

Note that it works even 2 LEDs in 48-bit part of chain are missing. How is that possible I descibred in previous forum post: Testing BI pin

Conclusion

That’s it. Outcome is that combining different types of LED on single bus is possible and works. It was not that hard, because I already prepared library with keeping this use case in mind. Next time I will look to final piece I need before I move to making final project.

Next forum post in my series: Misaz’s WL-ICLED experiments: Counting LEDs on bus

Building Custom LED Bar and Control Unit - RGB for RadiantGoofyBulbs

navadeepganeshu — Sat, 15 Nov 2025 12:08:32 GMT

After discussing the project idea here The Project Plan - RGB for RadiantGoofyBulbs and setting up prismatic tool for display colour extraction Display Colour Extraction - RGB for RadiantGoofyBulbs , where is my hardware!

Through this blog, I will take you through the my steps assembling the LEDs, bringing together in a frame, adding diffusers and finally building the RGB LED towers.

Materials and Components Used

Size 15×20 cm perfboard sheet
SMD 5050 LEDs of P/N 1315050930246
Breakout boards for 5050 LEDs
NodeMCU ESP board
Size 2.54mm JST connectors
Wires, Solder Setup
Standoffs or Spacers
Acrylic Sheets

The Process

Preparing Perf-Board by cutting it from 15cm × 20cm dimension to LED strip sized lengths to fit in the enclosure.

LEDs are now soldered along with 5050 size breakout boards provided and mounted on the perf board.

A much later image, but everything then works :)

Before the above image, some of the LEDs were having issues as they didn’t light during testing. Root cause was then found to be the LED pins were actually not making contact on the breakout board with the berg pins soldered. Had to solder bridge in some places - ewww, that's messy, yes and would kill the OCD of any healthy electrical engineer.

Completed LED Strips ready to go inside the tube looks like this and after making two of then, doing a polarity and continuity check, clean wire management, they're good to go.

The mechanical assembly is slightly more messy - we'll discuss about it in the next blog :)

Building the Control Unit

Now to control the RGB LED bar, NodeMCU based unit is brought together. Although the supplied Arduino was used during earlier evaluations, the idea is to keep it simple, bare minimum hardware and the one that has wireless capability. JST connectors are preferred for modular plug-and-play connection with the LED bars. Again, a small perf-board PCB is made for connections power section routing.

Assembled between two acrylic sheets using standoffs for a neat finish and durability. Please rate my standards out of 10...haha ;)

In the next blog, we'll look at the assembled tubes, integration and bring-up of the full system. Until then cheers and do share your comments and ideas!

Misaz’s WL-ICLED experiments: Mysterious End Frame

misaz — Sat, 15 Nov 2025 11:45:29 GMT

Hello everyone. I continue working on next experiment, but I found something which is strange or at least somehow interesting, and decided to dedicate blog to it.

I was implementing last protocol. It is two wire protocol supported by 1311610030140 LEDs. This protocol is interesting because, it does not require exact timing. Other LEDs require you to emit LED signal at specific frequency, with some tolerance, but not big tolerance. These LEDs are different. They have separate pin for data and clock and allow transferring data at any speed up to about 33 MHz. It has several benefits. First of all, you can clock your MCU at any speed you want. In case of classic LEDs, you need to adjust clocking system of MCU which typically place constraints of MCU clocking and can limit you if your design contains more timing sensitive parts. Other benefit is that you can get much higher data transfer, which may allow you to make much longer strips while maintaining same refresh frequency.

Such protocol is described in datasheet using following diagram (and table describing requirements for T parameters mentioned in diagram):

This diagram is somehow confusing. There are several parts more or less confusing. Sadly, Würth datasheet has no explanation. It actually contains absolutely no texts except tables, diagrams, graphs, etc. Well, there are two technical sentences as a note on the bottom of pages. The only other texts here are some legal disclaimers. I always expect datasheet to be comprehensive source of truth, but this one slightly weak. The most confusing part to me is “End Frame” section. It is slightly better explained on later diagram in datasheet including description of somehow similar “Start Frame”:

Start frame is easy. But I do not understand purpose of end frame. It says that it should generate one bits and the number of bits is equal to N/2 where N is strip length. First interesting thing is that according to this formula, it can end up with number of bits which is not even divisible by 8. It makes very hard time when implementing driver using SPI peripheral, because very few peripherals support configurable data width with all possible options less than 8. But you can design your software in a way that strip is always multiple of 16, then you can just add bytes to end. Strip do not know how long it really is, so you pick lowest higher multiple of 16. For 100 LEDs, you can make it 112 LED long on software layer. Another interesting part is division by two. There is not written anywhere if it is intended to round down or up, but Würth official library says up in comment.

I implemented it and it did not work. For some reason, only first LED light up. For some time, I consider soldering fault on my side, but I tried to play with this strange part more before resoldering and make it somehow working.

N/2 Stop Bits

One of my theories was that purpose of this section (no matter how crazy it’s definition is) is for synchronizing LED to start emitting new colour at the same time. If chips in LEDs have counter, they can count how many data were transferred before reaching this end frame and then start emitting new colour all at the same time. They do not need to compensate length of data transfer, because they actually receive end of frame bits all at the same time as highlighted on diagram in Würth datasheet. They only need to know when it should happen and for this reason end of frame could be useful to indicate it.

32 Stop Bits

My other theory is that it is used for compatibility with some other LEDs. Only LEDs with similar interface I know are APA102 which seems deprecated and very hard to acquire to me, but their datasheet is searchable. Their protocol is almost identical, including format of start frame, but end frame is not defined in such horrible way. In case of APA102, end frame is defined as sending 32 x one bit, basically the same as start frame, just ones instead of zero. I implemented emission of exactly 32 high bits, instead of N/2 high bits and Würth LEDs accepted it. But there was strange behaviour that when LED was not power-cycled since previous experiment, they started to emit colours as expected, except exactly second LED which turned off. This seem weird to me because 32 ones are valid command for LEDs for white at full brightness. After I power cycled board to reset all chips, even with 32-bit stop bits they no longer accepted colours and stuck in state, where only first LED work, exactly as in previous experiment.

0 Stop Bits

After such experiments, I looked how professionals do that. I looked how Würth implemented it in their official library. And to my surprise, they have some macros to counting stop bits, they allocate space in buffer for that, but they do not set them to ones. And especially, not to N/2 ones. They define buffer in this way:

static uint8_t DATABuf[ICLED_BYTESTOTAL] = {true};

I think they thought, that when defined in this way, C/C++ runtime will initialize all values to all ones. They actually reset Start bits to zero before sending data. But true is not 0xFF, but 0x01. Second, C/C++ standard says (using very simplified words), that if array initializer has less data, then array size, remaining part of array is zero initialized.

So, they actually send zero bits as stop bits. I tried experiment with it slightly differently and try send no bits at all. It started working, I have seen right colours on all my 6 LEDs.

First refresh, only first LED works

One issue which remains (and it was issue in all previous cases) is that on power up and first data transmission, only first LED works for some reason. At second refresh, all LEDs updates and start working. Maybe my signalling is still wrong. In datasheet there is several more confusions like that clock and data signals at the beginning of diagram are low, but at the end, they are high and there is no explanation when should MCU switch from high back to low. This basically define CPOL param when SPI peripheral is used to generate signal. Würth use CPOL=0 in their library. Also, it is not clear how 3-bit command type interfere with start and stop bits and if some detection of transfer phase is implemented using these.

Floating (High-Z) pins at powerup

One issue with (not only these) LEDs is that MCU pin is typically floating in time between power up and time when MCU initializes GPIO setting. I added external pull down to eliminate issues caused by this, but it has no impact on issue with only one LED working on first refresh cycle.

Searching Internet for Truth about End Frame

This is obviously lot of unexplained magic. So, I tried searching for LED which I think 1311610030140 are intended to be compatible with. I searched for APA102 and found library implemented by Pololu. It contains 20 lines long comment explaining real purpose of end frame. Simply rephrased, LEDs behave differently than I thought. Logic on clock signal is more dumb than I thought. Every LED just negate clock input signal and pass negated one to next one. This cause shift of half period. This minor clock shift LEDs use for data forwarding. Logic in controller wait for it’s 32-bit of data. Every (not only first one) LED receive clock almost immediately when data transmission begins. Clock is available to all LEDs immediately using chain of inverters. Only data transmission is delayed. Actually, while first LED receiving it’s data, second LED still receives zero bits. It seems that start frame can be arbitrarily long. My understanding is that LED identifies it’s own data by observing first high bit after long (at least 32-bit long) sequence of zeros. At that time, it still propagates zeros on output data line. After it receives it’s own complete 32-bit frame, it starts propagating data to next LED. I deduced this by observing how signal outputted from 6^th LED looks like. I exposed this signal on test pads on my PCBs. It would be better to evaluate single led individually but unluckily; I made PCB with 6 LEDs.

Data are shifted by half of the cycle because output clock is inverted input clock. But because clock is ultimately generated by MCU and data rate is lowered half a cycle on each LED, if MCU send 0 stop bits like I did, last LED will miss some clock cycles. For this reason, MCU need to generate at least N dummy clock edges or in other words N/2 full clock cycles, which are used just to propagate final bits which will be otherwise lost because of propagation delay on chain.

Why 0 Stop Bits worked?

It most probably did no work and worked only just by accident. It most probably explains why it did not work at first run. I still think Würth add some logic to determine validity of chain and synchronized colour switch to happen at the same time on whole chain or something like that. When I send zero stop bits, LED signal was likely incomplete and for this reason LEDs did not switched colours at first run. But when second refresh begin, it started with start signal which generated cycles which were missing in first run and at that point LEDs started emitting right colours. But I suspect that it was actually data from previous run. From my experiments it seems that LEDs has absolutely no timeout logic and end of previous transfer can interfere with start of next transfer. And this I consider quite problematic. Do you remember the confusing part that Würth’s diagram start at logical low level and ends with high level without explaining when and how should MCU switch between them in between transfers? I made some experiments and behaviour actually differ if last transmitted bit is low or high. I tried change end frame to be 0xFE instead of 0xFF and it actually behave differently. It definitely needs more investigations to understand what’s exactly going there.

Conclusion

While I explained some mysteries, I still did not manage to make it fully reliable. I will continue experimenting with it, but for now I wasted much more time than expected. It would be really nice If European based chip company produce normal reasonably detailed datasheet explaining chip behaviour and implemented features. Making even datasheet detail level compatible with Chinese is not good idea and cost me lot of time. Because time is running low, I will switch back to classic single LEDs for a while and continue with experiments according to original plan to be able to complete final project in time. While this forum post was quite longer, next time will be much shorter because I already concluded experiment and it went well. Btw, one lesson from today is that writing forum post/blog for element14 can serve as debugging duck. Thank you for attention. See you in next forum post.

Next forum post in my series: Misaz’s WL-ICLED experiments: Combining LEDs of multiple types

Misaz’s WL-ICLED experiments: Testing BI pin

misaz — Fri, 14 Nov 2025 12:51:08 GMT

Hello. I welcome you to my second forum post as part of Light Up Your Life Challenge!. In this forum post I will share my experience with PCB design and soldering LEDs. In this part I will experiment with BI pin of 1312121320437 Würth LEDs (middle sized PCB if you follow my previous blog posts).

BI pin is another input pin of 1312121320437 LEDs. It is used as fallback mechanism for case one LED broke. It makes chain operational even in that case (except the one broken LED, of course). If connected as recommended, it is connected in this way:

Wire highlighted by red colour on schematics above is standard chaining of LEDs. Data Output (DOUT) of previous LED is connected to Data Input (DIN) of next LED. Backup Input (BI) pin is connected to output of second previous LED. (I am not sure if Backup Pin is exact meaning of BI abbreviation, but it is my guess). If any of classic addressable failed, it stopped forwarding signal over daisy chain and all LEDs after it become unavailable to control. Purpose of BI pin is to mitigate it. It does not only target permanent failure like LED burning out, but it also targets intermittent failures, like when some LED lost power because of brownout and resets it’s engine in the middle of transfer. Purpose of BI pin is to mitigate faults like these. It obviously does not target faults like that some LED shorts power supply rails.

If middle LED on diagram above fails, previous LED still send data to BI pin of next LED, so while middle LED fails, left, right and rest of chain continues to operate. Chips in LEDs are smart and detect it. From LED point of view, it looks in a way, that every LED actually receive data on BI pin first. But the data received are actually intended to be used by previous LED, so LED ignore them. After 48-bit for LEDs is received, LED expect that it receives it’s own 48-bit while receiving the same 48-bits on DIN pin with short delay caused by forwarder in previous LED. If it does not happen, it processes data from BI pin because it technically the same data are transmitted here. BI pins work even when multiple LEDs on strip are broken. There just must not be 2 consecutive LEDs broken. If there are 2 consecutive LEDs broken, next LED do not receive signal from DIN nor BI (because both come from broken LEDs) and rest of the chain stop operating as well.

Let’s test in practice. If you read my previous blog, you may know that I partially intentionally and partially unintentionally omitted two LEDs on my testing PCB.

These missing LED actually behave like “broken” LEDs. There is nothing what would forward signal to next pin. But because of BI pins, this strip should work. Let’s test it.

Since signalling of these 48-bit LED is compatible with 24-bit, there were very little updates to the firmware. In fact, any firmware which works with 24-bit LEDs work with these 48-bit ones, but you need to set 2 LEDs for every 1 LED on bus and it needs tricky encoding of R, G, and B channels of these 2 virtual LEDs. I modified API of my library in this way. Originally, I had following functions

void LEDS_Init();
void LEDS_SetLed(size_t index, uint8_t r, uint8_t g, uint8_t b);
void LEDS_Transmit();

I renamed SetLed to SetLed24 and added SetLed48:

void LEDS_SetLed48(size_t index, uint8_t rI, uint16_t rPWM, uint8_t gI, uint16_t gPWM, uint8_t bI, uint16_t bPWM);

This function takes rI, rPWM, gI, gPWM, bI, and bPWM which corresponds to current and PWM values for each of RGB channels. It recodes them and set actually two slots in internal buffer. For this reason, when 48-bit function is used, it should be called with index multiplied by two because every LED occupies two entries in that internal buffer. While this design is strange at the first look, I will utilize it in later experiments when I will try control both 24-bit and 48-bit types of LED on single chain.

Example usage is something like:

LEDS_Init();
int iGain = 0;
LEDS_SetLed48(0, iGain, 50, iGain, 0, iGain, 0);
LEDS_SetLed48(2, iGain, 0, iGain, 50, iGain, 0);
LEDS_SetLed48(4, iGain, 0, iGain, 0, iGain, 50);
LEDS_SetLed48(6, iGain, 50, iGain, 50, iGain, 0);
LEDS_SetLed48(8, iGain, 0, iGain, 50, iGain, 50);
LEDS_SetLed48(10, iGain, 50, iGain, 0, iGain, 50);
LEDS_Transmit();

Code above. Set 6 LEDs on strip to following colours: red, green, blue, yellow, cyan, pink. I set values to 50 instead of full range, so it does not blow up my eyes. It also look slightly better on photos. So, let’s upload this to microcontroller, connect it and see what happen:

It works. Even with LEDs missing. As you can see stripe is not shift if failure like broken LED happen. Second colour (green) and fifth colour (cyan) are missing because LEDs which should light them are “broken” but rest of the strip work and colours stay at their position exactly as defined in source code.

I cheated a little in this experiment. It actually does not work reliably because I am controlling these LEDs by 3.3V microcontroller. And actually, these LEDs require at least 4.2V to operate. I actually power them from 5V rail of development kit which is fine, but control signal is only 3.3V which is slightly below threshold of digital logic in LEDs. Datasheet specify that your signal must be higher than 0.7 * VCC to be reliably classified as logical 1. In case of 5V supply 0.7 * 5 is 3.5V, so 3.3V is not enough. My favourite trick on this issue, is connecting my cheap Chinese logic analyser. It is connected to wires which go to left side on photo. Also works with scope probes from Multicomp Pro oscilloscopes. Not exactly sure how small additional capacitance or whatever make this working, but it typically works for me in these cases.

Propper solution is use voltage level shifter. Sponsored challengers received one. I have it as well in my drawer. I was lazy to use it and connect bunch of wires to it since I know this simpler cheat 😊 Another possible solution/workaround is to lower voltage supply. If you change 5V to let’s say 4.5V. VCC * 0,7 is now 3,15V and this is lower than 3.3V control signal. Another cheaty solution is to violate 4.2V minimum voltage and power them just by 3.3V. I tested it. They seem working well. Did not test running all possible codes and did not test it long time under various temperature conditions, but it may be easy workaround for development time.

So that’s it for today. Outcome is that my soldering was successful. The only two faults on board are intentionally missed LEDs and strip works even without them. Tomorrow I will look at the last type of LEDs which I did not test yet. And actually, they are the smallest one, so highest change of soldering issue. But let’s see. They also use different protocol, so I will need to rewrite testing firmware once more.

Next forum post: Misaz’s WL-ICLED experiments: Mysterious End Frame

I got the Sponsored Kit

Hey everyone, just letting you know I received the Sponsored Kit. Super excited to start building with it — thanks to the organizers and Würth Elektronik. I’ll be using this kit to make a 10x5 LED matrix and share the process as I go.

What’s inside the box

Here’s everything I found, with quantities:

Würth Elektronik 1315050930002
LED, AlInGaP / InGaN, RGB SMD, 120°, Round, R 13 mA / G 13 mA / B 13 mA — Quantity: 25
Würth Elektronik 1313210530000
LED, AlInGaP / InGaN, RGB SMD, 120°, Dome, R 5.5 mA / G 5.5 mA / B 5.5 mA — Quantity: 25
Würth Elektronik 1312020030000
LED, AlInGaP / InGaN, RGB SMD, 120°, Square, R 5.5 mA / G 5.5 mA / B 5.5 mA — Quantity: 25
Würth Elektronik 1312121320437
LED, AlInGaP / InGaN, RGB SMD, 110°, Square, R 20 mA / G 20 mA / B 20 mA — Quantity: 25
Würth Elektronik 1315050930246
LED, RGB SMD, 120°, Round, R 21 mA / G 21 mA / B 21 mA — Quantity: 25
Würth Elektronik 1311610030140
LED, RGB SMD, 120°, Square, R 6 mA / G 6 mA / B 6 mA — Quantity: 25
5050 LED breakout PCB
PCB is 0.8 mm / 0.03" thick, ~10 mm / 0.4" spacing between rows — Quantity: 50
Multicomp Pro MCBB830K
Solderless breadboard, ABS, 1 mm, 105 mm x 183 mm — Quantity: 2
Texas Instruments TXS0108EPWR
Level translator, 8 channels, 1.65 V to 5.5 V — Quantity: 1
Arduino Zero (ABX00003)
ATSAMD21G18, ARM Cortex M0+, 32 bit, 32 KB RAM, 256 KB Flash, 20 I/O pins — Quantity: 1
Power Supply with Interchangeable Plugs (MP007771)
AC/DC power supply, 24 W, 9 V DC, 2.5 A — Quantity: 1

My plan (short)

I’ll solder the 5050 LEDs to the breakout PCBs, wire them into a 10 columns x 5 rows setup, and control columns as chains from the Arduino Zero. I’ll post step by step: soldering, wiring the chains, code, and troubleshooting notes. Expect pics and short updates as I make progress.

I’ll start with the first solder session later this week and post the results.

AuraAlert - Part 4 - LED Control, Test PCB Design and Analysis

arvindsa — Thu, 13 Nov 2025 21:17:14 GMT

This project is extremely complicated given the number of components and power systems and I have never designed a buck booster on a PCB myself. So It took some time to learn and get it done. Add to it, my work required me to travel quite a lot and so, i couldn't post an update. But here I am.

LED Control using Micro-controller

I Immediately soldered the 1315050930246 and 1315050930002 on the Breakout board and wired it to my Nucleo Board. The Nucleo gave me 5V and I routed it's 3.3V logic through the logic level converter from Adafruit which I already had, Guess which chip it used? TXS0108EPWR. I really wanted to use the Fast-LED Library given the amount of effects i can easily do with it based upon its documentation, but behold my bad luck that STM32 code was failing and i had to resort to the Adafruit's Dot-star for DATA + Clock Protocol and Neo-pixel for Single Wire Data protocol.

www.youtube.com/watch

Things i noticed about the Wurth's LED 1315050930002 compared to WS2812B 5050. At the 5V Voltage, brightness is almost imperceptible but as the supply voltage does down, the Wurth's LED gives better Light. Sadly i was not able to capture this on my phone because to try this out, i had to use my university Lab and also Wurth's Plastic enclosure seems to be far more forgiving to my bad soldering skills. I have melted quite a couple of WS2812B 5050 in the past. Now, I have never used an Equivalent of the 1315050930246 so, no comments there. Also I noticed that Wurths' LED is Diffused. Something I overlooked in the Datasheet but it turned out to be a happy mistake because now i need not have a strong diffusion material in my project.

I did the same using the ESP32 Dev Kit (not S3 version) and again, i was able to control it without much change.

The PCB Design

In the Architecture, i mentioned that i plan to use an LiPo Battery which means the supply voltage is gonna vary between 3.4 and 4.2V, and yes, i have been able to make the LED work at lower voltages, but the brightness was not to my liking. A boost converter was needed. After going through the videos https://www.youtube.com/watch?v=QnUhjnbZ0T8 by GreatScott and Phil's Lab's Boost Converter Design & Sizing - Phil's Lab #113 , Switching Regulator PCB Design - Phil's Lab #60 and Boost Converter PCB Design - Phil's Lab #106 i chose the components for the power supply-

TPS6123 - 5V boost converter to ensure that LED receives 5V always for consistent illumination
AP61300Z6 - 3.3V Buck converter for the Logic level.
AP2112K-3.3 - Backup 3.3V
MCP73831 For battery charging along with FET based power path (A stable circuit Ive been using for an year now)
Dual Mosfet based Batter's Voltage measurement system
FUSB303BTMX for USB-PD
TPS25200 EFuse

I also added an ESP32-S3 and STM21L031, ICS-43434, TXS0108EPWR, NRF24L0. While I was learning the buck boost converter, i also came across Phil's Lab - ESP32 + PCB Antenna Hardware Design Tutorial - Phil's Lab #90 and so went ahead and added in a circuit for NRF24's chip with a PCB Antenna. I am using a Dual MOSFET design, so that i can read the ADC value only on demand and rest of the the time, the Battery is cut-off from the resistor bridge thus avoiding the slow current leakage which will reduce battery life. I thought hard to see if a Couloub based Battery Guage is worth is e.g. bq27441 as seen in Sparkfun baby sitter. But the cost is too high and we do not need very accurate measurements. The component is placed on the PCB such that each subsystem is visually different

Average Boost Converter has an efficiency between 80-90% based on load and many other factors. Assuming 80% efficiency the input current needed for the Boost to 5V = I_in = (V_out * I_out) / (V_in * 0.8).

Now, in the last post i mentioned i needed 250mA for the LEDs. That was for one channel, for all three channels it is 750mA which requires an input current of 1.38A, So input to the Add in ESP32-S3 which needs 500mA for itself as per their documentation and another 100mA for all others, it adds up-to almost 2A peak usage. Therefore, a 15W USB-PD Chip was needed. Note that for hand-held device, it is not needed as it does not have ESP32 and the LED power usage is lower, and most of the time it is supplied from the battery

And for the safety of any computer into which the device may be plugged into, i added an EFuse which will trip off at 2A

For the PCB Antenna, I had to calculate the micro-strip width to ensure that I get 50Ohm Impedance for a two layer board, KiCad's Calculator told be that i had to use a 2.8mm wide track. I was sure i made some mistake in the input, Kicad's micro-strip calculator had many options, But it turned out to be correct no matter what. The thickness of the dielectric layer played a major role,. and i have to use a 4 Layer board for a practical track width, but i decided to go ahead anyway and take a risk. So at the end of the last passive i drew a track of 2.8mm width to the feed of the antenna. I did add an backup NRF module just in case.

After couple of hours of routing, i sent it to the FAB and within a week i received the boards.

The PCB Testing

I had 5 boards manufactured. To test the circuit in isolated manner, I decided to populate 3 boards each with different systems

Board 1: USB PD, Battery Charger and EFuse.

In this i only populated the USB, Battery Charger and eFuse. I shorted the wires to see if the eFuse will work and yes it turned off the power supply, no harm done. Note that this TPS25200 can be programmed to trip at any particular current value upto 3A by setting the appropriate value of resistor. I first programmed it to trip at 500mA, i connected it to my previous prototype of the hex device which uses WS2812B and monitored the current using Nordic Power Profile Kit V2, and on cue it turned off at around 540mA. For exact 500mA trip, i did not have the right value of Resistor. Next i tried with 2A, and again it worked correctly at around 2A.

Then i added in the ESP32-S3, Microphone and Tested the I2S Interface and a sample Edge Impulse code for keyword spotting and it turned out well.

Disaster Struck. I turned off my oscilloscope which i used to check the ripples in the 5V VBUS and came after lunch and when i turned it on, i see lines on the screen. And over the next few days, the oscilloscope went dead. Now gotta use my university equipment.

Board 2: Buck Converter and Boost Converter

Installing both the boost converter and Buck converter, i hooked it up to a load tester to see how it performs. The ripple was around 320mV peak to peak, which is quite terrible. I tried to replicate the suggested layout in the datasheet, but After scanning through the datasheet i realized i made some mistakes. Oh well, except for a ominous hum at low load, it was fine. I put the boost converter to the board 1 and ran the LED using the esp32, no problem at all. but the 3.3V buck converter was out of the question. Decided to use the LDO in the future for this project. The 5V boost converter is enabled only on demand via micro-controller. The Green Jumper is to tie the enable it by tying it to 3V

Here is the Waveform for the 5V showing 320mV peak to peak ripple.

And below is the actual ripple caused by the boost converter.

The mistakes i made in the boost converter was

Poured ground under switching element, it makes ground noisy for sure and theory says it increases EMI
The Datasheet said i should have only polygon in top layer for switched node, input and output while having ground for input and output. But i put pour on top and bottom and connected them by via. Apparently doing that on switched node makes things worse.
I should be connecting AGND, PGND to the regular ground via a star point. I did not

Here is the recommended layout for TPS6123

and the one i did. (Red is top layer, Blue is bottom layer)

Board 3: STM32 and LED

This board will be Powered by USB-C with 5.1K resistor which can give me minimum 500mA, i Soldered on STM32, Logic Level converter and LED's and ran it. All well.

Observations

The Buck converter is extremely noisy and i do not have the skillet nor time to fix it.
The Boost converter gives an hum during low load. Not gonna see this during actual usage as LED will pull enough current.
The Level converter and the on demand 5V does destroy the level converter chip. The datasheet says the Chip has to be enabled via OE pin only after the higher voltage input has been stabilized. So i had to do a patch work on the Board one. It seems if i don't adhere to this rule, the chip does get destroyed.
The Wurth LED does respond to 3.3V Logic too with 5V Supply. Obviously it works does not mean it will work reliably. Stick to the Digital input voltage - high-level value in the datasheet for reliable communication

Changes to be Made

Sacrifice efficiency for clean and stable 3.3V by using an LDO
LED changes based on some further design thinking. Small change in Industrial design also
Improve the layout of the 5V boost converter by adding an Electrolytic capacitor and fix the layout issue (Put Ground plane under the switching element where i was sup)

Newer Power Budget for LEDs

Device		Qty	Current per LED Color	Total Current
Nano	1312121320437	3	20	180.00
	1313210530000	12	5.5	198.00
	Total			378.00

Hex	1315050930002	7	13	273.00
	Total			273.00

Halo	1311610030140	12	6	216.00
	1315050930002	1	13	39.00
	Total			255.00

Now off to the Final PCB Design ...

Misaz’s WL-ICLED experiments: It’s soldering time

misaz — Wed, 12 Nov 2025 22:30:00 GMT

Hello. I welcome you to my second forum post as part of Light Up Your Life Challenge!. In this forum post I will share my experience with PCB design and soldering LEDs.

For testing PCBs, I designed 3 PCBs. One for each type of LED I will play with. PCB for 1315050930002 (which is classic one; compatible with WS2812Bs) I actually made few years back, originally intended for WS2812B LEDs. So, at this step I tested compatibility for first time – 1315050930002 matches PCB layout exactly. Remaining two PCBs for 1312121320437 (6-pin LEDs with 48-bit single wire protocol) and 1311610030140 (6-pin LEDs with two wire SPI-like protocol) designed from scratch. I focused common best practices. I dedicated 1 layer for GND plane and VCC wire I made stronger. Signal wires are thin. Here are PCBs as I designed and route them.

For making it simple I will refer LEDs as largest (Würth number 1315050930002), medium (1312121320437) and small (1311610030140) in this forum post. Sizes proportionally apply to PCB sizes in Kicad screenshot above.

Tracing wires was quite easy. All LEDs are designed in a way that it is possible to route signals reasonably well even on 2-layer PCBs. DOUT signals of LED connect to DIN signals of LED without need to cross anything. This apply even to medium sized which has BI PIN which is basically signal from second previous LED. It is used as a fallback for case when previous LED broke. In that case it does not receive signal from previous, but from second previous and continue operate. Technically you do not need it and you can just ground that pin (this is actual case of first LED in chain). I routed it and PCB look nicely even when it is routed. I added 100nF capacitor to every LED, except for smallest. In case of smallest, I added one cap for 2 LEDs to make PCB compact. At soldering time, I actually, replaced exactly one 100nF cap per board by 1uF. In case of my older PCB for classic LEDs (largest), I routed VCC as stripe on back side. On newer two PCBs I routed in on top section in between two columns of LEDs.

Soldering

For soldering, I used solder past and hot air approach. I applied solder paste manually (without stencil) inaccurately like this:

Placed components onto it like on following picture. I do not like that pin 1 marker is hardly visible on Würth LEDs. WS2812 has bigger marker. On Würth LED it is barely visible and I had to use magnifier glass. But on other hands Würth mention how is chip placed inside package, so it can be aligned just by observing internals of LED without checking corners. This I used for triple checking. At that point it looked like this:

And then I heated it by hot air.

Actually, the biggest mistake was to use more than 2-year-old solder paste. It did not go well. Most of flux dried out. I had really hard time. Components did not fit at right position. I had to manually align them when heating. Because layer of solder paste was highly non-uniform, some joins were very fat, some were unconnected, some were shorted. It did not auto balance like I have seen in my previous hot air attemps. In case of classic LEDs which are quite large, I manually fixed all these by solder pen. In case of small and medium I tried to push them to the PCB. This pushed lot of amount solder from bottom of chips, but in case of medium sized it shorted lot of pins of LEDs. It was visible because these LEDs have visible pins from sides. Interestingly, the easiest were the smallest one. I pushed them, this eliminated over-solder from bottom of LED and additional solder remained as solder balls on side of chip. these I removed by pen solder then. The hardest was the middle-sized one. I had to desolder them all, remove all solder paste from both PCB and LEDs and choose alternative strategy. Alternative strategy was that I applied some amount of tin to pads by pen (but not placed LEDs with solder pen). Then heated again by hot air and placed LEDs one by one into tin applied by solder pen previously. It was still quite hard because amount of tin which I applied by pen soldering was quite low, so I had hart time to place LED and push it to the tin. Most of the time they flown away because of “wind” from hot air solder.

Luckily the hardest LED is the only LED which has BI pin which allow operation of chain even one LED is broken. Missing LED can be considered as “broken” because it behaves in the same way (well actually there are other modes of failure like short circuit, but for simplicity let’s consider missing led equivalent to broken LED). As you can see on the photo above, I intentionally missed one when playing components. Let’s call it sophisticated faulty LED simulator. But later when soldering I broken one more, so I ended up with only 4 LEDs. Main requirement is that there are no two faulty LEDs consecutively. When I was reworking this PCB, I moved the LED to the corner and missed LEDs are actually middle one:

Schematically that PCB looks like

Finally, it looks like:

I already test classic (largest) ones because I recently did Halloween Project14, so I have firmware capable of generating signal right at hand. It works!

Remaining I tested only by multimeter. I tested that there are no shorts between pins and that ESD diodes between VCC, GND and signal pins are detectable. They are. Still there may be some bad joints on data signals between LEDs. It would be better to place some test point on these signals, but I did not get it at PCB design time.

For testing others, I need to modify firmware. In next forum post I want to spend some time and play with middle sized LED and test that BI pin feature actually works. In other words, I will test my sophisticated faulty LED simulator. And finally, one lesson: If your only solder paste is several years old and dry, buy new with LEDs.

Next forum post: Misaz’s WL-ICLED experiments: Testing BI pin

Misaz’s WL-ICLED experiments: Introduction

misaz — Wed, 12 Nov 2025 00:56:18 GMT

Hello everyone. I welcome you to my first forum post as part of my participation in Light Up Your Life Challenge!. In this post I will describe my plans and status.

I posted application to this design challenge but my application was not one of the best. So, I was not selected as sponsored participant who received nice kit containing 150 WL-ICLEDs from Würth Elektronik. Even I was not selected, I decided to buy few LEDs on my own expense and play with them. I am joining this design challenge as self-sponsored.

My biggest issue as far was to acquire PCBs because they stuck for about three weeks longer than usual in customs and postal offices. They arrived yesterday, so I am starting about week before deadline but I was conservative at scheduling time. I did not plan any ultra complex project, so week for playing with fantastic Würth LEDs should be fine.

My project which I proposed in application was a tool for diagnostics of LED strip. Unlike others, I do not plan investigate their optical properties thoroughly because I do not own suitable equipment and I also do not plan any fancy blinky project (at least for now). Rather I want to play mostly about LEDs. I want to focus on LEDs interacting. Kit contains six different types of LEDs, but some of they have common interfacing. Technically, there are 3 different interfaces used:

24-bit single wire Interface. It is compatible with WS2812
48-bit single wire Interface. Has similar timing. But more data are transferred and allows configure both current limitation as well as PWM drive.
32-bit two wire Interface (not I2C). it can be driven by MOSI and SCLK pins of SPI peripherals (MISO and CS unused). Protocol Transfer 24-bit of collor data for PWM control and 8-bit control byte which can set even current limiting.

Since I am self-sponsored, I did not buy all six kinds of LEDs. Instead, I bought 3 types of LEDs which each type support different interface. Here is sneak peek:

I want to do following experiments around LED interfacing:

Test BI pin which allows continuing operation if one LED on chain is broken
Test possibility to combine 24-bit and 48-bit on single LED chain
Automatically count LEDs on LED strip of unknown LED count

These experiments I want to conclude before starting working on my main project: diagnostic tool which will identify LED strip length, hopefully will support even chains combined from 24-bit and 48-bit LEDs and will be capable to characterize every LED on bus, identify possible faulty LEDs and locate them.

So that’s all for introduction. Stay tuned for next forum posts and final project post. They should all get published this week. I already soldered LEDs to my PCBs. I will post forum and share my thoughts about it later today or tomorrow.

Next forum post: Misaz’s WL-ICLED experiments: It’s soldering time

RGBMATRIX enabling BLE to change light color and adding effects - Blog-5

embeddedguy — Mon, 10 Nov 2025 09:55:46 GMT

Using Micropython BLE(Bluetooth) module
- Using NVS to store color values
Adding Effects to the LEDs

This is blog-5 of Light Up your life challenge. In this blog post, I am going to cover the progress that I have made so far. In the previous blogs I have discussed LED parameters, PCB schematic creation in KiCad and then testing the final PCB that I received from NextPCB. So far everything worked fine as expected and that is good news (relief) for me.

Post-4 https://community.element14.com/challenges-projects/design-challenges/light-up-your-life/f/forum/56299/rgb-matrix-testing-wireless-communication---blog-4

Post-3 https://community.element14.com/challenges-projects/design-challenges/light-up-your-life/f/forum/56232/rgb-matrix-testing-the-new-pcb

Post-2 https://community.element14.com/challenges-projects/design-challenges/light-up-your-life/f/forum/56186/design-idea

In the last blog post, I have just started to create something interesting. I started to use wireless communication such as the ESP-NOW protocol to change the color and control the LEDs. That worked as expected but needed some more secure and finer control. I will continue to work on ESP-NOW but before that I have BLE functionality enabled on this device.

With ESP-NOW, I was using switches for analog input to the ESP32 chip and based on the analog values the ADC value will detect a button press. This is fine. But there are some issues that needs to be covered. They are following.

First, ADCs can suffer from noise. That means that there can be a wrong Analog value that can be detected by the chip. To reduce that there are some methods suggested by Espressif to put some 1nF capacitors at the input pin. So that the pin value does not accidentally change to 0.

But there are other wireless technologies such as Bluetooth that can be more effective in such cases. For example, BLE can operate using Android applications and follows a standard procedure to connect, disconnect, write values for characteristics, etc. This will reduce the need for separate remote devices to control the LED lights but will need complex Android BLE application programming knowledge.

One more protocol that I have seen in some smart home products is using IR LEDs to transmit data. This can be something like ESP RMT protocol that transmits IR pulses using remote. This will work only when transmitter and receiver devices are in line of sight for not more than 30 meters or similar. The advantage is that it is easy to control the lights using tiny remote and no need to manage BLE connections. Also like ESP-NOW there is not a chance of accidently sending a wrong value if keyboard is not working as expected.

Using Micropython BLE(Bluetooth) module

BLE protocol defines GATT service and GATT characteristics. These characteristic values can be read or write. There are other functions of these characteristics as well such as notify and indicate. But for read and write one can change the individual color value. i.e. between 0-255. There are many other possibilities such as fine control of strip and adding effects etc. But for now let's consider a simple application to change the color of the LEDs.

For this part, I am using the official Bluetooth module of Micropython. This module provides the required functionality for Bluetooth to work.

import time
import bluetooth
from bluetooth import BLE
import asyncio
import ubinascii
import neopixel
import machine
from micropython import const
import esp32

One need to register the event IDs for the callback functions. The following code snipet shows some of the common IDs such as connect, disconnect and characteristic read/write.

_IRQ_CENTRAL_CONNECT = const(1)
_IRQ_CENTRAL_DISCONNECT = const(2)
_IRQ_GATTS_WRITE = const(3)
_IRQ_GATTS_READ_REQUEST = const(4)

_IRQ_GATTC_READ_RESULT = const(15)
_IRQ_GATTC_READ_DONE = const(16)
_IRQ_GATTC_WRITE_DONE = const(17)

After this it is required to create a Bluetooth object and define connect, disconnect and IRQ callback functions. Remember not to forget some of these functions as they are mandatory to be defined for proper Bluetooth functionality.

class RGBMATRIX():
    def __init__(self, name):
        self.name = name
        self.BLE = bluetooth.BLE()
        self.BLE.active(True)
        self.connection = set()
        self.register_services()
        self.BLE.irq(self.ble_irq)
        self.advertise()
        
        
    def register_services(self):
        RGB_UUID = bluetooth.UUID('7bf20ec6-e66f-4a61-9aa4-8fa20097a0c4')
        
        RED_UUID = (bluetooth.UUID('7bf20ec6-e66f-4a61-9aa4-8fa20097a0c5'), bluetooth.FLAG_READ | bluetooth.FLAG_WRITE,)
        BLUE_UUID = (bluetooth.UUID('7bf20ec6-e66f-4a61-9aa4-8fa20097a0c6'), bluetooth.FLAG_READ | bluetooth.FLAG_WRITE,)
        GREEN_UUID = (bluetooth.UUID('7bf20ec6-e66f-4a61-9aa4-8fa20097a0c7'), bluetooth.FLAG_READ | bluetooth.FLAG_WRITE,)

        rgb_service = (RGB_UUID, (RED_UUID, BLUE_UUID, GREEN_UUID,),)
        services = (rgb_service,)
        ( (self.red, self.green, self.blue,), ) = self.BLE.gatts_register_services(services)
        
    def advertise(self):
        
        name = bytes(self.name, 'UTF-8')
        advdata = bytearray(b'\x02\x01\x02') + bytearray((len(name) + 1, 0x09)) +  name        
        self.BLE.gap_advertise(100, advdata) 
         #get MAC address
        mac = self.BLE.config('mac')[1]
        print("device MAC address is: "+ubinascii.hexlify(mac).decode())
        
    def ble_irq(self, event, data):
        
        if event == _IRQ_CENTRAL_CONNECT:
            conn_handle, addr_type, addr = data
            self.connection.add(conn_handle)
            print('Central connected')
            
        elif event == _IRQ_CENTRAL_DISCONNECT:
            conn_handle, addr_type, addr = data
            self.connection.remove(conn_handle)
            self.advertise()
            print('Central disconnected.')
            
        elif event == _IRQ_GATTS_WRITE:
            conn_handle, attrb_handle = data
            #print('Gatts write')
            self.val_red = self.BLE.gatts_read(self.red)
            self.val_blue = self.BLE.gatts_read(self.blue)
            self.val_green = self.BLE.gatts_read(self.green)            
            self.set_led_strip(self.val_red, self.val_blue, self.val_green)
            
        elif event == _IRQ_GATTS_READ_REQUEST:
            conn_handle, attrb_handle = data
            #print('read request')

Next it is required to define some Neopixel objects on different pins for different types of LEDs.

ledcorner = machine.Pin(12)
ledfive = machine.Pin(45)
ledseven = machine.Pin(47)

neopixelcorner = neopixel.NeoPixel(ledcorner, 9)
neopixelfive = neopixel.NeoPixel(ledfive, 5)
neopixelseven = neopixel.NeoPixel(ledseven, 7)

def set_led_strip(self, red, blue, green):
        
        for i in range(9):
            neopixelcorner[i] = (int.from_bytes(red), int.from_bytes(blue), int.from_bytes(green))
    
        for i in range(5):
            neopixelfive[i] = (int.from_bytes(red), int.from_bytes(blue), int.from_bytes(green))
            
        for i in range(7):
            neopixelseven[i] = (int.from_bytes(red), int.from_bytes(blue), int.from_bytes(green))
            
        neopixelcorner.write()
        neopixelfive.write()
        neopixelseven.write()
        
        nvs.set_i32("red" , int.from_bytes(red))
        nvs.set_i32("blue" , int.from_bytes(blue))
        nvs.set_i32("green" , int.from_bytes(green))

Now we are good to go. Only the final thing is to define the main() function, create object and run it continuously.

def main():
    BLE = RGBMATRIX("ESP32S3")
    #BLE.set_color(255)
    
if __name__ == "__main__":
    main()

One done just run the code. You will see that the device named ESP32S3 will appear on your BLE scanner lists. Now one can connect to the device and write the characteristics value for RED, GREEN and BLUE colors. The following video shows the colors in action with BLE application for Windows. One can use any BLE application such as nRF connect on mobile phones.

community.element14.com/.../2262.final_5F00_ele14.mp4

Using NVS to store color values

One most important thing to me is to store color values. I do not prefer that when there is power cut or user turns off the main switch and starts the LED light, there is either no color or there is specific prefixed color like white. I think that the LEDs should have the same color that was set previously. And for this reason, I am using NVS (non-volatile storage) to store color key-value pairs. In the begging the storage will be initialized once and values stored will be the color values for the LEDs.

This feature is useful in case where there are frequent power cuts and user do not need to set colors each time power is back or any situation similar to that.

nvs = esp32.NVS("RGBMAT")

try:
    status = nvs.get_i32("Lighton")
except OSError:
    print('Blob is not set, setting it now..')
    nvs.set_i32("Lighton", 1)
    nvs.set_i32("red" , 255)
    nvs.set_i32("blue" , 0)
    nvs.set_i32("green" , 0)
    nvs.commit()

In the __init__ function one can insert the following code. This will set the values of each color to previously set values.

self.redl = nvs.get_i32("red")
        self.bluel = nvs.get_i32("blue")
        self.greenl = nvs.get_i32("green")
        self.set_led_strip(self.redl.to_bytes(1), self.bluel.to_bytes(1), self.greenl.to_bytes(1))

The update the LED colors as there is BLE Write operation to the characteristic.

elif event == _IRQ_GATTS_WRITE:
            conn_handle, attrb_handle = data
            print('Gatts write')
            self.val_red = self.BLE.gatts_read(self.red)
            self.val_blue = self.BLE.gatts_read(self.blue)
            self.val_green = self.BLE.gatts_read(self.green)            
            self.set_led_strip(self.val_red, self.val_blue, self.val_green)

In the set_led_strip() store the values

 def set_led_strip(self, red, blue, green):
        
        for i in range(9):
            neopixelcorner[i] = (int.from_bytes(red), int.from_bytes(blue), int.from_bytes(green))
    
        for i in range(5):
            neopixelfive[i] = (int.from_bytes(red), int.from_bytes(blue), int.from_bytes(green))
            
        for i in range(7):
            neopixelseven[i] = (int.from_bytes(red), int.from_bytes(blue), int.from_bytes(green))
            
        neopixelcorner.write()
        neopixelfive.write()
        neopixelseven.write()
        
        nvs.set_i32("red" , int.from_bytes(red))
        nvs.set_i32("blue" , int.from_bytes(blue))
        nvs.set_i32("green" , int.from_bytes(green))

Adding Effects to the LEDs

Effects are ways to make LEDs blink more decorative and catchier. Hence, there are some standard effects such as Rainbow, chasing effect, fading effect, etc.

Out of these I was able to create Rainbow effect on these LEDs. Basically, one can take inspiration from Internet for different effects that LEDs can create. Here I have created a Rainbow effect using a Wheel() function that creates R, G, B values for the each color and updates these colors on the strip. Using some for() loop and doing the mathamatics of colors one can generate different effects that look eye catchy.

Following video shows the Rainbow effect on the LEDs.

(note: I still need to work on one of the SPI LEDs to create this effect but other SPI and normal LEDs work fine.)

community.element14.com/.../4807.rainboweff.mp4

import neopixel
import machine
import time
import esp32
from machine import PWM, Pin

class LIGHT_EFFECTS(object):
    
    def __init__(self, interface = 2, miso = 38, mosi = 14, sck=10, num_led = 7, firstbit=0):
        
        self.spi_num = interface
        self.sck_pin = Pin(sck)
        self.miso_pin = Pin(miso)
        self.mosi_pin = Pin(mosi)
        self.first_bit = firstbit
        self.leds = num_led
        self.spi = machine.SPI(self.spi_num, baudrate=8000000, polarity = 0, phase = 0, sck = self.sck_pin, mosi = self.mosi_pin, miso = self.miso_pin, firstbit=self.first_bit)
        self.start_frame = bytes([0x00, 0x00, 0x00, 0x00])
        
    def send_start(self):
        self.spi.write(self.start_frame)
    
    def wheel(self, pos):
        if(pos) < 85:
            return (pos * 3, 255 - pos * 3, 0)
        elif pos < 170:
            pos -= 85
            return (255 - pos * 3, 0, pos * 3)
        else:
            pos -= 170
            return (0, pos * 3, 255 - pos * 3)
        
    def rainbow_cycle(self, wait, numled, pin_num):
        neopixel_id = neopixel.NeoPixel(machine.Pin(pin_num), numled)
        for j in range(255):
            for i in range(numled):
                pixel_index = (i * 256 // numled) + j
                neopixel_id[i] = self.wheel(pixel_index & 255)
                neopixel_id.write()
                time.sleep(wait)
                
    def rainbow_cycle_spi(self, wait, numled, pin_num):
        frame = []
        
        self.spi = machine.SPI(self.spi_num, baudrate=8000000, polarity = 0, phase = 0, sck = self.sck_pin, mosi = self.mosi_pin, miso = self.miso_pin, firstbit=self.first_bit)

        #b, g, r = self.get_pixel(0x00, 0x00, 0xff)
        for j in range(255):            
            for i in range(self.leds):                
                pixel_index = (i * 256 // numled) + j
                r, g, b = self.wheel(pixel_index & 255)
                frame.append(0xFC)
                frame.append(b)
                frame.append(g)
                frame.append(r)
            self.spi.write(self.start_frame)
            self.spi.write(bytearray(frame))
            self.spi.write('b\x07')
            time.sleep(wait)
            frame = []
            
            
    def wheel2(self, pos):
        
        if(pos) < 1365:
            return (pos * 3, 4096 - pos * 3 , 0)
        
        elif pos < 2730:
            pos -= 85
            return (4096 - pos * 3 , 0, pos * 3)
        
        else:
            pos -= 2730 
            return (0, pos * 3, 4096 - pos * 3 )
            
    def rainbow_cycle_spi2(self, wait, numled):
        
        frame = []
        self.spi = machine.SPI(self.spi_num, baudrate=8000000, polarity = 0, phase = 0, sck = 40, mosi = 13, miso = 38, firstbit=0)
        
        for i in range(numled):
            for k in range(48):
                if((color >> i) & 0x1):
                    frame.append(0xFC)
                else:
                    frame.append(0xC0)
                    
            send = bytearray(frame)
            self.spi.write(send)
            time.sleep(wait)
            frame = []
        
                
eff  = LIGHT_EFFECTS()

while True:
    eff.rainbow_cycle(0.0000001, 9, 12)
    eff.rainbow_cycle(0.00001, 7, 47)
    eff.rainbow_cycle(0.000001, 5, 45)
    eff.rainbow_cycle_spi(0.01, 5, 45)
    #eff.rainbow_cycle_spi2(0.001, 3)

Smart car chamber #5 Solder Method for WL-ICLEDs

fyaocn — Sat, 08 Nov 2025 14:02:02 GMT

1 Solder method for WL-ICLED

Just briefing the solder method for WL-ICLED with the 4-pin production, 1312020030000, 1313210530000, 1315050930002, since there are still some problems driving 6-pin.But the principle are the same.

The soldering methods include using a soldering iron, hot air gun, and soldering station.

1.1 Characteristics of the LEDs

Package Type: All are 4-Pin SMDs – 1313210530000 (Side View SMD), 1312020030000 and 1315050930002 (PLCC4 package). They feature standard pin pitch (typically 2.0-2.5mm, no ultra-fine pitch) and a small number of pins, resulting in moderate soldering difficulty.
Key Sensitivity: LED chips are heat-sensitive (maximum tolerance: ≤260℃ for ≤10 seconds). Pins are prone to oxidation; cold solder joints and bridging must be avoided.

1.2 Pre-Soldering Preparation

PCB Preprocessing: Clean pads with anhydrous ethanol to remove oil and oxide layers. The new PCB is OK, but check first.
Solder Selection: Use lead-free solder wire (0.3-0.5mm diameter) with no-clean flux (reduces soldering temperature and prevents oxidation). Or use solder paste with appropriate character, most of which start from 183 ℃
Tool Calibration: Calibrate the soldering iron/soldering station to 280-320℃; match the hot air gun’s temperature and airflow (to avoid blowing off components). Use solder plate the temperature setting shall be low enough. In this case, 220 ℃ for solder plate and 280℃ for solder iron

2 Solder iron used for 1315050930002

2.1 Soldering Iron Method (Manual Point-to-Point Soldering)

Soldering Steps

Component Positioning: Place the WL-ICLED SMD accurately on the PCB pads, ensuring all 4 pins align with the pads (note the pin orientation of the Side View product 1313210530000 to avoid reverse mounting).
Temporary Fixing: Hold the component with tweezers, dip the soldering iron in a small amount of solder, and solder one pin to temporarily secure the component. Check for misalignment.
Full Soldering: Solder the remaining 3 pins sequentially. Touch both the pin and pad with the iron tip, feed solder wire after 1-2 seconds, and remove the solder wire first, then the iron once the solder uniformly wets the pin-pad junction (forming a smooth solder joint).
Cleaning & Trimming: Use desoldering braid to remove excess solder (preventing bridging) and wipe residual flux with anhydrous ethanol.

Like this, this is photo for capacitor, same to the 1315050930002.

2.2 Short circuit and bug detection

I am too quick in put everything in place. But it frustrated me with the five WL-ICLED black out. It is liable to overtemperature and break the LED with solder iron. I have to remove them all to check one by one.

Before I start to remove them I chech with multimeter, I found out that the Vcc and GND is short-circuited. I guess there may be the short circuit but capacitor. I remove all capacitors and check one by one. Capacitor can withstand high temperature, so it is easy to do it even prolong the heating time.

Yes, it works. The solding for LED is OK, save lots of time for me.

This video shows one bug from software, there are two LED skipped. Only three ones blinks. I shall explain later in next post. That is ineresting foundout. Anyway, solder is Good.

community.element14.com/.../VID20251107103355.mp4

The solder iron is quick and easy to use. Even for smaller parts, that is OK. But temperature control need skill and experience.

Advantages	Disadvantages
1. Low tool cost (affordable soldering irons under $20), low entry barrier – ideal for small-batch production or repairs. 2. Localized heating minimizes thermal shock to the LED chip (chip temperature ≤200℃, reducing damage risk). 3. Easy solder volume control reduces bridging; high soldering precision (simpler for 4-pin components). 4. No complex equipment debugging – suitable for on-site quick soldering.	1. Low efficiency (30-60 seconds per component) – unsuitable for mass production. 2. Skill-dependent; beginners may experience cold solder joints (insufficient heating) or dry joints (poor pad wetting). 3. The Side View product 1313210530000 may have obscured pins due to packaging, requiring angle adjustments for visibility.

Advantages

Disadvantages

1. Low tool cost (affordable soldering irons under $20), low entry barrier – ideal for small-batch production or repairs.

2. Localized heating minimizes thermal shock to the LED chip (chip temperature ≤200℃, reducing damage risk).

3. Easy solder volume control reduces bridging; high soldering precision (simpler for 4-pin components).

4. No complex equipment debugging – suitable for on-site quick soldering.

1. Low efficiency (30-60 seconds per component) – unsuitable for mass production.

2. Skill-dependent; beginners may experience cold solder joints (insufficient heating) or dry joints (poor pad wetting).

3. The Side View product 1313210530000 may have obscured pins due to packaging, requiring angle adjustments for visibility.

I prefer to solder iron in most cases.

3 Solder plate for 1312020030000, 1313210530000

3.1 Solder plate -Soldering Station Method (Temperature-Controlled Platform + Auxiliary Tools – Nearly Professional-Grade Soldering)

It is not difficult to buy one solder plate and solder paste. This is mini-version of solder station, in fact it is just one normal solder plate.

Steps

PCB Fixing: Secure the PCB on the temperature-controlled soldering station with clamps (to prevent movement during heating).
Preheating: Set the soldering station to 220-250℃ to preheat the pad area (ensures uniform heating and reduces temperature differences during soldering).
Solder Paste Application: Apply a small amount of lead-free solder paste (preferrable Sn-Ag-Cu, particle size 20-45μm) to the pads using a stencil or dispenser.
Component Mounting: Place the WL-ICLED SMD accurately on the solder paste with tweezers or a pick-and-place machine.
Heating & Soldering: Raise the station temperature to 280-300℃, hold for 5-8 seconds, and cool to room temperature once the paste melts and wets the pins.
Inspection & Trimming: Inspect solder quality with a magnifying glass (focus on bridging/dry joints) and touch up with a soldering iron if needed.

Since this is small PCB and mini solder plate is enough. Normally steel mesh for LED can be ordered with PCB at the same time. So as to apply the solder paster one time only and evenly without any problems.

In fact, I just dip the solder paste with hand. This lead to low quality in soldering by unevenly distributed solder paster.

3.2 For 1312020030000

Prepare the PCB and apply solder paste, put first capacitor in place.

Position all the 1313210530000 leds,

no need to worry about the precise position. If the paste applied evenly, the melted paste can pull the led in right position in the end.

It is preferrable to finish one LED first to confirm the polarization

as the video shows,

community.element14.com/.../VID20251107112948.mp4

Then put all others in same manner. But things is not always go easy , the middle one(the 3nd ) led is not blinking .

community.element14.com/.../VID20251107123511.mp4

After visual inspection, I find out that there paste is not evenly applied on all four-pin. So, it is pull off original position and off-load one of the pin.

I use simple solution to fix it. Put it on solder plate and heating again and take off the solder plate and cooling the PCB. AND, press the LED in right position on PCB with a tweezer until it cool down.

3.3 For 1313210530000

This is smallest PCB of all six LEDs, and it is side view LED.

I have made a mistake in PCB design. I select wrong model and the arrangement of PIN pad is different. the PIN pad 2 and 3 shall be in opposition side.

Once I appliy solder paste bit by bit and finish routine solder process, the LED is always black.

What a mistake. I do not have enough time to revise the design and order new PCB again.

I have to use one silly step again. apply minimum solder paste and solder 1313210530000 led one by one. As described above, repositoin the LED with tweezer during cooling down.

And finally, all positioned.

And luckly, all work fine.

community.element14.com/.../VID20251107134051.mp4

3.4 A little summary on to and pro

Advantages	Disadvantages
1. Precise temperature control (±5℃ error) minimizes thermal shock to the LED chip – highest soldering yield (≥99%). 2. Extremely high efficiency; supports simultaneous soldering of multiple components (e.g., arrays of WL-ICLEDs) – ideal for mass production. 3. Stable soldering quality; eliminates human error for uniform, durable solder joints with strong long-term reliability. 4. Compatible with all three products (Side View 1313210530000 and PLCC4 packages) – no visibility or heating blind spots.	1. High equipment cost ($200-$1000 for professional stations) – significant initial investment. 2. Requires supporting consumables (solder paste, stencils, clamps) and complex workflows (preheating, temperature control, cooling). 3. Low cost-effectiveness for small-batch production or repairs (time-consuming setup/debugging).

Advantages

Disadvantages

1. Precise temperature control (±5℃ error) minimizes thermal shock to the LED chip – highest soldering yield (≥99%).

2. Extremely high efficiency; supports simultaneous soldering of multiple components (e.g., arrays of WL-ICLEDs) – ideal for mass production.

3. Stable soldering quality; eliminates human error for uniform, durable solder joints with strong long-term reliability.

4. Compatible with all three products (Side View 1313210530000 and PLCC4 packages) – no visibility or heating blind spots.

1. High equipment cost ($200-$1000 for professional stations) – significant initial investment.

2. Requires supporting consumables (solder paste, stencils, clamps) and complex workflows (preheating, temperature control, cooling).

3. Low cost-effectiveness for small-batch production or repairs (time-consuming setup/debugging).

4 Solder method of hot air gun

This is the most popular choice for all. And high efficiency for refurbishment and repair in all situation.

Here is routine for hot air gun heating,

Soldering Steps

Flux Application: Apply a thin layer of flux evenly on the PCB pads (enhances solder fluidity and prevents oxidation).
Component Positioning: Place the WL-ICLED SMD accurately on the pads and hold it with tweezers.
Hot Air Heating: Equip the hot air gun with a dedicated SMD nozzle (5-8mm diameter, matching the 4-pin package). Set the temperature to 300-330℃ and airflow to appropriete levels (tavoid blowing off the component). Hold the nozzle 3-5mm above the component at a 45° angle and heat in a circular motion.
Touch-Up & Trimming: Once the pre-applied solder/paste melts and wets the pins, continue heating for 1-2 seconds, then remove the gun. After cooling to room temperature, check for bridging and clean excess solder with desoldering braid.

While I skip this choice , since

Advantages	Disadvantages
1. Uniform heating solders all pins simultaneously – high efficiency suitable for medium-batch production. 2. Lower skill requirement than a soldering iron.	1. Tool cost something and requires dedicated nozzles. 2. Improper temperature/airflow control may damage the LED chip

5 Comparation of Solder method

Simple suggesion below

Soldering Method	Core Advantages	Applicable Scenarios	Not Recommended For
Soldering Iron	Low cost, simple operation, minimal thermal shock	Small-batch production, repairs, DIY	Mass production, Side View packages
Hot Air Gun	High efficiency, uniform heating, compatible with Side View packages	Medium-batch production, repairing soldering defects	PCBs with nearby thermosensitive components
Soldering Station	Stable quality, high yield, suitable for mass production(Steel mesh needed)	Mass production, high-reliability requirements	Small-batch production, repairs, DIY

6 Some Hints

6.1 Visual inspection is important

Prepare on mini magnifier with near-view illumination. This is view of1313210530000, the IC-chip and RGB leds is easily read out.

6.2 Software matters, demo code shall be used during solder process.

The clock sequence may affect the one-wire WL-ICLED protocol. The 6-pins WL-ICLED equipped with clock pin, it would be more stable.

6.3 Placement of Capacitor can be re-designed in small PCB. In some PCB, not all capacitor is soldered on. But the LED blink GOOD. In one hand, the WL-ICLED is robust in harsh state. On the other hand, not all capacitor is mandatory.

Forum - Recent Threads

Light o'clock - Preface - OUTATIME

Finisher Prize for Light Up Your Life Design Challenge

Arduino Uno Q (2GB)

Power-up and first thought

First Sketch

Bonus: USB Type-C Hub Disassembly

Closing

Runners-up price for Light Up Your Life arrived

RGB MATRIX 3D printing parts arrive

Couldn't continue with my project due to health issues

AuraAlert - Part 6 - Improvement Discussion (Post Deadline)

Fixing the Boost Converter Noise

You should be able to note

Improving the Light Throughput

Sounds Recording

RGB Flashlight: Final Project Summary & Future Plans

RGB Flashlight #03: Soldering Woes

Desk LED Towers - The Demo - RGB for RadiantGoofyBulbs

Main Project Demonstration Video

Demonstration by Removing the Diffuser from LED Tube

List of Blogs

RGB Flashlight #02: Arduino integration attempt / misc planning

AuraAlert - Part 5 - Final PCB Design

Tile-able Wall Hex mounted Design

Wall Mounted Halo Design

Hand Held Device PCB

4th PCB - Hand held device charger

PCB Manufacturing

TXS0108E Issues

Soldering

Testing the PCB's

Build Continues with Mechanicals and Integration - RGB for RadiantGoofyBulbs

Materials and Tools Used

Step 3: Creating Stands/bottom plates Using MDF

Step 4: Cable Assembly

7. Final Assembly and Dry Fit Check

Misaz’s WL-ICLED experiments: Counting LEDs on bus

Next steps

RGB Flashlight #01: The Actual Unboxening (or: Welcome To The Diode-dome)

Single LED test (#2)

Single LED test: color cycle update

Quick setup I used

Code I used

What happened

Video

Next steps and plans

Misaz’s WL-ICLED experiments: Combining LEDs of multiple types

Conclusion

Building Custom LED Bar and Control Unit - RGB for RadiantGoofyBulbs

Materials and Components Used

The Process

Building the Control Unit

Misaz’s WL-ICLED experiments: Mysterious End Frame

N/2 Stop Bits

32 Stop Bits

0 Stop Bits

First refresh, only first LED works

Floating (High-Z) pins at powerup

Searching Internet for Truth about End Frame

Why 0 Stop Bits worked?

Conclusion

Misaz’s WL-ICLED experiments: Testing BI pin

Sponsored Kit Received (#1)

I got the Sponsored Kit

What’s inside the box

My plan (short)

AuraAlert - Part 4 - LED Control, Test PCB Design and Analysis

LED Control using Micro-controller

The PCB Design

The PCB Testing

Board 1: USB PD, Battery Charger and EFuse.

Board 2: Buck Converter and Boost Converter

Board 3: STM32 and LED

Observations

Changes to be Made

Newer Power Budget for LEDs

Misaz’s WL-ICLED experiments: It’s soldering time

Soldering

Misaz’s WL-ICLED experiments: Introduction