random($foo)

Next in my gadget backlog series…

I had preordered a Basis B1 Watch a long while ago and promptly forgotten about it, so it was a bit of a surprise to find one sitting on my desk after SXSW (which has turned into this amazing construct of pure marketing – good for business though, I guess).

Since then, I’ve worn it almost every day (about a month-and-a-half). I figured I’d give a report after living with it for a while since Basis is now apparently starting to sell them for real (after being back-ordered for a while).

While I have had reservations on the watch form-factor after getting a MetaWatch and realizing in the intervening decade since I regularly wore one that I now couldn’t stand wearing watches, I’ve mostly re-adjusted, and the data the Basis collects has been worth overcoming the annoyance factor.

There have been a couple reviews (the Verge one isn’t a bad summary), but here’s the basic rundown of what you need to know:

• Price is $199. It comes exquisitely packaged in a die/laser-cut box and overall all the industrial and product design is quite nice (package, device, site/app). The watch is less bulky than the typical smart watch and is pretty inconspicuous. The capacitive touch buttons work well and the display is simple but more than adequate.
• Unlike almost all devices currently on the market (besides the BodyMedia devices), the Basis is a multi-modal sensor device that’s more than just a glorified pedometer. Sensors include:
  • Heart-rate via green LED optical flow-based sensor (I assume using something similar to the TI AFE44xx but sadly, there’s no current support for SpO2 or glucose measurements); An important note is unlike the similarly kitted MIO Alpha, Basis specifically notes that heart rate measurements are not suitable for exercise monitoring
  • Skin Temperature (accurate to the tenth of a degree) – mine seems to be about 92-94 degrees fahrenheit when I’m up and a few degrees lower when I’m asleep
  • Perspiration specified by μS/cm, so it looks like it’s using galvanic response to calculate? The Basis itself seems to be fairly well waterproofed, and I’ve used it in the shower w/o issues (although usually not, because that’s weird, right?)
  • Pedometer and sleep tracking via a 3-axis accelerometer
  • Calories burned are derived from BMR via Oxford equations multiplied against a “physical activity level value” that’s presumably derived from the sensor data collected. Note, if you have a better BMR value (ie, I have an RMR estimate from my lean body mass from my Bod Pod measurements, you can presumably use Table 5.2 to reverse calculate what weight to enter to get more accurate estimates)
• Battery life is good for a few days (3-5?) and you need to use a custom charger to recharge. This is a bit of a pain actually, especially if you’re traveling – the charger is a plastic band that hasn’t broken yet, but is just begging to be and will soon enough, I’m sure.
• This charger also syncs data from your device. This is a really important point. While the Basis has Bluetooth (2.1 eww) built-in, it doesn’t work yet and the USB sync is the only way to get your data. Also, there are mobile apps (Android first, then iOS?) on the way, but again, these aren’t available yet. Personally, I wouldn’t recommend this to most end-users until this gets sorted out.

The web interface and the graphs that it gives you is actually quite nice. For me, the actual (almost) dealbreaker wasn’t the lack of wireless/mobile syncing (wireless power and data sync is definitely very high on my list for want-to-haves, personally), but rather that while there’s been the promise of an API/export for quite a while, there’s actually nothing (and no roadmap!) yet.

Paul Miller wrote a great piece on this earlier in the year about this, which I vigorously agree with and I won’t buy or support any self-instrumentation device that doesn’t give me full access to my own fucking biometric data.

Now, if you’ve read the last two paragraphs and are scratching your head on how/why I still have my Basis watch, well, that’s simple: there is an API, it’s just not publicly documented. If you’re an end-user looking for export, yes you are SOL and should send your Basis back and demand a refund if it’s important to you (and it should be!).

If you are a developer, simply pop up your Javascript console and look at the XHR calls to /api/v1 for nicely formatted JSON. Note: these calls are actually totally unauthenticated. That’s bad. However, since the tradeoff is easy access to my data w/ low likelihood of accidental leakage (data URLs have hashed unique identifiers), I’m ok with that for now.

