• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 54 subscribers
  • Views 3087 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC26xx: L2CAP Connection Oriented Channels?

CM2015
Expert 1060 points
Other Parts Discussed in Thread: CC2650, BLE-STACK

I have a few questions regarding connection oriented channels (CoC) in the new BLE STACK V2.1

1) My application implements something of a serial port wirelessly from a central node to multiple peripherals. Currently I achieve this by having the central write data to characteristics on the peripherals and the peripheral is able to send data back via notifications. Would CoC be more beneficial for this purpose since I could directly send payloads in either direction? Can paylods be queued up like gatt WriteNoRsp allows for example?

2) Does the sending application get confirmation of successful transmission/ack?

3) Could GATT be removed from the peripheral or at least minimized and save significant stack space if CoC was used? Any idea how much?

4) Any example code for CoC's on the CC2650 (or other devices)?

Thanks

  • 0
    TI__Mastermind 23440 points

    Hi,

    I don't think we have any examples for CoC. It hasn't been much in demand, most likely due to compatibility with existing devices (mobile etc) which haven't supported L2CAP CoC widely so far.

    It is perhaps allowed to get rid of all services on the server, but we don't have a compile option to take out GATT server. It is possible to remove the GATT Client however. This is default in BLE SDK 2.1's SimpleBLEPeripheral. See TOOLS/buildConfig.opt.

    Payloads can be queued up, but I don't think each frame is acked. You will get 'credits' from the peer device as and when that device sees fit to credit you, and this could be used as acks.

    If you are happy enough using ATT - you can notify from and write to the same characteristic attribute if you want to - I don't see a need to use L2CAP CoC. It can be useful for abstracting and controlling transfers of big chunks of data, or if you perhaps need to dynamically allocate several streams, CoCs can be set up and torn down as needed. There is also the flow control aspect which may or may not be useful to you.

    Best regards,
    Aslak

  • 0
    TI__Guru** 105180 points
    Hello,

    I would recommend reviewing the L2CAP CoC section in the BLE SW Developer's Guide (SWRU393). Aside from some processing, you save 3 bytes on each Notification as the ATT header is not used in CoC's. You could get similar efficiency improvements using GATT/ATT if you use a larger MTU size.

    GATT can't be removed from the BLE-Stack as it's used for every profile. Payloads are always queued at the Controller, so they will always be sent in the order they are enqueued.

    Best wishes
  • 0 in reply to JXS
    Expert 1060 points

    Hi all,

    Thanks for the replies. My main interest in CoC was the ability to send variable size payloads. My application has various amounts of data to be sent out and currently I use three characteristics of increasing size to which I choose from to send data to (e.g. small/med/large). Still it can end up in quite a bit of waste if I only have 5 bytes of data and have to send it to a 32byte characterstic (the remaining 27 bytes would just be garbage data transmitted over the air and discarded at the peripheral). It seems like l2cap might be good for this.

    Also, looking at l2cap.h, the L2CAP_SendData says it can return blePending if in the middle of another transmit.. I thought you could queue up multiple sends, or is that incorrect?

  • 0 in reply to CM2015
    TI__Guru** 105180 points
    Hello,

    You can send variable sized packets with GATT/ATT! The size of the characteristic is application specific (up to the max 512 bytes size), so you only need to write/read what is needed by your app. In your example, you will just write 5 bytes of data and if you capture likewise with a sniffer, you will see only 5 bytes of payload data. It's your application sitting above GATT that knows the expected size(s) of the data.

    Best wishes
  • 0 in reply to JXS
    Expert 1060 points

    Hi JXS,

    I think maybe you misunderstood me. I already do control the characteristic size, I have three custom characteristic sizes that I can choose from to send to. However, the amount of data I send changes on the fly e.g. one time I might send 5 bytes, one time 6, another time 43, another time 12, etc. Obviously it's not possible to have an infinite amount of characteristics so currently I use three of increasing size in order to minimize the wasted bits. Unless I've misunderstood something I don't think much better can be achieved with gatt characteristic writes. (Although, I understand that on the peripheral side, notifications can be sent as partial data less than their characteristic size).

  • 0 in reply to CM2015
    TI__Mastermind 23440 points

    Hi CM2015,

    You can send (and receive) variable length data over ATT.

    One way of handling this is to have a companion uint16_t variable for the length, and update this when sending and receiving. If you send and receive on the same char, you should probably have different len variables for transmit and receive, and also different buffer arrays for transmit and receive, in case you inadvertently send and receive at the same time.

    You can then change the length when calling yourService_SetParameter, and use that length in the ReadAttrCB. Vice versa, update the length field when receiving in WriteAttrCB.

    Best regards,
    Aslak

  • 0 in reply to Aslak N.
    Prodigy 30 points

    It's been about a year and a half since this original post, but I'm wondering if anything has changed regarding the CoC example.

    A minimal example would be helpful.