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:



Lino Project

I am playing with LEDs for few month and during that time some little projects were born, but now I need a system to handle the logical part and the power distribution. I simply just can’t use an Arduino board, or any other development board: I need a proper power handling embedded in a small space, all in one PCB, with some particularly high power requirements. And being Arduino compatible. This is Lino.

It will be used to power up the Glighter-S modules in a compact fashion, finally reaching something similar to a complete lighting working system. What is important here, is that we have 255 combination per each color, plus an algorithm to emulate in RGB and pure white combination to generate pastel colors or shades of white. With such assumption, I do not use any LUT but instead I generate the color according to the HTML encoding executed on the Lino microcontroller.

Project purpose and board review

This board is designed to power up any power LED, motor and/or anything which requires up to 10W and can be controlled in PWM. Lino supports in hardware the control through physical, glitch filtered, inputs like buttons and encoders.

In the picture below is shown the board with its main interfaces:


More protocols are supported onboard, like I2C and UART (real or through USB emulation). With the proper firmware running on Lino, terminal commands are supported using the serial protocol, connected with the Atmega (the main MCU) mainly in two ways: with USB through an emulated terminal, or directly with the microcontroller’s UART, supporting then any communication with a serial device, like the ESP8266 and with no additional circuitry, since everything is working at 3.3V.

Since this board can communicate using UART or I2C, this setup is scalable, making it capable to drive more Lino boards connected with each other.

Board characteristics: the union of Atmel and Microchip in practice

Here is shown the main blocks of the board. It is a kind of celebration of the acquisition of Atmel from Microchip. It is used an Atmega328P microcontroller and the Microchip MCP2200 USB to Serial converter instead of the FTDI, which instead would costs truly a lot.

Below, the block diagram of the project and a picture which shows where physically things were arranged on the board:



Everything is almost self-explaining. Briefly, the HMI (Human-Machine Interface) can support a single Encoder with an integrated button to minimize the commands and user interface complexity, but with firmware mods can be anything else.

The controller core is the Atmega328P, which is used to keep an Arduino compatibility. With the low cost and well supported Microchip MCP2200 I can obtain a neat working system interfaced with any PC or serial device: in fact I have also a pure serial connector, with 3.3V voltage swings. For example it can talk with the famous ESP8266 with no additional circuitry.

A bit of more explanation is instead necessary for clarify the power handling.

Dynamic power source selection

The backbone of this system is the dynamic power handling. When powered from an external supply, up to 10W can be provided to the load, while can be still controlled from the USB port. If this supply is not present, is still possible to drive the board using the USB power, which allows up to 2.5W.

The selection is performed by the MCU (green dashed line in pictuire below), while a default safe state is kept when the MCU is not driving the switch. All the voltages are monitored, in order to allow the firmware to make the right selection. The priority of the source selection is given to the external power source.


The USB power is limited, since this board can be used directly connected to a PC, able to provide, normally, no more than 2.5W per USB port. Therefore, to use the entire power capability, an external power supply shall be used.

Due to the extremely high input voltage range, the power source selection is achieved in the firmware while the hardware is fully protected against misbehaviours and short circuits. After all, it is a personal project and burning a board is tedious and I can’t afford this, prevention is better. As also in professional environments, anyway.

Below just a brief of the supply characteristics:

Electrical characteristics Min Max
Input voltage 3.3V 20V
Maximum supported power (USB only) 2.5W
Maximum supported power (Power Jack) 10W
Maximum supported power (Power Jack + USB) 10W

Source selection logics

The main power supply shall be capable to provide the total power required from the load. If this supply voltage is above the minimum required of around 3V, Lino is powered up and will source from the main supply. If the USB is present, the MCU can chose from where source the power. If the main supply is lower than 3V and the USB is present and the USB is present, the power is absorbed from the USB cable, otherwise the voltage would be insufficient.

Since the USB it is used to exchange the USB Data, it is usually connected to a device that cannot provide more than 500mA per USB port, therefore the power delivered to the load shall be reduced down to 2.5W using the firmware (in this particular case, by reducing the duty cycle of the PWM which drives the load).

