Saturday, April 19, 2014

Vancouver housing market trends: 2 - Maintenance Fees

As a follow up to my previous post, here are my findings on comparing Maintenance fees and Area of an apartment in Mount Pleasant, Vancouver. The data set is the same one presented earlier, and consists of 24 apartments currently offered for sale.

Fig 1. Maintenance fees increase as the area of an apartment increases.
This data shows that maintenance fees (strata fees) generally increase as the area of the apartment increases (correlation of 0.76). This is significant because it substantially affects the size of mortgage you can have for a given income. Lower fees mean you can put more money each month towards paying the principle, and could potentially pay off the house faster.

It is also interesting to note that while this general principle shows increasing area is correlated with increasing fees, there is a bit of variance between maintenance fees for a given square footage. For example between 600 and 650 square feet you could pay as low as $195 and as high as $270 from the data set I am using. This means that you do have some choice in the fees you pay, if you choose the apartment carefully!

So where does this extra variance come from? I also took a look at age and maintenance fees to see if that might provide some more insight:

Fig 2. Maintenance fees are generally higher in older buildings
Actually, the effect here was not at all what I was expecting. I had heard terrible stories of buildings built between 1980 and 2000 leaking (wiki), and assumed that this era of building would have higher than average fees. But I guess the older buildings have more problems (or more cautious strata councils?) and tend to have higher fees (correlation of -0.46).

Vancouver housing market trends: 1 - Building Age and In-suite Laundry

As an interlude to my posts on electronics, I decided to apply my engineering skills to solving an interesting real-world problem: how to buy the optimal house for the optimal price. From an economics standpoint, this seemed quite straightforward: I planned to use the idea of unequal value to obtain a house that no one else would want, at a price that I liked. For example, if everyone else cares about pets, making buildings that allow pets more expensive than others, then I would pick a building with no pets and therefore save some money while still keeping the other criteria (like in-suite laundry) that are important to me.

My thought process was originally something like this:
1 - Obtain data on all the houses and apartments in Vancouver
2 - Determine the principle driving factors of prices to make a simple linear equation representing the price of a house as the sum of all its components
3 - Find the home with the criteria important to me, at a price I like

But alas, no one publishes tables of data that I could use. So my actual process looked something like this:

1 - Choose a small neighbourhood (in my case Mt Pleasant, Vancouver, Canada)
2 - Digitize all the data from houses currently for sale from my local MLS into an excel chart
3 - Identify driving forces using excel graphs

And in the end, I still don't have a great understanding of what people are paying for in a house. But I did make a couple interesting observations: the first one being house age and presence of in suite laundry.

First: the data set I used (sorted by asking price):

ListingPrice (April 19)Sq feetLaundryMaintenanceBuiltWalkscore

When I plot the presence of in-suite laundry and age, I got a figure like this:
Fig 1. In-suite laundry as a function of the year the apartment was built

It seems to me that if you care about having in-suite laundry, you can start by looking at the building's age (which is sometimes easier to tell from the ad). My guess is that older buildings do not have the sewer system in place to support in-suite laundry, while newer buildings do. 

Some other trends I looked at were: 
  • Maintenance fees and square-footage, 
  • Age of building and maintenance fees, and 
  • Walk score and housing valuation.
All of which I will discuss in upcoming posts. If it is successful, I may adapt this to other neighbourhoods, as well as try to find a more automated way of processing the data (right now it is quite manual).

