Here’s a couple of resources I’ve found over the past week that’ve been helpful:

Cycling ‘74 has recently added a gear forum to their user forums, for support of hardware externals for Max/MSP. I maintain a few externals for biometrics and health hardware, and plan on using these forums for support and further requests.

Note that there’s also the openyou google groups that I’m using for general discussion of hardware/software, though Max/Pd discussion on health programming is more that welcome there too.

I also started doing some research on the BodyBugg today, just to see if any libraries exist for it yet. It looks like someone started a project to reverse engineering their data a couple of years ago, but it seems to have stalled. There’s some python code that was posted to a mediafire account, which I’ve downloaded and put on a github repo at

https://github.com/qdot/libbodybugg

I don’t currently have a bodybugg and I’m 3 deep in reverse engineering projects right now, so this is more a note for future reference, or for anyone else that’s looking for bodybugg libraries. I’ll be adding this to the libraries page once I get some time.

After both spraining my ankle and getting a cold, I decided it was time to spend a weekend on programming self quantification hardware libraries instead of producing data for them. Some people would probably call this “downtime,” but that’s not a term I deal with well.

In the emokit realm:

• Windows support in the C driver is done and confirmed working, though for some reason the device enumerates as 2 devices, since there’s 2 HID interfaces.
• Found out there’s another VID/PID pair for the usb dongle, which makes life slightly more difficult. The issue is outlined in this github issue on Daeken’s github repo. I’m now working with someone who has this dongle to try to get both working at the same time.

The hope is to get two of the major portions of emokit knocked out ASAP:

• Auto-headset type detection
• Searching for all possible VID/PID pairs

After this, the library should be usable in a v0.1 state while we figure out things like power levels.

Next up, I did a little bit of work on libfitbit. It’s now transfering data more reliably due to fixing how tracker resets are handled (they may or may not send 2 packets sometimes). I still haven’t gotten sending of data to the tracker working yet, but once that’s done, hopefully there’ll be a v0.1 release of the python version, as I outlined in the last post.

Now that the site seems to be up and stable, I’m hoping to get back to coding on libfitbit, emokit, and other things. Here’s my plans for the moment:

• Finish libfitbit python core - There’s still problems with sending data to the fitbit as part of the final step in the website communications. Once this is done, I’ll probably call it the v0.1 release.
• Once the libfitbit core is done, I’m planning on dividing out the Python ant communication library into it’s own repo since it’ll get used by a lot of projects. This includes adding a serial access core along with the libusb core, so it’ll hopefully ‘just work’ for some windows serial emulation devices. I may also do a C version of it, though I’m really not sure why ANT’s own libraries aren’t just open source at that point. The protocol is documented, would just save time…
• Make the fitbit real time “get up and move” application.
• Make a “fitbit finder” applicaton, so if you lose your fitbit, you can just hook your base station up to a laptop and carry the laptop around to find it. It’ll give you hot/cold readings, though I’m not sure on the accuracy available in ping times to the tracker.
• Trying to get emokit working in openvibe. This shouldn’t be too difficult, as openvibe already has a emotiv sdk communications core, and emokit exposes the same calls. Openvibe is just an absolutely enormous framework, so figuring out where things go and how to test is going to take some time.
• Do something with the Zeo. Not sure what yet.
• Currently working on getting a Garmin Forerunner. I already have a Suunto T3, I just need to order the USB unit for it. There’s already drivers available for talking to quite a few of the suunto watches and dive equipment, which I’ll be posting about soon.
• An generalized external for talking to ANT+ devices via Max/MSP or PureData. I do a lot of work with externals for these as is, and got a request via the Max/MSP forums for this specifically. Shouldn’t be too hard, once the ANT driver is done.

If you have any interest in helping out on these projects, please let me know via email or comments! Help is always appreciated.

After writing up the Zeo post yesterday, I decided to see if any projects involving the Zeo and the arudino or raw streaming libraries had happened yet. Sure enough…

SleepStreamOnline is a project by one of the interns at Zeo that uses the Zeo Raw Data library in order to stream your sleep data in real time to a website. That website then relays the data to other registered users, currently through a flash interface.

While the site still looks to be in the early stages of development, this could turn into something quite interesting for creative types, especially if a nice streaming API is added (this shouldn’t be too difficult with the relatively low amount of information transfer per Zeo unit). I’d personally love to be able to feed real time sleep data of a group into Max/MSP for live performance. Not to mention, if the user base becomes large and international enough (it’s currently at 10 users, so it’s got a bit to go), no matter which timezone you’re in, you could always hope to catch a real time stream coming from somewhere.

There’s some interesting privacy issues inherent in transfering this data, but I’m going to let someone else write about that. I’m happy to enjoy the creative potential here. It’s like pachube for dreaming!

I recently obtained a Zeo Sleep Tracker, and was ramping up on reverse engineering it. It’s always nice to find out during your first search for that task, that the company themselves released libraries and you don’t have to do the work.

The Zeo is basically a low sensor count EEG, similar to the Neurosky headset, except with a much better form factor to sleep with than headphones.

Zeo themselves put out two libraries you can use to access data from the device. There’s the data card decoder library, that allows you to access data from the SD card that sleep data is logged to. This is available in a Java library at

http://developers.myzeo.com/data-decoder-library/

There’s also an auxiliary serial port on the back, that can be used for real time data acquisition. There’s a python library available to do that at

http://sourceforge.net/projects/zeorawdata/

The Zeo picks up a more band-focused signal than Neurosky or Emotiv, since they’re just looking for resting versus a full spectrum, but it could be quite interesting nonetheless, especially to relay something like the arduino… Which someone has apparently already done!

This setup allows you to hook the Zeo directly to an arduino development board, which could then be used for setting sleep music, LED firing for lucid dreaming masks, and other sleep based projects.

There’s more development information on Zeo’s message boards.

I’ve put together a google groups mailing list to talk about development of open source health hardware/software and drivers for consumer health equipment. It’s at

https://groups.google.com/group/openyou/

Also, we’ve got an IRC channel on Freenode, #openyou. If you don’t have an irc client currently, you can use freenode’s web client to get there for now.

They say he who dies with the most maintainerships… dies very tired.

The emokit project, started by Daeken, aims to provide a free driver to access raw data coming from the Emotiv EPOC headset. However, he’s been really busy being awesome elsewhere lately, so after picking up the decode key for the special pre-release unit, writing a C implementation of the library, and fielding some support emails, I (Kyle) have finally just gone ahead and taken the lead maintainer role on the project.

Many thanks go to Daeken for the initial work on getting the library and community together, and hopefully he’ll come back to visit at some point.

The new main repo is at

http://www.github.com/qdot/emokit

Next big steps for the project are:

• Isolating the power level readings
• Finishing up and formalizing the C library
• Getting a full v0.1 release out

I also develop the np_epoc external for Max/Pd. I expect that I’ll be updating the external along with anything we get done with the headset itself, so keep an eye on that on my personal externals page.

I’ve spent the past couple of weeks working on libfitbit, library that provides hardware access to the fitbit health device. The current goal of this library is to provide a mechanism to build an open source data aggregation client, meaning linux-using fitbit owners can finally sync their hardware with the website.

For those that aren’t familiar, the fitbit is a clip-on accelerometer that features a nice little OLED screen and wireless data synchronization capabilities via ANT hardware.

Currently, libfitbit is written in python, and implements most of the fetching and uploading protocol of the fitbit, enough that web synchronization via linux has happened successfully (minus a couple of commands from the server that I can’t seem to send to the device correctly). Once all commands are sending correctly, the next goal is a C version of the library, as well as some demo applications of “real-time” access, such as a smart “get up a move” detector (that warns you when you’ve been sitting for more than a certain period of time, but also takes into account when you’ve moved by reading the fitbit). I will also probably split out the ANT python protocol library into its own repository, since it’ll be handy in other projects.

fitbit themselves have released their own API, but this is only for accessing their web services, and does not cover actual hardware access. However, the web API and libfitbit could easily be used together to create new and interesting interfaces combining the hardware and fitbit’s data services.

One of the other main goals behind this is to create a centralized ANT sync dongle so that multiple devices can sync to a single USB dongle. I’m honestly not sure if this is possible (my knowledge of the RF side of ANT is still cursory at best), but I don’t see why not, and it’s far better than having to keep track of a ton of different dongles across multiple machines.

Earlier this week, I was invited to check out an MRI as it was being dismantled for replacement of the gradient coil. It’s rare to see an MRI in this state outside of the factory, so I crutched myself down to the UCSF Neuroimaging Lab to check it out.

The gradient coil itself is a big cylinder of wire that weighs about 3000 pounds. It’s an integral part of providing positioning of signals coming from whatever is being scanned (which, in this case, is usually brains.)

Replacing it is not exactly a simple task. The coil had to be rolled along a large metal bar and lined up precisely with the opening of the MRI, as it is seated very tightly. Here’s video of the installation:

There were many other interesting pieces of hardware around the lab. Dr. Adam Gazzaley is currently doing a study on the brain and multitasking via video games, and needs to have a rig capable of playing video games in the room with the MRI. As there’s a 3 tesla sitting in the middle of the room while the games are being played, this means convention hardware using magnetic materials is right out. This means there’s specially built hardware all around, including specially built, heavily shielded LCD monitors using no magnetic materials.

There’s more photos of the trip at:

• Kyle Machulis’ flickr set
• Kelly Moore’s flickr set

Thanks to Dr. Gazzaley and Dr. Stables for inviting me to the lab and showing me around!

After a long weekend of work, I believe I’ve finally got the basic layout of the site ready to go. There’s still quite a bit of work to do on the library and application tables, as well as the question of whether or not those should just be wiki pages instead of centrally administrated, but for now, at least things are together.