• State Verified Answer
  • Replies 34 replies
  • Subscribers 68 subscribers
  • Views 9297 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 122245
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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.

  • 0 in reply to Olivier

    A) Reading values over (G)ATT methods in BLE makes sense for some read-only or similar informative string exposed by GATT Server. It's rarely used. For any real communication on application layer Notify methods are providing much better throughput so everyone uses that way.

  • 0 in reply to Olivier

    C) Yes the Notification maximal size is ATT_MTU-3 but what is the size of ATT_MTU? Is it defined by the Server or by the Client?

  • 0 in reply to Olivier

    B) Again all my comments are skipping this basic scenario of quasi-static value stored in Characteristic's Value handle. Yes, you can do Write and Read from Client side and async Notification from Server side but that leads exactly to the scheme you presented originally: load of single-purpose Characteristics on the server side. It can be fine for simple use cases but when scaling to dozens of things (like your case with dozens of sensors) and caring about "performance" in terms of connection time and throughput the experience is suggesting to design single "tube" (or pair of Tx/Rx buffers) on top of some Characteristic Value and then define more condensed protocol with Write/Notify methods. The worst thing which could happen is that you will have the same "performance" as if you would do Read + response, but typically you will be much better.

  • 0 in reply to Olivier

    A) The Notify method provides ATT_MTU-3 value while read blob response provides ATT_MTU-1 with should offer a better throughput. Doesn't it?

  • 0 in reply to Olivier

    ATT_MTU size is by default 23 and can be negotiated once per connection to minimum from Server and Client max values. We are going into too much theoretical discussion with many assumptions and potential situations where one or another solution can provide better throughput. Does it mean that you are designing solution for one very specific use case of data granularity and througput or are we really talking about some general (limit) use cases?

Related