Interfacing a TFT_320QVT LCD/Touchscreen/SD to a Teensy 3.0

I’m working on a project which needs a touchscreen LCD. After searching eBay for a while, I noticed that many vendors were selling basically the same 3.2″ 320×240 TFT with resistive touchscreen and SD card reader. Though there were slight variations in the silkscreens, they all had the same model number – TFT_320QVT. I bought mine from digitalzone88 for $12.29. TK0466-1-digitalzone88 TK0466-4-digitalzone88 The board uses a SSD1289 LCD driver IC, and runs on 3.3V. The 3.3V voltage is incompatible with the typical Arduino, which runs at 5V (some vendors have created shields to interface it to an Arduino Mega). However, I purchased the TFT_320QVT with the intention of interfacing it to a Teensy 3.0, which runs at 3.3V. I noticed that there were not enough through-hole I/O pins on Teensy 3.0 to simultaneously interface to the LCD, touchscreen, and SD card. This necessitated the usage of the Teensy 3.0’s additional I/O pins, accessible only via solder pads on its underside: teensy3b To facilitate access to the 14 solder pads, I attached some header pins to piece of stripboard, and soldered 40AWG wire-wrap wire to between the pads and headers: extenderThe Teensy 3.0 runs on PJRC’s specially modified version of Arduino – Teensyduino. The task was to find compatible Arduino libraries. First order of business was the LCD. I searched the web, and found that dawnmist had spent a considerable effort in modifying Henning Karlson’s UTFT to work with the Teensy 3.0. Unbeknownst to me at the time, dawnmist’s modified UTFT is actually bundled with Teensyduino!

Next, was to get the touch screen working. It turns out that the current version of Henning Karlson’s UTouch is compatible with the Teensy 3.0.

For the SD slot, I tried the version of the Arduino SD library that’s bundled with Teensyduino. Unfortunately, though the SD library works with the TFT_320QVT’s SD reader, it stops working if you instantiate a UTFT object in the sketch. I tried sdfatlib, and found that not only does it work w/ the Teensy 3.0, but it coexists fine with UTFT. The only catch I found is that it works only with SPI_HALF_SPEED. When I set it to SPI_FULL_SPEED, it stops working.

Here is the Teensy 3.0 running UTFT‘s demo sketch on the TFT_320QVT: utft

Below is the step-by-step procedure to getting the TFT_320QVT up and running with Teensy 3.0:

Step 1: Install the libraries

1. UTFT: Run the Teensyduino installer, and when the Libraries to Install dialog is displayed, check the box next to UTFT in the Choose Additional Libraries to Install combobox. (Note: Henning Karlson’s latest UTFT also works with Teensy 3.0, but my discussion below will show how to interface to the UTFT that’s bundled with Teensyduino 1.18).

2. UTouch: Download UTouch.rar. Use WinRar or 7-zip to extract the enclosed UTouch folder. From the Arduino IDE pull-down menu, use Sketch->Import Library->Add Library… to install the extracted UTouch folder. Alternatively, you can just copy Utouch/ to your arduinosketchbook/libraries directory.

3. sdfatlib: Download the latest version of sdfatlib. From the Arduino IDE pull-down menu, use Sketch->Import Library->Add Library… to install the downloaded file. You can alternatively just extract the SdFat/ folder into your arduinosketchbook/libraries directory.

Step 2: Wire it up

1. LCD: dawnmist‘s modified UTFT library that’s bundled with Teensyduino has a configuration file: arduinofolder\libraries\UTFT\hardware\arm\HW_Teensy3.h. Inside HW_Teensy3.h, there are 3 options for the LCD pin assignments: USE_B_D_PORTS, USE_C_D_PORTS, and USE_USER_PORTS. By default, the file has


