By building my own Air Quality project I hope to be able to reproduce the AQHI results at a fraction of the price and provide instruction to enable anyone across the province a chance to build their own.

To the left is a photo of the final (but always in a state of flux) result. It is a GPS enabled device powered by two AA’s which senses Air Quality and Ozone. I am currently running tests in a variety of ways. This is a more complex setup than it has to be. Below I’ll detail both a simple setup and a complex setup.

Simple Air Quality Monitor:

• USB-Serial Connection (~$15)
• Air Quality Sensor & Ozone Sensor ($6 each)
• 2 Resistors ($.15 - I’m using a 15k Ohm)

Connect the sensors as illustrated on the Wiring.org website. Attach to a computer and upload the data to a provider such as Pachube to share with the world. (Need an invite? Message me.)

Mobile Air Quality Monitor:

• Arduino (~$45)
• GPS Sheild ($16)
• GPS ($60)
• SD-Card ($20-60 depending on size - the SD-Card library uses a FAT-16 environment, so 1GB is all you’re going to need)
• MintyBoost ($20 - 12 Hour lifespan for 2 AAs, 3 for a 9V battery)
• Air Quality & Ozone Sensor ($6 each, see above for links)
• Batteries (~$5 - I’d suggest rechargables)
• 2 Resistors ($.15)

See above for the sensor connection details, then download the code to run the GPS and log the data (plus sensor data). I’m using the GPS CSV logging sketch.

Now for the notes:

• I have no idea if this is capale of producing valid AQHI data, I’m researching this now.
• The sensors are not calibrated, the data should only be valid relative to my own readings. I’d like to make the result reproducible across all sorts of devices.
• Particulates are not being measured. Someone suggested taking apart a smoke alarm to dig out the sensor. I still have to try this.
• Mapping of my results is coming soon. I intend on using this device in a setting where I can measure the effects on a highway with and without cars in the coming days. I will post the results.

Where things start getting interesting is when you start to be able to share the code with other developers. This is a more complete feature within wonderfl so for the next little bit I’ll concentrate on its model. This looks like a feature that will come with Bespin, allowing contributors to participate in Open Source initiatives.

Wonderfl allows the audience to browse other publicly available projects (does a private mode exist?). If they like the code they are free to fork the code and develop it in their own user environment. The owner of the original code is then notified that their code has been forked and is free to observe the changes. Its a smart introduction of social sharing that has always existed in the coding environment, but never to this level of slickness.

Today the guys over at the Arduino Blog posted this interesting hack enabling Bespin to enable syntax highlighting for Arduino code. Check out the comments, Olle Jonsson has developed a python script that allows you to compile (though still in the initial stages) Arduino code. Wonderfl has already produced some fantastic applications, and Bespin appears to be just getting started. There’s something significant brewing here, coding in the cloud appears to be something to watch very closely over the next couple of years.

To reiterate, the RPMs I was recording off of the Hall Sensor would increase to a rate of over 255 revolutions provided the speed was fast enough. This makes it difficult to save the data to a single address block in the EEPROM without bit-shifting the data to two addresses.

What Noel suggested was that you might only have to record the change in velocity, or Δv, to attain the same data. Recording the previous velocity in RPM minus the new velocity would give you a difference - which could in many cases be assured to be less than 255 revolutions at the wheel diameter I’m using.

For example, this is a fragment of the data I collected on one trip:
[ [ 0,0 ], [ 0,55 ], [ 255,45 ], [ 255,35 ] ]

This takes up eight address blocks. When bit-shifted back to its original values it looks like this:
[ 0, 55, 300, 290 ]

But by recording the change in velocity we can reduce this by a factor of two.
[ 0, 55, 245, -10 ]

You can achieve the same results by adding the values of the above array in a linear sequence. And therein lies the problem. The EEPROM address block can’t store a negative value (not without that extra byte), so we can’t reduce our reading.

Well, it was a pretty good idea, perhaps if we lived in a perpetual state of drunken stupor it would have worked out.

