chumby One

November 13th, 2009

The chumby One is finally released. You can buy it now for a $99 “chumby insider” pre-order price; once we start shipping, the price will go up to $119.



While I’ve been working on several new hardware platforms for chumby, this is the first of the crop to hit the market. This one made it out before the Christmas season because it is an evolution of the original chumby design, now called the “chumby classic”, as opposed to a completely new form factor for the device.

The key goal of the chumby One platform was cost reduction: my first sketches for the device were drawn on the back of a napkin about a year ago, back when the stock market was in a free-fall and losing several hundred points a day. Unfortunately, the chumby classic hit full-stride launch in the middle of the worst economic downturn since the Great Depression, and its cute cuddly form factor comes at a fair bit of a price tag that many couldn’t stomach. So, I did what any entrepreneur would do in a recession, I suppose … scale back, and take a good hard look at everything and try to build a product that is cheaper, faster, and better for the market, to try and win new customers, and to retain the loyalties of our existing customer base.

Fortunately, around that time, a Freescale apps engineer contacted me about a new CPU (the i.MX233) they were going to launch in 2009 that could hit a remarkably low price point. So, I drew up some strawman renderings and did some cost scenarios, and in CES 2009, we circulated the idea around with a few potential customers to get feedback on the features and pricing. The idea sort of slow-rolled through the first few months of 2009, and after chinese new years, I taped out the first prototype board in late March. Around May we contracted an industrial designer to do some sketches, and by June we had a near-final ID; our first 3D printed prototypes were made around then (we couldn’t afford a mechanical engineering contractor I had to learn Solidworks and do the mechanical integration for the 3D prototype myself — since I enjoy learning new things, this was quite a rewarding experience). In July, we inked a PO for steel tooling and by August we had first-shot plastics. September was spent refining and debugging the design, and October was spent doing more testing, refining, and ramping up mass production. And, here we are now, in November. When I wrote this, the first shipment of chumby Ones were somewhere 35,000 feet above the Pacific Ocean en route to LAX. As for the i.MX233, I believe we are one of the first devices on the market to use it…I even got a quote in their launch press release last August, although I couldn’t refer to the chumby One by name at that time.

Just to give you an idea of what the final assembly line for the chumby One looks like, below is a video of a part of the assembly line:


