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 <[email protected]> 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.
