Zeo Firmware and Raw Data API on OpenYou github

It appears Zeo, which declared it was shutting down in March, has taken a scorched earth policy in terms of developer firmware and libraries. All zeo websites are gone, and the sourceforge has been cleared out. I still had versions of the firmware and raw data API kicking around on my harddrive, and managed to fork the android project before the github account disappeared. I've thrown all of this on the openyou github account.

Zeo Firmware: http://github.com/openyou/zeo-firmware

Zeo Raw Data API: http://github.com/openyou/zeo-raw-data-api

Zeo Android API: http://github.com/openyou/zeo-android-api

Since most developers are used to looking for these kind of libraries on github, that seemed the best place to store them right now even though I certainly have no plans of doing any upgrades to them. The master branches will most likely stay as copies of the final versions so that others can have a reliable base to fork from.

For developers that want web accessible documentation, SleepStreamOnline (a project done by a Zeo intern a few years ago) is still around, and has web documentation for the raw data API available. Assuming this ever goes down, developers should also be able to generate their own version from the Raw Data API code using sphinx.

OpenYou Github Organization

I've finally gone ahead and moved most of my health driver repos, as well as the repo holding the openyou.org blog, to the OpenYou Organization on github. Over an indeterminate amount of time in the future, I'll be flipping the READMEs, and possibly the licensing, to reflect OpenYou also.

The hope here is to get more community involvement in drivers for health equipment. Up until now, the repositories have lived on my personal github account, which, while great for my coderwall badges, means that I'm primarily responsible for support. Ask anyone who's emailed me actually asking for support, and you'll find out how well that's gone so far.

While I do get and try to service pull requests on my drivers, sometimes it takes me weeks or months, or else I do things out of order and end up conflicting people's patches. My hope with moving these to an organization setup is to allow developers that are interested to help out with maintenance of these projects.

I'm already starting to see this in action, as there's now a developer on the emokit project working on porting the C library to HIDAPI. I'd like to get battery power and signals in soon too. There's a bunch of stuff to be done on things like libfitbit and libomron too.

Moving this stuff forward shouldn't depend on the amount of free time I have. If you're interested in becoming a developer with commit rights on one of these projects, file an issue in the project you're interested in working on.

OpenYou Projects Update

It's really amazing how quick a year can disappear by.

Due to personal circumstances that involved finding a new job, hacking some robots, being in Make Magazine, etc... It's been a quiet year at OpenYou so far.

So, an update!



I'm still seeing pull requests to libfitbit! The library has become somewhat more stable, though we're still plagued by issues with the base station locking and not communicating until it's unplugged/replugged. I'm not sure if this is an issue with the fitbit base station or with my python ANT library. It's something I hope to look into soon.

I'd also like to get a Fitbit Ultra at some point, to get altimeter readings into the system.



As of today, Emokit for the Emotiv EEG sees a major update, at least in terms of protocol documentation. We now have access to the sensor quality levels and battery power levels, the two portions we'd been waiting on in order to finish the library and release v1.0. I've created a protocol document that's available in the github repo, and would like to get this pressed into code ASAP.

In less new-featurey but important maintenancey issues, I'm also planning on moving the library to HIDAPI, which should solve a lot of the crossplatform issues reported in the repo. I'd also like to finish the OpenVibe bindings, which I got started but then fell off on due to above mentioned circumstances.



I've been permaloaned (Sorry Barry I swear I'll get it back to you) a Nike Fuelband to work on. I did some initial proof-of-concept code a while ago, which found some dates and what I believe are steps recorded down to the second (the highest granularity I've seen in a consumer pedometer thus far).

The unfortuate news is that there seems to be no good way to access the LED array, which was my original goal. However, the factory wipe mechanism looks like it may be a firmware reload, which would be super handy for possibly building my own LED access functions.

So, that's it for now. I'll hopefully be posting more about some of the patent battles in health technology this year soon, as things have really been heating up.

Speaking at SF Data Mining Meetup - March 6, 2012

Contrary to evidence otherwise, I'm not dead, just got busy with life outside blog/qs land for the past 8 months. Am now working on returning to former productivity levels, starting with a new release of emokit and openvibe bindings ASAP, then maybe taking another look at libfitbit and the fitbit ultra.

Before that's all done though, I'll be speaking at the SF Data Mining Meetup March 6th at the Trulia offices. It's me and one of the people from Basis. I think it may already be sold out, but watch the page to see if more spots become open.

libfitbit Hangups

First off, hello to everyone who found us through the MIT Tech Review article or Ubuntu Community talk! Been a bit slow around here lately, but hoping to get things booted back up.

It seems the most requested thing at the moment is a finalized version of libfitbit. Currently, we're at v0.0.1, which was released in February and hardly worked. There's been a lot of progress since then, and we are now able to replicate full communications with the tracker. There's really just one problem left with the library, and that's the subject of today's post.

So, unless you're into specifics of the implementation of the ANT protocol, you can probably skip the rest of the post. However, if you're interested in helping me kill the last bug before I can start making distributable, read on.

I recommend having the ANT Protocol Specification open while following along, as I'll be talking about packet types quite a bit. Also, if you have any comments, please leave them on the github issue about this problem.

UPDATE: And, 2 hours after I post this, I fix it myself. I wasn't resetting the USB device correctly, which meant we were getting weird configuration conflicts from the last session run. Fixing the device reset clears this, and libfitbit will now retreive information multiple times without having to completely un/replug the key. I'll write up a "rest of the things I need to do" post tomorrow to let everyone know what's next.