Computing stuff tied to the physical world

TD – LED flashlight

In Hardware, News on May 22, 2012 at 00:01

Welcome to the Tuesday Teardown series, about looking inside the technology around us.

Today’s episode will be a short one, it’ll become clear why halfway down this page…

This is a little bargain LED flashlight, nothing to it really:

DSC 3228

Three AAA (not AA) cells, a toggle button, 24 + 4 white LEDs, and that’s it. Press the button once, and the 4 LEDs on the side turn on, press again to light the 24 on the top, and again to turn it off.

Quite a bright light BTW. The 4 LEDs draw 190 mA, with 16 it rises to 270 mA. That’s perhaps 4 hours of use with 16 LEDs before the batteries run out.

The circuit is as ridiculously simple as can be – one 4.7 Ω resistor and a switch:

DSC 3229

That “metal” reflector is actually plastic with a chrome finish. The PCB is one-sided, no doubt to lower the cost:

DSC 3230

(it won’t take much bending to create a short with that top wire!)

Using Ohm’s law (V = I x R), we can deduce that the LED’s forward voltage is 4.5 – X = 0.190 x 4.7 – in other words, X = 4.5 – 0.190 x 4.7 = 3.6V. Note that the light intensity will vary considerably with battery voltage and that this lamp won’t work at all with 3 AAA EneLoop batteries which only supply 1.2V to 1.3V when fully charged.

The reason I’m opening up this trivial little gadget is not to marvel at the deep electronic engineering that went into it, but to show how custom plastics and a custom case makes something quite practical and nice to the touch. The top and bottom have a rubbery feel to them. The bottom has a little plastic hook in it, which can be folded out.

The bigger news today is a bit of a mess, unfortunately.

Last night I decided to upgrade the JeeLabs server from Mac OSX 10.7.3 to 10.7.4 – that update had been out for a few days, worked fine on two other machines here, so it seemed safe to apply the update to the server as well.

It failed.

This server is connected via wired Ethernet, and I usually only look at the GUI via a VNC-like “Screen Sharing” mechanism built into Mac OSX. It works well, because that connection is re-established even when the machine is in an exclusive “Updating…” mode, so you get to track progress even while the system is busy replacing some of its own bits and pieces. No screen needed, even though part of admin interface sometimes uses the GUI.

Last night, the server failed to come back online. Which is a major hassle, because then I have to move it to another spot to hook up a mouse, keyboard, and monitor to see what’s going on. Never happened before.

Trouble is (probably), that I turned the darn thing off forcefully. I knew that all the VM’s had been properly shut down, and I heard the characteristic reboot “pling”, so I thought it was waiting for a GUI response… or something.

Then the trouble started. Hooked it up, did a restart: no go. So I restarted it in recovery mode, and did a disk check/repair of all the disks. Guess what: the startup disk with all VM’s could not be repaired… whoops!

Time to kick my backup strategy in gear. I have two in place: local hourly Time Machine backups to a second drive, and daily backups for all VM’s to the cloud.

To make a very long night story short: the local hourly backups are fine, but they do not include the VM’s (whole-file backups of a VM disk every hour is not really practical). And the daily backups? Well, they are indeed all there – I can get any day in the past 3 months back, for any of the 4 VM’s. Awesome.

But Turnkey Linux does things a bit differently. Very clever in fact: it only backs up the minimum. The Linux Debian packages for example: these are not backed up, but re-installed from some other source. The rest is a well thought-out mix of full and incremental backups, and it all works just as expected.

Except that my VM’s are about two years old now, and no longer the latest base images used by Turnkey Linux. No problem, they say: you can get the latest, and then recover your own stuff on top of that.

So I spent about 6 hours trying to work out how to get my VM’s back up from the Amazon S3 storage. No joy. I can see all the files being restored, but the result is not a working VM. At some point, package installs & updates hang, with either udev restart problems or bootdisk image generation problems.

And now the crazy bit: the JeeLabs weblog + forum + café sites are all back up again (phew!). I restored from Time Machine to a freshly freed disk partition, and restarted the Mac – it’s alive! Right now, the server is running from the new disk partition, but with the 4 VM disk images still on the damaged partition. So apparently they did not get any damage, although the Mac file system structure on that disk seems to be hosed.

I’ll spend some time thinking about how to clean up this mess, and how to avoid it in the future. The good news is that I lost no data – just a lot of time and some hair. Yikes … this really was uncomfortably close to the edge!

The moral: test the backup strategy regularly. It can still break, even when not changing anything!

Update – All systems are “go” again.

Update 2 – Final diagnosis: one of the 2 internal disks was getting too hot, leading to intermittent failure, so it was hardware after all – unrelated to the 10.7.4 software. And it was probably all my fault, because I placed a (fairly warm) router on top of the Mac Mini. I’m going to replace the failed system drive with with an SSD.

  1. Hah, the proof of the pudding… Congratulations on, well, not a fully functioning back-up recovery system maybe, but on getting everything back online, on your own within a day, with no data loss! I bet there are lots of (big) companies out there who couldn’t have done the same.. Well done!

  2. You should take full backups every so often not just incremental. Check out this episode of techsnap for information on proper backup regimes from a couple of long time sys admin types.

    • Time Machine backups are full backups. And Turnkey Linux backups are also full, once a month.

  3. Hi jcw, how about keeping a Live CD for the proper base version of Turnkey Linux available somewhere? That way, you should be able to do a reinstall an apply the diffs.

    Like you said, Time Machine is not suitable for backing up a running VM image. At home I run a variety of VMs on my Linux boxes. Once a week, the VMs are briefly shutdown so I can create a consistent snapshot copy. Typical downtime is 1-2 minutes; snapshotting the filesystem is a matter of seconds. I can then copy the snapshot to a FreeNAS box for backup. And the FreeNAS keeps several versions, again in snapshots… A bit more complex than your solution, but I like consistent backups ;-)

    Anyway, back on topic: once upon a long ago, I was invited to the Philips Remote Control lab at Audio in Belgium. They had some sample CD-i remotes. After experimentation, they found that a rubbery surface (coating) conveyed higher quality to users. Also, weight matters a lot. They added small balls of fishing lead inside, the result was very convincing… First impression really counts!

    • Yes, I’m considering keeping a better complete snapshot around. Probably via CCC to another disk partition (am still pondering on what number/size disks to keep active). Turns out that the failing drive did have hardware problems (recoverable read errors), and probably it was getting too hot. More cooling (not putting something else hot on top!) helped reduce the problems.

      Note that Parallels has an auto-timed snapshot facility, and it claims to work with Time Capsule (it probably saves changed blocks in a separate file). Still looking into that as well. What a time sink!

      Thanks for the notes on industrial design. It makes a lot of sense, but it sounds like deception :)

  4. About deceptions in hardware: I can’t help but feel cheated after discovering on a Discovery Channel’s “How it’s made” episode that those nice, hefty table knives don’t have a sturdy metal handle, but is actually a thin metal wall filled with putty (Dutch: kit).

  5. VM snapshots are actually DIFFERENTIAL backups: every changed sector that gets written to the disk is saved in a file — you just need the full “base” and the difference. I don’t know parallels, but you can usually take a full snapshot a day and save it. To use less space you can use some ‘diff’ tool: 1) take snapshot: writes to the disk start being “logged” to a different file 2) for a full backup, just save the whole disk image; for a differential run your favourite ‘diff’ tool against the last saved full image and the current snapshot 3) undo the snapshot (merge log file with main image)

    Restoring such a VM is just matter of minutes. And it’s like you pulled the plug.

Comments are closed.