SRM/Quarq/Powertap Calibration, Slope and Offset

[Michael Churchward]

Hi,

I'm interested in building a GEGPS but i'm wondering how it handles the various configuration issues relating to powermeters:

Is there a way to set the offset of a powertap/srm/quarq?
Is there a way to automatically set the offset of a powertap/srm/quarq? (like the auto-zero feature in garmin head units)
Is there a way to set the slope of an srm/quarq?

or am i way off the mark here and the GEGPS is strictly a loggerm in which case how do i get meaningful power data from it when the slope and offset numbers aren't part of the file?

Also, is there an alternative to the no-longer-produced sparkfun package tracker: http://www.sparkfun.com/products/8755 ??

Thanks,

Michael

[Justin Knotzke]

On Sunday, 4 March, 2012 at 22:05 , Michael Churchward wrote:

   Hi

 

Is there a way to set the offset of a powertap/srm/quarq?
Is there a way to automatically set the offset of a powertap/srm/quarq? (like the auto-zero feature in garmin head units)
Is there a way to set the slope of an srm/quarq?

   We never coded in the ability to send a "calibrate" request to any of the PM's but it would be a fairly trivial thing to code. If the PM in question supports the ANT+ command to calibrate, then ya, it should work. I know for the Quarq, when you send the command, it responds with the actual offset. I don't know about the others. 

or am i way off the mark here and the GEGPS is strictly a loggerm in which case how do i get meaningful power data from it when the slope and offset numbers aren't part of the file?

   You don't need to know the offset to get meaningful power data. Unless your definition of meaningful is different from mine. ;-) I know for Quarq and I'm fairly certain for Powertap, the offset numbers aren't part of the calculation for power. I'd have to check again for SRM. But I know in the tests we did, out SRM numbers were verified to be correct. 

Also, is there an alternative to the no-longer-produced sparkfun package tracker: http://www.sparkfun.com/products/8755 ??

   I don't think so. I think they had issues with it. I know I had to return at least 3 of them and the others I have are flaky.. The logomatic is MUCH more stable. I use it more then GEGPS.. The only problem with the logomatic is the crystal for the clock isn't wired separately. So when you turn off the logomatic, there goes your clock. There is a hardware workaround for this but I never got to doing it.

  J 

[djb]

A quick glance didn't leave me feeling like there was much IO left on
the logomatic for adding any other sensors or a GPS. Wait, maybe
there's one UART available so the GPS could be added, but not much
else, right?


--Donnie

[Justin Knotzke]

On Monday, 5 March, 2012 at 19:59 , djb wrote:

A quick glance didn't leave me feeling like there was much IO left on

the logomatic for adding any other sensors or a GPS. Wait, maybe

there's one UART available so the GPS could be added, but not much

else, right?

   The logomatic offers 2 serial ports.. So you should be able to handle GPS and ANT+..

   You'd have to write all the code for it of course..

    J 

[Michael Churchward]

thanks for the quick replies guys.

harking back to the old SRMs (wired, pre-ant), the data files all contain both the slope and the offset value used in the formulation of the file. these numbers can be changed in SRMWin which will then re-process the file and spit out different power numbers accordingly.

how the newer ant+ devices handle calibration is another matter i guess. my understanding is that the offset and slope are both stored in the hub/crank and used to calculate the actual power value that comes from the hub/crank in the ant message. the only problem I see is that the offset value is constantly variable with temperature so it can change a few points on every ride. I don't know that the devices can calibrate themselves without a specific instruction (maybe, maybe not) but i'm not seeing a way that GE can force (or allow) this value to be updated periodically. perhaps the offset being used for all calculations is the last one set when requested, ie by a garmin/head unit and hence is no longer valid?

yes, i think the powertap does the same thing - the response to a correct calibration is the offset value itself.

I think i should just pick up a logomatic and start playing around. if adding a calibrate signal is as simple as you suggest, justin, i would be happy to do it once i have a handle on how the code works.