System setup question - looking for suggestions and direction

[devops]

Hello,

I am in the process of determining a system architecture for a sensor-bluetooth-android application. The goal is to read sensor information from an Android device, using ble and several sensors as the embedded part of the project.

The sensors will be connected to nrf52832 modules. Various elements will be measured so the communication between sensors and ble modules will be in several ways (SPI, I2C, analog readings).

As of right now, there is a working setup where several sensors are attached to a nrf52 module and their readings are transmitted through advertising packets to the Android application The limitation of this way is the number of bytes that can be sent per advertisement and attaching several sensors to one small battery is resource hungry and will not satisfy the capacity vs. time requirements.

I have been thinking of doing it like on the attached image: 

In this way, the sensors could be powered from different coin cell batteries of their peripherals. The peripherals would send their data to the central BLE node and that node will be set up to have a connection with the Android device.

1. Is this possible to do and which examples should I look into?
2. How should peripherals talk to the central? Should they be connected, or do some kind of directed advertising?
3. What would be the limitations of the data transmission between the central and android device? I have came to understand that the advertising package is limited to 31 bytes (usable is 20 something). How limited would it be to transmit data in such way?
4. Would it be possible to send a command to the central to put all devices to sleep, until connection is initiated again?
5. It would be possible to set-up all peripherals as advertisers and filter the results on the android phone - what do you think about that?

I will be grateful if you could offer some useful links and thoughts about the idea - especially keywords and topics what I should research according to the latest capabilities of SDK15+. I will start researching the pros and cons in the next couple of days and the aim would be to determine key focus points in such a connection setup.

[devops]

Thank you for clarifying the central/peripheral state.

The reason why I consider a connectable connection between the phone and the "common/central beacon" is that the whole sensor system illustrated on the image is one closed system, it will be used for one application.

What is there would be two of these "applications" close together or ten of these sensor networks in one area and 3 android devices walking around, trying to decide to which one of the "applications" to connect to? How could I sort/filter the applications/sensors on that case?

For illustration:

Application 1: sensor 1, sensor 2, sensor 3, sensor 4, sensor 5

Application 2: sensor 1, sensor 2, sensor 3, sensor 4, sensor 5

Application 3: sensor 1, sensor 2, sensor 3, sensor 4, sensor 5

Application 4+n: ...

n++;

Thank you already for these answers, especially the idea of setting advertisement timeouts to loop through the sensors. That seems like one possible solution? How would I synchronize the timeouts between sensors?

EDIT:

What about still having a centralized beacon, that collects data from surrounding beacons in intervals and at the same time transmits that data forward to the android phone? Do you see merit in this?

[Nguyen Hoan Hoang]

I am not sure to understand what you want to do.  I assume Application 1 = phone 1, Application 2 = phone 2.  All the phone will receive the advertisement data from the peripheral without any connecting to it.  The phone knows from which device the adv data came from.  The peripheral on the other hand knows nothing about the phone.  The peripheral cannot initiate a connection neither.  It is a slave device.

[devops]

But the phone does not know to which application the advertisements may belong to.

For example, imagine that you and 9 friends walk in to a big warehouse filled with 10 cars. Each car is in essence an "application x", equipped with multiple sensors, all advertising the sensor data from the cars at intervals.

Each friend and you pick a car, and go for a drive together on a 10 lane highway, driving next to each other (or at least in close proximity, so that your phone is able to pick up advertisements from your best friends car). How would you sort out the advertisements associated only with your car?

The answer would be to add identification to the beacons in the car manufacturing process, to make sure they are in sync with the VIN number, for example. What if that was not possible? What if you want the beacons to be as manipulative as LEGO bricks? You can add them to cars, take them away, do as you please. What solutions are there?

[Nguyen Hoan Hoang]

Now I understand better.  In that use case, a connection would be better.  As long as you are using the car.  That no interference from other cars.  The draw back is it will consume more power.

[devops]

Looking back at my previous post, what if "application x" consists of multiple sensor beacons? The plan is to power sensors + ble modules from coin cell batteries as well but attaching all sensors and a ble module to one battery cell would not give the expected lifetime for the device.

Connecting each sensor to its own ble IC and transmitting the values that way might just give the expected lifetime for the device. How would you approach that situation?

[Nguyen Hoan Hoang]

You can attach multiple sensors to the same BLE module (peripheral) and have multiple peripherals where each peripheral is powered by a bat.  Each peripheral advertised data and their own MAC address.  You Phone can keep track of the MAC address and assigned to a group managed by your phone.  Which mean your phone will filter by MAC address.  You can also assign a specific device name to the peripheral so the phone can also filter by device name.  In that case no connection is require, hence lower power usage.  The peripheral can then sleep and wakeup to advertise sensor data when available.