• Socket Connection - This requires a socket policy to be set up on the server or else you’ll get a nasty SecurityError. I used Processing to open the connection, and Flash connects to that socket. Check out this version by Mikko Haapoja which uses Processing to generate OpenGL and pass it to Flash as a ByteArray. You pass bytes from here. Also check out AS3Glue which extends the Socket Connection.
• Merapi - This bridges Java and Flash. 
• Serproxy - Included with Arduino, different versions for Mac/Win/Linux. I had difficulty with Serproxy on a Mac and had to switch to a Java version.

GPS Case

Originally uploaded by Eightlines

Playing with code is fun, but when you do it all day for work it’s nice to come home and build something tangible. I picked up some scrap Hard Maple from the baseball bat manufacturer that happens to make Barry Bonds’ bat of choice (purportedly). Now I’ve worked with Pine, Oak, Soft Maple, and some exotic woods, but I think this has to be my favourite. The stuff is durable, cuts really well, sands nicely, and has a nice texture to it. I’ve even tested it for a year under hard field conditions. Its going to be interesting how this looks like once I finish the inlay, seal, and mounting on my bike.

I’m devising a quick release mounting mechanism for the stem of my bike. This is my current hang-up with the project. I’m also thinking of drilling to within 1/16” of the outside casing so that the LED’s display without protruding from the case. I’d have liked to do the same with the power button, but I couldn’t make the case wall thin enough to make it flexible without it cracking.

Note: Requires Flash Player 10

It was never on my list of things to do since I knew the battery usage scenario would be so high, but I figured I’d bite the bullet and go the GPS route anyways. I picked up LadyAda’s GPS Sheild and have had a wonderful time working with it ever since.

I had been working on a way to parse the NMEA string data from the GPS device delivers when I figured it would be a perfect way to try out the Google Maps Flash API (my previous experience had only been using the JavaScript API, and Yahoo Maps API) and Flash Player 10. Flash Player 10 offers a number of new features, one of which being the FileReference API which allows you to browse for a file on your local machine and load it into the Flash Player without making a round trip to the server. Once loaded I split the text file based on the carriage return and cast all of the GPS Points to a Vector (another new feature — typecast Array. The speed difference is quite staggering!).

The end result is plotted on a map and colour coded based on velocity, which is recorded in Knots and translated to Km/h. The end result is a colourful chart of the route I commuted that particular day.

In the screenshot above, note the big red blotch at Allen Gardens — flat tire. The other red marks are stop lights or streetcars.

An example of the map in action requires some coordinates, so save these text files to your machine first (contains a couple hundred lines of NMEA data), and hit the load button in the map application. Once loaded the map should recentre on the coordinate boundary.

I’m currently working on some new modifications for the map so I should have more available soon. But first I’m putting the finishing touches on a wooden case I’m hand crafting as a shell for the GPS device. I’ll have photos up from that project soon.

What if you wanted to record more data, or at an increased resolution? Adding another sensor would further reduce your available space depending on how many bytes the recorded data would require. Its time to look at other methods of storing data.

• An I2C EEPROM with greater storage capacity connected to the Arduino using the wire.h library - couldn’t readily find an IC from any local vendors
• USB Stick - got these sitting around, but the Arduino won’t act as a host device. Viniculum makes such a device, but it would require an additional purchase and possibly a bigger form factor
• SD Card - readily available, just had to rip apart a cheap card reader for the port

SD Card Writer - Data Logger Prototype V2

I’m coming to the realization that the more difficult phase of this project is making sense of the data I’m collecting. I’m currently working on an application which monitors the data and charts and maps the correlations, but the collection of the data needs to be more seamless. I’m currently looking at a number of services, so I’ll be sure to write about them later.

I made the first successful run with the data logger yesterday. I’ve wired up a hall sensor to the wheel of my bike and recorded 60s intervals of my ride into work and back. Ideally I’m looking for increased resolution over a typical bicycle computer; where a low cost CatEye gives you average speed over the course of a total ride, I’d like to see how that average speed changes in increments. I recognize I wouldn’t be able to compete with a device such as a Garmin, but I could definitely improve on the $30 devices you get at bike stores.