enabled. USE_B_D_PORTS gives the best performance when your sketch needs to use SPI (which is needed for the SD card slot). USE_C_D_PORTS gives the fastest performance, but is incompatible with SPI. USE_USER_PORTS allows you to configure arbitrary pins (by changing the DB_0-DB_16 #defines), but results in the slowest performance. I elected to use the default USE_B_D_PORTS setting.

2. SD card reader: The SD card reader works via SPI, so it needs to use SD_DIN->DIN (MOSI – 11), SD_DO->DOUT (MISO – 12), SD_CLK->SCK (13), and one of the chip select pins, CS0-CS4 (10,9,20,21, or 15). I chose to use SD_CS->CS4 (15).

3. Touchscreen: The touchscreen uses 5 pins, T_DIN/T_DO,T_CS/T_CLK/T_IRQ, which can be assigned to any arbitrary free GPIO pins.

Below is a chart of my pin assignments:

Teensy_pin = TFT_320QVT_pin
0 = LCD_DB4
1 = LCD_DB5
2 = LCD_DB8
3 = LCD_LED_A (backlight)
5 = LCD_DB15
6 = LCD_DB12
7 = LCD_DB10
8 = LCD_DB11
11 = SD_DIN (MOSI)
12 = SD_DO (MISO)
13 = SD_CLK (SCK)
14 = LCD_DB9
15 = SD_CS
16 = LCD_DB0
17 = LCD_DB1
18 = LCD_DB3
19 = LCD_DB2
20 = LCD_DB13
21 = LCD_DB14
22 = LCD_WR
23 = LCD_RS
24 = T_CLK
25 = LCD_DB7
26 = T_CS
27 = T_DIN
28 = T_DO
29 = T_IRQ
32 = LCD_DB6

LCD_RD needs to be pulled up to 3.3v

I have created a sketch, UTFT_UTouch_SdFat_teensy3, that simultaneously demonstrates the LCD, touchscreen, and SD card by modifying the UTouch demo sketch. Below are the lines which are critical to configuring it to work with the above pin connections:
[code language=”c”]
#include <UTFT.h>
#include <UTouch.h>
#include <SdFat.h>

// bitmap file to load as background.
// must be 320×240 and in format output by ImageConverter565
char bkgRaw[] = "ade.raw";

uint8_t sdCS = 15; // SD_CS – chip select
SdFat sd;
SdFile inFile;

uint8_t lcdRS = 23;
uint8_t lcdWR = 22;
uint8_t lcdCS = 4;
uint8_t lcdReset = 9;
uint8_t lcdBacklight = 3; // must be a PWM pin for variable brightness
uint8_t lcdBacklightBrightness = 255; // 0-255
UTFT myGLCD(SSD1289, lcdRS, lcdWR, lcdCS, lcdReset);

// Initialize touchscreen
uint8_t t_Clk = 24;
uint8_t t_CS = 26;
uint8_t t_DIn = 27;
uint8_t t_DOut = 28;
uint8_t t_IRQ = 29;
UTouch myTouch(t_Clk, t_CS, t_DIn, t_DOut, t_IRQ);

The file displays a bitmap, ade.raw, as the background. Before running the sketch, copy ade.raw to a FAT-formatted SD card, and insert it into the TFT_320QVT’s SD card slot.

You can also substitute your own bitmap file. To create a .raw file, first create a 240×320 pixel jpg, png, or GIF file. Run it through either imageconverter565.exe (bundled with UTFT) or the online ImageConverter 565 make sure to select Convert to .raw file and Target Platform Arduino (AVR).

Here’s what UTFT_UTouch_SdFat_teensy3 looks like when it’s running:

Many thanks to dawnmist, and the others who figured out how to get UTFT working with the Teensy 3.0.


I obtained much of the information I needed from these pages:
dawnmist – screen working … finally
Teensy 3.0 – driving an SSD1289 with utft

Arduino IDE suddenly freezing up? Here’s how to fix it.

Every once in a while, my Arduino IDE suddenly takes forever to launch, sticking at the splash screen for a long time. Even after it launches, it’s still basically unusable, because the pull-down menus also freeze up, and take an eternity to respond. It happens to me every time I download a new Arduino IDE, which is so infrequent that repeatedly forget why it happens, and how to fix it. After ripping my hair out for a while, I start googling until I find the fix.

If you’re experiencing this problem running Arduino on Microsoft Windows, chances are, you have a virtual serial port from a Bluetooth SPP device installed in your system. The problem is that the Arduino IDE is trying to enumerate your system’s serial ports in order to locate the attached Arduino devices, and the code takes a long time to timeout. Luckily, user eried in the Arduino forums figured out what was happening, and posted a fix in the thread: Road to solve the delay in Arduino IDE. He has graciously come up with a workaround, and shared it with us.

The fix is easy. Simply download his rar file, extract his new rxtxSerial.dll, and replace the version that’s currently in the same directory where your arduino.exe resides. I’ve also attached a zip archive of the file below, for those people who don’t want to install WinRAR in order to get the new rxtxSerial.dll. Thanks, eried!


Noritake 24×6 Character VFD Module

I’ve always thought VFDs were pretty cool. They used to be the rage in high end consumer electronics. Back in the mid 70’s, I built a VFD alarm clock. Recently, I got my hands on a modern VFD module to play with. The Noritake-itron SCK-Y100-24063-N14 is a very flexible 24×6 character VFD module in the same form factor of a 20×4 character LCD module. It is a member of Noritake’s CU-Y series VFDs.



  • 5V supply voltage
  • serial (asynchronous and synchronous) and 8-bit parallel communication
  • CMOS signal and RS-232 (+-15V) voltage compatible
  • jumper-selectable baud rate: 9600, 19200, 38400(default), 115200.
  • extensive built-in character sets: USA, European, Japanese (Katakana only), Multilingual – various fonts and symbols, Canadian and French, Nordic, WPC1252 – european fonts and symbols, Cyrillic, Latin, Portuguese, PC858 – european fonts and symbols
  • adjustable brightness
  • locally selectable brightness for highlighting (useful for implementing menus)
  • double width, and double width & height characters

The video below compares the Noritake 26×6 VFD to a 20×4 LCD. The characters are noticeably smaller on the VFD due to the higher density, but still quite readable.

This page shows some of the versatility of the Noritake VFD: Versatile Character Display CU-Y Series

The VFD comes pre-configured to operate in async serial mode at 38400 baud. It isn’t necessary to use a UART to talk to the VFD; any GPIO pins will suffice. A minimum of 2 pins are needed, for SIN (input) and SBUSY (output). A third GPIO pin can be connected to RESET (input). I hooked mine up to an Arduino UNO as follows:

D2 -> SIN

Here’s what it looks like from the front, running Noritake’s Arduino menu demo:


The lower contrast on the left side of the photo is due to my camera’s reflection – the glass is very reflective. Note the highlighting via localized variations in brightness. Here’s what it looks like with a blue filter on top (again, apologies for the reflections – it actually looks a lot better than this photo):


Though my photos are crap, the display is quite easy to read indoors. I wouldn’t recommend it for outdoor use, however, or anywhere that you expect direct sunlight.

Back view:


The 10-pin  jumper block on the top center is used for configuration, and the 14-pin jumper block on the bottom right is used only for parallel mode.

The writing speed of this VFD is very fast. Running in async serial mode on an Arduino UNO at 38400 baud, I was able to output 120 characters in a mere 38ms, which is about 3x faster than LiquidTWI2 can muster, even after the I2C bus is tweaked (and over 100x faster than LiquidTWI2 w/o I2C bus frequency tweaking). Unfortunately, Noritake’s Arduino library doesn’t compile on a Teensy 3.x, because it contains AVR assembly code in a timing function, and calls _delay_us(), which isn’t implemented on the Teensy 3.x. On the other hand, it should not be hard to replace these two functions. To use the Noritake VFD with Arduino, first download the Arduino code library. From the Arduino IDE’s pull-down menu, use Sketch->Import Library…->Add Library... to import Include the following headers into your sketch:

[code language=”c”]
#include <CUY_Interface.h>
#include <CUY_Serial_Async.h>
#include <Noritake_VFD_CUY.h>

Two classes need to be instantiated:

[code language=”c”]
CUY_Serial_Async interface(38400,2, 3, 4); // SIN,BUSY,RESET
Noritake_VFD_CUY vfd;

Here is what initialization looks like:

[code language=”c”]
void setup() {
delay(500); // wait for device to power up
vfd.begin(24, 4); // 24×4 character module
vfd.interface(interface); // select which interface to use
vfd.CUY_init(); // initialize the module

Note that Noritake chose to implement only partial compatibility with the LiquidCrystal library.  So while vfd.print(s) is supported, vfd.setCursor(x,y) is not; one has to instead call vfd.CUY_setCursor(x,y). The Noritake_VFD_CUY class methods are declared in Noritake_VFD_CUY.h. Noritake includes a few sample sketches, which you can access from Arduino’s menu via File->Examples->CUY.

Noritake also provides a handy host program, which lets you configure and test the display without a microcontroller.


To use the program, connect the VFD to a PC running Microsoft Windows via a Serial->USB adapter, such as an FTDI cable. Using the Serial->USB adapter opens up the possibility of using the VFD  as a USB auxilliary display for a PC.

The Noritake SCK-Y100-24063-N14 is a very cool device, and I’m looking forward to building a project with it.

Resource Links

SCK-Y100-24063-N14 Overview 
CU-Y: Y-Series Evaluation Software
Code Library
Arduino Library with examples
Sample C++ code and configuration/hookup
How to use custom fonts
How to use the built-in font tables
How to use the font magnification command
How to create a menu using the highlight effect

LeafCAN v2 Firmware in Alpha Test

I have been working on v2 of the LeafCAN firmware, which adds a whole slew of new screens, selectable via a rotary encoder.  The rotary encoder is connected to the AD0/1/2 pins on the expansion header of the LeafCAN V2 hardware.  The code is currently in alpha testing, and is available in the development branch of the LeafCAN github repository.  Be aware that the development branch is for my bleeding edge code, and at any time, the code there may be broken, as I continually checkpoint my code.  I will move it to the master branch when it’s ready to be released.

While I was developing the LeafCAN v2 firmware, I received a pleasant surprise in the mail from Barbouri (GregC) of the MyNissanLeaf forum.  He designed a PCB with 16×2 OLED display + RGB Led Rotary Encoder support,


and sent me a completely assembled and tested rig.  I immediately added support for this new hardware variant into my working LeafCAN v2 firmware code.  The RGB knob is cool:


but I am still pondering how best to use it. Currently, I have it blue when the car is idle, red when it’s consuming power, and green during regen.
Below is an overview of LeafCAN v2Alpha3. The various screens are selected by rotating the encoder knob. Some of the screens have different modes, selected via a press of the encoder knob. The first screen is the familiar info screen from LeafCAN v1.3:


The top line from left to right is: kWh remaining/gids/fixed fuel bars, and the bottom line is: pack voltage/SOC%/instantaneous kW. The next screen is an idea lifted from Turbo3’s WattsLeft, the DTE (distance to event) screen:


The top line shows various miles/kWh values, 2.0/3.0/4.0/5.0/6.0, and bottom line shows the distance in miles to the event, in this case, Low Battery.  Pressing the encoder button switches it to miles until Very Low Battery:


and pressing the button a third time shows miles until Turtle:


Thanks to a breakthrough in active can sampling, spearheaded by GregH and TickTock, I was able to implement the following new screens. The first one has on the top line, High Precision State of Charge (SOC)%.  The bottom line shows State of Charge (Ah), and possibly a Battery Health %.


The next screen shows the 4 battery pack temperature sensors:


The units are selectable between Celcius and Fahrenheit with a press of the button. Finally, the last screen shows the minimum and maximum cell-pair voltages in mV, as well as their difference:


When an OLED is installed, the display now blanks after 5 sec of inactivity on the CAN bus. Pressing and holding the knob for a second wakes the display up for 5 sec.  When an LCD is installed, the press/hold turns on the backlight for 5 sec, instead.

I will be working towards finishing LeafCAN v2.0 in the coming weeks, and will announce its release here.

Barbouri and I are also collaborating on a dual-CAN bus version of the LeafCAN hardware, which will be able to monitor the Car-CAN as well as the EV-CAN on the Nissan Leaf. This will open up access to various information which is accessible only via the Car-CAN, such as friction brake actuation, steering angle, etc.

I would also like to point out that GregH has yet another cool Leaf CAN bus dash display in the works (only $80) that is worth checking out. Also, TickTock and garygid are working on the very fancy dual-touchscreen open-source CANary Project. Turbo3 has also figured out how to extract data from the Leaf Car-CAN using a cheap ELM-327 clone dongle and an Android phone. There is currently a flurry of CAN bus hacking on the Leaf.

UCTronics 3.2″ TFT LCD Arduino Shield with Touchscreen

Updated 2014-03-14

I’ve been looking for a way to add a touchscreen UI to my projects.  To this end, I purchased a UCTronics 3.2″ TFT LCD Arduino Shield.  Most of the cheap TFT touchscreens that I found need about 38 pins, and therefore, need to interface with an Arduino Mega.  What makes this UCTronics shield unique is that it uses an onboard latch to convert the onboard SSD1289 TFT driver data bus from 16-bits to 8-bits.  This allows it to connect to an Arduino Duemilanove or UNO.  The board I received is a RevB board, and it looks somewhat different from the board pictured in the UCTronics product description.  The resistive touch panel on top of the TFT very similar to the touch panel used in the Nintendo DS.  Below is the board running UTFT’s demo (UTFT_Demo_320x240):


When I purchased this display, I had to use a specially modified version of UTFT downloaded from UCTronics: This is because at the time, UTFT only supported the SSD1289 in 16-bit mode. However, as of 2014/14/03, the shield now works with the official UTFT distribution. The key is to supply the correct parameters to the UTFT constructor:

[code lang=”c”]

UTFT myGLCD(SSD1289_8,A1,A2,A0,A3);


SSD1289_8 specifies that we’re using an SSD1289 controller in 8-bit mode. The rest of the parameters are the pin assignments.

When compiling for an Arduino Duemilanove or UNO, the IDE will complain that the sketch is too big, unless you comment out all of the #define DISABLE_xxx except for #define DISABLE_SSD1289 in UTFT’s memorysaver.h.

While UCTronics’ version of UTFT comes preconfigured, it is based on an older version of UTFT, which is slower. On my Duemilanove, the UTFT_Demo_320x240 sketch takes 57.7 sec to execute with UCTronics’ UTFT, and 48.6 sec with the official UTFT library.  This is mainly because the latest UTFT has a new function called _fast_fill_8(), which speeds up certain fills. However, the sketches built with the newer UTFT library are bigger. With UCTronics’ UTFT, UTFT_Demo_320x240 compiles to 27248 bytes, and 30092 bytes with official UTFT.

Here is a bottom view of the shield:


At right is the integrated micro SD card reader, which is handy for storing bitmap data to load into the screen.

UCTronics supplies ArduCAM_Touch to support the touchscreen. However, I decided to just use UTouch, instead. Below is the UTouch_ButtonTest example sketch:


To use UTouch, you must configure the following lines in the sketch:

[code lang=”c”]
UTFT myGLCD(SSD1289_8,A1,A2,A0,A3);
UTouch myTouch(13,10,11,12,9);

I was able to operate the buttons by pressing firmly with my fingers. Note that the touchscreen is resistive, not capacitive, so it works by pressure. A stylus gives you considerably more control. The touchscreen is very similar to the one found in a Nintendo DS.

At first, I was disappointed by the bitmap display.  This is the output of the UTFT_Read_BMP demo sketch supplied by UCTronics:


There is severe quantization of the colors. This is the way due to the way that UCTronics implemented the UTFT::dispBitmap() function in their modified UTFT library. I wrote my own function, dispRaw(), to instead display .raw files generated by UTFT’s ImageConverter 565:

[code language=”c”]
// display a raw bitmap that was processed with ImageConverter565

#include <UTFT.h>
#include <SD.h>
#include <Wire.h>

#define SD_CS 8

//UTFT(byte model, int RS, int WR,int CS,int RD)
UTFT myGLCD(SSD1289_8,A1,A2,A0,A3);

void dispRaw(UTFT *utft,File inFile)
char VH,VL;
int i,j = 0;
cbi(utft->P_CS, utft->B_CS);
for(i = 0; i < 320; i++)
for(j = 0; j < 240; j++) {
VL =;
VH =;
sbi(utft->P_CS, utft->B_CS);

void setup()
if (SD.begin(SD_CS))
char VH,VL;
File inFile;
inFile ="ade.raw",FILE_READ);
if (! inFile)
while (1); //if file does not exsit, stop here.

void loop(){}

The output looks a lot better:


The display is actually much higher quality than the photo above.  The photo contains screening and moire patterns that you don’t see with the naked eye.  To create a RAW file, first create a 240×320 pixel jpg,png, or GIF file.  Run it through either imageconverter565.exe or the online ImageConverter 565 make sure to select Convert to .raw file and Target Platform Arduino (AVR). Copy it to a FAT-formatted uSD card, and insert it into the uSD slot.

It takes about 6 seconds to load a fullscreen RAW file. I’m think the bottleneck is the reading of the data from the SD card. Clearing the screen takes almost 1 second. The speed is acceptable when running UTFT_Demo_240x320.  This is board is no speed demon, but the speed seems adequate for implementing a graphic touchscreen control panel. If you need a fast display, look elsewhere.


User Guide
UCTronics Customized UTFT library


EKitsZone UNO Rev.3 First Look

I recently decided to buy an Arduino UNO R3, to test compatibility with my sketches, which I have been testing w/ a Deumilanove.  The UNO R3 contains an ATmega16U2  instead of an FTDI chip to do the serial to USB conversion, as well as 3 extra pins on the digital side of the board: SCL/SDA/AREF.  One thing I don’t like about the Arduino UNO is that while it uses a 16MHz crystal for the 16U2, the main 328P MCU runs on a resonator, which is not as accurate.  I found the EKitsZone UNO Rev.3 on eBay for $14.99, and decided to give it a try.

unor3The notable differences in the EKitsZone Rev.3 versus the Arduino UNO R3 are:

  1. the ATmega328P uses a 16MHz crystal oscillator instead of a resonator, so its timing is just as accurate as a Deumilanove
  2. the reset button is mounted at a right angle, so it’s easily accessible even when a shield is attached on top
  3. it uses a mini-USB connector instead of a full-sized one
  4. the JP2 pins aren’t filled with solder, so it’s easier to solder in headers, should you want to connect something the PB4..PB7 pins on the 16U2
  5. the programming header for the 16U2 isn’t installed, but it’s easy to solder one in

I see 1-4 as advantages.  Plus, the board is a cool looking red color.

Build Ganzfeld-style Photic Goggles (AVS Lightframes)

Building upon my passive Ganzfeld goggles, I decided to build a set of Ganzfeld-style lightframes for photic brain stimulation.  I was inspired by the goggles which come with the very expensive Laxman mind machine:


Typical lightframes which come with audio-visual stimulation (AVS) mind machines use point source LEDs, such as this pair which came with my MindPlace Sirius mind machine:


I covered the basics of how to construct such goggles in a previous article: Build an Audio Player Based Mind Machine Part 1: Photic Goggles

Even the RGB “ganzframes” which come with the MindPlace Procyon mind machine are rather feeble, consisting of point source SMT LEDs, covered by a simple roughened square of translucent plastic… the effect is only mildly diffuse, and still looks like a cluster of point sources.  Inspired by Michael Rule’s hallucinogenic goggles project, I modified his goggles design to my tastes, and built a monochrome replacement for my Sirius lightframes.

Parts for this project:



  • wiring harness from cheap headphones (a pair of earbuds from your local 99 cent store are a good donor)
  • 2 LEDs – I chose white LEDs
  • a ping-pong ball – I already sliced it in half in the photo.  Using the seam as a guide, cut it in half with a very sharp x-acto knife
  • passive ganzfeld goggles prepared as described in my previous article:  Relax Your Mind: Build Your Own Ganzfeld Goggles

If you your LEDs are of the clear point-source variety, it’s a good idea to scuff them up a bit with to make them more diffuse. You don’t have to do the whole LED.  Rubbing the tip with sandpaper will suffice:


Trim the LED leads, and solder them to the headphone wires:


The polarity of the wiring depends on the requirements of your particular mind machine.  My Sirius mind machine uses common-anode wiring (also known as CP or common-power), so the anodes connect to ground, and the cathodes go to the right and left channel signal leads.  If your mind machine requires common-cathode wiring (aka CG/common-ground), then you should connect the cathodes to ground, and the anodes to the left and right signals.

After soldering the LEDs, drill a small hole in the side of each ping-pong ball half (I actually just twirled the tip of my x-acto knife, rather than using a drill bit), and then tack them to the balls with hot melt glue.  The blob of glue that holds the tip of the LED to the ball actually helps to diffuse the light a bit more.  Notice that the LED’s are pointed toward the ball instead of away from it, so that you instead of shining the LED beam into your eyes, it bounces off the ball.


Next, carefully glue the ping-pong ball halves to the front of the goggles.  Tack one side of the ball, wait for it to harden, and work your way around it a section at a time, while bending it to conform to the shape of the goggles.  Be careful of overheating when applying hot glue to the ping-pong balls.  My glue gun was a bit hot, and the heat warped them a bit. Notice the flattened parts of the balls below:


Here are the completed goggles:


They work fabulously … much better than conventional point-source lightframes, and an added bonus is that they can be used with eyes open.


Plus, they look really cool & trippy: goggleshead

Here is a preview of my hallucination machine. It’s a standalone Arduino-based mind machine, which is my remix Michael Rule’s Hallucinogenic goggles.  The goggles are of identical design, but use RGB LEDs rather than a single color.  I will document the build in a future article.


Related Post: Relax Your Mind: Build Your Own Ganzfeld Goggles

Build a Bluetooth Low Energy (BLE) Controlled RGB LED

I have been wanting to play with my RedBearLab BLE Shield for some time, but have been too busy. This weekend, I finally was able to allocate some time to experiment with it. I decided to do something relatively easy as my first project, so as to familiarize myself with the Bluetooth API’s on both the Arduino and the host side. Wirelessly controlling an RGB LED seemed like something fun to do.  RedBearLab has some example programs for Mac OSX and iOS in their BLE SDK.  I decided to start with OSX, since the compiler and SDK are a free download from Apple.

One nice thing about BLE is that you can write iOS apps that talk to it without going through Apple’s expensive MFA program.  Apple is being asinine, as usual, and decided not to support the RFCOMM profile, which allows older versions of Bluetooth to emulate serial ports, and talk to arbitrary devices.  However, they still force you to pay them $99 per year (yes, per year, not a one-time fee) for the *privilege* of being able to run your own iOS apps on an actual device.  Annoying and evil…

While recent Apple computers have Bluetooth 4.0 support built-in, I have an older Mac Book Pro from 2008.  I bought a cheap CSR BT 4.0 dongle on eBay for <$10.

My Mac is running OSX Mountain Lion, but I was not able to get it working at first, even though I followed the hack described at: (Note: I deleted the bcdDevice key, rather than updating it as described in the article).  Then I noticed that Apple wanted to install an OSX update.  Once I updated to OSX 10.7.5, the dongle started working properly.  What’s strange is, with the update, I found that there is actually a kext which is configured to directly support my dongle (USB VID = 0x0a12, PID = 0x0001) straight out of the box, but for some strange reason, OSX was detecting it as a Broadcom device, rather than Cambridge Silicon Radio.  While the dongle is working now with the hack, it is a bit flaky on my Mac, and sometimes can’t talk to the BLE Shield, unless I unplug/plug it in or retry several times.  On the other hand, it works flawlessly on my Windows 8 machine.  If anyone knows of a cheap and reliable BT 4.0 dongle for OSX, please leave a comment below.  FYI, when you plug in the BT 4.0 dongle, OSX automatically disables the built-in Bluetooth controller.


I used a common-cathode RGB LED.  Here is the schematic:



The brightness of each color channel is controlled via PWM, using a value from 0-255.  The BLE Shield uses pins D8 and D9 for communication.  My Arduino Duemilanove has 6 PWM pins: D11, D10, D9, D6, D5, and D3.  Therefore, I decided to use D6=red, D5=green, and D3=blue. I wired it up on a mini protoboard.  To diffuse the light, I drilled a small hole into a Ping-Pong ball, and attached it to the LED.  Here is my test rig:



I have uploaded all of the code for this project to github:

Arduino Sketch:

The Arduino code for this project is in BleRgbLed.ino.  Before you can compile the sketch, you must install the BLE Arduino library.  Simply unzip into <arduinosketchbook>/libraries.  You will have two subfolders, BLE/ and BluetoothLowEnergy/.

To maintain communication integrity between the host and the Arduino, I decided to implement a simple 5-byte packet format:

<sync byte><red><green><blue><checksum>


 <sync byte> = 0xA5


<checksum> = <red> XOR <green> XOR <blue>

This way, if the signal drops out or some packets get corrupted, the Arduino can reject bad data, and easily regain sync.

OSX Cocoa App:

The Mac OSX app is very straightforward, using 3 sliders, one for each color, to control the LED:

As a template, I used RedBearLab’s SimpleControl_Mac example, which is included in their BLE SDK.  To compile the app, your Mac must be running OSX 10.7.2+, and you must use XCode 4.2+. To compile an OSX or iOS app that talks to the BLE shield, you must add two frameworks to your project:  1) BLE_Framework from RedBearLab’s SDK and 2) IOBluetooth.framework from Apple’s SDK.

