Grandfather clock; repaired

Recently the grandfather clock that my father built was brought up to our new house.  It had been having some trouble - it was skipping an hour at some point in the day and chiming the wrong hour from then on. My mom had tried to get it repaired, but it didn't work out.

It took a bit of time, but its fixed now.  In the end there were a just a few small adjustments to make, although it was a learning process to get there.  The movement had to be pulled entirely out of the clock and operated on the bench for a while to figure it out.

Its a beautiful mechanism.  I was actually tempted to leave it out of the clock and just operate it exposed, but I gave in to better judgement and reassembled it.  Works great now.

Here's a couple videos of the mechanism in operation.

The root problem was that the hour snail, which you see in the centre and has a different size step for each hour, was off by a couple teeth.  However, there were a number of slightly loosened or slipped parts which meant that after fiddling with it, it started chiming right through the half and three quarter hours together.  It was advancing its chime by one hour every 45 minutes while that was happening.  A slight adjustment of what i am going to call the chime wheel (I have no idea the proper name), and that was corrected.

And yes, there are a few (30+!) years of grime built up in there.  A future project will be to do a total overhaul and cleaning... but I think I'll get a bit more experience on clocks before I try that.

High Speed Photography

Recently i bought a FUJI HS-10 camera. A small step up from my good old Canon point and shoot. One of its neater features is that it can take high frame rate video. The size of the video shrinks as the frame rate increases. Theres not much technically to describe about this - set the framerate, point, shoot... The only thing to bear in mind is that it requires a lot of light, so this really works best outside.

Still, it lets you do fun things like take videos of popping balloons.

And this cannon shot is pretty cool too.

GPS Tracking

The other day I was wondering about tracking my bicycle routes, so I actually started to read the manual for my GPS reciever. Turns out, its really easy. Too easy, in fact, an interesting thing about Garmin GPS recievers is that they are always tracking you by default. Thats kind of disturbing, and you might want to turn it off for general use. But its kind of interesting to see your track sometimes.

With position logging on, your GPS track is located in a file called Current.gpx in the Garmin/GPX directory on the reciever. It looks like this..

                   ....
<trkpt lat="45.483459" lon="-73.582859"><ele>3.02</ele><ti
me>2010-02-21T18:09:14Z</time></trkpt><trkpt lat="45.483878" 
lon=""><ele>23.21</ele><time="">2010-02-21T18:09:48Z</t
ime></trkpt><trkpt lat="45.483880" lon="-73.583507"><ele>
44.84</ele><time>2010-02-21T18:10:02Z</time></trkpt>
<trkpt lat="45.483800" lon="-73.583487"><ele>40.99</ele><t
ime="">2010-02-21T18:10:07Z</t><trkpt lat="45.483653" lon="-73.5835
04">35.71</trkpt><time>2010-02-21T18</time></trkpt>
<trkpt lat="45.483607" lon="-73.583513"><ele>34.74</ele><t
ime>2010-02-21T18:10:17Z</time></trkpt>
                   ....

A little work with the shell makes it easier to read

  sed 's/><tr/>\n<tr/g;' Current.pgx > Current_formatted.gpx

thus

                   ....
<trkpt lat="45.483459" lon="-73.582859"><ele>3.02</ele><time>2010-02-21T18:09:14Z</time></trkpt>
<trkpt lat="45.483878" lon="-73.583719"><ele>23.21</ele><time>2010-02-21T18:09:48Z</time></trkpt>
<trkpt lat="45.483880" lon="-73.583507"><ele>44.84</ele><time>2010-02-21T18:10:02Z</time></trkpt>
<trkpt lat="45.483800" lon="-73.583487"><ele>40.99</ele><time>2010-02-21T18:10:07Z</time></trkpt>
                   ....

and we can clean out the xml tags like so

  sed 's:[abcdefghijklmnopqrstuvwxyzZT=<>"/]: :g' work_morning.dat > work_morning_cleaned.dat    

giving

                   ....
45.483765       -73.577330       53.01            2010-04-23 11:22:56
45.483493       -73.576993       46.28            2010-04-23 11:23:03
45.483415       -73.576909       44.84            2010-04-23 11:23:05
45.483381       -73.576872       44.36            2010-04-23 11:23:06
                   ....

No, sadly, i dont go to work at 11... its in UTC. I wanted to see it on a map, but was too lazy to actually read the kml spec, so i got a working kml file from somewhere, put my data in longitude latitude order, and manually pasted in the place of the data that was originally there. Like this,

  awk 'NF>1 {print $2 ",",$1 ",",$3}' work_morning_cleaned.dat >work_morning_data.dat

