Hypomnemata

Actually, since we don’t currently have a public blog or wiki, I thought it’d be nice to collect a bunch of Project Bacchus stuff in one place.

We started Project Bacchus in late October, 2009.  My friend Shannon approached me with a question: “What do you think about sending a camera to the edge of space?”  My answer was quick: “That’s why I got my ham radio license!”  We pulled in a few more people, and a plan emerged through weekly meetings, at which we always have beer. Always.

Our project was kept quiet for a while, in part to give ourselves room to fail (which we did), and in part to keep it coherent. The more people you have, the more ideas/goals you have, the less you can focus. By keeping it to just five guys, we stayed on track, though we did probably bite off too much for our first few launches.

The biggest challenge has actually been scheduling flights, with weather a close second. Everyone wanted to have the whole team present at our first big launch, which we did. Getting there was a challenge, especially in December: between the holidays and the rain, we didn’t have a single launch window. We’ve since moved to a much nimbler group, able and willing to fly with only three guys in the field. That’s worked out really well for us, as you’ll see.

Without further ado, a quick recap of most of Project Bacchus up to the present:

Bacchus I: 2009, November 21; abject failure.

My apartment, the night before Bacchus I

Adam has a flickr set of our attempt here, 20091121 Project Bacchus I.  Note that all these pictures were taken on November 21.  The ones in my apartment were just after midnight, the rest were at about 7am, an hour and a half drive from San Francisco.  This is on top of an all-nighter on Thursday by Michael and myself, which resulted in a nice, solid payload, but slightly frazzled nerves.

Bacchus I's Flight Computer: Spaghetti (Ted Scharff)

That’s a great shot of the flight computer’s (totally spaghetti) guts by Ted; he’s got more electronics porn in his Bacchus I Gallery.  There’s other documentary evidence of this trip, but it’s mostly depressing, so I’ll pretend it doesn’t exist.  On the positive side, I got an inadvertently free margarita at brunch after our failure.

Bacchus I, which never left the ground (Ted Scharff)

In summary, we learned a lot from our first failure.

Bacchus II: 2010, January 10; payload lost at launch. RECOVERED! 2010, May 29

The balloon, tethered between our cars (Adam Fritzler)

Adam’s the most photo-happy member of the group (but Michael and Ted are both pretty photo-happy themselves), so I’ll link to his set first again: 20100111 Bacchus II Launch.  This launch was in a valley that’s socked in with fog, underneath otherwise crystal-clear skies.  Launching through the fog was technically against FAA regulations, but there was no behavioral difference between us launching in clear skys and through the fog: pilots couldn’t have seen our balloon until the same altitude either way.

(L to R) Ted, myself, Michael, and Shannon (hidden) rig Bacchus II (Adam)

But maybe the FAA regs aren’t there for the pilots, because we immediately lost visual contact with the payload, and the ham radio rig only got three check-ins (up to 9,000′!) before it went silent.  We had a backup cell phone in the payload as well, but it never checked in.  The assumption is a catastrophic failure shortly after launch, but we’ll never know.  For now, the official story is pterodactyls.

Update, 2010, May 31 Bacchus II was found! A rancher moving cattle down to summer grazing land came across Bacchus II dangling from a tree. It was in a remote valley with no cell phone coverage, but the phone seemed to be in okay shape. The current theory is that the radio failed shortly after launch. We’ll know more in the next week or two–the call came in two days before Bacchus VI, which was retrieved from the top of a peak in the foothills (technically a mountain), which was yesterday. Needless to say, we’re a little overwhelmed between the post-processing of mission data from VI, post-processing of the data from II, and making time to post-mortem the failure of II’s hardware. Regardless, welcome home, prodigal probe!

Bacchus II: It's About Quality™ (Ted Scharff)

Again, we learned a lot from our failure here. For instance, our new fill method is nice and elegant; the fill method used in Bacchus II… less than elegant. There’s a lot of good photos in Ted’s Bacchus II Picasa Gallery.

Bacchus III: 2010, February 14; payload retrieved.

A camera, dangling from a balloon, took this.

After throwing away several hundreds of dollars of electronics on Bacchus II, we went back to basics for Bacchus III.  One tortilla warmer, one cell phone, and one camera.  We didn’t put on a chute, since we had a very light payload and a giant streamer, which worked out really well.  A couple hours after launch, we came upon Bacchus III lying, undignified, in a fallow field, nary a scratch on it.  The telemetry from the phone’s GPS shows it coming down at about 40mph, which is a little zippy, but not dangerous with as much foam as we had.

Bacchus III Away Team: Shannon, Adam, myself, Michael (Michael Toren)

As part of our “lean and nimble” goal for this launch, we went with just four of the five team members.  Ted had other plans that weekend, so we ran off without him.  We did have his hiking GPS, though, which, once we figured out the UI, was invaluable.

