• State Verified Answer
  • Replies 2 replies
  • Subscribers 73 subscribers
  • Views 1971 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 109781
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Fake "multiple central connections" by switching a single one

Rostislav Lisovy

Dear developers;

I am aware of the fact, that the nRF51 S110 softdevice (supports concurrent Peripheral and Broadcaster role) does not support connections to multiple Central devices. I would like to investigate if the following scenario would be possible (how to circumvent this limitation):

  • Multiple nRF51 devices in Peripheral mode are connected to a single Central device (having an active connection)
  • At the same time the nRF51 devices run in a Broadcaster mode (does it send ADV_SCAN_IND?)
  • A new Central device pops up (second one). It receives a broadcast message from the nRF51, while asking it for a "scan response", this triggers a function (callback) in the nRF51 that disconnects from a previous Central and makes it possible a new Central device to connect (Central devices would probably be whitelisted, so it won't connec to every possible device)
  • Data exchange will occur. The Central device disconnects, Peripheral (nRF51) connects back to the one it was preiously connected.

Is this feasible? I am aware most will recommend to use a Broadcasting mode only, however I would like to solve this scenario with connections.

Thak you; Rostislav

Parents
  • 0

    Ahoj Rostislave,

    Yes this should work, there is basically just one little hack and that's connection termination from Peripheral side on that Scan Request event. But that's available in the latest S110 Soft Device (BLE_GAP_EVT_SCAN_REQ_REPORT if I understand the API correctly) and Peripheral side can disconnect any time (if done properly;). So sequence would look like:

    1. Your peripheral is broadcasting ADV_IND packets while waiting for incoming connection.
    2. If incoming CONNECT_REQ is accepted and Peripheral follows the connection then it can start sending non-connectable broadcasts ADV_SCAN_IND (to be compliant with BT SIG spec 4.x).
    3. If there is SCAN_REQ coming with correct parameters (there are only RSSI, timing and Address available to your app at that moment I believe) Peripheral terminates the connection on LL layer (there is an API call).
    4. Now Peripheral needs to start advertising with ADV_IND again otherwise Central wouldn't send CONNECT_REQ.
    5. Once CONNECT_REQ arrives it processes all it should and once it is terminated (from whatever side) Peripheral needs to start broadcasting ADV_IND packets again to allow original Central device to connect (but I believe you meant this when you wrote "Peripheral (nRF51) connects back to the one it was previously connected" - because Peripheral device cannot initiate connection).

    It should work but you will need to survive poor throughput of such solution (these re-connections will take at least hundreds of milliseconds, could be up to couple of seconds in the worst case). If you need better performance then only custom BLE stack or proprietary solution (e.g. some mesh networking stack) could help you.

    Cheers Jan

Reply
  • 0

    Ahoj Rostislave,

    Yes this should work, there is basically just one little hack and that's connection termination from Peripheral side on that Scan Request event. But that's available in the latest S110 Soft Device (BLE_GAP_EVT_SCAN_REQ_REPORT if I understand the API correctly) and Peripheral side can disconnect any time (if done properly;). So sequence would look like:

    1. Your peripheral is broadcasting ADV_IND packets while waiting for incoming connection.
    2. If incoming CONNECT_REQ is accepted and Peripheral follows the connection then it can start sending non-connectable broadcasts ADV_SCAN_IND (to be compliant with BT SIG spec 4.x).
    3. If there is SCAN_REQ coming with correct parameters (there are only RSSI, timing and Address available to your app at that moment I believe) Peripheral terminates the connection on LL layer (there is an API call).
    4. Now Peripheral needs to start advertising with ADV_IND again otherwise Central wouldn't send CONNECT_REQ.
    5. Once CONNECT_REQ arrives it processes all it should and once it is terminated (from whatever side) Peripheral needs to start broadcasting ADV_IND packets again to allow original Central device to connect (but I believe you meant this when you wrote "Peripheral (nRF51) connects back to the one it was previously connected" - because Peripheral device cannot initiate connection).

    It should work but you will need to survive poor throughput of such solution (these re-connections will take at least hundreds of milliseconds, could be up to couple of seconds in the worst case). If you need better performance then only custom BLE stack or proprietary solution (e.g. some mesh networking stack) could help you.

    Cheers Jan

Children
Related
Terms of service