One of the things I find most interesting about this patent is the citations dating back to 1977. Definitely not a cutting edge technology we’re working with here. If the 1977 patent was the byproduct of the ’70s energy crisis what inventions will we see as a byproduct of our current energy phase?

Now this design appears to be based on a European design, and around this end of the globe we have Like-a-Bike which look very similar. The $300 price tag was a bit steep, and since I had all of the parts in the shop I decided I could build it myself. The whole project took about a week when you take in all of the trial and error that went on. A more competent woodworker could probably do it in much less time. All in all, it made me further appreciate the subtleties of the Like-a-Bike design.

Initially, I went with the design in the PDF file which included front forks cut out of a single block of wood (Left image). This became problematic when I noticed the axle would have to be thinner and the design gave less flexibility when manipulating the headset. I soon went to a different design (Right image) which ended up being more rigid, and easier to modify as the design changed. In the end I also managed to shim in a spring to act as a rudimentary shock. Instead of adding spacers to the front wheel I pulled the axle in far enough to bend the forks. It seems to add a nice bit of curve to the design.

Looking at other wooden bike designs it appears 1/8” plywood would have probably done the trick. I used 1/2” plywood which was probably overkill. This adds to the weight, but my daughter can still manage it easily. The edges are routed to give a nice curve, and to avoid splinters. It also added a really nice effect to the edges. I’m looking forward to seeing the varnish go on. In this image you can also see how the rear wheel fits between the body. I had to sand the plywood down to provide an allowance for the rear wheel to spin freely. To stop the rear axle bolts from loosening, use a nylon threaded nut.

The handlebars were simply cut and sanded down to the final rounded off shape. I also had to modify the front forks to give a larger turning radius. Sanding the inside edge of the fork provided about 20° to each side. The headset also had to be reinforced with more screws, I’d recommend putting countersunk bolts right through the frame. The first time the bike dropped to the floor the threads stripped the plywood. I’m hoping more screws would stop this from happening next time.

This was a pretty fun build that could be completed with some simple tools. I used a band saw, belt sander, router, and drill press. You could do this project with much less if you wanted to. You could also supplement the design with a kick stand, bell, streamers, or carrier.

Essentially, the code waits for the Power Monitor to transmit the packet. When it detects a signal it spins up to a 100 microsecond delay and captures the bytes. These bytes are stored to the internal memory. When the packet is finished, it dumps the data to the Serial Monitor and waits for the next packet.

/**
 * Packet Analyzer
 *
 * Project documented at:
 * http://www.eightlines.com/blog/2009/04/arduino-packet-analyzer/
 *
 * Many thanks to Andrew Kilpatrick:
 * http://andrewkilpatrick.org/blog/
 *
 * Captures & logs incoming packets in HEX format.
 * Digital signal is HIGH and drops to LOW when transmitting.
 * Accepts digital input on Digital Pin 8.
 */
 
unsigned char buff[128]; //Create a buffer array to insert bytes
int bufferLength = 128;
 
void setup()
{
  Serial.begin(115200); //Invoke serial connection
 
  //Set input based on port registers
  //Refers to Digital Pin 8
  //http://arduino.cc/en/Reference/PortManipulation
  DDRB = DDRB | B11111110; //Data Direction Register
  PORTB = 0xFF; //Port B Register
}
 
void loop()
{
  unsigned char tempByte; //Temporary Byte
 
  //while (PORTB & 0x01); //Not functioning as expected
  while (digitalRead(8)); //While HIGH idle
 
  //LOW transmitted enter For Loop
  //Repeat loop for each byte in bufferLength
  for (unsigned char b = 0; b < bufferLength; b++)
  {
    tempByte = 0; //Reset temporary byte
 
    //Loop for each bit
    for (char bit = 0; bit < 8; bit++)
    {
      tempByte = tempByte << 1; //Shift previous bit
      tempByte = tempByte & 0xfe;
      //tempByte = tempByte | (PORTB & 0x01); //Not functioning as expected
      tempByte = tempByte | (digitalRead(8)); //Incoming value
      delayMicroseconds(100); //Oversampled delay - can be adjusted based on speed of packet
    }
 
    buff[b] = tempByte; //Write byte to buffer
  }
 
  //Write buffer to Serial connection
  Serial.println("SOH");
  for (unsigned char b = 0; b < 128; b++)
  {
    Serial.print(buff[b], HEX);
    Serial.print(" ");
  }
  Serial.println("");
  Serial.println("EOT");
}

This code will produce a HEX output of the signal. Convert this to bytes and map the data to high (-) and lows (_). [I’m an Flash developer by day, so the code below is in ActionScript]

public function HexInterpreter()
{
   var hexArray:Array = hex.split(" ");
   hexArray.forEach(appendHex);
}
 
protected function appendHex(element:*, index:int, arr:Array):void
{
   arr[index] = uint("0x" + element);
   trace(arr[index].toString(2), arr[index])
}

The finished result is viewable here. The next step is interpreting this into data. I believe reset sends four packets, and every transmission (once every 30 seconds) sends an IR Count and Temperature. The next step is interpreting the results from this test.

[I just want to stress that none of this code or results would have been possible without Andrew’s assistance. In fact 90% of the code presented here is his, I was just along for the ride and to learn a hell of a lot. Many thanks!]