[flashvideo file=http://www.bunniestudios.com/blog/images/c1mp_line.flv /]

In addition to being about half the price of the original chumby, the new device added some features: it has an FM radio, and it has support for a rechargeable lithium ion battery (although it’s not included with the device, you have to buy one and install it yourself). There’s also a knob so you can easily/quickly adjust the volume. But I don’t think those are really the significant new features. What really gets me excited about this one is that it’s much more hackable. The most significant improvement is that the firmware is stored on a microSD card.

The microSD card isn’t replaceable from the outside — this is to prevent non-hackers from pulling it out and wondering why the device isn’t booting anymore — but if you take the back panel off (screws this time, no glue seals), it’s fairly easy to access. The key here is that no longer do you have to worry about bricking your chumby device: if you screw up the firmware, you just pull it out, mount it on your dev box, and dd a new image onto it. Also, microSD is a “managed” NAND device, unlike our previous generation device which used a raw NAND device. This means that we don’t have to rely on a MTD layer for the filesystem, and instead we can directly drop ext3 onto the device. While we still mount the root partition as read-only to harden the device against accidental damage, unlike our original cramfs implementation, you can trivially remount it as read/write and modify the linux on the device. Also, our OS image takes up only a small portion of the total device capacity, so there’s actually over a gigabyte of extra space on there for you to load extra applications and libraries.

Significantly, what’s good for the hackers is also good for the developers. Because of this additional flexibility, we could add a ton of great features into the OS. For example, the chumby one supports certain 3G modems, and will serve wifi as an access point through the 3G modem (it can also serve as an access point for an ethernet connection provided via a USB-to-ethernet dongle as well). This is really slick, because that makes it basically a 3G to wifi router; it is enormously useful when I’m traveling and I need to create a wifi hotspot for other devices to use. Of course, this feature isn’t exposed yet at the mainstream user level, but if it turns out to be a popular application it’s something we could wrap a GUI around and make it more friendly to use. There are also other little refinements, such as if you plug a USB keyboard into a chumby One, it will automatically pop up a console shell that you can type into; very handy for times when you can’t ssh in, like when you are debugging network scripts. It also has high-speed USB2.0 support, so unlike our previous generation device, you can plug a USB camera into this one and grab images at a decent speed. And yes, we’ve booted Android on the chumby One. Android runs on linux after all, so why not? Eventually we’ll get these hacks documented on the chumby wiki (heck, maybe even compile them into a book), but right now we’re a little pre-occupied with making sure the product launch goes smoothly. Actually, to give credit where it’s due, most of these cool hacks were implemented by xobs (remember him? he ported quake on the chumby classic), not me — I’m just the hardware guy, xobs is the software guru.

Below are some annotated photos of the chumby One mainboard. Schematics and gerbers are forthcoming, should be up in about a week or two; the GPL source code is already up.

This is actually a pre-production pilot board. The mass production board is basically identical to this, with some minor tweaks to enhance compatibility with the SMT machines we use in China. There’s a couple of noteworthy points about the board. First, the footprints are available on the board for you to populate some parts to break out a composite video signal (NTSC or PAL). We’ve actually wired this up and confirmed that it works, and it’s pretty neat for presentations where you want to plug into a projector and show a crowd of people some widgets. There’s also a pair of test points on the board labeled “SETEC ASTRONOMY” that you can use to bypass the write protect on our authentication ROM, in case you want to wipe out the keys we use to authenticate your chumby. I can’t think of a real reason why you’d want to do that, but I added them on the principle that hardware you own shouldn’t hold secrets from you, so if you don’t like it you can nuke the encrypted access codes we put into each device (of course, it means you no longer have the codes to fetch widgets from our servers, but hey, it’s your hardware, void the warranty and do what you want with it). The security system is actually a bit convoluted on this device, but it uses basically the same, published protocol we employed on the chumby classic with some enhancements to leverage the internal AES engine on the i.MX233 to save the cost of an external cryptoprocessor unit.

One other really cool thing about the motherboard that I’d like to point out is that the power regulators are embedded inside the CPU. And they aren’t just linear regulators, they are switching regulators. And they just aren’t any switching regulators — this switching regulator derives three voltages using just a single inductor. How cool is that? Mad props to the guy who designed that system. The insanely high level of analog integration on this CPU — it pulls in the audio codec, power regulators, speaker amplifier, USB PHY, video DAC, battery charger and more — is one of the key things that has allowed me to create a system that you can buy at an affordable price.

If you’ve seen any of the chumby classic boards, you’ll instantly recognize that there are also mounting holes and features so this board can be retrofitted back into a chumby classic. That’s very intentional, although chumby doesn’t currently have a schedule to put this into a chumby classic; the classic line costs a lot to produce for more reasons than the PCB (think hand-stitched Italian leather). There’s also a couple of technical issues with integration, the most significant being the brutal thermal environment inside the chumby classic: the CPU contains the battery charging circuitry, and unlike the main supply, the charger circuit is a linear regulator so when charging it puts out a lot of heat. This is why we added a heatsink to the CPU, so we could charge the battery at maximum rate without having to throttle the CPU’s activity. I’m not quite sure how I would solve this problem if I were to put the board into a chumby classic, since there are no cooling holes in the device. I also get the sense that there wouldn’t be very much interest in a chumby classic that was a little bit cheaper, but still lacking the much-requested rechargeable battery: I am stuck between a rock and a hard place. However, the initial reactions to the battery in the chumby One are an interesting study in consumer psychology. For some reason, even though the chumby One is smaller and lighter than the chumby classic, and does largely exactly the same things, people don’t feel like it should have a rechargeable battery; they have no intrinsic desire to pick up the chumby One and carry it around. Just goes to show how much form influences a consumer’s perception of function. Also, as a very important note to intrepid hackers who want to try to retrofit one of these boards into their chumby classic: even though the footprint is identical, the chumbilical is absolutely not compatible with the chumby classic. For one thing, the chumby classic gets 12V from the chumbilical, and this device expects 5V. So if you were to just solder on a header and plug it into a chumby classic housing, you would get quite a cloud of smoke out of the device!

Also, as a little game for the readers, I will award a chumby One as a prize to the first person who can most accurately guess the number of vias on the chumby One circuit board based on the photos in this post. It’s a bit like one of those competitions where if you can guess the number of jellybeans in a jar you get the jar of jellybeans. This is vias not counting through-hole pads. Since the gerbers aren’t posted yet, you can’t cheat and use a CAD program to count the number of vias. :-) I’ll end the contest once the gerbers are posted, in about a week or so.

