BLE heart rate speed

RE: BLE heart rate speed

Stian Røed Hafskjold — Wed, 23 Nov 2016 11:47:05 GMT

By default, in the hrs example, the connection params are updated after 5 seconds since it doesn't need a fast connection interval when only transmitting hrm data every second. So it starts out with a short connection interval (decided by the central in the connection request) so that service discovery, bonding etc. happens fast, then the peripheral (or central) can request a different connection interval which is more suitable to the application. So as you've already done, you should change the MIN/MAX_CONN_INTERVAL params to whatever is suitable to your application.

It is worth noting that MIN/MAX_CONN_INTERVAL is used only as a guidance for the central. So, the peripheral sends out a connection params update request after PARAMS_UPDATE_DELAY seconds, with the desired min/max. Then it's up to the central to decide what to do with this. The behavior changes between different central implementations; i.e. Android, iOS, etc. For example, iOS does not allow connection interval shorter than 11 ms, unless it is a HID device. Android allows 7.5 ms as minimum (but I think this is phone model dependent). nRF connect should follow the peripherals request regardless.

RE: BLE heart rate speed

Troels — Wed, 23 Nov 2016 09:51:24 GMT

I fixed it, but I'm not actually sure how... I set APP_ADV_INTERVAL to 40 (25 ms), and the MIN_CONN_INTERVAL and MAX_CONN_INTERVAL to the same values in the sensor and the receiver, 7.5ms and 30 ms respectively. Disabled MITM checking on the receiver, and changed the FIRST_CONN_PARAMS_UPDATE_DELAY to 30 s on the sensor (to avoid negotiation while data is being transferred). I suspect one or more of these parameters may have caused the slowing down of the execution. If you come here from searching for a similar problem, try fiddling around with these numbers; notice how it goes wrong below certain thresholds, and find values that work through trial and error.

RE: BLE heart rate speed

Troels — Tue, 22 Nov 2016 12:32:45 GMT

The problem persists, has anyone had this problem before? I suspect something in the BLE stack has to be cleared to avoid this. Tested earlier with an oscilloscope connected to the ADC, and it seems that even during the "fast" initial period, the data transfer is only happening at 125 Hz which isn't nearly enough for what I need.