Category: Blog

Teensy is a popular microcontroller ecosystem that I’ve highlighted on my site before. There are already a number of breakout shields on the market for most of the Teensy models. I’ve tried several, and written about them here.

The breakout boards that I’ve tried were either overbuilt with way more functionality than I required, or too basic, not offering what I needed for my projects. After considering a few ways to approach this, I made a physical prototype for connecting some sensors.

A few months prior to this, my father was transitioning from acid-etched circuit boards to computer designed boards using Eagle. He hadn’t sent his board off for manufacturing yet, so this was a good time to combine efforts and save on shipping if I could get my own board designed. I thought it would be good to use the same program so we could learn about it together. Unfortunately, couldn’t get Eagle to run on my laptop due to a video issue, so I opted for Circuit Maker.

For about two weeks, I learned how to pull off my design successfully and pass the QC process within Circuit Maker and the online manufacturer I selected (PCBWay in China). On one level the process is very much like desktop publishing in that you have many layers to manage and very fine tolerances down to the fraction of a millimeter. On another level this was a completely different world for me and I definitely learned a lot.

As usual, taking breaks was a good idea throughout the process. I often found myself having an idea about how to make an improvement after some time away. One frustrating part was that PCBWay doesn’t give you all errors at once when you go through their QC process. They tell you about one error at a time, and with the time delay between here and China, that can be somewhat grueling. But with ample help from Youtube and some forums I got through the major hurdles, and in the end I was able to go with a lot of default settings in Circuit Maker. I know a lot of people swear by Eagle, but I am pretty used to Circuit Maker now and will likely use it again.

I used Otherplan as a supplemental check to see if the build files would translate properly. My dad was also able to check my design in a different board viewer. All of the activity on my board project prompted my dad to finish his design, and we were able to ship everything together, saving on shipping. Then we waited… to make sure we didn’t just create a bunch of funky coasters!

After about two weeks, our order came. I couldn’t have been more pleased. The board looks great, and functions electrically the way it should. Like anything you do for the first time, there are always some improvements to make, so I am sketching out V2.0. I’ve worked the board into my project for now, and will be selling the rest on Tindie.com if anyone is interested.

This was a very fun process, and I already have ideas for a completely different board I’d like to make in addition to a revision of this one. My dad’s board is awaiting testing, and we’ll know before long how his design went. Hopefully it was just as successful and I can post an update soon!

March 3, 2018

I found Daniel Gilbert’s Teensy 3.2 Breakout (Revision D) on Tindie during a web search while working on my Teensy Audio project. The breakout board was out of stock, so I put myself on the wait list immediately. As soon as they were available a few weeks later, I ordered two – one for prototyping and one for potential permanent install. The boards arrived fairly quickly and are of great quality and design.

I know that is it always a good idea to read instructions a couple of times, especially for somewhat specialized stuff like this. This was even more important in this case because I did not plan on using the board 100% exactly as originally proposed. I wanted to use longer pins to allow insertion into a Teensy audio board.

Like other users I had some confusion about the VIN VUSB cut that you need to make on the Teensy, but a quick email to Daniel got me on the right track (see photos below). My only real challenge with this build was the 14-pin double row header. While the instructions say to not worry about lining it up too much, this really does need to line up perfectly with the 5-pin header above it or the Teensy and Breakout wont sandwich together. Luckily, with some foresight I avoided a major issue by using a female header to hold everything in place. In the end I actually had more trouble from the A11,A10,AREF,VUSB header, but with a little gentle bending got everything together.

The 14-pin header soldering area is tight once the 5 pin header is installed. I have a variable soldering iron, but even the conservative setting I typically use was a bit high for working in this area. I had one problematic pin where some plastic melted causing the pin to slide all over the place. At one point I considered scrapping the whole header, but I was able to salvage it after taking a break.

Good light and a magnifying glass are *extremely* helpful here. This was my first time working with the 14-pin right angle header design that connects to pads and to conventional pins. Even for an experienced builder may grow impatient with this. Take breaks!

Altogether the build took me 2 hrs. That was after reading the instructions 3 times in separate sittings. When you consider the cost of this board ($12), the Teensy ($20) and your time, you don’t want to mess up. After I was done, all pins tested fine and I now have a great board that is perhaps too good to use for some projects! This breakout offers more functionality at your fingertips than most people would use in small projects.

February 24, 2018

The LinkSprite is an 8 x 8 LED matrix that can be used when you need something more sophisticated than a single LED to give feedback. It also opens up the world of creating letters, numbers and basic shapes.

Extremely well documented, the Linksprite is very easy to get going – although, as I post this, the documentation site is down! I’ve had this unit for a few years, having only tried a basic sketch to spell out my name using this sketch:

 unsigned char i;
 unsigned char j; 
/*Port Definitions*/
int Max7219_pinCLK = 10;
int Max7219_pinCS = 9;
int Max7219_pinDIN = 8;
 
