This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2540 data exchange with multiple connections / slaves

Hi,

I am trying to connect a Central device with 3 slaves and cannot make it to work (transfer data, connection works correctly).

With 1 slave it works correctly (connection + data transfers in both directions). However, when the Central device connects with the second slave, the slave does not receive the packets sent by the Master.

I have tried different options for "GAPRole_SendUpdateParam" but none seems to work.

Could anybody provide a set of connection intervals for more than 1 slave that I could try ?

Is there anything else I should be looking at ?

Currently upon connection in my slaves I make:

void bleEventCB(gaprole_States_t newState) {
....

Slave 1:

} else if (newState == GAPROLE_CONNECTED) {

GAPRole_SendUpdateParam(80,80,0,10, GAPROLE_RESEND_PARAM_UPDATE);

}

...

Slave 2:

} else if (newState == GAPROLE_CONNECTED) {

// GAPRole_SendUpdateParam(100,100,0,10, GAPROLE_RESEND_PARAM_UPDATE);

// or

GAPRole_SendUpdateParam(160,160,0,10, GAPROLE_RESEND_PARAM_UPDATE);

}

Note: the #DEFAULT_ENABLE_UPDATE_REQUEST      is set to   TRUE

Thanks

  • Hi. This should work as long as all connection intervals are multiples of each other.  If you're using 1.4.1, the central controller should manage this as long as you provide a large enough range for min / max connection interval.

    I would recommend turning off parameter updates on the slaves and setting the same parameters from the master for simplicity.

    Then, once you get three devices connected, you can start sending updates from the slave.

  • Hi Tim,


    the main problem is that we don't have the 3 slaves available for connection at once. The goal is to connect if/when they get within scanning range. In any case I will try your suggestion. Just to check if I understood you correctly:

    On the slaves:
    turn off parameter updates, thus, not calling "GAPRole_SendUpdateParam".

    On the master:
    What do you mean with "setting the same parameters from the master" ? Should I call GAPCentralRole_UpdateLink(...) upon connection ?

    Thanks for the support

  • Hi Tim,

    I have done as you suggested. But I still cannot communicate with the second slave.

    When the Master has established the connection with the slaves I call: GAPCentralRole_UpdateLink(..)
    and get the event GAP_LINK_PARAM_UPDATE_EVENT in the ble callback,
    ...
    gapCentralRoleEvent_t *pEvent
    pEvent->gap.opcode ==GAP_LINK_PARAM_UPDATE_EVENT

    However the parameters are:

    pEvent->linkUpdate.status = 0
    pEvent->linkUpdate.connInterval= 0
    pEvent->linkUpdate.connLatency= 0
    pEvent->linkUpdate.connTimeout= 0

    Is that what I am supposed to receive ?

    Also I took a look in the Bluetooth specs (Core_V4.0) and on section "4.12 CONNECTION_PARAMETER UPDATE REQUEST (CODE 0x12)" it mentions that:
    "this command shall ony be send from the LE slave device to the LE master device. If LE slave Host receives a Connection Parameter Update Request packet it shall response with a Command Reject"

    I am a bit confused now.
  • Hi,

    I have tried already different possibilities, requesting parameter updates startting from the master and from the slaves after a connection is estabilished and none seems to work. I still cannot communicate with more than 1 slave at the time.

    Does anybody had simular issues regarding multiple connections ?
  • I was recommending that you do not send parameter updates from either side. Just establish the connection from the central device using the same parameters for each connection.
  • Hi Tim,

    this is what I have done since the beginning. No update parameters, all with the same parameters.
    The connections works correctly, data transfer works only with one slave, the second does not receive bluetooth data.

  • Ok well then I guess it's possible you're incorrectly parsing connection handles or some other problem in the code. I would recommend taking a sniffer capture of the second connection to verify data is actually being sent.
  • Hi Tim,

    thanks for the suggestion, it helped a lot. Sometimes the detail is really on the simple things.

    I was so blind-sided looking for connection parameters and internals and completely overseen the connection handles management (once the test cases were passing "offline" without the hardware calls). The system was using only 1 connection handle to send bluetooth messages.

    Once more, thanks for the feedbacks