Hello,
I am testing the ble_app_hrs project on two eval boards, with s110 and s120. Everything works. If I power-off the peripheral board (s110), it seems that the master board restart scanning around 5 seconds later. Is there a way to restart scanning earlier ? What is the shortest time ?
Thanks,
Olivier
I'd again suggest that you reread the question I linked to. As you should be able to understand from that, having a supervision timeout shorter than the connection interval is meaningless.
Normally, I'd recommend to keep the supervision timeout at least 3*(slave latency+1), to allow for some packets lost without considering the link lost. This is however dependent on what is most important for your application.
To be able to successfully make a BLE product it is essential that you thoroughly understand the parameters involved, so I'd recommend you to spend some time reading up.
I have read it ten times ...
Please, can you provide me values in order to solve my use case: as soon as (few ms) the peripheral is power on, the Central connect to it (connection led on) as soon as (few ms) the peripheral is power off, the Central connect to it (scanning led is on)
In peripheral side I have:
#define MIN_CONN_INTERVAL MSEC_TO_UNITS(500, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(1000, UNIT_1_25_MS)
#define SLAVE_LATENCY 0
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(4000, UNIT_10_MS)
In central side I have: #define CONN_MNGR_MIN_CONNECTION_INTERVAL MSEC_TO_UNITS(7.5, UNIT_1_25_MS) #define CONN_MNGR_MAX_CONNECTION_INTERVAL MSEC_TO_UNITS(30, UNIT_1_25_MS) #define CONN_MNGR_SLAVE_LATENCY 0 #define CONN_MNGR_SUPERVISION_TIMEOUT 4000
There is no magical values that I can give you that will suddenly solve your problem exactly the way you want. You will have to understand the parameters involved, and tune them for your use case.
As far as I can see from the snippets you post here, you haven't changed the connection supervision timeout, which "determines the timeout from the last data exchange till a link is considered lost", as explained in the question I linked to. To get a quicker disconnect event to your application, you'll therefore have to reduce this.
Also, your snippets seem to indicate that the connection interval you use on the Central side is outside the parameters that the Peripheral requests. This will hence most likely cause an error from ble_conn_params module after it has tried requesting new parameters the configured number of times. You should make sure that the connection parameters you connect with from the Central side are within what the Peripheral wants, or make sure that you handle the Connection Parameter Update Procedure. You can take a look at this MSC to see what events you get from the S120 when this happens: https://devzone.nordicsemi.com/documentation/nrf51/5.1.0/html/a00885.html
Thanks for your reply !!! I know it is not easy by mail ... :-)
I have put some traces in the Central code:
Hello from fix module !!! [APPL]: Scan started ble_evt_dispatch:BLE_GAP_EVT_ADV_REPORT, [APPL]: Scan stopped
[APPL]:[37 11 AF 64 BA C4]: Connection Requested ble_evt_dispatch:BLE_GAP_EVT_CONNECTED [APPL]:[37 11 AF 64 BA C4]: Connection Established
ble_evt_dispatch:SD_BLE_GATTC_PRIMARY_SERVICES_DISCOVER ble_evt_dispatch:SD_BLE_GATTC_CHARACTERISTICS_DISCOVER ble_evt_dispatch:SD_BLE_GATTC_DESCRIPTORS_DISCOVER [APPL]: Heart rate 8192 ble_evt_dispatch:SD_BLE_GATTC_WRITE ble_evt_dispatch:SD_BLE_GATTC_HV_CONFIRM [APPL]: HR Measurement received 180 ble_evt_dispatch:SD_BLE_GATTC_HV_CONFIRM [APPL]: HR Measurement received 180 ble_evt_dispatch:BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST ble_evt_dispatch:SD_BLE_GATTC_HV_CONFIRM [APPL]: HR Measurement received 180 ble_evt_dispatch:BLE_GAP_EVT_DISCONNECTED [APPL]: Disconnected [APPL]: Scan started
When I power on the peripheral, the connection is done immediatly. Nice ! But then the 3 DISCOVER messages arrive slowly (one every 1.5 sec) and I receive the BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST 10 seconds later. Or at the Peripheral side, I have set: FIRST_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(1000, APP_TIMER_PRESCALER) NEXT_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(2000, APP_TIMER_PRESCALER)
Unfortunately, it seems there is an issue with the connection manager, that I haven't actually noticed. It uses hard coded connection parameters, and you'll therefore have to do those changes in conn_mngr.c on lines 187-188 instead of just in the header file. I'm terribly sorry for not noticing this before, and I've reported it internally so that it can be fixed in a future version.
