Assume:

There’s 0.134 cu ft/gallon. Thus, 5 gallon is 0.67 cu ft.

2.2 “volumes” means there is 2.2*0.67 = 1.47 cu ft [...]]]> I was wondering how long the CO2 tank should last when used for both carbonating and serving the beer.  The carbonation consumption is not insignificant.

Assume:

• 1 keg is 5 gallons
• Carbonating to 2.2 volumes
• Dispensing at 40°F
• Dispensing at 12 PSI

There’s 0.134 cu ft/gallon. Thus, 5 gallon is 0.67 cu ft.

2.2 “volumes” means there is 2.2*0.67 = 1.47 cu ft of CO2 that is dissolved in the beer.

12 PSI is the same as 1.82 atmospheres.  Thus after dispensing all the beer, the empty keg has 1.22 cu ft of CO2 in it.

CO2 has a specific volume of ~8.2 cu ft/lb at 1.0 atmosphere and 40°F.  Thus, 2.69 cu ft is 0.33 lbs of C02 used per 5-gallon keg.

So, assuming no leaks (yeah right!), the 15 lb bottle should be good for about 45 kegs.

The Atmel ATMega328 microcontroller has 6 analog inputs with [...]]]> My first Arduino project was to build a battery capacity tester. I’ve got a box of rechargeable AA batteries, and it seams they’ve been less and less effective. Since most applications require 4 batteries, invariably one problem battery makes the rest of them look bad.

The Atmel ATMega328 microcontroller has 6 analog inputs with 10-bit A-to-D converters and a external AREF that allows you to define what voltage 0x3FF represents. In other words, it’ll give you ~1.4mV precision measuring 0-1.5V when given a 1.5V analog reference. Plenty accurate for a battery capacity measurement.

The principle is fairly simple. Apply a known load to a battery, record the voltage periodically while the battery discharges, stop recording at some point, and integrate to arrive at the area under the curve in order to derive the amp-hours delivered from the battery.

Enough theory, let’s see how it works. The UI starts with a helpful message:

Insert Battery

NIKON D70, ISO 500, ƒ/2.0, 1/20sec, 50mm focal L.

While the battery discharges, the UI prints the voltage, real-time capacity measured thus far, and the duration that the measurement has been taking place.

Battery In

NIKON D70, ISO 500, ƒ/2.0, 1/25sec, 50mm focal L.

When the cut-off voltage of 0.9V has been reached, the “usable” capacity is saved at the top. The real-time data continues so the capacity below 0.9V is measured. For the NiMH batteries I’ve tested, the capacity below 0.9V is minimal (~100mAH).

After the cut-off is reached, an LED starts blinking to attract attention that the test is effectively over.

Done

NIKON D70, ISO 500, ƒ/2.0, 1/20sec, 50mm focal L.

Here’s the code (click to download as text rather than the questionable HTML translated version pasted below):

/*  Battery Characterization Tool

     11/7/2009 John Terry

     Compiled on Aurdino 0017 in 4930 bytes.

 This uses the analog in to measure the voltage of a battery under a known load and
 integrates the area under the curve to arrive at the useful capacity of the
 batterin in mAH.
*/

#include <LiquidCrystal.h>

// Set some constants -- these will need to be adjusted for your setup
//
// Connect a ~10K Ω (Rr) resistor from 3.3V supply pin to the AREF pin,
//   creating a voltage divder with the internal 32KΩ resistor on AREF.
//      aRefVoltage = supply_voltage * 32K / Rr
//   Alternatively, measure the actual AREF voltage applied with a good DMM:
//  my measured aRefVoltage = 2.62;
const float     aRefVoltage = 2.62;

