Can’t believe how much time has passed since I’ve posted anything. I really should try to make up for that oversight.

My robot project continues to evolve, the mechanical parts are coming together rather nicely. The picture here shows the most current status, with the chassis, motors, suspension, battery holder and deck are in place. The electronics will be mounted to the deck as soon as I get the boards back from production by BatchPCB.

The boards will be the interface between a Gumstix Overo and the motor controller and sensor boards. I’m using CAN as the communication mechanism. My other post sort of explained how that all works.

My hope is to have the robot up and running around by late June, in time for the Vancouver Mini Maker Faire. The Vancouver Robotics Club will be doing demos all weekend.

Despite my initial disappointment with Netflix in Canada, it is more appealing than I originally thought. I’m still frustrated by the lack of “big name” movies – even those that are quite a bit older e.g. 2001 or Close Encounters of the Third Kind. On the positive side, I have found a few good films that I’ve really enjoyed.

The trick seems to be to “sneak up on them”. In other words, I never find movies by searching for movies I think I want to see – those are never available. Instead, I explore what movies are available, as linked to other movie suggestions. I haven’t found very many of the initial suggestions to be good enough to watch, but I believe that is a feature that gets better with time, so I’m willing to keep trying.

I think we’ve decided to keep our subscription going. At $8 per month, the cost of getting this decision wrong for a few months is not very high. Maybe that is why it works – it only takes one or two movies a month to make it feasible. We’ve run out of episodes of Top Gear to watch though, so now we need to find that next unexpected gem to watch. More than ever before, I’m confident we’ll find it.

Uh what? Netflix, please explain to me why Resident Evil and a later movie in the franchise is available, but not this one (second in the series)?

Background: so we purchased one of the new Apple TV boxes for ourselves for Christmas. The new Apple TV is excellent, and I find it even better than the original (which I also own). It is streaming only, which is unlike the original, but it works flawlessly. We’ve purchased about five different movies from the iTunes store and each has played without fault.

Then we signed up for a Netflix account. They have a free month trial program, and at $8 each month it seemed like a good deal. So far, I’m not very impressed. The selection is less than stellar, there are some surprising gaps and the Apple TV interface really stinks for finding titles. We’ve ended up using their website to find titles then “Search” for them. Sigh. I’ve watched about a dozen episodes of Top Gear without trouble, but the first (The Great Train Robbery) of the two movies I’ve watched had severe download issues – every few minutes the stream would stop and the film would pause for a minute or two. The second movie (Resident Evil) worked without issues, so I was ready to accept the problems might have been temporary.

Then we decided to watch the sequel, Resident Evil: Apocalypse. Finding it via the Netflix interface didn’t work so I went to the website. Imagine my surprise that this film, made in 2004, is not available. What? It makes no sense to me, although I’m pretty sure Netflix isn’t choosing to do this. So it probably means that one of the many production or distribution companies involved doesn’t like Netflix.

I had higher expectations for the Netflix catalog, especially when compared to the availability in the US market. Sort of sucks actually. I don’t mind paying for the latest movie releases (that is why I’m using the iTunes store with the Apple TV) but when it comes to a deep back catalog, that is something I expected Netflix should be able to provide at a flat rate per month. Apparently I was mistaken, at least for today. I’ll give Netflix more time to see what changes, especially since it it still part of my free month, but I can’t see paying $8/month until the current situation improves.

Recently Eileen needed some help with creating a video to promote the Canadian Booksellers Association “Independents’ Day” back on October 16th. She wanted to promote her favorite local independent bookstore in North Vancouver.

We are not professional film makers, but I figured that we could pull something together. My equipment was limited to iMovie and Quicktime, my iPhone 4, a tripod, and a couple of dogs as “extras”. After bouncing around a few ideas we came up with the idea of silent film style clip, as it wouldn’t require audio, and some simple Quicktime effects would mask the low-end video recording. In all, I’m really happy with the results especially since we made the whole thing in one evening.

You can see the full version here, or a version tailored for mobile devices here. The silent film concept worked but we needed a twist to make it timeless (you’ll have to watch the video to see what we did).

A while back I posted about my work to enable support for the Microchip MCP2515 CAN controller with my Gumstix Overo. At the time I was confident of success because I was successfully receiving messages from my AVR setup. It was only recently that I discovered that in fact although reception was ok, transmission was not actually working.

Debugging the mcp251x Linux driver was an interesting exercise. Google wasn’t much help, as it seemed the few others attempting this same feat were either successful or completely unsuccessful. My situation suggested I didn’t have any electrical problems nor did I have any compatibility issues. Though resolving my problem I learned a whole lot of stuff I didn’t expect to, but it was really fun and rather educational. Maybe by sharing my diagnostics process others can learn something too.

Since I had a working receiver I was working under the impression there was some sort of issue with the way I configured the mcp251x driver. I tried upgrading to the latest version of the kernel (2.6.34) but no joy. I also looked at the latest development version of the mcp251x driver from the SocketCAN project. No new insight there at all.

From building a simple driver for the AVR chip I had a good working knowledge about how the MCP2515 works, so I figured it was really something to do with how the driver was written. It obviously wouldn’t be a generalized problem, but I had no idea what could be wrong. I started by adding a whole bunch of printk() debugging statements to better trace how the driver was called from userspace. Something odd was happening where the driver was repeatedly polling the MCP2515 chip for status. I traced what it was doing in the code and also followed the SPI conversation using my Saleae Logic logic analyzer. Nifty device by the way, highly recommend it. Turns out it didn’t really help solve the problem, but it did manage to help eliminate various false leads.

The SPI conversation and responses were perfectly normal. More printk() statements later and I was rather stumped. Then it occurred to me (at a time I wasn’t actually in front of my project) that there really should not be any polling. The driver configured itself with an interrupt line to know exactly when an event was pending. The polling I could observe over the SPI bus suggested this mechanism was not working (the status returned by the chip was correctly suggesting there was no pending events most of the time).

Turns out the default Overo build from OpenEmbedded sets up the GPIO pin for the interrupt line with a pull-down resistor. The interrupt line should normally be high then pulled low to signal a pending event. As far as I could tell, the pin was never actually being pulled high enough to be sensed by the Overo processor. I expect that the voltage level converters I’m using are to blame, failing to overcome the resistance of the pull-down resistor. This meant the Overo was seeing the GPIO pin as a low logic level all the time, leading to a constant interrupt. When this happens, the interrupt handler will fire and poll for the reason for the interrupt. Inspection of the code suggests this could starve the transmit code path from ever getting enough time to send messages. Indeed this would explain the situation I was observing. I adjusted the pin configuration in the u-boot recipe (now in my user.collection) to use a pull-up resistor instead, and now everything is fine. Because of the way that the mcp251x driver is written this should be ok.

I also discovered my previously published user.collection tarball was not matching my actual configuration. For reasons that are (again) likely due to the voltage level converters I lowered the maximum SPI rate to 500kHz. I’m using a CAN bus speed of 125kHz with a very low message frequency, so this doesn’t seem to be a problem. I was also annoyed by several of the useless messages printed to the console from the SPI driver and the mcp251x driver, so I commented them out with my own patch. Both issues are now fixed in the tarball. Download, roll into your own user.collection directory, and enjoy.