People ask me all the time which battery they should use for their Arduino project, or how long an XBee will run on a specific type of battery. Rather than continue to give vague answers, I decided that it would be much more helpful to generate some real-world battery life results for Arduino projects and XBee mesh networking radios. There were a lot of surprises. The results depend of course upon which battery you choose, but everything else makes a difference too. Changing the duty cycle of a single LED doubled battery life on an Arduino project. Simply sleeping an XBee radio between transmissions generated a whopping 1470% increase in battery life. In a few cases specific types of batteries failed completely–probably the most helpful test result of all.
Use the real-world battery life results to help choose which setup is right for your project. You can also use my Battery Test program in Processing to run your own tests. Send me any well-documented results and I’ll gladly add them to the list.
Dan Shiffman and I are working on a Processing library for Digi’s XBee Series 1 radios. The library currently facilitates receiving single sample I/O packets in API mode, and returns an object that contains the analog values, digital values, sender’s 16-bit address and RSSI value. The next tasks will be to receive regular RX frames, issue AT commands and receive responses, issue TX frames and receive responses to those. We’d also like to support the XBee Series 2 radios, which have a similar API structure.Here’s a page where you can download and learn about the XBee API Library for Processing v1.00.
On the Arduino microcontroller, the millis() function counts the number of milliseconds since the program started running. Unfortunately, this count resets to zero after approximately 9 hours and 32 minutes. I have written a millisRollover() function that detects these rollovers, so that programs can respond properly to the overflow event. This can solve problems with servo routines, steppers, timed pauses and a variety of other calculations. In addition, because my millisRollover() function counts the number of times rollover has happened, it is now possible to record total Arduino runtime with a counter that’s good for over 35 years.
You want to blink an LED only on Christmas during leap years? Totally possible now.
(yes, there really is a millis police department)
ATRE Command Brings Sanity:
When putting an XBee into a project and doing the configuration from software code. I often have the problem of some crazy sleep mode or pin definition going on that I didn’t know about. So now, all my functions for setting up an XBee start with the command ATRE. That resets the radio to factory defaults before issuing the remainder of the setup commands like ID, MY and so forth. As long as you don’t write the settings back to firmware with WR, the factory reset is transient. As soon as that radio loses power, it goes back to whatever unique settings it had before you ran your program. Pretty handy if you’re popping the same units back and forth between hard configured Direct I/O mode and software configured applications.
New Ember ZigBee Coming:
Looks like Maxstream is coming out with a new line of ZigBee radios. These will be based on the Ember chipset rather than the current one from Freescale. The existing XBee radios will continue to be manufactured and fully supported in the 802.15.4 mode that we use here at ITP. For the ZigBee layer, it looks like that will mainly be developed on the new XBee Series 2. Inside information is that the AT commands and API will essentially match the current one. All good news.
Cookware Antennas:
One of the many reasons I can’t wait for my thesis to be done is so I can try out New Zealander Stan Swan’s method for repurposing “Asian cookware scoops” into parabolic WiFi and ZigBee antennas:
He claims that by using these #13 cooking scoops with an XBee Pro, the signal range would be theoretically only limited by the curvature of the earth. Wow! I wonder if by using a giant #13 spatula to flatten the earth, I could further extend this range…
I’ll be teaching a new course at ITP in the Fall that examines collaboration on wireless networks. Students will create experimental devices and connect them together. Here’s the official description:
Collaborative Mesh Networking
H79.2672 (Robert Faludi) Wednesday 12:30 p.m. - 3:00 p.m.
Modern devices no longer need to be isolated. Recent advances in wireless mesh networks have created the potential for a massively interconnected world of easy information sharing. Cheap communications, high reliability, unique addressing, small size, efficiency, standardization, broadcast options and routing features combine to enable exciting new interactions. Developers of toys, wearables, performance devices, portables, network objects and sensor arrays can take advantage of radio mesh networking to design more interesting, better informed and more complex behaviors for their projects. This course explores devices that connect with and respond to each other. The technical focus will be on 802.15.4/ZigBee wireless mesh networks. Interconnections with other platforms and devices will be examined as needed. Students will gain an expertise in all functions of the ZigBee system to facilitate smart and novel behaviors in their projects. Through a series of accessible weekly exercises, students will build skills and explore the challenges and delights of mutual connectivity. As a final project, the class will construct an dynamic device network. Most labs and projects involve group work, so students should be ready to collaborate extensively as they experiment on the cutting edge of device interaction.
Slinky Metronome Proof-of-Concept
The initial proof-of-concept for the Slinky Metronome, a Sociable Object for my thesis, is complete and it works. It uses a Slinky spring toy as a pendulum. An accelerometer at the base of the Slinky tracks the (primarily) sinusoidal movement as the bottom of the spring rises and falls. An Arduino microcontroller processes the Z axis from the accelerometer to figure out when the pendulum phase shifts from negative to positive, signaling a beat. The current code then takes this information and sends out those beats with measure codes over a XBee 802.15.4 radio.
The idea is that different musical and art projects in the same space can use this metronome wirelessly to coordinate their sounds, motions and lights with each other. The result should create a diverse orchestrated work where the whole is greater than the parts.
The current proof-of-concept leaves the electronics off-board, with only the accelerometer on the bottom of the Slinky. The next prototype version will use a printed circuit board, bigger Slinky and place all of the electronics radio and battery in a lightweight case that rides along at the base of the spring. Here’s a schematic for the new system:
Metronome Schematic
And a movie showing the metronome sending to a simple Processing program that wirelessly claps along in time:
Click to play movie
The XBee time clock is back up and running on the ITP floor. It has been changed from a broadcast to a responder model. This is both more efficient generally, and faster in practice. The new PIC code for the clock is matched with new sample Arduino code that any project can incorporate to pick up accurate Eastern Standard/Daylight Time. This is the first of my series of Sociable Objects.
TECHNICAL INFO:
To get the time, set your XBee to:
- PAN ID: C
- Destination Low: 1
- My Address: 0
Then send “GET”. You’ll receive a time string is in the following format: *20061003143227 where the year is 2006, month is October, day is the 3rd, hour is 14 (2 p.m.), minute is 32 and second is 27.
The clock also broadcasts the time in human readable format once per minute to all addresses on PAN ID CC.
Every hour, the system grabs a time update from the National Institute of Standards, and adjusts itself accordingly so that its signal is always accurate.
XBee Broadcast Time as received by Luscious Electric Delight - click for movie
(L.E.D. created by Leif Krinkle with Rob Faludi and Benedetta Piantella)
The real-time clock which broadcasts time to the entire ITP floor via XBee ZigBee radio is now complete. Its time signal can be picked up by any project on the floor that incorporates standard 802.15.4 radios, and used for anything from time display to inter-project synchronization. The XBee Time Broadcast Clock code is written in PIC Basic Pro. It now incorporates regular updates from NIST servers. Time is stored and maintained locally on a DS1307 real-time clock chip, available on a convenient breakout board from Spark Fun.
Schematic of XBee Broadcast RTC Clock (essential components)
To pick up the signal at ITP, simply set the PAN address on your XBee to C or CC (the c is for clock). The signal is simultaneously broadcast to all 65,534 addresses within that network. PAN C is in a human-friendly format and PAN CC is formatted to be easily machine-readable. Here’s sample Arduino code for reading and parsing the real-time clock broadcasts.
This project is the first in a planned series of objects that will create an “information landscape” at ITP. Each object will provide information that other projects and objects can use, along with publishing actions which are publicly available so that the object can be externally controlled.
New Micros makes an nifty yet expensive XBee Dongle carrier that plugs an XBee radio directly into your computer’s USB port. It’s also available bundled with an XBee Pro. The schematic indicates that the hardware handshaking pins are connected, so this dongle should work for firmware upgrades as well.
XBee radios can now record and output multiple channels of digital and analog data without using microcontrollers. The latest firmware (version 10A1) supports up to seven channels of analog input, nine channels of digital I/O and two channels of analog (pulse-width modulation) output. These will be great for creating small sensor modules or miniature output modules with low power and very low complexity.
Andrew Schneider and I cobbled a couple experimental modules together last weekend, and I recreated them for a demonstration to my Project Development Studio class. Here’s the presentation on XBee Direct that I gave to the class. Firmware updates can be performed with MaxStream’s X-CTU software, and you’ll certainly need to do this if your XBee’s were purchased before 2007.
Direct I/O should be considered for wearables, remote controls, toys, covert sensors, computational jewelry or anything airborne. Photos of the input and output circuits are below, along with the AT commands for this setup, with one analog (potentiometer) and one digital (switch) input, and the corresponding outputs (motor & LED):
INPUT MODULE:
ATID3456 –> PAN ID
ATMY1 –> my address 1
ATDL2 –> destination address 2
ATD02 –> input 0 in analog mode
ATD13 –> input 1 in digital in mode
ATIR14 –> sample rate 20 milliseconds (hex 14)
ATIT5 –> samples before transmit 5
ATWR –> write settings to firmware
OUTPUT MODULE:
ATID3456 –> PAN ID
ATMY2 –> my address 2
ATDL1 –> destination address 1
ATP02 –> PWM 0 in PWM mode
ATD15 –> output 1 in digital out high mode
ATIU1 –> I/O output enabled
ATIA1 –> I/O input from address 1
ATWR –> write settings to firmware
Input Module with Potentiometer and Switch
Output Module with Vibrator Motor and LED
