Category Archives: Intel Galileo

LED Helmet V1a – Project update

I am still waiting on the Mega modules, ordered last week. Not sure what the postage hold up is. In the meantime, I managed to get the Galileo Gen1 to work!! So many bugs and wrong turns on this device.

●The firmware update instructions are very unclear…the device must have NO sd card inserted and then booted up with the usb port plugged in. It then comes up as a serial.port for the firmware update to work.

●To my surprise, i ran the latest IOT image, the same one used on the Gen2 board. It worked…with bugs..

●SPI functionality via MRAA is non existent on the Gen1. Even with the lastest 7.3 mraa moduke. The clock signal on my scope was garbage! Very disapointing

●SPI via arduino sketches is also flaky, at a setting of 8mhz i was only able to get around 2-3mhz clock before it skewed into noise

On a whim i ended up trying the pi-spi nodejs module and it worked at 3mhz!!! But when i rebooted i got noise on the spi pins…hours later i realised that if I ran an arduino sketch that uses spi before hand, spi was usable again…so i wrote an arduino sketch that initialised the spi and did nothing else…at boot time the sketch starts and about 10 seconds later the xdk daemon launches the main.js script…and bam!!!

Wow Suit build update

The plan is to have the suit ready for public display on July 18th for the Robot Party that is part of the Gertrude Street Projection Festival. Here is a build update:

Power System
I have ordered 4 new battery modules for the suit. They should arrive this week. Wiring for the power system has been completed and will need to be laid out on the suit material and stuck on. Ill start work on the power module carriers this week but this is the last piece of the puzzle to go in.

Memory Instability in Intels MRAA SPI Implementation
I have heard back from Intel, and have been given an updated mraa library build. Its a huge improvement but its not 100% there. They think the problem may be with Nodes engine on the Galileo. As suggested, I will be trying some manual garbage collection in my software.

Intel Galileo replacement
I have ordered an Intel Edison board just in case this memory problem is unsolvable. I am actually hoping on using the Edison instead of the Galileo in the future as its smaller, cheaper, faster, has built in WiFi and uses 5V.

The 10 meters I originally ordered were not enough, so i got another 10 meters.Arrived today, and if I work really hard should be able to have all the modules build by the end of this week.

Wow Suit Software Status Update


Spreadsheets are super handy for this kind of work. Its a kind of Meta pixel mapping and It saves me a TON of time. I have so far created a full class for the Wow Suits LED matrix. It includes 3 major blocks of data

  • pixelGrid: An array containing the pixel map. This is a 40 x 64 item array of 3 byte blocks (7,600 bytes). All rendering and processing is done directly to this block of data. its the bitmap representation of the suits LEDs
  • LEDs: An array containing n (number of LEDs in the suit) number of bytes x 4, 1 start frame of 4 bytes, set to 0,  and 1 end frame of 4 bytes, set to 255. Each LED block has a start byte, which contains brightness data for that LED, and 3 bytes each representing Red, Green & Blue. This is the data block that is sent out to the suit via SPI (7,688 Bytes)
  • rowMap: An array containing a map of physical addresses of each LED relative to its position on the suit. This is a 40 x 64 item array of 1 short Integer (5,120 bytes). This is used to find out the physical ID of an LED in the real LED data block, LEDs that is sent out via SPI to the  suit

I have created a full set of functions to set up the data structures, render horizontal and vertical lines of any given length, and a smooth dimmer function for frame blending.

On another note, I have received the MIC IN audio modules I was waiting on from eBay…

 wpid-20150625_143657-1.jpg  I really hope to utilize this and make the suit and masks audio responsive.


Driving an LED Strip with SPI

Driving Chart for the WS28XX series ICs

WS2811 ws2811 0
0.5μs H
2.0μs L1
1.2μs H
1.3μs LReset Time
Above 50μs
 WS2812B  ws2811 0
0.40μs H
0.85μs L1
0.85μs H
0.40μs LReset Time
Above 50μs

Because I would like to use the Galileo, I’m limited in not being able to use the FastLED library, as its intended for AVR.  One approach is to use SPI at a very high frequency, and send whole Byte sequences to imitate a tight timing sequence for the above:

For the WS2811 1 bit is transmitted in 2.5μs. So if We set up an SPI driver to push out the 8 bit number 255 , 11111111 in binary, at 400khz


Now as a whole pulse that’s useless to us. Because we need to pulse a HIGH and LOW in a specific pattern. To do this, we can mimic the signal by increasing the SPI frequency and sending in BYTES with specific patterns. For example If we double the frequency to 800Khz we can now send in 2 bytes in the same time frame. So if we send in a 255 and a 0:


