Best way to send data from many sensors

[Olivier]

Hi,

For an application I have a nRF51 at my disposal and I need to transfer about 3'000Bytes. I found in the documentation that the nRF51 can use the S130 SoftDevice which support BLE 4.2. The data I have to transfer come from 1 to 50 sensors and are divided in 2 categories with 3 respective 6 parameters each as follow:

Sensor No1

• Data type A
• --Parameter A1
• --Parameter A2
• --Parameter A3
• Data type B
• --Parameter B1
• --Parameter B2
• --Parameter B3
• --Parameter B4
• --Parameter B5
• --Parameter B6

Sensor No2

• Data type A
• --Parameter A1
• --Parameter A2
• --Parameter A3
• Data type B
• --Parameter B1
• --Parameter B2
• --Parameter B3
• --Parameter B4
• --Parameter B5
• --Parameter B6

Sensor NoX

• Data type A
• --Parameter A1
• --Parameter A2
• --Parameter A3
• Data type B
• --Parameter B1
• --Parameter B2
• --Parameter B3
• --Parameter B4
• --Parameter B5
• --Parameter B6

I thought that a way to transfer these results would be to use 2 customized services (a service for type A and a service for type B) with 3 respective 6 characteristics (A1-A3 and B1-B6) each. Each characteristic should have up to 50 values. The number of values in each characteristic would indicate the number of sensors.

Has someone a better / a more suitable solution for this use case?

Thanks in advance for you ideas.

[endnode]

I don't want to be impolite but looking to your assumptions about how BLE works I'd recommend to go through some basic courses like this one from BT SIG. Maybe twice;) It's pretty detailed and explanatory to understand basic concepts of all layers. It's missing few enhancements coming with BT 4.2 and 5.0 but unfortunately there is no such material to cover these known to me, maybe just few blog posts by Nordic guys here cover some parts.

[Olivier]

B) If I write in a characteristic and I notify the same characteristic (say the characteristic is Write+Notify) will the data be written in the same memory region? I'm not referencing to the notification enable which enable the notification but is actually written in the CCCD characteristic.

[endnode]

This is probably just implementation detail but normally (= with Nordic SoftDevice) you get event callback and in event data structure you get pointer to the data buffer. Then you should take the data and work with them, if you store them in one or million buffers inside your application code/logic is your business. Once event callback processing ends you should probably not assume that data are left somewhere for you (they actually are as I wrote but you should do little testing if it matters to you, I was never investigating this because I just use Write and Notify so there is no one who would "read" any data which are left in some Value data buffer).

[Olivier]

A) Why do you say that the Read methods is kind of old-fashion "pull" model for people who are not able to understand or use "sync" way? What is the sync way if it isn't read?

[Olivier]

B) If I understand you right, with the read command I will read the data written with the write command but the content of notification will not be the same as the written data? In my understanding a Service with notification has a Characteristic with the propertie (read, notify, etc.) in its value, a Characteristic with the value being advertised and a Characteristic format with the status of the notification/indication (enable or disable) in its value. For example the Battery Service is read and notify and has only one Characteristic Value, so I assume that an application reading the Battery level will get the same value as the one being notified. For this reason I don't understand why should the write command write at a different place as the read command read from? In this example I differentiate the notification enable and the write because notification enable write a 1 in the Characteristic Format bit0 which is notification enable.