unsigned char disp1[38][8]={
{0x3C,0x8,0x8,0x8,0x8,0x8,0x48,0x30},//J
{0x7C,0x40,0x40,0x7C,0x40,0x40,0x40,0x7C},//E
{0x3C,0x22,0x22,0x22,0x3C,0x24,0x22,0x21},//R
{0x7C,0x40,0x40,0x7C,0x40,0x40,0x40,0x7C},//E
{0x81,0xC3,0xA5,0x99,0x81,0x81,0x81,0x81},//M
{0x41,0x22,0x14,0x8,0x8,0x8,0x8,0x8},//Y
};

void Write_Max7219_byte(unsigned char DATA) 
{ 
 unsigned char i;
 digitalWrite(Max7219_pinCS,LOW); 
 for(i=8;i>=1;i--)
 { 
 digitalWrite(Max7219_pinCLK,LOW);
 digitalWrite(Max7219_pinDIN,DATA&0x80);// Extracting a bit data
 DATA = DATA<<1;
 digitalWrite(Max7219_pinCLK,HIGH);
 } 
}

void Write_Max7219(unsigned char address,unsigned char dat)
{
 digitalWrite(Max7219_pinCS,LOW);
 Write_Max7219_byte(address); //address，code of LED
 Write_Max7219_byte(dat); //data，figure on LED 
 digitalWrite(Max7219_pinCS,HIGH);
}
 
void Init_MAX7219(void)
{
 Write_Max7219(0x09, 0x00); //decoding ：BCD
 Write_Max7219(0x0a, 0x03); //brightness 
 Write_Max7219(0x0b, 0x07); //scanlimit；8 LEDs
 Write_Max7219(0x0c, 0x01); //power-down mode：0，normal mode：1
 Write_Max7219(0x0f, 0x00); //test display：1；EOT，display：0
}
 
void setup()
{
 pinMode(Max7219_pinCLK,OUTPUT);
 pinMode(Max7219_pinCS,OUTPUT);
 pinMode(Max7219_pinDIN,OUTPUT);
 delay(50);
 Init_MAX7219();
}
 
void loop()
{ 
 for(j=0;j<38;j++)
 {
 for(i=1;i<9;i++)
 Write_Max7219(i,disp1[j][i-1]);
 delay(500);
 } 
}

That was 2014. With my return to the Linksprite in 2018, I found it is even easier when you reference one of several LED Matrix builders available online.

Aside from getting familiar with the MAX7219 chip which does all the heavy lifting, I found the Linksprite to be very good for studying coding in general.  I thought maybe I’d work with it for a couple hours and get bored, but it became the focus of much of my weekend experiments as I tried different things.

There are a few behaviors to consider, and some concepts you must master for the Linksprite to work. The most important is arrays, which are used to store the various codes for the images. I use the term “images” here loosely, as what you can create with 8×8 LEDs/pixels is limited. Speed and intensity parameters also come into play, and its interesting how many ways you can tackle adjusting these parameters for different effects.

Using a tilt switch, I created two sets of behaviors. One just scrolls through some arrow shapes using a long-ish method of coding.

The second uses an array and some variables to create the appearance of a moving arrow (which is nothing more than a visual trick). Both behaviors show an increase in light intensity.

I tried a number of ways to load the images and change the intensity at the same time. I tried two FOR loops running in parallel, and a FOR within a FOR. Usually I ended up with intensity changing all at once, and sometimes stopping the motion in the process. The solution here is one of many potential options, but worked the best out of what I tried.

/* JJD 2/24/18 - 2/25/18
 * Matrix HEX code from https://xantorohara.github.io/led-matrix-editor
 * 
 * Linksprite LED Matrix v1.0 (MAX7219)
 * https://www.sparkfun.com/products/retired/11861
 * http://linksprite.com/wiki/index.php5?title=LED_Matrix_Kit
 * http://store.linksprite.com/max7219-8x8-red-dot-led-matrix-kit/
 * 
 * Tested with Redboard
 * Intensity of lights change along with animation, but there are a few ways to do this.
 * Not all of them work the same way. Method here gives smoothest transitions.
 * 
 * */

#include <LedControl.h>

int CLKPIN = 10;
int CSPIN = 9;
int DINPIN = 1;
int TILT = 13;
int buttonState = 0; // Variable for reading button
int arrowDelay = 1000;
int arrowToshow = 0;

// https://xantorohara.github.io/led-matrix-editor
const uint64_t IMAGES[] =
 {
 0x081c3e7f1c1c1c1c, // DOWN 0
 0x0010307fff7f3010, // RIGHT 1
 0x1c1c1c1c7f3e1c08, // UP 2 
 0x00080cfefffe0c08, // LEFT 3
 };

//DOWN ARROW ANIMATION
const uint64_t ARROWS[] = {
 0x081c3e7f1c1c1c1c,
 0x1c3e7f1c1c1c1c00,
 0x3e7f1c1c1c1c0000,
 0x7f1c1c1c1c000000,
 0x1c1c1c1c00000000,
 0x1c1c1c0000000000,
 0x1c1c000000000000,
 0x1c00000000000000,
 0x0000000000000000,
 0x0000000000000008,
 0x000000000000081c,
 0x0000000000081c3e,
 0x00000000081c3e7f,
 0x000000081c3e7f1c,
 0x0000081c3e7f1c1c,
 0x00081c3e7f1c1c1c
};

