Name that Ware March 2012

March 27th, 2012

The Ware for March 2012 is shown below.

Been on the road in China this past month, so I snapped this one with my camera while on the go!

Winner, Name that Ware February 2012

March 27th, 2012

The winner of Name that Ware February 2012 is mangel, for correctly guessing the ware as a BBN Safekeyper box, CP1 Series, c. late 1992. Congrats, and email me for your prize!

Thanks again to Ben for contributing this rare look inside such an interesting box!

MicroSD card FAQ

March 23rd, 2012

A while back I wrote an analysis of fake microSD cards. As a result of the post, I’ve received this question regularly via email:

“I’m trying to buy a thousand microSD cards for my embedded controller project. How do you qualify a microSD card?”

So, I thought it might be helpful to share my answer here.

There’s this awkward phase between the weekend project (where you buy your microSD card from Best Buy for $20 and have a no-questions return policy) and being Nokia (where you buy the same cards for $2 in quantities large enough to actually have leverage over vendors). When you source a few thousand cards at a time on the wholesale spot market, you’re basically on your own to control quality.

As far as process control, some vendors are easier to work with than others. Samsung will bump their part numbers based on die revs or other significant internal changes to the card. Sandisk, on the other hand, uses a very short part number for their cards, so you have no idea if the NAND on the inside is MLC or TLC, etc.; you just know the capacity and the card is simply guaranteed to perform to spec. To wit, Sandisk is very thorough about ensuring they meet the spec. However, it’s the edge cases that usually bite you in production; regardless of the spec, every die/controller combo has some character and your embedded controller may bring out some of that color. And, of course, there’s the fakes — Sandisk is a huge target for fakes, people who want to borrow their good name to sell you a batch of shoddy cards.

If you’re working with a distributor, get a copy of their authorization letter that certifies the relationship with the brand they are selling. It’s easy to fake the certificate, but it’s a good formality to pursue anyways. If you can, get the upstream brand to confirm the distribution relationship.

Aside from these supply-chain side things, here’s a check-list of technical tests to run on your cards:

For each new distributor:

1. I read out the CID and CSD registers and decode them. This is easy to do on linux with a directly connected microSD card. You cannot do this if the card is plugged into a USB adapter — you need to have the card plugged into a direct SD interface. The CID and CSD should look “right” i.e., the manufacturer ID should make sense (unfortunately the manufacture ID codes are all secret, but I can assure you it’s not supposed to be FF or 00), serial numbers should be some big number, date codes correct, etc.

2. Do a “full write” test at least once. i.e., create a random block of data that’s the putative size of the card, and dd it into the card. Then, do an md5sum of the contents of the card. This will identify loopback tricks that fake capacity. This is a relatively common trick that is surprisingly hard to detect, because many cards are only used to less than 50% capacity in real life.

3. Do a reboot test, to understand the behavior of the controller/die combo during ungraceful powerdown. It’s less important on systems that can never have their battery removed.

Before the test, I do a recursive find piped to md5sum to get a full map of all the files in the card. Then, I use a script that writes a random amount of /dev/urandom data in odd-sized blocks (ranging from a couple hundred bytes to a couple megabytes) to the card and then calls sync, in a constant loop after boot. For each block written, the md5sum is recorded. At boot time, all old blocks are checked for md5sum consistency and then deleted. The system under test is automatically power cycled by cutting the AC power about once very 2-3 minutes plus some random interval (depends on how long it takes your device to boot). I cut on the AC power side to capture the effects of the power decay curve of the wall adapter; the logic goes that a clean power down is less likely to cause problems than a gradual powerdown. I run the test on a cohort of at least 2 systems for 2 days straight. If you want to get fancy, you have the system upload its statistics to a server so you can see exactly when it starts to fail. After a couple of days, I extract the card from the system and redo the recursive find with md5sum to verify that no non-critical files have been corrupted that would be difficult to notice without the comprehensive check. Be sure, of course, to ignore files that naturally vary.

I still don’t have a straight answer on why some cards perform better under this test and others fail miserably. Ultimately, however, every card I’ve encountered eventually corrupts the filesystem after enough cycles, it’s just a matter of how long. I feel comfortable if I can reliably get to ten thousand ungraceful reboots-while-writing before failure. Note that supposedly eMMC has design features that harden cards against these problems, but I’ve never had the luxury of building such high volume systems that eMMC becomes an affordable option. Besides, I consider giving users the ability to remove the firmware card and reflash it with new code using a common USB adapter an important feature, at least in the systems I design. Mobile phone carriers would think differently.

