Monthly Archives: November 2013

Fitbit Force Review

I was excited to receive my Fitbit Force in the mail last week, because I’m constantly looking at my Flex to see what time it is (there is, of course, no clock on the Flex, so this habitual action frequently leaves me feeling quite stupid). The Force is definitely a bit heavier and almost twice as wide, but the quality of the display was excellent and the ability to interact with the device with a button rather than crude tapping gestures was great. Unfortunately, the Force is not even remotely waterproof! I wore it accidentally in the shower for 20 seconds before remembering to take it off, and the device shorted out. For about half a day, the Force flickered on and off while intermittently displaying the Fitbit logo, and condensed water was visible inside the display. Although it ultimately started working again, the problem reemerged after 5 minutes of washing dishes so I stopped wearing the device.

Condensed Water Inside the Force

Condensed Water Inside the Force

Given the durability of the Flex, I was shocked that a device which feels just as rugged can’t even handle a splash of water. Having a display to show time and step count is a great feature, but if you can’t even wash dishes with it, I think there’s a brand-damaging design flaw in this product. The whole point of the Flex is that it’s thoughtless, and simply disappears into your life for days at a time until it needs to be charged. If getting my activity tracker wet is instead tantamount to spilling water on a mogwai,  that completely changes the use case and makes it stick out like a sore thumb in my daily routine. I’ll be returning Fitbit’s latest creation, and leaving “the force” to Starwars…

Advertisements

Sample Signal Selection

While reviewing some previous posts, it occurred to me that my methodology for identifying cross correlation sample signals – i.e.,  choosing a “representative” signal at an arbitrary point in time for an arbitrary duration – was not very scientific. Using any discrete sample walking signal (rather than the average walking signal) might result in lower than expected correlations. So, I decided to build a script which would automatically extract an average sample signal from a specified window of data, in the hope that it could be used in the future to generate better correlations.

I used the data from a previous post, and found a window of data that I consider to be representative of general walking, from time 160 < t < 180:

Plotted Data from All 3 Axis from Time 160 < t < 180

Plotted Data from All 3 Axis from Time 160 < t < 180

There are a lot of interesting features in the plot above which could be used to identify a step – for example, each Z axis peak seems to be accompanied by a Y axis peak, and every other local minima in the X axis seems to correspond to a peak in both the Y and Z axes. I will ignore these for now, and focus on the X axis, where it is clear that period of the signal is two peaks long, i.e. there is a larger peak, a smaller peak, and then the signal repeats. This makes sense in the real world, in which the force the logger experiences in the X axis is larger from the step of one foot (presumably, the step which occurs on the same side of the body on which the logger is being worn) than in the other. I created a script, signalextractor.m, which takes the data from an input window, runs a peak detection, and then extracts the data in two-peak long periods. Plotted on top of each other, the data for each two-step period looks like this:

Data from Multiple Steps in the X Axis

Data from Multiple Steps in the X Axis

I was very pleased with the consistency between the various periods shown in the plot, although the discontinuity between the beginning and ending values is disconcerting. I will assume however, that this is simply due to the low sample rate, and that if I had sampled at the logger’s maximum rate of 200Hz, the fist and last values for each plotted period would be nearly the same.  I then used this extracted data to produce an average sample signal, which is plotted below ontop of the underlying sample data points:

Average Signal ontop of Multiple X-Axis Two-step Cycles

Average Signal ontop of Multiple X-Axis Two-step Cycles

I now have a useful script which I can use in the future to generate an average sample signal, as well as a means for investigating the standard deviation of accelerometer readings at each point in the step cycle. It might be useful in a future step counting algorithm, for example, to reject any signal as a step if it falls outside of a given range at a given point in time.

DIY Medical Implant

Many thanks to TKM for letting me know about this DIY implant a bio-hacker recently embedded into his arm. As he aptly pointed out, I will never be this hardcore, although I’d like to think I would have done a better job with those sutures…

Coors Light & Fourier Transforms

