Today, the panels of bare circuit boards, the paste stencil, and the last parts I need (the Venus GPS modules) to hand assemble first-article prototypes of TeleMetrum v0.2 all arrived!

The parts for the first three prototypes are staged and ready to load, so my next step is to go use my CNC mill to rip up one of the panels into individual boards, then make up a fixture for the stencil. Meanwhile, the solder paste is out of the shop fridge warming up...

For my friends in Colorado, this means I will not try to attend the NCR annual meeting this weekend. It's about a 6 hour round-trip drive from my house to Ault, and getting boards loaded and tested before I leave for New Zealand where Keith and I are scheduled to give a talk at LCA about our work takes priority!

Some quotes are in for professional SMT assembly of TeleMetrum v0.2, and I've had to reset my expectations. The shop I thought would be my first choice came in with a quote much higher than I expected. Another shop we've heard good things about gave us a much more reasonable quote, but can't get any made before LCA. So...

This morning, I ordered some bare circuit boards and a paste stencil from the places I used quite successfully for v0.1. With any luck, they'll be in my hands in time to load a few boards before leaving for LCA.

If all goes well, we'll put a set out for professional fab sometime later.

I just sent a data package representing TeleMetrum version 0.2 out for an assembly quote. Hope to have first article boards in hand before heading to linux.conf.au 2010 where Keith and I are scheduled to give a talk about the project.

Keith and I have been pretty quiet about TeleMetrum for a while... but that doesn't mean we've been idle!

In recent weeks, I've built up several more flight units and two more ground station boards, as noted in my production log. We're both trusting rockets solely to our boards and Keith's firmware at this point. In fact, we've accumulated a significant number of succesful flights, including a cool drag-race between 4" airframes at NCR Oktoberfest where we both put brand-new, nearly identical rockets fully at risk flying only TeleMetrum boards, and a flight by Keith the same weekend on a full-K Loki K350W moon-burner in which he set a new personal altitude record! I've also flown a board with 100-g accelerometer installed successfully in a flight that peaked at 52.8 g!

We're now hard at work on a "next version" of the hardware, incorporating everything we've learned so far. There are a number of significant changes planned:

• Fully integrated, on-board GPS receiver and patch antenna, with support for off-board amplified antennas when airframe geometry or materials demand it.

• A change in the design of the circuit for firing e-matches to ignite ejection charges that will improve mechanical reliability, plus explicit support for using a separate pyro battery if desired.

• Inclusion of a "companion board interface" that we envision using for a pyro channel expansion board to support staging and air starts, among other things.

• Dramatic increase in the capacity of the on-board data logging memory.

• Changes in connector series to eliminate our dependency on expensive crimping tools for making cables.

To make all this fit, I'm stretching the board an extra 1/4 inch to a total outline of 1 by 2.75 inches. We're also moving all the connectors, the GPS patch antenna, and the beeper to the "back side" of the PC board. This is a win on several levels... it will allow us to have silk-screen labels for the connectors, will help protect the baro sensor from sunlight and the various surface mount parts from physical damage during rocket prep, and opens up more board surface area for component placement and routing on the "top side" of the board. In practice, this means that boards will be mounted on standoffs with all the active components facing "down" and the connectors facing "up."

Before we'll be ready to build some of these, we need to get in some more flights to test the various changes we're making. In particular, the change in ejection charge circuit, and the GPS receiver chip and antenna choices we're now favoring. Unfortunately, Keith and I are now both into the time of year where launch opportunities come less frequently, even before we consider the weather.

Meanwhile, Keith's firmware and ground station software are now doing nearly everything we've envisioned wanting from this project. It seems entirely likely that he'll be ready to declare "version 1.0" soon after we obtain and verify the functionality of our next version of the hardware...

In the meantime, our friends at Woot have posted a really funny video combining material from a couple launches this summer of my 10-inch Goblin, on one of which we flew some of their screaming flying monkey dolls... Enjoy!

In preparation for several upcoming high power rocket launches, I've spent some time over the last two weeks building up several more TeleMetrum boards. Five new ones, in fact, serial numbers 7 through 11. The first four are fully-loaded normal boards, the last one has a 100 gee accelerometer installed instead of the normal 50 gee part.

While I haven't yet tested 100% of the functionality on all five, I'm definitely getting better at loading and reflow soldering these boards. I found exactly one soldering defect, a bridge between two pins on the cc1111 noticed during initial visual inspection which was easily removed, and all five flashed and passed initial tests on the first try!

I also retrieved one of the OLPC XO machines from my son and loaded it up with Debian for the XO, then upgraded it to unstable so that I can use it as a ground station for receiving telemetry. Having a small machine with long battery life and a screen that is readable in direct sunlight should be a huge win!

Now that I care about having working AltOS bits on more than one machine, I took some time today and created a Debian package. In the process, as I stumbled over various issues, Keith was quick to jump in and help... as were fellow Debian developers on IRC. We now have a "lintian clean" package that's easily maintainable from our shared git repository, and yes, we even have man pages for all the utilities!

A special note for folks near Colorado. Weather permitting, this Sunday morning the 23rd of August, I'm planning to "drag race" my big Goblin airframe against Jason Chamberlin's similarly-sized Polecat Fat Man on long-burning Aerotech M650W motors at Chili Blaster. Even for those of us who fly high power model rockets every chance we get, a drag-race between 10-inch airframes on long-burning M motors is a special event. If you've never seen rockets like this fly, and/or would like to see a TeleMetrum board in action, this would be a great time to come hang out with us!

