Lino Project: USB tests


The Lino board was correctly made and roughly tested. But now, how can I see how correctly performs? By simply integrating the load (power LEDs) and the PC environment to a complete working system. In this article will be provided a summary of these various steps, just to keep rtace of the progresses.

The test load

The load is made by 4 Glighter-S that are powering as many power LEDs. I grouped them in a proto PCB like in picture below:


These 4 boards are simply connected to the same power line, with 4 control wires that are connected th Lino. Each of their output is connectet to a single LED, with the result of 4 LEDs in total driven singularly by Lino.

The finger test

Now, moving to the board that actually carry the LEDs, I felt the need to change some things. When doing my math, I realized that a small heatsink could work keeping the LEDs cool enough to keep them alive, as you can see here:


This “cool enough” is not enough to pass the so called finger test: this test is considered to be failed if you can’t stand a finger on the heatsink or any surface. If this happens, we are likely more than 65°C, depending on what is it your job, if you are a farmer maybe you have thicker skin and maybe you are sensible to higher temperatures.With this one, we are passing 80°C using my IR thermometer. My finger is definetely hopeless.

Since the heatsink actually shall be touched during the usage and my finger must not be burned, I needed to ovesize the heatsink itself. With a new one, the maximum temperature rise to no more than 60°C, and I extend by 20°C more the ambient operating temperature range of the LEDs:


As you can see, I need to think about the shape of the heatsink and the PCB. But for this test, what’s in the picture is acceptable.

Turn on the board

The board can be driven using the USB/serial or with a single encoder. Herein I will show the serial test, and to generate the correct data pattern to be sent on the board, I wrote a simple Python script to simplify the testing. It uses Python 3+, exploits the pySerial and Tkinter module. Basically the Tkinter lib generates an HTML compatible color code and will be arrangend to an array sent throug the serial line, here emulated on USB. At every complete frame received, Lino will apply instantly the requested color. In other words, when receives the “stop character” described in the Lino protocol.

Here the complete assembled configuration, where the power supply is given from a 9V – 1.5A DC power supply that will be connected to the board.


Let’s connect the DC power jack and the USB to the Lino and to a PC running the Python script demo available here.

Run the script with Python 3.5+ and the following will be opened:


Just type the available COM that appears when you connect the board, a space mark and write the communication speed used by Lino. Press enter and the following appears:


It is in italian, but it is the intuitive and dummy default color table provided by Windows: select the right combination and press OK. Lino automatically displays the colors on the LEDs.

Shades of white

Note that it is implemented a white adjustment computed directly by the Lino’s microcontroller, the white component that controls the white LED it is not generated by the script: when all of the RGBs are greater than zero, there is a bit of white that will be reproduced using the fourth pure white LED, making it more realistic with respect the expectations. In this way I can generate any kind of white light shade. Awesome.

Setting-up the prototype

To set up everything and test it in a more compact way, I thought to use a PVC panel. But at the moment they were missing. So to finish in the same day, I remembered that I have kept a light guide plate from an old LCD panel. I knew that wasn’t trash!

A light guide plate is a panel (in acrylic like material) with some dots that are intercepting the light from the side backlight and redirect, guiding it, it to the LCD, actually rotating the light path by 90° towards the LCD panel:

