Volksduino Error: 2.1mm power jack

August 28th, 2011

We’ve found a bug in the Volksduino v1.2 PCB, related to the power jack. There is no danger to power supplies or the Volksduino if you plug in a power adaptor: the problem is actually that the jack isn’t actually connected to the circuit correctly. This is a problem with the 1.2 Volksduinos, which are nearly sold out, so we don’t anticipate many problems with this. This post is mostly for anyone who happens to want to add power to an older Volksduino at some point in the future.

First off: sorry! We screwed up. The original Volksduino (v1.0) had a few problems, which were fixed in v1.2. Somehow, this one slipped through the cracks. We’re especially sorry that it took so long to find this out and document it. Since we don’t usually include the barrel jack (in our experience, no one uses it, and it’s one of the hardest parts to solder for new solderers), it took nearly the full first production run of the v1.2 for someone to notice it. In any case, this is entirely our fault, and we’re working with folks who are affected to try and make things right. There isn’t a Volksduino 1.3 in the plans at the moment, unfortunately (we’re focusing on other products, which are a bit more “different” than Yet Another Arduino Clone).

Anyway, let’s get down to fixing this thing. The problem is with the pinout of the barrel connector. Instead of connecting the power input to the ring and center pin (ie: ground and positive voltage), it’s connected to ground and the “power supply is plugged in” switch. There is no danger to your power supply or stock Volksduino: it’s just that the wallwart’s positive supply isn’t really connected to anything.

The problem is that the wrong pinout was used for the power jack, so we need to cut one trace (“wire” on the PCB) and run a quick jumper from the jack. Here are images of the two step:

1. Cut the trace, (and where to do it, and what a cut trace looks like):

2. Run a jumper wire between these two points:

Fuller details:

Tools needed to fix this:

  • Multimeter for continuity testing
  • X-acto or similar sharp, maneuverable knife
  • soldering iron
  • solder wick (radio shack has it)
  • short length of wire, preferably 22 or 20gage stranded

Problem description: the power jack pinout is wrong. We need to cut the socket-D1 trace and add a jumper from VIN+ to the barrel jack terminal closest to the 7805.

A quick, overly thorough textual walk-through:

  1. Test for continuity between the left/outside VIN pin and the bottom pin of the power socket (on the top of the board, it has “7~15VDC” printed through it). On a stock board, this will be a short.
  2. On the top of the board, there’s a trace running between the socket and D1′s anode (right under the letter “1″ in “1N4004″). Between the socket and the diode (ie: right next to the socket), cut this trace with the x-acto knife. This is a very thin layer of soft copper under a thin layer of soldermask, so you don’t need to press hard. It’s sometimes helpful to make two angled cuts, cutting a “v” in there.
  3. Once this is cut, test continuity again. If it’s still connected, try making your cuts a little deeper. Keep going until these aren’t connected.
  4. Flip the board over, and use solder wick to remove a lot of solder from the socket pin closest to the 7805 (it’s on the left when the board is flipped over). We want to get to the little hole in the terminal, so it shouldn’t require pulling off too much solder.
  5. If the little hole doesn’t want to clear out, heat up the solder, and gently tap the edge of the board on the table. It’ll probably come loose.
  6. Make a short jumper of wire, just long enough to go into the outside hole of VIN and run through this hole.
  7. Solder that wire in.
  8. Plugging in the wall wart should now light the power LED.

Make sure to keep the wire short, and that the insulation covers things well, which makes this a reliable repair.

If you run into any questions or problems, email support@appliedplatonics.com and we’ll get everything sorted out. Apologies again for the bug!

Posted in Uncategorized | No Comments »

Volksduinos in the Wild: Lasers pew-pe

September 23rd, 2010

The Volksduino is our high-power Arduino clone.  The first (short) run is nearly sold out, and has been integrated into everything from a prototype laser display to a bacon-y alarm clock.  Over the next week or two, we’ll have a series of blog posts talking about these Volksduino projects, with links as needed.

First up: the laser drive circuit, as a teaser.  This is a part of a Noisebridge project that’s still a bit nascent, but it’s handy to know how to drive a higher current device from the Volksduino board.  Miloh is hooking up his Volksduino to a laser diode, adding some repurposed hard drive platters, and building a raster scanning laser display.  Note that this is a Volksduino v1.0, which was used in the Greenwire (PCB Repair) workshop.

