Carlitos’ Contraptions

Ever since the implementation of the new Opus Card system by the Montreal’s Public Transportation (STM), there have been lots of malfunctions and bugs.

Crashed STM Ticket Vending Machine

The malfunctions were mainly caused by the poor build quality of the smartcards, the poor wireless reader range, the easy demagnetization of the paper tickets, etc. Slowly (very slowly) these malfunctions are being addressed and (sometimes) solved. The unsolved bugs become a part of the daily routine and we Montrealers learn to accept them.

On last weekend, I witnessed a bug that I would have never thought possible in a professional widespread software application that involves so many money transactions: what I usually call a boundary condition bug.

The Bug

Quick note on the STM’s fares (for those who do not live it day-to-day):
There are mainly two transportation systems: the bus and the metro (subway) and the fare pricing is governed by a (somewhat) simple set of rules:

• There are monthly passes that allow unlimited fares within the month in both the metro and the bus. They are more expensive for adults than for students or elders.
• There are weekly cards that are similar to the monthly cards by work for a given week.
• There are tickets (either as a magnetic paper card or as some information on a smartcard) which allow for one fare that allow to take the metro, the bus, or both within a two-hour time limit. Should the time period be elapsed, or should you take the metro or the same bus more than once, you will need another ticket.

Since the Opus Card implementation, one of the first things that came into my mind was the attention required to compute the fare price when a month ends (i.e. at 12:00 on the 31th, 30th, 29th, or 28th), or when a week or a day ends. Everyone who has programed at least a little bit (like me) knows that these boundary conditions are usually exceptions to the normal behaviour of a program and need to be taken into account. I, of course, assumed that such mundane exceptions would be addressed by professional programmers swiftly and painlessly. I was wrong.

On last Saturday, my girlfriend and I took the metro after going to the movies and she swept her card (loaded with tickets) at exactly midnight (00:00 as reported by the STM records) at the metro reader. Around 20 minutes later, we walked into a bus and surprise! another ticket was charged instead of using a transfer from the previous ticket.

The conclusion to this is that when a day ends, there STM fare algorithm fails and defaults to charge you an extra ticket. Unfortunately, It is unlikely that this bug is noticed by the STM any time soon since they are not loosing any profit from it and they do not accept bug reports. Even the lady at the reclamations booth had a hard time to understand what the problem was.

In the end, instead of a full refund she got a “courtoisie” ticket which expires on next Sunday (instead of a regular ticket that which expires in around two years). So much for costumer service.

The poor programming quality is also reflected by the poor choice of OS for their vending machines. Let’s just say that using Windows Embedded is the equivalent to eating a faulty grenade: it will rather sooner than later get ugly.

Google Wave

I finally got a Google Wave account and I decided to do something for the community. More precisely, the hacker/tinkerer/DIY community.

I think it would be rather interesting to have a place where to share, showcase and discuss projects and hacks with local people (from Montreal).

If you want to join the wave you can find it here.

I hope this will result in a stronger more connected Montreal Hacker community.

Cheers, and see you on the wave!

I have a few Wave invites left so if any geeky Montrealer would like one, please leave a comment and I’ll see what I can do.

In my trip to San Francisco, I had the chance to see many beautiful things. And I wanted to be able to remember them and show them to my friends and family.

San Francisco Seen Form Twin Peaks Park

Besides taking simple photos, sometimes you need a wider view- angle to really capture the scenery. The obvious solution to this is making a panorama. This means you take many pictures of different sections of your subject and then align them and stitch them together so to form a bigger picture.

Many people believe this is a very difficult procedure and that the results are never as good as expected, and they are partially correct. In order to get a nice looking panoramic picture hat will align and stitch together correctly you need to follow some rules:

• Make sure that contiguous pictures have a good 30% overlap between them.
• Make sure the overlapping areas contains some hard object, like a building. If they overlap only over the sky or some water, then the stitching together will be more difficult.
• Make sure you follow a simple pattern when shooting the photos. Follow a horizontal line, for instance, and shoot the pictures in order. Also, if your making a taller panorama, I suggest you shoot many horizontal lines that will stack up together. This will make things easier when recognizing which photos to stitch together.
• Make sure all the pictures have a similar exposure. This should be no problem if you are shooting your pictures all at once.
• Make sure your subject is always on the same focal plane. You can have many focal panes but it will make the stitching more difficult.

Once you have shot all the pictures you can start the stitching. In order to so so, you can use an excellent software package called Hugin. Of course since I’m using it, Hugin is open source and (thus) cross-platform. Is is a very intuitive program to use and since there are many good tutorials about it, I won’t be outlining the instructions on how to use it.

Once you stitched your images together (which can be done in the three steps the wizards takes you trough) you will end up with a big TIFF or JPG file. Now you are basically done. Now you just need to crop it and made any desired adjustments with a picture editing program lie Gimp.

The only problem is that if you want to share this picture it can be hard since it may be too big for sending by email and will take a long time to (upload and) download if you put it on a website.

Now you can use the Google Maps Image Cutter. This little Java program developed by UCL enables you to use the Google Maps engine as a picture viewing system. It creates many copies of your image at various resolutions and chops those images into small square pieces. Then when you view the image trough the google maps engine, you are only loading the small squares at which you are currently looking at the resolution corresponding to your zoom level.

