From Emerging Technologies in Location-Aware Computing


Arlene: Where the Hel? (working title)

I'm developing 2 mobile helmets that will visualize proximity as a function of signal strength, via an LED light strip. If there's time, I would like to add GPS modules and more fine-grained visualization output (via an iOS mapping app?). These helmets are potential iterations towards a more developed HADR (Humanitarian Assistance and Disaster Relief) helmet system. Click the image below to watch a concept movie. Documentation of the development process follows.

WhereTheHel Screenshot.png

ROUND ONE: Experiments with Brian's Zigboard (AT86RF230/1-based system)

Brian gave me a couple of his Zigboards to play with. The working hypothesis was that we could build them into the helmets. After some minor struggles, I set them up on my Mac Pro, see below. Brian's wiki directions are very good.

P 00296.jpg

I tested the Zigboards using this script, a simple adjustment of the python script on Brian's wiki. So far so good.

import zigboard

zb = zigboard.ZigBoard()

# If you have multiple devices connected to the same computer, you can
# select which one to talk to with its serial number (find this through
# Apple System Profiler, for example; omit the '' from the front:

zb1 = zigboard.ZigBoard('463033343837150D1C22')
zb2 = zigboard.ZigBoard('4630333438371508150D')

# Sending a packet:
# arguments are dest addr, dest pan, data

zb1.send(0x1011, 0x9002, "foo bar")
zb2.send(0x1010, 0x9002, "foo bard")

# Non-broadcast packets return True if an ack was received, False if no
# ack (broadcast packets do not generate acks and always return true)

# You can broadcast to all nodes on a PAN by using the address 0xFFFF,
# or all nodes on all PANs (careful!) with address 0xFFFF and PAN 0xFFFF

zb.send(0xFFFF, 0x9002, "hello everyone")

# receive gets received packets... it returns a packet if there is one,
# or none if no packets have been received.

one1 = zb1.receive()
two2 = zb2.receive()

# The data fields on the received packet object contain metadata about the
# packet and the data payload.


# RSSI/Energy detection are also available

# energy detection value/average RSSI for the packet
print one1.ed 
print two2.ed

# based on correlation of symbols, predicts bit error rate
print one1.lqi 
print two2.lqi

Then I attached the Zigboards to the Mac with super long USB cables. That worked ok, though sometimes there were disconnection issues. However, the long USB cables don't provide enough slack to really change link quality index or energy detection when the Zigboards are moved around the room. Also, when I tried to connect the Zigboard to a USB wallwart, its green light starts blinking and it won't connect. Brian explained that the networking protocol is still a work in progress.

At any rate, the Mac Pro is too big to strap to a bike helmet! So I set up the Intel Atom to possibly run the Zigboards. I'm trying to get a hold of some even smaller computers (Raspberry Pi) to run them.

2 Questions about the Atom (answered later by Brian).

  • Do you add a hard drive to it so that it won't need to boot from the USB stick every time?
  • How did you de-couple the compute module from the carrier? Also, do you have any spare Atoms already encased in your altoids-like boxes?

To these questions, Brian explained that the Altoids tin is a completely different platform called Fish River Island (FRI); it's not just a compute module in a box.

I'm now struggling with deciding on next steps for my helmet project, especially as it pertains to the remaining time in the semester. I would ideally like to have helmet-based mobile transceivers, without base-stations, outputting proximity data that is visualized by some LEDs.

It seems that it may be more straightforward to do this with some Arduino Xbees. On the other hand, I think the zigboards are really cool and I'd like to contribute to the project if there's a need. UPDATE: I'm ordering some Arduino FIO boards, XBee series 1 radios, and Parallax GPS modules for the next round.


For the final project, I will 3D print a "pretty helmet" and bundle an Xbee radio and GPS device into it. A second Xbee/GPS set will be bundled into a "plain helmet." A cyclist wearing the plain helmet will be charged with finding a cyclist wearing the pretty helmet. The major phases for this project involve setting up Xbee communication and indicating signal strength between them, setting up GPS tracking on the helmets, and printing a pretty helmet. Since I don't yet have access to Parallax GPS devices, I will use some iOS devices for the purposes of this project.

ROUND TWO: Setting up an xBee RSSI meter

In this round, I'm using a couple of Series 1 Xbee radios combined with a couple of Arduino Fio boards. Arduino Fios are built for Xbee radios, no additional shields required.

Xbee RSSI meter.png

Click to see xBee RSSI meter in action

R-click to download Helmet Emitter Arduino Sketch (for pretty helmet)

R-click to download Helmet Emitter Arduino Sketch (for plain helmet)

  • Right now, this sketch maps about 5 meters to a 10-LED series (values of up to 50 from the XBee RSSI pin). The sketch can be modified to map up to 200 meters (values of up to 200 from the XBee RSSI pin).
  • The sketch is also a little noisy at the moment. To-Do: dealing with zero values (which are outputted seemingly randomly at all ranges) and perhaps decreasing frequency of processing.

Helpful Xbee + Arduino Fio links

ROUND THREE: Setting up iOS GPS tracking

I set up a quick app on my iPod touch to be tracked using its internal GPS module. I'm using a GPS data service called InstaMapper. It's sending its position every few minutes. A web visualization using the Google Maps API is below, you can see it live at


It's a little spooky to be seeing my tracking visualized.... ack!

ROUND FOUR: Preparing a funky helmet

I'm also modeling a funky helmet to be tracked. An image of the model is below. It will hold the iPod Touch (GPS module) and Arudino FIO in the back hook.

I modeled the helmet in Maya and scaled it in Pleasant3D. Here's the STL model: