I drive the least interesting car in the world, a gray 2004 Toyota Camry.  To stave off death from boredom while driving, I use a tape adapter connected to an A2DP receiver to wirelessly listen to music from my iPhone.  A few weeks ago, the tape deck developed an extremely irritating clicking noise.  The easy options, the ones that most Camry owners would choose, would be to turn on the radio, get an FM transmitter for the iPhone, listen to CDs, or just let the tape deck click.  Being an engineer, I refuse pick the easy option, but rather the one that seems best, which inevitably devolves into a weekend of hacking, cursing, and setting things on fire, with a best case of eventually restoring the object of interest to something resembling a functioning state.

The plan was to enable direct auxiliary input, which the Internet claimed was possible on this model.  The backup plan was to resolve the clicking noise by just unplugging the tape motor, which we assumed was unnecessary to operate the adapter.  My roommate Will and I popped the head unit out of the car with much effort and two trips to the hardware store.  Apparently stealing a radio isn’t easy, even from your own car.

Attempting to power the unit off of the 12v rail of a 350w ATX power supply resulted in it shutting off immediately.  With a 450w PSU connected to the battery and accessory voltage lines, a tiny laptop speaker from my spare parts bin connected to the massive amp, and another speaker being used as an antenna, we managed to pull in the beautiful sound of late 70′s hits on FM radio.

I’m not entirely sure what happened, but Will managed to break the tape deck in about a dozen different ways over the course of the next couple of hours.  It wouldn’t play at all without the drive gears spinning, it refused to eject tapes because it believed it was empty, and still, the clicking gear clicked.

It was then up to me to get aux in working.  Apparently, Toyotas from around my model year use AVC-Lan, a communications bus based on IEBus for the head unit to connect to things like a CD changer.  There is some pretty solid research across the web on how to emulate a device on the bus to message the head unit to use its aux input.  I used the circuit and software from SigmaObjects, as it required only parts I already had or could get from Halted.  The code there is designed for an ATmega8, but with some trial and error, I managed to port it to the current ATmega48/88/168 series.  Unfortunately, the code doesn’t mention being under any permissive license, so I can’t share my modifications.

While hooking it up to the head unit, the wire connecting the device to ground actually burst into flames, burning part of a connector and melting copper.  On later inspection, we found that the wires were extremely high gauge internally, and it is likely that only a single thin strand was carrying the current in the area that caught fire.  Miraculously, neither the radio nor the ATmega168 was damaged by the incident.  I switched to lower gauge higher quality wire, checked my car insurance terms relating to explosion due to user error, and continued.

After a few more hours of debugging, I realized that I had the two data lines backwards, and after switching them it worked instantly.  We repurposed the TAPE button to switch to aux in.  I taped the board down, put the head unit back together, and we stuck it back into the car.  There was an unnerving startup delay the first few times, but I am now the proud owner of a gray 2004 Toyota Camry with auxiliary audio input… and no tape deck.

The Arduino and the massive community around it have made AVR the de facto standard for hobby microcontrollers, despite the aloofness of Atmel to take advantage of it.  TI apparently decided that they wanted a piece of the pie, so they took a peek at the Arduino recipe and are now selling something that looks a whole lot like it for a fraction of the price.  The TI MSP430 LaunchPad ships with a MSP430G2231 and a MSP430G2211, microcontrollers sourced from TI’s Value Line.  The first, with I²C, SPI, ADCs, PWM, and UART, is a capable Arduino replacement for physical computing, though the latter chip is limited mostly to GPIO.  Unfortunately, both are a bit anemic when it comes to Flash and RAM.  TI’s roadmap shows promise regarding this issue.

The big problem though, is software.  The appeal of Arduino is largely that it has a dead simple to use, cross platform IDE, running on the well maintained and supported avrgcc and avrdude.  TI’s solution, on the other hand, is a set of two Windows-only, registration-required, code-limited, IDEs.  Linux and Mac users are left a little high and dry.  Luckily, there are some projects, new and old, that make it work out.

You can follow the instructions at mylightswitch to install MSPGCC4 and mspdebug, neither of which is in the Lucid repositories.  MSPGCC is an MSP430 port of the GCC toolchain, complete with GDB.  mspdebug lets you program and erase the flash on the LaunchPad, among many other things.  There are some usage instructions for it at Ramblings and Broken Code.  True to its name, the guide is partially broken.  To use the LaunchPad with mspdebug 0.9, you have to specify the driver instead of using -R.  In our case, we want to use the following:

mspdebug rf2500