The first issue was how to deal with the intermittent pickups of the Hall Sensor. If the sensor fired too rapidly and the loop method wasn’t in the right position you wouldn’t pick up the digital I/O change. The solution, offered by Blalor, was to use the Arduino Interrupt commands. The Interrupt fires whenever a digital I/O signal is received. In this case I receive a 1 every loop. I’d be looking for a 0, so I’d set the Interrupt to look for a FALLING attribute.

The EEPROM was the next issue. 512 bytes is a serious limitation. Some math was required to see if I what wanted to do was even possible. If I were to poll every minute over a ride I’d be able to record 8.5 hours of one byte readings. That’s pretty good, seeing a 200km ride would take approximately 6 hours.

One byte is capable of storing 256 possible values. Is that enough, or would I need more values? If my revolutions were 255 with a wheel circumference of 2110mm I’d be traveling an average speed of 32km/h. Clearly not enough. I’d need to peak at 70km/h, with an average at maybe 30-40km/h.

Is it possible to compress a value of over 256 into a byte? Neil sent along an interesting piece of code on Octet Packed Integers. This code is a little beyond my comprehension so I gave it a pass. Instead it was decided to use a second byte. This allows a max value of 65535 rotations to be recorded — and at a circumference of 2110mm a max speed of 8257km/h. Well over the speed of sound! That should give me ample room to accelerate.

Problem is the second byte reduces my overall recording time to 4.25 hours. I also decided to remove 2 bytes from the array so I could track my counter when the device was turned off. When you start it back up it starts recording at the next address from where you left off. One possible solution to the space issue is to externalize the EEPROM and use the wire.h library to communicate. This would also reduce the issue of each address of the EEPROM only be written (and guaranteed) 100,000 times.

Neil also helped with the splitting of the rotation counter across two bytes. We took the full rotation count and masked it out with a hex value of 0x00FF and stored that as an int low. Then the full rotation count was bit-shifted right ( << 8 ) and stored as int high. When the report is generated after the ride the values are recombined and reported back to the screen.

I also added in three indicator LEDs for the Hall pickup, reset button, and report button. The reset button when held down for three seconds deletes all the data on the EEPROM,  anything less than that will generate a report of the current EEPROM memory.

I’ve included the code below, any suggestions on improvements would be much appreciated.

#include 
 
#define PIN_SENSOR_HALL 2 //Hall Sensor
#define PIN_LED_HALL 13 //Hall indicator LED
#define PIN_LED_RESET 6 //Reset indicator LED
#define PIN_LED_RESET_COMPLETE 5 //Reset complete indicator
#define PIN_BUTTON_RESET 7 //Reset/Report Button
#define TIME_INTERVAL 60000 //EEPROM write interval (60s)
#define MEM_SIZE 510 //EEPROM memory size (remaining 2 bytes reserved for count)
 
long countReset = -1;
long countCurrent = -1;
int countEEPROM = 0; //EEPROM Address Count
volatile int countRotation = 0; //Rotation Counter
 
void setup()
{
  pinMode(PIN_SENSOR_HALL, INPUT);
  pinMode(PIN_LED_HALL, OUTPUT);
  pinMode(PIN_LED_RESET, OUTPUT);
  pinMode(PIN_LED_RESET_COMPLETE, OUTPUT);
  pinMode(PIN_BUTTON_RESET, INPUT);
 
  Serial.begin(115200);
 
  countEEPROM = EEPROM.read(512); //Set counter to last known free space
 
  reportEEPROM();  //Report all EEPROM entries
}
 
void loop()
{
  digitalWrite(PIN_LED_HALL, LOW);
  digitalWrite(PIN_LED_RESET_COMPLETE, HIGH);
 
  //Write to EEPROM at specified interval
  if ((millis() % TIME_INTERVAL) == 0)
    writeEEPROM();
 
  //If Hall Sensor triggered then init the test
  attachInterrupt(1, incrementRotation, FALLING);
 
  resetEEPROM();
}
 
