Sunday, November 18, 2012

Beer Bread

This morning I was in a baking mood.  Having already got some Scottish morning rolls and a sandwich loaf rising, I spied a bottle of beer hiding in the corner of the kitchen.


Fig 1. Bottle of beer.

This particular bottle was a "Hoptical Illusion Almost Pale Ale" (From the Flying Monkey's Brewery).  For those that have never had it, it's an interesting beer; It's got a taste that is reminiscent of the label on the bottle; complicated, fun, in-your-face and exposure to it will give you a headache long before you expected it to.  In other words, it's a real beer that is unlike that mass-produced bland stuff put out by the big breweries.

The cool thing about alcoholic drinks is anything that isn't drunk can normally be turned into food.  Whether you're sloshing meat and veg in gallons of wine, shoving beer cans up chickens, putting vodka in your pasta sauce or in this case, turning beer into "bread" (technically, it's not real bread, but a "quick bread" as there's no yeast).

Instructions:
  1. Turn on oven to 375F
  2. In a mixing bowl, throw in 3 cups of flour, a tblsp of sugar, a teaspoon of salt, a tablespoon of baking powder.
  3. Mix for a few seconds.
  4. Throw in an entire 355ml bottle of beer (don't worry about frothing foam - it all disappears into the bread). 
  5. Mix for a minute or two on medium speed until you have some form of thick batter-like substance.
Fig 2.  Sloppy goop.

5.  Throw this into a greased bread tin.
6.  Spread the batter around, to cover the bottom of the tin.

Fig 3. Goop in the tin.


7.  Throw the tin into the oven for about 45 minutes (a toothpick should come out clean when done).  When done, let it cool about 10-15 minutes in the tin before tipping it out.

Fig 4. A slice of finished beer bread. 

As you can see this is super easy to make.  

Two notes:
1.  You'll notice in Fig 3, that my tin isn't greased even though the instructions say to grease it.  There's a reason for this; I use the Williams Sonoma Goldtouch pans.  Now, you might scoff at the thought of buying bakeware from Williams Sonoma due to the expense, but although these are expensive as far as tins go, to your breads and other baked items they are also as slippery as an eel sliding down a greased fireman's pole. This means, less fat gets into your food just for the sake of lubricating it in order to get it out of the thing you bake it in.

2.  The height on this bread should be about half as high again.  This is down to my baking powder (something I don't use too often) getting a little old.  If you use fresh baking powder, this loaf will have far more height.

Thursday, November 15, 2012

Putting a backflow preventer on the Internet

WARNING: THIS POST GETS TECHNICAL

Back in August 2012 we had a bad storm in Toronto.  It was bad enough that the storm drains in my neighbourhood (and many others around the city) got overwhelmed with rain water. The end result was a lot of unnecessary floods in people's homes as the water had to go somewhere.  Ours was one of them - so far costing about $26,000 to fix the damage and try to prevent it happening again.

The problem was the storm drain under the street was built about 50 years ago for the houses on the street.  Since then, it's been connected to other streets, large carparks that don't let water soak into the ground but send storm water straight into the sewers, etc.  All this run-off water has to squeeze into the pipe.  When it doesn't fit, it goes two places:

1.  Back up through the catch-basins onto the streets.
2.  Up any other pipes underground that feed into it.



Just to give you an idea what we're talking about, the above hole with the cable coming out of it is my 4-inch storm pipe where it meets the street storm drain (as you can see it's 68ft out).  If my pipe is 4-inches, then that storm sewer looks to be about 12 inches across.  Whilst there are run-off calculations (see section 5.4.1 here) to tell you how much water would flow, this is a 60 yr old sewer that is just inadequate and overloaded.

What I did was install some backflow valves.  We put one on the storm pipe and one on the sewer pipe.  In our case, they're these ones.  What they are, are a box with a flap in it - so that when the sewer gets overloaded and water rushes up the pipes towards the house, the flap goes up and seals off the pipe.  When the water recedes, the flap falls down and the pipe re-opens.

Whilst this is very simple, it has one draw-back because when the flap is up, I need to know this due to the fact that a closed pipe won't let water in, but also doesn't let water out.  This includes toilets, showers, washing machines, dishwashers, and anything else (sinks for example) that generates waste water.

It became very clear that I needed to monitor the pipes or the back-flow preventers and raise an alarm when it blocks off...   It has to be cheap, and have low running costs.

My plan was simple:
  • Take an old Arduino Uno I had kicking about (~$30).
  • Bolt on a Sharp GP2D120X Infra-Red distance sensor ($25 with cable)
  • Find some method of getting the data out off the Arduino and onto the Internet... This bit was not quite sorted out as I had some options (will cover this later).

The Sharp IR distance sensor was wired up as follows:
Red wire into the 3.3V Power Line
Black wire into GND
White wire into A0 (Analog In)

The first thing was to build a C++ class for the drain.  This is what V.1 came up as:

For the header, I had this:

/*
  StormDrain.h - Drain Monitoring Library.
  (C) 2012, Jason Coulls.

  This code was used with a Sharp GP2D120X IR Sensor wired as follows:
  Red:     3.3V Power Line
  Black:   GND
  White:   A0 (Analog In)
  
*/
#include "Arduino.h"

#ifndef StormDrain_h
#define StormDrain_h

class StormDrain
{
  
  public:

    //The public class constructor
    StormDrain(String description);

    //Public functions.
    String   getDescription();      //Returns the name of the drain.
    void     updateState();         //Queries the backflow preventer and updates it's state.
    boolean  isFlooded();           //Returns the state of the backflow preventor.
  
  private:

    //Private members.
    String   _description;
    boolean  _flooded;

};

#endif

As you can see, the drain can be labelled in the constructor.  There's only two private members with public functions to retrieve each value, and a simple void function to update the state of the drain.

For the .CPP file, I had this:

/*
  StormDrain.h - Drain Monitoring Library.
  (C) 2012, Jason Coulls.
*/


#include "Arduino.h"
#include "StormDrain.h"

#define IRPIN 0            //Analogue Pin 0.
#define OVERSAMPLERATE 15  //Used to get a proper reading.  

//Class Constructor - Takes the name of the drain.
StormDrain::StormDrain(String description)
{
    //Store the name.
    _description = description;
}

//Returns the name of the drain.
String StormDrain::getDescription()
{
    return _description;  
}

//Returns a boolean indicator of if the drain is flooded (true) or not (false)
boolean StormDrain::isFlooded()
{
    return _flooded;
}

//Queries the physical state of the drain.
void StormDrain::updateState()
{

    //Get ready to read. 
    int iAllSamples=0;
    
    //Grab the values a number of times.
    for(int i=0; i<OVERSAMPLERATE; i++)
    {
        //Query the Sharp IR Sensor.
        iAllSamples += analogRead(IRPIN);
        //Give it a breather before going again.
        delay(20);
    }
    
    //Now divide down the total of the samples.
    //(This gives a smoother version of the actual reading).
    int reading = iAllSamples/OVERSAMPLERATE;
    
    if(reading > 300) {
       //Drain is up.
       _flooded = true; 
       
    } else {
       //Drain is down.
       _flooded = false;
    }
    
    Serial.println(reading);    
    Serial.println("\n\r");
}

In the method updateState, you'll notice some funky oversampling.  If I asked the sensor for it's current distance reading twice, I'd get two different readings.  One way to get a good smooth reading is ask a bunch of times, then divide down the answer by the number of times we asked (to get the average).  

What I get is a bunch of values between ~40 (40 cm) and ~450 (4cm).  To make life easy at this prototyping stage, I just said anything over 300 is probably worth getting alarmed about.

The code that uses the above class was then written thus:

/*
  SurgeAlarm - Drain Monitoring Application
  (C) 2012, Jason Coulls.
  
  Besides the StormDrain class that ships with this app,
  a library (http://arduino-tweet.appspot.com) is also
  used to provide the Twitter interface.
  
*/

#include "StormDrain.h"
#include <stdio.h>
#include <Ethernet.h>
#include <Twitter.h>

#if defined(ARDUINO) && ARDUINO > 18   // Arduino 0019 or later
#include <SPI.h>
#endif

#if defined(ARDUINO) && ARDUINO < 22   // Arduino 0022 or earlier
#include <EthernetDNS.h>
#endif

//Create an instance of the drain, and give it a name.
StormDrain thisDrain("Storm Sewer");

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
byte ip[] = { 10, 0, 0, 177 };

//Your Key from (http://arduino-tweet.appspot.com) goes here.
Twitter twitter("<YOUR_KEY_HERE>");

char closedMessage[] = "@coulls - Storm surge detected. BFP Closed";
char openMessage[] = "@coulls - Storm surge receeded. BFP Open";

void setup()
{
    //Open the ethernet.
    Ethernet.begin(mac, ip);

    Serial.begin(9600);
}

void loop()
{
     

    //Ask the drain to take a look at itself.
    thisDrain.updateState();

    //Print the state.
    if(thisDrain.isFlooded()){
        if (twitter.post(closedMessage)) {
            int status = twitter.wait();
            if (status == 200) {
                Serial.println("OK.");
            } else {
                Serial.print("failed : code ");
                Serial.println(status);
            }
        } else {
            Serial.println("connection failed.");
        }
    } else {
        if (twitter.post(openMessage)) {
            int status = twitter.wait();
            if (status == 200) {
                Serial.println("OK.");
            } else {
                Serial.print("failed : code ");
                Serial.println(status);
            }
        } else {
            Serial.println("connection failed.");
        }
    }

    //Stop for 5 seconds before checking again.
    delay(5000);

}


As you can see here, the idea is to check the drain, and if it's up, then tweet it to me.  This has two fatal flaws.

1.  I'd get flooded in tweets.  This code needs to be added to, so it does things only when the state changes.
2.  I've still no idea if the Sharp sensor can see "through" the top of the Mainline Fullport Backflow preventer to the flap, or whether it will only measure to the top of the valve case.  

So, as you can see, the idea is coming along.  I ran out of time to do more on this today as dealing with family, but I have to amend the code further to suit the application.  It's not really difficult at all - just time consuming.

For the first run at prototyping, I will run an Ethernet cable through a shield and connect that directly into my Bell modem.  A big unknown question is whether to implement a ZigBee wireless transmitter.  I don't have one kicking around, but it might be fun (if a little over budget) to implement.

I will update this story in a consequent post, when I get time to throw the hardware down the hole and try IR sensing through the back-flow preventer itself.

Stay tuned.

Thursday, November 8, 2012

Guns N' Media

Toronto has a gun problem.  It's not as big a problem as found in some cities around the world, but it's still a problem nonetheless.  Toronto also has gun solutions in action.  You might think that the two would attempt to cancel each other out? That the solutions would curb the problem until there is neither the problem or the need for the solution?  

There's a third element to take into account: The media.  You have the police, government and communities trying to address the problem, and the media is throwing fuel onto the fire belonging to the shooters camp.

See, what happens when the media gets involved is this cycle:

1.  Someone gets shot.
2.  The shooter's name gets pumped out by the media to the point that they're nearly a household name.
3.  Someone else sees this publicity and aspires to be as infamous as this shooter, so they plan to go out and shoot a rival gang member, or someone who's perceived to have wronged them.
4  Go back to step 1 again.

The media should have a name blackout for gun shooters in the city. By all means report the incident, but leave out the names.

It's not a secret that these people are notoriously bad shots and literally can't aim their guns at the intended targets to save their lives, so innocent bystanders often get caught up in this, Q.E.D.  

By removing the media bestowed glory that the shooters want to aspire to, the media will then allow the police and communities to play on a more level playing field.

Sunday, November 4, 2012

When the rules of the game don't work, the game should change.

The process of improving the quality of anything, whether it be a service or product, usually takes an iterative loop like this:

  1. Query it's current state.
  2. Apply corrective measures to make it better.
  3. Go back to step 1.
When improvement takes a back seat to other agendas, such as cost-saving or arse-covering, the process changes thus:
  1. Wait until there's an issue.
  2. Pass the buck, or make an excuse for the issue.
  3. Go back to step 1.
A further permutation to this loop occurs when we see the iterative process go into a death-spin, like this:
  1. Query it's current state.
  2. Apply corrective measures to make it better.
  3. Go back to step 1.
I'm all for process. I like it when there are clear expectations of how something will work, and a clear understanding of how things will be improved or fixed.  As you can guess, process does go wrong from time to time.  When it does, it often shows up underlying problems in either how to handle a given situation, or what the real mandate of the problem solvers are.

For instance:  At Victoria Park subway station, there are two elevators for those with strollers/push-chairs or wheelchairs.  There is one on each platform, but the one on the east-bound platform was not working.  A person with an electric mobility wheelchair was stuck on the platform, unable to exit the station due to the situation with the elevator (the concept of a fall-back route hasn't hit this station yet).  Their attempts to call for help using the assistance button wasn't generating any response from TTC staff either.

Next, add to this mix two mothers with strollers.  One had a new-born, the other had 2 month old twins.  They also tried to call for assistance with getting out of the station.  No response either.

At this point, I get an angry call explaining the situation and asking me to get on twitter and find out what is going on.  So I duly post a question to @TTCHelps:


Enough time goes by without an answer on the assistance button or twitter that it's determined that whilst the women can harangue stronger passengers to help shift the babies down the steps, the only course of action for the disabled person is to catch the next train, and take two more stops to Kennedy where there is an elevator.  At that point, they can go down under the tracks and come up on the westbound platform, take another train back to Victoria Park, then exit on the platform that has the working elevator.

Eventually, the TTC responded after 30 minutes, bypassing the expected process of determination as to whether anyone was actually in trouble and needed the assistance that the button was designed to provide, but instead went straight to arse-covering mode:

Well, that just makes everything better, doesn't it?

A side effect about using Social Media is sometimes other people will add their contribution to the situation, which sometimes can be beneficial, and sometimes (like here) ends up with people not just getting the wrong end of the stick, but the "wrong stick" altogether.



People may wonder why I don't file a report with the TTC about the things that are wrong?  I used to do that, but in my experience that process is highly broken.  With Twitter you get a response, whereas using the TTC official process has shown (see here) that you may as well send your complaint to Sgr A*, because I've never had a response or seen a solution arise from the process.

A similar failure of process I recently spotted was with City Hall.  In my ongoing war with the garbage people, I'd finally had enough.  To recap, in 12 months we've had the following:
  • Garbage picked up on one side of the street only, whilst the other side of the street was ignored.
  • Garbage not fully picked up on multiple occasions.
  • The special collection for flood victims (after the City destroyed everyone's basements with storm water) didn't happen on the scheduled day that they advised us, so we had to pay a private firm to remove our items to allow reconstruction crews in on time.
  • Misinformation of what can/can't be recycled, resulting in unnecessary expenditure through the use of garbage tags.
All of the above have been filed with 311 Toronto.  After the latest debacle (involving the raccoon locks that Home Depot, etc, all sell in the Toronto area resulting in the green bin not being picked up yet again), I wanted to speak to someone - so I follow the posted process and lodge something with 311 Toronto... again.

A few days later, an unnamed guy without business cards or other information with which to contact him back arrives unscheduled at the house whilst I'm at work.  

I asked 311 Toronto to identify the person and DM me, because I actually want to talk to him, and I can't schedule or contact the guy if he's wandering around without any cards or leaving other information.  Instead of DM'ing me the answer, it requires phoning up or emailing their support desk for the umpteenth time - that's the process.  We're now in that "process death-spin" because all they need to do is answer the question they've already been asked, but they require me to re-engage in the process.

Now, you may think that I'm being a little unfair to 311 Toronto on this, but this isn't the first time that process has caused issues.  One example was back in the summer of 2012, many homes in the East end of Toronto had their basements invaded by storm water from the city storm drains.  In the ensuing furore, we had the world and their dog visit the house, including councillors, city engineers, the head of the basement flooding program, a manager from Toronto Water, people from public works, etc.  

Everyone at City Hall appeared well acquainted with our house, it's construction, the sewer configurations, etc.  The Basement Flooding Program process mentions that if you get a flood in your basement to call them.  The day after the next flood, I called 311 Toronto to record it, as per their posted process.  However, 311 Toronto couldn't record it because I was "not making the call from the house"... 

Although they don't state this on their website, you are apparently supposed to call 311 Toronto from your home, so that they can ask you questions.  

To me, the answers to these questions the day after a flood has disappeared would be the same whether I was standing in my basement or standing on a Bahamian beach.  When the purpose of calling 311 Toronto is to record a replica of a flood that City Hall has already been to the house to determine the cause of, telling me that they cannot record "this flood" because of where I'm standing is like the police not taking your eyewitness account of an event because you're not standing in a particular location. 

So, what to do?

My view is simple:  If the other party's process is not working and becoming a hinderance to us both accomplishing something, I stop playing their game and change it to run by my rules.  

Their rules and processes have failed, so let's try something new.

In the case of 311 Toronto, it's a simple process to just cut them out of the picture and go around them.  The departments that they represent (water, waste, etc) all have a person in charge, and these people are held accountable for their departments, so I approach them instead.  When I do, I make sure to point out that the previous rules of engagement are now suspended and show evidence as to why.  This process has worked every time.

The TTC is a different animal: It generally faces a moderately hostile public on a daily basis. As a result, the usual "squeaky wheel" approach just doesn't work when trying to fix things.  Q.E.D, asking why an assistance mechanism isn't working doesn't garner the expected "does someone need assistance?" response.  

When one dissenting voice isn't heard, you can be sure that the TTC listens to a full-on chorus.  The solution, therefore, to getting something addressed in these circumstances is simply to educate the public and let them become your amplifier.  Demonstrate to a bunch of people that nobody was answering the passenger assistance button for a long time and people do take notice with alarming curiosity.

My final thoughts on this will be a suggestion to the TTC:  If the current process of manning the assistance alarms at the stations is as effective as a chocolate fireguard, centralise them so there's always someone available to help.