const int IMAGES_LEN = sizeof(IMAGES)/8;

LedControl display = LedControl(DINPIN, CLKPIN, CSPIN);

void setup(){
 pinMode(TILT, INPUT);
 display.clearDisplay(0);
 display.shutdown(0,false);
 display.setIntensity(0,5);
}

void displayImage(uint64_t image)
{
 for (int i = 0; i < 8; i++) {
 byte row = (image >> i * 8) & 0xFF;
 for (int j = 0; j <8; j++) {
 display.setLed(0,i,j,bitRead(row,j));
 }
 }
}

void loop() {

// Read the state of button or tilt
 buttonState = digitalRead(TILT);

// Remember that images are numbered starting at 0,1,2,3... etc
 /* Set the brightness of the display. void setIntensity(int addr, int intensity); 
 * Params:
 * addr the address of the display to control
 * intensity the brightness of the display.
*/
 if (buttonState == HIGH) {
 display.setIntensity(0,0);
 displayImage(IMAGES[3]);
 delay(500);
 display.setIntensity(0,1);
 displayImage(IMAGES[2]);
 delay(500);
 display.setIntensity(0,2);
 displayImage(IMAGES[1]);
 delay(500);
 display.setIntensity(0,3);
 displayImage(IMAGES[0]);
 delay(500);
 display.setIntensity(0,4);
 displayImage(IMAGES[3]);
 delay(500);
 display.setIntensity(0,5);
 displayImage(IMAGES[2]);
 delay(500);
 display.setIntensity(0,6);
 displayImage(IMAGES[1]);
 delay(500);
 display.setIntensity(0,7);
 displayImage(IMAGES[0]);
 delay(500);
 display.setIntensity(0,8);
 displayImage(IMAGES[3]);
 delay(500);
 display.setIntensity(0,9);
 displayImage(IMAGES[2]);
 delay(500);
 display.setIntensity(0,10);
 displayImage(IMAGES[1]);
 delay(500);
 display.setIntensity(0,11);
 displayImage(IMAGES[0]);
 delay(500);
 display.setIntensity(0,12);
 displayImage(IMAGES[3]);
 delay(500);
 display.setIntensity(0,13);
 displayImage(IMAGES[2]);
 delay(500);
 display.setIntensity(0,14);
 displayImage(IMAGES[1]);
 delay(500);
 display.setIntensity(0,15);
 displayImage(IMAGES[0]);
 delay(500);
 
 } else {
 for (int arrowToshow = 0; arrowToshow < 15; arrowToshow++)
 // the 15 here refers to the 16 arrows (0-15) in the array above. Could also make this a variable like IMAGES_LEN
 
 {
 static int count = 0; // setting this for use as intensity, initialize only once via static
 display.setIntensity(0,count); 
 displayImage(ARROWS[arrowToshow]); // use value from FOR loop to assign the arrow image from the array
 delay(arrowDelay); 
 count ++; // increment the intensity
 if (count > 16) // limit intensity to unit threshold 0-16
 {
 count = 0;
 }
 } // close 1st FOR

} // END ELSE
} // END MAIN LOOP

This was a lot of fun and gave me some ideas for how to work this into some of my other projects. One could set a arrow to flash down/up when a temperature reaches too low/high. These LEDs are very bright and could be seen from far away if necessary.

Of course, since these came out in 2012/2014, many more sophisticated LED and NeoPixel devices are available. There’s still lots to learn from even a small 8×8 matrix – time well spent!

February 16, 2018

After making some advances with audio board selection and programming, it was time to go through my parts supply and explore various sensors to see how they could be employed.

First up was the ZX Distance and Gesture Sensor made by Sparkfun. I have the original version which is now retired. Following the hookup guide, things were easy enough to get going.

This sensor uses infrared (IR) beams to place objects. As Sparkfun note, “The ZX Sensor is a touchless sensor that is capable of looking for simple gestures in the air above the sensor (e.g. swipe left or swipe right). Additionally, the sensor can also recognize the distance of an object away from the sensor at distances up to about 12 inches (30 cm), referred to as the “Z” axis, and the location of the object from side to side across the sensor in about a 6 inch (15 cm) span, referred to as the “X” axis.”

This has some very similar capability to the Sparkfun APDS-9960 RGB and Gesture Sensor, though a key difference is that it requires 3.3 –  5V power, but 5V gives better range according to Sparkfun. Oddly, there is no “down” gesture, which the APDS-9960 does have. I found the response a bit less immediate than I would like for some things, so haven’t worked this into a project yet.

HC-SR04 Ultrasonic Distance Sensor Module

I’ve had the common HC-SR04 sensor sitting around for years, exploring it early in my Arduino learnings. I probably got mine from Adafruit, but I see they no longer carry it. Sparkfun does, and these sensors are pretty easy to find elsewhere, being a staple in the robotics community.

I chose to use a Pro Mini as the main board here because it would mirror the size of the project I have in mind. Setup was fairly easy, though I did have some issues with my library. Eventually I landed on the one from Martinsos on GitHub, though there are others out there that may be more suitable depending on the application.