void reportEEPROM()
{
  Serial.println("EEPROM Report: ");
 
  Serial.print("[");
  for (int i = 0; i < (MEM_SIZE - 1); i = (i + 2))
  {
    int h = EEPROM.read(i) < < 8;
    int l = EEPROM.read(i + 1);
 
    Serial.print(h + l);
 
    if (i != (MEM_SIZE - 1))
      Serial.print(",");
  }
  Serial.println("]");
}
 
void incrementRotation()
{
  countRotation++;
  digitalWrite(PIN_LED_HALL, HIGH);
 
  Serial.print("Rotations: ");
  Serial.println(countRotation);
}
 
void writeEEPROM()
{
  byte low = countRotation & 0x00FF;
  byte high = countRotation >> 8;
 
  Serial.print("EEPROM Address: ");
  Serial.print(countEEPROM);
  Serial.print(", High: ");
  Serial.print(high, BIN);
  Serial.print(", Low: ");
  Serial.print(low, BIN);
  Serial.print(", Stored: ");
  Serial.print(low + (high < < 8), DEC);
  Serial.println(";");
 
  EEPROM.write(countEEPROM, high);
  EEPROM.write(countEEPROM + 1, low);
 
  if ((countEEPROM + 2) < MEM_SIZE)
    countEEPROM = countEEPROM + 2; //Increment the EEPROM Address
  else
    countEEPROM = 0; //Loop back to start address
 
  EEPROM.write(512, countEEPROM);
 
  countRotation = 0; //Reset the rotation count
}
 
void resetEEPROM()
{
  if (digitalRead(PIN_BUTTON_RESET) == LOW)
  {
    digitalWrite(PIN_LED_RESET, LOW);
 
    if (countReset == -1) //Start Reset counter only if -1
      countReset = millis();
  }
  else
  {
    digitalWrite(PIN_LED_RESET, HIGH);
 
    if (countReset != -1)
    {
      countCurrent = millis();
      if ((countCurrent - countReset) > 3000)
      {
        Serial.println("Reset");
 
        for (int i = 0; i < MEM_SIZE; i++)
        {
          EEPROM.write(i, 0);
        }
 
        digitalWrite(PIN_LED_RESET_COMPLETE, LOW);
        delay(1000);
        digitalWrite(PIN_LED_RESET_COMPLETE, HIGH);
      }
      reportEEPROM();
      countCurrent = countReset = -1;
    }
  }
}

The post ride report looks something like this (values are in rotations per minute):

EEPROM Report:
[-31156,310,332,300,392,306,216,598,228,516,390,282,254,354,
496,198,436,60,254,263,400,382,280,394,362,340,300,306,256,
380,354,297,284,20,72,378,486,450,104,398,522,372,370,133,366,
360,164,336,460,542,488,366,396,384,512,484,300,300,332,346,
344,360,398,226,360,390,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]

There appears to be some irrelevant data in the mix (see the array item 0 for example) which I haven’t quite figured out. The numbers don’t quite calculate to the precision I expect from a cycle computer. I have a feeling the Hall count is firing multiple times per revolution — like it has a FALLING state more than once.

Here is a quick JavaScript rendition of the data in a bar chart format. The RPMs are converted using this equation:

(((rpm * wheel circumference) / 1000) / 1000) * 60 = km/h

The next phase is to gather data on multiple days for the same course and comparing the results for analysis. I’m looking at developing an Adobe AIR Project which would allow me to keep an offline/online database. Getting real time data is another big incentive and I’d be looking at the XBee solution for that. Being able to record heart rate data and GPS/Digital Compass are also interesting but the limitations of the EEPROM don’t easily allow for recording of data that complex. So I think hooking up an SDCard is the next most probable option. I’ve already tried a USB adapter but the Arduino does not have USB host capabilities, so that didn’t work. There are options to get the USB host to work, but it involves purchasing another PCB. Finally, I don’t think any of this makes much sense without introducing a mapping API to add context to the data. So there’s still lots more to come!

