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

BLE characteristic array/set

martin

i know that it's not up to you guys to tell me this but maybe you can give me a hint: right now i'm using the bluetooth developer studio together with the nordic plugin for code generation to design my communication/GATT.

i'm transferring sensor values (xyz acceleration raw values) which should be processed by the central (much more powerful than the sensor). i want to keep the communication cycles to a minimum and thus the idea would be to transfer a set of xyz values.

is it possible to transfer a set of (structured) values / is there a proper way to design this?

i know that i could simply define a characteristic with an array type and fill it up to the MTU of 23 byte (is that correct?) and simply parse it properly on the central side, but i though it might not hurt to ask if there's a better way to do this ...

also > do you maybe have an example for array-type characteristics?

thanks!

  • 0

    Yes, this is the right way. BLE GATT is the highest layer providing some data frames/packets/whatever you want to call it and on top of that are APP layer proprietary data. If you want to design some optimal protocol you can simply map your data structure to GATT handle Value and send it over link by Notify (from Server side) or Write (from Client side) methods. Btw. this is more or less what Nordic's BLE UART Service (NUS) does and because Nordic provides full set of examples in their SDK it's very popular in the field. If you need to be more future proof then you can add some header like what is the protocol packet structure version (and length if you want to make it dynamic). Some purists would even go with full ASN.1 defined protocol (so typically set of BER-TLV structures which then can be parsed without doubts on the receiver's side and would scale to basically infinite packet sizes etc.) but in the end it's all the same. So take the approach which suites the best to your purpose and skills, design some proprietary GATT Service and Characteristic with 128-byte UUIDs and map your XYZ samples to GATT "byte array" in the way you will be able to parse and interpret them easily on the other side.

  • 0 in reply to endnode

    spot on - thanks a lot. i guess it wouldn't be to hard to implement another protocol layer on top of GATT and the NUS is a great reference, i'll have a look at that. just have to make sure to make something re-usable for BLE mesh (MTU sizes might be different, didn't have a chance to look at it just yet).

Related