The laser pulls more current than the Atmega328 can provide, so he added a transistor and a couple of resistors to drive it.  The transistor is a 2N2222 or 2N3904, and the resistors look to be 510 ohms between digital 8 and the base of the transistor, and 22K into the collector, with the laser diode going from the emitter to ground.

With that, he can pulse the laser, and has full PWM control of it.  Along with an optical encoder on the mirror platters, this can form a full-fledged raster scanner.  I can’t wait to see the finished result here; perhaps it’ll be done soon enough to be featured in this parade of Volksduino projects!

Coming up next time: monitoring web server utilization with a Volksduino and a surprising choice of output devices.

Tags: , , , , , ,
Posted in Hacks, Volksduino | No Comments »

TI Launchpad: no Arduino killer

June 26th, 2010

TI recently announced a new entry in the hobbyist microcontroller space, the TI LaunchPad, which is targeted at the Arduino market.  I don’t believe it’s going to make much of a dent, though.  I spent a while looking at the LaunchPad. I like the idea of it, and I love that TI is doing something to make devices cheaper and therefore more accessible (which is why I built the Breaduino and Volksduino kits, low-cost, accessible Arduino clones). After my initial excitement, though, I’m feeling pretty negative about the device’s future.

(Shameless plug: order the Volksduino kit for $20!)

The kit is a $4.30 purchase, which sounds great, until you find out what’s in it: everything.  Not great, but incredible!  It’s got a USB programmer, a couple of MSP430 Value Line microcontrollers, the development environments.  It even includes the USB cable, and comes in a nice box.  The website has an unboxing video, which is … odd, for a uC dev kit.  Overall, this is a fantastic value, and a wonderful development kit.  If the IDEs are remotely friendly, it makes a compelling first device.

First off, they must be taking a loss on every one of these. I priced out building a knock-off of just the carrier board (without all the control electronics, though with a regulator). I can’t do a kit for less than $4.50*, not including the actual MSP430 chips.  True, they’re using all their own parts, so it’s probably not more than $6 a board, but, still, it’s impossible for anyone but TI to make the main board with their pricing.  This locks up the core of the ecosystem, but might be okay: people can make stations (what I’m calling “shields” for this board).

Judging from the photos, the footprint is 2″x2″, with the header rows at 1.8″ apart. This is just a tad larger than the little Radio Shack protoboards, but not small enough to make the larger protoboards look “at home” docked to the top of it. Their pin layout is suitable for doing stations, but it’s teensy. The Arduino shield footprint is annoyingly small, and this thing is smaller still. And, of course, these microcontrollers have a lot fewer GPIO and analog inputs  than the Atmegas, so you can’t do a useful station-shield adapter board. Beyond that, it looks to be 3.3V only; ask Sparkfun how popular 3.3V Arduinos are vs their 5V siblings.  Overall, I don’t find it terribly friendly to kit work.

TI is going to move a ton of these devkits, but I don’t see it developing into an ecosystem like the Arduino’s. Kitmakers are going to feel the “cheap cheap cheap!” pressure, and it’s going to be really hard to escape that.

(That said, I have a design for the “ProtoStation” already done. I just need to get my mitts on a copy of the board to double-check my schematic before I send it off to the board house. Hopefully people are willing to spend another $3~10 on their new ultra-cheap toys.)

* NB: TI hasn’t published application notes for that uC, nor a reference schematic in the datasheet, so my design estimate is ballpark, within a quarter or so.

Posted in Uncategorized | 6 Comments »

Greenwire (PCB fix-up) Workshop

June 24th, 2010

Want to learn how to repair circuit boards?

Did you make a PCB, only to find out that the design is wrong?

Green wires to the rescue! “Green wires,” aka “patch wires,” are the fixups made after-the-fact, completing connections and adding components. It’s the last (and mostly hidden) step in circuit design: schematic, board, green wires. There’s a lot of art to green wiring, but you can learn the fundamentals in a couple of hours, hands-on.

Conveniently enough, I’ll be running a 2 hour, hands-on workshop on green wiring on Saturday, July 10th! The cost is $25, which includes an Arduino clone kit that needs several kinds of fixes. We’ll talk about diagnosing potential problems on a circuit board, then walk through techniques for fixing them on a kit I’m developing. At the end,
you’ll have new tricks for fixing boards, as well as a better understanding of the board design process (and a shield-compatible Arduino clone to play with).