Bacchus III, on the ground (Michael Toren)

We retrieved the payload and got a bunch of photos off of it.  Adam went through and edited them down to the best ones: 20100214 Bacchus III (payload camera).  We thank him greatly for that, as it’s kind of a huge pain, and he’s really good at it.

Based on the data we collected here, we’ve been able to understand the dynamics of the system, predict future behavior, and better plan future flights.  We’re working towards a payload for Bacchus IV in a couple weeks, which is part of why I was reviewing battery holders in the last post.

Bacchus Kite Tests: 2010, February 20; way fun.

Myself, Ted, and Michael rig a "test" payload (Adam Fritzler)

To test some of our descent gear, we decided to use a kite as a flying platform.  We had a few things to test this way, but only really got to one of them this time.  Mostly, this was a good excuse to go out into the park and drop stuff from kites.  It’s really, really fun, try it sometime.  Also, it gave me an excuse to buy a 200′ measuring tape, which is probably one of the more specialized pieces of equipment I own.

Mission accomplished! (Ted Scharff)

After we finished our actual goals (breaking the hell out of some styrofoam), we went ahead and did something silly: dropped the camera, recording video, from 100′ with a Wal-Mart bag as a parachute.  It’s really, incredibly disorienting, but damned fun. Video as soon as wordpress stops being stupid about it.

And that’s it. You’re now caught up on Project Bacchus!

A lot of my free time has gone into Project Bacchus lately.  Some friends and I decided to try and get a picture of the edge of space in late November, and we’ve been working at it ever since.  A few weeks ago, we had our first successful flight, Bacchus III.

Bacchus III's view of the horizon near apogee (Courtesy Adam Fritzler)

We’re now getting a little more ambitious, and working on engineering things a little better.  We captured a bunch of pictures, but our camera stopped right after this one:

A nice shot of Bacchus III's impact point (Courtesy Adam Fritzler)

This is the field Bacchus III landed in.  Taken on the way down, literally seconds before impact: talk about good timing!  It landed surprisingly gently, and all the equipment survived intact.  In fact, our styrofoam cooler doesn’t even have a dent from the impact.  It was, quite frankly, a perfect landing.  Despite this, the camera suddenly stopped after the above photo.  Our conclusion is that the batteries came “loose”: the springs that hold the AAs in place inside the camera were compressed by touchdown.  This disconnected power for an instant, resetting the camera.

So, we’re now very interested in battery holders.  So interested, in fact, that I spent an hour the other evening playing “Consumer Reports for Near-Space Hackers.”  Andy (of the eSATA help) purchased some candidate holders from Jameco, our neighborhood electronics warehouse.

Here’s my notes, if you’re in the market for battery holders.

Jameco 216152: 4-AA, 1×4, no case, $1.15/unit

This is a boring 4-AA holder, like you had in the bottom of R/C cars as a kid, yadda yadda. Except that it doesn’t have a door, like your cars always did.

The springs feel good, pretty firm. A longitudinal landing will probably cause disconnect, similar to that seen in the camera on Bacchus III.

There is no case, so it’s really easy for me to imagine bouncing the batteries out unless they’re retained somehow. Given that it costs us $2.50 for two of them, and we’re already spending $20 on the batteries, we could consider these consumables and just replace them every flight. The real challenge there is that we’re resoldering the most important solder junction in the system every flight, which is going to be bad for the PCB eventually.

Another alternative is to construct a little sleeve to go around the batteries, which could be as simple as cardstock (read: cereal box) and fiberglass tape (read: duct tape).

Jameco 216216: 6-AA, 2×3, no case, $0.75/unit

This a little 2 by 3 battery pack.  In layout, it’s the same as the 216152, except that it’s only got three batteries in a row, and there are two of them back-to-back. It feels reasonably constructed, same as the last, but still not the totally solid feeling I’d like. The springs are less solid than the 216152, by a noticeable amount.

Most significantly, the middle battery in each row has the exact same “could get jostled out” problem as the middle two batteries had in the 216152.

We could resort to the same “consider it consumable” strategy here. This is cheaper than the previous solution, and I’m much more okay with burning $0.75 per battery load if it means we don’t have to worry about our power supply.

A sleeve is also an option here.

Jameco 2095453: 4-AA, 1×4, case, $0.99.unit

You know the battery cases Mitch uses for his kits? This is one of those, without the switch. It has the little hole for the switch, just no switch.

It’s 1×4, with a case around it. It snaps closed, and then is retained by a screw. It generally feels really solid, which is nice.

The one big concern I have here is the quality of the springs. They’re significantly weaker than the ones in the 216-series cases.

Conclusion:

I’d go for the 2095453 vs the 216152. They’re both 4-AA, which is not ideal for our current payload, but they both feel really solid in their own ways. With a bit of testing, I’d feel confident that the 2065453 can handle the impact of landing, and then I’d be totally sold. Barring that, I’d prefer to make a dapper little sleeve for the 216152 and work with that a bit.