Of course, once a vendor is qualified, they can still send you bad lots.

For each new lot I get, I take a few cards and burn them myself and check they boot the system before handing them over the factory. I also manually inspect the CID/CSD to ensure that the manufacturer’s IDs haven’t rotated and I inspect the laser markings to ensure that the lot number changes (it should — if it doesn’t then they are pulling something wonky on you). I also compare the circuit trace pattern on the back, visible through the reliefs in the solder resist coating. If you have easy access to an X-ray machine (some CMs have them on site) you can go so far as to compare the internal construction in the x-ray to see if the dies have been revved. If all these are the same you’re probably good to go on the new lot, but I do pay attention to the failure rate data in the first couple hours of production just to make sure there isn’t something to worry about.

There’s probably a bunch of other tests, techniques and good ideas that I should be aware of…look forward to reading the comments!

China: Crowdsourced Tax Enforcement

March 22nd, 2012

Riddle me this: how does a government enforce tax collection in a cash-only society? Cash has the wonderful property of being anonymous, and therefore hard to track. As a result, cash businesses often under-report revenues, thereby dodging a portion of tax payments.

China is primarily a cash-driven economy; few local places will accept payment cards of any kind (event rent payments are made in cash — a big, fat stack of cash, as the largest bill in China has an equivalent value of about US$15). As such, China has a big challenge around collecting taxes.

A solution to the problem is to go with a tax pre-payment system. At the beginning of every month, every business is required to pay an estimated tax. Proof of tax payment is issued in the form of “fapiao” (发票). They look a bit like the one below:

This fapiao represents tax paid on 10元 (元 is like the $ symbol, and colloquially pronounced “kuai”), so the restaurant I got this from probably paid about 1-2 kuai for this fapiao. When you settle your bill in a restaurant, in addition to getting the itemized receipt, you are supposed to receive a stack of fapiao of equivalent face value.

At the end of the month, the restaurant claims a tax refund on any remaining fapiao. As a result, fapiao are basically as good as money to the restaurant; hence, the fapiao are printed on watermarked paper with anti-counterfeiting measures, and employ serial numbers you can validate by sending an SMS to a government hotline. Also, restaurants have a strong incentive to omit a few fapiao from your stack, or completely forgo giving you the fapiao (they love it when foreigners dine, because they don’t know about fapiao — they get big business and they get the tax refund on it!).

So, how does one enforce the distribution of fapiao to customers? China’s clever solution is to make every fapiao a lottery ticket. If you look at the above photo carefully, you’ll see two metallized patches on the fapiao. You can scratch these off, and underneath might reveal a prize! Of course, the one I have above is a losing ticket — it just says “thank you”, with a serial number; but the prize can be thousands of kuai.

And so, China has crowdsourced tax enforcement, by potentially rewarding citizens with a cash reward for asking for all of their tax pre-payment receipts, and using them up by scratching off the prize areas. The cost of this massive force multiplier is vanishingly small, as all they are offering is the chance to win; I have only ever seen one winning ticket in the past couple of years, and it was for about 2 kuai. Still, it is a nice cultural touch to the end of a big meal, everyone sitting in a circle, scratching their fapiao to see if they won a prize for playing the part of a Chinese tax enforcement agent.

Of course, with every new system, new problems come in. One is that the waitstaff might nick a couple of fapiao en route to the customer. So now, to get your fapiao you usually have to go in person to a special counter that manages its distribution. And, of course, the restaurant can offer a bribe in place of the fapiao. Just this past month when I was visiting Harbin, I went to collect my lottery tickets and the lady at the register glanced at my 80 kuai receipt and offered to pay me 4 kuai instead of giving me fapiao! I was a bit surprised at how brazen the offer was, but in retrospect, I clearly was not from around there, and thus unlikely to be an auditor.

Safecast Geiger Counter Reference Design

March 15th, 2012

This past weekend marked the anniversary of the Tohoku-Oki earthquake that devastated Japan. I had not felt my blood so cold since I watched the twin towers fall almost a decade earlier. I still vividly remember the twisting knots I felt in my stomach as I watched the footage of a tsunami wiping out huge swathes of Japanese countryside. In a matter of hours, entire cities were washed off the map, leaving an eerie post-apocalyptic landscape of a few survivors weeping amongst twisted wreckage. Then, in the ensuing days, Fukushima Daiichi melted down, leaving in its wake one of the worst on-going radiation contamination crisis since Chernobyl.