This is a slightly advanced workshop, so you should be comfortable with a couple of things:

* soldering: we’re going to do a fair bit of this (building a kit)
* reading schematics: you should be able to read basic schematics

If you’d like to come, please let me know, so I know how many kits to bring. And, if you pay by PayPal before July 4, it’s only $20:

Register for the green wire workshop! (Workshop has happened, look for a re-run at a future date!)

What:

Green wire workshop (PCB fix-up)

When:

Saturday, July 10th, 1PM

Where:

Noisebridge
2169 Mission St (at 18th)
SF CA 94110

BART: 16th and Mission

Cost:

$20 before July 4, $25 thereafter (materials included)

Noisebridge is an open workspace, so the environment may be a bit chaotic.

10% of the money I collect will be donated to Noisebridge, to ensure we continue to have it as an excellent resource.

What we’ll cover:

* The construction of a PCB
* Identifying faults (shorts, opens, and oopsies)
* Basic strategies for dealing with the above
* Hands-on practice fixing each of the above

No one turned away for lack of funds. Drop me an email in advance, and we’ll work something out. I’d love to have you there!

Posted in Uncategorized | 1 Comment »

Breaduino: the all-breadboard, no solder Arduino clone

June 6th, 2010

I’m now selling my first kit! The Breaduino is a $10 Arduino clone you build from scratch. Unlike most kits, there’s no circuit board: you provide a breadboard (even the teensy half-length ones will work), and build your own Arduino from scratch.

I’m really excited about the prospects for this kit. It’s perfect for a classroom setting, which is a big deal to me. Any electronics classroom has everything you need to build this, and it can run off a 9V when completed, letting everyone start their kit up, instead of taking turns on the bench supply. More importantly, students can see exactly how it’s hooked up: it’s pretty darned simple. As an instructor, you can easily explain the purpose of every component during assembly, and still have a classroom of the things assembled in a half-hour session. I’d love it if these made their way into classrooms (email me for educational discounts). At $10/each, the Breaduino kit is also pretty easy in terms of materials fees. Students will also need a 9V clip ($0.10) and a breadboard ($8 for something nice at Adafruit), so, for $20 apiece, they can take home their handiwork.

It’s also great for those of us who work on Arduino-powered art pieces and gizmos. Dropping a Duemilanove ($30) into a project is a commitment, especially when the rest of it is made from free-to-you scavenged parts. This kit is designed for a breadboard, but it’s totally amenable to solder-down protoboard for permanent installation. You can do all your prototyping on a breadboard with a Breaduino, then transfer it exactly as-is to a protoboard. It’s also really small-footprint, so you can use a board only a fraction larger than the Atmega328 chip itself. The only way to get appreciably smaller is to go surface mount (but that kit’s a ways off). I’m hoping to do cheaper soon, too, by removing a few components from this kit.

Building the Breaduino kit has been interesting. It’s been almost entirely a matter of documentation: putting together an Arduino clone is fantastically straightforward. Between Atmel doing a fantastic job of making an easy-to-use microcontroller and the clear schematics from the Arduino team, it went together quickly. After that, there was a bit of work putting together a bill of materials, and a big order from Mouser. Then I had to document it. And make a video. And a website. And then redo a bunch of that, because it looked awful. Finally, all that work was done, and it came time to bag up kits. Oh, wait, I need a sticker design, and and and…

Happily, a lot of that work was in learning. I’ve now learned a lot, and will have a few more kits coming out soon: a 48-input analog input shield, another couple of different low-cost Arduino clones, and, eventually, the project that kicked all this off: a near-space ballooning shield. I’ve got a handful more ideas for things, too: a benchtop power supply with LCD readout powered by an Atmega, the ever-popular automatic bike lights, a plug-and-play relay board, an RFID appliance shield, an all-surface-mount Arduino clone… That said, I’d love more ideas. I’d love any kit suggestions people might have, leave a comment!

Posted in Uncategorized | No Comments »

iPad: Taking away our kids' fingerpaint

April 11th, 2010

The iPad is hot. It’s a stellar product, with slick hardware and software. And Apple will make it better, much to their credit. Unfortunately, they’re making it a closed device: you must go through Apple to write software for the iPad, and forget about even replacing the battery yourself. It’s a sealed box, and Apple controls everything about it. They see this as key to keeping their (incredible) user experience today, but I wonder if they’ve thought about the longer-term implications. I believe that they’re depriving themselves of their lifeblood in ten years’ time. It’s not just the iPad, either: it’s the increasing prevalence hermetically sealed hardware and software. But I’m going to pick on Apple because they’ve done a total about-face from their origins.

