a glob of nerdishness

An up-coming new hobby reminded me of the CHDK (Canon Hack Development Kit) project. I realized that my old Canon 350D body was ripe for some experimentation, since (due to a flaky shutter release button) I use it only as a backup to my T1i these days.

As it turns out, my Canon 350D (a.k.a. Rebel XT) digital SLR camera is not supported by CHDK. This means it’s outside of the normal CHDK ecosystem of motion detection, BASIC/Lua scripting and the like.

However, there is a way to hack the 350D to enable a smaller handful of “bonus” features and settings, including an ISO extension to ASA 3200 and an intervalometer mode useful for things like time-lapse photography. I had a few hiccups getting it going — proceed at your own risk! — especially from Mac OS X it seemed, but here’s how I did it:

1. First, find a small (4GB or less) empty CF card and format it using the camera’s menu — this should give you the FAT16 filesystem needed for the next two steps.
2. Grab the bootflg2.zip file attached here and copy the “bootflg2.fir” file in it onto your card, preferably via the command line. (NOTE: I had trouble when I just copied it using the Mac OS X Finder, which creates a hidden ._bootflg2.fir metadata file alongside. This extra file seems to confuse the camera in the next step, so make sure you delete this file if it appears via Terminal.)
3. Now follow the instructions in the ReadMe.txt file included in the bootflg.zip folder for how to trigger the “hacking” of your camera’s built-in firmware so it will load the additional bootable code we’ll be dealing with in the next steps.
4. Now download and use the MacBoot card preparation tool that fills in for the Windows-only CardTricks step. Make sure to choose the “Make DSLR-bootable” radio button, which (as explained above) is different than the normal CHDK process. You can use the same card as before or a new one(s).
5. Once you’ve setup each CompactFlash card to enable the bootable custom firmware, you’ll need to actually put a version of on each card you’ll be taking pictures onto while the custom controls are enabled. The latest version of these files I could find was 350D-20101011.zip (via the forums). Basically, put the included “autoexec.bin” file on any cards you’ve made DSLR bootable via the previous step.

There’s some more detail and links in the instructions buried within the banner ad–splattered CHDK Wiki page for the Rebel XT, as well as the best overall summary of how to actually use the custom menu features enabled by the custom code on your CF card about halfway down the page. If you have questions, the best place to get help and find even more details is probably this forum thread.

Not quite plug-and-play but on the bright side, there’s very little fluid dynamics or tax regulations involved. Now when I plug in a compact flash card I’ve made bootable, I get even more control over my exposures than the camera already provides out of the box.

With this hack running, I can also set my camera to just keep taking pictures, say, every 10 seconds — should be great for time lapse and remote photography situations. If I want to disable all the experimental “power user” features, I just turn my camera on with a non-bootable card in the CF slot, and it goes back to its normal featureset.

It’s been a busy week!

The biggest event was announcing the departure of my friend and Calf Trail co-founder Hjon from the company. It’s been in the works for a while, but this week we officially transferred the iPhone half of our work over to Hjon’s new LLC: Pseudorandom Software. (If you use FogBugz, be sure to check out his great Inbugz app. Despite keeping busy with other jobs, he’s got some useful new features in the works.)

The other big announcement was Sesamouse, a free utility to send real gestures and touches from the Magic Mouse. Translation into dev-speak: Sesamouse gives legitimate applications access to the Magic Mouse’s otherwise-crippled multitouch hardware features. It contains the private/undocumented API gunk within its own process, interpreting gestures and sending the system its results. Applications that use the publicly supported NSEvent and NSTouch APIs then work with the Magic Mouse automatically. Accomplishing this involved many hours staring at hex dumps and learning to read assembly, with a helpful boost of UTSL. Quite a fun challenge!

In the midst of all this, I also made some great strides on another iPhoto-related app this week. It currently lacks the finishing touches, but my wife and I already have fun testing it. Plans call for a beta release next week.

I’m hoping to give Calf Trail’s lineup of Mac products a big boost during the early part of this year. That way, even if sales don’t pick up, I’ll have some good stuff sitting out there while I’m busy finding paid work. I’ve been thinking a lot about the last two years’ investments…but that’s a topic for another post.

Trail Location is a subproject I’ve been working on at Calf Trail. Its primary goal is to be a drop-in replacement for Core Location that can use position data from any location service.

This enables a number of new possibilities.

But first a demonstration

More interesting location data in the simulator

Testing a Core Location app in the simulator is really boring. Apple might eventually wire the simulator up to Snow Leopard’s Core Location implementation, but that would just move your app from Apple’s headquarters to yours. Trail Location lets you send your own test data, which your app receives just as from Core Location.