Ideally, we would be able to use the uif driver that the eZ430U and other TI development boards use.  Unfortunately, the LaunchPad is incompatible with the firmware used with the ti_usb_3410_5052 module that comes with Linux.  There is a really amazing three part series on this at Travis Goodspeed’s blog.

While it is indeed possible to use the LaunchPad and MSP430 devices in general in Linux, I’m going to stick with the trusty AVR/Arduino combo for now.

www.youtube.com/watch?v=OvfT3TX_tn0

It’s bit of a stretch to call this Virtual Reality, in capitals no less, but I can’t think of another noun that fits it better.  This is the idea I have been hinting about, sprouted into a proof of concept.  By combining the stable positioning of the SpacePoint Fusion with the always in focus Microvision SHOWWX picoprojector, one can create a pretty convincing glasses-free virtual reality setup in any smallish dark room, like the bedroom in my Bay Area apartment.

This setup uses the SpacePoint to control the yaw, pitch, and roll of the camera, letting you look and aim around the virtual environment that is projected around you.  A Wii Remote and Nunchuk provide a joystick for movement and buttons for firing, jumping, and switching weapons.  All of the items are mounted to a Wii Zapper.  For now, it is annoyingly all wired to a laptop I carried around in a backpack.  Eventually, I’m planning on using a BeagleBoard and making the whole projector/computer/controller/gun setup self-contained.

The software is a hacked version of Cube, a lightweight open source first person shooter.  It’s no Crysis 2, but it runs well on Mesa on integrated graphics, and it’s a lot easier to modify for this purpose than Quake 3.  Input is via libhid for the SpacePoint and CWiid for the Wiimote.  All in all, it actually works pretty well.  The narrow field of view and immersiveness (a word, despite what my dictionary claims) makes playing an FPS quite a bit scarier for those who are easily spooked, like yours truly.  There is some serious potential in the horror/zombie/velociraptor genres for a device like this, if anyone is interested in designing a game.

This is just the start, of course.  I know I say that a lot, and there are about a dozen projects on this blog I’ve abandoned, but I think this one will hold my attention for a while.  I hate showing off anything without source code, so even though it will likely not be useful to anyone, I’ve attached the patch against the final release of Cube.

Download:
projecting.diff

To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries.

Article I, Section 8, Clause 8, United States Constitution

One of the few Congressional powers specifically enumerated in the Constitution over two hundred years ago allows for the protection of intellectual property rights for a limited period of time.  Limited is, like much of the Constitution, intentionally vague.  In theory, depending on the whims of the judiciary in place, limited could be defined as anything up to the heat death of the universe.  Recent judgments put this within the realm of possibility.  I will not use this space as a discussion (rant) about copyright law or reform, mostly because there are much better and more interesting places to read about that.  I will, however, describe my experiences as a user of copyright and propose a workaround for some of its woes.

The Copyright Act of 1976, as confirmed in Kahle v. Gonzales, changed copyright from an opt-in system requiring registration to an opt-out system, in which any copyrightable work is automatically copyrighted upon publishing.  That means that without any intervention on my part, under current copyright law and assuming no further extensions, this blog post will enter the public domain April 25th, 2080 if I croak immediately after hitting the Publish button.  As my red meat intake has been limited recently and Congress is still in the pocket of big business, I expect the actual date will be much later.

Many rightly find this unreasonable, hence the rise of the copyleft and free culture movements.  Practically perpetual copyright isn’t so bad when the work is opened by a permissive license like Creative Commons Attribution or three clause BSD or a reciprocal license like the GPL.  Or is it?  If in 2134, a brain hacking hobbyist decides she wants to repurpose and distribute a Python game I wrote in 2009 as a retro eyesaver, should she really have to include the ISC license stating that my corpse disclaims all warranties including implied warranties of merchantability and fitness?  I argue that in a sane society, she should not, as the work would long have been in the public domain.  However, the license I attached to the work will remain valid for the entire absurd length of its copyright.

I propose a simple workaround for this problem: a self-destruct wrapper for licenses.  That is, a legal instrument by which the owner of a work can specify that he or she voluntarily and automatically relinquishes the work into the public domain after a specific number of years.  This is à la carte copyright, in which the creator may choose a length that seems sane, like the 14 years we started with in 1790.  This also has the effect of trumping any further extensions Congress may enact to keep Steamboat Willie in the vault, preventing a work I publish today from remaining under copyright in 3010.  One could use such a wrapper on any license, permissive, reciprocal, or restrictive.  An individual or company could profit from a work for a period of time of their choosing, and automatically grant it to the betterment of society at the self destruct date of the license.  A software developer can protect a piece of code from going proprietary with the GPL today without forever limiting projects that use it to a copyleft license.  I could protect myself from exploitation by marking a photograph I’ve taken as CC by-nc-nd for now without preventing its public use long after my death.

