ble central disconnects after one minute

[gaucho1978]

i'm using the BLE_Central_Test example to connect a BTLE Heart Rate Sensor (Polar H7) to the redbear nano. I just modified the "ble.connect(peerAddr, BLEProtocol::AddressType::PUBLIC, NULL, NULL);" to use the PUBLIC address type.

I can connect and then I start to receive HR notifications with HR measurements.

PROBLEM: after exactly one minute the connection stops (disconnection callback is fired). I added a print to params->reason and i found that the reason for the disconnection is 0x3B (CONN_INTERVAL_UNACCEPTABLE)

I started a sniffer (bluefruit board equipped with a nordic chip) and i made the annexed sniffed file where i can see that after 30 seconds the HR sensor send a "connection parameter update request" but the arduino didn't fire any event.

I requested support to Nordic and they said that the Redbear Stack should implement an event for this message, in order to let me update the connection parameters according to what the peripherial is requesting.

I'm using nano v.1.5 with last available sources, installed using the board manager (i added on the arduino settings the https://redbearlab.github.io/arduino/package_redbearlab_index.json)

Can you help me?

sniffedPackets.zip

[gaucho1978]

No news for me?

[gaucho1978]

I added important details to my request. Nordic says that it is missing a callback declaration in redbear stack.

[rogerclarkmelbourne]

Please can you let me know what fix you did for this

I have a fork of this repo, which I am going to update with a load of other changes, including making the build process a lot faster by compiling the mbed etc folders into a static lib, as well as refactoring to move the pin_transform files into the variant folders (where IMHO ) they really should be, rather than using # defines etc

[gaucho1978]

Dear Roger, I didn't fixed the problem. As you can read, I just understood that it is missing a callback to an event that should inform the user about the peripherial desired connection parameters. Then the user should update the connection parameters. I asked to Nordic which is the callback to use in the Nordic S130 stack and I am waiting their feedback.

[rogerclarkmelbourne]

OK. Thanks

[gaucho1978]

This is the reply of Nordic: The connection param update events and responses are shown in the message sequence chart here. I would assume that this would be included in the BLE API you are using, but I couldn't find it.

[gaucho1978]

..and this is the message sequence chart mentioned by Nordic: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s130.api.v2.0.0/group___b_l_e___g_a_p___c_e_n_t_r_a_l___c_p_u___m_s_c.html?cp=3_6_2_1_0_2_1_3_2

[rogerclarkmelbourne]

All the underlying code in this repo comes from mbed, so you could try compiling your example using mbed and see if it has the same issue, and if so, post a question to the mbed forums

[rogerclarkmelbourne]

BTW.

I am not sure if the RBL repo uses the new V2.0 of the S130 soft device.

Originally their bootloader used the old version, which used to be called "V9" https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk51.v9.0.0%2Fser_codecs_130.html

I will try replacing the existing bootloader with the new S130 V2.0.1 softdevice to see if its actually compatible.

[rogerclarkmelbourne]

OK

I just checked this, and RBL still appears to be using the old V1.x Softdevice which was part of the Nordic V9 SDK

I tried using the V2.0.1 SD with this core, but it doesn't work. I made sure I changed the linker file to link to 0x1B000 instead of 0x1C000 but it didn't make any difference.

And, looking in the migration docs from Nordic and then checked what code is in this repo, and things which have been removed from the latest (V11) SDK like NRF_APP_PRIORITIES are till defined in this core.

So in terms of fixing this issue, you probably need to refer to the V1.x Softdevice docs and the V9 SDK

[rogerclarkmelbourne]

Edit.

Sorry. I was partially mistaken

I can get the basic functionality working e.g. Blink using the latest S130 SD (I had an issue with the uploader causing the binary to be flashed to the wrong location.)

However I have also looked at the SD header files in the repo again and also whats in mbed and I'm very certain that this repo uses the old version of the SDK, as mbed is till using the S130_nrf51_1.0.0 softdevice hex file, not the newer V2.0.1 version

[gaucho1978]

I think that the method is supported also in the old version of the SDK, in fact inside the repository you can find BLE_GAP_CONN_PARAM_UPDATE and SD_BLE_GAP_CONN_PARAM_UPDATE. The problem it may be that inside Gap.h the methods are not implemented, in example, on line 580 you see:

