Data journalism, meet sensor journalism. You two should talk.
What’s sensor journalism? I’ll get to that. But first, let me tell you a story about bugs — and a pair of gadgets that sat for months in a box under John Keefe’s bed.
Keefe, senior editor for data news and journalism technology at WNYC in New York, said by phone that he had bought the Arduino microcontroller and Raspberry Pi with great excitement, played with them for a weekend, and then boxed them up. But he kept kicking around ideas about what you could do with a small computer paired with sensors or other devices. And when asked what WNYC was doing about the 17-year cicadas that will emerge from the earth like insect zombies this summer, Keefe wondered if the answer might be under his bed.
Keefe learned that when the soil eight inches down reaches 64 degrees for a few days, cicadas emerge to fill summer nights with their songs. And so he asked himself: Could WNYC build a sensor to find out when they’re coming?
A few days later, at an internal WNYC hackathon, Keefe presented the idea of building a cicada sensor. He gathered a team interested in trying and took a field trip to Radio Shack. By the end of the hackathon, they had a device … and backing from the station’s managers. With proof of concept in hand, they moved on to how to make more cicada sensors and teach listeners to make their own. After beta-testing those instructions at March’s NICAR data-journalism conference, they announced the project at SXSW Interactive a few weeks later.
The Cicada Tracker has taken off from there: WNYC is now planning a pair of hack days: one where more than 250 volunteers will build sensors and another where New York schoolchildren will make even more cicada trackers.
The devices report the temperature of the ground, which reports plotted as colored dots on WNYC’s website. Click a dot, see the temperature. Volunteers hosting a device are asked to report in regularly. Dozens of people, from as far west as Goshen, Ind., and as far south as Jacksonville, Fla., are doing just that, with more dots added to the map all the time.
“The whole time, I’m thinking this is cool — a little ridiculous, but cool,” Keefe recalls.
But that’s part of sensor journalism’s appeal: It’s cool. And cool opens the imagination to other possibilities. This time it’s cicadas, but next time it might be pollution, or some other public health issue.
“There’s clearly technology to do anything we want to do,” Keefe says. “There’s just not enough people there bridging the gap. What’s missing now is the journalism.”
So what would that journalism look like? It’s too soon for any real definitive answers, but this post from O’Reilly’s Alex Howard might get minds working. So — I hope — will a little experiment I conducted on my own.
What sensors do best is detect characteristics of the physical world — properties such as light, heat, sound, pressure, vibration, air quality and moisture.
I’ve been interested in the idea of using a sensor network to detect noise pollution, answering in real time which neighborhoods are louder than others and exploring why. But in a decent-sized city that would take hundreds if not thousands of sensors. And would it even work?
Instead of talking about it, I decided to build a prototype.
For parts, I needed three things: a sound sensor, a computer brain to run it and a place to store the data.
The best-known tool of the open hardware movement is the Arduino, which costs about $30 and fits in the palm of your hand. It’s a microcontroller that can run on a little bit of electricity and control simple things, such as sensors.
Then there are “shields,” which are other circuit boards that do something and plug straight into the Arduino, no soldering required. They can cost anywhere from a few dollars to more than $100, depending on what they do. I have an Arduino Ethernet Shield, which happens to have an SD card slot on it — a convenient place to store a bunch of data.
The sound sensor that I bought — really a microphone and a tiny amplifier — cost $7.
The wiring for my little prototype was super simple. It needed power — so first I soldered red wire to the 5v spot on the sensor and plugged it into the 5v pin on the Arduino. Then I soldered a black wire to plug into the Arduino’s ground pin. And then the data output wire went into an analog serial port where the values coming from it could be read. Through the software uploaded to the Arduino, the output value gets recorded. The program says, basically: read the sound sensor data from the wire, write it to the SD card, wait a tenth of a second, then do it again. Rinse. Repeat.
After testing my device, I plugged it in and placed it in the lobby of the College of Journalism and Mass Communications at the University of Nebraska-Lincoln. It’s not a loud place, most of the time, and it’s not a truly quiet place, most of the time.
For hours, my device kept recording data: 707,122 times, to be exact, for a total of 1.96 hours of readings (at a tenth of a second each). Looking over the data, 684,811 times my device recorded … nothing. Meaning that for 1.9 of the 1.96 hours of the sampled data, things were pretty quiet around it. (That doesn’t mean it was silent. It just means my sensor didn’t pick up any noise.)
For the other samples, most noise levels were between 1 and 15 on the sensor’s scale. To put that in perspective, my speaking voice five feet from the device measures between 6 and 9, and clapping my hands five feet away is between 50 and 70. There were seven readings between 50 and 70 throughout the day, almost certainly the front door closing at the precise moment the sensor tuned in for a listen.
A graph of the readings shows the range of the values, but leaves the impression that it was noisier than it was. Remember: 97 percent of the time, the sensor heard nothing. In an academic building’s lobby, that’s not surprising. If this were at a construction site, I’d question the results.
So what did I learn? I learned it’s possible to monitor noise for five hours using a battery pack. I learned my sensor might not be sensitive enough — I should spend more than $7. I learned my code would keep writing out data, even when that file started to get big — it’s 2.1 megabytes of text.
And most importantly, I learned we can do this.
And right now, that’s a key lesson: We can do this, so what stories should we be chasing? What’s possible? What’s feasible?
One of the things that intrigues me about sensor journalism is its potential for crowdsourcing — letting people help sense changes in their local environment. We can build ideas that let people know data about their own location, and feed that data into a greater whole.
For instance, with our noise sensor, we could look at noise by neighborhood. Are poor neighborhood louder than rich neighborhoods? That would have public health consequences. (To oversimplify: noise causes stress, stress causes heart problems, heart problems cause death.) Or we could evaluate how zoning changes or road construction alters daily life in a neighborhood.
Want another example? UNL student Ben Kreimer and I built a device that sensed how my luggage was being treated as we travelled to NICAR this year. Our device was simple — an accelerometer similar to the one in your smartphone that you use to play video games that sent data to an SD card. It recorded data all the way through the check-in and loading process, with the battery dying as the plane started to taxi. Our data showed us that 1) the parking lot of the airport is a terrible surface; 2) the TSA pulled the device out of my bag to look at it; and 3) your bag mostly sits, going nowhere, until it’s time to get on the plane. Then? Wham!
And that left Ben and I thinking … what’s next? We have some ideas. So does Keefe.
And that’s what’s needed right now — ideas. Journalists thinking about stories they could tell if only they had some data. Which, as stories like ours show, they can get with relatively little money and effort, if they’re willing to veer well outside the usual tools journalists work with.
“The more we show people, what else can we unlock?” Keefe wonders.