This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Custom Service Structure

I need to create a service on the nRF52832 that can send large amounts of a few different data types to the central device. For instance

  • ADC1 sampling (~256 bytes/s)
  • ADC2 sampling (~256 bytes/s)
  • IMU orientation (32 bytes/s)

And I also need to be able to receive commands from the central. This would be things like:

  • Start/ Stop sampling
  • Update device name
  • Enter Test Mode
  • Device shutdown

Should I create 1 service, and a separate characteristic for each data that I need to send? What's the best way to handle the incoming commands?

Parents
  • Depend on what is your major criteria;) Is it speed hence minimal overhead during GATT service discovery right after connection is established or you don't care about that (e.g. because your use case is rather "all the time connected" or "devices will be always bonded and GATT Server stack will be static hence Client will use cache all the time") and you rather prefer having it "nice"? I guess answering this question will give you also immediately answer to your original one;)

  • (2/2)

    However if you don't care about 1-3 seconds of delay between actual connection on link layer and start of data transfer on application layer then you want to at least separate Tx and Rx "tubes" into two characteristics (because it seems that this can help with bandwidth during full-duplex transfers if you have them in your use case) or go and separate each "function" to separate characteristics (one for reporting of sensor data type X1, second for reporting of sensor data X2, third for sending management commands to sensor gateway etc.)

Reply
  • (2/2)

    However if you don't care about 1-3 seconds of delay between actual connection on link layer and start of data transfer on application layer then you want to at least separate Tx and Rx "tubes" into two characteristics (because it seems that this can help with bandwidth during full-duplex transfers if you have them in your use case) or go and separate each "function" to separate characteristics (one for reporting of sensor data type X1, second for reporting of sensor data X2, third for sending management commands to sensor gateway etc.)

Children
No Data
Related