Integration and Build
After soldering all the parts together, it was time to make the watch finally come to life!
The first thing I did is called, for lack of a better name, “Board Bringup”. It’s basically the smoke test to see if there is anything massively wrong with the design. It’s best to do this in stages, so initially I powered up the board without the display attached.
I measured the two power supplies:
The 3.0v supply is fairly simple, and it performed perfectly as expected. If it hadn’t, I could have destroyed the microprocessor -- annoying, but not a major loss.
The 12v supply is a lot more complicated. The prototype had worked perfectly, but when I powered up the board my multimeter only registered 9 volts. I was a bit puzzled about this, but after some probing I figured out the problem.
Remember that close-up picture from 2 days ago of the flux-coated ultra-small resistors? They adjust the output voltage of the 12v supply.
Besides their size, there is something else special about these parts. In order to save power, they are both extremely high resistance. Higher resistance means less current flows, so less power is wasted. Most resistors are in the 1000-20,000 ohm range (1k-20k), but the resistor on the right is 2,000,000 ohms (2M).
I turns out that there was enough grime near this part to conduct current. It wasn’t a lot of current, but it was a lot relative to the amount flowing through this high resistor. Even with multiple cleanings, the grime still persisted. To get the circuit to work, I eventually ended up using a soldering iron to boil away the flux, and then an exact-o blade to scrape the rest.
These two resistors consume about 0.7% of the total power of the watch. If I had used a 200k resistor, the part would have taken 7% of the power (or cost 1.8 hours of battery life). A 20k resistor would have be practically immune to grime, but it would also almost cut the battery life in half.
Once the hardware was tested and working, it was on to finishing the software.
I had already developed most of the software for a more-powerful but too-large PIC microcontroller, so I knew the basic game play would work. All I needed to do was port this program to the MSP430 -- since it was in “C”, most of the code didn’t require any changes. I needed to add code to control serial port (which is substantially different), plus code to accurately keep time.
I coded up the serial port routines and made it put out a test pattern -- success!
This snow pattern didn’t stress the power supply too much, and it allowed me to measure the speed that the screen could be updated. The default speed was too slow, so I opted for the 8x speed.
After that, I added code to turn off the display if the battery was low (and turn it back on once it was charged).
The processor actually has two clocks. The ball animation runs on a high-speed, low-power, but not-so-accurate internal oscillator (it’s rated at 0.8-1.5 MHz -- almost a 2X spread!). The time is kept with a low-speed, low-power, very accurate 32.768 kHz external crystal (it’s the rectangle thingy under the purple wire). The design choice is due to a bunch of tradeoffs -- a high-frequency and accurate time reference usually means it’s not low power. I added the software to enable the crystal and to increment the “minutes” counter every 11,966,080 oscillations.
I added a few other things to speed up the program -- such as redrawing the score only if necessary. Speed wasn’t the real goal, though -- saving energy was. By making the program more efficient, I could afford to add in some low-power resting time between animation frames.
Finally, I added a way to set the time -- this was something I had been putting off. Since there are no buttons on the watch, the only thing from the outside world it can detect is if the battery is being charged. I had to devise a system that wouldn’t accidently set the time every time the unit was recharged. And, since this processor can store only about 1000 instructions, the code had to be efficient.
The procedure I developed is done in two steps:
-
•First, apply power for 2-10 seconds. Any less and the watch assumes it’s a glitch and does nothing. Any more and it assumes the user is just charging the battery. The time display flashes for the critical 8 seconds to give the user feedback.
-
-
•Second, apply power again. The time will increment at a rate of 2 minutes per second, so any time can be set in a maximum of 6 minutes. (It’s a 12 hour clock with no AM/PM). When the correct time is reached, remove the power.
Once I got the software working, it was time to button up the watch!
Here’s a picture from a few days ago:
I soldered two small wires to the battery and used epoxy to keep them from moving. Any movement could cause a short and/or break the delicate metal tabs on the battery.
I temporarily added two small wires that I could use to charge -- in the real device, one wire would go to the metal case, and the other one would go to the charging post. Since this case is non-conductive plastic, it couldn’t run the first wire. And since, I don’t have a charging post yet, I couldn’t run the second yet.
And here’s what it looked like when it was ready to go:
Everything fit in surprisingly loosely! The battery and screen really determine the size of the case, and because the circuit board is smaller than it needs to be, it’s free to move around. I used some tape to try to keep things in place, but I’ll probably use some glue in the next version.
I’ve worn the watch to three coffee shops, and no comments yet. It’s a hit at my office, though, but the folks there have been following the development.
The battery life is higher than expected -- 33 hours instead of 25.
Next up... fixing a bug in the time-keeping software (it occasionally stops keeping time). I’d like to make the metal case, but I thinking of getting a smaller battery so I can make the watch thinner. I also need to drill and tap holes to keep the back on - it’s a pain to hold it on with tape. And, lastly, transforming this in to something cooler than a pong watch. Yes, cooler!
Tuesday, January 2, 2007