Getting Itty Bitty With The Ice Breaker 2.0

Dusted off and polished an old idea to get it ready for prime time!

Background

About eighteen months ago (jesus, was it really that long?), I made the "Ice Breaker", a small persistence of vision toy worn on the hand that displays "HELLO" or "GOODBYE" when waved back and forth.  It contained a "ghetto" accelerometer that determined the frequency and phase of the user's hand motion and drew apparently stationary text on the forward swing.

Before the QR Clock, I was planning on turning this into the first commercial Ch00ftech product.  It's a super small and relatively low-risk circuit (unlike the clock), which makes it great for the purpose.  I figured that with some clever engineering, I could get the bill of materials costs down to a minimum and improve the functionality while I'm at it.

Still not sure if I want to go through all the work of selling this thing since I'm still nursing my wounds from the QR clock experiment, but I thought designing it for such a purpose posed an interesting challenge.

Who knows, if the demand is high enough, I might make a small run.

Accelerometer

The original Ice Breaker had a number of features that would make it very expensive to manufacture.  The biggest problem was the ghetto accelerometer.  Taking a tip from a similar device that I reverse engineered, I built my "accelerometer" using a drinking straw, a wad of paper, and an infra-red proximity sensor:

The idea was that when the wad of paper passed in front of the sensor, it would send a pulse back to the micro controller that would indicate that the user had reached the beginning or the end of a wave.

This whole system utilized the inherent properties of a mass inside a tube to function.  The wad of paper only moved when the retrograde acceleration was large enough to overcome friction.  It's actually super convenient because it works out that the paper only moved at the absolute edges of the waving motion.

This solution is much cheaper than an accelerometer when you have access to the tools required to mass produce a plastic housing, but I'm not going to make thousands of these if I end up cutting up and gluing drinking straws for each one.

I settled on a conventional accelerometer.  If you shop for accelerometers, you'll rapidly find that the market (phones) has dictated that they have to be tiny.  This basically rules out any sort of leaded package.  I chose the KXTC9-2050, a 2g, 3 axis accelerometer based on its capabilities and low price.  I only needed a single axis, but again, the demand for 3 axes is huge.

I wasn't sure how exactly this part would behave in the context of a waving motion, so I ended up building a small breakout board that would let me run some experiments.  The part is a "Land Grid Array" (LGA) package which means that there are no leads and the solder points are on the bottom of the part; the pitch between pads is also very small (.65mm).

I was impressed with how fine I managed to make the contacts on the breakout board:

It's gotten to the point where I'm pretty sure I can do anything with my current fab methods...

In the absence of a hot-air gun at home, I originally tried to assemble this thing using a blow torch attachment for my butane soldering iron and managed to COMPLETELY screw it up.  A second attempt using a hot air gun at work got me this:

The accelerometer puts out an analog voltage that's centered at around 1.65V and goes up and down for positive and negative acceleration.  I hooked the thing up to an oscilloscope and took a video of me waving it around.  Video analysis seemed to show that the output was at an extreme during the beginning and end of each motion:

This was good news for my application.  By detecting the maximum and minimum of each motion, I would be able to determine the exact starting and ending points.

I also discovered another cool feature of the accelerometer.  It seemed that no matter how low the input voltage got, the minimum output voltage stayed at a constant .7V (no doubt because of some kind of diode situation going on inside):

This was good because all I would need to do is look for times when the accelerometer's voltage dropped below around .75V to  locate the beginning of each cycle.

Satisfied, I moved on to the rest of the circuit.

On the Cheap

There really wasn't a whole lot of space for lowering the cost of the original circuit.  After all, it was just 8 LEDs and a micro controller.  Even ditching the drinking straw left me with a replacement $3 accelerometer.  The only spot I saw room for improvement was with the switch.

A lot of people don't realize this, but it's not very uncommon to see physical interface items like switches and plugs dominate the pricing of a BOM.  The double pole triple throw switch that I used for the original design which acted as both the power and mode switch cost a whopping $1.33 which places it a good $.20 above the microcontroller which...y'know...actually has the millions of transistors and does all the magic.

I replaced it with a simple tactile switch that lopped a good dollar off the price of the original.  Unlike the original switch, I wasn't able to route power directly through this one, so I opted to use the technique I developed for my Longboard Display which involves sleeping the circuit when it's not in use and waking it up from a button press.

One other area where I was concerned about manufacturing costs was the actual mechanism that holds the device on the user's finger.  I ended up opting for two simple pieces of wire creating a finger loop.