I’ve been looking for an eSATA enclosure to put on an Atom board for a home NAS.  My primary goal is to have 4TB of disk space that’s in a RAID.  The secondary goal is to be cheap, which means low power.  Assuming I keep this thing for four years, and that PG&E continues to charge $0.12/kwh, every extra watt of power consumption costs me a little over $4.

So, I’m looking for low power.  This means an Atom processor and motherboard, which barely sip power.  Unfortunately, none of them have both a reasonably recent Atom and more than two SATA ports onboard, so the goal was to use an eSATA enclosure to connect three 2TB drives in a RAID5.  The first enclosure I came across was the AMS Venus ES5 (AMS DS-315SES), $170 on sale at Central Computers.  I picked it up (after inquiring about restocking policy), along with three Hitachi 2TB drives (HITACHI 0F10311).  I have been trying to get it to work with a PCI SATA board in my old desktop.  That didn’t work: the SIL3512 chipset doesn’t support port mulitpliers.  I borrowed another card from my friend Andy, a VIA chip this time.  Also didn’t support port multipliers.

Andy was then kind enough to meet me at a Peet’s in downtown SF, where we plugged it in to his Dell laptop, with an Intel GS45 (ICH9M) chipset.  This worked like a charm, and we proceeded to do some tests on the array.  At a coffee shop.  It drew surprisingly little attention from passersby: this is San Francisco, after all.

On the positive side, it just worked with linux.  It came up a little curiously the first time, but that’s typical for older RAID enclosures (scanning disk by disk).  Hotswap also seemed to mostly work, though it did cause the enclosure to reset its entire link every time you unplugged or replugged a drive.  This makes hotswap a lot less useful, but it is still, technically, hotswap.

We tried reads and writes of 1GB with ‘dd’, varying the number of simultaneous spindles.  We also tried buffered and unbuffered modes for  these operations, to try and get raw performance of the array’s drives and chipset.

For writes, the enclosure does okay: it looks like it scales out nicely, though doesn’t nearly saturate a 3Gbps link.  At peak, we got just under 210MBps, or 1.68Gbps, or 56% of the theoretical peak.  More typical would be 1.2Gbps, or 40% of peak.

Reads were far more disappointing: buffered reading off three drives gave us 76MBps, or 20% of the theoretical peak.  Note that a single drive reads at 130MBps, so it’s apparently just bus contention slowing this down.  Since this is roughly my use case, I decided that I wasn’t keen on using this enclosure.

A very large thank-you to Andy, for sharing both his hardware and expertise.  He’s been testing spindle performance a lot lately; he may post results somewhere, and I’ll be sure to link to it here.

Also, thanks to the staff of that Peet’s, for not kicking us out, even though we unboxed a weird device and plugged it into the wall in your shop.

NB: We didn’t get to do mixed reads and writes, nor did we get to complete the table below.  Please recall that these tests were performed in a coffee shop; we ran out of latte, and didn’t feel like ordering another, given the way these turned out.

Short version: the Roku Channel SDK License includes language that prohibits GPL-bearing applications.  Given that their device runs a GPL’d OS with a bunch of other OSS infrastructure, this is disappointing, and F/OSS authors should be careful in accepting the Roku SDK’s terms of service.

If you read my old blog, you may remember that I found a way to  Download the Roku Firmware a while ago. It was clear that one could load custom firmware via a man-in-the-middle technique. In my case, I wanted to place my ripped movies into the Netflix Play-it-Now queue. It was technically feasible, but sort of a pain (it required reversing the Netflix protocol, which required adding custom CA certs to the image, and and and…), so I dropped it.

Fast forward to now-ish, with the introduction of the Channel Store on Roku.  I just noticed Roku’s Channel Developer SDK in an email announcement they sent out.  Exciting!  With a little elbow grease, I could watch my ripped DVDs, use YouTube on my TV (Google TechTalks and MIT OpenCourseWare!), or maybe even have a nice weather channel.  I was so stoked, I got out of bed an hour earlier than usual to look into it.  No, really.

Part of my excitement was knowing it would be familiar.  Having seen their firmware, I know the Roku is a Linux box, running X windows, and using QT for its UI.  All of this is Open Source Software, and I’ve used it all before: this is great!  I can bring my former experience to bear, and a lot of the Open Source stuff I’ve been using in the past should integrate pretty flawlessly.

I went and started signing up for the process.  Before downloading the SDK, though, you have to agree to The Roku Channel Developer Agreement. Instead of blindly clicking, I decided to read it.

5.A.iii:   Subject to the Grace Period, Your Channel Application must at all times: … not contain any open source code or other restricted code that could require Roku to publicly post or display any third party notices or any modifications to such code.