The “Lino protocol” – Board demo interface

To have the board working, I setup a simple protocol used over the serial, but other physical line can be used, like I2C. I need to master even complex variations of the PWM sequence, also in a scalable way. For this reason I needed a proper protocol, with expansion potential, to open the possibilities to develop a proper higher level application in a simple way on a PC or any master controller side.

Moreover, as it will be explained, the data handled by this protocol is conceived to be developer friendly, where the developer is someone who will generate a proper software to achieve the desired data exchanged. It is not perfect, but it works.

Physical Layer

It consist in an array of 18 bytes sent from a master PC or device (over serial/USB) made by the following sequence, from the first to the last byte sent, MSB to LSB:

[StartChar] [CTRL#00] [CTRL#01] [R#0] [R#1] [G#0] [G#1] [B#0] [B#1] [W#0] [W#1] [INT#0] [INT#1] [RES#00] [RES#01] [RES#10] [RES#11] [EndChar]

Where each byte is represented from LSB to MSB, the data is sent using UART (8 bits, 1 Start + 1 Stop bits, no parity), but can be transferred using any other simple protocol (I2C, SPI ecc).

Serial voltage levels swings are on 0V-3.3V.

Data handling

The values inserted by the application or the user through the terminal are written in ASCII, but representing an hex format coded to save bytes. In other words, if the sender wants to send the value 254(decimal) to Lino, it will send the chars “F”(character) and “E”(character) or “f”(character) and “e”(character) on text terminal, representing the intention to send the 0xFE hex value. The first char sent is the MSB of the hex number; how each bit is transmitted is no more concerned here, but hidden in the physical layer described before, handled in UART. The chars sent are corresponding to ASCII codes, so on the serial lines are physically sent, in this example, the ASCII “70”(decimal) (for letter f)+”69″(decimal) for letter e.

On the board is made all the conversion reversed to actually compose the number 254. To ease the software front-end, the serial is completely case insensitive and look only for characters that can represent the hex numvers, so any character sent outside the range “0” to “9” and from “a” (or “A”) to “f” (or “F”) can be used in the firmware for synchronization, or can be discarded at run time but used by the user when sending data manually over the terminal for testing purposes.

Here below is listed the meaning of each byte:

  1. StartChar: the char used to discriminate a begin of transmission after startup, or a StopChar, after a timeout or any subsequent StartChar in case of line issues
  2. CTRL#00/#01: The combination of characters reserved for any auxiliary command. #00 is the MSB, #01 the LSB.
  3. R#0/#1: channel Red data (from 0 to 0xFF). #0 is the MSB, #1 the LSB.
  4. G#0/#1: channel Green data (from 0 to 0xFF). #0 is the MSB, #1 the LSB.
  5. B#0/#1: channel Blue data (from 0 to 0xFF). #0 is the MSB, #1 the LSB.
  6. W#0/#1: channel White data (from 0 to 0xFF). #0 is the MSB, #1 the LSB.
  7. INT#0/#1: intensity which is applied to the RGBW channels (from 0 to 0x64 [100% in decimal]). #0 is the MSB, #1 the LSB.
  8. RES#00/#01: reserved byte for any further necessity. #00 is the MSB, #01 the LSB.
  9. RES#10/#11: reserved byte for any further necessity. #10 is the MSB, #11 the LSB.
  10. EndChar: the char used to end the transmission and call the command interpreter on the receiver (Lino).

Each group of byte (numbered as #0#1, #00#01, #10#11) can be divided using a mark char (here the “.”, a dot) to make it more human readable the text on a terminal emulator, when debugging, testing and so on. These chars will enlarge the data transmission because it is a data overhead, but on the receiver side are completely invisible since are discarded, at run time.

These 3 examples can be actually copied in a terminal and sent as a text on Lino, moreover, these three commands are equivalent (colors are used to identified the fields):


In which:
– start char “$”
– the CTRL field is CTRL#00 = 0, CTRL#01 = 0
– the R field is R#0 = 0xA, R#1 = 0xA
– the G field is G#0 = 0x2, G#1 = 0x0
– the B field is B#0 = 0xF, B#1 = 0xF
– the W field is W#0 = 0xB, W#1 = 0xC
– the INT field is INT#0 = 0x6, INT#1 = 0x4
– the RES field is RES#00 = 0x0, RES#01 = 0x0, RES#10 = 0x0, RES#11 = 0x0
– stop char “#”

The colors are therefore represented adopting the HTML color compatibility 24bit coded. As example, the above frame will represent the following color:

at maximum intensity, and the additional pure white set to 87% to make the white component more realistic.

Next steps

The next steps will be the usage of such board to control Glighter-S modules, but for now the hardware test is sufficient to proove that the system works, the MCU, the protocol and the serial too. More details will be provided as soon as a final release will be tested, and the protocol can be tested also more deeply in all its potential.

To be more precise, will be setup a prototyping system with Lino and 4 Glighter-S. These will be controlled by the already present initial firmware release running on Lino, and a Python script which generates the correct sequences according to a color selection made on a PC connected to Lino. All the test loads are designed in Glighter-S project page.



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.



PWM and I2C libraries

clangI needed a flexible square waveform generator to test the behavior of a mosfet. I have in my hand a board with a PIC18 microcontroller (, so I wrote few lines of code for it. Of course, things are degenerated and I have been infected by the developer fever and is born the desire of reuse them without always opening the data-sheet. So a barely complete set of runtime variables which can be used in the provided functions has been implemented, which can be useful in a general purpose environment; only the more improbable settings, according to my opinion, are kept static with the need of recompiling libraries, if are changed.

So, in GitHub button below there are functions for all the capture/compare modules of the PIC18F47J53, but are very similar if needed to be expanded for other PIC18/xx microcontrollers. I wrote them to be compatible with the XC8 (link) compiler. The source files are timers.c and capturecompare.c with their relative haders. pwm.h is particular since simply combines the previous sources in a more elegant way.
The use is pretty straightforward, requires only to know the allowable range of variables or the implemented defines. The compiler automatically implement in memory only the functions used, but if it is not the case, a proper set of #defines is adopted, one per hardware module present on the MCU. A good requirement is to know the block diagram of the module used, in order to see the correspondences with the software, and reading the README for everything else.

I’ve put also  the first version of the I2C, since I wrote them for the DS Emulator… why not writing them in order to be reused again?

Click to follow on GitHub:github_logo

For sure I will implement the same libraries for the enhanced modules, which are still needed for my little dumb projects. Happy coding!

An UART interpreter – sneak peek

mainbrdIn a hot summer of a couple of years ago, trying to not thinking about the stifling heat of the afternoon, I put some efforts in a system which should drive a set of motors and peripherals by means of a single serial line. The idea consists in creating a sort of instruction set, sent over the serial, to transmit and receive informations, but the main effort was to develop this under a robust software, to make the system rensonsive and interrupt driven, fully aknowledged to keep trace of errors also.

This project is born following these ideas, on order of development:

  • Driving a low level peripheral using a console, with an affordable and error tolerant firmware
  • HW separated by SW, being able to design them finely and independently
  • Being able to drive the HW on any type of PCs
  • Expliting any software that can handle strings, the only specification is to know the language of the console
  • As a natural consequence, a PC connected on the Internet can drive the HW remotely

The main idea

In order to do this, I thought to a concept made of a two stages of control: the microcontroller receive commands from the user and put them in action. But the user of the microcontroller could be another board or PC, not necessarily a human generated commands. This, as previoulsy said, can be made through a console.

In this way the microcontroller carries an “interpreter” which translate commands to the hardware. By this mechanism I split a single action in a confined memory and execution time, affordable and in a responsive way. Due to this software “modularity” it is possible to extend indefinitely the instructions that the micro can interpret and use all of its calculus power to control precisely the hardware desired or manage the instructions in a robust way. The MCU is then only a front-end of the system which receive and sent signals from/to external world. By using a coherent language, the device can communicate with other peripherals (like a PC) by using the serial, and being driven by them directly.

The abstraction layer

The user only see a console over the serial, which work so vaguely similar to the Python line interpreter. But commands are simple, being able to be generated by a software running on another machine which send them to the console. And are simple because this project is at a very early stage. 🙂

Here the user of the console can implement all the algorithms, writing them down to the MCU generated command prompt. With this machanism we already have an abstraction to blink an LED over the Internet, or driving a robotic arm, nothing change inside the MCU. The abstraction give the possibility to personalize the behavior of the device and save in a text file on the PC without the need of reprogramming the chip. Also, but this is not structured yet, can be possible to save this content on an EEPROM or whatever memory support can be reached by the microcontroller, when the console is not directly accessible.

So, anyone can control the device directly or through a PC algorithm. The power of the idea is that if I want to drive a robotic arm, I have sufficient abstraction to drive it directly from another location, making this MCU implementation very suitable for remote control and environment analisys.

At this stage of the project, the software running on an internet connected device is written in the multi-platform Python language, due to its versatility. It reads the console and write commands to it. But here the console is just an echo taken from the microcontroller, elaborated by the Python based SW and printed on the screen. What is important, the user can not know anything of the hardware of the MCU, being free to think to the optimum driving algorithm.

Are also implemented 2 buttons where each control a device bypassing the physical serial console. But due to the modularity of the firmware, when a button is pressed, it is not activated a signal inside the MCU, but there is an auto-generated internal command sent back to the console, by parameter passing without using the USART module. By means of this mechanism, all controls are the same, the code remains modular and there are no performance losses.

A pretty stupid image is shown here, just to make the idea. The light green is what is done inside the MCU, while the light orange shows the basic algorithm of the PC. Between these two colors, there is an USART wrapper, but can be implemented on other technologies, like SPI, I2C, whatever isola supported on the MCU side.


I almost forget an analogy: we can think about a client-server structure. Here, the server is the MCU while the client the Phython based PC software. I like thinking to the old fashioned gerarchy of the computer terminals, a dumb terminal that send commands on a mainframe. But here the terminal is not so dumb compared to those in 1960.

Some specifications

I almost forget to talk about the core. Its based on a 8-bit PIC18F47J53 microcontroller, which can handle  very efficiently two levels of interrupts priority. Here I can give more priority to the USART commands instead of those on board, or viceversa, depending on what I desire. For example, when I press a button and I want to be interrupted by the serial, I can put the serial receiving interrupt up in priority. The project was previously born on an Atmega328P by using Avrdude and AVR Studio 6, but then ported on this PIC using XC8 and MPLAB-X, due to better hardware specifications.

Moreover, and I will talk about that on next article, on the MCU board there are two buttons and here are configured to work efficiently like a joystick. The ADC samples a value of voltage on a potentiometer and can set the intensity of the command.

The software on PC is Python based and uses the Pyserial library.


And now?

Now as soon as I can find some time to put something on more than a breadboard and when the Python based terminal is presentable (keep in mind what “presentable” means for an electronic student…), I will put something more that a bare useless presentation. I will also put the sources and I will explain better what is going on, trying to be helpful to who want to play with this stuff.

On the next article, I’ll try to explain how to control a motor by using an opposite phase PWM modulation, allowing the analog control of a motor. This can be done also without an MCU, by using only one 555. I’ll see what implementation I will adopt.

Nevertheless, this opposite phase PWM method can be integrated very well with this UART intepreter project: one can drive the motor manually and then an algorithm can decide if that speed must be kept, and so take the control over the device. Yes, I will decisely talk about that in the first release of this project. I will play with the 555 another time…
But I’m afraid that I’ll not find so much time to setup a proper sensor and data acquisition. So, I need to organize myself on order to find time, and this is not a good news.