I was originally planning on using some kind of thread, so I wasn't too worried about the solder properties of my holes.  These holes doubled as ground plane vias, and they were printed with no thermals.  Thermals are the little gaps around solder points that help slow the flow of heat away from the solder pad.  Without them, it's often too hard to heat up a pad hot enough to melt solder.

I had no trouble melting the solder when adding the wire, but removing the solder that plugged the holes after the wire inevitably broke almost destroyed the entire circuit.  After about half an hour with an iron, solder wick, a hot air gun, and tweezers, I was able to remove it.  For the next round, I chose to stick the wire through and blob some solder on the end to act as a plug to keep the wire in place without soldering it to the PCB:

If I were to sell these, I'd probably leave it up to the end users to find a way to attach it to their fingers.  I might widen the holes a bit to help them.

Tiny

I wanted this device to be something small enough to put on a keychain and keep with you at all times.  Because of this, I opted to not even try to suffer through hand crafting the tiny vias required to make something so small and instead got the boards made at my new favorite low-volume fab house seeedstudio:

In addition to shrinking the accelerometer down to a 3x3mm LGA package, I also chose a 4x4mm Micro Lead Frame (MLF) package for the microcontroller and even dropped the battery down to a CR2016 which is 8mm smaller than the CR2032 I used before.

Without access to a hot air gun at home, soldering the microcontroller and accelerometer wasn't trivial.  I've done reflow soldering before, but this time, I couldn't find a solder stencil for the packages I was using.  I read somewhere online that reflow soldering can be pretty forgiving, so I opted instead to just apply it by hand.

I purchased some "Chip Quik" solder paste:

And put a small amount on my PCB.  I used a toothpick to remove some of the paste between the traces:

And carefully placed my components on top:

Then I plunked the whole PCB down in a frying pan on the stove and heated it up until the solder flowed locking the chip in place:

Wow!  This gif is probably playing back slightly sped up, but in reality the whole process still only took about 10 seconds once it got started.  I made a big deal the last time I did this about getting the solder paste exactly right, but judging from my experience this time, I could have done much worse.

Now, It wasn't totally perfect.  I applied way too much paste which ended up creating a few shorts:

But they were quickly dispatched with a swift tap of a hot soldering iron:

I imagine the precision of a good solder stencil is very important when you're making hundreds or thousands of something, but I was excited to find that for small hobby projects, a toothpick and 5mL of paste will go a long way.

I imagine I could probably make it smaller still if I wanted to.  Replacing the current limiting resistors with a single resistor array and replacing the programming header with a smaller proprietary header could also shave off a few square millimeters.  Though anything smaller than the current design would likely require a smaller battery.

Still, I managed to shave the board area of the current design down to 65% of the original and that's not even counting the space taken up by the drinking straw!

Schematic

Unsurprisingly, the schematic is very simple, though there are a few notes I'd like to share.

R2 and R3 aren't meant to be stuffed at the same time.  It's always kind of disorienting trying to make sense of exactly how the output of an accelerometer will work.  Just take a look at this page from the datasheet:

Easy, right?

I figured that there was a fairly high chance that I'd mix up X and Y and mount the accelerometer at a 90 degree angle to where it needed to be, so I gave myself some options.  It's not like I'd be able to do rework on a part that hides its terminals underneath it.  As it turns out, R3 was the correct stuffing option.

R13 is used to hold the accelerometer in standby mode when it's not in use.  This drops its current consumption down to just 5\muA which when added to the 2\muA of the ATTiny gives me about 1.5 years of standby time on the 90mAh capacity of the CR2016.  This isn't quite as amazing as the 13.6 years of the longboard display, but considering it's powering more components with a smaller battery, it's still pretty impressive.

Everything else you've seen before on the original Ice Breaker.

User Interface

Curtailing the user interface to a single button presented an interesting challenge.  I wanted this device to go beyond the simple hello/goodbye of the original design and allow for user-programmable text.  Through some trial and error, I came up with the following program flow:

Might seem kind of confusing, but I think that it can be pretty intuitive once you have the device in your hand.

The device can store eight twelve-letter patterns which it indicates by lighting up one of the eight LEDs when it's at rest.  It could actually store a lot more than that, but I figured that most people would be displaying short messages anyway.  Besides, working the 8 LEDs into some mode that could indicate more than 8 patterns in a user friendly way is problematic.  Yes, I know what binary is, but a lot of people don't.