After basic tests, I wanted to add some LEDs and found a similar idea from Instructables, so integrated that code. From there, I wanted to incorporate my Adafruit FX Sound Board project and trigger it from the ultrasonic sensor. This was actually a dry run for a similar idea I have for a Particle Photon project, but I wanted to have a proof of concept first.

In the pictures there is a little red PCB on an orange breadboard between the two projects. This is because I thought a logic converter would be needed, but in the end it was not. For one thing, the Adafruit FX Sound Board has a built in regulator for the inputs. So there was no benefit to overbuilding with the converter.

I also couldn’t get it to work anyway – though this was probably user error. Everything worked with the LEDs, but as soon as I tried triggering the soundboard, I either saw repeated triggering (bad) or only got the intended results with what I saw as some backwards wiring. After telling my dad about this, he set me straight with a simple transistor approach that did the trick. “Transistor BASE goes to Mini OUTPUT. COLLECTOR goes to sound board input pin. EMITTER goes to ground. Probably both ground of Mini and ground of soundboard should connect together.”

So the projects are now connected, with an object triggering a sound as it passes the sensor. Final code below. In many ways this is still rather overbuilt (compared to Teensy), but could still be fun to use for Halloween 2018.

/*
JJD 2/16/18 HC-R04 with Pro Mini 5V
Uses Library from
https://github.com/Martinsos/arduino-lib-hc-sr04/blob/master/examples/simple/simple.ino


Sensor is initialized by creating instance of class UltraSonicDistanceSensor and providing trigger and echo pins:
UltraSonicDistanceSensor sensor(triggerPin, echoPin);.

Then, to measure the distance, you just call measureDistanceCm(), which will return distance in centimeters (double).
If distance is larger than 400cm, it will return negative value.

LED code inspired by
http://www.instructables.com/id/Simple-Arduino-and-HC-SR04-Example/

*/

#include <HCSR04.h>
#define LED_1 10
#define LED_2 11

// Initialize sensor that uses digital pins 13 and 12.
int triggerPin = 13;
int echoPin = 12;

//UltraSonicDistanceSensor distanceSensor(triggerPin, echoPin); // this line not really needed if declaring INTs above

void setup () {
 Serial.begin(9600); // We initialize serial connection so that we could print values from sensor.
 pinMode (LED_1, OUTPUT);
 pinMode (LED_2, OUTPUT);
}

void loop () {
 long duration, distance;
 digitalWrite(triggerPin, LOW);
 delayMicroseconds(2);
 digitalWrite(triggerPin, HIGH);
 delayMicroseconds(10);
 digitalWrite(triggerPin, LOW);
 duration = pulseIn(echoPin, HIGH);
 distance = (duration/2) / 29.1;
 if (distance < 6) { // This is where the LED On/Off happens JJD X cm to act as switch for whatever
 digitalWrite(LED_1,HIGH); // When the LED_1 condition is met, the LED_2 LED should turn off
 digitalWrite(LED_2,LOW);
}
 else {
 digitalWrite(LED_1,LOW);
 digitalWrite(LED_2,HIGH);
 }
 if (distance >= 200 || distance <= 0){
 Serial.println("Out of range");
 }
 else {
 Serial.print(distance);
 Serial.println(" cm");
 }
 delay(500);
}

The Sparkfun APDS-9960 RGB and Gesture Sensor is a fairly low-cost ($15) option for hands-free control of all kinds of things. I’ve had this sitting around for a while waiting to be integrated into a project, but I wanted to explore it on its own before making that leap.

For the size, this is a sophisticated sensor, with capability to do proximity, gesture (left/right, up/down, near/far), color sensing and some other options. My initial interest was gesture sensing for a Teensy project, but I chose to explore this sensor on the Sparkfun ESP8266 Thing and Pro Mini 3.3V boards first, just to become familiar with the code.

The trickiest part of my initial tests were the interrupt settings. I ran into issues on the Sparkfun ESP8266 Thing where I’d get a successful sensor initialization, but no gestures. I had better luck with the Pro Mini, though still had some issues with gesture sensing and it was much easier to get Proximity working (shown below).

Here’s the code for the LED proximity threshold test based on Shawn Hymel’s original sensor test sketch:

#include <Wire.h>
#include <SparkFun_APDS9960.h>

// Global Variables
SparkFun_APDS9960 apds = SparkFun_APDS9960();
uint8_t proximity_data = 0;
int LED_PIN = 3; // JJD LED for if then

void setup() {

pinMode(LED_PIN,OUTPUT); //configure LED_PIN as OUTPUT 
 digitalWrite(LED_PIN, LOW); // set LED off
 
 // Initialize Serial port
 Serial.begin(9600);
 Serial.println();
 Serial.println(F("------------------------------------"));
 Serial.println(F("SparkFun APDS-9960 - ProximitySensor"));
 Serial.println(F("------------------------------------"));
 
 // Initialize APDS-9960 (configure I2C and initial values)
 if ( apds.init() ) {
 Serial.println(F("APDS-9960 initialization complete"));
 } else {
 Serial.println(F("Something went wrong during APDS-9960 init!"));
 }
 
 // Adjust the Proximity sensor gain
 if ( !apds.setProximityGain(PGAIN_2X) ) {
 Serial.println(F("Something went wrong trying to set PGAIN"));
 }
 
 // Start running the APDS-9960 proximity sensor (no interrupts)
 if ( apds.enableProximitySensor(false) ) {
 Serial.println(F("Proximity sensor is now running"));
 } else {
 Serial.println(F("Something went wrong during sensor init!"));
 }
}