Apple is putting a (relatively steep) barrier to entry on getting content on their devices. I understand why they think it’s important: to maintain that trademark slickness, they can’t let Just Anybody in. Considering that they built or purchased every component in their system, that’s their perogative.

But they’re shooting themselves in the foot. Not today, with all the rabid Free/Open Source fanboys; we’re a tiny drop in the bucket, even with the ripple effects of our righteous indignation. Instead, they’re crippling the next generation of creative programmer, or at least pushing them off to other platforms. Those creative types are the people who make Apple’s own products so great, and are the people who build innovative software on their platform.

My generation of programmers will talk about their first programming language with an acute nostalgia. Most of us learned to program using a language called BASIC, which teaches you all sorts of bad habits. It’s the programmatic equivalent of learning to drive in a car with half a steering wheel, a missing rear-view mirror, and no turn signals. But every platform back then came with BASIC, or had one easily available. Even if you didn’t have that, your middle school graphing calculator came with a BASIC. And that’s how we learned to think like a computer (or at least, as close as you can in BASIC).

From tweaking the BASIC programs we swapped with friends on floppies, we went on to build other creative things. We wrote text adventure games, graphical animations, and programs to work our algebra homework for us. BASIC opened up a new venue for creative expression, and we kept at it. Giving a kid a BASIC is like giving them pastels or tinkertoys: the initial products are rough and silly, but they’re forming a critical foundation for later development.

With new, hermetically sealed platforms, I fear we’re going to miss kids during their “critical period” for learning to speak programming languages. We’ll have a whole wave of programmers that didn’t get the tools to program until they were freshmen in college. Programmers who had that experience are working in the industry today, but they started at a great disadvantage, and it shows. They make great “engineers,” writing software to match a specification using standard tools they learned about in books. They are not, for the most part, the kinds of people who really innovate in the discipline. Would you expect exciting new paintings from someone who didn’t handle a paintbrush until they were nineteen? Or dynamic buildings from someone who hadn’t built so much as a pillow fort before college?

That’s what we’re forcing upon this generation of kids. We’re taking away their fingerpaint and their Lego, and I fear we will reap what we sow in a decade’s time. Apple and Microsoft are both pushing towards more closed platforms, and many vendors are on-board with the effort, or at least are complacent about it.

I’m especially disappointed with Apple, though: their first mass-produced computer booted up to a BASIC prompt.

Tags: ,
Posted in Uncategorized | 1 Comment »

Excising FAT Tumors

March 2nd, 2010

I recently built a new fileserver for home. It’s pretty nice, with 3.7TB of RAID5 storage. I’ll never have to worry about losing data again (mostly).

Unfortunately, in the process of transferring data, I found that, well, I had already lost data.  My old backup drive (an external, FAT32 disk)  contained a directory that pointed off into gobbledygook, containing garbage as “files” and “directories.”  I noticed this when my rsync went off the deep end.  This “broken copy problem” is a simple problem to fix: rsync has a –exclude option.  To get the copy to finish, I just –exclude the broken directory and recopy.  Thankfully, the directory was junk (eclipse metadata), so I could ignore it, and all was well.

But.  Once I finish the copy, I’d like to continue using this drive for moving data around, etc.  With this corrupt directory, though, I can’t quite trust it.  When you realize what causes this corrupt, it becomes clear that no off-the-shelf tools will repair this without potentially mangling other data.  So, there’s no way to fix it short of formatting it.  But, understanding the corruption pretty intimately, I saw that it might be possible to fix this, if I hand-edit the disk.

So I did.  Knowing what the underlying problem was, I wrote some tools to inspect the filesystem manually, then went in and excised this directory.  Once that was done, the FS came up “clean enough,” and worked.  It might be fun to go through the process of building these tools, so here’s a quick overview.

First off, let’s identify the problem more precisely.  The big symptom is that ‘find’ returns tons of the following:

