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.

[Olivier]

Hi rct42, Thanks for your comment! Yes I'm considering starting with this example (infocenter.nordicsemi.com/index.jsp. That is why I don't understand very well why endnode says that I only need one Characteristic while this example uses 2 Characteristics (working with the nRF51+S130 SoftDevice).

[endnode]

Hi both, I'm used to work with single Characteristic simply because it works well. The only added value of splitting Tx/Rx streams into two GATT Characteristics (I'm aware of) is that you get full-duplex capability aka you can "stream" data both ways at the same time and througput should be close to optimal while with single Characteristic some devices (I don't think it is limitation mentioned in BT SIG specification but I might be wrong) can use only one GATT method (= Write or Notify) on the same handle during one connection interval so sometimes when there are multiple PDUs pending on both sides to go over the radio they might get delayed. But because 99% of protocols I see in the wild are half-duplex (command-response not asynchronous data streams from both sides) I don't see this as major limitation.

[endnode]

But to conclude on NUS: it is good thing which should just allow data to flow over the GATT, basically no overhead (examples are expecting the strings to end with line delimiters or similar but I'm not sure if it is inherent limitation of NUS itself or just example implementation). Still it doesn't help you with designing your own protocol (= if you want to send some sensor data over the link you need to format them yourself, if you want to provide them on request - after the other peer asks and maybe even says what data it wants - then you need to design your command/response protocol yourself as well... we were maybe mixing these two things together in this Q&A too much.

[rct42]

If you decide to go down the UART over BLE, one recommendation for a protocol is IBM Bisync (or something similar). However, if you're wanting to transfer 3K bytes in a go, how about YMODEM? (I haven't used YMODEM on NRF5x projects but have used the STM32F0xx_IAP for STM32 UART/RS485 bootloaders)