void loop() {
 
 // Read the proximity value
 if ( !apds.readProximity(proximity_data) ) {
 Serial.println("Error reading proximity value");
 //digitalWrite(LED_PIN, LOW); JJD LED TEST
 } else {
 //Serial.print("Proximity: ");
 //digitalWrite(LED_PIN, HIGH); JJD LED TEST
 //Serial.println(proximity_data);
 }

// JJD Section 2/10/18 to set LED on/off at threshold
 if ( proximity_data < 100 ) {
 digitalWrite(LED_PIN, LOW);
 Serial.print("LED OFF, Proximity under 100: ");
 Serial.println(proximity_data);
 } else {
 digitalWrite(LED_PIN, HIGH);
 Serial.print("LED ON!! Proximity over 100: ");
 Serial.println(proximity_data);
 }
 
}

Gestures took some more tries, with a complete refresh of my test code, but eventually it worked (below).

While testing gestures, I tried to include some code to turn an LED on/off. This seemed to slow things down and didn’t work as well as I’d hoped. Response was a bit sluggish, probably because of the delay I used in gesture routine. Even after I took out the LED code, I thought the gestures responded a bit sluggishly.

I’m still not 100% sure why I found so many conflicting tutorials on the interrupt settings.

attachInterrupt(0, interruptRoutine, FALLING);

attachInterrupt(digitalPinToInterrupt(interruptPin), interruptRoutine, FALLING);

Setting that aside, I worked the proximity sensor into a Teensy project to control audio volume and that worked great. I’d like to leave that intact, so I’m going to order another sensor to dedicate to troubleshooting this further. Next step is to a) refine gesture response and b) see if both gesture and proximity can be used from same sensor. Combining them from the same sensor seems feasible, but involves more than just calling the Proximity and Gesture functions in the same sketch. Sparkfun provided some guidance:

“…the gesture function runs off of the proximity function (pages 9-17; the diagrams on 9 & 15 might be more helpful to visualize). You would probably have to internally call the register addresses for that proximity data (page 26).”

So there’s much more to explore!

/****************************************************************

2/9/18 JJD Reworking with SparkFun ESP8266 Thing WRL-13231 (not Dev Thing)
 2/11/18 JJD Pro Mini tests WORKING

APDS-9960 RGB and Gesture Sensor
 Based on Shawn Hymel @ SparkFun Electronics May 30, 2014
 https://github.com/sparkfun/APDS-9960_RGB_and_Gesture_Sensor

Tests the gesture sensing abilities of the APDS-9960. Configures
 APDS-9960 over I2C and waits for gesture events. Calculates the
 direction of the swipe (up, down, left, right) and displays it
 on a serial console.

To perform a NEAR gesture, hold your hand
 far above the sensor and move it close to the senasor (within 2
 inches). Hold your hand there for at least 1 second and move it
 away.

To perform a FAR gesture, hold your hand within 2 inches of the
 sensor for at least 1 second and then move it above (out of
 range) of the sensor.

Hardware Connections:

IMPORTANT: The APDS-9960 can only accept 3.3V!

Arduino Pin APDS-9960 Board Function

3.3V VCC Power
 GND GND Ground
 A4 SDA I2C Data
 A5 SCL I2C Clock
 2 INT Interrupt

Resources:
 Include Wire.h and SparkFun_APDS-9960.h

Developed in Arduino 1.0.5, revised by JJD 1.8.5
 Tested with SparkFun Arduino Pro Mini 3.3V
 ****************************************************************/

#include <Wire.h>
 #include <SparkFun_APDS9960.h>
 //#include <ESP8266WiFi.h>

// Pins
 #define APDS9960_INT 2 // Needs to be an interrupt pin
 #define APDS9960_SDA A4 // I2C Data Must use A for Analog
 #define APDS9960_SCL A5 // I2C Clock Must use A for Analog

// Constants

// Global Variables
 SparkFun_APDS9960 apds = SparkFun_APDS9960();
 int isr_flag = 0;
 const byte interruptPin = 2;
 int LED_PIN = 3;

void setup() {
 Wire.begin(); //Start I2C with pins defined above
 pinMode(APDS9960_INT, INPUT);
 pinMode(LED_PIN,OUTPUT);
 digitalWrite(LED_PIN, LOW);

// Initialize Serial port
 Serial.begin(9600);
 Serial.println();
 Serial.println(F("--------------------------------"));
 Serial.println(F("SparkFun APDS-9960 - GestureTest"));
 Serial.println(F("--------------------------------"));

// Initialize interrupt service routine
 attachInterrupt(0, interruptRoutine, FALLING);
 // attachInterrupt(digitalPinToInterrupt(interruptPin), interruptRoutine, FALLING); // JJD interrupt

// Initialize APDS-9960 (configure I2C and initial values)
 if ( apds.init() ) {
 Serial.println(F("APDS-9960 initialization complete"));
 } else {
 Serial.println(F("Something went wrong during APDS-9960 init!"));
 }

// Start running the APDS-9960 gesture sensor engine
 if ( apds.enableGestureSensor(true) ) {
 Serial.println(F("Gesture sensor is now running"));
 } else {
 Serial.println(F("Something went wrong during gesture sensor init!"));
 }
 }

