A Sensor Network Walkthrough: ONA 2013
This is a guest post by Julie Steele and Kipp Bradford of Senselab. They are the creative technologists who built the network of sensors that were set up in the keynote room at the recent Online News Association conference in Atlanta. The project was a partnership between the Tow Center, WNYC, ONA and Senselab.
The ONA conference was a great opportunity to illustrate the possibilities of using sensors to collect data about the world. While demonstrating the technology and discussing the state of the field, we could also push our own understanding forward, and share some resources with the digital journalism community. At the end of the conference we held a discussion panel, where lots of people wanted to talk about how they could get started, ideas about accuracy and meaning, and some of the privacy implications. We wrote a post on those topics, published just after the conference.
This post by Senselab details what they built and how, the lessons they learned, and what conference delegates learned. We’ve also linked to board designs, code repositories and a bill of parts.
What We Built
The sensor network we deployed at ONA had 30 separate ‘motes’ each collecting temperature, RF activity, motion sensors, audio levels and undifferentiated air-quality. We also had a single unit at the back of the room logging MAC addresses. With the Tow Center and WNYC we chose this combination of sensors because we wanted to sense what people were doing (moving about and using their cell phones) and what people were experiencing (warm and cold patches, air quality). The MAC address logger was included as a way of talking about privacy and surveillance. The whole network was administered by a single computer, which controlled each mote, knew its position, processes the data and uploaded it as a json file to Dropbox. The WNYC’s data news team pulled the data off Dropbox and visualized it on a webpage which the ONA projected onto the big screens in the keynote rooms.
In comparison to other networks that Senselab has deployed around conference venues, this had far fewer motes, but it was the first time we’d deployed them so densely; getting a smaller picture, but at much higher resolution.
The boards that we brought to ONA are the third generation of a wireless sensor mote that originally used Arduinos and XBees along with a number of off-the-shelf sensors. The previous generations of sensor devices required power outlets to run. We decided to develop a battery-powered sensor device this time around, because crawling around looking for outlets is even more of a pain than you imagine it is.
The battery-powered devices required low-power design techniques, which brought us to the Texas Instruments MSP430, a low-powered processor that can be programmed using an easy programming tool called Energia (a fork of Arduino). Kipp designed our circuit boards in Eagle, manufactured them in a day with Advanced Circuits, and we assembled the boards in an afternoon with parts from DigiKey and Mouser. Low-power design really means looking carefully at what specific chips and sensors we were selecting, and also looking at how those sensors will be used to determine the overall power draw and whether it can be managed.
For example, the air quality sensor we used (generally a power-hungry sensor) has an on-off switch. The other very power-hungry device on the board is the wireless; we ultimately chose XBee Pros because they can transmit a mile with line-of-sight, and we wanted to guarantee that we could still get our signals through, even with people filling up the venue. But that was a trade-off, because the XBee Pros use a lot of energy compared to the regular XBees. So we spent some time considering the architecture that would give us the longest battery life and still do what we needed it to do.
How We Built It
In the first iteration of our motes, we hand-soldered everything in the office of a friend; in the second iteration, we paid for automated assembly because of the large number of boards involved. This time around, we had a small enough batch again that hand assembly was the best choice. But we used a combination of stenciling solder paste (for the resistors, capacitors, and other small surface-mounted pieces) and hand soldering (for the larger and through-hole pieces).
As in the past, we used a custom-designed Printed Circuit Board (PCB). Kipp designed this in Eagle and sent it off to [?] for production. Then three of us (Kipp, Julie, and Veton) basically had an assembly party. It started off with lots of boxes and bags of parts.
Since the circuit boards came printed in sheets of six, we each assembled six motes at a time. Kipp took the circuit diagram and blew it up, printing it out on 11×17” stock for each of us. Then we used that as a template on which to place six of each tiny component (and we mean tiny: we used tweezers to remove most components from their packaging and place them on the paper guide). Once all the parts were laid out, we were prepared to begin assembly.
The easiest way to solder three-dozen tiny, tiny pieces at once happens to be with solder paste. Many PCB manufacturers allow you to order a stainless steel stencil with your boards (some complimentary, some for a small additional fee) that fits into a jig. The PCB sheet is laid in the jig and the stencil is folded down over that, exposing only the board’s contacts. Solder paste can then be squeezed out in a line down one side of the stencil, and pulled across using a squeegee or a knife of some kind. When done carefully, this will leave a thin, even coating of solder paste on the board’s contacts without getting anywhere you don’t want it to be.
After applying solder paste, we took a PCB sheet back to our desk and began the process of picking up each component from our template (once again with tweezers) and placing it on the boards. This was a painstaking process that took a bit of time, but the second board sheet definitely went faster than the first. You can make this process go much faster if you have a few tens of thousand dollars to invest in a pick and place machine to do this work automatically. But it’s a little like baking: sure, you can use a mix from a box or just go to the bakery, but before you avail yourself of those shortcuts you should really bake something from scratch so you can understand the process from beginning to end. This part of the assembly might have been old hat for Kipp and Veton, who have done this many times before, but for an electronics newbie like Julie is was a good experience and something akin to a chore for the Karate Kid (imagine chopsticks and grains of rice).
Once all the components had been placed, the PCB sheets went into the oven (see—baking isn’t so far off). You can do this step in a regular, run-of-the-mill toaster oven, which we did. It goes in for about 10 minutes at 200F to warm up, and then gets 4 minutes at 325F and then at 450F until the solder melts. When the boards come out, the milky-looking substrate in the solder paste has evaporated, leaving only a shiny, sturdy solder joint that looks just like what you’d get from hand-soldering—only neater. Miraculously, and squishing out or accidental bridging of the solder paste that occurs when the parts are pushed onto the board manage to heal themselves by the miracle of surface tension. The finished boards are beautiful.
Next, it was testing time. It’s pretty common for there to be a manufacturing glitch or an assembly glitch somewhere, so before we went and added all the additional parts to the whole batch of boards, we just wanted to make sure that one board was working. Kipp made a quick stop at the soldering station to add the through-hole components: headers for the XBee radios, our PIR sensor, programming, and other purposes; our air quality sensor; and the microphone.
One of the pieces we had placed during our solder paste extravaganza was the TI MSP430, a 16-bit, ultra-low power microcontroller platform that we decided to use this time around instead of an Arduino Leonardo, because of the low power advantage (hooray for battery packs instead of crawling around on your knees to find dozens—or hundreds—of outlets). So to test the board, we just plugged it into TI’s LaunchPad, a separate board with on-board emulation for programming and debugging code. It turns out that we did have a glitch or two, but luckily they were all in our software: easy enough to correct.
In the end, we had a 100% board yield: 30 out of 30 worked perfectly. We have not always been that lucky. This was a win. Then it was back to the soldering station to add the through-hole components to the entire batch of boards.
What We Learned
With any data collection project, there are the things you expect to learn and the things you end up learning by accident. This project was no exception.
What the Data Said
In a large room the size of the ballroom at the Atlanta Marriott Marquis, we expected to find hot spots and cold spots throughout the room (caused by clusters of people, placement of air vents, and other similar factors). Indeed, we did see gradients of temperature. These shifted subtly as the room filled up, but cold spots tended to remain cooler than the rest of the room.
We also saw areas of variation in mobile phone use. Our RF sensors were tuned to 900MHz, the frequency band used by most GSM phones in North America. When individual motes sent back high readings for RF data, they were probably next to a person or a few people who were sending lots of texts. However, we can’t know that for certain; it’s possible that an audience member had WIFI turned off, and their phone was pulling data in the background.
In both of these examples, the motes really only served to indicate what we already suspected: the temperature in large rooms is uneven, and people don’t always pay attention during conference talks. Not that surprising. But knowing where those things were happening at any given moment in time was pretty cool—sort of like a superpower.
What the Data Didn’t Say (aka War Stories)
Of course, all superheroes have weaknesses. As with any hardware project, things went wrong. (We prefer to think of these as lessons learned.) Whatever you call it, there are a few things we’ll do differently next time.
Seeing the Signs
Signage remains an important part of the deployment, and has also evolved with the sensor motes. While we’d like to think that most of the attendees at the conferences we’ve instrumented are savvy technology types, the fact remains that naked circuit boards with lots of wires protruding from them still scare people. At every event we do, we inevitably have one or two nervous people sidle up to our table and ask some version of, “That’s not a bomb, is it?” Eye-catching signage that explains what the sensor motes are, what they’re doing, and where more information can be found—boldly emblazoned with the official conference logo—is the best reassurance we can offer. It has the added benefit of making the sensor motes bigger and more noticeable, decreasing the chance that people will step on them or otherwise harm them.
For ONA, we purchased off-the-shelf, clear acrylic brochure holders with room for a letter-sized insert sheet; the attached brochure pocket was the perfect size to hold our sensor motes. This seemed like a brilliant solution to our previous signage problem(s). The paper table-tents we used in the past were a bit flimsy; these were sturdy. The paper tents required manual folding and gluing; these were ready-made. The paper tents were low to the ground (out of necessity, to lower the center of gravity so they wouldn’t tip over); these were 11 inches tall (and thus more visible on the floor) and self-supporting. Big win, right?
Well, we thought so too, until the motes had been running for a while. We thought that the open side of the brochure pocket would allow enough airflow for the sensors to work properly (one concern we had with a full enclosure—another solution we considered—was that there wouldn’t be enough circulation for the temperature and air quality sensors to do their jobs). We were wrong. In particular, the air quality sensor we were using generates enough heat that it was throwing off the temperature sensor, even though we had taken steps to remove them as far as possible and to elevate the air quality sensor off the circuit board to get lots of airflow around it. Once we stuck the whole mess into a five-sided acrylic box, everything just got warm.
We ended up solving this by just leaving the air quality sensors off for almost the entire measurement period; the temperature readings were more important to us. As one of our team members pointed out, the acrylic would probably have thrown off its own VOCs and artificially inflated the air quality sensor readings anyway.
Another issue with our acrylic sign holders was that the PIR sensor was unable to detect motion through the acrylic (not really surprising). We were able to solve this pretty easily by mounting the PIR sensor on the outside of the brochure pocket with adhesive hook-and-loop squares. We were only able to do this, though, because the PIR sensors were attached to our circuit boards by several inches of wire. The air quality sensors were soldered to the boards, so we couldn’t move them this time around. But next time, if we decide to stick with the off-the-shelf acrylic sign holders (which we might because of their other relative strengths), we’ll wire the air quality sensor separately and mount it on the outside with the PIR sensor.
The air quality sensors that we used generate a combined volatile organic compounds (VOC) and particulate matter (PM) reading. And even the PM measurements weren’t broken out into fine and large particles. This matters – when you get high readings of undifferentiated air quality contaminants you might know that an area is unpleasant, but you can’t understand specific health risks or broken laws. An undifferentiated reading could come from fine particles below 2.5 microns (aka PM2.5) which represent higher health risks than if the readings are caused by PM10, or VOCs.
A Hotel Room is not the Real World
After a late night spent writing code upstairs in a hotel room, we brought everything down to the ballroom to deploy it and… it immediately broke. Lesson learned: a hotel room is not the same thing as the real world. The deployment environment matters—a lot.
Fortunately, we were able to fix the code. It took some detective work first: layers of sensors, software, and networked radios meant that it wasn’t obvious where the problem(s) lay. We were fortunate to be able to call on the expertise of some friends (Jer Thorp was a huge help on Processing, and Rob Faludi offered some key insights on the XBee radios). We ended up with code that was much better and more robust, but it was a frustrating experience to think that we had everything working and then find out we were wrong. Always be testing. For real.
What Others Learned
We went in to this project intending to research and report on concepts like: What is sensing and what can it do? What are its limitations? How does data sensing tie into ideas of surveillance and privacy? How accurate is the information you can gather from sensors? What does it mean to deploy physical things: property rights, protecting hardware from the environment? In a panel session on the last day of the conference, we got to discuss all this and a bit more.
The maker community is uniquely well poised to help out the journalism community on these issues. The tools of makers are sophisticated engineering tools that have been wrapped in easy-to-use skins, and they’re very powerful when they’re brought to bear on journalistic questions. Journalists can get information that doesn’t exist yet when they can make the sensors they need. The maker community is making these tools much more accessible, much more affordable, and much more widely available.
Of course, these tools won’t be NIST-calibrated. They might not give absolute data. But they may be useful for giving initial indications of where to do more rigorous investigation, and for raising awareness. There’s a gap between sensing for awareness and sensing for scientific evidence, but one can lead to the other.
In talking about potential future projects, as well as considerations for the ONA project (such as signage), it became clear that public perception is one of the main limiting factors. Deploying sensors in public spaces can be tricky, since many people still think of circuit boards as something nefarious. Educating themselves about sensors and making—and then educating the public—is probably the biggest contribution journalists can make on this front, aside from actual data collection and reporting. Sensor journalism is still in its infancy, but the potential is huge—especially when makers and journalists work together.