// Connect a load resistor (Rl) to the battery. ~2.2 Ω restistor gives ~500mA drain which
//   is about right for a battery rated at 2500mAH.  Note, this should be a >=1W resistor!
//   Dont trust your DMM to meausre such a low resistance accurately. I measured the current
//   and back-calculated the resistance. Best just to trust rated resistance.
//   my  resistance = 2.18;
//
// The integrator works by accumulating the sampled voltage values from the start until
//   hitting a pre-determined low-voltage threshold. Since they are sampled at a
//   known period, the number of samples taken cancels out and the accumulation of all samples
//   simply needs to be scalled by a factor
//
//   Let's make some definitions to show the derivation of how this is so:
//   I = current
//   V = load voltage
//   Rl = load resistance
//   samples = number of voltage samples made
//   sensor = value read out of analog A->D
//   rate = number of samples taken per second
//
//                                     ave(V)
//   capacity = ∫I ~= ave(I) * time = -------- * time
//                                       Rl
//
//   Where:
//                ∑(V)     ∑(sensor) * aRefVoltage/1024
//     ave(V) = ------- = ---------------------------------
//              samples              samples
//
//      time  =  samples/rate
//
//   Thus:
//               ∑(sensor) * aRefVoltage     samples
//   capacity = ------------------------- * ---------
//                samples * 1024 * Rl         rate
//
//               ∑(sensor) * aRefVoltage
//   capacity = ------------------------- = ∑(sensor) * quanta
//                  1024 * Rl * rate
//
//           quanta = aRefVoltage/(1024 * Rl * rate ) * 1000/3600   // scaled for mA Hours
const double quanta = 0.00030179; // 2.62/1024/2.355/3.6

// Define low voltage threshold where any remaining capacity is "unusable"
//        lowThreshold = 0.9V * 1024/aRefVoltage
const int lowThreshold = 354;

int sensorPin          = 0;    // select the analog input pin for the voltage measurement
int ledPin             = 13;   // select the pin for the LED
int fetGatePin         = 8;    // select the pin for the LED
int sensorValue        = 0;    // unscaled sensor output
float voltage          = 0;    // measured voltage
double mAH             = 0;    // Calculated current
long accumulator       = 0;    // sum of all unscalled sensor values sampled
int epoch              = 0;    // seconds since battery was inserted
int lowVolts           = 0;    // debounce the low voltage threshold
boolean done           = false;// Voltage has dropped below threshold
boolean batteryIn      = false;// Battery present

// initialize the the LCD library with the numbers of the interface pins
//  LCD Pins  --  RS, EN, D4, D5, D6, D7
LiquidCrystal lcd(12, 11,  5,  4,  3,  2);

void setup() {
  // declare the ledPin and fetGatePin as an OUTPUT:
  pinMode(ledPin,     OUTPUT);
  pinMode(fetGatePin, OUTPUT);  

  // set analog reference to external
  analogReference(EXTERNAL);

  // set up the LCD's number of rows and columns:
  lcd.begin(16, 2);

  // Print a helpful start-up message to the LCD.
  lcd.print("Insert battery");

  // DEBUG initialize serial communications at 9600 bps:
  // Serial.begin(9600);
}