I didn’t made any photo back when the panel was disassembled, so I googled for one of it. (src:

Then I have realized too late that I could make a photo before cutting the plane, so here is what remains of my panel, already cutted, bended and somehow abused:


Exactly, the old panel was used for all but lighting purposes. In the end, I can put everything in a uglyish case, sticked on the wall like a painting:

A place to keep the prototype: the wall

The video below shows the working system paired with the PC:

When only powered from USB, the firmware derates the total provided power to stay inside the power budget of 2.5W. This video shows the automatic power handler when disconnecting/connecting the main power supply:



Tiny, robust, low cost, fail-safe LED driver: the Glighter-S project

It has been a while since the last LED related article. Was experimented the linear current source, its pros and cons and the field of application. Now arises the need of a small version, handling the same high power, things that are contrapposed in the linear regulator. I need something that I can bring with me, connecting a bit of everywhere, potentially. Heatsinks were expensive, heavy and it is impossible to cover the entire voltage range without huge radiating elements and is also very low efficient. So what I need to do?

A new board design

With the new version, the entire design is completely changed. I moved to a swiched solution, by exploiting an integrated buck converter controller.

A Glighter-S

The core is the Texas Instruments LM3405 buck controller, with a fixed sense resistor directly mouted on PCB. With some tricks, like using an external companion LDO boost voltage regulator, I can provide all the required drive voltage for the LM3405’s internal mosfet over an enormous input voltage range without damage or efficiency loss. More over, the output voltage required can be of any value from almost 0V to the input applied, therefore there is no concerns related to what minimum or maximum LED voltage I can use, matters only the current which the LED can withstand without generating the magic smoke.

The high switching frequency of 1.6MHz of the controller allow also to use small components: in the picture there is a reduced size inductor, mounted on pads designed to carry on the higher ones. This left me some flexibility on performance analysis and experimentation.

Project summary: Glighter-S Power LED driver

  • Technology: switching buck regulator
  • Input voltage: 3V to 20V (note 1)
  • Output voltage (LED Vf): 0.3V to 20V
  • Sourced current: up to 1A (note 2)
  • Size: 32mm x 21mm
  • Efficiency: ~90% (note 3)
  • Operating Temperature: -40°C to 60°C
  • Safety features:
    • Short circuit immune
    • Open circuit immune
    • Safe state (off) when no control is applied
    • Control features:
      • PWM control: voltage swing from <0.4V to >1.8V up to input voltage, max PWM frequency 5kHz
      • Analog control: voltage swing from 0.4V to 1.8V. Outside these limits device is either shut off of fully on.
    • Overtemperature protected
  • It does not make the coffee, but the coffee made this. (note 4)

Note 1: active regulation starts from the forward LED voltage plus 0.6V. Full power is delivered from 4V on (device’s control voltages fully on)
Note 2: can be set by changing a resistor
Note 3:  with one led with a forward voltage of 3V is 83%. 90% can be achived my using more than 3 LEDs in series.
Note 4: with caffeine.

On the back of the board there is a brief indication of what is summarized above:

Back view of the driver


Regarding safety, if the output is shorted, the regulator instantly lower the output voltage avoiding failures. With open circuit, as any buck converter with a sense resistor removed, the output raise as the input voltage due to the broken feedback loop, but with no damage on components: when connecting the LEDs back again, the regulation starts “immediately” avoiding LED damage. Smooth delayed start of few microseconds is implemented when powering the board with the enable already active, to avoid high inrush currents, stressing also less the LED avoiding high current glitches.

It can be dimmed with an analog signal or through a PWM wave up to 5kHz. A greater frequency is just filtered away. Another safety feature is that when PWM pin is left floating or the wire is broken, is equipped with a pulldown in order to guarantee a device shutoff with no misbehaviors. If no control is needed, just connect the PWM pin safely to the input voltage to turn it always on.

Wiring the LEDs

I wanted a very high power LEDs, but with a relatively low voltage, in order to try it also with low voltage batteries, lower than 6V. So I choose an LED with single diode chip, because when power LEDs have an high voltage (usually greater than 5V) is composed with multiple LEDs in series. My choice is a Luxeon Rebel LEDs, with a single diode, no series:

A red LED used with the big fat chip under the silicon lens.

Each of these LEDs can take up to 700mA (1A peak), therefore I chosen the sense resistor on the board in order to achieve 700mA. I designed a board used as a satellite, mouting 4 LEDs, with the peculiarity of handling the thermal management of a global 9W LED lamp.

The LED board (a.k.a. satellite board) is straighforward: 8 pins, 4 anodes and 4 cathodes to drive each LED individually using 2 wires per LED connected to the driver. The A means anode (connect the +), K the cathode (connect the -). Below the RGBW LEDs soldered on the red, green, blue and white position.

Front view if the LED satellite

On the back is mounted an heatsink capable of dissipating through natural convection up to 9W up to 40°C of ambient temperature. Bigger heatsink will extend the temperature range. But here the purpose is to have a small heatsink, and wasting time in my playground.

The back of the board, naked on the left, equipped with the heatsink on the right

Wiring the driver

Here is shown the board connections used to test the LEDs and the driver.


The input voltage was 20V from an old laptop power supply, the enable pin shorted to the 20V. I have connected 4 LEDs in series (one cathode on the next anode and so on), with a total forward voltage of around 12V, which means that in this configuration, the minimum supply voltage required was a bit higher than 12V, here 20V are provided. Since the leds in seried are dropping more than 3V (12V in total), the efficiency of the driver is near the 90%, because the ratio between internal losses and delivered power is lower.

The power absorbed is roughly 9W, I just can’t prove its light due to the exposure of the camera, but it is comparable of a white LED bulb of 10W commercially available.

Light the Light!

Fun fact: these LEDs are also used in some Philips RGB lamps, with a similar thermal design of the PCB. That is somehow encouraging.

The schematics can be downloaded from Github.

Conclusion and next steps

There is no much else to say, but it works and it is a small accomplishment that allows me to play more with power LEDs, more easily than before, mainly because of the possibility to use, NOW, almost any power supply (from tablet’s charger, to laptop ones and any battery lying around).

Every microcontroller can drive these boards with no additional components. The absolute value on the pin have analog effect if inbetween 0.4V and 1.8V, while if lower than 0.4V shut off the driver, and if higher than 1.8v will fully turn on the device. Any board, 5V, 3.3V or 1.8V can drive this module even with a low voltage logic I/O pin or even using an DAC. I plan to continue the improvement, and maybe design a control board in order to control these drivers with a small power low-profile set-up.



Current sources for LEDs – Glighter: a multichannel LED Driver

This is kind of a report of the second attempt in making a power constant current source, high speed, for power LEDs. Taken all the errors made previously, I tried a new linear based current source which should be kept “simple” and “fast”.

Technology adopted so far

I have experimented with power LEDs, how they work and various solutions possible to drive them. With a pseudo evaluation board I tried the very inefficient linear based approach, with the intent of making an high speed driver. As you can read in the previous article there are some troubles that make this kind of circuit everything but not so straight for a rapid DIY approach. On the other side, this journey was very educational to me. The current absorbed per LED (700mA), thermal dimensioning and the LED descriptions are still present in the previous board description, while here I am focused on describing the improvements in this version.

Troubles with the maximum input voltage, offset, mechanical handling and power efficiency have been encoutered and herein somehow fixed with a “new” version. Moreover,  I perfectly know that there is still no input and short circuit protection, as long as various improvements that can be made. But was only the beginning of PCB design, with PTH (plated-through hole), which occupy space and size, so costs. So I said: do not put any capacitor, what could happen? Yeeah, herein I will describe how this choice was something comparable to only an evil genius would do.

Troubleshooting the offset

The main issue on the first version, was related to the offset introduced by the op-amps. Therefore, I need to countermeasure this by injecting some current in the sense resistor. This will lead to some dummy current absorbed by the device, thus the capability to deactivate this functionality. This can be accomplished by using SMD transistors and the proper resistors to inject up to: I = \frac{V_{offset}}{R_{sense}} . Where V_{offset} and R_{sense} are the maximum op-amp offset and the sense resistor. Let’s say 7mV of offset and 0.47Ω resistance, I need to inject at least 15mA. Since the current sink will work between 3.5V and 7V of supply, the minimum resistance to keep 15mA injected to the sense resistor will be aroud 270Ω, as you can see in the schematic. More input voltage, more losses. The enabling capability is achived efficiently by using an N-MOS digitally driven (0-5V), as a low-side switch, since the source voltage will be up to 0.33V, i.e. the maximum op-amp’s reference voltage.

This compensation will lit up the LED a bit lower, since part of the current used forthe compensation will not flow though the LED, but it is not significant on the final test. I have actually used some 330Ω and the result is achieved equally. But at the highest defined voltage here will source up to 20mA, meaning the the regulator will attemp to flow 20mA less in the LED. In picture below, R11 and T6 are the current limiting resistance and the signal MOSFET used to let deactivate this offset compensation, while Q3 is the main MOSFET which source current for the LED. The X6-4 and X5-4 are the connectors of the main board and the “satellite” which mounts the LEDs.



Troubleshooting input voltage range and voltage dropout

Another issue was related to the high value of the sense resistor. This high value was chosen in order to make the system more stable, since the output resistance of the op-amp combine with the MOSFET capacitance, will add a pole. The circuit will be stable if the frequency of the added pole is more than a decade above the circuit’s bandwidth. But I DON’T know the output resistance of the op-amp. Empirically, increasing the efficiency on the sense resistor by reducing the resistor’s value itself and the input voltage, lead to a greater ringing, because reduces the pole frequency. Thus, the system must be slowered down with respect the expectations.


As can be seen in the picture above, the capacitive load (here the main MOSFET) introduces a R_O \cdot C_L pole at f_p frequency in the picture, where C_L and R_O are respectively MOSFET’s input capacitance and op-amp output resistor. At the crossover frequency the closed loop phase w/out compensation is very close to -180° due to the pole contribution. In my circuit, we are at unity gain, therefore in the area labelled as “potentially unstable gains”, that reduces even more the phase margin. Now, with the compensation used in the last design it only rings a bit, improving the situation. In other words, we are practically somewhere between the dashed line (no capacitive load) and the dashed one (capacitive load and unstable control feedback), with a compensation empirically adopted, since the R_O is unknown.

Reducing the input voltage, will bring to the need of reducing also the input control voltage. This reduction has been made by 10 times, so in the board also the voltage divider resistors have been added. Then a buffer placed before this voltage reducer allowing me to not interfere with the resistance divider factor. Reducing the voltage drop on the sense resistor, allow me to power the system with a lot power savings which is not wasted anymore in sensing the current.

The main pain in the amp was to choose a different MOSFET that has a lower theshold voltage, allowing me also to use a lower voltage on the opamp. The choice was on the IRLI630GPbF. Almost 2V of threshold, but big input capacitance. Below the entire schematic:


(Click to enlarge)

Handling and manufacturing

I preferred to desing also a separated satellite PCB which is used to store the LEDs. I wanted to try to make it more compact. In these pictures are shown the main board and the satellite, sent togheter to OSH Park as a single design. In terms of cost, that was not a good idea. I like to call it experience.

(Click to enlarge)


Here the final assembly:

The satellite mounting 4 LEDs, on the back can be spotted the naked aluminum heatsink.
Final assembly of the main board.

Frequency troubleshooting and considerations

The oscillation was even worse, despite the compensation. That’s the evil genius’ choice. I didn’t put any filtering/bulk/tank capacitors. Putting a 100uF one on the main voltage rails, eliminate the oscillation. This let me understand that in my setup I had a lot of wires that are going from the board to the power supply, keyword: RLC oscillator.

The capacitance will likely dump an LC resonance composed by the MOSFET output capacitance and the lead/parasitic/wiring inductance on the supply rails. The frequency that is dumped thanks to the capacitor seems to be around the crossover designed freqeuncy, ~160kHz, not so strange since at crossover we had such stability issues.

But lowering the voltage will trigger again ringing. The answer is in this picture:ciss_vs_vds.PNGReducing the supply voltage to 3.5V will increase the (already fat in its own) input capacitance, Ciss and also the output capacitances of the MOSFET. This reduces the pole frequency combined with the output resistance of the op-amp, tunes the LC filter, and with no proper handling leads to to much instability (see bode plots before).

And here the LEDs powered with a stable conditions. As always, if you think there are errors or suggestions, feel free to comment or contact me.

Glighter: the multichannel LED driver



Current sources for LEDs: firsts DIY impressions

Recently I found that today almost lighbulbs are made with power LEDs. And surprisingly most of them are made so cheap that the controller fails far away before its lifetime. At least for what I’ve experienced with few models. Most of them seems to work well, and I think that LEDs are the future for many more things, more than we imagine nowadays.

This triggered in me the need to start experimenting how difficult is driving with consciousness a power LED system, containing mainly the driver and the LED itself, of course.

Lighting up an LED: what does it means?

Lighting up an LED is simple. Put a resistor in series to achieve a correct current with respect to the supply and the forward voltage of the LED, and voilà, it is light. You can realize that if dimensioning badly these parameters, the LED become hot, leading to change also its colour. Becaming hot, will lower its forward voltage and then more current will flow. As you may realize, this is not ideal when color precision, high power and energy savings are the keyword of a design. An indicator LED (few mW of light) can be designed with a constant voltage, and due to the low energy absorbed, there is an absolute low wasted energy. But relatively speaking, the energy loss is very high.

Let’s consider the circuit below:


The wasted power is always the difference of the voltages between the LED and the supply. So we have that P_{wasted} = I \cdot (6V-V_{led}) and I = \frac {(6V-V_{led})}{R1} . Using a constant voltage generator will not compensate the variations of the forward voltage of the LED, here called V_{led} , which as said before, it is not very constant with temperature, which can vary a lot due to the dissipated power. To avoid variations in luminosity or to avoid overtemperatures, a different kind of circuit is used everywhere, which is a constant current source circuit. The more efficient way is, nowadays, to use a switching regulator, of any type. These circuits can bring average precision, if needed, despite they are quite noisy.

For now a switching regulator is part of the next steps, if making a linear regulator will be successful.

Constant current linear regulator

The most simple linear regulator is made by two transistors. Through the 2.2K resistor is powered the T2, which turn on the LED. The drop on R is senses by T1 which choke the base of T2 on order to keep the current on T2 around to I = \frac{V_{beT2}}{R}.

Generic double transistor’s constant current source

This is fine if one does NOT need high stability over voltage range, considering also that the Vbe are almost the same, therefore given a current required, the resistor cannot be reduced to reduce wasted power. Since T1 is driven in its active region, the stability corresponds to its plot of the collector’s current VS the collector-emitter voltage:aEi4T.gif

A possible and more controllable solution is using the LM78xx in constant current source configuration. The issue is the limited linearity in current, and moreover we cannot change the reference voltage without making strange things, leading to waste a lot more power in sensing the current (dropout cannot be lower that 1.25V in these regulators).

Therefore I have ended up with an initial trial in these drivers by making something more “controlled”.

Linear constant current: the challenge

I need to make something very precise, simple and instructive for myself. I found the classic configuration of a linear current regulator, but using an Operational Amplifier, a MOSFET and shunt resistor. Here is the principle of what I am talking about:


Assuming a sufficient supply for the OpAmp, V1 must be high enough to allow current flowing in Rs so that the current can follow the rule I = \frac{CLK1}{R_S}, where CLK1 is the voltage at + terminal. Now, TWO conditions must be followed:

  1. V1 must be equal or greater than the forward voltage of D1 plus the voltage drop on Rs and the  Vds in linearity of the MOSFET, in worst condition (MOSFET works in saturation region if higher voltage is applied, enabling the analog control of the light, but also higher wasted power).
  2. The voltage drop on Rs must be the voltage on CLK1 pin

The #2 condition is the key of this circuit, and it is the OpAmp purpose. The values and components in the figure are just for reference. The sense resistor substantially determine the minimum voltage applied to the LED: if the resistor need to drop 3.3V, these must be the starting point for the minimum voltage. We are designing a linear current regulator with a “dropout” of 3.3V! It is quite a lot of wasted power: P = 3.3V \cdot I_{LED}. But this is just a trial. Here, we have 3.3V of reference voltage, but reducing the resistance, the voltage can be lowered even more than the canonical 1.25V of an LM78XX regulator.

But here the advantage: I can change the reference in order to reduce the wasted power! And its linearity is order of magnitude higher that the configurations shown above (yes, with the expense to use an op-amp). In the reality I need to slow down my circuit response, because low sense resistor will lead to instability.

The real world: demo boards

I then build a demo board to test the thermal calculus applied on power components (LEDs, MOSFET, Sense Resistors), without any concerns about efficiency: one need first to understand if the main concept works, with the simplest conditions… the roots of the tree! 🙂 To add a bit of fun, I will try to design a setup of 4 LEDs, Red, Green, Blue and White.

Which is the accuracy of the design? The precision is dependant from the op-amp’s offset: a sensed voltage of 3.3V with 9mV offset, bring uncertainty of few hundredths of percent. Then the other main source of error is the sense resistor. Here I used 5% power resistors, so the main error in current stand point can be said to be 5%.

Thermal experiments

I choose the Luxeon Rebel series LEDs, which provides also a public well designed thermal pad for normal 2-layer PCBs. Following the basic rules of thermal design (I should write something about that in the future), I have interfaced an heatsink to a pad, which brings a thermal resistance of 7 °C/W, junction to heatsink, which is from the LED to the top PCB anding to the bottom layer:

A Luxeon Rebel pad design

The design takes in consideration the maximum forward voltage of the LED, and its maximum current. In this design, 4 LEDs are used (Red, Green, Blue, White) and only white have the higher voltage and so the higher power, so the dimensioning is made on the white to achieve the worst case.

A bit of math

The maximum junction temperature allowed is 150°C, reduced to 130°C for reliability. The white LED dissipates up to 2.2W at 700mA. Thermal resistance of the junction to case of LED is 10°C/W for these LEDs. So:

[\Theta_{junction-case} + \Theta_{case-heatsink} + \Theta_{heatsink-ambient}]\cdot P_{LED} = T_j - T_{ambient}     (1)

 Thanks to the thermal pads, the heat is trasferred to the bottom and from that towards to ambient, using an heatsink.  Where Tambient is 40°C, in order to consider the maximum allowed one. Calculus lead to use a 24 °C/W, the used one is 25°C/W, can be unsafe for the LED to work at 40°C, but it is well cooled at 25°C. To stay even more safe in a reasonable way, the power of the LED is assumed to be entirely transformed in heat, while actually only around 60% is wasted, due to efficacy the LED to be around 40% and therefore that quantity of light is transformed in light, and this percentage will vary from one color to another. With this assumption and these LEDs, I can use them at 40°C too with a smaller heatsink.

The remaining power due to overvoltages is absorbed by the MOSFET.Again, Tj will be 130°C. Here, if I decide to power my board with maximum 9V, the drop on the MOSFET will be:

P_{mos} = (9V - V_{led-min} - V_{sense})\cdot 0.7A = 2.5W

And using the (1) only with the junction-to-case resistance, with parameters extracted from the datasheet of the BUZ70 used:

\Theta_{case-ambient} = \frac{T_j - T_a}{P_{mos}} - \Theta_{junction-to-case}

The system will work up to 40°C of ambient temperature, still air. The same happens for the power MOSFET, which is dimensioned to dissipate up to a supply voltage of 9V (my maximum supply allowed) minus the minimum forward voltage between the 4 LEDs, leading to a worst case condition and so higher power dissipated on MOSFET corresponding to lower power dissipated on LED, here is the Red one, which have the lower voltage drop. The MOSFET uses then a simple TO-220 heatsink of 21°C/W. Calculus lead to Θca = 32°C/W, but I had only these larger one at the moment of the test.

Since it is just a proof of concept, the sense resistor drops a very high reference voltage, here 3.3V. Which at 700mA of maximum current, dissipates up to 2.5W. A small vitreous enamelled wirewound power resistor is used.

The PCB design

You can see the schematic of the final system, with different supply rails for op-amp and LEDs, which can be also merged togheter. To feel safe, I’ve added some pulldown resistors, keeping the LEDs off if no signal is applied.


The placement takes into account the dimensions of the heatsink, shown here:


The Luxeon Rebel LED pad used brings the heat down to bottom PCB with 7°C/W of thermal resistance. But how to place the heatsink? I choose a PLCC heatsink and glued to the bottom with a thermal tape. Of course, the bottom must no contain the soldermask, freeing the condutors.

Here the demo board ordered exclusively from OSH Park:

Top view

Nice work, even the tiny 0.25mm vias of thermal pads are made correctly! And here you can see the bottom section with the exposed conductor in which will be mounted the heatsink on it. Note that this solution is adopted since it is a regular FR4 and not an aluminum PCB:


Since I am an evil genius which tries to drive 4 LEDs, I bought 3 heatsinks both for LEDs and MOSFETs. For that reason I will show pictures of only white and separately the RGB test.

First tests

To see the regulation, I probed the signal on the sense resistor. In the real world, this is how my regulator regulates, when applying a 50% duty cycle:

Oscillation in the sensed voltage, means oscillation in the current. Y-axis: 2V/DIV

This beacuse we drive a capacitive load (i.e. the MOSFET gate!), introducing a pole which depends also on the output resistance of the op-amp, reducing the phase margin too much. I have found that my circuit is one of the most unstable systems. By improving the reliability inserting a resistance between opamp and MOSFET’s gate, the oscillation will increases. Such a pain in the amp.

The answer to this problem is to increase the phase margin of the system, and I chose to use a Lead Compensation circuitry, this will reduce the bandwidth of the system to a known value, in my case to around 160 kHz, choosing a values of R and C of 100Ω and 10nF, after a bit of math and trials, not depending anymore from the operational amplifier’s bandwidth. This compensation seems to work, also on various supply ranges, because reducing the Vds will increase the capacitance Ciss, so testing over various suply voltages worth something. Here the smoothed output:

The oscillation is gone!

Still, I did not made any rising time tests, but I will need to. This linear regulator can modulate signals up to 160kHz! Any switching LED regulator do not handle modulating frequencies up to few tens of kHz. Is this useful? It depends: we will see in the next episodes. “Is it more efficient than a linear COTS component?” “No.” “Can be improved to be more efficient?” “Yes.” “When?” “Later.” “How w…” “shut up”.

The thermal pad of LED becomes quite hot, demonstrating that some heat is tranferred. I run the LED for a while, with no damage, I need only to test it in an environment of around 40°C, since this is the temperature at which needs to survive by design. Just for curiosity, I probed the temperature, to make a quantification of the “finger test”, by putting an NTC (did you know how to use it?) as close as possible to the heatsink, fixing the probe with a thermal grease:

The NTC probe fixed with thermal grease and a piece of thermal sellotape.

What is a finger test? When you put your finger on a surface and you can’t stant the finger, it is usually more than 60°C. And here the system set-up to use 3 LEDs:

The set-up for the RGB test. Shame on me for the space and placement organization.

Color power

The white works, I did not made a serious comparison with other light sources, but is visible like almost as a 5W or 6W neon bulb at first approximation. The picture is taken with a partially hidden LED behind the MOSFET heatsink otherwise the camera  will close completely the shutter.


I then discovered that the offset is sufficient to light up dimly the LEDs when they are supposed to be fully off (here you can spot the blue one behind the resistor). Injecting current in sense reistors, to compensate the offset voltage will solve the problem. Must be applied a resistor in order to flow a current at least equal to the current generated by the offset, here I = \frac{V_{off}}{Rsense} . Next versions will take into account this. Here the temporary solution for testing the RGB setup:


Let the light begins! The 5V-3.3V voltage shift is provided through a blob of air soldered resistors placed in the inputs:


Multicolour shadows of my finger projected to a sheet, when generating “white” light.

The red trial:

If roses are red, LEDs are more red.

The LEDs were soldered using an hot air gun, heating from the bottom: the pad is used then as a heating tranferrer for the soldering phase. The Luxeon Rebel LEDs are demonstrated to be strenght enough.

The blue will shows an interesting thing: exposes the fluorescent materials!

Power LEDs start to re-remit light in a different wavelenght, thanks to their fluorescent material (illuminated with normal blue LED).

With an another set of blue LED (here more blue, to be precise I’ve used a Royal Blue when I taken the picture below) I discovered that my small toolbox is somehow fluorescent (the light green one). In the center of the picture, you can see another board disconnected in which the white led seems to emits on its own, while it is just converting back the royal blue to a more sensible and wide wavelenght range, i.e. white, thanks to its covering resin made of fluorescent material.

White LEDs are made by fluorescent materials, and their diode is emitting light in ultraviolet range (illuminated with royal blue LED).

Another LED from a smartphone flash, that re-emits under the Royal Blue:



Little demo

In the video posted here, can be appreciated the variety of shades that can be represented. With a firmware handling 8bits per colour, here can be represented 255 times 255 times 255 colours, i.e. 16,581,375 color shades. Implementing the white, an even more precise white light can be generated (did you mentioned Philips Hue?). For the future improvements, I will release also the code and stuff.

Future improvements

The next version will have the offset compensation, better LED positioning, higher efficiency. The concept works, but now a proper firmware will be developed, strarting from implementing a better script in Python which communicates with the Arduino and selects the colour.

Maybe for efficiency reasons and since I don’t need speed, I will “switch to switching” for future versions. For now, I am satisfied of having touched with hands the “inefficiency” of the linear current sources for LEDs, which is the price to pay if you want precision and, eventually, high bandwidth.

The classic hardware hacking: ATX power supply


If you like playing with lab instruments, enjoy to make things and design electronic stuff, you are probably attracted from the idea of create a new powerful (with some limitations) bench power supply by using an old ATX supply. Moreover, I need an high power supply to test my motors. For sure, building your own (not switching like this one) is possible and far more instructive.


You should follow this and/or other guides related to high voltages only if you know what you are doing. It is also a good thing to know the Ohm’s law and dimensioning a resistor to light up an LED. Remember that inside the PSU there are high voltages, potentially deadly. Despite I’ll not try to manipulate these voltages, the insulation integrity must be kept. Do this hack at your own risk! See also the disclaimer.


Let’s start

Firstly, in case it is not clear, you need to find an old ATX power supply of a PC that you don’t use anymore. Usually it’s always a low cost supply, those that will never reach powers that are mant to be supported. Those sold to be, for example, 300W can output more than 200W nicely, with a lot of voltage combinations but with some drawbacks: without adding some hardware, are neither voltage nor current adjustable. This means that if you short something on your low power PCB, you can destroy it because it will source all its possible current. This is a situation that a bench born power supply will avoid.

TIP: when you buy an ATX power supply of a “generic” chinese sub-brand, apply a security factor of 0.5 when planning the power budget of your PC, usually they can stand a stable current/voltage which is usually far less than what is written.

Then let’s open it and see what’s inside. This one is a “chinese” one, with no EMI filters nor a power factor corrector.  Considering that my version of hacking will have all cables tied inside, that can arise an heat problem which is ignored right now, because can be easily solver later, after the completion of the bench supply.

Here you can see the missing filters, along the uncomfortable soldered fuse:


But never mind, I continue, aware that this power supply can be not compliant with some RF constraints. If the final job is accomplished, I’m are already happy.

I cut out all the connectors and applied as many holes on the chassis as I need (see the bottom of this article). I’ve considered 3 indicators (+5VSB orange LED, 230VAC orange neon lamp and a green Power Good LED indicator). Other holes should be dedicated to the voltages I want to obtain. I used a normal drill, so was quite difficult to obtain the holes. Everyone must sadly arrange with what is present at home. But just rember that there are so many ways to implement your own implementation, and mine can be done more cleverly than what I’ve realized at the end.

Connectors and signals

Since those power regulators are very complex, I’m limiting to check the compliance with the ATX standard and follow that to manage the few control signals. For that same safety reason, this “hacking” does not involve any modification to the original PCB.

The ATX (version 1 and 2) follow the ATX standard to define control signals and some internal regulations. At the can be found the full specification of the connectors that we’re facing to. Mine is version one, you can check by googling or referring to ATX standard to understand what version you have in your hands.


I’ve to identify all common voltages, like +-5V, +-12V, 3V3, COM ecc and cut out the connectors. Then merged all the same voltages togheter. Since the GNDs wires are too much, I’ve split them in two separate threads of wires. I’ve joined the cables with the same voltage and appllied some solder tin to make the pin of merged cable stronger. Then I’ve soldered them to the crimp connector which will be inserted to the back of banana connector that I used (below the crimp is pointed by the black arrow), and closed everything in a thermo shrinking rubber, if the crimp does not already have some “protection”. This gives a mechanical strenght and electrical insulation. It looks not perfect, but it’s very solid and easy to mount. The tin on the bolt has no meaning, as you may see there are few signs of experimentation on alternative fixing leading to melting some plastic, but neglect them.


Remember, depending on what you want to obtain, to keep apart the VIOLET cable (+5VSB), the GREEN and GREY and one +5V RED cable. As one can easily check holding the original connector, those are the voltage of Stand-By, +5VSB, used to power up some peripheral of your PC like the PS2 keyboard, some of USB connectors and the auxiliary functions on the motheboard. See:

atx_connReading the specifications of the ATX, the Green and the Grey are used to provide a digital TTL signal on the PS_ON#, being low to start the supply and can left float, by defined by the standard, to assert it high (if the PSU is designed properly, otherwise you can use a 10KΩ pull-up resistor, here is not needed though), then, when voltages are considered stable, an high TTL signal is readable from the PWR_OK. But if I want to use this signal to light up an LED I need a transistor. Here I will use a switch to turn on the system, which will tie the GREEN cable to GND and I will use a BC337 bjt to receive the OK signal to drive the LED, because the TTL port can sink up to 4mA which are too few to bright an LED correctly. Moreover, since I want to light-up the LED when the signal is high, the TTL port can source a max current of 200uA with a 1KΩ  resistance: a bjt is totally needed.

A FACT: The LED will turn on very dimly without using the BJT, so maybe more than 200uA are provided and the TTL can go lower than 5V. Even using a BJT can absorb more than 200uA to keep the transistor saturated; it could work in the active region, but I don’t like it when it is needed just to visualize the presence of a digital status. Ideally could be a MOSFET, but I’ve no one which works at a signal level. What can I do?

I’ve seen that LED has turn on dimly because there was at least 1mA.  Digging in the circuit, I discovered that this is the output of an LM393 comparator: it can sink only, in other words the logic high signal is provided by a simple pullup resistor.

Once all connections of the schematic below are made “on the air” I’ve closed every thing in the magic shrinking rubber as it’s reported on images below.

One thing on dimensioning the circuit:

The power dissipated by BJT is devised by multiplying the collector current by the voltage drop. Here Ic=15mA (see Icsat formula below) and Vcesat = 0.7V; so P = Ic*Vcesat = 10mW and to be safe we can consider it at least 3 times, P = 30mW. Datasheet says that the TO-92 package can dissipate 200°C/W and provide a graphical representation, with a maximum temperature of 150°C. Yes, at 25°C I can dissipate more than 600mW, but it will burn if you turn off your air conditioner: what are my ranges? 30mW means an increase of 6°C, which means that the power supply can stay lower 144°C. If I will get to that temperature, the problem is somewhere else. So everything is good.

Of course I want to use the BJT in saturation, so to keep the BC337 Vce under the saturation value, I need to provide some high base current. The Vcesat = 0.7 V by datasheet, obtaining a saturation current of Icsat = (5V – 0.7V – 1V)/(220Ω) = 15 mA, where 220Ω is the LED resistor and the LED drops by 1V the voltage. To devise the base current we apply an overdrive factor of 10, obtaining a beta = 100/10 = 10, where saturation beta is 100. This lead to a base resistor of (5 – 0.7)V/1.5mA <= 2533 Ω. The overdrive will cover the BJT approximations. I put a 1.8KΩ resistor in the base, added to the 680Ω already mountend to be the pullup of the comparator.

Good. And in fact, the LED looks pretty bright. A way to think: the current should be limited by the resistor and not limited by the BJT, when used in saturation.  🙂

See images below.


While the monitoring of the +5VSB can be made simply attaching an LED (orange here) to see if is present, just a series resistor is put (allowing some mA, like 10/15mA). But, be aware to create a fork of the Violet cable, since here there is only one wire and we want also to use this voltage as output for the bench supply! As shown below. The arrow indicates the LED connected to the blue cable derived from the violet (see the fork from violet to blue on the left image), and the series resistor is hidden under some shrinking rubber (not visible here).

Due to lack of dimension of holdings dedicated to LEDs (because I used a drill which was not the proper one to be used to make holes on chassis), those LEDs can’t be fixed mechanically in the holes. So I just glue them on the respective holes. You can now insert the banana connectors in the other holes and screw in the bolt to keep the crimp connector (the one indicated before with the black arrow) strongly attached to the back of banana ones. I also directly connected to the 230VAC an orange neon bulb to see always if there is AC line inserted. Insulated with a proper not home-made holder.

Things to keep in mind

Oh yes! There is a remaining one +5V cable. This is used to power up some dummy resistors. If you search in the web, you can find the general advice to use a load resistor of 5W or 10W of 10Ω. I’m not always agree with that.

Depending on the power supply used, you may need to power a dummy load to the 12V or 3.3V. Usually for old ATX power supply like mine the 5V should be loaded. Here I’m referring to this voltage, but situation can vary with other PSUs.

The resistor is used to let flow some current from the +5V rail and close the loop of voltage regulation feedback, which is applied the the +5V also to regulate the other rails (3V3, 12V ecc). Since I don’t want to waste energy and generate uselss heat in the resistor, I measured the stability and the absolute value of voltages by varying the resistor. I came up with a minimum current which is arount 100mA that seems sufficient to keep the supply stable. So I used 4 resistors of about 38Ω to obtain a final equivalent resistor of the same value but able to support twice the power of the single component (2 series pair of resistors, each with a parallel of two single resistors). I also check by removing the PCB if the grounding was directly connected to the chassis and it is. So the chassis screws can be used to close the circuit. The space is precious here. Also, the resistors are not quite hot, so it’s ok. The white tape in the picture has insulation purposes, underneath wires are soldered, of course.


Final result

I put some effort to keep the airflow as clean as possible, the heatsink on the left has also a couple of wings that are bended to not touch cables too heavily. For now, seems that there are no heating issues. All voltages are good  enough excepts for negative ones: could be my fault, but they were few mV under the nominal value also when the power supply was used in a real PC, prior to any modification. The technical reason is that this power supply is a crappy one. The whole result is posted here below.




A clever thing could be use the hole on the front to hold the switch. I didn’t, I’ve complicated my life uselessly, cutting a piece of metal (the one on the relief) to give a shape on the space where the switch slides, because the rectangular shaped hole was not perfect at all. But holes for screws were quite nice and the switch is fixed strongly on the chassis.

What I’ve learned

As you may notice, I wanted to have a power supply which was blue. So I spent a week trying to painting it and learning all steps to achieve a durable paint on a metal chassis. I’ve also tried to paint some letters on the top to make them visible inside the blue main paint, just for experimenting some painting techniques. I used the primer to allow me use the spray can to cover the whole chassis with this blue that you can see. And it’s not perfect at all the whole result. But I’ve never painted a chassis before and I feel satisfied.

The whole hacking, at the end, has taught me basics about painting. Yes, agree, WTF! 🙂

Blink an LED over the internet: the begginer’s low level approach


In this article we continue our road to the IoT approached at a low level, or better, at bottom-up approach, that will be applied in the future to my UART interpreter. Here I will talk about how to drive an LED over the Internet. So as always I’m using Python libraries to get things done safely, quickly, but also make them useful under the knowledge point of view. So, if you are trying to do similar things, this can be an article that is not completely useless. And remember, if you can blink an LED, you can do whatever you want… This is the “Hello World!” of the basic IoT. Maybe even less.

But be aware, there are a lot of guides that allow you to do the job quickly. You are reading this because I am developing an hardware platform which works differently from most of ready-to-go solutions, and I usually need to develop my own application and if something become useful, I write about that, like in this article.

Let’s start

As a starting point, you have to understand what you need. Here, since I don’t have any ethernet/wifi adapter to be used by an MCU and considering that I may need some calculus power, I used the well trusted RaspberryPi B. I set it up with a basic Raspbian distro and configured it to use a static IP address local to my LAN. Forwarding the traffic from outside is made by the router connected to the internet.

If you start from scratch and don’t have the DHCP disabled and the RPi doesn’t have a fixed IP, you can connect it to the LAN and observe by looking at the router at what address is connected to. Then to access to the board once you know the IP, you should have the ssh daemon running, this is the default normally. In Windows, I use PuTTY to access to it.

Once entered in our RaspberryPi at its new address, we set a static IPv4 address (note that in the so called “IoT” stuff the IPv6 should be used, but for now it is not a big problem) to avoid checking the IP every times. Open the file /etc/network/interfaces, it should look like this:

auto lo
iface lo inet loopback
#uncomment to change loop address
#address <address>
#netmask <address>

auto eth0
iface eth0 inet static
#uncomment for use RPi as router
#network <address>
#broadcast <address>

where iface eth0 inet static matters, because in this way we assign a static local IP address w/out using the DHCP of the router. Remember to set the IP accordingly to the gateway, where in this case represents the address of my router. The netmask should be identical.

Restart the network typing on the console:

sudo /etc/init.d/networking restart

and may not work, in that case simply reboot the RPi. Now, every time you boot the Raspberry and connect it to the router, it should always have the address that you have choosen, in this example is the

The scripts

As usually, I wrote a script that should run on the RaspberryPi, called server and another client that you can run on whatever PC, smartphone which can interpret python commands. Those are derived from the same functions described in this article, and with a new one, fine_data(), to refine the data received by cutting out the number of byte attached at the head of the string prior to send the data. Be aware that the server implemented is not working like a real server, it is capable to handle only one connection at a time, because my application because I want it. It’s a kind of  be-or-not-to-be-server. Otherwise, the basic concept is that you need to put the server.accept() call in a loop and exploit multithreading. That is why servers are needing high parallelism and memory to allow parallel execution, instead of single thread performances.

Both scripts uses an infinite loop to interpret the data, and the client send to server whatever command is inserted from the user. The server itself should verifiy the command and decide what to do. So what’s new, now, is in the server, where thanks to the library GPIO, prepare and drive one pin of the RaspberryPi. Depending on what is received from client, the pin 3 of the RaspberryPi (in my case is model B, rev 2) can be set to high or low. The server reasponds to client according to the action taken with the send_sck(clientsocket, msg).

Something like this:

while 1:
cmd = 0
mex = receive_sck(clientsocket) # lettura comandi veri
mex = fine_data(mex)
print(&amp;amp;amp;quot;Incoming data from client: &amp;amp;amp;quot; + mex)
if mex=='on':
msg = 'Led ON.'
msg = msg_len(msg)
send_sck(clientsocket, msg)
cmd = 1
GPIO.output(3, 1)
if mex=='off':
msg = 'Led OFF.'
msg = msg_len(msg)
send_sck(clientsocket, msg)
cmd = 1
GPIO.output(3, 0)

if mex=='q':
#print(&amp;amp;amp;quot;Incoming data from client: &amp;amp;amp;quot; + mex)
msg = &amp;amp;amp;quot;Server ended. Stay rock.&amp;amp;amp;quot;
cmd = 1
msg = msg_len(msg)
send_sck(clientsocket, msg)
GPIO.output(3, 0)
print(&amp;amp;amp;quot;Uncorrect format received&amp;amp;amp;quot;)

if cmd == 0: # is still zero
msg = 'Unrecognized command.'
msg = msg_len(msg)
send_sck(clientsocket, msg)

print(&amp;amp;amp;quot;Server connection closed.&amp;amp;amp;quot;)

Note that this GPIO library “simply” interacts with hardware control registers of the BCM2835 by accessing the file /dev/mem, and since it is a system file you must run the server script as a root. In the server script you should locate the line below and set the address and port like this

server.bind(('', 8000))

while in the client

client.connect(('', 8000))

The server should have the internal LAN address. The internal port, 8000 in this case, is the one used inside the LAN by the server. At the moment in which you decide to access from outside, you should open a port (can be different if you want) on the router allowing it to redirect the packets toward the internal address:port, here For this capability, refer to your specific router manual. About the port, an high number (> 1024) usually do not provides standard services, so often conflicts are not encoutered.

The client.connect() must use the address of your ISP provider if you are outside the LAN, and the proper port opened on your router previously. Here are the same because I’m using the scripts inside my LAN, so no redirect is needed. Note that you can’t test the correctness of forwarding from inside the same LAN where the server resides. If you are in the same LAN, you can instead connect to localhost and run both scripts on the same machine.
There are tons of guides on emulate a free static public IP and I don’t want to load too much this presentation. And since I’ve not tried this method in first person, I will skip the static IP tricks for now.

You can download the scripts and start playing with them. I’ve remained quite short in descriptions because I want to arrive at the next part. 🙂
If you have questions, you can ask them in the comments, of course!

And finally…

The final result is a LED which is on whenever I write “on” and viceversa if “off”. Connect using an SSH connection to the board and start the script “” by typing

sudo python3

because I wrote it in Python3. If there is an error about an already used port:

[Errno : 98] Message Address already in use

it’s normal, maybe there is an open connection or if you are already ran the script, maybe the client has not closed the connection. In that case you can change the port: after few minutes that previous port will became again available.

I remotely driven the GPIO 3 (SCL) pin. Be careful to follow the guidelines  to avoid to ruin the SoC pins, and remember that those pins can output up to 50mA. See image below:

The setup is very trivial, just the GPIO 3 with a series resistor connected to the LED. This useless picture is posted “just for fun”. 🙂

ledThe server script has a console allowing to understand what is going on, while the client works as always in a console style. Whenever the LED is in the wanted state, the server confirm that by printing on screen. The use of the screen can be avoided if not needed, because the response message is sent to the client, as you can see.

serverThe client, for now, requires the user intervention, so the screen is needed to allow writing commands in console, as below.