./density_home/jbm/workspace/.metadata/.plugins/org.eclipse.core.resources/.history/8f/ ?<A2>md`<B5>?.?<EE>?
./density_home/jbm/workspace/.metadata/.plugins/org.eclipse.core.resources/.history/8f/<F4><B0>q<EA>^\@??.?s<FC>
./density_home/jbm/workspace/.metadata/.plugins/org.eclipse.core.resources/.history/8f/<E6>q^]^\^K^G^N%.<E6>?0
./density_home/jbm/workspace/.metadata/.plugins/org.eclipse.core.resources/.history/8f/??^]v<B2>?<ED>?.?b^\
./density_home/jbm/workspace/.metadata/.plugins/org.eclipse.core.resources/.history/8f/?<E2>^^8<A5>^?<F4>?.u<F2>`
./density_home/jbm/workspace/.metadata/.plugins/org.eclipse.core.resources/.history/8f/<E8>???^X<DF>?<EE>.<F6>8^T

./density_home/jbm/workspace/.metadata/.plugins/org.eclipse.core.resources/.history/8f/ ?<A2>md`<B5>?.?<EE>?./density_home/jbm/workspace/.metadata/.plugins/org.eclipse.core.resources/.history/8f/<F4><B0>q<EA>^\@??.?s<FC>./density_home/jbm/workspace/.metadata/.plugins/org.eclipse.core.resources/.history/8f/<E6>q^]^\^K^G^N%.<E6>?0./density_home/jbm/workspace/.metadata/.plugins/org.eclipse.core.resources/.history/8f/??^]v<B2>?<ED>?.?b^\./density_home/jbm/workspace/.metadata/.plugins/org.eclipse.core.resources/.history/8f/?<E2>^^8<A5>^?<F4>?.u<F2>`./density_home/jbm/workspace/.metadata/.plugins/org.eclipse.core.resources/.history/8f/<E8>???^X<DF>?<EE>.<F6>8^T

It’s clearly “corrupt,” but what does that mean?  First, we’ll need to learn a little bit about how FAT works.  To do that, you can read any of a myriad of difficult-to-follow documents, all of which talk a lot about things that are only relevant on floppy disks (no, really).  Examples: Microsoft’s Description of the FAT File System (which is incomplete: it doesn’t cover FAT32), Wikipedia’s File Allocation Table (good, but tl;dr), Andries Brouwer’s The FAT filesystem (great, a little incomplete), and Paul Stoffregen’s Understanding FAT32 Filesystems (aha, finally helpful!  But lots of disk-ish stuff, and a few missing bits).

Once you’ve digested all of those, you’ve got a good idea of how FAT works.  Or you can sit down and listen to Josh talk story.

First and foremost: FAT was designed for floppies.  There’s lots of cruft in there, and a bit of weirdness, from that heritage.  A lot of things we think of as constants are variables in the land of 3.5″ vs 5.25″, DS vs SS, DD or not… all that great floppy crap.  Just be prepared for this.

So, without further ado, the structure of a FAT filesystem.  I’m going to assume you’re working with a partition on a hard disk, or a ‘dd’ copy of one.  The first chunk of the disk is the Boot Sector.  This is where the CPU boots from, so it’s got some actual code in it.  This is important for floppies.  We don’t care.  What we do care about are the following fields stored in the Boot Sector:

  • bytes per sector (0x0b-0x0c)
  • sectors per cluster (0x0d)
  • number of FAT copies (0×10)
  • number of sectors per FAT (0×24-0×27)
  • first cluster of FS (0x3C~0x3F)
  • FS type (0×52-0×59)

If you’re playing the home game, begin by checking the FS Type.  It should be “FAT32 “.  If it’s not, you’re in trouble, because I’m only explaining FAT32.

This is just the header structure, which lets us determine the geometry of the drive, and calculate where data goes.  After this, there’s the eponymous File Allocation Table, then a second copy of the FAT, and then we get to the actual data.  Let’s talk a little about how the data is organized, then come back to the FAT.

The actual directories and files in FAT32 are stored in “clusters.” A cluster is a contiguous block of sectors; a sector is a contiguous block of bytes (corresponding to a floppy disk sector, once upon a time).  All of these things are variables, though it’s really typical that sectors are 512 bytes, and clusters are 32Kbytes.  You should read in the appropriate variables above, and compute them for your disk, though.  The cluster is the base unit of allocation of your filesystem.  When you store a file, its content gets put into a set of clusters.  If the file is under 32K long, it goes into a single cluster; if it’s more than 32K, it goes into multiple clusters.  Similarly, directories are stored in clusters.  Most directories fit within one cluster, but sometimes they, too, span multiple clusters.