void loop() {
 //digitalWrite(LED_PIN, LOW);
 if( isr_flag == 1 ) {
 detachInterrupt(0);
 handleGesture();
 isr_flag = 0;
 attachInterrupt(0, interruptRoutine, FALLING);
 }
 }

void interruptRoutine() {
 isr_flag = 1;
 }

void handleGesture() {
 if ( apds.isGestureAvailable() ) {
 switch ( apds.readGesture() ) {
 case DIR_UP:
 //digitalWrite(LED_PIN, HIGH);
 Serial.println("UP");
 break;
 case DIR_DOWN:
 //digitalWrite(LED_PIN, HIGH);
 Serial.println("DOWN");
 break;
 case DIR_LEFT:
 //digitalWrite(LED_PIN, HIGH);
 Serial.println("LEFT");
 break;
 case DIR_RIGHT:
 //digitalWrite(LED_PIN, HIGH);
 Serial.println("RIGHT");
 break;
 case DIR_NEAR:
 //digitalWrite(LED_PIN, HIGH);
 Serial.println("NEAR");
 break;
 case DIR_FAR:
 //digitalWrite(LED_PIN, HIGH);
 Serial.println("FAR");
 break;
 default:
 Serial.println("NONE");
 digitalWrite(LED_PIN, HIGH);
 delay(100);
 digitalWrite(LED_PIN, LOW);
 }
 }
 }

As discussed in my ongoing series of sound board experiments (most recently with the Adafruit Sound FX Board), I have been on a quest for an easy to use platform for sound installations and experimental projects.

The basic spec for this project was as follows:

• • 44.1 Khz 16 bit stereo
  • Allow up to three (maybe four) stereo audio tracks at a time.
  • Each track triggered via a button (or some other control)
  • Compact
  • USB or battery operation
  • Easy to update audio

My search for a good board for this project brought me to the Teensy Audio Board.

This project started with near disaster, but brought a great deal of satisfaction afterward. The disaster started when the Sparkfun package came earlier than expected (normally that is a GOOD thing!). I enthusiastically jumped into the project on a weeknight after being fried from work. Never a good idea. I was also working from a relocated laptop area that was less comfortable and poorly lit. Yeah, my own fault.

So the focus that I’d normally bring to something like this just wasn’t there, and probably accounts for some of the early struggles.

The Teensy Audio Board video and PDF tutorial that the makers of Teensy provide is great. Mostly. There are a few details they leave out about SD card formatting and the camera angles in the video make it difficult to see the wiring of their test device.

Headers

Sparkfun sells a header kit for Teensy, but right away I didn’t like how it was going to go together. The Teensy has 14 pins on the long side, but the long headers in the kit only cover 13 of those… leaving the end pins (12,13) open. There’s a 7-pin header that is intended to handle this… but it is not a great fit.

Having already soldered the 13-pin headers into place, and not having much to work with, I came up with a silly workaround…

I purposely didn’t solder this connection and just left it wired together with friction. This worked for a while, but when I got deep into the code I had to eliminate some of the variables that might have been causing some strange behaviors (like this crappy connection).

So I eventually broke down and filed the headers so that they fit together, with the 7-pin header boxing everything in.

The 5 pins in the center (VBat, 3.3V, GND, Program, A14/DAC) are either redundant or not needed for my planned project, so I could have cut those pins off. Note how they do not cooperate with the breadboard. Instead of cutting them, I just bent them out for potential use later.

It was only after all this drama that I learned that there are some specialized headers out there from the Teensy folks. Sparkfun also carries better Female Headers (PRT-00115) and Break Away Headers – Long (PRT-10158). There’s also some nice tricks in a 4-channel audio project buried on Sparkfun’s site. Had I seen all of this beforehand, I would have approached things much differently!

I’ll take responsibility for not researching my options further on this one, and just jumping in with what was in front of me. But it still seemed odd to me that Sparkfun would sell something with such obvious flaws. So I contacted them and they quickly responded. After sending them pictures and describing the issue they gave me a credit for the Teensy board and the header kit (more than I expected). Pretty cool. I’ve already placed an order for more boards (AND BETTER HEADERS) so I can redo the hardware part of this project. I’ll keep the first one as the prototype… which is the point after all.

As you’ll see, I’ll have mostly good things to say about Teensy and their audio board, but there is one last pet peeve…

Form Factor

As I learned later, in the workshop materials, they wired up their breadboards first and then plopped the controller down into place. This is completely backwards from how I work on projects.

I like to see the pins I am accessing. The wings of the Teensy Audio board are problematic for easy access to the pins. At one point this contributed (with poor light and fatigue) to some funky wiring on my part which made me think I had routed voltage to an input. The board seems to work though, so I may be OK.

