Noob: confused by all the possibilities

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi,

I am certain that people will find this silly, but I'm confused as to which setup I need for the following project:

Essentially, I want to have multiple BLE sensors scattered around a confined space and measuring different characteristics (temperature, pressure, etc.). I do not need the sensors to be measuring continuously (they would be in a low power state mode if possible), instead, I would like the central client (there would be just one) to tell them when to start measuring and report back their findings. Once done, the sensors would revert back to a low power state mode.

What exactly do I need to remotely trigger the sensors to start measuring?

How is the data reported back?

Is there a low power mode that would allow this type of behavior?

I'm very confused by the service characteristics when I try to create a custom profile. Read, Write, WriteWithoutResponse, Notify, Indicate?

My first thought was to have the central client write a 1 to a characteristic when it wants the sensor to start its process, then have the sensor (server) put the data into another characteristic so that the client can read it. But that seems very inefficient!!

I went through a bunch of project example, but didn't exactly find a similar case. If anyone as any thought on a course of action, it would greatly be appreciated.

Thanks

0 Likes
1 Solution
Anonymous
Not applicable

1. The client will need to BLE to connect to the other peripherals. So each one will need BLE or some other wireless connection to detect a measure request and respond with the data measured.

2. BLE supports notifications or attribute writes/reads for devices currently connected to each other. Otherwise, you could setup the data to be advertised if you don't want to do a full BLE connection (anyone can see the advertisement information)

3. BLE supports sleep and deep-sleep while still operating, the CPU supports sleep and deep-sleep as well.

4. Read: reads a value for a characteristic on the device (like reading a database value)

    Write: writes a value to the characteristic on the device (writing to the database value)

    Writewithoutresponse: no response or guarantee that the write was successful.

    Notify: sends an unsolicited database value to the device. (think like an ad popup with data on it )

    Indicate: same as notify, but checks/waits for a response to ensure the other device received the data (notify doesn't ensure the other side responds)

5. Having two different characteristics will save more headaches than trying to combine them (unless you run out of space, there is no need to "compress" the functionality into the same characteristic. Write a 1/true to the first characteristic, then have the unit respond with a notification or indication to give you the measured data. Thus, you won't even need to read the second characteristic explicitly.

6. You will probably never find an exactly similar case, but you can find examples that implement parts of what you are looking for/using. For example: The Project #027: BLE Power Consumption Optimization | Cypress Semiconductor  project demonstrates using the different power modes to save power for an application; Cypress Projects  has a list of projects/examples that will help demonstrate different application cases; http://www.cypress.com/blog/100-projects-100-days/project-043-heart-rate-collector​  shows an example for measuring the heart rate from a peripheral BLE device.

I would recommend starting with a single central/peripheral devices and get BLE communication working first. Next, add the power-saving functionality (deep-sleep is what you want I think). Finally, add in the functionality to trigger reads/writes of the data sensor from the master device. (I'm assuming you already have the sensor measurement parts working)

View solution in original post

0 Likes
1 Reply
Anonymous
Not applicable

1. The client will need to BLE to connect to the other peripherals. So each one will need BLE or some other wireless connection to detect a measure request and respond with the data measured.

2. BLE supports notifications or attribute writes/reads for devices currently connected to each other. Otherwise, you could setup the data to be advertised if you don't want to do a full BLE connection (anyone can see the advertisement information)

3. BLE supports sleep and deep-sleep while still operating, the CPU supports sleep and deep-sleep as well.

4. Read: reads a value for a characteristic on the device (like reading a database value)

    Write: writes a value to the characteristic on the device (writing to the database value)

    Writewithoutresponse: no response or guarantee that the write was successful.

    Notify: sends an unsolicited database value to the device. (think like an ad popup with data on it )

    Indicate: same as notify, but checks/waits for a response to ensure the other device received the data (notify doesn't ensure the other side responds)

5. Having two different characteristics will save more headaches than trying to combine them (unless you run out of space, there is no need to "compress" the functionality into the same characteristic. Write a 1/true to the first characteristic, then have the unit respond with a notification or indication to give you the measured data. Thus, you won't even need to read the second characteristic explicitly.

6. You will probably never find an exactly similar case, but you can find examples that implement parts of what you are looking for/using. For example: The Project #027: BLE Power Consumption Optimization | Cypress Semiconductor  project demonstrates using the different power modes to save power for an application; Cypress Projects  has a list of projects/examples that will help demonstrate different application cases; http://www.cypress.com/blog/100-projects-100-days/project-043-heart-rate-collector​  shows an example for measuring the heart rate from a peripheral BLE device.

I would recommend starting with a single central/peripheral devices and get BLE communication working first. Next, add the power-saving functionality (deep-sleep is what you want I think). Finally, add in the functionality to trigger reads/writes of the data sensor from the master device. (I'm assuming you already have the sensor measurement parts working)

0 Likes