Tuesday, November 15, 2011

Start Small. Make History (Farm School Testbed)

Originally this post was slated to be a cut-and-dried show and tell describing our live pilot at The Farm School, but the developments over the last 16h at Occupy Wall Street, NYC, and some of the awesome guerrilla reporting that's been happening, provides some perspective for us developers that refuse to let anything be done until it's "perfect".

The particular story I have in mind is that of a liveblogger named Tim Pool, of TheOther99, who has been streaming live now from lower Manhattan for about fifteen continuous hours.  The part I love about  Tim and his stream is how he has cobbled together an ultra-simple technical solution with free services and has been debugging the setup and learning the tech in real time with a live audience.  Over the course of the stream, Tim sources replacement batteries from the viewing audience, takes technical suggestions from their text stream, and works through mini-crises  like his phone number getting posted to the internet (oops!) to keep his stream live.  By the time of the pivotal hearing verdict at nearly 5pm, he amasses an arsenal of equipment spares, has over 100,000 viewers, is being rebroadcast by major networks, and has a pro-level live video rig on the way (donated) from ustream.tv.

When we're sitting around (on Skype) at Fabfi repeatedly pondering the intricacies of "perfect" security and "fully-automated" setup, we would certainly do well to take inspiration for the model of, "get out there now.  Sort the details later".  This was, in fact, the way we ran the show for Fabfi 1-4 (there hasn't been a single version of Fabfi yet where I knew exactly how it would work when I arrived on location).  With all this "planning" we've been doing, it's easy to forget that the best way to do user-centered design is to design some stuff, subject a whole bunch of people to it, and make rapid changes based on real data.

Every time we've gone live at a new site in the past we learned four dozen new things in no time at all, but in our latest iteration we've been thinking so big (1000 nodes), that we've been neglecting the value of a small  live test for some time.  What can five or six nodes tell you about a network that scales to a thousand?  As it turns out, quite a bit...

Over the past two weeks I've been working out at The Farm School building a small FF5 testbed.  Despite being little more than an hour from Boston, this site has a lot of the features we might find in a developing area:  A DSL connection provides only 3Mbps of capacity, many of the residences (staff live on the farm) are entirely off-grid, and small buildings provide little opportunity for high mounting points without significant investments in mounting poles or hardware.  About a dozen users reside at the site full-time, with day users potentially doubling that number.

Keeping with the theme of approximating developing areas, I went out of my way in this deploy to minimize the additional mounting hardware I brought to the table, instead mounting nodes on existing structures with materials I was able to scrounge on site.

Here's some field-test porn:

Wireless gateway node (101):


 Off Grid Nodes:


Node on a (stationary) bus:


Live map:


Within moments of installing the network, we began to learn new things about our system.  Here's the highlights:

  1. The largest time investment in node installation comes from mounting solar panels.  For the panels to be effective they must be mounted at a relatively accurate angle and direction.  Working this out with "found" supplies is tedious and slow, even with power tools and a lot of experience.  
  2. The AP+ADHOC single radio config that worked for us in bench tests, had very strange behavior (>95% packet loss on one link)  when three nodes were live with connected clients.  This was resistant to all sorts of RTS/CTS configs and was remedied by either dropping out the third node or separating the AP off to a separate radio.  We're unsure whether this was due to the shift to a real environment or a change on the ath9k driver between builds.  
  3. You need more solar than you think.  I originally believed would be possible to sustain a routerstation with two radios on as little as 48 Watts of solar at our site and a 10Ah battery.  In practice, even our setup with 80W of panel and a 14Ah battery had difficulty after a few cloudy days.  (likely more battery is needed).  130W and 24Ah seems to be more than sufficient if there is no sun obstruction, but we have plenty of that...
  4. <(expected) sad face>RS devices are not tolerant of brownouts, and require manual power-cycling after low-voltage condition
  5. 2.4Ghz speeds are more than double those of from our urban tests, and signal strengths below -75dBm provided useful speeds.  

The new network has a number of useful features that were missing from FF4, namely a live map, which clicks though to network statistics.  Nodes automatically add themselves to the map and stats interface.  This interface will be steadily improved over the coming weeks.

At the moment, the network is operating  with un-encrypted open access, but Antoine promises that his new "portalgun" access controller is but days away.

more to come...

~Keith

No comments:

Post a Comment