Libraries – Bounce and SD

The projects that I was working on just before this one used the web IDE for Particle Photon. I really like the Particle IDE, and got kind of spoiled by how easily they handle libraries. When I came back to Arduino, I had to reacquaint myself with how libraries are stored and updated, and how to handle conflicts.

I had the most trouble out of Bounce and SD libraries, either because they were old or conflicting with Teensy’s better libraries. When this happens, you get some freaky errors…

Arduino: 1.8.5 (Windows 8.1), TD: 1.41, Board: "Teensy 3.2 / 3.1, Serial, 96 MHz (overclock), Faster, US English"

C:\Users\Jeremy dePrisco\Documents\Arduino\libraries\Bounce\._Bounce.cpp:1:1: warning: null character(s) ignored

  Mac OS X  2 °  â 
 ATTR;šÉÿ â ¼ Y  ¼ J com.apple.quarantine 
  com.apple.TextEncoding -40000;50e83707;Safari;A8E94CDC-818F-4261-9260-ADAEECB12457|com.apple.Safariutf-8;134217984

These were easy enough to work through, and a couple reboots were needed to really clear things out.

SD Card Madness

Over the years as I’ve tried other boards, SD card and file format issues were the norm. So I wasn’t surprised to run into some things here. As of this writing, the Teensy folks leave out some specifics on the requirements. On both generic and SanDisk SD cards, a default Windows FAT32 with default block size didn’t work. NTFS and exFAT also didn’t work (didn’t think they would – only tried for the heck of it).

It was only after I reformatted using 16kb block size that I had success. Some tutorials will tell you to use FAT16, but there is no option to format FAT16 in Win 8.1 (not without special software). Even the Sandisk SD card formatting program only did FAT32.

Teensy recommends that you use a Sandisk Ultra card for SD card Ultra best for multi-file playback, which I proved out: my generic card glitched out and sent me down a rabbit hole looking for coding solutions that were not necessary.

From there, the file naming convention is 8.3, which is typical of these projects. It was so nice to be free to use more than 8 or 16 MB of audio! With 16 GB, there’s not really much I can’t do with this.

The Good News

After moving my work area back to a much more comfortable spot, and after getting some sleep, I tackled this project for about 8 hrs. The time flew by. The Teensy Audio Board kicks ass.

I was able to duplicate most of the behaviors of the pre-programmed Adafruit FX Board by creating my own code pieced together from a variety of example files. But it wasn’t all copy/paste. I had to solve a number of issues, all of which took some careful thought.

The online audio system design tool gives a great visual representation of how signals are routed. While I’ve been exposed to MAX in Ableton, this was my first outing with this sort of platform, and it was easy to use. Creating my own routing for my project – which differed significantly from the workshop setup – was easy to do.

Where’s the code? I’m going to post that eventually, but right now this write-up is more about the hardware – and the benefit of setting aside dedicated time to immerse yourself into a subject.

February 10, 2018 Update

After considering a few different options for mounting and headers, I gave it another go with fresh boards.

Yet a third iteration is on the way using the Teensy Breakout sold on Tindie. Sparkfun also carries a Teensy Shield that allows interfacing with the Arduino Uno shield footprint, but it is of course a bit larger and more than I need for this project.

 

January 2018

This is a continuation of an earlier exploration of Adafruit’s FX Sound Board. Previously, I worked with the 2MB version, but soon found I needed more storage for the intended application.

The 16 MB version is basically identical in functionality – just more storage. The attraction of this board is that it is extremely easy to use, and it can do 44.1 Khz 16 bit audio in WAV or OGG. The ease of use comes from a file name-based trigger system whereby you can set sounds for one-shot, random, temporary play, and loop on any one of 11 pins.

Though this board goes together quickly on a breadboard, the time consuming part is calculating how much space you are going to use with your files. I typically work in 44.1 Khz 24 bit (stereo) WAV which is just too big for this platform. So right away there is a compromise to get down to 16 bit. Then, depending on the file, you may need to reduce from stereo to mono.

Using the Sound Devices Audio Time Calculator, I was able to get some pretty good estimates on just how much I would have to reduce my files before putting the files in the naming format required for the FX board.

The basic calculation to keep in mind is 1 min of stereo 44.1 Khz 16 bit audio (WAV) is going to be roughly 10 MB of data.

 

 

This calculator did not offer OGG, but it does MP3 which gets you close.

It helps to have a TXT file or notepad handy to work out the mapping of what files you want to do what, and their associated pin so you match them to the hardware correctly.

In this case I landed came up with 11 files that took up about 14.2 MB. I could only get close to the intended result by using OGG format (converted from WAV). I was able to keep some files stereo, but the “NEXT” files are mono. In a sense this doesn’t matter since the speaker I am using doesn’t have good separation, but for a larger system this would matter more.

One odd thing… for some reason the OGG files took forever to transfer from my Macbook to the FX board over a Sparkfun Cerberus cable, even though WAV files zipped right across. I’ve never experienced this before, and the cable has been performing great otherwise. I’m going to toss this out as some strange behavior of my USB hub, which was also in the chain.

