Pm3 Specific Features

[old] bbsportz · Post by **[old] bbsportz** » May 18th, 2005, 9:25 pm

It would be nice if at the higest frequency of polling the PM3 device (around 30-20hz) the key variables were changing at a similar or faster rate. eg Time is resolved to 1/100th of a second but updates/refreshes every 100ms (10hz). Yet we poll at the maximum frequency available (30-25hz). Its a simialr case for Distance. However Stroke State is thumping along at 100hz refresh. Any chance of increasing the frequency of update of: 1: Time from 10HZ to the same as StrokeState (SS) ie 100HZ so that we can use this as a TimeStamp against SS change instead of the internal high frequency PC Timer. 2: Distance from 10HZ to 100HZ for the same reason above. 3: Expose the 'kg/lb' graphing variable as a pollable interface at 100HZ for the same reason above. MarkO and MarkA

[old] mlyons · Post by **[old] mlyons** » May 23rd, 2005, 11:05 am

<table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><div class='genmed'>QUOTE(bbsportz @ May 18 2005, 08:25 PM)</div></td></tr><tr><td class='quote'>It would be nice if at the higest frequency of polling the PM3 device (around 30-20hz) the key variables were changing at a similar or faster rate. eg Time is resolved to 1/100th of a second but updates/refreshes every 100ms (10hz). Yet we poll at the maximum frequency available (30-25hz). Its a simialr case for Distance. However Stroke State is thumping along at 100hz refresh. Any chance of increasing the frequency of update of: 1: Time from 10HZ to the same as StrokeState (SS) ie 100HZ so that we can use this as a TimeStamp against SS change instead of the internal high frequency PC Timer. 2: Distance from 10HZ to 100HZ for the same reason above. 3: Expose the 'kg/lb' graphing variable as a pollable interface at 100HZ for the same reason above. MarkO and MarkA </td></tr></table> Gentlemen, Your statement that the time and distance updates are occuring at a 10Hz rate is incorrect. Also, the stroke state is not updating at 100Hz either. All three of these items are driven by the angular velocity of the flywheel which is providing three equally spaced timing markers (e.g., tach inputs) per rotation. Since these inputs are used to determine time/distance/stroke state, the update rate of these values is a function of the flywheel speed. For example, at 2000 rpms a tach input occurs every 10 msec whereas at 1000 rpms it's every 20 msec. At a 1:35 pace/34 spm a tach input is occuring every 13-15 msec. At a 3:00 pace/22 spm a tach input is occuring only every 25-28 msec. If you poll the PM3 at its maximum rate of 25Hz - 30Hz the fractional part of the WorkTime (1/100th second resolution) should demonstrate the changing time as a function of flywheel speed and effective poll rate. The same holds true for the distance and stroke state. The next Beta release of PM3 firmware (due out in the next several days) will have the ForcePlotData available. The updated SDK documentation will describe how to access the data and its time-sampled characteristics. Thanks for the feedback, Mark

[old] bbsportz · Post by **[old] bbsportz** » May 24th, 2005, 10:29 pm

Thanks very much for that reply. It has straightend out of a few misunderstanding for us. Its an understatement to suggest that we are excited about the coming release of the ForcePlotData. MarkA and MarkO