@Alang -- thanks for your help! You're correct on the laces placement. Avoiding something that's 'too' far down is best.
@runnerdave, @brebre -- good question(s). I'll try to shed light on it from a couple perspectives -- 1) how we're measuring angular metrics (like pronation), and 2) gait event detection / sensor drift.
1 -- The metrics (like Pronation Excursion FS->MP) are measured by looking at the difference between the instantaneous angle at the first gait event (FootStrike) and the second gait event (MaxPronation in this example). The difference is then what's reported. We went this way for a couple reasons, but the biggest was because we can then be 'terrain' independent. You can see how much roll/pronation your foot is going through even on a highly crowned road. The FootStrike Type algorithm uses the PitchExcursion between FS and MP. It's looking at how much (and in what direction) your foot is pitching between those gait events. Again, with the goal of being terrain (in this case, that includes gradient) independent.
2 -- The key to the metrics is the accurate detection of the gait events. The per-footstep algorithms are looking for the detection criteria for each gait event (based on values from the accelerometers, gyroscopes, and sensor fused angles). Placement does matter, but only in as much as the Heel location wants to be 'close' to vertical and the Laces location wants to be 'close' to around 35deg. 'Close' in these cases being +/-15deg. As @Alang noted, the biggest differences we've seen is in Laces mounting configurations with the sensor mounted far down the laces, where it's orientation is nearly horizontal. The other confounding variable is how the sensor fusion algorithms work within our digital motion processor. It is running a Kalman Filter to continuously compute the absolute orientation based on the (highly accurate) readings from the gyroscope, using the accelerometers (and Earth's gravity) to control the natural drift in the gyros. As @runnerdave noted, a sudden change in mounting orientation 'during' a run can muck with the local calibration that was done at the very beginning of the run.
This is all a long-winded way of saying that sensor placement can matter, but the design of the system should be pretty tolerant. Using the new Compare Tool, it's now possible to compare A vs. B data, filtering down to runs that are at similar paces, as Pace can (and does) have a significant impact on just about all of the metrics.
Hope this helps.