09/09/2016 at 20:38 •
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 in the project links. 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:
- (src: geek.com)
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:
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:
06/25/2016 at 18:06 •
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.
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.
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.
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:
- 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
- CTRL#00/#01: The combination of characters reserved for any auxiliary command. #00 is the MSB, #01 the LSB.
- R#0/#1: channel Red data (from 0 to 0xFF). #0 is the MSB, #1 the LSB.
- G#0/#1: channel Green data (from 0 to 0xFF). #0 is the MSB, #1 the LSB.
- B#0/#1: channel Blue data (from 0 to 0xFF). #0 is the MSB, #1 the LSB.
- W#0/#1: channel White data (from 0 to 0xFF). #0 is the MSB, #1 the LSB.
- 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.
- RES#00/#01: reserved byte for any further necessity. #00 is the MSB, #01 the LSB.
- RES#10/#11: reserved byte for any further necessity. #10 is the MSB, #11 the LSB.
- 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:
- 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.