For reference, there are a number of useful sites if you are trying to do some house finding analysis of your own: here are a few that I used: - an interesting study of house listings over time, with 'desperation scores'. This author is putting effort into bringing transparency into the market which I applaud. - Here is where I obtained appraised values for each house I was looking at (though I didn't find it so useful in my analysis) - This is a very interesting map of Vancouver showing a number of useful data sets, though unfortunately not evaluations - And this is the type of transparency I wish Vancouver offered: a map overlaid with property values. Good job North Vancouver!

Saturday, April 5, 2014

Greenhouse project - The Build

After hearing about some amazing Ikea Hacks, I decided I wanted to try one of my own. I bought a greenhouse (Socker) and two LED light strips (Ledburg) as a starting point.

The light strips were quite long, so I divided them into 3 and wired them together so I could place them side by side and mount them on aluminum angle.

6 lights total, mounted in 2 groups of 3 at the top of the greenhouse
To turn the lights on and off, I used a relay module to switch the load side (after the AC/DC converter). For safety I put the relay module and connections inside a box, which had the added advantage of being a nice place to mount my electronics later.

The grey electronics box (grey) holds my relay modules, but also provides a solid mounting point for my Arduino and camera 
Because I don't like wasting power, I salvaged an IR sensor from my Roomba robot, and connected it reverse biased in order to detect how much ambient light was around. This way I could switch the lights on when they were needed, and off during the day.

Of course any respectable greenhouse needs data collection abilities, so I used the SHT15 temperature/humidity sensor, which I have used in previous projects and has given me great results. It has an on-board processor which digitizes the sensor data and sends it over a 2 wire connection. I was able to find Arduino sketch examples to base my data collection software from.

The SHT15 is also mounted to the side of the electronics box and measures ambient temperature and humidity
To display my data, I connected an 2x16 character LCD display, that tells me the light value (L) ranging from 0-1027, the temperature (T) in degrees celsius and relative humidity (H) in %.

The 16x2 character LCD display on the outside of my greenhouse

But what really sets this greenhouse apart from others is its scientific abilities. I have a LinkSprite serial camera mounted inside to take a photo every minute. This will allow me to observe long term growth trends visually and compare to the data (temperature, light and humidity) to find the optimal plant growing conditions. These photos are logged to an SD file as .jpg images, which I can convert into a time lapse on my computer. On my LCD character display, the number of photos taken is shown in the top left, and in the top right are the number of bits remaing to be transferred in the current photo over the serial connection (in Hex).

Once I put some plants in it, the whole thing looks like a bit like a cyborg greenhouse. I have 3 plants, so now I can watch them race and see what grows the fastest.

From the side (top photo) and from the top (bottom photo) my cyborg greenhouse now has 3 plants which are racing to see which is fastest to grow. I will not be putting my bets on the cactus.
So what are the results? I took data and made a time lapse from the first 4 days of operation. First is the temperature and humidity result. The temperature seems pretty constant, varying only a couple of degrees, probably due to the heat in the environment. Humidity doesn't change much either.

Temperature and humidity over 4 days in my greenhouse
The timelapse consisted of 5700 photos, and took up 875 MB on my SD card. This means I should be able to capture somewhere around 2 months worth of photos if I continue to capture them every minute on my 16 GB card. I am thinking that increasing the interval between photos to every minute or so might be more appropriate for filming the growth of cacti however, so this might require a bit of tweaking.

A couple other notes about my design, for anyone looking to do something similar:
  • The program size is about 25 KB, which fits on a Duemilanove. A large portion of this was the SD FAT library I used. 
  • I used all the pins on the Duemileanove except A5
  • I used 4 libraries: SoftwareSerialLiquidCrystalSDFat and LinkSpriteCam (which is a library I wrote myself to control the camera). 

Sunday, February 16, 2014

Reverse engineering the Roomba

Since I was having difficulties with the Roomba's battery, and because it looked interesting, I decided to take my Roomba apart and see if controlling the individual components was feasible. Taking it apart took a couple of hours, and the first component I decided to play with was the motor.

I knew that it had some sort of encoder, but I was surprised how basic it was. The encoder consisted of a single photodiode and a toothed wheel... I presume that the engineers must have used additional information from the motor driver (current direction?) to resolve the direction of the rotation. I connected the diode to a 220 ohm resistor, 5 V power source, and reverse biased the photodiode with a 560 KOhm (also 5 V source). I then ran this through a comparator (LM311) against a 2.5V reference (I just used two 120 KOhm resistors in a voltage divider) to digitize the output.

With an Arduino, I wrote a simple sketch (posted after the break) to take the input from the comparator and increment a counter. I tested that turning the wheel increments the encoder. I ran the signal to an interrupt pin as well as a digital input, so that I didn't have to keep polling the pin. Should allow me to add extra inputs from my other wheel to the system easily I hope.

I don't want to drive the motor from my Arduino so I'm going to have to figure out a second power source and motor driver (perhaps a shield might be easiest) before going too much further with this.

Also below the break I posted a few more photos of the Roomba disassembly.

Thursday, December 5, 2013

Updates to the Christmas tree project

I made a handful of modifications to my Christmas tree this week! Using shift registers I eliminated most of the wires connecting the Arduino to the LED display. Programmed a few scrolling patterns and select between them randomly. And I neatened up the wiring a little bit, so the whole thing is not quite so ugly.

Seems to be a couple deficiencies though... I think its due to the way I tied the shift and latch clocks together, but I am not able to get the top row of my tree to light up. And I would love to make it battery powered and wireless and hang it on my actual tree. Might be a bit ambitious for now though, and would require taking apart one of my older projects which I don't know if I want to do yet.

Saturday, November 30, 2013

Christmas tree! Engineer style

Its the last weekend of november, and that means time for a Christmas tree. But, since I don't own one, I had to make one -- LED style!

First I laid out 27 LEDs in the shape of a tree. Didn't have all the same color or size, so had to be a bit mismatched. Also discovered that my camera does not like to autofocus on protoboard... must be all the little holes messing it up.

Step 2 was wiring. Each LED got two wires, one for cathode and one for anode. Tried to keep all the cathodes orange for distinguishing them later.

Third, I divided up the wires into rows and columns of the tree. This way I could individually address each LED in a logical manner. I used the Anodes for the columns and cathodes for rows.

Fourth I connected them to the digital pins 0-13 on my Arduino (I had 6 columns and 8 rows) and loaded some code from the Arduino Cookbook. Christmas is here!!!

Wednesday, October 16, 2013

Sensor readings

Finished the first iteration of code for capturing Roomba sensor readings. Now I have a function that can be used to access each individual sensor on the Roomba. I have some ideas to increase the speed of accessing the sensor values, right now it is quite brute force and wasteful, but it seems to work. The code posted includes some demo functions for outputting each sensor package. Code is available from my repository and a sample screenshot is given below: