RSS

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!

UPDATE 2013-06-11: Zeo has shut down, and all sourceforge/myzeo links no longer work. All of the APIs are now available on the OpenYou Github account. For more info, see the Zeo API OpenYou post

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.