When first powered up, the device is populated with 8 standard messages.  I haven't decided what they should be yet, but of course "HELLO", "GOODBYE", "YES", and "NO" will be included.  If you have any more recommendations, let me know.

The user is then free to modify these messages by holding down the interface button to enter into edit mode.  In edit mode, pressing the button briefly will increment the currently selected letter and a longer hold will move to the next letter.

I was originally planning on programming functions for "double tap" and "triple tap", but I realized that they would interfere with the fact that the user is going to want to push the button as fast as possible to roll through the alphabet.  I even considered utilizing the accelerometer to have the user shake the device while holding the button down, but I quickly found that people have much more precision when pushing buttons than when shaking their hand.

The "cursor" is just a bar that replaces the current character every other cycle.  I went through a few different options such as having the letter disappear entirely every other cycle or inverting the letter's colors, but I found that this method was the most visible especially considering cases like selecting a blank space:

The cursor still isn't perfect though.  Depending on the lighting conditions, the users might wear themselves out just trying to figure out which letter they're editing.  This is why I included the "clear current pattern" function.  It's actually fairly easy (if time consuming) to enter an entire word without looking at the device if you keep everything straight in your head.  I figure that the user will just clear out the whole word at the first sign of trouble and start over rather than try to repair it.

Likewise, when editing a letter that's already filled, pressing the button once always changes it to "A" no matter what letter was there before.

Every time the user leaves edit mode, the current set of messages are stored to the nonvolatile EEPROM.  That way, if the device loses power, the custom messages are still preserved.  This is especially important considering how easy it is to short out the battery on anything metallic sharing the same pocket.

If the user really messes up the messages and wants to return them to the defaults, he just needs to remove the battery and hold down the button while replacing the battery.  This runs a special routine which reprograms the EEPROM to the default values stored in the program memory.

Firmware

I'm actually kind of proud of this firmware.  A lot of my projects end up with horribly disfigured spaghetti code, but this time I made a point of keeping things orderly from the start (I used my first #define!).  The framework is very similar to the original IceBreaker with a few exceptions.

When I first set out to use the accelerometer, I was really hoping to take advantage of the .7V low output of the accelerometer.  The ATTiny24 has an integrated 1.1V voltage reference that can be compared to an external voltage to generate an interrupt.  I was hoping that the .7V would be close enough to 1.1V to generate an interrupt very close to the end of the wave.  I wrote a quick routine to test this theory that generated a test pattern that included diagonal lines with vertical bars at the beginning and end:

Not even close...

I ditched the 1.1V voltage reference and fell back on a simple digital interrupt.  I noticed that the time between this interrupt and the end of the wave was more or less a constant percentage of the whole wave time.

I rounded this timeout off to the closest thing that I could calculate quickly:

timeout = (mastercount>>1)+(mastercount>>3);

This works out to roughly 5/8 of the total cycle time.

The most dramatic change to the new firmware is the editable text.  The original Ice Breaker had no text.  The text displayed was simply a pre-programmed image stored in program memory.  This image took up a substantial amount of space.  In order to compress the text small enough to fit in 128 bytes of EEPROM, I needed to create a font so that the image of the text could be reproduced every time it's needed.

Creating a font (and basic word processor) was a little more difficult than I was anticipating.  The original plan was to create a fixed-width font.  This would simplify some issues such as letter spacing when editing letters in the middle of a word.  Once I started drawing out my font though, I realized that this would be a major problem:

I couldn't think of a more efficient way to draw W or G which are 7 pixels wide.  Most of the  other letters are 6, but some like S and of course the punctuation marks are smaller.  Using a fixed width font would totally destroy my kerning as I'd need to have enough space for a W in every letter slot.

I ended up storing the font as three separate arrays.  The first array is simply the pixel values of each letter all crunched together.  If you removed all the spaces between the letters in the above picture and recorded the byte values of each column of pixels, you'd get this array.  The second array contains the starting position of each letter in the first array.  The third array contains the width of each letter.

To generate a letter, the code needs to grab the letter position from the second array, pull the pixel value from the first array, and then keep iterating the number of times indicated in the third array.  With this method, only the numerical value of each letter (A=1, B=2, etc) needs to be recorded.

The AVR framework only allows for program memory arrays to be 256 bytes long.  Fortunately, none of these arrays needed to be longer, but if more symbols were required, some more code would be needed to accommodate it.

It was only after I spent all the time doodling up this font that I thought of maybe looking online to see if anyone had already made an 8 bit font.  Turns out lots of people have, but I stuck with mine anyway.  I might tweak the X and Y a bit at some point...