Name that Ware November 2009

November 12th, 2009

The ware for November 2009 is shown below. Click on the image for a much larger version.

This is from a brilliant little device that I’m thoroughly enjoying right now. Well-designed, and surprisingly addictive. First person to guess this correctly gets a chumby One as a prize.

As a reminder, if you want to enter a tentative guess without letting everyone else know, you can post an md5sum or a sha1sum of your guess string, and then post the source text for your hash in about a week — but remember to do that, because if you just leave a hash and fail to post your source text, I can’t judge your entry and the prize might go to someone else!

Winner, Name That Ware October 2009

November 12th, 2009

The winner for October 2009’s ware is insidetronics. All I can say is, dang, I don’t know how people managed to figure out where this one came from, but the web links you posted to photos of the assembled boards convinced me. If you do get a chance, please share with us how you knew or discovered the answer.

Very impressive! congrats, email to claim your prize!

Advice on Reliable SSD Chipset?

November 9th, 2009

I spent the weekend transferring my data and applications to a new Crucial 256 GB M225 SSD, and after about 10 hours of operation, the hard drive simply failed. It failed while “hot” even — the hard drive lite jammed on, my MP3 stopped playing, and the system froze up — like my worst nightmare come true. How is this possible? It’s supposed to be solid state. It’s supposed to have greater than 1,000,000 hours MTBF. Yet, it’s true. No matter what laptop I put it into, I now simply get this on boot:

2100: HDD0 (Hard disk drive) initialization error (1).

The drive isn’t 100% dead per se. There is a little switch on the drive that puts it into configuration mode, and it will identify itself as a Yatapdong Barefoot device (instead of a Crucial device) in this mode. So presumably, the embedded controller is still alive and kicking, but even in this mode I can’t seem to reflash the drive’s firmware or re-initialize it to a state where the normal mode is functional. When I switch it back out of configuration mode, the BIOS refuses to enumerate the drive, and without enumeration I can’t even run a diagnostic on the device. It’s definitely not an OS issue — BIOS-level diagnostics simply refuse to recognize the drive.

Searching around in the Crucial Forum, it seems these drives “have a high failure rate”. So much for a million-hour MTBF. I’m not sure exactly what’s causing it, because it is entirely solid state, and the SMT process used to build these drives are a very robust and well-proven technology. My guess is it’s got something to do with the firmware or the controller chip; they already have three firmware releases out for this drive, and disturbingly you can reflash these from inside the native OS — seems like a great candidate method for deeply embedding malware into a PC. Well, hopefully I can just return this drive for a full refund, since it failed so quickly.

At any rate, I’m wondering if anyone can give some advice on a good, reliable brand of SSD to use. The few hours I did spend with the SSD were quite positive; the performance boost is excellent, and a large number of my common work applications greatly benefited from the extremely fast access times. I’m still a bit spooked by the idea that these drives can fail so easily, but then again, fundamentally if I were in a jam I am equipped with the tools to recover the data — these devices use simple TSOP flash memory, so I suppose in the worst case I could dump the ROMs. Fortunately this one failed young, so the quickest solution is to just return for a refund and try something else.

Poking around a bit on-line, it seems that this Crucial drive uses the same Indilinx controller and firmware as the OCZ Vertex, the Patriot Torx, and the Corsair Extreme series (based on the “Yatapdong Barefoot” ID in configuration mode). On Amazon.com, I can see other users are experiencing exactly the same issue with a Corsair Extreme Indilinx series device. So I think it’s safe to say I’d like to steer clear of a solution based on the Indilinx chipset, at least until this issue is patched — ironically, the Indilinx website’s motto is “Beyond the Spin” (who are these guys, Fox News?), but it seems to me like their website’s got a lot more spin than substance. A link to a datasheet or firmware spec would be nicer than the marketing fluff.

Thanks in advance for the advice!

Mythbusting Personalized Genomics

October 11th, 2009

