Read long characteristic as ble central

[RomainQ]

Hi, First I'd like to salute the great work done by you Nordic people for those open source and hardware. I just installed the SDK 10.0.0, S120, gcc-arm toolchain, configure my Mac OSX, plug my RedbearLab Nano ... and it JUST WORKS! Impressive.

But ... there is always a but ;) I need to read a long characteristic from a peripheral (I can't modify it). So I configured my Nano as a central, pair, bond, get characteristic change notifications. All is working, except I just receive 20 bytes where I should receive 45 or more.

I read that the MTU of SoftDevice 120 is limited to 20 user bytes. Well, ok, all buffers are limited in size. What I don't understand is why SoftDevice is not able to get the data in multiple batches as I am now forced to do with the GATTC (multi) read via offsets ?

It would help a lot if this could work, save power and code !

Thanks,

Romain

[RomainQ]

Hi, Thanks, I did that and my project is working. I'm just wondering why the SoftDevice itself is not doing it ...

[shibshab]

Ah, I see, did not see that part of your question. I have no knowledge of the motivation behind this design choise :)

[run_ar]

We had an internal discussion how to do this, and it was decided that this should resemble the size of the payload sent on air. This way we avoid having to allocate a lot of memory internally in the Softdevice to handle long reads, instead this has to be handled by the application. This way it's easier to manage memory usage in a wide variety of applications. The size can vary quite a lot, and the application doesn't necessarily know how many packets will be sent on air. Alternatively, if we did this procedure in the Softdevice, we would need large buffers both in the Softdevice and in the application.

[RomainQ]

Thanks for replying. But what about keeping a small buffer and giving several calls to a callback with offset. What is disturbing is that the notification data limit is not easy to see when you discover the SDK. And you don't see how many bytes were sent by the peripheral vs how many bytes you actually receive in the central.

[run_ar]

This would be possible, but I'm not sure I see the big difference between this solution and the actual implementation except that in this case the application would be force to handle the callback, instead of just stop reading if desired.

"What is disturbing is that the notification data limit is not easy to see when you discover the SDK"
Not sure i understand what you mean by this.

"And you don't see how many bytes were sent by the peripheral vs how many bytes you actually receive in the central."
The data received by the Softdevice will be forwarded to the applicaiton.