BLE CSCS cadence value problem

[cavalihno]

HI

I am working with BLE CSCS example, and I found some problem during read cadence value. Simulator is changing values and I am observing situation: if cadence value is less than 50rpm occasionally shows 0rpm. I think that it occured when cumulative_crank_revs is not incerement during 1 seceond (BICYCLE_POWER_MEAS_INTERVAL).

Have anyone meet the same problem ?

[cavalihno]

Hi, I am using SDK12.1.0.

[Hakon]

Ok, can you please specify the following?

Is it the "ble_app_cscs" example  you are referring to?

By "cadence value", do you mean crank rev?

What is "BICYCLE_POWER_MEAS_INTERVAL"?

[Hakon]

Hmm, that's strange. I installed the wahoo fitness app and tried the example and it worked for me. It reads 40 rpm all the time. Perhaps you can try reinstalling the SDK, and make sure you download it from this location http://developer.nordicsemi.com/nRF51_SDK/nRF5_SDK_v12.x.x/. Then you can compile the example unmodified and see if it works, and if it does you can then try to modify it and see if it still works.

[cavalihno]

Try to set other values from range 0 - 50rpm;

[cavalihno]

Still the same effect.stock example from SDK15, s132_nrf52_6.0.0_softdevice

Please try wit Wahoo ultility

[Hakon]

I tried it, and I got the same result as you. It happens because last_crank_event_time isn't updated every time the measurement is sent to the phone application. This happens if the RPM is below 60.

If you want to know why, read this file

https://github.com/NordicSemiconductor/Android-nRF-Toolbox/blob/master/app/src/main/java/no/nordicsemi/android/nrftoolbox/csc/CSCService.java

The crank measurement is handled in onCrankMeasurementReceived(). As for the Wahoo application, I assume the behavior is similar to nRF toolbox and that's the reason it reads 0 most of the time.

[cavalihno]

What do You think about this solution (which works correctly for everyone third party app's):

    // Calculate simulated cadence values.
    p_measurement->is_crank_rev_data_present = true;
    degrees_per_sec = RPM_TO_DEGREES_PER_SEC * RPM;

    crank_rev_degrees     += degrees_per_sec;
    cumulative_crank_revs += crank_rev_degrees / DEGREES_PER_REVOLUTION;
    crank_rev_degrees     %= DEGREES_PER_REVOLUTION;

    if(cumulative_crank_revs > last_cumulative_crank_revs){
      p_measurement->cumulative_crank_revs = cumulative_crank_revs;
      p_measurement->last_crank_event_time = event_time + (1024 * (degrees_per_sec - crank_rev_degrees) / degrees_per_sec);
      last_cumulative_crank_revs = p_measurement->cumulative_crank_revs;
      last_last_crank_event_time = p_measurement->last_crank_event_time;
    }else{
      p_measurement->cumulative_crank_revs = last_cumulative_crank_revs;
      p_measurement->last_crank_event_time = last_last_crank_event_time;
    }

    event_time += event_time_inc;

Is it correct in terms of Gatt specifications ?

[Hakon]

https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.cycling_speed_and_cadence.xml

It looks to me like it's fine.