I have good friends in Japan, and I visit often. I wanted to do something to help, but I didn’t know what I could do. I was connected by Joi Ito to Safecast, and I joined the effort to build an open sensor network that could aggregate trustable, source-neutral radiation monitoring data. Safecast itself has many talented and hard working volunteers who have done a remarkable job of achieving their goals by instrumenting Japan with radiation monitors and aggregating data through cleverly designed and rapidly deployable mobile monitoring capabilities.

I decided my tiny contribution to the effort would be to design a radiation monitor suitable for everyday civilian use. This is a preventative/preparedness measure, addressing the long-term issue of empowering a civilian population with few available options for power generation to self-monitor their environment. The problem with the current crop of radiation monitors is that they are basically laboratory instruments: accurate & reliable, but bulky, expensive, and difficult to use, requiring a degree in nuclear physics to understand exactly what the readings meant. Another problem with crises like these is that while radiation monitoring is important, it’s something that is typically neglected by the civilian population until it is too late.

Therefore, the challenge set out before me was to design a new Geiger counter that was not only more intuitive and easier to use than the current crop, but was also sufficiently stylish so that civilians would feel natural carrying it around on a daily basis. Furthermore, it had to provide extensive logging capabilities, as radiation monitors are typically not turned “on” until after the fact. It also had to operate effectively in catastrophic conditions, i.e. in scenarios where internet and power have been cut for days. Finally, the data collected by the instrument had to pass any scrutiny thrown its way, and the collected data had to be traceable to a given instrument so that if its calibration is incorrect, its data can be selectively excluded without poisoning the entire dataset. Radiation monitoring is a politically sensitive subject, and certain parties have interests to manipulate the data one way or the other to promote their views with the public. Ad-hoc data collection networks suffer from the possibility that their efforts can be discredited by institutions with big budgets who find that the readings represent an inconvenient truth.

Radiation sensing primer

Radiation measurements are subtle, partly because radiation comes in many flavors. Many Geiger counters can only efficiently detect the most energetic kind of radiation, gamma radiation. This includes the Geiger counters frequently favored by government and regulatory agencies. However, there are weaker forms of radiation (alpha and beta) which often go overlooked that can also pose a human health risk, particularly if they are ingested or inhaled. These weaker forms of radiation are also by-products of a nuclear meltdown, and because they come from different isotopes they have different patterns of distribution and absorption in the environment.

Because of the diversity of radiation sources and their varying biological impact, it is very hard to determine if an environment is safe in the face of an elevated Geiger counter reading. However, improved historical and spatial distribution records of background radiation measurements can help identify when there is a spike in radiation, which is a clearer cause for concern.

In the interest of creating a complete solution for public health needs, a core design requirement of the new Geiger counter is to incorporate a sensor that could detect all three forms of radiation. This type of sensor is a “pancake” style Geiger tube, which has a large mica window that enables sensitivity to all three kinds of radiation. The ultimate selection of the LND7317 pancake tube plus iRover HV radiation sensing core influenced every aspect of the industrial design (ID) and internal electronics.

There and Back Again: a Hacker’s Tale

I thought it would be interesting to share not only the final design, but also the intermediate designs that were scrapped en route to achieving a final design. Design is an iterative process, where one has to make difficult choices about what to include and more significantly what to leave out. It’s extremely rare to see what got left on the cutting room floor, but I saved my notes along the way so I could share them with you now.

Initial Design Sketch

Above is a rendering of the first design sketch, made back when Safecast had the name of “RDTN”. I do all my industrial design using Solidworks, a survival skill I picked up during my tenure at chumby designing consumer electronics. I came up with this in the first couple of weeks after the disaster. This design incorporated a low-sensitivity tube from Sparkfun, because at that time I did not understand the importance of using a pancake tube.

The biggest problem I wanted to solve with this design is user abandonment. Radiation leaks are thankfully rare events. However, this also means that when an event happens, there is typically a lack of pre-crisis background data against which to compare the post-crisis readings. Therefore, I wanted to build a device that people would be compelled to carry around every day and use for years at a time.

My thought is that the average consumer would have a hard time justifying carrying around yet another gadget in their pockets or purses for the sole purpose of measuring radiation. Within weeks or even days of getting nothing but “safe” readings, the Geiger counter would be forgotten and left at home to languish until after the next crisis.