Price

A quick tally on Digikey says that at a quantity of 500, the parts would cost around $5.93 including the battery.

The PCBs would be basically free.  They're slightly more complex than the QR clock PCB, but they're only 1.6% the size.  If I get them V-scored or tab routed and cut them apart myself, I might save a lot of money.

If I were to try to sell these, the most expensive part would probably be assembly.  After my very negative experience with Myro, I'm not exactly willing to dump a lot more money into foreign assembly houses unless I get a really solid recommendation.  Some quotes I found for domestic houses however put the assembly costs at around $8 a unit for quantities of over 1000.  Sort of demolishes my margin, doesn't it?

I'll keep poking around, but I really think a gadget like this has a good market if it's sold for $10-15.  Until I can get it down to that price and keep my profit margin, I think I'm going to just sit on it.

Might make for a fun experiment in extremely cheap toy production engineering.

Looking Forward

This project is sort of on the side burner at the moment.  I'm pretty proud of how polished the whole thing is, but at the end of the day, it's not super useful.  The "HELLO" and "GOODBYE" features are fun, but programming custom messages can be downright tedious, and at twelve letters a pop, nobody's going to be writing a soliloquy.

It was still a lot of fun though.  It's certainly the smallest circuit I've ever built, and I'm sure I could make it even smaller if I had the right batteries.  Solder paste is something I'll certainly be using in my future projects, and I want to try to start using smaller component packages to really cram stuff together.  Maybe even 4-layer boards?

If I were to sell them, I'd also need a better product name than "IceBreaker".  I've got a few prototypes lying around, best three product name suggestions in my inbox get a free prototype mailed to their door.


Project files can be found here: IceBreaker 2.02


14 thoughts on “Getting Itty Bitty With The Ice Breaker 2.0

  1. Please buy a hot-air station. You can get a 852D+ for under $100 on ebay these days. You seem like you really need one or you can get a model without a soldering iron, but i recommend that model, that is what i use and it works very nice.

  2. I really enjoy reading your project write-ups--thanks for taking the time to write them!

    Why do you want to change the name? FWIW I think IceBreaker is a reasonable name. :)

    Also, at least for an initial release I think you might be surprised by how much people would be prepared to pay for a "toy" like this. Like many of the hacker persuasion I'm a cheapskate but apparently not everybody is, so you might still be able to make this work at a higher price-point like $20. (Perhaps a Kickstarter..? :)

    • Well with the low cost of small PCBs like this from seeedstudio, it might be hard to sell these to hobbyists considering they have all the design files right here.

      If I were to sell them, it'd want to learn how to "do it right" with a custom enclosure and a super cheap low-quality PCB.

  3. Nice write-up! See a few things here that I can take away and learn from. Also I would be willing to pay for a kit for something like this too. Can never have to many LED toys.

    KG

  4. As always, I thoroughly enjoyed your write-up and learned a lot! Props! :)

    Just a thought. Seeing as you are already using an accelerometer which maxes out at 2g, couldn't you implement a tap-to-change letter system (left towards 'A' - right towards 'Z' to make it quicker and more intuitive. I know you thought about waving left and right to do it and surely the implementation would be the same?

    • Interesting idea. Determining a "tap" would require a little bit of signal analysis though considering you have to determine the difference between a tap and a shake. It might make for a fun challenge. I might give it a shot, but I'm still not convinced it'd be easier than a button.

  5. Is there any way you could post the schematics and code, or just sell a kit? A friend and I are very interested in building our own.

    • Like almost all of my projects, I've linked to the project files at the bottom of the post. Your eyes must have passed right over it! ;)

      • Sorry about that; not quite sure how I missed it.

        Anyway, I am currently attempting to upload your code to my board and avrdude is reporting the following error:

        avrdude: reading input file "main.hex"
        avrdude: input file main.hex auto detected as Intel Hex
        avrdude: ERROR: address 0x0810 out of range at line 129 of main.hex
        avrdude: read from file 'main.hex' failed

        I'm assuming that I did something wrong while compiling your main.c file, but I can't figure it out. What was your compiling process. and is there a chance that you could post your finished main.hex?

        • Oh crap, I discovered this problem and forgot to update the files. The schematic lists the ATTiny24 which has 2k of flash. You actually need the ATTiny44 which has 4k. Your part doesn't have enough space! I did the same thing when I ordered parts to stuff the rest of my order and ended up with a bunch of ATTiny24s.

          Sorry about that!

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>