I can’t even pretend to be a lawyer, but here’s a proof of concept ripped from a piece of the Creative Commons Zero license.

/*
Upon the date of publication, the License shall be deemed effective.  Upon
X years from the date of publication, the Waiver shall be deemed effective.
 
Waiver:
To the greatest extent permitted by, but not in contravention of, applicable
law, Affirmer hereby overtly, fully, permanently, irrevocably and
unconditionally waives, abandons, and surrenders all of Affirmer's Copyright
and Related Rights and associated claims and causes of action, whether now
known or unknown (including existing as well as future claims and causes of
action), in the Work (i) in all territories worldwide, (ii) for the maximum
duration provided by applicable law or treaty (including future time
extensions), (iii) in any current or future medium and for any number of
copies, and (iv) for any purpose whatsoever, including without limitation
commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes
the Waiver for the benefit of each member of the public at large and to the
detriment of Affirmer's heirs and successors, fully intending that such Waiver
shall not be subject to revocation, rescission, cancellation, termination, or
any other legal or equitable action to disrupt the quiet enjoyment of the Work
by the public as contemplated by Affirmer's express Statement of Purpose.
 
License:
...
*/

Since I am not a lawyer, I have no idea if a self-destructing license is legally possible.  I would like to get lawyerly advice on the idea before I start attaching it to my projects, but this is certainly something I plan on using.  Hopefully it appeals to others too.  Since the bug fix for perpetual copyright isn’t coming any time soon, this workaround will have to do.

www.youtube.com/watch?v=uRnBg9gflZM

This idea, like most good ones, came to me while I was in my bathroom.  I recently took delivery of a Microvision SHOWWX laser pico projector, and I was trying to come up with a quick project to show the cool stuff it could do.  I noticed that the light above my mirror was diffused by a large frosted glass dome, which led to this strange project.  It’ll probably make more sense around Halloween.

The software is pretty similar to what I wrote the last time I did face tracking:  OpenCV’s very convenient Haar feature detection along with Pygame to do the image display.  I tried taking a picture of my own eye, but Flickr user Sarah Cartwright’s is much more photogenic and available under Creative Commons Attribution-Share Alike.

A regular pico projector would probably work as well, but the contrast ratio on this thing means it looks like the iris is being projected by itself.  I have some much cooler projects planned that will really take advantage of the focus free nature of the laser projector.  In the mean time, the code for this project is available below.  The image is CC A-SA, the code is public domain, and the Haar file is Intel License Agreement like the rest of OpenCV.  I also attached the Python script itself for perusal by search engines or folks who just want to see the code.

Download:
EvilEye.zip
EvilEye.py

Sometimes a project is just not meant to be.  I picked up a Boogie Board LCD Writing Tablet when they went on sale to satiate my gadget addiction.  I didn’t expect it to be hackable, as it is little more than a glorified chalkboard, but I figured I’d give it a try.  My goal was to be able to lighten what was drawn on the screen, rather than erase it completely, to allow for the possibility of greyscale, or greenscale in this case.

I cracked it open (literally, I didn’t realize there were screws under the sticker), and found a more complex machine than I expected.  The brains of the tablet are an MSP430F2001, one of the cheaper microcontrollers in TI’s MSP430 lineup.  The header on the left hooks up to the programming pins, so anyone out there with a GoodFET might want to take a look at writing new firmware for it.  Unfortunately, I didn’t have one.

The waveform below captured between the two big pads, TP1 and TP2, shows how the cholesteric LCD refreshes.  On pressing the button, the power circuitry on the left generates 36v for 400ms, followed by 18v for 800ms, and feeds it to the multiplexer on the right.  The MSP430 toggles the input pins on the mux to switch that input voltage back and forth between the two pads in 150ms pulses, flashing the screen green and black and clearing what was drawn on it.

Unfortunately, while lifting the PCB up to see the traces on the bottom, I snapped one of the connections to the LCD, rendering the tablet useless.  Hopefully someone can pick up where I left off, modify the firmware on the MSP430, and see if its possible to make the LCD go only partway cleared by using shorter or fewer pulses.

