BLE heart rate speed

[Troels]

Hi, I need to make a BLE system which sends ADC values from a chip to a receiver kit.

The example most closely resembling this functionality seemed to be the heart rate collector example, which I ran on two devkits without issues. I then ran the adc_simple example, and after verification, added the modules to the heart rate sensor code. After tinkering with the ADC code a bit, I made it possible to send the ADC result instead of the simulated values in the example, and removed all of those. I then removed battery, rr interval, and sensor contact timers, their associated interrupt handlers etc. I set APP_TIMER_OP_QUEUE_SIZE to 1 since only one value is necessary now, and HEART_RATE_MEAS_INTERVAL 10 times lower to increase speed.

When I test this new sensor program with the heart rate collector and Termite, it sends out the first 580 adc values quickly, but then slows down a lot, sending 3 values out every ~second or so. I suspect this could be caused by a memory leak filling up the sensor chip's RAM, but I'm not sure?!

Also, is it possible to completely remove the heart rate timer, and just send whenever a new ADC value has been calculated? Would probably speed up execution to be able to remove that interrupt. Whenever I tried this, I got several compilation errors.

Sensor code: main.c

Collector code: main.c

[Troels]

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.

[Troels]

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.

[Stian Røed Hafskjold]

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.