getTimerPeriodUs and timer rates

[tylerjw]

I see there is a getTimerPeriodMs function in the documentation, why isn't there a getTimerPeriodUs? Secondly. The timers can be set to run slow, medium, or fast. Is there documentation of what these rates or and what period would cause them to overflow?

[brentp]

The timer period functions returns the amount of time between pulses - it's not designed to measure actual pulse width.

The slow/medium/fast sets the base timer clock. Typically medium is what's used for measuring things like RPM.

[jdawson]

The timer period functions returns the amount of time between pulses - it's not designed to measure actual pulse width.

The slow/medium/fast sets the base timer clock. Typically medium is what's used for measuring things like RPM.

Hi brentp - per the OP's original question... would it be possible for have an API added to allow access to the timer period in micro seconds? getTimerPeriodUs would allow for much more accurate RPM calculation than is currently possible.

Example: 2006, pre-CAN Elise; connecting the cylinder1 coil pack signal to Freq1 results in 120rpm resolution (function is probably rounding to the nearest integer frequency and the multiplying by 60 * revolutions per firing event).

API "getTimerPeriodMs" results in the nearest integer period value. Using this value to calculate RPM yields reasonable resolution at low engine speeds. However, at high engine speeds, the whole value period rounding causes significantly worsening resolution. 1ms out of 70ms at idle is a smallish error. 1ms at 6ms period near redline is a much larger error.

If we could access the timer period in microseconds via an API, a scripted RPM calculation could yield quite accurate results.

[brentp]

Sounds useful, we'll see if we can get it in the next firmware release.

Logged here: https://github.com/autosportlabs/RaceCa ... ssues/1049

Thanks for the suggestion!