I just uploaded makedev version 2.3.1-89, the most significant change of which is a move from Debian package priority 'required' to priority 'extra'. I've also filed a suitable bug against ftp.debian.org asking the ftp-masters to do the required bit on their end.

This change was largely motivated by bug #522048, which pointed out that in an era of reliable udev, most Linux users should no longer care about the presence of MAKEDEV. The Debian packaging of the Hurd apparently uses it's own MAKEDEV script, and I understand this change is a non-issue for the BSD porters in Debian as well. Since the makedev package is not marked 'essential', and the package documentation and Debian policy encourage conditional use of the MAKEDEV script, there should be no package changes required as a result of this demotion in priority.

If anyone experiences any undue pain as a result of this change, please let me know.

As already reported, while at Debconf9 this week, I succumbed to peer pressure, and have generated a new 4096-bit RSA key. Doing this was made substantially more pleasant (and certainly a bit more amusing!) by the fact that I was loaned a prototype of the new Simtec Entropy Key to play with.

Can't wait until they're in production and available for sale...

Basically, it's "just" a very high quality hardware random number generator that sits on a USB interface. Associated with this is a small MIT-licensed daemon that gets loaded along with some udev configuration (all in a Debian package in my case), such that any time you plug it in, your system available entropy goes way up and stays up until you unplug it. It really is that easy! My new 4096-bit GPG key generated without perceptable delay, while the one my daughter made at the same time on her similar notebook required lots of mouse wiggling and I/O traffic generation to accumulate enough bits. A dramatic difference, to say the least!

Anything that needs lots of random bits for generating things like session keys will clearly benefit from a device like this. Some systems have other hardware sources of random numbers, but I was impressed by the attention to detail the guys have put into this little widget, and the work they've done to make it integrate so well with Debian.

Very cool.

In recent months, a number of arguments have been made in favor of abandoning use of SHA-1, which I won't rehash here (yes, pun intended!). The practical consequence that matters to me is that many Debian developers are in the process of transitioning to new, stronger gpg keys, and in the process also moving to generate more strongly coded key signatures.

While at Debconf9 this week, I succumbed to peer pressure, and have generated a new 4096-bit RSA key 0xC095D941 which I will henceforth use as my primary key. I note in passing that my previous key 0xF2CF01A8 is just over 10 years old, and thanks largely to my intense business travel in recent years and willingness to engage in key signings everywhere I go, had risen to be one of the world's best connected keys and thus very near the center of the "strong set". Since I have no evidence that this key has been compromised, I have no intention to immediately revoke it, and in fact will continue to sign keys with both my old and new keys for at least a while until my new key establishes itself. In the process of creating and setting up my new key, I stumbled over some issues that I think others should be aware of.

To create a strong key, there are several reasonable recipes, and following one is a good idea. I started with these notes from Ana's blog. Make sure to read the followup comments and follow the suggestion to add the algorithm preferences to the gpg.conf file before creating your new key, so that you don't have to update the preferences manually afterwards. I also learned a lot by reading about using multiple subkeys here... while the document says it's out of date, most of the important bits are still completely accurate. With these two documents, and a little man page review, creating my shiny new key was pretty easy.

For quite some time, I've been exclusively using caff (which stands for "CA - fire and forget") from the PGP Tools repository that ends up as the signing-party package in Debian to do all my key signing. Unfortunately it has a bug or feature relating to the use of a distinct home for gpg within the ~/.caff directory such that new options added to my normal ~/.gnupg/gpg.conf file were not noticed by caff! So even though I moved to a new strong key, I was continuing to generate weak SHA-1 signatures with the new key! The fix for this turned out to be simple enough (after burning a half-hour or so figuring out what the problem was!), I just created a symbolic link so that ~/.caff/gnupghome/gpg.conf points to my canonical gpg.conf file, and all was well. Or, almost all...

It bothered me that I had generated weak signatures with my new strong key, so I decided to re-sign the keys I had already signed with my new key so that all the signatures issued with my new strong key are strong signatures. To do this, I used gpg's --edit-key option with gpg warped to point to the caff home to 'delsig' the signatures I'd made to these keys, then used caff with the '--no-download' option to re-sign the keys and re-issue the associated emails. Trolling ~/.caff/keys helped me discover which keys were in the affected set, then I studied the command lines caff was feeding to gpg to see what options I'd need for gpg. Here's an example of the commands required to fix key id 0x2DA8B985:

gpg --homedir=/home/bdale/.caff/gnupghome --secret-keyring /home/bdale/.gnupg/secring.gpg --no-auto-check-trustdb --trust-model=always --edit-key 2DA8B985
caff --no-download 2DA8B985

I haven't fixed all the signatures made this week yet, but I will. Those of you who think I'm just re-sending the same signatures, take note of what's really going on! I understand that adding the new signatures works and you'll end up with my stronger signatures replacing the weak ones.

Hope this helps someone else avoid the frustration I felt while chasing these details down last night late!

I managed to break the LCD on my HP r717 digital camera a while back, but couldn't find anything that excited me as a replacement, so have been doing without and borrowing my son's camera from time to time. That changed recently... my new camera is a Casio High Speed EXILIM model EX-FC100BK.

I've never been able to get the timing right to take photos of our rockets leaving the launch rails. I manage to get passable videos from time to time, and a lot of pictures of smoke trails... but WOW, the ability to take a burst of high-resolution still photos at a fast frame rate (some of which are even before the shutter release gets fully pressed!) completely and totally rocks my world!

I just put a few of the best frames I captured at Saturday's launch up on Flickr. Enjoy!

Thanks to my wife Karen's graphic design skills, and Keith's SVG-foo, the Altus Metrum group of projects now has a logo!