I want to identify the BLE wheel and crank sensor data from the 11-bytes data from a mobile application we have developed

Question

I want to identify the wheel and crank sensor data from the 11-bytes data. I have tried to parse the 11-bytes hex data which i got in our mobile application as per the split ups in the link below.

https://www.bluetooth.com/wp-content/uploads/Sitecore-Media-Library/Gatt/Xml/Characteristics/org.bluetooth.characteristic.csc_measurement.xml

For instance i have tried the following,

Hex Data : 0x03 6D010000 FC7E 2C01 F87E

Flag-03 ->0000 0011 -> 8bits so both are true hence we can get the wheel and crank's respective values.

Cumulative Wheel Revolutions- 6D 01 00 00 -> 32bits so converting it in decimal we get -1828782080

Last Wheel Event Time- FC 7E -> 16bits so converting it in decimal we get - 64638

Cumulative Crank Revolutions- 2C 01 -> 16bits so converting it in decimal we get - 11265

Last Crank Event Time- F8 7E -> 16bits so converting it in decimal we get - 63614

I am unable to get the actual wheel and crank measurement values from the BLE. Is the above procedure what i have understood from the reference link which i have followed is correct ? or am i wrong elsewhere ? I have put our maximum effort to dissect and parse the data but unfortunately I am unable to reach the solution. Kindly guide me through this process. What do we have to do to get the right value ? Like am i supposed to multiply it with some number ? I have tried with different combination yet not able to get. The device i am using is the SunDing515 cycling speed and cadence sensor with Bluetooth low energy.

Teneshatenesmus

Answer 1

From your data and from the data sheet, we see that the values are using unsigned integer. (uint16 or uint8). None of your value should be negative.

Usually, bluetooth values are little endian instead of big endian. Example:

6D010000 should be read 00 00 01 6D = 365

FC7E should be read 7E FC = 32508

2C01 should be read 01 2C = 300

F87E should be read 7E F8 = 32504

Areopagite

Answer 2

I don't know if you figured out what you were looking for at this, but the endian thing really helped me out. The basic process you need to do is read the data twice. Then use the difference in time and the difference in crank revolutions (i only did cranks) multiply by 1024 (as per the spec).

so assuming that you have from the little endian example: 300 for the Cumulative Crank Revolutions (CCR) and 23504 as the Last Crank Event Time (LCET) (Unit has a resolution of 1/1024s.) . Read the data again and you will get a slightly higher CCR (say 301 or 302) and a much higher LCET say 24704. Then subtract the more recent LCET from the older one (24704-23504) to get 1200 and the Higer CCR from the lower CCR (302-300) to get 2. Then multipy the CCR by 1024 and divide by the difference in the LCET. Giving you 1.7. That is your rotations per reading. Then multiply by 60 to get Rotations per minute. (102.4)

Drat

yes sir thanks. I have connected and completed the project by calculating the speed in kmph and rpm through the crank revolution. – Teneshatenesmus

Thanks, this solution helped me a great deal with the cadence calculations. – Fu

Answer 3

Dennis Rutherford's answer is the right direction, but in my opinion we should take into account the nature and mechanics of cycling: if someone is climbing uphill with a 20 rpm (I know this is extreme but it can happen!), then that's less than 1/3 crank rotation per seconds. So multiplication by 60 would yield too highly variable data in that case.

The Event times have high enough resolution (1/1024s), but the wheel and crank revolutions are just simple counts, because traditional magnetic sensors cannot provide fractional revolutions.

Therefore my solution is a sliding window to calculate the instantaneous cadence: if we wait enough time (20-30 seconds) then we can settle for a less instantaneous but more stable reading.

It's also important to deal properly with the overflow of the Event Time values, because with UInt16 bytes it overflows every 64 seconds. So if the last event time is lower than the first event time then an overflow happened, and for our calculation we'd need to bump the last event time by 64 seconds. Also note that our time window cannot be too large, otherwise multiple overflows could fuse together and the calculation will be off.

Lastly: please check the 1826 GATT Service's 2AD2 "Indoor Bike Data" GATT Characteristic, because if you are lucky (I was not) then you'll get an instantaneous cadence supplied there and you'll save yourself from all these shenanigans.

Ation