I wanted to use the same methodology from a previous post (Coffee Run) to analyze a new set of data,  so I took a  different route  around the block to buy a six pack of Coors Light at the corner store. I also wanted to test out my iPhone 5s’ M7 motion co-processor, so I kept my phone in my left pant’s pocket and used the Argus app to note the number of steps (any app should give the same results, since it’s just calling an API from the M7).  I used the correlationwindower.m script from an earlier post on the raw data (beerrundata), and generated the following result using the first block of steps just before t=100 as the sample data:

Plot of the Correlation of a Sample Signal (91<t<97) With the Dataset (blue) ontop of the Raw Data (Green)

Plot of the Correlation of a Sample Signal (91<t<97) With the Dataset (blue) ontop of the Raw Data (Green)

Immediately, you can tell something is wrong because from 260 < t < 310 on the X axis, when I am clearly standing in line not moving, the correlation is really high. This led me to think about micro-oscillations that might be showing up in the noise during periods of non-motion, so I wanted to look at the data in frequency rather than time. I built a simple script to perform a discrete Fourier transform on the data using the fft command in Matlab (quickdft.m), and produced the following plot:

Fourier Transform of the Data from Each Axis

Fourier Transform of the Data from Each Axis

I was pretty excited by this data. First, the data from the three axes are all very consistent with each other, which gave me a lot of confidence that I can ultimately build an algorithm that can extract motion from any axis (versus just the X axis, currently). Secondly, I thought it was very interesting that the peaks for the Y and Z axis were greatest around 1 Hz, while the X axis peak was greatest at around 2 Hz. I timed my gate, and found that each step takes about a half second, so what must be going on is that the X axis is oscillating with each step, while the Y and Z axes are oscillating with each stepping cycle (i.e. both the left and right foot). This makes sense, given that my hand was positioned as follows:

Logger Positioning During Normal Walking Motion

Logger Positioning During Normal Walking Motion

So, you get an acceleration in the X axis with every step as you bob up and down while walking, you probably get some lurching back and forth in the Y axis which occurs with each step pair, and in the Z axis you sway side to side a bit with each step pair since no two legs are exactly the same length. It is also interesting to note the 2Hz frequency component of the Y axis signal, which is probably capturing some of that same individual step motion as the X axis because some part of my the raising and lowering with each step is actually occurring in the Y axis. At the same time, the absence of any 2Hz signal in the Z axis is very comforting as it reinforces the idea that the Z axis is experiencing a side to side sway.

I thought that perhaps creating a band pass filter might solve the problem of the phantom correlation data during periods of no motion; perhaps there was a high frequency noise signal with lower frequency elements that were seeping into the data. So, I created the following filter in Matlab’s filter design tool, which was launched with the fdatool command.

A Simple Bandpass Filter

A Simple Bandpass Filter

I used the bandpass filter on the X axis raw data, and produced the plot below:

X Axis Data After Bandpass Filtering

X Axis Data After Bandpass Filtering

Running a simple peak detection on this data  ([x_pks, x_locs] = findpeaks(xf,’MINPEAKHEIGHT’,.1,’MINPEAKDISTANCE’,10);) counted 549 steps, which is pretty close to the 539 recorded by my Fitbit Flex and the 536 recorded by the iPhone 5s. I then changed the parameters of the filter to focus even more tightly on the 2Hz frequency with the following settings (fstop 1.5, fpass1 = 1.8, fpass2 = 2.2, fstop2 = 2.5), and counted only 507 steps, which led me to believe that the previous answer was mostly just lucky, although it is possible that tightening the filter might have excluded steps which occurred at a slower pace. Overall, I was a little disappointed with this experiment in frequency, but I learned a lot which can hopefully be applied to future experiments.

Interesting post from FitBit’s Blog

Found this really interesting blog post (pdf here: Fitbit 11-23-10) from Fitbit’s chief data scientist explaining how steps do not necessarily equate to calories. Will have to check out the two authors mentioned in the post as well….  Of course, I need to figure out how to reliable detect steps first! It had not occurred to me to look for academic research on the the matter, however, so perhaps I should look for some literature on the subject before blinding performing my next analysis.