The downside to the Adafruit FX Sound Board is that it can only play one sound at a time.

Ultimately, this board will not work for what I would like to do. The Teensy Audio Board is a much better option. Look for a write-up of that after my next Sparkfun order comes in!

February 10, 2018 Update

With so many projects on breadboards, sooner or later one must make time to either pull them apart or build them into something more permanent. The FX Board in this project uses a non-standard footprint, and I didn’t bother to locate any shields or breakout boards because I knew I could make my own.

This build was something I just thought of and executed without drawing it out. Only thing I might change if I make another one for my 8MB board is to pull the power connector in more so that it is flush with the board.

While the Adafruit Sound FX Board is too limited for most things I want to do, it will make an appearance in a future project where I just need a few small files to play one at a time.

January 2018

Next up in IoT exploration is the Sparkfun ESP8266 Thing – part WRL-13231. Note that this is not the Dev board – a separate device with different pinout and other changes.

Navigating Sparkfun’s hookup guide was fairly easy, especially since I had already installed the ESP8266 libraries as part of another project. The example they walk through on Sparkfun’s site shows you how to set up a basic, localized server. All of the other ESP8266 experiments I’ve done up to now were designed to make a device connect to an existing network, so this was a nice change.

Having experienced the easy connection of Particle Photon and the NodeMCU boards, using the FTDI Basic module to program the Sparkfun Thing was a bit odd. I had an FTDI module on hand from a previous project, but it had female headers soldered onto it. So I had to use a 6-pin male-to-male header to make the connection. This overly complicated connection may have contributed to some of the wonkiness with uploading my sketches, though uploading is also a known issue with this board that Sparkfun addresses in detail on their site.

The web server example went by pretty quickly, so I went over to Hackster.io and found a light sensor project to try. This too was pretty easy.

Yeah, not terribly exciting on the surface, but this is something that took way more hardware to pull off even a few years ago.

Impressions:

I like the fact that the Sparkfun Thing has a power switch onboard. The JST battery connector is a bit fragile, so I could see that having to be repaired or replaced with rough handling, especially if that was the only way to turn it on/off.

Still not crazy about the FTDI, but I can deal with it. Going to consider how I can pull this device into my ecosystem of other similar devices. Probably need to play with some other sketches. Also interested in trying the sister board. It seems there are more projects on Hackster.io for the Dev board than the one shown here.

A lot has changed since my last connected sensor project in 2013, so I wanted to jump in again to see how the technology has come along. After playing with some Particle Photon stuff, I came across NodeMCU. Hackster.io has lots of  ideas for this board, so I sought to recreate what Achraf Oukheir did there.

Achraf’s project is good, but it left out a lot of details, which I will summarize below. It was only by referencing Adafruit and Instructables for similar projects that I was able to eliminate errors and get the code to work. The other consideration is – if you have stepped away from Arduino for a while – just do yourself a favor and update your IDE first!

Tips and links:

Tip #1 – Update to latest Arduino IDE (unless told otherwise)
Tip #2 – Do not copy code into Notepad and back into Arduino IDE – it may introduce non-compliant quotes or other characters.
Tip #3 – Replace your DHT library with the latest one. The one I had was from 2013/14 and it did not work with this project. I used Adafruit’s library: Adafruit_Sensor
Tip #4 – Get the Blynk library directly from their site. Otherwise you might see an error like the one above.
Tip #5 – Be sure you have the NodeMCU. See this Instructables article.  Select NodeMCU 1.0 ( ESP-12EModule).
Tip #6 – See also Adafruit’s tutorials on this sort of thing. Different WiFi chip, but helpful for wiring.

So what did I think of this device? Things have come a LONG WAY since 2013! The app connectivity with Blynk is great. Less hardware, smaller footprint. The NodeMCU was $7 from Bandgood.com – and now the newer version with Bluetooth and more capability is out for only a few more dollars. Crazy! The next step will be to possibly use this platform to create a notification setup for our hot tub for both temp and water level. Still considering Photon for that, but NodeMCU might be a good option too.

February 2018 Update

In order to free up my breadboard, I moved this project onto a Seeed breakout board that allowed me to make more solid connections. This design – housed in a take out container – survived harsh temps from February through April. I also added an email notification when temps got out of bounds. Hence the ice test.

The Seed board actually came with another NodeMCU board. It was dirt cheap, and appeared to be a poor copy and I had a lot of trouble with it. It was also a 1.0 vs the 0.9 version I had been using, so that created some confusion. A write-up is in the works, but frustration was high, so I had to step away.

May 2018 Update

The Seeed breakout was a bit overbuilt for this project, so to free up the Seeed I replaced it with the NodeMCU Carrier/Dev/Breakout Board, a purpose-built design by BK Hobby that I found on Hackster.io. BK made his board files available, so I was able to include them in my order top PCBWay when my dad and I put an order together for some stuff we were designing.

To learn more about BK Hobby’s board:

BK Hobby’s Youtube Channel

Gerbers on PCBWay

Gitbub

3D models & Eagle CAD board and schematic files on Thingiverse