• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 51 subscribers
  • Views 410 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

scanning many periferals

Itamar Cohen
Intellectual 570 points

Need to read/get info from 50 sensors as fast as possible( once a second from each) in a period of 15 min. run. Power is not an issue on both central and peripherals.
What will be the best architecture?
Suggestion:
All sensors are Broadcasters sending the info in the manufacturer data whenever data changes.
However because of the high number of broadcasters and high collision rate, it could be better if the scanner would confirm receiving.The most effective would be if broadcaster sense response request then it could stop advertising until a change in data.
Problem: Response request is not reported to the application(?)
Any better idea?

  • 0
    Guru 22270 points

    Hello Itamar,

    Welcome to the Forum!

    There are a number of different approaches to use.  The first one would depend on if the system is fixed and all sensors are known.  As opposed to unspecified sensors (broadcaster) coming in and out of range.  If all is known, then it would be best to have your master cycle through you list of sensors, make a connection, get the data, terminate the connection and move onto the next sensor.   This guarantees that all devices are read and responded to.

    You can still do the same thing with the broadcasters by creating a list and cycling through it and record the information from the sensor.  The only issue I can see with that is you will have to account for the synchronization of reading a broadcast message from the sensor you are looking for. 

    If power is not an issue, then having a broadcast at a specific interval would allow the application to know that the device is still alive.  The issue here is that the OSAL Timer has a tendency to wander.

    Thanks,

  • 0 in reply to Greenja
    Intellectual 570 points

    Thanks

    All sensors are known and are fixed in specific session, so what is needed is first to discover all available sensors and then (thinking loudly) to connect, read, disconnect through all.

    However this can be a bit of waist because some sensors may not have new information but others do, so may be the best scalable approach  will be that sensors with new data starts advertising (with the info embedded in the advertising payload) and stop on response request and starts again next time new data is available.

    Can a peripheral detect response request ? 

  • 0 in reply to Itamar Cohen
    Guru 22270 points

    "...a bit of a waste"... Well, it's not like they have anything better to do. LOL!

    You can add as much complexity to your project as you are comfortable with.  The peripherals can only detect a response if they are trying to make a connection.  A broadcaster is not trying to make a connection.  You can switch the roles of the device if you like, but I suggest you connect and read  from the sensors.

    Also, if you are using an iOS or other device to do the monitoring, you can theoretically connect to more than 50 sensors at a time.   The 1 master with 3 slave connections is a limit of the TI BLE stack.

    Thanks,

  • 0 in reply to Greenja
    Intellectual 570 points

    Thanks 

    You are right about the waist. May be it is not an issue. I was worried about crowded radio channel with all the 50 advertisers at the same time. Rethinking, your idea is better because it is more reliable and after the first burst, peripherals that was read can stop advertising until they got some news.

    Thanks for valuable advice