Wednesday, November 26, 2008

A Flashlight Story

Back in May of this year, in preparation for a campout, I bought a nice looking LED headband flashlight at Walmart. It's a Garrity light and it ran me about $13. I used it on the campout and fell in love. It was incredibly light-weight and I soon forgot it was on my head, yet it was plenty bright (click these images for larger versions).

After the campout it sat in a drawer for a few days before I had occasion to use it again. When I pulled it out of said drawer and pushed the button to turn it on, nothing happened. Saddened, I figured it must have been bumped and turned on while in the drawer or maybe one of my boys had found it and left it on. I bought new batteries and used it while performing some bicycle maintenance in my dimly lit garage late one night. I put it away high on a shelf away from any bumps or curious hands afterwords. A few days later, the batteries were dead again. I've gotta return this defective thing to Walmart, I thought to myself, but never found the time. Here it is 6 months later, I have not package nor receipt, and I'm afraid I still don't have the desire to venture back into Walmart only to be rejected for my $13 return.

Instead, I decided that there was a remote chance I could fix it myself. Even with my basic EE knowledge and caveman electrical tools (Radio Shack multi-meter) I should be able to figure this out, I figured. It's just a flashlight. The obvious thing would be a short, right? I extracted the light from the headband:

And opened up the back.

Probing the battery connections, I discovered that with the flashlight sitting off there was 77.5 kOhms of resistance between the two pads, not a completely open circuit, right? That's gotta be it. I inserted some new batteries with the multimeter in series and there was no current draw. Hmm. Well, it takes two CR2032 batteries for a voltage of 6V. I don't know what to use for their internal resistance, but even assuming none, V/R give us:

6V / 77500 Ohms = 77.4 microamps.

My meter doesn't exactly go into the microamp range so maybe... Another thing to consider is this isn't a mechanical switch so maybe that's not a straight up resistance I was measuring anyway. I found a datasheet online just for furn and read that these little batteries have a 220 mAh capacity. I believe the calculation for two batteries supplying 77.4 microamps would be (Note the correction: two batteries in series does not double the current. Thanks, Nols):

(.220 * 2 Ah) / .0000774 amps = 5684.75 2842.38 hours

So that could be draining the batteries while the light is off, but it would take more than a couple days. Maybe that's not actually the problem. For fun I measured the current used when the light was on. The numbers weren't as memorable and I wasn't thinking blog entry at that point, so I didn't write them down. I think it was about 60 milliamps on the low setting and 100 milliamps on the high setting. Nothing outrageous.

I decided to take it apart. It was a tight little package with no screws, and no good place to pry. After a few minute of frustration I hit it with a blunt object and out popped this black plastic piece:

Then I pried out the circuit board.

And at this point I'm kind of at the end of my EE rope. I don't see any obvious shorts sucking current out of my batteries (and my multimeter didn't find any either). I see some transistors, resistors, and caps that are likely the constant current driver circuit for the LEDs (maybe similar to this one, even), and then a blob of epoxy covering something else mysterious but probably benign, and that's about it. No fix, but at least I have some really bright LEDs to play with.

If you have any suggestions on how to debug or fix my battery sucking flashlight feel free to chime in down in the comments. If you are from Garrity, I will blog about how amazing it was that you found my blog and how nice you were to send me a new flashlight. :-)

Sunday, November 9, 2008

Carefully Upgrading to Django 1.0

I’m a little behind, but I finally upgraded my family website to Django 1.0. First of all, I wanted to keep the main site running my older version of django from subversion while having 1.0 installed and being used by the development version. First I added the old install to my apache configuration’s PythonPath. Here’s the diff:

-   PythonPath "['/home/bryan/web/murdockfamily'] + sys.path"
+   PythonPath "['/home/bryan/web/django_src', '/home/bryan/web/murdockfamily'] + sys.path"

Then I deleted the symlinks to that django install from any site-packages locations:

sudo rm /usr/lib/python2.4/site-packages/django /usr/lib/python2.5/site-packages/django /usr/local/lib/python2.5/site-packages/django

Then reloaded apache:

sudo /etc/init.d/apache2 reload

And it seemed to still work.

Next I untarred Django 1.0, and installed it:

tar -zxvf /home/bryan/downloads/Django-1.0.tar.gz
cd Django-1.0
python setup.py build
sudo python setup.py install

I restarted apache again at this point to make sure the production site was still running. Thankfully, it was.

Then I started up the development server in the development branch of the family website and saw it fail while trying to use Django 1.0. Sweet. Just for sanity’s sake I did this to make sure it still worked with the old version:

$ PYTHONPATH=/home/bryan/web/django_src ./manage.py runserver 10.0.0.10:8080
Validating models...
0 errors found

And the world is still sane. The next step, of course, will be to fix those errors I got when starting the development server with Django 1.0. I’ll let you know how that goes.

Monday, November 3, 2008

Convert a PostgreSQL Database from LATIN1 to UTF8

I had a problem with my family django-powered website. I have an aggregator for all our friends blogs, very similar to the Django aggregator, except that mine hasn’t been aggregating. After some serious investigation, I found that psycopg was barfing error messages because the feeds that were being stuffed into my postgresql database contained utf-8 characters that it couldn’t figure out how to convert into latin1 characters. I hadn’t paid any attention to this, but apparently my blog database was using latin1. Lame. I decided it was time to learn how to convert it to utf-8.

First, I did a pg_dumpall in order to get a look at things (this happens automatically every night, actually):

/usr/bin/pg_dumpall -U <special user> > /home/bryan/backups/all.dbs.out

Sure enough, my database was created like so:

CREATE DATABASE bryan WITH TEMPLATE = template0 OWNER = bryan ENCODING = 'LATIN1';

So, I dumped just that database:

pg_dump -U <special user> bryan > bryan.dbs.out

Then I converted it to utf-8 with iconv:

iconv --from-code latin1 --to-code utf-8 bryan.dbs.out > bryan.dbs.out.utf8

Then I dropped the lame old latin1 database, after shutting down apache2:

sudo /etc/init.d/apache2 stop
dropdb bryan

Then I created the shiny new utf-8 database, using the command from the pg_dumpall output, with a slight change:

psql -U <special user> bryan < "CREATE DATABASE bryan WITH TEMPLATE = template0 OWNER = bryan ENCODING = 'UTF8';"

Then I restored the converted backup:

psql -U <special user> bryan < bryan.dbs.out.utf8

After starting up apache2 again:

sudo /etc/init.d/apache2 start

The website looked just like it did before. Phew!

Next I ran my update_feeds.py script and my aggregator aggregated, which was really awesome to see. I have some serious reading to catch up on now.

References:

  1. http://archives.postgresql.org/pgsql-general/2006-03/msg01259.php
  2. http://www.postgresql.org/docs/8.2/interactive/backup-dump.html
  3. http://www.postgresql.org/docs/8.2/interactive/manage-ag-dropdb.html
  4. http://www.postgresql.org/docs/8.2/interactive/manage-ag-createdb.html