## 100 Step Trial

In order to test the logger in a real world situation I needed to mount it. I chose the wrist as the test location, so that its data could be easily compared to that from a FitBit or other activity tacker. I bought several wrist bands from Amazon, and used electrical tape to secure it to \$5 nylon band. I thought this would only be a trial solution, but despite the clunkyness of the mounted logger, it actually turned out really well and there was no need to improve upon the mount.

Once mounted on my left wrist, I had to decide what to do with my arm while walking. I chose to hold my phone in the monitored hand and walk with my arm stretched out in front of me as shown below. I wanted to keep the step signal as simple as possible and avoid the introduction of any swaying arm motion back and forth at this point. Figured holding my phone would give it additional inertia and help damp out any swaying back and forth (in addition to allowing me to see my fitbit step count).

With my arm held steady as shown above, I recorded a brief sample of data at 25Hz while standing still in order to see what the baseline measurements for the logger mounted in this location were. I produced the plot below, which includes the average values for the X, Y and Z axes from time t = 5 to t = 17.

The change in the forces at the beginning and end of the plot makes sense, as I had to activate the logger with a magnet while looking at it as you would a watch, and then roll my wrist over to hold the phone as shown in the previous photo. I then had to roll it back to turn the logger off with the magnet at the end of the plot, which took a bit longer. I was initially concerned that the sum of the three highlighted forces did not equal 1, because in a previous post , where the device was sitting at rest on a table, the sum of the all three forces was always approximately equal to 1. I then realized, of course, that is the vector sum of the forces which should be equal to 1, i.e. sqrt(X^2+Y^2+Z^2) == 1. This calculation was not necessary in the first post because the static force of gravity was always parallel to an axis. With fractional components of the gravitational force in each axis as in the above, however, it is extremely important, and the vector sum of 1.0152 for the three values above gave me sufficient confidence in the device to proceed.

With my hand positioned as described, I walked exactly 100 steps at a brisk pace along a flat gravel road while wearing flip flops. My FitBit Flex recorded 101 steps, which is pretty close, and may actually be the more accurate number as I could have miscounted somewhere. I analyzed the raw data (DataPost2) in Matlab, scaled it, and produced the following plot with the mean values for each axis from t = 29 to t = 84 seconds superimposed:

The first thing that jumps out in the plot above is that the X and Z axes have flipped position. I think this must be due to a slightly different hand position while walking, which is supported by the very different mean values that the axes are experiencing. Although there was also motion introduced into the data here, this is probably not the primary cause because even during the period of non-motion which occurs after the steps from about t = 85 to t = 110 seconds, the X and Z axis are still flipped. Regardless, trying to compare the two plots in this post based on something as vague as my general arm position is not a good use of time – I will just assume the data logger is correct.

As part of my first real analysis of accelerometer data, I thought I would just do a simple peak detector to see if I could get some code running in Matlab. I created a Matlab script (myfirstpeakfinder) which to accomplish this, which generally runs as follows:

1. Load raw data into Matlab; scale to G units
2. Run the script, which will prompt the user for the start and stop time of the period they would like to analyze in the data, as well as for the accelerometer sampling frequency.
3. The script then uses the findpeaks function built into matlab, and passes it inputs around the minimum peak height and the minimum distance between peaks (‘MINPEAKHEIGHT’ and ‘MINPEAKDISTANCE’). I used the mean value of the data for a given axes in the given time frame as the minimum height (so as not to double count cycles), and set the minimum peak distance to 10 samples. In the future, it would be interesting to run a FFT on the data, figure out what the average frequency of my walk is, and then have that data inform the minimum distance between steps. But let’s just keep it simple for now….
4. The peak data are then plotted back onto the original input data, which have been cropped by the start and stop times.
5. The number of Peaks, aka “Steps”, are then displayed for the data from each axis, along with an average of all the axes.

By selecting only the cleanest portion of the data, from time t = 29 to t =  84, and keeping the min distance between peaks at 10 samples, I was able to generate the following plot: 3 Axis Plot From Mounted Sensor – (100 Steps, Analyzed with myfirstpeakdetector.m)

The diamonds indicate detected peaks, and the the data for each axis were as follows:

Now, there are obviously many issues with the algorithm, but it felt pretty damn good to achieve the same accuracy as my flex (+/- 1 Step) on the very first trial! Of course, taking a larger bite of data completely blows up the script, and inputting a minimum peak distance other than the one I serendipitous happened to input on the first trial dramatically decreases the accuracy. But – it’s a start. The next thing I would like to do is create an aggregate metric for motion in excess of 1g, and use that to inform the peak detector… more to come on that. But for now, I thought I would also include a sensitivity analysis showing how the average number of steps calculated from t=29 to t=84 is effected by the minimum step distance changing over a series of values: Sensitivity Analysis: Minimum Number of Samples Between Steps versus Average Number of Steps Calculated