One way to compel users to carry around a Geiger counter is to put it into something they already carry all the time. While it would be tough to convince a smartphone vendor to incorporate a very expensive and bulky Geiger tube, many smartphone users also carry around a spare battery pack, which they use almost every day. So, I thought it might be a good idea to trojan horse a Geiger tube into such a battery pack.

The sketch above demonstrates such an incarnation. This design is basically a battery pack that can charge a smartphone, but also incorporates a Geiger tube, an LED flashlight (handy in an emergency when there is no power), and some logging circuitry. The Geiger counter would upload its log data to the Safecast network whenever a user plugged in to charge the phone.

The design itself is minimalist, with a shape inspired by the steam cooling towers frequently used to iconify nuclear power in western media. The shape was chosen to remind us that sometimes we have no choice but to harvest the power of the atom, and a well-equipped and informed civilian data collection network is a key factor in trusting the safety of our power sources.

A second iteration

The first sketch had to be abandoned, primarily because the sensor it was designed around was too small to effectively measure alpha and beta radiation. After Safecast settled on the LND7317 Geiger tube as the standard reference sensor, I started re-designing the sensor around the new tube.

The problem with the larger, more sensitive sensor is that it was big – over a half-inch thick, and a couple inches in diameter. Below is a sketch of a design study aimed at creating the smallest possible Geiger counter that could also incorporate the large pancake tube. It’s about the size of a hockey puck, but a bit thicker. In order to keep the size and weight of the Geiger counter reasonable, I had to abandon any notion of a dual-purpose as a battery pack. Instead, I had to rely on “sex appeal” alone to compel users to carry the device around. I wanted to make the Geiger counter something unique and aesthetically pleasing, something you would enjoy carrying around frequently. I started from a minimalist design – the puck – and endeavored to design-out any outward indicators or displays. Hence in this sketch, the radiation measurement is provided by a set of super-high efficiency 7-segment LEDs that could shine the numbers through a seemingly opaque white shell. The design’s shape and feel was meant to be somewhere in between “Eve” from WALL-E and an egg.

Unfortunately, this design, too, had to be abandoned because at the time when I was drawing up the sketches, I didn’t have detailed mechanical drawings of the LND7317 tube. When I was finally given a sample of the tube and drawings for it, I discovered there was not only the puck-like body, but also a nearly 1″ long protrusion for the cathode and anode. This completely destroyed any notion of building a puck-like sensor.

Closing in on the final design

Below is a rendering of an attempt to accommodate the accurate CAD model for the LND7317 into an ID that stayed faithful to the Eve/egg design inspirations. The puck was elongated to the minimum dimensions required to house all the internal components. Again, the hidden 7-segment LED display motif was employed.

The final design

After much discussion and review with the Safecast team, we decided that a key component of the user experience should be a graphic display, instead of a 7-segment LED readout. Therefore, a 128×128 pixel OLED panel was incorporated into the design. The OLED panel would be mounted behind a continuous outer shell, so there would be no seams or outward design features resulting from the introduction of the OLED. However, as the OLED is not bright enough to shine through an opaque white plastic exterior shell, a clear window had to be provided for the OLED. As a result, the naturally black color of the OLED caused the preferred color scheme of the exterior case to go from light colors to dark colors. User interaction would occur through a captouch button array hidden behind the same shell, with perhaps silkscreen outlines to provide hints as to where the buttons were underneath the shell. I had originally resisted the idea of using the OLED because it’s very expensive, but once I saw how much an LND7317 tube would cost in volume, I realized that it would be silly to not add a premium feature like an OLED. Due to the sensor alone, the retail price of the device would be in the hundreds of dollars; so adding an OLED display would help make the device “feel” a lot more valuable than a 7-segment LED display, even though the OLED’s presence is largely irrelevant to the core function of the apparatus.

The design also lacks any integrated radio connection. A popular request for the design was the incorporation of a bluetooth or zigbee style radio; however, a combination of a very stringent battery life goal (several months of standby time) and low manufacturing volumes meant that it was impractical to incorporate a radio into the device. It’s a slippery slope to start adding features like GPS and bluetooth – to add those features, you’d need to upgrade the microcontroller, at which point you’re basically building a very expensive, heavy and large cell phone with a geiger counter in it. Furthermore, the entire development effort was being done by an unpaid volunteer operating on a shoestring budget – Safecast isn’t Apple. So, rather than build a buggy cell phone that can sense radiation, I’d rather build an outstanding Geiger counter; hence the decision to focus efforts and resources on core functionality, with the sole allowance being the inclusion of the OLED + captouch array for improved UI. This is a controversial design decision and I fully expect to be chastised for it.