It would be very straightforward to port the app to iOS, using the SimpleControl_IOS sample as a template, but I haven’t done it yet, because my Apple Developer license expired, and I don’t want to spend another $99 for a new one.  It is supposedly possible to run it on your Mac via the iOS Simulator without a developer license, but I wasn’t able to get the simulator to connect to the BLE shield through my BT4.0 dongle.  iPhone 4S/5 and late model iPads have BLE built-in.  I believe you need to be running iOS 5.1+ to use BLE API’s.

Here is what it looks like in a darkened room.  It’s bright enough to make a nice night light. It looks a bit like an Ambient Orb, and with a bit of extra coding, could actually behave like one. With some transistors to drive more current, you could drive RGB LED strips, and make multicolored under-counter kitchen lighting.

I think it would be cool to use the LED as a notifier for SMS messages, voice mail, etc for an iPhone, but I am not yet sure whether or not the proper API’s are available.

I am more comfortable programming Microsoft Windows apps… if anyone has any good examples for getting started with BLE communication API’s under Windows, please leave a comment below.

One of my goals is to build wirelessly controlled RGB LED goggles for photic brain stimulation – once I get this working, I will post a blog entry.

Code Download:

Previous Post: RedBearLab BLE Shield – First Look

LiquidTWI2 v1.1.0 Released

