Radio vs. WiFi

       vs.

Pictured above, two ways to skin a cat. Or, in our case, two ways to transmit data from a sensor in the ground to a computer in the classroom. On the left is an XBee, a small radio that attaches to an Arduino via a shield; two XBees can send/receive data. On the right is the Arduino WiFi shield, which connects to the Arduino and sends data via an available WiFi network. After running into a little bit of frustration* with the WiFi shield at this week’s Code For Philly meetup, our group started talking about some of the fundamental decisions we made about data transmission. Below are some pros/cons for using an XBee (or a Wixel, or some other similar radio device) versus a WiFi shield. For the record, the cost is similar—a WiFi shield is $85, two XBees and its shield are around $75.

The nice thing about XBees is that they can be used anywhere. They don’t need access to a wifi network. You can also use multiple XBees to make a mesh network if, say, the rain garden is a good distance away from the school. (The book Building Wireless Sensor Networks by Robert Faludi is a bible in this regard.) On the other hand, weather—especially storms, when we most want to see the data—may affect the transmission. And XBees must be used in pairs, which means an XBee must sit inside a classroom, attached to a computer, to listen for incoming data. We realize that not every classroom has a spare laptop to dedicate to receiving a radio signal. With XBee, there are two legs to the journey from sensor to Web: data transmitted to a computer via radio, then data transmitted from the computer to the server via WiFi (or Ethernet or however that computer connects to the Internet).

Just thinking about the WiFi shield makes me sad that Philadelphia’s dream of the ’00s—a citywide WiFi network—never came to fruition. Accessing a school’s WiFi network is no small feat; the School District’s IT department has to be on board with the initiative (luckily, Philadelphia’s School District IT people have been amazingly supportive of a pilot project). A WiFi shield requires no equipment to be housed inside a classroom, and there’s something attractive about a product that’s a single object, that takes care of business all by itself. Plus, WiFi just seems like … the future. Going forward, there will only be more WiFi access. So we’re sticking with the WiFi shield and will work out the error messages; it provides the most direct link to the Web.

And just as an aside, we’re not married to Arduino over here. There are other boards out there—more of them every week, it seems—that control sensors, connect to the Web, etc. We’re keeping an eye on what’s being developed. Behold, for example, the BeagleBone. Seriously, who names these things?

* “ERROR WEBrick::HTTPStatus::LengthRequired,” if you’re curious.