New Relic, Networked Wearables and the Conference Badge
You read about my “Electro-matic Conference Personality Identification Device” in a recent article. People who’ve seen it in person liked the idea of putting the Steampunk theme together with an LCD and an Arduino. It didn’t have any connectivity, though, which is a basic element of the Internet of Things (IoT). This time around, we’ll start exploring the idea of a connected badge using a network-enabled microcontroller. Later on, I’ll tell you about a company who is on a similar quest using slightly different technology.
Wearable … And Networked
The “wearable computing” movement is pretty new. You’ve probably seen the little LED pendants that flash or change colors at Maker events. How about all those commercial wrist strap gizmos that measure your blood pressure, heartbeat, bank balance and other crazy stuff? The latter are sometimes networked using near field communication (NFC) or Bluetooth.
I want my badge to do things and am only interested in using WiFi and cell network-based devices. In other words, a device has to have a ubiquitous Internet connection.
The goals for my conference badges are simple:
- Create a conversational icebreaker to use when meeting new people.
- Explore the role of wearables in the real world.
- Identify and develop the skills needed to build “new stack” wearable computing products.
Version 2.0 is a Challenge
You’ll recall from version 1.0 the design of the badge was straightforward. An Arduino Pro Mini is hooked up to a little 1.8” TFT color LCD screen and displays a color bitmapped image of my “Dr. Torq” logo. It alternates the image with the ambient room temperature, as sensed by an onboard Dallas temperature chip.
When I started, it seemed like it would be pretty easy to port everything over to the Arduino Yun. I’ll tell you, it’s not.
There are a few challenges to using the Yun for a networked badge.
First, the Yun uses the same ATmega32U4 processor as the Leonardo, while the Pro Mini uses a standard ATmega328 chip. Neither the Yun nor the Leonardo connect the SPI interface to the general purpose input/output pins. You have to connect several lines of the Yun’s 6-pin SPI hardware port to the color LCD panel before you can see anything. I chased my tail for a while on that one, then finally found a diagram on the Arduino site. Once the MOSI (master output, slave input), MISO (master input, slave output), and SCK (serial clock) lines are hooked up correctly, the screen lights up like a champ. And it’s pretty fast.
The next thing I ran into was that there’s limited flash storage available on the Yun. You don’t have very much space for additional Linux programs. Also, writing to the flash memory on the Yun all the time supposedly wears it out. The solution: move everything over to the Yun’s onboard SD card. Sure, the SD card might wear out too, although they are made to take tens of thousands of write cycles. There’s a nifty sketch to format, partition and copy over the required files for the SD card system operation on the Arduino site. Now, there’s about 1 GB of storage for the Linux side of the Yun and 700 MB for storing files and sketches. Perhaps I should see if LibreOffice will load. Just kidding.
The biggest problem I’ve had is that there’s a conflict between the Arduino SD and Bridge libraries. The SD library is needed to read the bitmapped images from the LCD’s onboard SD card. The Bridge library functions are used to allow the ATmega32U4 (Arduino side) to talk to the Atheros AR9331 (Linux side), both of which reside on the Yun. Apparently, the two libraries define a couple of classes with the same name. As a result, you’ll get a bunch of errors when the libraries are used in the same sketch.
Why didn’t I just put the Dr. Torq bitmapped images into the Yun’s newly created SD storage and load them using only the Bridge and FileIO libraries? It should work in theory. Sadly, after a day of trial and errors, I have not been able to get it to work in real-life — yet.
The upshot of all this is that the LCD works with the Yun, but I’m not able to load bitmaps from the LCD’s SD card if I’m using any of the Bridge functionality. Perhaps I’ll investigate programmatically generating a graphic of my logo, in lieu of the bitmapped image. Animated graphics would probably grab people’s attention.
The Networking Part
All of the work done so far has been programmed over my local LAN using the Arduino IDE version 1.5.8 on my Linux notebook. Programming the Yun remotely is a little tricky. Use a browser on your notebook to log into the Yun using it’s IP address and enter the admin password. Proceed to the IDE and select the Yun from the dropdown processor menu. Make sure the port points to the Yun’s IP address. And, don’t forget that after a reboot, it takes a minute or two before the Yun’s networking machinery is up and running.
SSH also works well on the Yun. I logged in as root to the IP address and am able to list files, use vi, run shell scripts and do any number of other command line jobs.
The next steps are to build a new Steampunk frame for the LCD display and the Yun, figure out some interesting network applications that would be appropriate for a name badge and maybe create some programmable graphics.
Once you get the hardware prototyped, the idea of a networked badge opens up a lot of possibilities. And, I haven’t even touched upon using the input/output capabilities, like push buttons, sensors, LEDs and servos.
How a Data Analysis Company Builds a Conference Badge
New Relic is on a parallel path. Their 2013 conference badge is considerably more complex than what I’ve built. It sports an Electric Imp brain, a variety of LEDs and buttons for interaction and is fully networked. They also have a smartphone app for badge setup and configuration. The company provided each conference attendee with a badge.
While their 2013 version badge was cool, their 2014 badge was much smaller with rounded corners and an E Ink screen. Additionally, it had headers for various hardware interfaces and could be modded through a cloud-based IDE. New Relic encouraged attendees to hack their badges and share their work with others.
The badge provided lots of conference and attendee data, and facilitated wireless contacts through “bumping” the badges together. The company’s interest in conference badges makes sense seeing as New Relic is a data analysis company. Their badges are a great example of where wearable computing is going.
New Relic is a sponsor of The New Stack.