I’m having a few issues getting the readings I need, namely the revolutions are not counting with any consistency. I think the issue is with the way Arduino loops through the script. Below is the first iteration of the code I’ve written.

NOTE: Script updated August 31, with Blalor’s suggestions. The RPM reading now works with a high rate of speed.

int pinHall = 2; //Hall Sensor
int pinLed = 13; //Indicator LED
int time = 10000; //EEPROM Write Interval
volatile int rpm = 0; //RPM Counter
 
void setup()
{
    pinMode(pinHall, INPUT);
    pinMode(pinLed, OUTPUT);
 
    Serial.begin(9600);
}
 
void loop()
{
    //Write to EEPROM at specified interval
    if ((millis() % time) == 0)
        writeEEPROM();
 
    //If Hall Sensor triggered then init the test
    attachInterrupt(1, incrementRPM, FALLING);
}
 
void incrementRPM()
{
        rpm++;
        digitalWrite(pinLed, HIGH);
 
        Serial.print("RPM: ");
        Serial.println(rpm);
}
 
void writeEEPROM()
{
    noInterrupts();
    Serial.print("EEPROM: ");
    Serial.println(rpm);
    rpm = 0;
    interrupts();
}

It appears to me like the checkReading() method isn’t firing with any consistency and therefore I’m not incrementing rpm properly. The writeEEPROM() method is firing on target, however I worry that the writing process may be delaying the rpm count.

Below is a Fritzing illustration of the circuit I’ve wired up:

Setup of the Data Logger

Suggestions? I’m open to any hints someone might have on how to structure this a little differently.

I’ve had the Solenoid project working for about a week and a half now, but the rain and lack of sunlight was getting in the way of making a video of everything in action. It worked out well because it gave me the chance to demonstrate the project to a number of visitors today, all at once. And, as the photo above demonstrates, the project passes the kid test.

The project is still in need of refinement, but I’m thinking that’s where things would get expensive. I’ve sourced out some new solenoids that could be used in a multimedia environment, I’m just unsure of the cost. The solenoids I have used are $7 washing machine parts. Specialty valves are bound to be more expensive. Some of the valves leak, and I’m pretty sure it’s not occurring in the sections I’ve sealed, the valves may be defective, or they may have a scratch in the plastic I created when I was reconfiguring the orientation of the connectors.

The brace you can see in the photo on the left was constructed to correctly position the hoses in sequence. the centre photo demonstrates the digital radio, Arduino, and transistor controller. The green wires leading out of frame are wired to the Solenoids. On the right, the solenoids are hooked up to the hoses. (All the photos have notes visible in Flickr)

In the above video, I’ve got the device filled with water, and directed through flexible hoses. Valves 2, 4, 6, 7, and 1 turn on. They then cycle off, leaving valve 1 open. The camera then pans up to the controller where it zooms in on the LEDs which I’m using as indicators of which valves are turned on. We then go through a test of all the valves on and off to demonstrate the flow when everything is open. A couple of the valves don’t work, and I’ve traced that back to a point on the controller circuit that I think has not been soldered correctly.

I think it would be important to note the projects out there that are doing the same thing. The Jeep waterfall was unveiled at a Detroit autoshow in 2000. This waterfall was published on the Make blog just the other day. MIT’s building made of water is scheduled to open at the 2008 Expo, they’ve hired Lumiartecnia to produce the valves. Also check out this water keyboard for its innovative use of sensing electric resistance when you touch the water to control the solenoids — in this case controlling air flow in a liquid. All these examples show that the envelope can be pushed that much further, and that there’s a large degree of possible variatons.

Still lots more ideas to play with, but many of these will be with the code. I’ve got some really interesting image processing ideas coming up.

]]> http://js-kit.com/rss/eightlines.com/blog/p=19 1