This project started as an EMG datalogger to study my dad's Parkinson's disease, but after some testing I determined wearing electrodes wasn't practical for the long term datalogging that I wanted to do, the data ended up very noisy due to RF interference and shoddy electrode to skin connections.
I moved away from the EMG idea and began working on a low-cost low-power consumption accelerometer datalogger instead.
In this instructable I go over this long term project (I started it around this time last year) trying to highlight pain points and mistakes, and tips to avoid making these mistakes in your own designs.
Also, this instructable is entered in the Microcontroller and Tech contests, thank you for your votes!
If you're interested I have a blog where I posted updates on the project here. Any further updates will probably be posted to my personal project blog though.
Step 1: Read documentation, tutorials!
I hadn't made any real microcontroller projects before this, so the first step was reading and picking a micro to work with. I decided to go with the MSP430 mainly because I had an ez430-RF2500 devkit and the MSP430s low power consumption.
I had to also learn about producing a PCB since I wanted to make the circuit compact and comfortably wearable. I watched videos on youtube about EagleCAD and learned how to convert datasheet specs into footprints to be used in Eagle.
I read the first few chapters of MSP430 Microcontroller Basics which is a great book for starting with the MSP430. You also want to look up the Family Guide for the MSP430 you're working with as well as the model specific datasheet.
Step 2: Electronic design
The board is populated with:
The video shows a run-down of most of the circuit iterations I went through.
I used OSH Park to get the boards produced, a really wonderful service that does small runs of boards as a group order which really drives the costs down.
At this time a set of 3 boards for this project cost $3.35 from OSH Park. I shared the latest iteration of the board here so you can easily order a set. A word of warning for those who want to order the board: For some reason the drill holes for the programming header are tighter on some boards than others in the set of 3. I've tried expanding the drill size with each iteration, but it's still pretty tight, so you may want to go into the eagle file and expand those drill holes a bit if you can.
The hardware design is pretty basic: The switch just cuts the power to the whole circuit from the battery, which can be any 3v battery, any future iterations should use a small tactile switch instead and put the system into a standby mode so we can be sure to shut-down cleanly. The accelerometer connects to the first 3 ADC pins on the MSP430 for X,Y and Z analog signals with 0.1uf anti-aliasing capacitors. The programming header to the SpyBiWire interface on the MSP430, and the microSD holder connects to the USCI (Universal Serial Communication Interface) ports on the MSP430.
Step 3: Electronic Assembly
The board is mainly uses surface mount devices (The MSP430 and ADXL335 are QFN packages and the passives are 603s) besides the programming socket.
I used an X-Tronic 4040 purchased from eBay and leaded solder paste. I attempted to use "low melting point" non-lead paste, but it didn't melt and I ruined a few early boards and components (check the video).
However, leaded solder paste worked great, you can also find good deals on e-bay for small quantities in a syringe.
Using a toothpick dab small amounts of paste on the pads, place the components with tweezers and fix any problems after with the pencil iron, it takes practice and I definitely did my share of sweating.
A USB microscope can help, I tried using a zipscope (used in the video) but was more trouble than help for the most part during the actual soldering process. However, inspecting boards after the fact it was nice.
Step 4: Firmware Design
I programmed the firmware mainly using msp43-gcc which has been worked on by TI and Red Hat.
I got FatFS interfaced and running on the MSP430G2755, I was doing that work on the fatfs git branch hosted on bitbucket. I have a feeling my code in diskio.c has some mistakes, but as things stand now they are working.
You will want to clone the fatfs branch if you want a filesystem that produces a binary file of the data instead of writing the data directly to the SD card memory:git clone -b fatfs email@example.com:naked/msp-datalogger.git
The makefile has a rule "prog" which compiles/links the code and uploads the elf to the MSP430. Just type "make prog" after cloning with the rf2500 in the usb and the circuit on the rf2500 programmer.
The right now samples the 3 ADC pins about 40 times per second, stores the values to a buffer, then appends that buffer to a file in FatFS. I'm trying to figure out how to prevent opening and closing the file on every write because that throws off the sample rate. Using the f_sync function should do that, but it isn't working like f_close is. The other option is to ditch the fatfs branch and FatFS and go back to writing the raw data to the card. The only problem with that is the extra code needed to pull data off the card without a FS, I don't know if it's even possible on windows, with a Linux based OS it's as simple as reading bytes from the /dev/sdc device.
Step 5: Data Analysis
I wrote some python with a GTK UI to make going through the data easier using matplotlib. I have a repository for that project here.
I used numpy and scipy to do things like filtering and smoothing the signal.
I mainly wanted to see a plot of where my dad's tremors were the worst during the day. The animated gif there shows a days worth of data cut up into chunks (the vertical lines) and then measuring the spectral power at that time.
Step 6: Conclusion
I used an ipod nano case off ebay to strap the circuit and battery pack on. I used a 2xAAA pack, but a 3v 2032 coin battery should be fine, I haven't done any analysis on how much current is being drawn, but I'm turning off the CPU in between interrupts, so things should be pretty efficient.
There is always work to be done! But as the project currently stands on the fatfs branch was have a datalogger that produces blips of missing data due to the overhead of using FatFS to close the file after each buffer dump. I believe if I can get f_sync working properly we can avoid that data loss.
The main branch doesn't have that issue without the overhead of FatFS and can fit the dump to raw SD in between timer interrupts, but that isn't very easy to work with on non *nix based operating systems.
I was very excited to see the Michael J. Fox foundation and Intel work together to start datalogging and analyzing in the same way (you can see matplotlib being used in the video!) -- the difference being their system is expensive while this system is relatively cheap, free and open and doesn't require carrying a fancy cellphone everywhere. If anyone has ideas or wants to help or whatever please contact me directly firstname.lastname@example.org
Thanks for reading my instructable, and I hope find it in you to vote for my project!