My brother uses Phonak hearing aids, and recently the patch cable he uses to listen to music deteriorated so far that only one channel was working. Unfortunately, the cables are $50 new and hard to buy. I decided to try my hand at making a new cable, using top-quality components.

The Old Cable

In my haste, I didn’t photograph the old cable. It was a blue PVC patch cable with a Y-splitter about halfway up, like many earbud cables. The splitter was suspiciously large, a fact that will be important later in this tale. I started by measuring for continuity from the TRS (tip-ring-shaft) connector to the “Europlug” connectors at the hearing aids. It seemed that the cable was completely broken, since no current would flow except in the ground return!

I thought the discontinuity might be somewhere in the cheap cabling along the way, so I cut the Europlugs off (leaving whips for soldering later) and found that the connectors were intact.

I next checked the TRS end of the cable, and it too seemed okay. The only reason that the cable would not conduct, then, is if it had some sort of AC coupling capacitors for attenuation… I carefully cut away the cast silicone on the larger-than-normal Y splitter and indeed found an attenuator circuit inside. It was formed on a tiny two-sided PCB, but a little trace-following revealed the schematic:

The Phonak attenuator circuit.

The attenuator turns out to be very important. Without it, headphone audio signals commonly reach up to 2Vpp (peak-to-peak). On the other hand, the low-voltage battery in the hearing aid sets its maximum allowable voltage to around 1.3V. Considering that the ‘aid can function even when the battery is low, and can receive signals from tiny accessory “boots” that act as parasites on the main battery, it makes sense that the signal level can be very tiny. The attenuator in the cable bring the headphone signal down to the order of millivolts, protecting the hearing aid from overvoltage. Without it, even the lowest volume settings would sound horribly loud!

I used the schematic I harvested and the old connectors to build a new, better cable with fancy braided insulation for durability.

The new cable, with old connectors salvaged

Files

I made a gEDA schematic of the attenuator and connectors, in case anyone needs it. Hack on!

I interact with my alarm clock every day. It wakes me up in the morning, and because I get up at different times each day depending on what I need to do, I end up setting the alarm time again almost every night. I have been thinking about device design and the user experience of an alarm clock, and I have some idea that may make it into a new prototype I’m building. The device I have in mind isn’t really cost-effective–It won’t compete with the bargain-basement plastic clocks pouring out of China–but I would like to explore some new design ideas.

Problems with Other Clocks

The clock I use every day is bare-bones. I like it, because it has multi-colored seven-segment displays. But the interface for setting and checking the time and alarm settings is the seemingly-standard four buttons: time and alarm buttons; and hour and minute buttons.

The interface is admirably simple, driven to extremes by the competition for lower prices. But it requires two hands to use, and to setting a time earlier than the one programmed in the clock is annoying. There is no way to go back; the user must go “around the horn” to choose a new time. Simply holding the buttons down doesn’t work, either: the clock counts forward so slowly that my finger cramps from holding the button for so long. So I end up pressing the buttons as quickly as I can, and if I miss the minute I need, it’s another fifty nine clicks to get back around. That’s annoying!

I also generally find myself frustrated with the lack of clarity as to whether the alarm is even active. The designers usually hide the alarm switch on the side or back of the clock, so if you don’t want to snooze, you’ll have to flip the flimsy switch until the evening.

My Goals

I would like to create the simplest and fastest interface I can. I have many thoughts about how to do so, but some ideas are central. Here’s the breakdown:

1. Choosing a time is a continuous action. Time (at least as clocks portray it) is linear, and the user needs to be able to find a time in the continuum quickly and easily. For this task, I have in mind a rotary encoder, like a modern volume knob. The detents should be gentle and smooth, and fairly close together so going through sixty click doesn’t take too much effort.
2. Clocks are important at night, so the screen needs to light up. I don’t want to press anything to see what time it is, and I surely don’t want to turn on a lamp to see the time. I want to know, still in the dark, whether the alarm is on, what time it is now, and whether the clock thinks it is currently morning or night.
3. The clock needs to survive a small power outage. If I have just fallen asleep, a power outage is not going to wake me up. And if the clock doesn’t wake me, nothing will. So I need the clock to remember the time for about twelve hours when it’s off wall power, and still sound the alarm when I have to get up. It doesn’t have to show the time if that takes too much energy, but it does have to wake me up.
4. The alarm switch and buttons need to feel good. I want a solid click, not a wimpy squish.
5. The clock needs to look nice. Ugly appliances are garbage.

