We’ve had some new hatches in the Butterfly Fort, and there are at least six chrysalids which will be eclosing in the next couple of days1. This reawakens my interest in time-lapse photography.
I used to have a setup with a Harbortronics D2000 which I hooked up to my Nikon Coolpix 950 (and, later, Coolpix 995). It was good for a lot of things, but I succeeded in burning a nice streak across the sensor of the camera when the sun passed directly through the scene — the Coolpix line didn’t have a physical shutter, so the lens focused the sun onto the delicate sensor for the full time it was in view.
I’ve been using the Brinno Gardenwatch Cam that I received as a gift
a few years ago. It’s a dedicated, all-in-one time-lapse device. Once I learned a few things, I was able to use it successfully. First off, it really needs to be run on Nickel-metal hydride batteries. Next, you have to listen carefully when turning it on, because it’s not always obvious when you’ve powered it on and then off again by holding down the button a bit too long.
The Gardenwatch Cam does a decent job. It creates AVI format movies. It has 7 interval settings ranging from 1 minute to 24 hours. It has two focus settings, one for close up, and one for landscape.
With the monarchs, though, I want to be able to get in closer, and have sharper images than the Gardenwatch cam will give me. I still have a Nikon D70 which served me well for many years, but has been supplanted by the D90 in recent years. I also have a small assortment of lenses that I’ve accumulated over the past fifteen years. I’m thinking that the six megapixels of the D70 should be far more than adequate for doing some nice macro time-lapse work.
So the only problem is intervalometry — how do I trigger the camera to take pictures? Nikon sells intervalometers for most cameras, but the D70 is notably excluded from that list. There are a number of people making kits (or generously giving away their designs). I thought I might be able to rig something together.
I was successful. Taking an ancient Gateway Solo 9300 notebook that I’d bought for a king’s ransom back in 1998 or 1999, I installed Ubuntu 11.4 desktop on it. This was a mistake. The machine has a 366MHz Pentium II processor, and 128 MB of memory — lesser specs than your iPhone2. It got part way through the boot sequence, and locked up (terminal swapping? driver issues? I don’t know). I then installed a version of Ubuntu 8 Server for which I happened to have a CD. After installation, I booted into Matrix-esque screen garbage, but after some fighting with boot parameters was able to get running cleanly. Next, I installed gPhoto2. Putting the D70 into PPT mode, I hooked it up to the notebook with a USB cable.
Voilà! Now, all it took was a few commands:
Find the camera:
Store pictures on the camera’s compact flash card:
gphoto2 --set-config capturetarget=1
And take pictures at a 30-second interval:
gphoto2 --capture-image --interval 30
An iPhone locator app I’ve been building had a weird thing happen: if you denied it access to Location Services and entered a valid ZIP code, it would work — but an invalid ZIP code would always home in on Lancaster, Pennsylvania. At first, I thought it was a bug in how I was sending coordinates to MKMapView, but I quickly was able to confirm that the problem originated in my server-side geolocation service.
My server-side geolocation service uses Google’s deprecated Geocoding API version 2. The problem arose from sloppy coding on my side, coupled with Google’s map intelligence, and the v2 API’s reporting. Here’s how:
My code would assemble an address string from street number, city, state, and ZIP code (if provided). In this particular case, however, it was only receiving a ZIP code. But my code was crappy, and the address string it assembled looked like “null, null, null 90066″. If the ZIP code was legit (like 90066), Google’s geolocator is smart enough to figure out that it’s a ZIP code, ignore the “nulls,” and do the right thing. But the interesting thing happens when the ZIP code is not legit. Google’s algorithm evidently tries its best to match up the provided address with something you might be looking for. Perhaps due to previous searches with the API key we were using, perhaps for other unknown reasons, those “nulls” were matched to Noll Airport, East Hempfield, Lancaster, PA 17603.
Interestingly, the Geo Address Accuracy resolution value returned for that specific match is 9, or “Premise level accuracy” — the highest level of accuracy. Again, my crappy code had assumed that the Geo Address Accuracy was a confidence factor, not a resolution indicator. So that guess appears to be a really good fix, when, in fact, it’s no better than any other guess.
Revising the code to leave out the “nulls” resulted in another interesting result. Again, legitimate ZIP codes were found right off. Bad ZIP codes ended up being matched against other numeric codes, so, for example, “90000″ ended up matching Belfort, France, and “91000″ ended up matching Tawau, Malaysia. These results all come back with a Geo Address Accuracy of 5, or ZIP-code level.
One solution to this problem is to validate ZIP codes before submission to Google. Another solution would be to upgrade to the v3 API, where there’s more information about what’s going on.
Several years ago, we replaced our commodity hardware firewall (a Sonicwall SOHO from ’01) with pfSense running on an unused Dell 4100 desktop from that same year.
pfSense was a little confusing to configure the first time through (doing 1-to-1 NAT with virtual IPs and CARP was initially confusing, but the pfSense forums and The Google came to our rescue). Once in place, though, it did a great job. And when I say a great job, I mean that we could pretty much forget about its existence. It just hummed away in the background, and everything worked. When we needed to check up on our ISP, we discovered that quality of service logging was already supported, as well as pretty graphs of various connection properties. Very nice!
Over the last weekend, the 4100 locked up, and our connection was interrupted. Rebooting gave a firmware error about a bad disk in drive A: — but there was no disk in the drive. Power cycling, opening the machine, wiggling some cables, and blowing out some dust brought it back up, and all was well. Except it wasn’t, really. The machine spontaneously rebooted a number times over the next few days, and occasionally got into the “bad disk in drive A:” boot failure, requiring a hard power cycle. As I watched on the console, I saw the kernel fault out after too many memory checksum errors. The old machine was giving up the ghost.
After commissioning another old desktop (an ’07 vintage Dell, this time), I was able to install pfSense on it. I had to disable some of the extraneous hardware in the BIOS, but after about an hour I had it installed, booting, and ready to go. I was able to simple dump the configuration from the old firewall, load it into the new machine, reassign the LAN and WAN interfaces to the proper devices, and swap the boxes out. voila! Back in business!
With any luck, I won’t have to repeat this process for another five years.
I’m accustomed to having a hot-key in my text editor for inserting a time-stamp. Now I have a plain-text note-taking application that I want to use for managing my time, but it has no bells or whistles. It doesn’t allow the creation of macros and it doesn’t have a time-stamp function.
All is not lost! Using Automator, I created a service which calls a shell script to generate a nicely formatted time-stamp. I haven’t found a way to assign the service to a hot-key, but in many text input areas, a contextual services menu can be brought up with a simple right-click of the mouse.
Simple, nice, and convenient.
Here’s how to do it:
Fire up the Automator application. Create a new “Service” workflow: (click to enlarge)
For the operation, double-click on “Run Shell Script” and set it up as shown in the image below: (click to enlarge)
You’re done! Now you can insert 2011-08-04 16:58:06 time-stamps 2011-08-04 16:58:13 everywhere 2011-08-04 16:58:20.
Note: this is under Snow Leopard / Mac OS X 10.6.8. It probably will work under anything from Leopard onward.
I’ve had a few requests on Flickr to document what I’ve been using for bug hunting.
Well, here it is. Nikon 105mm f/2.8 macro, 36mm (and/or sometimes 24mm) Kenko extension tube(s), and Nikon R1 close-up flash system. I’ve been shooting mostly hand-held, 1/200 sec at f/10-f/22. I make up for hand shake by taking three or more pictures for each one I even consider keeping.