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]

Btw. I'm still assuming these sensor numbers have some significance in your architecture but I might be wrong;) So in very general protocol you can only define certain data object which will have 3 sub-objects:

1. What is the sensor number encapsulated in this object
2. What type of sensor data this is (needs to be known to receiver to decode them of course)
3. Sensor data itself (whatever length you need, previous item should fully describe the format).

Now it depends how scalable your solution must be vs. how much you want to reduce overhead. In the first case you would make ASN.1 BER-TLV from all these objects (so you would have typically 2 + 3 + 3 + 2 bytes of overhead to transfer one sensor data blob in the length of 0-127 Bytes) or similar, second case would make it enough to do TAG (1B) + LENGTH (1B for data length 0-125B) + 1B (sensor number) + 1B (data type) + ACTUAL_DATA.

[endnode]

... so the second notation provides 4B of overhead to each data blob which has length 0-125B (if longer then you simply have +1 or +2 bytes because length element will be longer then 1B).

[endnode]

To your update:

"Using the Notifications automatically activate the CCCD (Client Characteristic Configuration Descriptor -> Core Specification, Volume 3, Part G, section 3.3.3.3) in the Server (Slave) nRF51+S130 Stack which need to be activated by the Client (Master) in order to enable the notifications, right?" - NO! Notifications must be always enabled explicitly by GATT Client through write. At least once (if peers are bonded - because then should GATT Server store state of all handles and use it during next connection) but typically at the beginning of every connection (if devices are not bonded).

[Olivier]

Using the Notifications automatically activate the CCCD, I mean that when a characteristic has notification a handle CCCD is automatically created allowing the Client to write (0x0001) in the Server to enable the Notification.

[endnode]

(continue...)

A) As I said I was lost in your Client/Server architecture so in general from Client to Server you transport data through Write methods (two types) and from Server to Client through Notify/Indicate methods (this is usual "async" model used by most of modern Profiles) or through Read methods (kind of old-fashion "pull" model for people who are not able to understand or use "sync" way). Again I don't understand all the details of your application data flow so this was general remark and you will need to decide yourself.