I decided recently to embark on a new robotics project. I bought a BeagleBone, a small Linux computer running the Angstrom distro, because I want to make a Wall-E robot with computer vision capabilities.

Initially, I thought about powering the mechanisms with an AVR, and offloading the processing to my laptop. I could use  a networked camera and connect the AVR over Bluetooth or WiFi to relay commands. But I rally want Wall-E to be able to make his own decisions, even when my laptop is busy with other things.

The BeagleBone should have more than enough power for what I’m doing. It has a USB host, so I can hook up a WiFi dongle, a webcam, and potentially a USB-based AVR motor controller. USB cameras are extraordinarily cheap compared to similar models that expose TTL signals for microcontrollers (ah, the wonders of mass-production).

The Plan

First I scoured the internets and failed to find new Wall-E toys for use in my project. Unfortunately, it seems Pixar has discontinued the adorable line of toys. Who wouldn’t want a Wall-E to play with? I ended up on eBay in bidding wars with other Wall-E fans and the formidable collectors. I bought a Wall-E “InterActive” toy, which basically makes noise when you push it around and may or may not have motors in it. The cubic torso is about 5″ on a side, so hopefully I can fit my electronics in there.

I will rip open the plastic enclosure and remove the battery holder, the noise circuits, etc., and supplant them with my BeagleBone and a better battery pack. I may put servos in the binoculars, for emotion, and perhaps one at the base of each arm. I will put DC gearmotors on the track wheels, assuming the ones in the toy are lousy. I plan to make an I2C motor controller based on the AVR to simplify programming the kinematics.

The Parts

I bought a cheap webcam from Syba via Amazon, and took out its innards. It turned out to be a well-build PCB for $8, and it works out of the box with Linux. I plan to mount it in one of Wall-E’s eyes. I haven’t seen the toy yet, so I hope the camera will fit in an eye.

I already mentioned the BeagleBone, an ARMv7-based board devloped with help from TI by the folks behind BeagleBoard. I already have the Bone running WiFi via the adapter from Adafruit, and I have confirmed that the Syba camera works with the Angstrom flavor of Linux with ffmpeg. I am trying to set up video streaming for remote monitoring.

I still need to work on the battery, which will likely be a rechargeable hobby unit. I want to put together a buck regulator for a clean 5V, an potentially include some kind of power management system to monitor the battery status. Wall-E shouldn’t run out of juice without knowing about it!

For the servos I picked up an Adafruit I2C servo driver, which has 16 channels of PWM from dedicated hardware. The extra cost is justified considering how complicated PWM from Linux can get. The less time I spend debugging code the better.

The faceplate for the Gauges project is 1/8″ Aluminium sheet metal. I bought a 12″-square sheet through McMaster-Carr, and after cutting it to size decided it would be best to anodize the finished product to keep it from scratching or corroding. After a few successful tests, I ran the final process, though I switched the anode and cathode polarities by accident, resulting in a strange thin-film oxidation on the work piece, which gives rise to varied rainbow interference patterns.

Step 1: Etch

After sanding and thoroughly cleaning the Aluminium with detergent (dish soap), I etched it in a solution of lye (Sodium Hydroxide) to remove surface defects and give a matte finish, like that of the Apple MacBook. I bought the lye in a solid form, as crystals of drain cleaner, and assumed that the crystals were pure lye (a stretch, though it was the best conservative estimate I could make). I read a guide about the etching process that suggested a 15% lye solution, so I mixed 1 part lye to 6 parts water in a 5-gallon plastic bucket. Wearing gloves and goggles, I submerged the metal in the solution, and it heated up and bubbled furiously as the lye ate away the surface. I only left the piece in solution about 2 minutes, to give a consistent matte look without making pock marks.

Step 2: Desmut

I don’t have access to proper desmut solution, the solvent that takes off the impure “smut” residue that accumulates on the surface of treated Aluminium. I rinsed the part in water and cleaned it with dish soap to fair success, and proceeded to anodizing.

Step 3: Anodize