There’s some benefits of the Power Monitor over other devices. It tracks the entire house, the 30 second delay on readings is almost realtime, and its affordable ($100 — would probably pay back fairly quickly). There’s also some disadvantages. It is less accurate then the Kill-A-Watt, and it has now data connection.

The Kill-A-Watt has a simillar problem, it doesn’t export the data either. This is a bit of an issue if you wanted to log the power consumption of your house. That’s where the Tweet-A-Watt comes in. What I’m attempting to do is bring this ability to the Power Monitor. How hard could it be?

The Power Monitor is a device manufactured by Blueline Innovations. It transmits a signal on a 433.92 MHz spectrum. My first attempts were to try to intercept the signal through an RF Receiver in the same frequency.

Initial attempt. Nothing. Set up an RF Transmitter, it communicated with the receiver perfectly. I was a bit stumped. This is when I checked out a session at Hacklab. There, I was schooled on using RF Scanners, spread spectrum and other RF black magic. (Many thanks to — make sure to check these guys out — Andrew Kilpatrick, Toronto Goat, and everyone else at Hacklab) We could detect the packet’s being sent, but couldn’t intercept any usable data.

It was decided that to get any useful data we must be more invasive. Warranty, out the window. We broke out the oscilloscope on the Monitor. Conveniently there’s two test probes marked on the board. This allowed us to identify the packet quite easily.

Now at least I have some confidence that we will be able to produce some results and this isn’t some wild goose chase. The next phase is to capture the data off the device. I’ll follow up shortly with the Signal Boost circuit and Arduino code used to capture the transmitted signal. More soon!

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.

The Amgen Tour of California was in its first official leg and it was doused in rain. Cloud cover was so low it kept helicopters grounded and radio transmissions were inconsistent. But the Tweets were coming fast and furious live from the racecourse.

21 hours ago #atoc trended to #8.

During this time Lance Armstrong of team Astana crashed and photos appears on Twitpic. Live coverage on the Amgen Tour of California website still doesn’t have any event coverage. The reporters are doing their best to fill in the time by reporting on the Women’s crit, which had some fabulous footage of the final sprint to the line.

#atoc Trends to #6 during the same hour.

@FredCast (publisher of a fantastic bike podcast) Begins to broadcast on Qik from a team car. Live TV coverage is spotty, and technical notes are the only news popping up on the tour tracker.

#atoc Trends to #4 later in that hour.

Race reports start to stream in from spectators at the In and Out Burger house, and along the descent reporting time gaps before official sources. @johanbruyneel Reports from the Astana team car that race radio is sending out mixed messages. This inevidentally leads to issues in catching Mancebo’s break from the peloton.

20 hours ago #atoc hits #1 ahead of NASCAR’s Daytona 500.

By this time the TV coverage was ground based in Santa Rosa. Camera’s could cover Mancebo’s break and the chase of the peloton. The break closed from 2’30” to nothing over the last few kilometers. Twitter followers started taking bets. I predicted Mancebo would have been caught,@FulSpeed thought otherwise. (We called it a draw at the end of the day.)

In the end Mancebo takes the race. 635 Twitter comments ensued in the following 3 hours.

Today, the action continues. And if you needed a ride @track_stand was offering a lift across town on the #atoc feed, but if you’re reading this now you probably missed it.

Recognizing that drivers of all types of vehicles may or may not be compassionate at any such time, I wonder if the design of vehicles could alter their behaviour. Recalling a presentation by a graphic designer I witnessed, he theorized that by increasing the size of the windows in a car you would make the driver feel more vulnerable. By making the driver feel increasingly vulnerable you heighten their defence mechanism. In turn that driver would reduce their speed, increase space between themselves and any other obstacle, and in general drive with a greater intention of self-preservation.

Observe the design of a bicycle, most bicycles consist of a triangular frame with two wheels (I’m lumping in recumbents, unicycles and tricycles). In many cases the driver of this vehicle is entirely exposed to their surroundings. Does this make them behave differently?

Tom Vanderbilt author of Traffic: Why We Drive the Way We Do (a recommended read) posts about cabin noise and how it is touted as a feature. Instead should it be viewed as a detriment? Does it separate us from our environment thereby inhibiting our senses? Does a departure from our senses equate to reduced compassion?

In a long winded way this gets me to an idea. Would we be able to measure someone’s compassion or empathy through the environment presented to them in a vehicle. We may not be able to measure empathy, but we could look at contributing factors. Does an increase in tension, aggrivation, lead to reduced compassion? If so this is something we can measure quite easily.

In a previous experiment I was working on a data logger. If we set up a number of sensors on the steering wheel of a car, the handlebars of a bike, or the gloves of a pedestrian we could measure moisture content, pressure, and posture changes. With a little more advanced setup we could perform eye tracking. The idea being that by comparing results of any given moment against a baseline average we could determine spikes leading to tension.

I’m theorizing that compassion is a behaviour we’re usually conscious of. This behaviour would require that we provide the mental faculty to process. In a defensive scenario I wonder if conscious behaviour is low on the priority list. Thereby increased tension would be the inverse of compassion.

Going back to Pucher’s article, the first step in increasing compassion is being aware of it. If we could create a device that the driver of a vehicle could acknowledge, that might be a starting point to increasing that compassion. Although, I still think the original idea of making the windows bigger is much simpler and doesn’t require another piece of technology.