1

A Bluetooth LE Cycling Speed and Cadence sensor sends measurements data according to the Gatt characteristic measurement data. For the crank cadence this is:

  • Cumulative Crank Revolutions - an unsigned 16bit integer
  • Last Crank Event Time - an unsigned 16bit integer with 1/1024s resolution

I'd like to understand how the Last Crank Event Time is defined. The documentation makes it sound like a timestamp but because it is a 16bit integer at 1/1024s it overflows after about 1 minute. So I suspect it is actually a time interval. Below is a sequence of events on a time scale. Message B sends n+2 for the number of crank revolutions but what is the Last Crank Event Time for B?

enter image description here

Christian Lindig
  • 1,216
  • 1
  • 9
  • 24

1 Answers1

5

In section "4.4 CSC Measurement" of the Cycling Speed and Cadence Profile document it says:

The Collector shall take into account that the Wheel Event Time and the Last Crank Event Time can roll over during a ride.

so my reading of this is that it is a time stamp but as you only need to know the difference between the last two readings it can still be calculated even if it overflows.

There is more information in the Cycling Speed and Cadence Service (CSCS) document that states:

The ‘crank event time’ is a free-running-count of 1/1024 second units and it represents the time when the crank revolution was detected by the crank rotation sensor. Since several crank events can occur between transmissions, only the Last Crank Event Time value is transmitted. This value is used in combination with the Cumulative Crank Revolutions value to enable the Client to calculate cadence.

The Last Crank Event Time value rolls over every 64 seconds.

Calculation of cadence at the Collector can be derived from data in two successive measurements. The Collector calculation can be performed as shown below:

Cadence = (Difference in two successive Cumulative Crank Revolution values) / (Difference in two successive Last Crank Event Time values)

ukBaz
  • 6,985
  • 2
  • 8
  • 31
  • So your answer would be t4 should be sent as part of B for the Last Crank Event Time? – Christian Lindig Oct 31 '20 at 17:53
  • The CSC Measurement characteristic values sent at B contain the crank rotation count and the timing of that count. This allows the calculations of RPM/Cadence since the last the characteristic notification at point A. What I don't know is whether t4 (n+2) is part of that transmission. And to a certain extent it doesn't matter because the CSC Measurement gives you a timestamp and a count which allows you to do the calculation. I can imagine the scenario where the count has increased by the time you get a measurement but it doesn't matter as you have the time of that count. – ukBaz Oct 31 '20 at 20:00
  • 1
    Thanks. So even though 16-bit timestamps frequently overflow they still can be used by the receiver to compute the timespan t4-t1. And together with the difference in absolute crank revolutions, the cadence can be computed. – Christian Lindig Oct 31 '20 at 20:25
  • It should also be considered that the crank revolutions is also designed to rollover albeit much less frequently than the last event time. Wheel revolutions is not intended to rollover, however I've had speed sensors reset (revs =0 and time = 0) during a ride when stopped at a traffic signal. This results in a big spike in the data. Detecting resets versus rollovers can be tricky. – trukvl Oct 28 '22 at 15:17