Well, this step is supposed to involve using the work piece as an anode (positive terminal) in a direct-current circuit. The theory is that the metal will form a thin oxide layer, a clear ceramic that adds scratch- and corrosion-resistance to the finish. However, I accidentally wired the system in reverse, so that the work piece was the cathode (negative terminal). The result was a strange thin film of oxide that creates rainbow interference patterns. I like the look, and I assume the coating is indeed Aluminium oxide as it should be, but I cannot know for sure. It seems to have moderate scratch resistance, but I may try again with the correct circuit some time in the future to get it right. In the mean time, I am enjoying the vintage effect the “cathodizing” created, and I may just decide to keep it this way.

Following the guide I found, I bought battery acid from the local auto parts store and mixed it into water in the ratio of 1 parts acid to 4 parts water. The acid comes as 50% solution, and the goal is to have around 10%, so a solution of about 12% acid is just about right. The solution stays at room temperature.

I fashioned an electrode (supposedly a cathode, though due to my error ultimately an anode) out of Aluminium stock, which I placed in the bottom of the bucket of acid solution. I used an old computer ATX power supply to run a current of around 16 Amps through the workpiece, dangling from a bar of Aluminium, into the acid solution and back out through the “cathode”. Because I had wired the whole thing in reverse, the intended “cathode” ended up with the MacBook-like finish while my part looked just about the same as it did going in.

I sealed the part with boiling water for about an hour, and the rainbow effects showed up. Not exactly what I was after, but cool!

I am prototyping the software for Gauges from the Ubuntu partition on my white MacBook from 2007. One of the early tasks was finding the name of the temperature sensor corresponding to the main CPU. I installed a cool utility called Psensor that charts sensor outputs over time. Then I opened every application I could think of, and waited for the CPU temperature to increase. Psensor clearly showed that the sensor named “TC0D” corresponded to the CPU temperature. That acronym may mean “Temp-CPU 0 Die”, but I don’t know for sure.

Psensors Output

Once I knew the sensor name, I ran “sensors” in a terminal and found that my computer uses a chip called “applesmc-isa-300″:

travis@travis-ubuntu:~/Projects/Gauges$ sensors
applesmc-isa-0300
Adapter: ISA adapter
Exhaust  :   3074 RPM  (min = 1800 RPM)
TB0T:         +32.5°C
TC0D:         +57.2°C
TC0P:         +55.0°C
TM0P:         +58.0°C
TN0P:         +54.0°C
TTF0:         +55.0°C
TW0P:         +74.0°C
Th0H:         +54.8°C
Th0S:         +54.5°C
Th1H:         +54.2°C

Every Linux sensor has a corresponding pseudo-file for reading programmatically. I dug through online references of various sorts until I found the directory of my chipset, called ‘/sys/bus/platform/devices/applesmc.768/’. Once I had the directory, I ran sensors again with the -u flag set for “debugging” output:

travis@travis-ubuntu:~/Projects/Gauges$ sensors -u
applesmc-isa-0300
Adapter: ISA adapter
Exhaust  :
  fan1_input: 2309.000
  fan1_min: 1800.000
TB0T:
  temp1_input: 32.500
TC0D:
  temp2_input: 58.250
TC0P:
  temp3_input: 56.000
TM0P:
  temp4_input: 57.750
TN0P:
  temp5_input: 54.500
TTF0:
  temp6_input: 56.250
TW0P:
  temp7_input: 74.000
Th0H:
  temp8_input: 56.000
Th0S:
  temp9_input: 55.750
Th1H:
  temp10_input: 55.500

The verbose output told me that the sensor I want, TC0D, is also called “temp2_input”. Looking in the

/sys/bus/platform/devices/applesmc.768/

directory, I found a pseudo-file called “temp2_input”. Perfect!

When my Python script reads ’/sys/bus/platform/devices/applesmc.768/temp2_input’, it gets a string something like “59500″ corresponding to 59.5°C. My script converts the number to a float, divides by 1000, then rounds off to the nearest integer so I can fit the number in one byte. Awesome!

Over the past few days I’ve worked on connecting Gauges to my computer over Bluetooth. I have the physical gauges attached to an Arduino and a breadboard, and I am using a Sparkfun BlueSmirf Silver to receive streaming data from my laptop.

