myObservatory (mO) for Empowering Communities – Part I (Natuf, near Ramallah, Palestinian Authority)

Providing tools for communities is an important part of our vision for mO.  Information is power, and it can be used in useful and creative ways to improve life quality, including reporting environmental hazards, documenting (and reporting in real-time) violations of environmental regulations, or monitoring of environmental resources. In this and in subsequent blogs, I will provide some insights into projects that tapped into such capabilities.

The Natuf Experience

How did mO get to Natuf? Well, we provided pro-bono support for a UC Berkeley project, a collaborative effort with Bir-Zeit University. The project is documented here: http://www.ce.berkeley.edu/newsletter/977

Jon Sege from UC Berkeley was the prime mover in this project. He travelled several times to the region, and established a network of contacts. I traveled there “by proxy”, meaning, looking around through Jon’s eyes and listening to his stories. To prove my point, here’s a funny story I heard from him (I cannot vouch for its accuracy). So one day a local branch of Starbucks was opened in Ramallah, much to the delight of local residents and ex-pats. People were queuing to get their fill of latte’ and other types of designer coffees. Then it turned out that this outlet was not an officially-sanctioned Starbucks, much to the chagrin of the local aficionados.. who decided to boycott the Starbucks wannabees.. How was this crisis in a cup of coffee resolved? The coffee outlet changed its name to Stars and Bucks.. and everyone’s happy again. I hope we have similarly quick resolutions of the other pending issues in that troubled area.

OK, back to empowering communities. So there is a detailed report developed by the joint Bir-Zeit UC Berkeley team. Take a look at it, it is pretty good (it would be provided upon request, write to me at yoram.rubin at webh2o.net). My favorite part is this figure (see below) that shows how an environmental hazard is recorded in the field, reported on a mobile app using simple-to-use forms, and then, with one press on the “Save” button, find its way to the Natuf web site where it is nicely displayed (geo-tagged, geo-dated, with pictures and notes)

Now, let’s extrapolate a bit. Imagine now dozens of reported being filed on a given hazard, or a water leak, or a traffic hazard... and a flag showing how long that hazard has been reported using some sort of a color code to denote the persistence of the hazard (like green for one day, yellow for up to one week, and red above that). Now this could translate into some timely response, right? This approach was not implemented in Natuf, so it is just an idea, for now.  We are waiting for someone to raise the flag, so to speak (just let us know if you want to give it a try).  

In the field, users can collect information on pollution hazards using a smartphone and upload it directly to the site. The information will be geotagged using coordinates from the smartphone’s GPS, and will instantly appear on the map in the location where the user gathered the information. The images above demonstrate the pollution hazard collection form for the Natuv risk map. While at the pollution site, the user fills in prescribed data entry fields to collect all necessary information, and can include notes and pictures taken at the site. The user then submits these data directly to the map, where the information appears as a clickable icon.

Even kids can do it!

An overview of building an atmospheric data logger using Arduino for use with myObservatory

Recently, it came to my attention that a particularly bright middle school student was interested in sensing the environment and using data loggers. This is a perfect mesh for myObservatory and its capabilities, and indeed we've built Arduino-based data loggers several times in the past.  I decided to assemble some basic hardware and write a quick blog post about it, in enough detail that someone could hopefully follow along.