void loop() {

  sensorValue = analogRead(sensorPin);    

  if (!batteryIn && (sensorValue > 100)) {
    // Initialize upon the insertion of a "fresh" battery
    batteryIn   = true;
    done        = false;
    epoch       = 0;
    accumulator = 0;
    lowVolts    = 0;
    digitalWrite(ledPin, LOW);
    digitalWrite(fetGatePin, HIGH);
    // clear out when LCD when starting over
    lcd.setCursor(0, 0);
    lcd.print("vlts  mAH  Time ");
    lcd.setCursor(0, 1);
    lcd.print("                ");
  }
  else if (batteryIn && done && (sensorValue <= 20)) {
    // consider the battery removed only after finishing the last measurement to
    // debounce a glitchy concact
    batteryIn=false;
  }
  else if (batteryIn) {
    // Running state during discharge state

    voltage = sensorValue*aRefVoltage/1024.0;

    // print voltage
    lcd.setCursor(0, 1);
    lcd.print(voltage);

    if (!done) {
      accumulator += sensorValue;
      // print mAH
      mAH = accumulator*quanta;
      if      (mAH <   10) { lcd.setCursor(8, 1); }  // adjust to make it perdy
      else if (mAH <  100) { lcd.setCursor(7, 1); }
      else if (mAH < 1000) { lcd.setCursor(6, 1); }
      else                 { lcd.setCursor(5, 1); }
      lcd.print(int(mAH));

    }

    // print current time
    lcd.setCursor(11, 1);
    lcd.print(epoch/60.0);
    lcd.setCursor(15, 1);
    lcd.print("m");

    if (!done) {

      // lowVolts requires 10 seconds in the last 20 before being done
      if (sensorValue < lowThreshold) { lowVolts++;}
      else if (lowVolts > 0)          { lowVolts--;}  

      // If it's below threshold for 10 of 20 samples, bail out
      if (lowVolts > 10) {
        done=true;
        digitalWrite(fetGatePin, LOW);
        lcd.setCursor(0, 0);
        lcd.print("    mAH in     ");
        lcd.setCursor(1, 0);
        lcd.print(int(mAH));

        // put the time, in minutes in the upper right
        lcd.setCursor(11, 0);
        lcd.print(epoch/60.0);
        lcd.setCursor(15, 0);
        lcd.print("m");

        // Clear out the bottom line
        lcd.setCursor(4, 1);
        lcd.print("v      ");
      }
    }

    epoch++;
  } // batteryIn -- main routine

  if (done) {
    // When done, flash the LED to get attention
    digitalWrite(ledPin, HIGH);
    delay(500);
    digitalWrite(ledPin, LOW);
    delay(499);
  } else {
    // Since the processing takes some time prior to the delay, we'll assume 1mS
    // This could stand to be improved with an interrupt routine that is kicked off
    // before all the processing starts for each loop
    delay(999);
  }

/* DEBUG

  Serial.print("\nsensor = " );
  Serial.print(sensorValue);
  Serial.print("\t lowvolrs = " );
  Serial.print(lowVolts);
*/

}

Compiles into 4930 bytes.

Schematics, excluding the LCD display (pin-out is listed in the code).

A couple of days ago, a tiny little package arrived from Sparkfun Electronics with my first Arduino kit. Valerie’s response upon finding said package in the mail box, “well, so much for seeing my husband for the rest of the week”. In all fairness, I waited [...]]]> Success has been had … finally!

A couple of days ago, a tiny little package arrived from Sparkfun Electronics with my first Arduino kit. Valerie’s response upon finding said package in the mail box, “well, so much for seeing my husband for the rest of the week”. In all fairness, I waited till the second day (night, really) to get sucked in. I’ll be back tomorrow…

Last night, I just plugged it into the USB port and loaded a pre-canned example that made the LED blink. Did some experimenting with modulating in and out with a few for loops just to refresh my C code.

Tonight was all about getting the LCD wired in. Soldered a header onto it to mash into the bread board to keep the wiring flexible.

Opened up the LiquidCrystal tutorial and wired it all up and measured the resistance between power and ground to make sure I didn’t have any shorts. Finally plugged it in to the USB spigot and dumped the “hello, world” example program, and … nothing.

Hmmph. Take some measurements — voltages are good. Contrast voltage bias is about half-way, that ought to be close. Let’s try a little higher: nope. Lower? Nope.

OK, rip it all out and move to a different section of the breadboard. Still nothing. The LCD doesn’t so much as blink. Must be dead.

In fit of desperation, I grab pair of random resistors and jumper them across my voltage divider that’s biasing the contrast, first moving contrast closer to VDD, then moving it much closer to VSS and — presto — it was running all along.

It’s alive!

NIKON D70, ISO 500, ƒ/1.8, 1/30sec, 50mm focal L.

For the record, this particular 5-volt LCD contrast likes to biased at about 1.3 volts. 2.5 volts get’s you nothing.

My first real “project” is to build a rechargeable battery characterization tool. More on that later…

First time taking the new bike up highway 9. Must have had half a dozen riders signal to warn that the police were up ahead; this part of the ride was none too spirited.

152 from Watsonville [...]]]> Got a quick ride in today — 112 miles. Quickly coming up on the 1K mile mark on the odometer.

First time taking the new bike up highway 9. Must have had half a dozen riders signal to warn that the police were up ahead; this part of the ride was none too spirited.

