Lightstone Repairs

I have a Lightstone, and a copy of the game “Journey to Wild Divine”, despite not being a whifty hippie. My friend Ne0nRa1n gave them to me years ago for biofeedback hacking, but pointed out that the finger sensor connections were broken.

The Lightstone is actually a USB interface to GSR and pulse sensors. Internally, the board uses a M430F133 chip from TI to call the shots, along with a ST72F623F2M1. Why there are two microcontrollers in there, I’m not sure. It could be that one is handling USB communication and the other is dealing with the analog signals, which is supported by the ST part being connected directly to the USB port (with a pair of test points along the traces) and the TI part having a lot of traces running to the analog section of the board.

Overall, the design of the hardware is solid. The Lightstone is easy to open up, the board is well-assembled and has what I’d consider good looking PCB design. There are lots of test points in the analog and digital sections. Spare GPIOs on the MSP430 are broken out to little pads for possible hackery. There are even populated headers that probably were used for programming the microcontrollers.

However, there’s one point where the hardware falls down. The finger contacts for the GSR and pulse sensors are on thin wires with minimal strain relief. Two nice microcontrollers, sweet board design, and it falls apart because wires break.

The sensors are on a 6-pin DIN connector, with red, black, orange, green, yellow, and white wires. The red and black wires each go to a GSR contact. The GSR contacts are silver or silver alloy buttons, so I want to keep those. The other four wires go to the pulse sensor, which is a three pin device. Looking into the front of the device, the left lead gets the yellow wire, the center lead gets the green and orange wires, and the right lead gets the white wire.

2016-01-01 21.31.12

To repair the fingertip sensors, I had to pull out the hinge pins that hold the sensor case together. I used very fine-tipped pliers for this, starting from the hinge and then grasping the tip once I had pushed the pin out enough. Then I took the sensors apart, and cut out the bad section of wire. In the image below, the spot to grab the hinge pin is just to the right of the small spring.

2016-01-01 21.23.35

I stripped the original cable, and wrapped the stripped sections in heat shrink. I drilled out the molded strain reliefs so I could thread the wires back through them more easily, threaded the wires, and used more heat shrink to improve the strain relief. My new wires are not as flexible as the old ones, but should be more durable. Finally, I soldered the sensors to the ends of the new wires, and put the sensor cases back together.

2016-01-01 23.05.01

If you do this repair, be careful soldering to the silver-alloy sensor buttons for the GSR sensor. The silver part is surprisingly easy to soften and distort with heat from a soldering iron. I slightly damaged one of mine, but managed to do the other one with no problems.

2016-01-01 23.59.10

I’m using liblightstone to get the information from the device. So far, it seems to be working fine.

Web Development with Flask and Python

I haven’t done anything that could properly be called web development since about 2002, when I took a college course in it. There have been a few developments in the field since then, and I’m a little rusty.

I chose Flask, because I like python and because Django seems like overkill for what I’m doing. There are literally dozens of frameworks out there, and I imagine some people know and care about the differences between them. If I had comments enabled, they’d be yelling at me to switch to Django right now. Hence, no comments.

Installing Flask is easy on Ubuntu:

sudo apt-get install python-flask

I copied the Flask “hello world” from the Flask page, ran it with

python snowflake.py

which got me the expected result, a web server running on port 5000 with a “Hello World” message.

My plan for this web app is to have users be able to visit some page, and the page will contain an image of a snowflake, generated from the url they used to visit. That’s it, but over on Facebook, my post about generating snowflakes from people’s names made people go just about nuts asking for them. Rather than generate them myself, I figured I’d write a web app.

Flask is a joy to work with. In debug mode, it detects changes to the file that contains the currently running app, and restarts when that file changes. It also presents a traceback and interactive debugger if something goes wrong in your app (it goes without saying that this needs to NEVER reach production, since it’s an interactive python shell on your server).

At this point, I have the core functionality of the app together, and I’m not even done with my beer. I can visit a URL, and a snowflake image gets generated from that URL. Everything else is details, and then deployment.

A couple of downloads later, the image now gets converted to png, and served back to the user as an image in a page. Soon, deployment!

KiCad is Still a Shitshow

Six months ago, I designed a schematic and circuit board in KiCad. Yesterday, I tried to open it and got a list of errors so long that it didn’t fit on my screen from top to bottom. The reason is that KiCad loads the footprints of the parts you use from Github, so when (not if) the KiCad devs change how they store footprints, your install of KiCad breaks. In other words, installing KiCad gives the KiCad devs permission to break your workflow for no reason.

I fixed my KiCad package list by writing a little python script that goes through the KiCad github repo and generates a new footprint list based on however they happen to be organized and whatever they happen to be called today. Copy that over my previously working footprint list, and the error message went away.

However, since the last time I used it, my install of KiCad has stopped rendering in CVPCB. No error message or anything, just doesn’t render the copper layers, parts, etc. I got part of the ratsnest, and that’s it.

Clearly, the thing to do is to install the newest version of KiCad from the developer’s PPA.

Nope, that returns a 404.

Clearly, the thing to do is to install using the script the devs wrote to install and build KiCad.

Nope, the script fails because they use a version of WXWidgets that like no one else on earth uses.

So let’s recap: No method of installing KiCad works, and just LEAVING YOUR WORKING INSTALL ALONE is not sufficient to ensure that it continues to work.

Since I’m designing a small PCB, CadSoft’s Eagle is looking more and more tempting. Limited PCB sizes aren’t a problem if you’re making something small.

Structured Light Scanner

image

I got the projector back in the spring, planning to do some projection mapping. I got distracted by some stuff for a festival, but some co-workers and I were talking about structured light scanning recently, so I threw this together.