to get

                   ....
-73.574906, 45.482053, 39.55
-73.574535, 45.481752, 40.99
-73.574299, 45.481560, 42.44
-73.573888, 45.481230, 44.36
                   ....

The picture shows part of a GPS track generated yesterday morning as i biked to work. If you have Google Earth, clicking on this link to the kml file should display the track in Earth, which is more interactive than this png.

Some of the apparently high-altitude cycling is real - the bridge is actually quite high. But it does seem that the altitude info from the GPS is pretty noisy and wierd. I also have the impression that the receiver is gluing me onto the street. I was actually on the bike path, and I definitely didnt go on autoroute Bonaventure (although i did go underneath it for a ways).

The data can also be converted to meters using the proj.4 tool, and the total distance calculated like so:

 awk 'NF>1 {print $2 ,$1 }' work_morning_cleaned.dat >work_ll.dat
proj +proj=utm work_ll.dat >work_utm.dat    

to get:

                   ....
-4558775.49     8004745.96
-4558785.90     8004720.21
-4558786.15     8004719.30
-4558787.05     8004716.93
-4558788.19     8004714.00
                   ....

and then

 awk 'NR>1{dx=$1-lastx;dy=$2-lasty;dt=$4-lastt; dist=sqrt(dx*dx+dy*dy);  \
      sum=sum+dist; } {lastx=$1;lasty=$2;lastt=$4}END {print "Total Distance:",sum}'\
      work_data.dat
Total Distance: 27209.3

Twenty-seven km. That explains why my legs feel like jelly. Theres a few jumps and skips in the track and it appears to sometimes float off the ground, so it would seem that some more adjustments would be required before I would entirely trust this GPS track. But it does give me something to look at while my legs recover.

Writing a mobile phone app

Update (July 17, 2010) - the applet is now up to date with the new bus schedule from RTL.

So for a while now, i'd been wanting to write an app for my cell. In particular, some time ago i had written a Java applet which shows a countdown to the next bus leaving my workplace, so i know when to sprint out of the office in hopes of catching it. This could be a useful phone app, for obvious reasons.

Here is the applet, web browser style:

I dont have a particularly smart phone, its a Nokia 6275i, one of their Series 40 models. However, it does run Java. Despite the fact that i had bought the phone outright, not on a plan, my phone company (who shall remain nameless) had kept it locked down. With a little help from a friend, i managed to free it from their evil clutches using roughly this procedure.

Nonetheless, this just means i had to find a way to compile java apps for it. Such applications will utilize one of many different APIs for accessing the mobile device screen, etc. Different phones support different APIs, and which phone supports what does seem a bit confusing. However, there seems to be a bit of a standardization around the J2ME (vs J2SE which is Standard Edition, ME is Mobile Edition). Disappointingly, the newest J2ME is windows only. Blech.

However, i eventually found this article, and was able to get the Java Wireless Toolkit from Sun. This is basically one version back on J2ME and it runs just fine under Linux. The first step was to write a typical HelloWorld app, which was easy, i just copied it from the article. More difficult was to figure out which mobile device profile to use. Each profile determines the set of API functions available to you. By trial and error, i found that the JTWI, with CLDC 1.0 worked for my phone. For the reference of others - i recommend you figure out first which profile to use, as this determines the API available to you. If you develop for the wrong API, you may have to rewrite lots if the functions you used are not available on your phone.

What remained was to port the code from a web browser applet to something that ran on the phone - a MidLet. Theres a lot less functions available on the phone. The user interface functions are all different -not really surprising as the user interface is all different. Oddly many common functions are missing. Most annoying was the lack of String.format... but in the end that is not a very serious problem.

The phone has a relatively slow processor. My original applet was updating the time at 1/10th of a second intervals. Useless of course, but flashy. On the phone, updating this fast would lock the phone into a spasm of calculating. I had to pop the battery to get it to snap out of it. Updating at a more sedate pace of once a second - more than adequate, its a bus after all - made the applet more controllable.

The jar file from the phone can be downloaded here and the source code downloaded from here. I'm very interested if it runs on other peoples phones - do let me know in the comments.

You can also svn the code from assembla if you would like to help in the development.

svn co http://subversion.assembla.com/svn/NextBus

Project #1: create a blog

At heart, i'm a maker. I make stuff. Bread, robots, strangely shaped pieces of wood. In fact, it doesn't really matter much what. This blog is to post notes and pictures of the making process.

So, step 1, create a blog. Looks like i'm done. Till next time then...