I wrote a Python script using the PyBlueZ stack to connect to the Bluesmirf. I had tried using PySerial, a great package, to write directly to the symbolic /dev/rfcomm0 representing serial bluetooth devices in Linux, but the connection had problems. The problems I thought I could avoid by switching to PyBlueZ popped up again, and I am still hunting for  solution.

When I start the Python script, which I call “gauges-daemon” since eventually it will run as a Linux daemon, or background task, the connection opens fine and the gauges respond. However, after a certain period of activity the script suddenly encounters BluetoothError #11, “Resource Temporaily Unavailable.” To counter this error I thought I could have the script re-open the connection, but then I get error #16, “Device or Resource Busy”.

I did some permuting and found that I can start the script, wait for it to fail, and then re-start the BlueSmirf. This allows the script to reconnect. The evidence seems to suggest that the problem is with the BlueSmirf, though I have pored over the datasheet (PDF) and found no mention about necessary steps to keep connections alive.

EDIT: The problem was a buffer overflow on the PC. I was sending Bluetooth messages to the Gauges, which would respond with status text. Because the Python script never read the port for incoming messages, these incoming packets collected in the Bluetooth serial buffer and everything halted until the buffer was cleared.

I fixed the Python script to represent the necessary changes:

import psutil
import serial
import string
import time
import bluetooth

sampleTime = 1
numSamples = 5
lastTemp = 0

TEMP_CHAR = 't'
USAGE_CHAR = 'u'
SENSOR_NAME = 'TC0D'

filename = '/sys/bus/platform/devices/applesmc.768/temp2_input'

def parseSensorsOutputLinux(output):
	return int(round(float(output) / 1000))

def connect():
	while(True):
		try:
			gaugeSocket = bluetooth.BluetoothSocket(bluetooth.RFCOMM)
			gaugeSocket.connect(('00:06:66:42:22:96', 1))
			break;
		except bluetooth.btcommon.BluetoothError as error:
			gaugeSocket.close()
			print "Could not connect: ", error, "; Retrying in 10s..."
			time.sleep(10)
	return gaugeSocket;

gaugeSocket = connect()
while(True):
	usage = psutil.cpu_percent(interval=sampleTime)
	sensorFile = open(filename)
	temp = parseSensorsOutputLinux(sensorFile.read())
	try:
		gaugeSocket.send(USAGE_CHAR)
		gaugeSocket.send(chr(int(usage)))
		#print("Wrote usage: " + str(int(usage)))

		gaugeSocket.send(TEMP_CHAR)
		gaugeSocket.send(chr(temp))
		print gaugeSocket.recv(1024)
		#print("Wrote temp: " + str(temp))
	except bluetooth.btcommon.BluetoothError as error:
		print "Caught BluetoothError: ", error
		time.sleep(5)
		gaugeSocket = connect()
		pass

gaugeSocket.close()

The stock gauge

I love the look and feel of vintage analog gauges, like those on the instrumentation panels of WWII-era planes and submarines. They have a certain aura of importance and longevity that attracts me. I have been thinking about a wireless hardware add-on that artfully displays my computer’s temperature and CPU usage, and I figured that some of those old gauges would be awesome for this project if I could find them at the right price.

I had actually looked around online for vintage panel meters before, but I was too specific: I was trying to find DC panel meters for voltages under 12V. I recently realized that I could instead choose any of the multitude of DC meters available on eBay, as most of them simply use scaling resistors to calibrate to the ranges on their faces. So, I ordered two that I thought looked cool, for around $20 each.

I got the first gauge in the mail today. It’s a “20 mA” DC current meter, with a metal faceplate, solid glass crystal, and a metal housing. It has two screw terminals on the back. It’s also waterproof and ruggedized. Of course, I want it to display CPU temperature and not “DC Milliamperes,” so I immediately started the teardown.

The Teardown

The gauge has a metal face held on by six small machine screws. Removing these, along with the three mounting screws, I exposed the crystal.

The crystal lifts off, though it was a bit stuck down due to years of pressure on the rubber gasket. Prying up gently around the gasket, the crystal easily peeled off and I was left with the exposed inner gauge.

To get the gauge assembly out I had to remove the screw terminal nuts on the back of the unit. Then everything slid out of the housing.