We get the above. Which is almost to a point where we can start making up masks. In the above example each BYTE, that’s 8 bits, takes 1.25μs to transmit, and looks like a continuous HIGH signal for that amount of time. This means that each BIT takes 1.25μs/8 = 0.15625μs to transmit…


To get a correctly timed pulse for the WS2811 we will need to adjust a few things. 1st we need to find out a nice round number for each Bit to sent out at.  We need to be able to add multiple bits transmition time together to get exactly 1.2μs and 1.3μs. As well as 0.5μs and 2μs. For example…

Time Required for 1 Bit to Transmit = 0.1μs

Time required for 1Byte = 0.8μs

At 1,250,000Hz a single Byte takes 0.8μs to transmit and a Single bit takes 0.1μs to transmit. So…


Above we transmitted 4Bytes over SPI [255,240,0,0] to get a Logic 1

ws2911spiex5And here we transmitted 4Bytes over SPI [248,0,0,0] to get Logic 0

What this means is that we have to transmit 4 Bytes for each BIT in a standard Byte of representation Data. If I have to control 1 LED i need 3 bytes to control Red, Green and Blue. That means I need:

3bytes x 8bits x 4spi-block-bytes = 96Bytes per LED!!!! With my current suit layout that has 288 RGB LEDs, I need 864 Bytes of control data. With the Above protocol, ill need 27,648 Bytes per FRAME….Now what I’m getting at here is that Using SPI to control these drivers is probably not a great idea. It will take 22.1184 milliseconds per frame which is at best around 5 frames per second.

My other concern is that the Galileo probably wont allow such tight control over the SPI frequency. I will be able to set it at 1mhz and 2mhz but not anywhere in between with any kind of certainty. I spent some time on my oscilloscope last night to see if the SPI frequency actually changes in between MHz but saw no difference unless the change was significant .

Here is the same diagrams but using the WS2812B timing, which is the same as the WS2811 but using the double data rate:

Set SPI to 2,500,000Hz Use 4SPI Bytes per LED BYTE:

To send  Logic 1 you send [255,255,128,0]

ws2812sendhighTo send Logic 0 you send [255,0,0,0]


I can confirm that the 144LED strips uses fast mode… This was sent ot me directly from WorldSemi

“The 144LED Strip uses the WS2812B chipset(built-in IC), and HIGH speed mode”

Their Web page states they use the WS2811 chip but they also say that they use High Speed  mode in prepackaged systems… Using High Speed mode I can get maybe 10 frames per second with the same number of LEDs.

Here is some NodeJS code I wrote that will grab an array of Bytes and create a Buffer() of bytes with the appropriate bit pattern to be pushed out to the SPI bus.

var ledBytes = 1*3;
var ledBar = new Array(ledBytes);
var aBuffer = new Buffer(0);
var counter = 0;


function init()
 //clear the led array

function runMain()
 var testBuffer = WS2811b_SPI();
 for(counter=0; counter<testBuffer.length; counter++)
 console.log("Index "+counter+"->"+testBuffer[counter]);

function WS2811b_SPI()
 var spiBuffer = new Buffer(ledBytes*8*4);
 var currentByteSPIBlock = new Buffer(8*4);
 var spiBufferIndex = 0;
 for(counter=0; counter<ledBytes; counter++)
 currentByteSPIBlock = createSPIBlockFromByte(ledBar[counter]);
 return spiBuffer;

function createSPIBlockFromByte(dataToPush)
 var mask=1, bitResult=0, cnt=0, bufferIndex=0; 
 var tempBuffer = new Buffer(4*8);
 var spiBlock = new Buffer(4);
 mask = mask << 7; 
 for(cnt=0; cnt<8; cnt++) 
 bitResult = dataToPush & mask; 
 bitResult = bitResult >> (7-cnt); 
 spiBlock = createSPIBit(bitResult);
 mask = mask >> 1; 
 return tempBuffer;

function createSPIBit(value)
 var spiBitBlock = new Buffer(4);
 spiBitBlock[0] = 255;
 spiBitBlock[1] = 255;
 spiBitBlock[2] = 128;
 spiBitBlock[3] = 0;
 spiBitBlock[0] = 255;
 spiBitBlock[1] = 0;
 spiBitBlock[2] = 0;
 spiBitBlock[3] = 0;
 return spiBitBlock;

function clearSuit()
 for(counter=0; counter<ledBytes; counter++)
 ledBar[counter] = 0;

Galileo GEN2 Javascript shiftOut() function progress



I used the MRAA library to get a pretty good rate out of  the GEN2 Galileo. Above is 8 Bits being latched via the clock pin. I made a VERY hacky bit-bang function that pushes out data to the WS2803. And success.

Below is a video of a fully working shiftOut() function written in JS for the Galileo GEN2, driving the suit