The content of files are stored “raw”: a file cluster is just a 32K chunk of that file.  All the metadata about the file is stored in a directory cluster.  Directory clusters, on the other hand, are nothing but metadata.  They’re a list of entries with names, types (directory or file), and cluster numbers.  So, you start out at the root cluster (“first cluster of FS”), and read it as a directory.  Walking through this, you find the name of all files and directories in the root of the FS, and pointers to the clusters containing those files and directories.  From there, you can go to those clusters and read their contents.

But what if a file (or directory) spans more than one cluster?  Normally, you’d assume the OS would allocate a contiguous range of clusters to any file, and just write the file there.  However, let’s assume you’re the OS, and you’re working on a disk that’s been in use for a while.  What if the user wants to write a file that’s bigger than any contiguous range of clusters, but fits into the free space fo the disk?  You could shuffle things around to make that work, but, haven’t I heard this before?  Oh, yeah, the bin packing problem.  It’s hard.  So, instead, we fragment the file into multiple clusters, and spread them to the four corners of the disk.  This lets us use all the free space on the disk, without having to solve NP problems every time the user writes a new WordPerfect document. (Yay floppies!)

So, now we need a way to keep track of all these clusters.  Putting them into the directory entry itself is tricky: we’d really prefer it if our directory tables were made of constant-length entries.  We could use some space at the end of each cluster to point at its next entry, but there must be some good reason not to do it that way, which probably involves floppies (it smells like a DMA/alignment thing to me, but I dunno.  If you do, please comment).  Why must there be a good reason not to do it that way?  Because MS chose to solve it in a way that makes absolutely no sense otherwise.

They created the File Allocation Table.  If you looked at the Boot Sector of your disk, you might’ve noticed that the “number of sectors per FAT” is a kinda big number.  On my 320GB drive, it comes out to 37MB.  If all the file contents are in clusters, and the directories and filesystem metadata are in other clusters, what the heck is in the FAT?

Naturally, it’s the linked list of what cluster comes after the current one.  Every cluster on the disk gets a 32 bit number entry in the FAT (hence FAT32), which is the index of the next cluster after it in the current file. These are coindexed, so cluster 2 gets the 2′th FAT entry: whatever number is in there is the next cluster in this entry.  There’s a few special values: anything over 0x0ffffff7 is an “END” marker.  So, let’s assume we have a directory that points to “NIBBLE.BAS” of length 35K at cluster 13, and that FAT[13] = 37, and FAT[37] = 0x0ffffff.  Then NIBBLE.BAS is made up of all 32K of cluster 13, and then the first 3K of cluster 37.  The remainder of 37 gets wasted, which is a real shame on a 720K floppy.

So, to recap: file metadata is stored in directory tables, which are stuck in clusters.  File contents are also stuck in clusters.  If any one entity spans more than one cluster, you start at the first cluster in its chain, then go to the FAT entry for that cluster to find out the next one.  If the next one is greater than 0x0fffff7, you’ve hit the end of the chain.

How is that metadata stored?  Well, it’s not too bad until we get to long file names.  It’s just a packed struct, of a fixed length.  Every directory table entry is 0×20 bytes long.  The fields you care about:

  • FilenameExt: (0×00-0x0b): 8.3, minus the dot
  • Attributes: directory/readonly/system/etc.  (0x0f is a wacky VFAT entry, if 0×20 is set, it’s a directory, see Andries for a complete bitmask)
  • Cluster high: 0×14-0×15
  • Cluster low: 0x1a-0x1b
  • Filesize: 0x1c-0x1f

Notice that the cluster is split up?  The “high” part is in a previously reserved part of the directory entry structure.  They used to only have the low part.  Floppies.

So, you read in those bits, multiple high by 256 and add it to low, and bob’s your uncle.  The filenames are probably awful (BOBSY~12TXT), but, for the purposes of “Find the place to excise a tumor from my FS,” I can deal with ugly path components.

At this point, we can see what went wrong above: the directory entry for …/8f/ got mangled somehow, and its clusterhi+clusterlo now points off into the middle of file.  The contents of that file are being dutifully interpreted as a directory.  Better still, the file goes on for a reasonable number of clusters, and, best of all: since those clusters contain random stuff, some of it is being interpreted as pointers to subdirectories, which point off to random clusters.  Which are probably other files, and so on, and so forth.

