ble
ble copied to clipboard
"connection parameters update request" CALLBACK IS MISSING FROM MBED STACK
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.
ARM Internal Ref: IOTSFW-2793
@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 ?
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....
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
- 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.
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
@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)
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
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 ?
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.
can someone of you try to use the param update and check the result? it's a common problem?
Where does the connHandle comes from? How is it passed to a variable?