152 from Watsonville over Hecker pass was loads of fun, even if the road was a bit rough in spots. After the left turn northward toward, Uvas road was also very interesting. I truly enjoy the ride up these “hidden” valley roads that most folks don’t realize exist so close to their suburbs.

Got tired of hand-editing the GPX files to merge the routes. Started to write a sed script to do it for me, but, just had all kinds of trouble trying to get the version of sed that ships with Mac OS X to insert a newline — which a quick search of ‘sed newline’ reveals that perhaps sed doesn’t much like to do this any case. So, scratched some rust off my once budding Python and decided to learn how to do a regular expression with it.

And for the first time with Python, it underwhelmed me. The simplicity of a regex is burdened by the fact that (I only now realized) Python doesn’t have any in-built regex abilities; I just assumed it did, and it would work like Perl. It most certainly does not:

#! /usr/bin/python

import sys
import re

if len(sys.argv) < 3:
  print "usage:"
  print "  gpx.py <gpx input file> <output file name>"
  sys.exit(1)

f_read  = open(sys.argv[1], 'r')
f_write = open(sys.argv[2], 'w')

for line in f_read:
  p = re.compile('<wpt.*/wpt>')
  line = p.sub('',line)

  p = re.compile('<trk')
  line = p.sub('\n<trk',line)

  p = re.compile('</trkseg')
  line = p.sub('\n</trkseg',line)

  p = re.compile('<time>.*</time>')
  line = p.sub('',line)

  p = re.compile('<trk.*37\.3[0,1,2].*-121.8[8,9].*/trkpt>\n')
  [line,count] = p.subn('',line)
  print "Removed", count," points from the track"

  f_write.write(line)

f_read.close()
f_write.close()
sys.exit(0)

Which does the following:

1. Removes all waypoints from the file.
2. Adds newlines in front of some key xml tags which makes it trivial to merge multiple tracks together using a text editor
3. Removes the timestamp from each track data point
4. Removes any data point that are near my house

All simple stuff, but tedious to do on the XML source file that has no line feeds as generated from the Garmin Nuvi GPS.

With the munged GPX file, this is uploaded to the very handy GPSVisualizer.com site that dumps the track into the map you see above.

It came with a 3-month teaser introduction to the Clear Channel FM traffic service which allows the GPS to “intelligently” determine how bad traffic is and reroute [...]]]> Recently purchased a Garmin Nuvi 760 GPS for the car/motorcycle. All in all, it’s lived up to expectations and does the advertised job. But, it’s not without quirks and annoyances.

It came with a 3-month teaser introduction to the Clear Channel FM traffic service which allows the GPS to “intelligently” determine how bad traffic is and reroute to find the fastest path to your destination. Sounds all well and good, until I actual found some traffic this weekend.

There was a section of “slow-n-go” for a few miles along I880 north while making my way from San Jose to Albany. Normally, 880 would be the preferred route all the way. But, at Hayward, it commanded the following departure:

The blue path is our track. Note the departure from the freeway, only to return right back onto 880! Yes, the GPS’s grand idea to route around the traffic was poach the off-ramp and then merge right back into traffic!

And suddenly, I was THAT person that so infuriates me. The one that zooms up the right lane on I5 and cuts you off just before rear-ending the semi-truck that everyone else in the left lane is patiently waiting in line to pass. The one that tail gates you for a mile, changes lanes 3 different times attempting to weave around you only to end-up back on your ass again, because, yes, in fact, you are actually going faster than everyone else. The one that uses the on/off ramps to pass people — it’s just not polite, and Garmin’s programmers think it’s a good idea!

As if that wasn’t bad enough, later in the trip, it sent me off the road again to a stop-light intersection in order to route around traffic that didn’t exist.  Yes, it was there an hour prior when we started the trip, but had since flushed out while en route. We were very near our destination so I assumed it was time to exit the freeway — but then it wanted us right back on it again, only to exit for real a mile down the road.  It clearly showed there was no traffic in our vicinity, yet, it wasn’t smart enough to note the change in conditions and update the route.

So, lesson learned — if you don’t look ahead at the next 3 turns when it wants you to depart the freeway, good chance it’s doing you no favors.

Lesson 1) backups are only as good as your backup strategy.