A recent Slashdot post about Weird Stuff Warehouse reminded me that they carry cheap pedestrian traffic lights. I’d been meaning to pick one up to use as a completely overkill status indicator at work.  I managed to get this one for $10. It is a GE PS7-CFC1-01A that uses LEDs and looks new, but was presumably dumped by the original owner because it is a basic stop/go light without a countdown timer or accessibility features.

There were three mystery wires coming out of the back to interface it, so I cracked it open to see what was inside. The stop hand and walk person have independent AC-DC power supplies. Both halves share the white neutral wire, while each has a live wire of its own. The idea is to have the common line always connected to neutral while switching the hot line to whichever half you want lit up. Note that there is some additional circuitry on the right and an optoisolator connecting the halves. I believe this sign was designed such that if you attempt to power on both halves simultaneously, it will fail safe and light only the stop half.

People often get their hearts broken on Valentine’s Day. Frying mine by playing with 120v AC is one way to do that. Kidding. Household AC is fine to tinker with as long as you’re careful. I built the circuit from the Arduino Relay guide to do the switching. I picked up a SPDT 5v power relay to make it easy to run off of the Arduino. The transistor is still necessary because the AVR can’t drive the 100+mA the relay needs to switch itself. I used an ATX power supply socket for convenience, rather than cutting a cable and using that. The neutral line from the socket is soldered to the neutral line on the sign. Each of the hot lines from the sign is connected to one of the relay throw positions, while the hot line from the socket is connected to the relay pole. Thus, toggling a pin high or low on the Arduino will flip the hot line from one half to the other, powering either the stop or go sign on. The project in total cost less than $20. It probably would have been under $15, but Radioshack is the only electronics store open on Sundays.

The code on the Arduino end is pretty simple. It just reads a character off the serial port and flips the relay one way or the other.

#define RELAY_PIN 13
bool state;
 
void setup()
{
  Serial.begin(9600);
  state = LOW;
  pinMode(RELAY_PIN, OUTPUT);
  digitalWrite(RELAY_PIN, state);
}
 
void loop()
{
  if (Serial.available()) {
    byte in = Serial.read();
    if (in == '0') {
      state = LOW;
      Serial.println("Switching relay to Stop.");
    } else if (in == '1') {
      state = HIGH;
      Serial.println("Switching relay to Go.");
    }
    digitalWrite(RELAY_PIN, state);
  }
}

The computer end can be whatever you want it to be. For example, in Python, you can use pySerial as follows.

>>> import serial
>>> sign = serial.Serial('/dev/ttyUSB0',9600)
>>> sign.write('0')
>>> sign.write('1')

My college roommate Donnie mentioned the PNI SpacePoint Fusion in comments of the HMC5843 post, and it seemed too good to be true.  A 9 DOF controller (3 axes each of magnetometer, accelerometer, and gyro) with a Kalman filter to calculate a smooth quaternion that interfaces as a USB HID device, all for under $100.  I’d be surprised if PNI is making any profit on it.  I sound more like a shill than I’m normally comfortable with, but I’m truly impressed with this gadget. I have some plans for it involving a Microvision SHOWWX that I’m quite excited about; I’ll write more on that when it’s available in a couple of months.

PNI provides some Windows only sample apps that show off how weirdly stable and precise the SpacePoint Fusion is.  Luckily, since it’s a normal USB HID device (redundant, I know), and PNI provides application notes, it’s easy to use on any platform.  I wrote a Python module that uses libhid via python-hid to make it easy to prototype with in Linux.  The usage is pretty simple, as shown below.  Note that when plugging the device in, you need to keep it still for a few seconds while the gyros are calibrated.  After that, the quaternion, accelerometer, and button data can be updated 62.5 times a second.

>>> import spacepoint
>>> fusion = spacepoint.SpacePoint()
>>> print repr(fusion.quat)
(0.987518310546875, -0.04425048828125, -0.04119873046875, 0.145294189453125)
>>> print repr(fusion.accel)
(-0.054016113354999999, 0.018859863306999999, -0.89648437622400001)
>>> print repr(fusion.buttons)
(0, 0)
>>> fusion.update()
>>> print repr(fusion)
accel: (-0.054016113354999999, 0.018859863306999999, -0.89648437622400001)
 quat: (0.97186279296875, -0.233428955078125, -0.030548095703125, 0.005401611328125)
 buttons: (0, 0)

Update on February 7, 2010: I emailed PNI about a bug in the firmware, and got the following response:

