Arduino Packet Analyzer

Following the previous success where we managed to see the transmissions from the Black & Decker Power Monitor, Andrew Kilpatrick and I went about trying to capture the packets. Without an access to an oscilloscope with packet capture capabilities we built our own with an Arduino.

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!]

Black & Decker Power Monitor Hack

Energy Monitor hackBlack & Decker makes an interesting product called the Power Monitor. The monitor straps on to your hydro meter and reports the revolutions of a spinning disc or blinks of an IR LED depending which model of meter you have. It then broadcasts that reading to a handheld unit inside your house. As the fridge cycles on you can track this increase in power usage. Subtract that from the reading prior to the device powering on, and you have a rough estimate of how many watts that device uses. The Power Monitor is very simillar to the Kill-A-Watt except it monitors the entire house instead of specific devices.

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?

RF ReceiverThe 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!

Air Quality Monitoring

Recently I had a discussion with someone from the South Riverdale Community Health Centre on Air Quality monitoring in Ontario (AQI). I learned a number of things, there are only 40 Air Quality Monitors in Ontario and they test for six key indexes. Toronto runs a slightly different test, the Air Quality Health Index (AQHI) which is a pilot programme and reports on how the Air Quality will affect your health. The AQHI test for three key indicators. Detecting three indexes sounds pretty reasonable.

Mobile Air Quality MonitorBy 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:

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.

Incoming Projects!

Its been a busy couple of months! Through work we’ve launched the Count Me In Ontario website and an upcoming energy visualization tool in cooperation with the IESO. I’ve also been busy hacking the Black & Decker Power Monitor with some interesting results. Coincidentally enough, its Clean Air Day and I had to take the day off due to Asthma. All this work in the green sector is really hitting home. So over the next little while I’m going to break the silence on my latest projects (which have closely paralleled work) hopefully it will make up for the lack of posts. (Note: my Twitter feed is much more lively lately.)

Coding with a Fork

Recently I’ve been experimenting with online coding tools, wonderfl and Bespin. Essentially both are IDE’s enabling you to write code with syntax highlighting. Wonderfl enables coding for the Flash environment, while Bespin works in the HTML/JavaScript spectrum. There’s some pretty immediate differences, Bespin is an attempt at building an environment entirely in Canvas and wonderfl has the ability to generate the Flash piece on the fly.

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.

Twitter as the future of event broadcasting?

22 hours ago #atoc trended to number 9 on the Twitter trend chart.

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.

The Inverse of Compassion

To further yesterday’s thought, someone at the office mentions that he read in a Buddhist book the opposite of Compassion is Vexation. Looks like a bit of serendipity is in action here.

Designing for Compassion, Empathy

Momentum Magazine has an interesting article by John Pucher in their Jan/Feb 2009 issue. Its worth a read by drivers of vehicles and cyclists alike. It led to an interesting lunchtime discussion, and some really interesting ideas pertaining to designing for compassion and empathy. In short, Pucher argues that by having compassion we make our commute safer and more enjoyable.

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.

Balloon Powered Boat




Toy Boat

Originally uploaded by Eightlines

By no means original, this was a really simple design I had to build. The hull is cut with a bandsaw at 15 degrees, 1/2” dowel with a 3/16” hole in the middle. Glued and bisected by another 3/16” hole out the stern. A balloon is filled up and dropped onto the stack then released in a bathtub. Finished with hemp oil.

Kid test to follow.

Augmented Reality

Recently Saqoosha’s port of ARToolkit from C to Flash has taken the Flash world by storm. The biggest hurdle for me was that the comments in the source were all in Japanese. That was until Mikko Haapoja published a getting started in FLARToolkit entry. Now we’re witnessing an onslaught of Augmented Reality projections available right in our browsers.

My initial experiments with the toolkit are really no different from anyone else’s. I had Neil send me a 3D model which we skinned and dropped into Papervision. Immediately the clients at work started to pay attention. But aside from seeing a thousand advertising campaigns six months from now all with their own 3D model that spins around, what can we do with this technology?

  • Most computers outfitted with webcams have the camera’s targetted at the user’s face. This means the marker used to identify the placement of the model should be placed in that zone in order for a 3D model to appear. On my development system I’m using a PS2 Eyetoy, which is a camera on a USB cable enabling it to be moved around. In many user situations this will not be the case — so orient your models with the marker standing up.
  • Through the input I’ve received markers with thin lines in them tend not to be recognized at long distances. This could be due to the resolution of my camera, but even with a high resolution web cam it will cause a problem at longer distances. Make your marker files bold without fine detail and they should work better in different environments (poor lighting, greater distance, oblique angles).
  • Print your marker on card stock. If the marker bends it won’t register. I’ve found smaller markers won’t distort as much.

Now currently I’m working on adding some physics to the 3D scene. I’m using a mixture of Papervision and WOW-Engine. One of the difficulties I’m encountering is determining the rotation of the marker. From what I’ve determined, the Papervision camera is static. The camera is your eye which looks at the marker. As the marker changes orientation the camera does not move. Within FLARToolkit the scene includes a class named FLARBaseNode which extends DisplayObject3D. Tracing out rotationX/Y/Z results in 0/0/0 as the marker rotates. But what is shifting is the rotation matrix of the FLARBaseNode. So essentially if we wish to derive the rotationX/Y/Z we need to retrieve the Matrix3D of the FLARBaseNode and translate the coordinates back into degrees. From what I’ve been told, Papervision includes a static method Matrix3D.matrix2Euler() which should provide this data returning radians.

And I’ve been at this off and on for three days now but haven’t quite found the results I’m looking for. I’ll be sure to post more (plus examples) once I get everything working. In the meantime, this document does a brilliant job explaining Matrix3D.

Experiments in Physical Computing