The faceplate was held in place by two hex-headed machine screws. Removing these, I carefully slid the plate out from under the indicator needle. I popped the plate into the scanner, and it was time for a face lift.

The Face Lift

I loved the look of the face that came in the gauge. It just had the wrong label and units. So, I scanned the plate with a flatbed scanner, then cleaned up all around the edges with GIMP, my image editor of choice. I also rotated the face to align it with the program’s grid.

The plate had the word “MILLIAMPERES” across the center, so the first change I made was replacing this text with “CPU TEMP”. I also changed the smaller “D.C.” label to “°C”, and masked out all the numerals with background color.

To find the range of values I needed, I installed “Psensor,” a graphing utility for system vitals monitoring on Ubuntu. Then I opened every application I could, running multiple browsers with videos and music, etc. I wanted to find the maximum temperature of the CPU under normal conditions. It peaked around 88º C, so I decided on 50-100º C for the indicated values on the new faceplate.

Matching fonts as closely as I could, I aligned the new numerals where the old ones had been. I printed a test page, and fortunately it was exactly the right size!

I got out some fancy stationery that happened to closely match the color of the faceplate, and printed my new design on high quality. I cut the design out with a razor knife, and then carefully applied removable double-sided tape across the whole plate. I trimmed away the edges of the tape so it would’t show.

Finally, I applied the new face plate design and smoothed it down gently. Time to reassemble!

The Reassembly

From here the project was simply a matter of working in reverse. The plate when onto the gauge assembly, and both of its screws went back in.

Then I slid the whole assembly into the housing, and applied the (now clean) crystal, followed by the outer gasket and metal face.

Around back, the screw terminal accessories went back on, and it was time to try some electrical experiments.

Calibration

Next I hooked the gauge to a 1.3V DC power supply in series with an ammeter and a 10K potentiometer. Dialing down the resistance, the gauge made a full swing at almost exactly 5mA. When I am ready to hook it to a microcontroller, there won’t be a problem sourcing such a small drive current. Awesome!

Files

In case you want to try your hand at gauge modding, here are the GIMP files I used: Gauges GIMP Files

 Last night I had an involved conversation with a peer. I had come back from class thinking about the state of the global economy, and specifically the advanced rate of gadget consumption in the U.S. I insisted, as I lately do, that our obsession with high rates of gadget turnover is both unhealthy for our environment and for our happiness.

My thinking was largely inspired by the TED talk I had just watched, at http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_choice.html, about what speaker Barry Schwartz calls “The Paradox of Choice.” His thesis is that, given some choice over none, people tend to be happier, but at some critical point the number of choices overwhelms the consumer and people simply cannot feel happy about their choices.

Read more on “So Many Choices” »

The circuit boards have come back through BatchPCB, and I couldn’t be happier with the results. The lines are clean, the sizes are just to spec, and I got 20 boards instead of the ten I ordered (presumably to account for manufacturing defects, though I haven’t found any). I populated one of the PCBs, and the design works!

The Boards

The StarTiny boards turned out just right. Granted, it’s a very simple design. However, the price was right at just $3 per board. I originally hoped to order in the US, but the cost was just too high for an entry-level designer trying to get a feel for the manufacturing process.

The Code

The code I had written for my solderless-breadboard ATtiny was close to correct, though the timings were a bit off from what I wanted. As I’ve said before, there’s not enough flash space to include floating-point math libraries, so I had to forgo the sin() function I used on the Ardweeny. The code uses a rudimentary linear ramp to approximate the sine, and the results are pretty good, though there is a bit less visual distinction between the nodes.

I altered the pin mappings in the code to reflect the connections on the PCB, and I think with a few more tweaks I can get the look just right.

Change of Plans with Paper

The paper doesn’t pass light as well as I had hoped. I could try sourcing brighter LEDs, but they would have to stay under the 20mA drive capabilities of the ‘tiny. I think I might go with lighter-colored (and thinner) paper instead. The issue then would be structural integrity, though.

StarTiny is cool, in my opinion, partly because it features a hand-crafted paper star housing. The paper gives the whole item a certain crafty feel that speaks of art and care. And I appreciate care in products.

Photos of the Paper Patterns

I can’t wait to get the PCBs to bring these colors to life!