ble icon indicating copy to clipboard operation
ble copied to clipboard

"connection parameters update request" CALLBACK IS MISSING FROM MBED STACK

Open gaucho1978 opened this issue 8 years ago • 12 comments

in repository Bluetooth Low Energy / BLE_API the function updateConnectionParams is returning the error 3 (wrong parameters). This is needed, when in master role, to reply to the parameter update request coming from the peripherial, according to this chart: http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s130.api.v2.0.0%2Fgroup___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

More big problem, is that the peripherial is sending to the master the "connection parameters update request" but the Mbed stack don't implement a callback to inform the user about this request. I know it because I sniffed the packets. As a result, after 1 minute the peripherial disconnects from the master.

Note: the peripherial is a Polar H7 Heart rate sensor. The nRF51822 is the master with MBED code.

gaucho1978 avatar Jul 14 '16 07:07 gaucho1978

ARM Internal Ref: IOTSFW-2793

ciarmcom avatar Jul 14 '16 07:07 ciarmcom

@gaucho1978 You are looking at the abstraction and not the implementation. This function is virtual and is overridden by implementation.

The implementation on nrf51 is present (see here)

Could you update your ticket if this answer your question ?

pan- avatar Jul 14 '16 09:07 pan-

yes, sorry. I'm continuing the debugging and if i call the following: 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 avatar Jul 14 '16 13:07 gaucho1978

I also added another problem on the same question, sorry if i'm making confusion. I updated also the original question. Please read the original question again.

gaucho1978 avatar Jul 14 '16 13:07 gaucho1978

@gaucho1978

  • minConnectionInterval: the minimum interval between two connection events
  • maxConnectionInterval: The maximum interval between two connection events
  • slaveLatency: The number of connection events a slave can drop
  • connectionSupervisionTimeout If no data has been received by the peer in this interval, then the connection is considered over.

The important part here is that: connectionSupervisionTimeout > maxConnectionInterval * slaveLatency

So in your case, you can change the connectionSupervisionTimeout to something over 4 * 400.

For your second question, you are right, there is no callback invoked for the parameter update request and response. That is a defect in the API. But remember that connection parameters are up to the central, not the peripheral.

pan- avatar Jul 14 '16 15:07 pan-

The other issue with most of the Softdevice wrapper functions is that they do not return the correct response.

In this case the function returns that there has been a paramater error if the SD didn't return success

However there are a load of other possible response codes that the SD could return See https://developer.nordicsemi.com/nRF5_SDK/nRF51_SDK_v8.x.x/doc/8.1.0/s130/html/a01260.html#gaf89b434841998ab384e0612dca9e12f8

And at least some of these could be mapped to mbed equivalents, instead of returning a possible erronous error indicating a paramater error when in fact the SD may have actually returned BUSY or that its out of memory etc

rogerclarkmelbourne avatar Jul 15 '16 03:07 rogerclarkmelbourne

@pan- I think you are wrong because timeout is in steps of 10ms, while min and max inteval are in steps of 1,25ms.

i modified the code to show precise error, according to https://developer.nordicsemi.com/nRF5_SDK/nRF51_SDK_v8.x.x/doc/8.1.0/s130/html/a01260.html#gaf89b434841998ab384e0612dca9e12f8

It turns to be: NRF_ERROR_INVALID_ADDR Effectively, the handle of the connection is 0. It is zero in the connection callback and also in the discoveryTermination callback.

So the new question is why the handle is zero in the connectionCallBack.

(then the following question it will go back to the original question)

gaucho1978 avatar Jul 17 '16 14:07 gaucho1978

I checked the Nordic website and it seems normal to have handle equal to zero when the device is in master role (from zero to seven). So I continue to do not understand why am i getting the NRF_ERROR_INVALID_ADDR

gaucho1978 avatar Jul 17 '16 15:07 gaucho1978

Oups, my bad, I though the update connection parameters were in ms. In some cases APIs they are while in other they're not.

@gaucho1978 Could you provide a program which reproduce your issue ?

pan- avatar Jul 17 '16 20:07 pan-

this is the complete example, consider that it is structured as it follows: on start an active scan is started. when the desired peripherial is found, it connects, and registers for notifications. On the first notification (inside function hvxCallBack) I request the connection parameters update.

this is the code: http://pastebin.com/1v540nhb

note: the peripherial is a Polar H7 Heart Rate sensor.

gaucho1978 avatar Jul 18 '16 09:07 gaucho1978

can someone of you try to use the param update and check the result? it's a common problem?

gaucho1978 avatar Jul 24 '16 07:07 gaucho1978

Where does the connHandle comes from? How is it passed to a variable?

mkarn3yru96 avatar Jun 22 '20 23:06 mkarn3yru96