This explains the behavior I was seeing quite nicely.  So, what do I do to fix it?  If I tried to delete it recursively (rm -rf and/or deltree), it could be Very Bad: it’s going to go through and crap all over the clusters randomly pointed to, breaking the chains they’re in, and potentially mangling the whole FS.  That would be pretty tragic.

Knowing what we know above, though, there’s a pretty obvious entry: let’s just remove the bogus directory entry by hand!  Since the contents of 8f are a lost cause anyway, I could just go in and nuke its directory entries.  But, honestly, I kinda hate eclipse.  I only care about that workspace directory for the code in it; the eclipse metadata can go to hell for all I care.  So, I’m going to cut the tree of there.  Now I just need to find the 32 bytes on the disk to overwrite to make this happen.

To do that, we need to find the cluster on disk.  We know the first cluster comes right after the FAT, so that’s easy: len(boot sector) + len(FAT) + N * sizeof(cluster), right?  No, that would make sense, and this is FAT32.  Remember the variable “first cluster of FS” in the boot sector?  Didn’t it seem like that should be zero?  Yeah, it’s two.  It’s always two.  Not sure why, it just is, but, remember, it’s stored in a variable.  So, that’s the cluster you go to read the root filesystem, but it’s actually the first cluster immediately after the FATs.  Yes, FATs, because there’s probably two of them.  So, in the end, you wind up with:

offset_of_cluster(N) = 512 + 2*sectors_per_fat*bytes_per_sector + (N – first_cluster) * (sectors_per_cluster * bytes_per_sector)

Ain’t FAT grand?  This is the most widely-deployed FS in the world, folks.

With all that in hand, we can finally write code to walk down these things and find out where they live on disk.  Once you’ve done that, you can find the offending entry in the directory table and pluck it out by writing zeros over it.  Well, assuming it’s after anything else you might want in that directory.  If the zeroth byte of a filename is 0×00, it’s assumed to be the end of the directory listing.  Supposedly.  So, if you want to access stuff beyond the excised directory, you might be in trouble.  Good luck with that.  Happily (and oddly), Linux’s implementation of vfat skips over zeroed out entries, probably assuming that they’re problematic in this kind of a way.  Actually, it only does that when I mount the disk I modified; the disk image treats this as a directory terminator.  There’s an awkward question I don’t want to ask there, so I won’t.

Also note that the FAT is probably wonky at this point.  We pruned the directory entry, but it might still have clusters allocated to it.  Since we didn’t (and can’t) clean those up, there are probably a bunch of clusters marked as used which aren’t actually connected to the current FS tree.  There’s not any good way to identify these, short of walking the whole FS and keeping track of which clusters are part of something.  At that point, we’ve written our own baby fsck (the stock fsck.vfat totally fails on drives this size for me, and I’m definitely not hooking this thing up to a windows machine at this point).

After all was said and done, I got my drive back.  It’s probably got a bunch of wasted clusters, but, you know what?  I don’t care.  There’s a lot of stuff in this process that, when it comes down to it, I don’t care.  All that matters is that, at the end of the day, I got my drive back.

Tags: , , ,
Posted in Hacks | No Comments »

Project Bacchus Catch-up Post

February 27th, 2010

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!

Tags: , ,
Posted in Hacks | No Comments »

AA Battery Holder Reviews

February 27th, 2010

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.

White, blue, black: the edge of space

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.

Tags: , ,
Posted in Hacks | 4 Comments »

Roku Channel SDK: No Free Software

February 12th, 2010

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.

Disappointment.  That is: this platform, built almost entirely on Open Source, won’t allow me to use the same tools they did.  iPhone developers face a similar problem, for much the same reason: the iPhone Store’s TOS disallow GPL code.  The big difference is: the iPhone is a phone.  It’s not too alluring to run Linux on there, or make it do new tricks.  Moreover, Apple used almost no off-the-shelf Open Source in the iPhone device.  The Roku, however, is built entirely on F/OSS, and is a nice little box that sits on your TV.  It’s a fantastic little box, and deserves to run totally custom software.  Unfortunately, with their current Terms of Service, anyone who develops Roku channels can’t legally take part in that creative reuse of an excellent device, which is too bad.

Tags: , ,
Posted in Hacks | No Comments »

« Older Entries