virtual ble_error_t updateConnectionParams(Handle_t handle, const ConnectionParams_t params) { / avoid compiler warnings about unused variables */ (void)handle; (void)params;

    return BLE_ERROR_NOT_IMPLEMENTED; /* Requesting action from porter(s): override this API if this capability is supported. */
}

[gaucho1978]

where should i post the question on MBED websites? do you have precise link?

[rogerclarkmelbourne]

You could try any of the forums that use the nRF51822 e.g. https://developer.mbed.org/forum/platform-39-Nordic-nRF51822-community/ as they will all have this issue if the function is not implemented

Or you could post an issue to the mbed github repo https://github.com/mbedmicro/mbed but check that its not fixed first and RBL took a shapshot of the mbed code a few months ago, and there may have since been a fix

[gaucho1978]

I posted it here: https://developer.mbed.org/questions/69722/BLE_API-Gaph-function-not-implemented/ and here: https://github.com/ARMmbed/ble/issues/185 can i post it somewhere else?

[rogerclarkmelbourne]

Are you sure its not implemented

Line 580 in gap.h is a virtual function and is probably overridden by

https://github.com/RedBearLab/nRF51822-Arduino/blob/64167306ac2e9777a81d432e8a107bbc4e1fe759/arduino-1.6.x/hardware/RBL/RBL_nRF51822/cores/RBL_nRF51822/ble-nrf51822-master/source/nRF5xGap.cpp#LN406

Line 406

[gaucho1978]

yes you are right. I'm continuing the debugging and if i call the foolowing: Gap::ConnectionParams_t *connParams; connParams->minConnectionInterval=250; connParams->maxConnectionInterval=400; connParams->slaveLatency=4; connParams->connectionSupervisionTimeout=550;

ble_error_t resultCall= ble.updateConnectionParams(connHandle, connParams);
Serial.print("1.Result=" + String(resultCall) + "\r\n");

I Always receive "3" as a result. It means that the method is implemented but the parameters seems to be wrong. How to find good parameters? these are what the peripherial is requesting me....

[gaucho1978]

I updated the requests on the MBED GITHUB

[rogerclarkmelbourne]

I think the problem is possibly something else

There are multiple return codes

https://developer.nordicsemi.com/nRF5_SDK/nRF51_SDK_v8.x.x/doc/8.1.0/s130/html/a01260.html#gaf89b434841998ab384e0612dca9e12f8

The function may just be returning that the SD is busy See https://devzone.nordicsemi.com/question/13588/connection-parameter-update-handling/

The mbed function

ble_error_t nRF5xGap::updateConnectionParams(Handle_t handle, const ConnectionParams_t *newParams)
{
    uint32_t rc;

    rc = sd_ble_gap_conn_param_update(handle, reinterpret_cast<ble_gap_conn_params_t *>(const_cast<ConnectionParams_t*>(newParams)));
    if (rc == NRF_SUCCESS) {
        return BLE_ERROR_NONE;
    } else {
        return BLE_ERROR_PARAM_OUT_OF_RANGE;
    }
}

should not just return BLE_ERROR_PARAM_OUT_OF_RANGE it should return other error codes as well

There are a whole heap of defines for this in

https://github.com/RedBearLab/nRF51822-Arduino/blob/64167306ac2e9777a81d432e8a107bbc4e1fe759/arduino-1.6.x/hardware/RBL/RBL_nRF51822/cores/RBL_nRF51822/ble-master/ble/blecommon.h#LN53

Its just lazy coding in https://github.com/RedBearLab/nRF51822-Arduino/blob/64167306ac2e9777a81d432e8a107bbc4e1fe759/arduino-1.6.x/hardware/RBL/RBL_nRF51822/cores/RBL_nRF51822/ble-nrf51822-master/source/nRF5xGap.cpp

as it looks like BLE_ERROR_PARAM_OUT_OF_RANGE is returned if there is any form of error

So, the first step would be to confirm precisely what the error code really is

Mbed really needs to be updated, so I'd modify your issue to point out this massive bit of lazy coding

Of course even if Mbed fixes it, you'd need to manually copy the fix to here as this is a snapshot of mbed, not a submodule that could be automatically updated ;-(

[gaucho1978]

I checked the precise error: NRF_ERROR_INVALID_ADDR I suppose it has to do with connection handle connection handle is returned in connectionCallback and it is equal to ZERO. according to Nordic documentation this is correct, so I don't understand where the problem comes from.