Trail Location includes a sample app for your device that can send locations to the simulator as you pan around the map. It should also be easy to make an app that plays back recorded location patterns.

Send real GPS data to an iPod touch during development

This one’s a bit more complicated, but worth mentioning. The first two iPod touch models (hopefully NOT the third, but we’ll see) don’t have GPS chips and rely exclusively on Skyhook positioning, which is based on visible wireless networks. With Trail Location, you can use a laptop and a GPS receiver for better results in rural areas. (I bought an Amod ABG 108 Bluetooth GPS mouse for about $20! Unfortunately, you can’t use a Bluetooth GPS directly even with a second-generation iPod touch, because it would degrade the core experience or something.)

Trail Location includes a sample Mac app that can pass locations from gpsd to a listening iPhone app via WiFi.

Better Core Location on the desktop?

Snow Leopard adds the Core Location API to Mac OS X. This is interesting, because while on current hardware the Core Location framework itself is still limited to Skyhook positioning, the rest of the Mac platform is much, much more developer friendly. Trail Location could serve as the glue that connects third-party apps to third-party GPS receivers using the same well-designed API that Core Location provides. Just like you can use your device to send data to Trail Location on the simulator, you could use an iPhone as a GPS mouse for a desktop app.

Eventually, I hope Trail Location can grow mature enough to be left in code that ships to end-users, giving more people the benefits of an open location platform. Currently, you should consider it as an alpha release, NOT ready for anything but debug builds. Right now the code is overbuilt (debatably) but under-implemented (definitely). We’ve released it now so that it can help other developers test their Core Location apps, and so that any progress towards the long-term goals can be influenced by other developers. Get the source at Google code; it’s shared under a non-viral license but your patches are welcome.

I flew to rural Northwest Illinois last week, to visit my childhood house and stomping grounds for perhaps the last time. My parents, who had settled there for two decades, are moving several states westward to a house in the city. Pulling up those kind of stakes is an opportunity to realize just how much junk can accumulate without careful curation.

Nerdishness, it turns out, is genetic. The pack rat tendency may be a learned behaviour, but the hereditary effect is the same. Combine the two and the offspring will look something like this:

The decades of collecting and the two days of extraction and disposal were a team effort between my dad and me. I’m sure there were some gems in all that junk, but that will be for the salvage yard to figure out. This necessary catharsis might not have cured either of us of our collecting habits, but it was a healthy step in the right direction. The whole week, Dad kept singing a chorus about the freedom we find from the Things We Leave Behind; I felt like I was Mourning the Death of a Dream instead. Dad’s choice of Michael Card song was more appropriate, but the components and computers we did keep still carry kernels of nerdish dreams.

I’m glad I’m not the only one who wasn’t surprised by no Blu-Ray in the new iMacs:

So who do I think will win the high-def format war? TCP/IP.
–Steven Frank

There’s an Apple announcement roundup on MacWorld that echoes the same sentiment. From the Apple TV to the new iMacs, Apple seems to be waiting on this format war (though see below) and hoping their disc-less hobby box and online store win.

It’d still be nice to be able to make double-digit backups onto higher density discs. It seems like HD-DVD, being naturally more scratch-resistant, would be the better media for that. Depending on how much Blu-Ray’s “scratch proof” coating actually gets used, there’s no point in burning 10GB more per layer if it will be unreadable after the real world gets to it. But alas, Apple is on the Blu-Ray board (link=good comparison article, btw), so if only one makes next year’s Macs I probably won’t get my druthers.

Ok, so I’m not getting an iPhone (and don’t plan on even getting a cell phone anytime soon), but it is kinda fun to see what some people do the instant a new Apple product (or other hyped-up gadgets, not just Apple’s) comes out. For example, Think Secret has a gallery of their disassembly project, and AppleInsider has an article summarizing the take-apart job that the folks at iFixit did very soon after acquiring an iPhone.

Finally, for anyone who wants to see what it’s like to open up an iPhone box for the first time, CNET has been so kind as to post a video of the unwrapping of their iPhone.

More on hard drives. Here’s a paper that won a “Best Paper” award at FAST ‘07. And a wonderful summary from StorageMojo. Schroeder and Gibson are from CMU’s Parallel Data Lab.

Blogged with Flock

Google put out some research on hard drive failure trends lately, and they should know. You can check it [pdf] out, as well as some hundred other papers at Google Labs, or read a summary at engadget. Unfortunately, to keep their edge against competition, I guess, Google didn’t release results related to the failure rates by manufacturer, though they admit there is a correlation. Of course, you can always Google for that kind of advice….