Overall I like my Basis although I have an Amiigo on the way that, if it functions as promised, should be better than the Basis in pretty much every single way (sans telling time/wrist display – but that’s not so necessary anyway w/ a proper mobile app). It’s also half the price. For developers and data geeks, the Amiigo also promises to have a full SDK and actual developer support (although I hope they have their data as nicely formatted as the Basis data – it’s totally sweet).

However, the Basis is well designed, and if you’re absolutely buying something today, the Basis is by far and away the best device for those looking for serious self-instrumentation (ie not Fuel Points). The habit system is also on the right track, as well, in terms of general usefulness. However, as outlined, the B1 is also a seriously unfinished product at the moment and anyone expecting basic fitness-tracking functionality (like a mobile app/wireless syncing) will be disappointed. Early adopter caveats definitely apply.

It’s a pretty interesting time for fitness/activity trackers – I think we’ll soon be reaching a point where the sensor-suite will be more than good enough (as mentioned earlier, photometric glucose measurements and SpO2 should be possible w/ the existing sensor packages, and having wireless charging would be the last really nice bit), and the real value will be integrating with other data to create an integrated picture and assisting in behavioral modification/self-improvement. It’s also interesting seing some of the vertical applications as well. The LIT for example looks pretty neat.

UPDATE: Looks like a QS guy also reviewed the Basis and also spotted the JSON feed, and better yet, published some instructions and some code on Github for people.

UPDATE 2: I have a bunch of notes on wearables and smart watches on a hackpad

UPDATE 3: Current biggest discovered annoyance is that it’s impossible to change the Time Zone w/o going online to set it then syncing. WTF. Does no one at Basis ever fly?

In Python, you can set most request timeouts w/ socket.setdefaulttimeout(). In recent versions, urllib2 has also added a timeout field to urllib2.urlopen(). So far so good, right?

Unfortunately, while these work fine when looking up IPs or domains in /etc/hosts, this fails miserable when querying a FQDN as you’re at the mercy of socket.gethostbyname() and your DNS resolver which does not let you adjust the timeout. On my Mac this defaults to 30 seconds. It’ll ruin your day, really. (A good recent thread, old summary)

This is a somewhat common problem and you can see a lot of various workarounds (using signals didn’t work for me). The proper modern way is to probably using multiprocessing with a join(timeout) (sample) but that seemed awfully wordy, so here’s my simple one-line hack that I ended up with instead:

subprocess.check_call(['/sbin/ping','-t','1','FQDN'])

Just set 1 to the timeout you want. It’s hacky, but it works and it’s much easier and shorter – a one liner in a try block without any other libraries. Another advantage this has is that it works as it should both with DNS and mDNS (zeroconf) without any additional lookups. I’m using this for finding local machines so this is quite useful.

Some extra references:

• pybonjour, zeroconf – a couple zeroconf libs that are way overkill for what I wanted to do
• monkeypatch/custom dns – creative way to solve this
• another monkeypatch example
• dnspython – for custom resolver
• timeout w/ subprocess – you’ll need the subprocess32 backport if you need this
• tornado-dns – async dns w/ Tornado (fyi Tornado blocks on DNS for async_http calls by default – still as of late 2012)

While there are public tools like Storify that do an OK job for tweets, and I personally end up using Evernote or for most of my (private) tracking of topics, it’d be useful if there was a good tool for collecting/collating and snapshotting primary sources and making notes/comments on any particular topic (and groups of topics). Useful things would include seen-on and publish dates (a la Zotero etc). And being able to contextualize/parse interesting pieces (Evernote and Clipmarks do a pretty good job with this)

For example, for the controversy of the past few days on the whole PyCon fiasco:

* Summary: How “dongle” jokes got two people fired—and led to DDoS attacks

A series of discussions on Hacker News related to the topic:
* 2013-03-17 Inappropriate comments at pycon 2013 called out
* 2013-03-20 The PyCon Incident
* 2013-03-21 PyCon Code of Conduct changed to avoid public shaming
* 2013-03-21 SendGrid Fires Company Evangelist After Twitter Fracas
* 2013-03-21 Adria Richards, PyCon, and How We All Lost
* 2013-03-21 A Difficult Situation