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:

lino_periph.jpg

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:

8632111467049373713.PNG

lino_block_complete.jpg

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.

dynamic_power_simplified.jpg

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):

$00.Aa.20.FF.bC.64.00.00#
$00Aa20FFbc640000#
$00AA20FFBC640000#

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:

color_example_lino.JPG
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.