I'm trying to write a BLE Server for the CPS service (Cycling Power Service). Power data is capture correctly by the client (polar watch), but I cannot get the watch to capture wheel rotation & crank rotation pairs. At least no data is shown on the watch for speed & candence. Cadence should def. be working as it works with another stagePower sensor using the same service.
I tried to capture Control Points call in case this was the root cause of being unsupported, but none occurs...
Then I thought about the issue may be in the features bits. And it's still unclear to me how these bits should be sent. Byte little-endian like data? Or LSbit -> MSbit ?
From the examples I could find for reference, it's sent in regular order, but I doubt it's the case. What I'm sending right now is :
uint8_t fBuffer[4];
fBuffer[0] = 0x00;
fBuffer[1] = 0x00;
fBuffer[2] = 0x00;
fBuffer[3] = 0x0C;
CyclePowerFeature.writeValue(fBuffer, 4);
Just for completness, here are a few characteristic data frames that are sent (captured by nRF Connect):
30002A001500000070190800E3F9
30002A001A00000004300A0067FF
30002A001C00000053380B002A02
30002A0020000000B4480C00EC04
30002A002600000065610E00700A
30002A0028000000B4690F00320D
30002C002C00000063771000F80F
30002B002F0000005A8812005F15
30002A0033000000F89813001818
30002A003700000059A915009C1D
30002B003D0000000AC217001923
30002B003F00000059CA1800D325
30002B00420000009DD819008E28
30002A00460000001FE91B00062E
Flags : 0030 (bits 4 & 5 activated) to activate wheel & crank data pairs Power output : 42-43 Watts (2A00 - 2C00) Calculated speed from this set (wheel size : 2.35m) : 11.9-16.4 kph Calculated cadence from this set : 87-89 RPM
Wheel details : Revolution counter : 15000000 -> 46000000 (ie 15->46 in hex B-endian / ie : 21->70 in decimal) Revolution timestamps : 7090 -> 1FE9 (ie 1970->E91F in hex B-endian / ie : 6512->59679 in decimal - 1/2048th of s)
Cadence details : Crank counter : 0800 -> 1B00 (ie 08->1B in hex B-endian / ie : 8->27 in deciaml) Crank timestamp : EFF9 -> 062E (ie F9E3->2E06 in hex B-endian / ie : 63971->11782 in decimal - 1/1024th of s)
Decoded values for each frame look OK for me following the logic :g
Tried to contact Polar (who signed off the CPS specs...) to get some infos, but they only replied "we are compatible with X and Y sensors"
In your case, the specification indicates endianess.
According to the Cycling Speed and Cadence Service, Chap. 1.7 Byte Transmission Order, all characteristics used with this service shall be transmitted with the least significant octet first (i.e., little endian).
The other part of the specification Cycling Speed and Cadence Profile may also be of interest.