For the Adafruit RGB LCD Shield (MCP23017), I changed the GPIO writing from 16-bit to 8-bits. This increased the library size by 14 bytes, but it’s well worth it, because writing a 47-character string has sped up from 99ms to 76ms on my Arduino Duemilanove – that’s about a 25% increase!  This is vs Adafruit’s RGB LCD library, which is 1.4K bigger, and takes 322ms.

Download: LiquidTWI2

Related Post: LiquidTWI2 – A Lean, High Performance I2C LCD Library for Arduino

LiquidTWI2 – A Lean, High Performance I2C LCD Library for Arduino

I have released LiquidTWI2, a lean, high speed I2C LCD Library for Arduino. This library is an extension of the great work done by FalconFour on his LiquidTWI library.  Notable additions to LiquidTWI:

LiquidTWI2 also supports the Adafruit I2c Backpack (MCP23008-based) in I2C mode.  The library is a drop-in replacement for both the Adafruit LiquidCrystal Library (for the I2C backpack) and the Adafruit RGB LCD Shield Library.  By replacing either of Adafruit’s libraries with LiquidTWI2, memory use will decrease, and writing to the LCD will become blazingly fast.


  1. download LiquidTWI2 from github.
  2. copy the LiquidTWI2 folder to <arduinosketchbook>/libraries/LiquidTWI2


