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 !
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.
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.
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.
1 - what is disturbing: the com buffer is limited to 20 bytes max, this is not clearly visible in the doc.
2 - the data will be forwarded: my peripheral sent 27 bytes, softdevice only send me 20 bytes without warnings it truncated it. I need to know the peripheral did try to send me more data !
I don't want to argue too much about it as the manual handle with read works. But a new user can easily fall in the problems I found.
2- no, I need the characteristics full bytes: my peripheral advertise a characteristic with let's say 45 bytes. On the central side, on HVX I only get 20 bytes.