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:
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:
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:
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.