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

[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.