Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Handling the borderline peripheral nodes

Hello,

We are working on an IoT project where we will have multiple peripherals and central nodes. You can assume that there will be around 30 peripheral and 3 to 4 central nodes. 

Each central node will be connected to 10 to 12 peripheral nodes, one at a time. We will deploy the peripherals and central nodes such that each peripherals node remains in the scanning range of any one of the central nodes.

Peripherals nodes will be in sleep mode most of the time. They will wake at a fixed interval, collect the data, and transmit it to the central and again go back to sleep. We are planning to develop a scheme where peripheral nodes will wake up one by one after a fixed offset time. So at a time, only one peripheral node will wake up.

There will be a scenario where a peripheral node is in the scanning range of multiple central nodes. 

  1. How can we make the peripheral node to connect to the specific central node?
  2. Whitelisting is one way to achieve a connection with specific devices. There will be some conflicting scenarios where the link status of the whitelisted central node will be poor and other central node's link status is good.  We want to connect the peripheral node with the central device with a good link status. So whitelisting will not work in this case. Is there a way to implement the dynamic mechanism for the borderline peripheral nodes?
  • How can we make the peripheral node to connect to the specific central node

    Why does it matter?

    Might it not be better to just design your system so that it does not matter ?

  • Hi,

    If connecting to a close-by central is very important, then I guess for instance the central could check the RSSI of the advertisement, and "back off" for a time inversely proportional to signal strength, giving other (closer) centrals time to connect first. But it would be at the expense of complexity in the central, longer average time before connection is established, and depend on RSSI which can be a bit unreliable.

    In the general case I would rather just accept any connection, regardless of which one is "the best", and rely on correlation between correctly receiving advertisement (one way) and correctly receiving connection request (the other way) with being able to keep two-way communication afterwards. In the (presumably rare) cases where the connection is lost, reconnecting or connecting to a different central should happen fairly quickly. When it comes to power consumption I would expect mechanisms or schemes to "ensure good connection" to give both overhead and complexity, but not necessarily any gains. It also sounds (reading point 2) like you already plan on handling "connecting to different central from time to time", and so your design should handle that aspect as is.

    Regards,
    Terje

  • Thanks, Awneil.

    It is because Central is connected to the WiFi module and the WiFI module collects data from the database for the sensor node. WiFi module somehow to know for which peripheral node data has to be read.

    We are still open for the better suggestions.

  • Thanks, Tesc.

    I understood. It makes sense to allow connection to any of the central nodes because power consumption is a key factor in our application. The peripheral node should be woken up for a minimum amount of time. 

  • Any Central will always know what peripheral it's connected to!

    You've already said that each Central handles several peripherals - so you must already have the means to identify peripherals anyhow.

    As also said in the accepted answer, it really makes life simpler if you just allow any peripheral to connect to any central.

Related