Lesson 2) your backup strategy is useless if its never been tested to recover from bare metal.

Lesson 3) your ill conceived, unproven backup strategy will bite you. And it will not be for a reason that [...]]]> I’d really like the last 18 hours of my life back.

Lesson 1) backups are only as good as your backup strategy.

Lesson 2) your backup strategy is useless if its never been tested to recover from bare metal.

Lesson 3) your ill conceived, unproven backup strategy will bite you. And it will not be for a reason that was beyond your control, like say, drive heads screeching on platters. No, it will bite you because of your own stupidity and failure to fully RTFM.  Beware: your ill conceived backup strategy is cunning!  It is most likely to bite you while doing something that might actually result in a more robust backup strategy.

While I’m not entire sure if this was my undoing, I’m unable to grok how doing ‘grub-install‘ on a disk that is not the first BIOS disk does bad things to the disk that *is* the first BIOS disk.  Doesn’t seam to matter that you told it to go work on /dev/sdX, where X != “first BIOS disk”. I’d like to compare notes if your mileage differs on this point.

No matter — something happened that really upset the boot-ability of the system. Of course, anaconda was useless in trying to “rescue” me. No, no! That would have been too simple.

OK, bed time.

Some of the key things that I always forget about my setup that haunt me later:

For example, suppose we have direcotry [...]]]> Never realized how easy it is to duplicate a directory tree from one machine to another through the network without building an intermediate tarball and finding room for it and the original files all at the same time. Simply pipe the tar command through ssh and untar it on the fly.

For example, suppose we have direcotry “pictures” on SRC_HOST machine and I want to replicate it over to DST_HOST, do this from the SRC_HOST machine:

tar cvf – pictures | ssh user@DST_HOST “cat | tar xf -”

Or, if you just wanted to create a compressed archive of “pictures” on DST_HOST:

tar czvf – pictures | ssh user@DST_HOST “cat > pictures.tar.gz”

I’m ashamed to admit how many times I’ve jumped through hoops to find the free space on both machines due to making a compressed tarball, copying it over, unpacking it, then deleting the tarball.

Update: While the above is functional, it’s all rather academic. Not but a few days after writing this, I stumbled across ‘rsync‘. Yeaeh, this is a little easier:

rsync -avz user@DST_HOST:pictures pictures

And how to do it on a Mac and get all the resource forks to transfer to a non-HFS file system requires extra care and a better version of rsync than Apple delivers.

Although, I’ve noticed that the VB7001G board I’m using has inconsistent results on the calculator — 16.23 watts idle versus 13.92 in “network mode”. Take it for what it’s worth.

While [...]]]> The Via Epia mini-ITX boards are some of the lowest power around. Epiacenter.com has a power simulator that’s good for comparing the differences in boards.

Although, I’ve noticed that the VB7001G board I’m using has inconsistent results on the calculator — 16.23 watts idle versus 13.92 in “network mode”. Take it for what it’s worth.

While I’m at it — first booted the Via VB7001G this evening. The sole purpose of this is for use as my main mail/web server as well as the mythtv backend. With a good power supply and a laptop HD for the primary (non-video) storage, I hope to have a box that idles at <30 watts. Then the power hog P4 system connected to the TV would only be booted as needed.

Using an el’cheepo power supply and an old Maxtor HDD pulled from the shelf, it’s currently idling along at 46 W. Not a bad start. I think there’s easily enough room for improvement to achieve the goal. Silent PC Review got their EN12000 board down to 17W at idle — mind you, they had a 5 W head start on me using a low-power variant of the C7 CPU  (not to mention 20% slower, and ~300% more expensive).

Here’s a good review of popular 2.5″ notebook hard drives.

Update: With a 90W Pico Power supply + the tuner card and 1.25 TB of disk on-line (2 disks, one 250MB laptop, and one 3.5″ 1.0 TB Western Digital Caviar Green Power drives), the box is idling at a grand total of 25 watts (AC wall power)! Mission Accomplished.

There’s still some room to tweak that down a bit. The 1TB drive does not need to be spun-up full time. That should drop the idle power down a few extra watts.