Building a battery

I wanted to take some pictures yesterday, so I dug out our Canon EOS Rebel T7i camera, which hadn't been used in a year or so, and found that the battery was completely dead - like, so dead that it wouldn't take a charge.  The Canon batteries have a protection circuit - once the voltage drops below the "safe charging" threshold, the protection circuitry cuts off the battery from the electrodes, so it can't power anything and also can't be charged any more.

Looking on Amazon, I found a pair of no-name batteries which claimed to be replacements for the LP-E17 Canon battery, with a charger, for about thirty bucks.  "But wait!" I thought.  "I have all the parts to BUILD a battery that should work!  I bet I can design a case, 3D print it, and assemble a working prototype in a few hours... and turn IDLENESS and SLOTH into ELECTRICAL POWER!"

Sure enough, I had the most crucial part - two Li-Ion cells which would both fit within the form factor of the Canon LP-E17 battery, and provide the 7.2V (nominal) which the camera needs. 

OK, the guts were taken care of.  Now, about that case...  I've been 3d-printing stuff just long enough to have some facility with Fusion 360.  How hard could it be?!?  Turns out, between making measurements and the fact that I really am just a rank amateur at 3D design, it took about four hours.(including some "proof-of-concept" printing to make sure I could ACTUALLY make it fit in my camera before spending time getting it all "just right".)

After a little printing, soldering, and electrical tape (for safety!), I managed to put together something that actually fit!  I always get a little nervous playing with lithium ion cells, because they'll quite happily dump several amps worth of current into that short circuit you didn't realize you were making. 

 I managed to get everything assembled without shorting anything out, and a quick check with the multimeter showed 8.25V in the correct polarity, so... let's try it out!

It fits!  I can even remove it!  Even better, IT WORKS!

Now... do I recommend doing any of this?  Absolutely not!  This took far longer than I expected at the outset.  It also runs the risk of fire and/or damage to an expensive camera... all to save $30.  But it does feel pretty good to have set myself a task and completed it.  Now... what was it I wanted to photograph, again?

NetBSD on Banana Pi

The "Banana Pi" is a new(ish) ARM-based board, aimed at being "mostly-compatible" with the Raspberry Pi - which they have accomplished to a degree.  The Banana Pi has a newer, ARMv7-based core, though, so has the potential to be a lot faster.  I'm always looking for new hardware to test NetBSD on, so I thought I'd give it a shot.  At about $65, it's more expensive than the Raspberry Pi, but since it has more on board (SATA, Gigabit Ethernet, dual-core CPU, 1GB RAM), it's a pretty good deal. The one I ordered came yesterday, so I fiddled around with it bit trying to see how fast I could get a kernel booting.  I downloaded the "Bananian" Linux image, booted to make sure it worked, and investigated how the boot process worked.

NetBSD 6 is out!

I pulled the trigger on the release of NetBSD 6.0 this morning, and a huge weight has lifted off my shoulders.    Here's a quick rundown on what I like about NetBSD 6:

• Multiprocessor support for Xen DomU ("guests").  This one is huge!  It puts NetBSD in a great position on various Xen hosting platforms, such as Amazon EC2, Rackspace, Panix and others.
• NPF, the new NetBSD Packet Filter.  It's still a little rough around the edges, but it's solid and it promises to have great performance, as it's written from scratch with multi-core CPUs in mind.
• Great support on low-power embedded platforms, such as lots of new ARM platforms and PowerPC  MPC85xx.  I just built myself a router for home out of a DreamPlug running NetBSD 6.0, with NPF as a packet filter.  It's working great, and only draws between 9 and 10 watts of power!
• NetBSD's phenomenal build infrastructure.  This isn't new, but it bears repeating:  if you're developing for NetBSD, you can build it on almost any POSIX platform!  I personally have built on NetBSD, FreeBSD, Ubuntu, Centos, and MacOS X (recently).  It's one feature I wish all other systems would adopt.

Now to catch my breath and prepare for 6.1, in which we hope to have full support for Raspberry PI and some other new platforms...

NetBSD 6 is getting closer!

With the announcement of NetBSD 6.0_BETA2 availability, NetBSD 6 comes closer to reality.  There are still some outstanding issues, but we're getting closer!

We're hoping to have a release candidate out in a month, and perhaps the final release in 7 or 8 weeks!

Supporting local business, and reliability.

I work out of my house, and so having reliable Internet service is important to me.  I don't make much money at the moment, so things being inexpensive is also a plus.  Additionally, being able to keep the dollars I spend local is a great thing - I *like* doing business with people nearby for a lot of reasons.  So, I was thrilled a while back (a year, maybe two) when I learned of a local wireless ISP who was lighting up my neighborhood - and their HQ in the Mission is about a mile from my house!