Some of our past sensors have used SD-card storage and two-row LCD panels, while others have used GSM cellular connections to upload data in realtime. The former has the advantage of long battery life and being feasible to operate on solar power, with the disadvantage of needing to go retrieve your SD card to get your data (and you don't know when the battery has failed). The latter has the great advantage of seeing your data come through in real time, and knowing if there's a problem (due to the sudden lack of a data stream). The disadvantages are two: needing a data plan from a mobile carrier to use it with, and relatively enormous power requirements.

Thinking about these two approaches, I decided to create a hybrid - merge the idea of an SD card and cellular upload. This would let me record data every 5 minutes and save it to the SD card, then upload via cellular every 12 hours or so, hopefully reducing power requirements. Unfortunately this didn't end up panning out, due to problems with the SIM300 module that I tried to use for cellular connectivity. The final result of this build for the kits I'm sending the student ended up being just SD-card storage, but with an improved user interface leveraging a full-color 1.8" TFT display instead of the original 2-line LCD display.

So, let's get started! The first step is to assemble all the required equipment:

• Arduino Mega or generic equivalent (Uno is sufficient as well, if you're not doing cellular and TFT together)
• Optional: GSM modem shield; I tried Geeetech's SIM900 module in this build, and was unimpressed. The official Arduino GSM shield has worked better for me in the past.
• Optional: 2G-capable unlocked SIM card
• Adafruit 1.8" 18-bit TFT Shield with MicroSD and Joystick
• uxcell Sensitivity Control Temperature Humidity Sensor DHT11
• BUD Industries NBF-32018 Plastic ABS Enclosure with Door
• Generic 4AA battery holder
• DS1307 Real-Time Clock
• Battery holder and connector; DC barrel jack connector
• Various bits of wire
• Soldering iron and solder (and desoldering braid, if you're pessimistic about your soldering skills)
• Digital multimeter

I originally selected the Arduino Mega due to it's increased maximum program space of 256k, a requirement for using both the nice TFT display and the cellular modem libraries together. Without the cellular modem, an Arduino Uno (32k program space) is sufficient.

Some of the components don't always come entirely "assembled". Frequently, the pins of Arduino shields aren't shipped soldered on, so you just need to break off the desired number from the strip that comes with it, and solder those into place. If you're lazy, you can solder only the pins you need to use, but since you never know what pins might end up getting used by other stacked shields, it's wise to solder them all on - shouldn't be more than a 10 minute job. Remember to use a very hot soldering iron so you can minimize the contact time, and reduce risk of melting anything important. The TFT shield, after soldering on the pins, looks like the image at the left. Be sure to also connect the hidden "Lite" pin to D7, which will enable software control of the TFT backlight so we can turn it off when not in use.

Next, we can stack the shields onto the Arduino. In the picture shown below, I still have the (faulty?) Geeetech SIM900 module stacked in place. Be sure to align them properly and have them facing the correct direction - look for the pin numbers along the edge of the boards. Next, since we need to be able to tell what time it is when we save our readings, we'll work in an RTC (Real-Time Clock). This is a digital device that communicates over the I2C interface - so it will attach to the SDA and SCL pins. These vary from device to device; on the Arduino Uno, these are A4 and A5 respectively. On Mega, these are digital pins 20 and 21, respectively. These are connected to the RTC breakout via short wire segments that are removable (a theme you'll see throughout my builds). The power lines are connected by soldering to the TFT shield, and the I2C lines connect over to the Mega directly, since the TFT shield doesn't cover all the Mega inputs.

Next, we need to correct a few pin mapping issues. The Arduino Mega has its SPI interface on pins 50, 51, and 52 instead of the usual 11, 12, and 13 on Uno. So, if you're using an Uno, you can skip this; if using a Mega, we need to connect pins SCK, D1, and D0 to pins 52, 50, and 51 respectively. This is used for digital communication with the SD card portion of the shield; without doing this, the TFT display will work, but not the SD card.

Lastly, we need to attach a few more wires for the simple atmospheric sensor we'll use in this example. We'll attach two more lines for power - to the "5v" and "GND" - and one for sensor data, on pin 3. The completed assembly looks like these two pictures - again ignore the antenna and GSM card, which was unused in the final mailed-out version.



Next, we'll prepare the DHT11 atmospheric sensor, connecting it to a standard 3.5mm headphone-style jack, connecting VCC to tip, ground to the base, and data to the middle. We'll also drill a hole in the enclosure to allow the connector to slide through, and solder some wires to the headphone jack connector. Your multimeter is useful to verify what wires will connect to tip, middle, and base of the headphone jack and its connector. These are shown in the pictures below:



Finally, we can place the assembled components in the box and connect the wires. (The final version has printed labels instead of sticky notes!)  The box size is quite overkill. When ordering the box I neglected to account for centimeters versus inches...but on the plus side, there's plenty of room for documentation, a notebook, a big fat battery, etc. This box is also fully waterproof, and can be screwed to a pole. You'll see I've attached the board to the box via twist ties, and all components are very easily removable using black female wire connectors. I always try to make demonstration or prototype builds easy to change, soldering as little as possible, never using glue, and documenting what wires connect to what with tape labels. This makes tweaking and adjusting much easier.



The next step is to write the Arduino sketch that we'll upload to the board. The original version for this demo factored in the Geeetech cellular shield, but after every conceivable method of trying to communicate with it, I was never able to get the cellular modem to respond to the arduino board, whether I used a Micro, Uno, or Mega, and software or hardware serial, and every baud rate imaginable. The board also failed to connect to AT&T unless I supplied slightly more voltage than the documentation stated was required, which I felt was unsafe. For these reasons, the final version of this build has no GSM modem. In the future I may acquire a few alternate GSM shields to test with. The original Arduino-branded GSM shield works well, but I've found that hard to come by lately.

The logic for Arduino boards are called "sketches" by tradition, and basically tell the Atmel chip on board what to do. The language is based on C, and most standard C library functions are available for use. In particular there are two things to note when getting started with Arduino programming:

1. Every sketch must have a "void setup()" and a "void loop()". The setup function will run upon initial power on or reset, and after that the loop function will be run over and over endlessly.
2. Digital control is performed using "pinMode(/* Pin number */, /* OUTPUT or INPUT */)" to set the "direction" of data flow, and "digitalWrite(/* PIN NUMBER */, /* HIGH or LOW */)" to change the voltage of the data pin. digitalRead(pin_number) will read the current state of a digital pin. Also available are analogRead and analogWrite, which work in the same way, but accept float values instead of HIGH or LOW. The analog read/write functions will only work with analog pins, those preceded by "A".

The sketch for this example can be found here - and the software used to send the sketch to the Arduino can be found here. If you're interested in the cellular version of the sketch for uploading directly to myObservatory, get in touch with me or look at the older cellular example for inspiration.

Power in this version is provided via the barrel jack, which is connected to an AA battery holder. Power can be provided to the barrel jack in any voltage from about 5 to 12 volts, though 7 to 12 is recommended. Power can also be provided via the USB port, though the USB port power must be exactly 5 volts. As such, commonly available "cell phone power bricks" make a great power supply, especially the ones with large fold-out solar cells integrated.

This example is fairly bare-bones in having only a single atmospheric sensor, but serves as a good starting point for building your own solution. Additional sensors of a wide variety can be connected and used. One advantage of the Mega board over Uno, in addition to the increased program space, is a much greater number of digital and analog inputs, letting you connect a large number of sensors to a single device.

Have fun, and if you have any questions when building your own sensor devices, get in touch!

First storm

We finally had a significant snow storm!  No more whining kids asking, "When will it ever snow?"  Now we have three days of sledding and snowball making and snowman destroying in the books!

We are a storm family.  We spend pretty much any daylight hours (and many evening hours as well) outside experiencing the storm.  Before the snow started we ran out to the store for some last minute supplies: eggs, bread, and a new battery for the anemometer!  Throughout the storm we took wind speed readings from our driveway.  Since our house is tucked into the woods we typically observe far lower wind speeds that are reported for our town.  In fact, many new channels send reporters to our town beach and broadcast about wind and coastal flooding on the Cape.  While watching news coverage the day after the storm we noticed a weather report on national news from Sandwich, MA!

I used the myObservatory app to record snow fall totals around my yard.  I used the freeform sample method to collect my data.  The reason I did this was that most of my yard was trampled during the storm by three dogs two boys and an excited storm-loving husband.  There were few sections of the yard the morning after where the snow had not been trampled.  Using the freeform sampling campaign tool I was able to move around the yard to sections that appeared unspoiled to take depth measurements.

Nothing is more fun than involving the boys in data collection!  Will had a great time finding untouched spots in the yard and even practiced reading the measuring stick.  In our family, data collection is a family affair.  But it doesn't stop with data collection...we also love data analysis.  A typical evening is my husband and I playing with kids outside and diagramming spreadsheets on the garage floor with sidewalk chalk :) 

Tune in soon to hear about the data curation and publishing process and what we can see when we use the myObservatory desktop version to view our snowfall data!

Ski report

Loon Mountain Ski Resort reports that they have 10 inches of snow at the base and 18 inches of snow at the summit.  They also report having gotten 6 inches of new snow in the last 72 hours.  But I wondered how much snow they actually have around the resort.  Loon makes snow on 99% of their trails.  They boast a 2100 foot vertical drop with 61 trails and 12 lifts.  Being new to the ski world I hear a lot of talk about conditions and elevation and I wonder how accurate those portrayals are.  It seems to me that ski areas may pad their reported data to encourage patrons to make the trip from home and pay the exorbitant lift fees for a chance to fly down snow.  Do conditions dictate the number of patrons or is it more driven by the day of the week?

I used my Dual XGPS150A Universal Bluetooth GPS Receiver paired with my cellphone to improve accuracy of GPS tagged data.  This is particularly important in a remote location like a ski resort where some spots are completely out of normal cell phone range.  At the different points around the resort I pulled off the main part of the trail and made estimates (based on snow levels in the woods off the trail) of snow depth on trail, at the side of the trail and off the trail.  If I ever get the chance for a ski get-a-way again I plan to attach a measurement rod onto a ski pole so that I can get a measurement versus using estimated values.  I recorded my estimations in a Data Collection Form with the myObservatory mobile app.  I also recorded elevation at each location, GPS tagged observations of atmospheric conditions and GPS tagged photos of trail conditions and general crowdedness.

Day 1: Martin Luther King weekend Sunday seemed like a peak ski day.  We had to park in the "Escape Lot" and take a packed shuttle 2 miles back to the resort!  The general conditions were 29 degrees, mostly cloudy, wind 3-5 mph with no snowfall in the last 24 hours.  The wait for the Seven Brothers lift was significant and discouraging.  Skiers and riders cued up 5 lines wide each line 30-60 people deep.  And the ride for the gondola was so long we never even attempted it.  We put in our time and made the most of the crowds.

Day 2: Martin Luther King Monday was a day East coast skiers dream about.  No lines, practically empty trails, a bit windy on top but otherwise great cruising weather at 25 degrees.  With two-four fresh inches of powder and full blown snowmaking efforts the resort was open and ready for the few of us still around.  I was able to really enjoy myself unafraid of barreling over the hoards of patrons from the day before.  Gently falling snow; I think I just might love this.

How can we help with the World’s most urgent water problems?

Dr. Alberto Montanari is the editor of Water Resources Research, the “water” journal of the American Geophysical Union. In a recent REDIT Forum he was asked the following question:

And here is his response:

In short, continuous monitoring is a fundamental requirement for addressing water problems. This reminds me of one of our earliest projects, circa 2007, where we developed a comprehensive groundwater basin monitoring system for the Sonoma County Water Agency (SCWA), in California. We named our system SHIP (Sonoma Hydrologic Information System). SHIP allows SCWA personnel as well as others from the local water districts, well owners and volunteers to enter groundwater levels into a shared, web-based platform (check for EIMS here http://info.webh2o.net/)

SHIP had a nice 2-years run, data were collected, shared, plotted, stored, etc. See for example the map below. It shows the Sonoma Creek Groundwater Basin, the groundwater level contour map (in blue) and flow directions (in red arrows).

But there was a problem.. the water law did not require well owners to post data. And they were reluctant to post it. Posting data could disclose how much water is being pumped at a certain area, and could be used as a basis for enforcement of some kind.  The State of California made a bold move in that direction, when it initiated, in 2009, the California Statewide Groundwater Elevation Monitoring (CASGEM) program that mandates some monitoring. Our SHIP is ready to sail and to support this effort in California and everywhere.

Discover Magazine

One month ago today, on December 9th, myObservatory was featured in a Discover blog post.  Here is a link to the article.

Putting Your Data to Work with myObservatory

I thought it was a good thing to post here on this blog to show that others are talking about myObservatory also.  Over the next couple of weeks I have invited some guests to come and blog here on this site about their own observations.  I will also be interviewing some people who use myObservatory and writing blog posts on their behalf.

And of course if we ever get a measurable snow I will get to test out my sampling campaigns that I set up!