Sunday, May 23, 2010
Mac Mighty Mouse trackball embedded interface hack
Inspired by input nirvana from geekhack I got a free mighty mouse from a generous donor and went about interfacing to it. There's plenty of teardowns already available on the net, so I'll skip opening the mouse and just show this picture with the pinout to the trackball. Note that it's even simpler than most typical trackballs in that it doesn't make use of quadrature encoding for the two axes. The trackball actually has four distinct pulsed outputs corresponding to the four little wheels surrounding the ball. When rolling in any of the four cardinal directions (left,right, up,down) only one of those little wheels is actually spinning. Decoding the output of the overall trackball simply requires detecting pulses on each of the four pins. If the state of any pin changes from what it was during the last polling interval then you've moved in that direction. Instead of polling you could also just set up four pin change interrupts.
To test things out I hooked up the trackball to one of the new SMT connector boards from Schmartboard (seen in the picture) and from there to an atmega32u4.
At the moment I haven't decided whether to make a small wireless mouse out of this or integrate it into my kinesis project. I'm leaning heavily towards the former, since the keyboard already has 4 pointing devices.
Total time taken from disassembly to working USB trackball mouse (including the time for this quick writeup): ~2hours 10 mins.
Posted by trtg at 3:15 PM 16 comments:
Sunday, May 2, 2010
forearm massager for climbers (and keyboard users)
OK. the link here to keyboards is probably even more tenuous than my bluetooth scale but whatever. In the quest to relieve perpetually tense forearms due to bouldering + heavy keyboard usage I came up with this massager using easily obtained components. The total parts list with estimated price: (all items except for skateboard wheels were obtained at Lowe's)
4 skateboard wheels with bearings: $10 at target, but you can easily wind up spending far more for fancier wheels like the 70mm kryptonics wheels in most of these pictures.
2 4" wood clamps: 2@ $4.99 ea. = $9.98
2 5/16" x 8" machine bolts: 2@ $1.15 = $2.30
3 11"x1/4" threaded rods: 3@ $0.97 = $2.91
8 plastic spacers: 4 x (2 @ $1.09)= $4.36
2 pieces of thicker(1.5"x1.5"x8") wood: ? this was just scrap wood I had lying around, not sure how much it would cost.
(optional) 1 piece thinner wood (0.75"x1.5"x8") also scrap wood and not really necessary, just added to allow clamping in one other place.
4 pieces of 1/4" thick ABS plastic: ? scrap plastic I had lying around, not sure how much it would cost but small sheets of lexan or acrylic at Lowe's are pretty cheap.
Putting things together is pretty easy: thread one wheel onto one of the 8" bolts, followed by 2 plastic spacers.
Next, add another wheel followed by two more spacers and a piece of ABS plastic.
Posted by trtg at 12:58 PM 23 comments:
bluetooth wireless bathroom scale with fatsecret integration
Not exactly a keyboard, but I'd argue that a datalogging scale is an imput device... In any case, this is a project I did a while ago (~2 years ago). Start with a cheap bathroom scale from ikea, then strip out all the hardware except for the load cells. Add in the following:
roving networks bluetooth serial module
24 bit ADC (AD7799)
4 AA batteries +linear regulator (don't want switching noise here)+ input ORing diodes to allow powering from batteries or USB without damaging either (handy during development)
After assembling the above hardware, the microcontroller code was fairly straightforward- when a user taps a corner of the scale I take repeated ADC readings until the "running STD" (STD of last N measurements) drops below a certain threshold. At this point the scale will have a stable zero point to normalize the subsequent weighing. When the user stands on the scale I do the same thing- take ADC readings till STD< threshold. I chose the threshold such that the delay before convergence was short, at the expense of some accuracy. Left to run long enough the scale was able to detect the difference between my bodyweight and my bodyweight plus one US quarter. With the current threshold the scale appears to be repeatably accurate to within 0.1 lbs which for my purposes is acceptable. I was actually pretty happy to get that level of performance considering I didn't lay out a board for the ADC and just used a schmartboard instead.
One other metric I was happy about is the battery life - approximately > 9 months when used once or twice a day. I coded things such that the microcontroller is in a deep sleep until the user touches a corner of the scale. I could have taken a hardware approach and actually disconnected the uC power with a transistor until the user touched the scale, thus arming a delay circuit, but the software approach yielded more than acceptable results. The uC current draw is in the microamp range when sleeping and I use transistors to disconnect power from the bluetooth module and ADC while sleeping so I probably shouldn't have been surprised.
I think for a future revision of this project I'll actually spin my own main board. This would allow for a much more compact footprint and allow me to power from a smaller 3.3V source instead of the stack of 4 AAs. This latter arrangement was needed to avoid extensive rework of the olimex board where certain bits of hardware expect 5V.
On the PC side of this project I'm using bluez rfcomm server to listen for inbound serial connections and then run some other code when a connection is established. That other code consists of python scripts that insert the current reading in a sqlite database (which is then visible from my ruby-on-rails site) and submits the reading to fatsecret via its API. This data submission is done using OAuth, so the whole process requires no human intervention and I avoid any ugly hacks involving plaintext saved passwords.
Fatsecret is great because:
(1) it has an API
(2) it has an android version
(3) it can scan barcodes to fetch associated calories and nutritional content
Here's a screenshot from my phone showing a graph of weight readings for the last few months.
One final aspect of the scale which I find interesting is the means by which the user interacts with it. I intentionally made it so that scale does not have an LCD to show the current weight reading. Day to day fluctuations are not reflective of what really matters- long term trends. Usage of the scale thus boils down to the following:
(1) User taps lower corner of scale to initiate auto-zero sequence
(2) The scale turns on its sole LED to indicate that the zero process is ongoing
(3) The scale switches its status LED from solid red to blinking to indicate the zero process is complete.
(4) User stands on scale until LED turns off, indicating the reading has stabilized.
(5) User reviews cumulative weighing data at some later time (either via phone, or at their PC)
For fun, I added an additional means of relaying data to the user- spoken weights. By feeding the stabilized weight reading to festival (text to speech engine), the scale can "announce" the most recent weighing.
Posted by trtg at 9:56 AM 28 comments:
Labels: quantified_self, wireless
Subscribe to: Posts (Atom)