RE: BLE characteristic array/set

martin — Fri, 18 Aug 2017 15:01:06 GMT

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).

RE: BLE characteristic array/set

endnode — Thu, 17 Aug 2017 20:23:42 GMT

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.