For software, I’m probably going to do the calibration stuff in Python and OpenCV. I’d like the first demo to be perspective correction, to project on non-flat surfaces. Second will probably be virtual lighting.

ToyBrain Rides Again

Now with WiFi, current monitoring, and the ever-worrying li-poly battery chemistry.

image

I haven’t tested the WiFi module or motor drivers yet, but the board is fully populated and the battery regulation circuit works.

There are a few design changes in the pipeline, but I’m going to go for a full hardware test and try to find more bugs before I create version 2 of the boards.

The current design is in github, along with all the docs.

Un-Ubuntuing Ubuntu Redux

Ubuntu ships with the “main” and “universe” repos enabled, and the “multiverse” repo disabled. This is because there are legal or ideological reasons to not use the software in multiverse.

However, there are practical reasons to use the rar/unrar packages from multiverse over the unrar-free package in universe: unrar-free frequently doesn’t work, but unrar-nonfree does.

If you want your compression and decompression software to operate, rather than be ideologically compliant:

sudo apt-add-repository multiverse
sudo apt-get update
sudo apt-get install unrar rar

Bah humbug

The V2 toybrain boards have the diagnostic LED on analog input 6, which isn’t able to also act as an IO pin. Other than that, though, they work. This entry is mostly a note to me to fix that if I make another rev of the board.

Flashing bootloaders on an ATMega328 with the internal clock enabled

The V2 Toybrain boards are getting pressed into service for an art project that I’m working on, so I’m trying to get a set of them up and running. I use Linux, so the tools for talking to AVR microcontrollers are the Arduino IDE, and avrdude, which the Arduino IDE uses.

I started today by telling the Arduino IDE that my boards are a Lilypad Arduino with an ATMega328 on them. This isn’t true, but the electrical design of the board is such that this is close enough. I also informed the IDE that I had a USBTiny ICSP programmer. That bit is true. I had high hopes (because I’m lazy, and configuring the IDE is not the problem I’m trying to solve) that this would let me just hit the “burn bootloader” option in the IDE. Such is not the case. I got the error message:

avrdude: Warning: cannot open USB device: Permission denied
Error while burning bootloader.
avrdude: Error: Could not find USBtiny device (0x1781/0xc9f)

I’m a normal user, and the permissions on the USB device are not such that mere users can talk to it. I figured I’d double-check by using avrdude as root (so the permissions would be ok). Then I ran into my next problem:

sudo avrdude -p m328p -c usbtiny
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9514
avrdude: Expected signature for ATMEGA328P is 1E 95 0F
         Double check chip, or use -F to override this check.

The version of avrdude I have is 5.11.1, and doesn’t ship with a hardware definition for the ATMega328, just the ATMega328P. The P is for Picopower, and isn’t related to anything I’m doing (it mostly relates to the technology used to make the chip, and some power handling options like brownout detection). To get around this, I opened /etc/avrdude.conf and copied the ATMega328P hardware definition. Then I changed the descriptions and a few of the fuse bytes to match the parts I do have, and saved the file. Now avrdude doesn’t flip out about my chips.

Unfortunately, programming them through the Arduino IDE is still a bad plan, as the configuration for the LilyPad Arduino isn’t close enough to the hardware I’m using. Specifically, the Lilypad/328 configuration sets the lfuse bits to use an external oscillator, and I’m using the internal oscillator. Once the bad fuse settings are burned in, the chip doesn’t communicate unless it has a 8Mhz crystal attached to it. The error message from avrdude is:

avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

I added a crystal (temporarily) to the bricked boards so I could reset the fuses, and they worked fine after that. One of them had the chip on 90 degrees from the proper orientation too, and gave the same error as the chips with the bad fuses, so that error can be anything from the wiring being bad to the chip being configured wrong.

To use avrdude as non-root, I put

ATTR{idVendor}=="1781", ATTR{idProduct}=="0c9f", GROUP="dialout", MODE="0666"

in /etc/udev/rules.d/99-usb-tiny-asp.rules and restarted udev. That lets users in the dialout group have appropriate access to the USB port for the programmer.

The commands to burn the fuse and flash the bootloader are:

avrdude -c usbtiny -p m328 -U lfuse:w:0xE2:m -U flash:w:/home/ams/arduino-1.6.0/hardware/arduino/avr/bootloaders/atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex

My current fuses are lfuse:0xe2, hfuse:0xda, efuse:0x05.

Now we’ll see if I can send a program to them…

Safety third!

Say what you will about globalization and the downfall of the USA, I still like ordering stuff from China. It’s cheap, and it takes so long to get here that I forget I ordered it, so it’s a surprise to me.

Recently, I got a bunch of li-poly battery monitors. These (not surprisingly) monitor li-poly batteries and sound an alarm when the battery voltage gets too low. Overdischarging a li-poly battery can damage the battery fairly quickly, and so may mean you have to buy a new battery. This is far better than overcharging them, which can start a pretty dramatic chemical fire.

The monitors I got are these or something very like them. The ones I have have a button which you can press to set the alarm voltage, with a default of 3.3V/cell.

Like a good hacker, I immediately opened one of them up. It has two ICs, one of which is a Atmel 24C02BN, which is a 2kbit I2C EEPROM. The other is unmarked. I had high hopes that it would be an Atmel part as well, or at least marked, so that I could possibly reflash it with my own firmware.

Having 16 pins counts it out from being any of the ATTiny or ATMega series, as well as any of the 8, 16, or 32-bit PICs. I imagine it’s something like an Elan microcontroller, and probably not super-well documented.

I did also find out that the speakers are simple dumb speakers, not beepers, so the micro generates the audio waveform for them. That means if I want to use the beep as a shut-off signal, I’ll have to do a little filtering, or add a 555 as a pulse stretcher.