It’s the year 2009, and I’m wondering: where is my flying car? After all, Hollywood reels from the 60’s and 70’s all predicted that flying cars are what I’d be using to get around town these days. Of course, automotive technology isn’t the only victim of Hollywood hype. The potential impact of personalized genomics has been greatly overstated in movies like GATTACA. This has lead to the pervasive myth that your genome is like a crystal ball, and somehow your fate is predestined by your genetic programming. Recently, my perlfriend co-authored a paper in Nature (“A Personalized Medicine Research Agenda”, Nature Vol 461, October 8 2009), comparing Navigenics’ and 23andMe’s “Direct to Consumer” (DTC) personal genomics offerings. She’s qualified to offer deep insight into personal genomics, since she designed the original Illumina bead chip used by leading companies to generate their DTC genetic data, and she is also the person who made sense of the first complete diploid human genome sequence (1 2). She’s sort of the biology equivalent of the reverse engineer who takes binary sequences and annotates meaning into the disassembled binary sequences. So, let the mythbusting begin.

Myth: having your genome read is like hex-dumping the ROM of your computer. Many people (I was one of them) have the impression that “reading your genome” means that at the end of the day someone has a record of all the base pairs of DNA in my genome. This is called a “full sequence”. In reality, full sequencing is still cost-prohibitive, and instead a technique called “genotyping” is used. Here, a selective diff is done between your genome and a “reference” human genome, or in other words, your genome is simply sampled in potentially interesting spots for single-point mutations called Single Nucleotide Polymorphisms (SNPs, pronounced “snips”). In the end, about 1 in 3000 base pairs are actually sampled in this process. Thus, the result of a personalized genomic screen is not your entire sequence, but a subset of potentially interesting mutations compared against a reference genome. This naturally leads to two questions: first, how do you choose the “interesting subset” of SNPs to sample? And second, how do we know the reference genome is an accurate comparison point? This sets us up to bust another two myths.

Myth: We know which mutations predict disease. Herein lies a subtle point. Many of the mutations are simply correlative with disease, but not proven to be predictive or causal with disease. The truth is that we really don’t understand why many genetic diseases happen. For poorly understood diseases (which is still most of them), all we can say is that people who have a particular disease tend to have a certain pattern of SNP mutations. It’s important not to confuse causality with correlation. Doing so might lead you to conclude, for example, that diet coke makes you fat, because diet coke is often consumed by people who are overweight.

Thus, there are two echelons of understanding that can come from a genotype: disease correlations, and disease causes. The majority of SNP mutation-based “predictions” are correlative, not causative. As a result, a genotype should not be considered a “crystal ball” for predicting your disease future; rather, it is closer to a “Rorschach blot” that we have to squint and stare at for a while before we can make a statement about what it means. The table below from the paper illustrates how varied disease predictions can be as a result of these disagreements on the interpretation of mutation meanings.

Myth: the “reference genome” is accurate reference. The term “reference genome” alone should tip you off on a problem: it implies there is such a thing as “reference people”. Ultimately, just a handful of individuals were sequenced to create today’s reference genome, and most of them are of European ancestry. As time goes on and more full sequence genetic data is collected, the reference genome wlll be merged and massaged to present a more accurate picture of the overall human race, but for now it’s important to remember that a genotype study is a diff against a source repository of questionable universal validity, partially because it’s questionable if there is such a thing as a “reference human”, i.e. there are structural variations and some SNPs have different frequencies in different populations (e.g. the base “A” could dominate in a European population, but at that same position, the base “G” could dominate in an African population). It’s also important to keep in mind that the “reference genome” has an aggregate error rate of about 1 error every 10,000 base pairs, although to be fair the process of discovering a disease variant usually cleans up any errors in the reference genome for the relevant sequence regions.

So now you can see that in fact “reading your genome” is less of looking into a crystal ball and more of staring at a Rorschach blot obscured by cheesecloth (i.e., the genome is simply sampled and not sequenced). And, even if we could remove the cheesecloth and sequence the genome such that we knew every base pair, it would still be … a Rorschach blot, but in high resolution. It will be decades until we have a full understanding of what all the sequences mean, and even then it’s unclear if they are truly predictive.

Here lies perhaps the most important message, and a point I cannot make fine enough: in most situations, environment has as much, perhaps even more, to do with whom you are, what you become, and what diseases you may develop than your genes. If there is any upside to personal genomics, it won’t be due to crystal ball predictions. It will be the lifestyle changes it can encourage. If there’s one thing I’ve learned from dating a preeminent bioinformaticist, it’s that no matter your genetic makeup, most common diseases can be prevented with proper diet and exercise.