I2C Backpack or compatible MCP23008-based module

#include <Wire.h>
#include <LiquidTWI2.h>
LiquidTWI2 lcd(0); // 0 = i2c address
void setup() {
lcd.setMCPType(LTI_TYPE_MCP23008); // must be called before begin()
lcd.setBacklight(HIGH); // only supports HIGH or LOW
void loop() {
lcd.print(“Hello World!”);

RGB LCD Shield or compatible MCP23017-based module

#include <Wire.h>
#include <LiquidTWI2.h>
LiquidTWI2 lcd(0);

void setup() {
lcd.setMCPType(LTI_TYPE_MCP23017); // must be called before begin()
lcd.setBacklight(WHITE); // see LiquidTWI2.h for color options
void loop() {
lcd.print(“Hello World!”);
uint8_t btns = readButtons();

Note that you must call setMCPType() with the correct module type prior to the first call to begin().  The module type can be switched at any time during runtime by merely calling setMCPType() and begin() again. This allows you to create a single firmware which can run with either module, and store the module type in EEPROM.

When working in a memory-constrained environment, you can save memory by disabling the unneeded support.  Edit LiquidTWI2.h and comment out the #define for either MCP23008 or MCP23017.

For further speed gains, you can tweak the speed of the I2C bus.  See the included i2c_perftest example sketch.


Related Post: LiquidTWI2 v1.1.0 Released