Thank you for submitting the SpacePoint bug regarding libusb, Python, and Linux. You’re right! There is a bug in the SpacePoint FW that prevented opening interface 1 without opening interface 0 when using libusb under Linux. While your work around was effective in allowing the device to operate normally, one should be able to open interface 1 directly without the work around. We were able to use your Python source code to quickly diagnose and repair the bug. Please see the attached for the modified Python script. Please feel free to post this paragraph, the modified code, and all bragging rights on your blog (http://eclecti.cc/).

Units being shipped now have the fix. I modified the Python module to handle units both with and without the firmware fix and bumped the version to 0.2.

Download:
SpacePoint Python Module or
Standalone spacepoint.py

Setting udev rules to get the permissions right

In most cases, the module will just work properly.  However, if you get the following error, you probably don’t have the right permissions to access the usb device.

>>> import spacepoint
>>> fusion = spacepoint.SpacePoint()
hid_force_open failed with return code 12.

On most modern Linux distros, you can fix this by setting a udev rule for the device. In Ubuntu Karmic Koala, saving the following as /etc/udev/rules.d/45-spacepoint.rules , running sudo service udev restart , and then unplugging and replugging in the device should fix it:

# PNI SpacePoint Fusion
SYSFS{idVendor}=="20ff", SYSFS{idProduct}=="0100", MODE="0664", GROUP="admin"

The chunk of title after the colon intends to serve as an explanation of what a sleep remaining indicator is. However, this project is neither an alarm nor a clock. It is a visual indicator of approximately how much time I have remaining to sleep in the night.

This may not be a problem you need solved. If, however, like me you wear glasses or contacts, the world when you are in bed turns into a blurry mess. Normally I reach over and unlock my phone or lean over and squint at my Chumby One, but those actions make it harder to get back to sleep. What I wanted was a way to instantly know how much longer I could sleep before my alarm would go off.

My solution involves a line laser, a servo, and an Arduino. I set a potentiometer with a number dial to approximately the right length of time in hours and hit the reset button. The servo with the line laser attached will shine the laser line onto the ceiling. The servo will then slowly rotate, moving the laser line underneath a cover made of Lego pieces, making the length of line showing on the ceiling shrink over the hours. It’s a little like an hourglass, but with lasers.

Here’s the Arduino sketch. Use it under whatever license you want.

/* Sleep Remaining Indicator v1.0
 * by Nirav Patel <http://eclecti.cc>
 */
 
#include <Servo.h>
#include <math.h>
 
//#define photoPin 1
//#define laserPin 9
#define potPin 0
#define servoPin 10
#define M_PI_4 (M_PI/4.0)
#define MINSERVO 1190 // The laser line is no longer visible
#define MAXSERVO 1810 // The laser line is at its longest
 
unsigned long startTime;
unsigned long totalTime;
unsigned int lastVal;
Servo laserServo;
 
void setup()
{
  Serial.begin(9600);
//  pinMode(photoPin, INPUT);
  pinMode(potPin, INPUT);
 
  // this magic converts the pot value to 0 to 9 hours in milliseconds.
  totalTime = (unsigned long)31641*(unsigned long)(1024-analogRead(potPin));
  Serial.print('Time in hours: ');
  Serial.println((double)totalTime/(double)3600000.0);
 
  laserServo.attach(servoPin);
  startTime = millis();
  lastVal = 0;
}
 
void loop()
{
  // The laser brightness should depend on the ambient light in the room.
  // Unfortunately, my laser dislikes PWM, so I just have it hooked to 3.3v
//  unsigned int light = analogRead(photoPin);
//  analogWrite(laserPin,light>>2);
 
  // calculate the time we've been running (well, sleeping)
  unsigned long time = millis()-startTime;
  // Note that one could use this as an alarm clock by setting off a buzzer or
  // even having the servo rotate loudly
  if (time > totalTime) {
    laserServo.writeMicroseconds(MINSERVO);
    while(1) {}
  }
 
  // This trig makes the line length shrink uniformly over time.
  time = totalTime-time;
  double angle = atan2((double)time,(double)totalTime);
  unsigned int servoVal =  (unsigned int)((angle/M_PI_4)*(double)(MAXSERVO-MINSERVO))+MINSERVO;
 
  servoVal = (servoVal > MAXSERVO? MAXSERVO : (servoVal < MINSERVO ? MINSERVO : servoVal));
  // The servo is imperfect, so don't move unless the value actually changed
  if (servoVal != lastVal) {
    Serial.println(servoVal);
    laserServo.writeMicroseconds(servoVal);
    lastVal = servoVal;
  }
 
  // tick like a clock
  delay(1000);
}