non-linear output of accelerometer solved... sort of

spoke with tom a bit today about the issue of non-linear output from the step detector.

he mentioned two problematic areas: the delay that i take after a step is detected, and the fact that i'm not taking the entire length of the pulse into account.

basically, i'm only looking at the t1 part of the pulse, the part where it's high. as soon as i've read all of the high part of the pulse, i punt, determine if the pulse was wide enough to count as a step, then dump the number of samples i'd read since the last step i detected.

so, t2 (the length of each pulse in total) isn't static. it's period changes based on how much acceleration is being applied, which in turn means the sample rate isn't constant. i went home and made some code changes to have it output t2 constnatly and started playing moving the accelerometer wildly. turns out t2 varies only a small amount, and not in a way that would create the non-linearity of the output. basically, the variation of t2 isn't really a big deal, and 99% of the time t2 is constant.

i wrote some code to have the step detector do nothing but loop as fast as possible reading the pulses, and blink the led after it had read X number of pulses. i then started trying to find how many samples were actually being read in 1 second. i put on a metronome, and found that about 138 samples between blinks = 1 second between blinks, more or less. it was close enough that the desynchornization period between the led and metronome took about 1 min. close enough for me.

SO. that means that, theoretically, if the accelerometer IS putting out a linear change in pulse width, i should be able to set the pic to blink an led every 69 samples and it will blink the led twice as fast, in fact, exactly 120 bpm. so i had it do that, set the metronome to 120, and guess what? almost perfect. 68 samples is close to 120 bpm, but hey, an error on that level is probably my eyes and is completely acceptable.

so the acceleromete IS outputting a linear curve. 138 samples = 60 bpm, and 68 samples = 120 bpm. yay.

i then tried to find the section of my code that would break this linearity. once i got to the delay between steps (after a step is detected, do nothing for about 30 samples so that we don't get double step detection for a single step). i could tap with 60bpm and get about 137 samples on average, and at 120 bpm i could tap the step detector and get about 70 samples between steps.

now i have to figure out why delaying for 30 samples after a step is detected screws things up. my guess is, as soon as a step is taken, t2 is changing the most. 30 samples at 120bpm may not be as long as 30 sample at 60bpm because t2 is sort of bouncing around while the signal settles down from the step.

perhaps filtering somewhere else less time-critical is a solution. i could simply have my python program on the gumstix ignore steps where only a few samples have passed. after all, it seems that 300 bpm is allows 30 samples to be read between steps. not many people can run 300 steps per minute (thats five steps every second) unless you're really sprinting. i could just make an upper bound on things, so that any step that has less than 30 samples between steps is just ignored.