Ta Da! Im running a simple test program I developed to test a single WS2803 chip and its working as intended .

Now onto integrating the HTTP server via NodeJS and interactivity here we come



Intel Galileo GEN 2 roadtests


I accidentally purchased a GEN 2 Board 2 weeks back. It was advertised on ebay as an un-used but packaged opened GEN1 Board. So i bought it as a backup for my current project and to test some more razor edge stuff, so I wouldn’t blow my live one. This came to me as both a good and bad surprise. I actually wanted to get a GEN 2 board because Intel improved all the things i hated about the GEN 1 board. But i also needed a quick swap in backup for my project….and boy did Intel do a number on us all!

Things I really like:

  • Networking “Just Works” even the WIFI module was simple as plug in and boot!
  • Both the Standard Dev image (click here to download it) and the IOT image worked out of the box
  • They boot up system was unchanged and it booted up just as fast as the GEN 1
  • Same form factor and size as the GEN1
  • Packaging came with the power supply….
  • NodeJS works natively…with some tinkering
  • There is a pretty good IDE called the Intel XDK IOT edition which lets you create NodeJS projects, upload, debug etc…

Things I REALLY hated:

  • Power….the main power supply has changed from 5v to 7.5-12v! WHY??? This makes portable devices so much more annoying to power.
  • The GEN1 serial port, which was strange on its own, has been replaced by an even stranger 6 pin FTDI connector. You need to buy your own $15 serial to USB module and a special one, as no other standard ones work. You need to get the TTL-232R-3V3 . This is super annoying. They took out 1 chip from the board, and made the user pay for it externally

I’m yet to test out how the pins speed work in Node JS. If i can create working WS2803 Driver in Node, I will be super happy!

I had some luck getting a simple web server to accept POST data and action it by outputting a PWM signal to the pins..This was quick! which I’m happy with. This is one of the main reasons i would like to ditch the Arduino code. The HTTP server instance is too slow to be usable in a real time input system

Lightsuit – Standalone Galileo Version

After some major modifications to the code, I have some relatively good results….I have a relatively stable driver. I’m using the Galileo board on it own and the OUTPUT_FAST option. Strangely, my previous attempt at using this method failed. The data was somehow corrupted as it was pushed out on the data bus of the drivers. I then attempted using the OUTPUT_FASTMODE(which actual doesnt exists but uses a different method to write to pins 2 and 3 fastGpioDigitalWriteDestructive()… Anyway onto the results…. Here is a video of..

  • shiftOut using fastGpioDigitalWriteDestructive()
  • shiftOut using fastGpioDigitalWrite()

As you can see, these are NOT the results we want. I initially thought the problem was related to the size of data i was pushing onto the bus. We have 864 Bytes to push out. Strangely when i reduced this to 18 Bytes, enough to drive 1 row, i saw that 1 row get pushed up the serial ladder…and get garbled up after the 1st push. So i changed my write method back to the standard digitalWrite(), however i initialized the data and clock pins as OUTPUT_FAST….

As you can see, these are exactly the results we want!!! I can still see glitches every now again but they seem to be very fast and get wiped out. My thoughts are that the 2 fast IO pins 2 and 3, get wonky when driven at their super speed rates. I have seen multiple people online hook these up to their Oscilloscopes and show that the waves are not at all constant or smooth. I would love to get my hands on a Rev 2 board and see if these is any kind of improvement…but in reality I’m hesitant to waste money on it as I’m thoroughly disappointed with the Rev 1 board.

Achievement Unlocked !

imageOk some major progress today!

  • I have written my own implementation of the shiftOut() function to he drive the WS2308 LED drivers. Its a little buggy…seems to take 3 drives to work for some reason, but I am still working on it
  • I have been able to drive the suit with only the Galileo and a client device!!! No mode NodeJS bridge server and no more arduino. AND NO MORE SERIAL problems!

The above pic is an interactive drawing made from the client interface


Controller Prototype

I realized early on that the Arduino was not going to be a good candidate for controlling animation sequences. Its a great drive system however. My 1st idea was to use a TI-83 or similar calculator to send it animation frames…but interfacing the calculator with an Arduino is a little cumbersome. So I’m going to use a WiFi enable Arduino, or easier still the Intel Galileo Board(if it can sent serial data quickly enough..this is to be tested)

The actual nity-gritty of animation data is going to be rendered by a web browser, a phone or a tablet..


This is my 1st prototype. Where ever you touch, the cell(LED) is set to a random RGB value. The entire frame is then dimmed to BLACK (0,0,0) by a background process and each frame is sent as a string of 864 Bytes to the Arduino which is then intern sent to the drivers.

Above is just a prototype controller, something to render the frame bytes and send them. The end product is super flexi!