Photo by Adrian Black, on Flickr

So, I signed up.  I believe I was a relatively early customer, in that they didn't charge me a monthly fee (just an install fee for the wireless bridge on my roof) for a period of a couple of months, because their residential wireless service was in beta.  They eventually got me hooked up (they were busy at first announcement, no big shock there), and I was pleased with the speed I was getting - it was about the same, or slightly better than the speed I was getting with Astound, the number 2 local cable Internet provider, at approximately the same price per month (once billing began).  I was very happy during the beta period, getting decent service for free.  There were a few glitches, but I didn't mind - I kept my Astound service during this period, so when push came to shove, I could switch back if there were problems.   I wound up switching back two or three times during the months I was a beta customer.  No big deal.  Then, the beta came to an end and they started billing me, so I canceled my Astound Internet service after about a month, not wanting to get double-billed.  Because of Astound's bundle pricing, it winds up costing me slightly more to get my Internet service from another ISP, but when it's working well, the speed is higher.

Things were OK for a while.  I started noticing occasional glitches during the day, but I didn't think anything of it.  Then, I started paying attention to their Twitter feed (which one of the founders tweets on), and realized that they were fairly regularly doing network maintenance *during the day*.  Hm.  OK, small business, small staff - I guess I get it.  But as I paid fairly close attention during the next year, I noticed a *lot* of outages.  Most were small, but a few were 10-20 minutes.  One lasted multiple hours(!). Sometimes it was maintenance, sometimes genuine problems.  The practical upshot is that over the last year-plus, I've spent probably 15-20 hours troubleshooting (to rule out my local setup) or waiting for fixes for what eventually proved to be issues on my provider's network.  They're really nice, and very helpful, but I start to wonder:  at what point is it just not worth it to me?

Unfortunately, I think I'm reaching that point.  Luckily for me, being in San Francisco, there is at least one more local-ish provider I can choose from.  I don't like the idea of spending more cash on setup fees, but I'm also kind of fed up with problems.  I understand that I'm not paying for business service - but I also feel like network issues should be the exception, and not the norm.  It feels like hardly a week goes by without something...  What do others think?  How much should I be willing to put up with?

Amazon EBS Volume Failure Notice

 Ever wonder what happens when Amazon loses your data?  I got this in email the other day:

Dear Jeffrey C Rizzo,

Your volume experienced a failure due to multiple failures of the underlying hardware components and we were unable to recover it.
Although EBS volumes are designed for reliability, backed by multiple physical drives, we are still exposed to durability risks caused by concurrent hardware failures of multiple components, before our systems are able to restore the redundancy. We publish our durability expectations on the EBS detail page here (http://aws.amazon.com/ebs).


Sincerely,
EBS Support

Fortunately, there was nothing of importance on that volume, and I had a snapshot which was unaffected by the failure but it's a reminder that just because something is in "the cloud" doesn't mean that it's necessarily safe.

On their EBS detail page, Amazon says that a single volume with less than 20GB of data changed since the last snapshot should expect an annual failure rate of between 0.1% and 0.5% - or between 1 and 5 out of every 1000 volumes should fail annually, where failure is defined as complete loss of the volume.  This is better than commodity hard drive failure rates, but still in the range where they can and do happen to ordinary users.

A simple way to improve your failure rate is to snapshot often;  EBS snapshots are stored on Amazon's S3 service, which guarantees 99.999999999% durability and 99.99% availability.  If you get a volume failure, you have only to roll back to the most recent snapshot, and you've only lost the data which has changed in the interim.   A more robust and high-availability solution would be to mirror writes to volumes in different availability zones, but that's another project for another day.

Keep your data safe!

NetBSD on Amazon EC2

As some of you know, I've been maintaining Amazon EC2 AMIs running NetBSD for a little while now, and after a few requests, I'm happy to say I've finally cleaned them up to a point where I'm comfortable sharing them with others.

The original scripts these are based on were written by Jean-Yves Migeon, another NetBSD developer.  I've cleaned them up and modified them quite a bit.

To get started rolling your own NetBSD AMIs, you'll need an Amazon EC2 account, and a NetBSD system with the misc/ec2-api-tools package installed.  (Note that as of this writing, you may need to install the required openjdk7 package from source, rather than using a binary package from ftp.netbsd.org;  hopefully this will be fixed soon)  Once the package is installed, you should follow the Amazon documentation on Getting Started with the Command Line Tools for more infomation on the commands that the ec2-api-tools package provides.

The actual scripts can be downloaded here, or you can check them out with CVS from anoncvs.netbsd.org, in the othersrc module, in share/examples/ec2.  Be sure to read the README!