Thanks for the tip. Would try that too.. However, I have tried few variations to check the BLE side ( whether it was responsible for truncating )
1. I am able to send the same message using encoding only.. i.e. if I trigger the same using a button to send over ble. i.e. BLE Connection, Button -> Encoding -> BLE Output, works. 2. The method which receives the char * data, itself receives a truncated value. BLE Connection, BLE Incoming -> Decoding -> Encoding -> BLE Outgoing, does not work. Truncation. 3. I am able to send the same message using encoding only.. i.e if I trigger only the encoding method after receiving a message over BLE. i.e. BLE Connection, BLE Incoming -> Encoding -> BLE Outgoing, works. This kinda makes me feel that it should be a memory issue when its BLE + Decoding + Encoding. With or without using mbuf / mbuf_pool Let me know if you require to see the code, I can write another small test app for you. Thanks, Aditya Xavier. > On 29-Mar-2018, at 9:34 PM, Christopher Collins <ch...@runtime.io> wrote: > > Hi Aditya, > > On Thu, Mar 29, 2018 at 08:52:08PM +0530, Aditya Xavier wrote: > [...] >> And it doesn’t work when am trying to trigger it from BLE. >> >> Assuming it was a memory issue, I used a mem_pool, mbuf, allocating >> and reserving space. However, problem remains. >> >> It usually encodes and sends the following structure: >> >> {“field1”:1, “field2”:2, “field3”:[{“field4”:4, >> >> Which naturally fails because of incomplete cbor structure. > > My guess is that the Bluetooth ATT MTU is too low to accommodate the > full packet. The ATT layer is specified with the somewhat surprising > behavior of silently truncating overly-long attribute values [1]. > > How are you sending the CBOR data? If you are using a simple "write > characteristic" procedure (`ble_gattc_write()`), you can use the "write > long characteristics" procedure instead (`ble_gattc_write_long()`), > which will fragment the long attribute value for you. If you are > sending the CBOR data in a notification, on the other hand, then I'm > afraid the BLE stack doesn't offer any means of fragmentation; you'll > need to implement an application-layer fragmentation scheme. > > Chris > > [1] Perhaps we should add a syscfg setting which causes an over-long > write to indicate an error to the application instead of silently > truncating the data. The stack wouldn't be standards-conforming in this > mode, but it seems more useful.