The Prototypes

Once the design was finished, the next step was to build prototypes. This is the really fun part, where you turn your ideas into something you can touch and hold.

The prototypes are made out of CNC-machined ABS (even the clear part!). The cosmetic moldings that go over the connectors were also built and they do fit, but because of their expense and fragility (CNC milled ABS lacks the robustness of injection-molded ABS), I try not to install them, even for glamor shots. To wit, the whole thing was done on a shoestring budget, as Safecast is a non-profit; two full prototypes were built, including PCB fab, assembly, and CNC milling for one and a half revisions of the cases, for a bit under $3k total.

An important point readers should note about this design is that I’m not manufacturing this Geiger counter reference design. My contribution is limited to design IP only. Practically speaking, I’d make a terrible Geiger counter supplier, because I don’t have the credibility or history in the industry. Instead, the design has been donated to the community, thereby enabling International Medcom, a business that has spent decades specialized in producing high-quality Geiger counters, to bring this to the market. If you’re interested in getting one of these, keep an eye on their website.

The final design features include:

  • LND7317 pancake tube + iRover HV board
  • STM32-based microcontroller; sufficient CPU power to digitally sign logs with a unique private key as a non-repudiation/anti-tamper measure
  • 450 mAh Li-poly battery
  • 3-axis accelerometer so sensor orientation can be recorded
  • 128×128 color OLED display
  • 6-button captouch array
  • “hold” button on the back to lock the captouch array and prevent false triggering of the power-hungry UI elements
  • lanyard attachment (important for the Japanese market)
  • microUSB port for charging and data upload interface, featuring an FTDI-based serial chipset capable of loading firmware into the microcontroller
  • 3.5mm jack capable of bidirectional audio
  • embedded hall-effect sensor (to detect attachments, e.g. for occluding alpha or beta radiation)
  • audible event notification via piezo buzzer
  • low-power visual event notification via conventional LED
  • real-time clock
  • a high-quality entropy source ;-)
  • I am a proponent of open source hardware; so here’s the source files for my design! All of the following source files are licensed under CC3.0-BY-SA with my XL1.0 automatic patent cross-license rider (CC doesn’t address patents, so I invented my own rider that piggybacks on CC to ensure that any patents that may arise from this or its derivatives are automatically cross-licensed to the community).

  • Altium design source / schematics / gerbers / BOM for the mainboard electronics
  • Altium design source / schematics / gerbers / BOM for the buttonboard electronics
  • Solidworks design source / IGES / STEP for the industrial design
  • For those who don’t have 3D design tools, you can install Solidwork’s free e-drawings viewer and look at the easm file, or if you run windows you can download this executable and just run it
  • Of course, a hardware prototype is only the beginning – there’s a huge amount of effort remaining on the software. To bootstrap things, xobs and I have coded up a core demonstration system based on Leaf Lab’s libmaple. You can peruse the code and/or download it at github. Basically, this demo system provides an architecture to easily register drivers and facilitate power management. The validation demo shown running on the prototype photos above indicate that all of the hardware features work. But, the software has yet to have a layer of polish and shine added in terms of the UI and power management optimization.

    A key design goal electronics’ system design was to enable community participation. As such, I eschewed the use of JTAG adapters during development. Instead, hooks were provided in the hardware to enable the integrated FTDI USB-serial controller to flash the microcontroller’s firmware via a “bitbang” interface. As a result, anyone who has an interest in developing for this Geiger counter can simply plug it into their laptop’s USB port and start coding without any need for proprietary JTAG adapters or proprietary software to purchase, as the entire developer’s toolchain is available in source form. We were able to code up and test the entire functionality demo (including sleep/stop/standby power management) using nothing more than the USB-serial capability built into the design. As I write this, I realize I had neglected to upload the firmware loader to github, so here’s a tarball for it; currently, the loader only runs under Linux and OSX.

    I think there’s some fun things the community could do with the UI on a Geiger counter. At the very least, the microcontroller has sufficient power to play Tetris. Another whimsical thought was to build a subsystem that would play music out the audio port based upon the current radiation level — calm, ambient music in low-radiation environments escalating to death metal and the sound track of “Run Lola Run” at dangerous levels.

    So that’s it! I hope that the design ultimately helps the people of Japan – or people anywhere in the world where radiation contamination may be a concern – to feel more empowered and in control of their situation.