Here you can enjoy a few examples I made (click on the title to view them in full screen).

Keep in mind that Hugin is very powerful and can do much more than simply stitching a few images together. Also, there might be a few issues with the file writing routine when trying to run the Google Maps Image Cutter in Linux.

The Opus card is pretty much like an onion
~ Oscar Wilde

Here in Montreal, the public transportation system (STM) started to use a new system for paying the fares: a smartcard.

This smartcard is called Opus and features contactless communication as well as regular metal pads (like those on telephone cards). This card can be recharged with various tickets, month passes, week passes, etc. More info on it can be found in its very own wiki page.

Ever since it came out, I wanted to hack it and learn more about it. By searching a bit on the net, I found out that it is similar to other smart cards being used elsewhere in the world and this allowed me to learn some interesting things.

Similarly to the Hong Kong version of the system, the reader has a security feature that avoids writing to more than one card at the time. Let me explain: if you try to add fares to many cards at the same time (on the paying machine that features a contactless reader) by placing them on the reader, only the first one will get loaded with fares. This means that the cards are more than a simple memory, they feature a more complex and almost certainly encrypted communication system.

Also, each card has its own identification number.

Observations on the card behaviour:

• Cards loaded with a monthly pass will make the the readers shine a green light (or yellow for students) during the given month and grant access.
• Cards loaded with tickets will make the reader say that one ticket has been used, shine a green light and grant access (same behaviour as with alternative magnetic band tickets). The ticket is then spent.
• If the card with a ticket is read again within two hours of spending a ticket, the reader will shine a green light and grant access without spending another ticket. The readers also displays a message acknowledging this.
• The process of loading a card with new fares takes around two seconds after the payment has been performed. While the card is being loaded, a yellow progress bar is shown. This means that writing to the card is a slow operation and cannot be performed on the fly while passing the card by the reader when entering the bus, for instance.
• It is unlikely that the readers in the buses are connected in a network with all metro stations and themselves.

How I think the card works:

1. The card is put next to the reader which provides it with power (same as any contact less communication)
2. The reader sends the current time to the card.
3. The card checks if it can grant access to the transportation at the given time.
1. If it has a month pass, the card only worries to see if the month is write.
2. If it has a ticket it stores the time and spends a ticket.
3. If it has spent the ticket in the previous two hours it does not decrement the ticket count
4. In all the previous cases, the card sends the instruction to the reader to grant access and tells it what kind of message/light it should show.
5. If the card does not have tickets or month passes or transfers (a ticket spent in the last two hours) it less the reader so and the reader does not grant access.

If this card is any similar to the ones in other countries, all the communication between the reader and the card are encrypted. The encryption may be symmetrical which means that there is a secret key shared by all the readers and the cards.

Also, at some point, the card may send its unique ID number to the reader.


Some extra info:
I also wanted to see how the card is built, and the easiest way of doing so is to disassemble it.

Since it is made out of plastic, I put it to rest in a bath of acetone (nail polish remover) for a bit less than a day while periodically checking how it was doing. I poured the acetone in a old iPod metal casing since it has almost the same size as the card.

In the end I found out that the card is made up of several layers. This layers are very thin (or so are they after being soaked in acetone for 20 hours) but very sturdy.

The middle layer contains the antenna and contact pads in order to be connected to the microprocessor. The chip is merely sitting on the pads, this may explain why the cards are so prone to break: when it is bent, the pads do not touch the antenna any more and the the card becomes inactive.

Note that the dissolved plastic in acetone really stinks on the fingers when you manipulate the dissolved card and it is really a pain to clean.

In many drugstores and bookstores here in Montreal (AFAIK), we find the Solitudes CDs. These are CDs containing music mainly based on nature sounds (elevator music really). The interesting thing about this CDs is that they are displayed on a shelf with an interactive player that the customer can use to get a glimpse of the content of the CDs being offered. In other words, the customer touches on a CD icon, and the shelf starts to play (what seems to be) the contents of that CD.

Oddly enough, I found the guts of one of those shelves in the garbage and I will expose my findings here. Also, the system I found is in perfect working condition except for the power button which was broken.

How the system works

One might think that the shelf contains a CD library that plays the selected CD on command (that is what I thought anyways). But it is much simpler than that. The system consists of a computer CD drive connected to a small computer power supply and a sort of IDE controller (run by a microcontroller). The IDE controller is told what to do by the user interface, a sort of large keypad hooked up to a(nother) microcontroller. The sound is taken from the CD drive by using the standard audio port.

But, how come it can play all the CDs if there is a single drive? Simple, it doesn’t. It plays a special CD, with tracks corresponding to each one of the displayed CD. The tracks contain a mix featuring short samples of the CDs’ songs. One can have the illusion the entire CD is playing since nobody stays near those shelves for long enough.

Some Pictures

(BTW, I thing the pictures are much more enlightening than my explanation. They show the naked keypad, the back of the keypad with the microcontroller and dip switch position guide, the inside of the black box, and the IDE controller.)