On the CSR101x running as a GATT Server, when a read request comes in on a Characteristic whose value length is greater than 20 bytes, I process the read request successfully and the client gets the full value. Though it does not seem to be working when a write request comes in to assign a new value whose value length is greater than 20 bytes. Does anyone have experience with implementing 'Write Long Characteristic'?
Read Long Characteristic and Write Long Characteristic are part of the BLE standard. Their protocol is slighty higher level and so by breaking up into smaller packets and recombining their user value is not limited to 20 bytes.
I am using CSR_uEnergy_SDK-2.6.0.10.
Hi,
Could you help confirm if you invoke GattInstallServerWriteLongReliable() in AppInit()(you can place it right after GattInit())?
Thanks.
Ryan
Yes of course I am invoking GattInstallServerWriteLongReliable in AppInit. Can we please focus skip pass the 'is it plugged in' rhetoric? Does anyone have a working gatt server that support a client doing a write long characteristic? The client performing a read long characteristic is working.
None of the sample applications that ship with the sdk use Characteristic Long Read or Characteristic Long Write. If anyone has a working example for a gatt server that supports Characteristic Long Write please share the code. Otherwise it seems for now I will have to implement my own higher-level protocol for gatt server support of Characteristic Long Write.
So I have it working now ... sort of. I've done the equivalent of gatt server support for write long characteristic, except I was forced to implement an alternative instead of using the built-in mechanism. I feel so dirty this isn't computer science this is a hack. If CSR / Qualcomm would be so gracious to provide a working sample for supporting on the gatt server side the built-in write long characteristic, then maybe it would be respectful instead of ridiculous.
It is a failure of CSR / Qualcomm after so many years of fine tuning and improvement to their silicon and SDK that CSR101x still does not support the external client performing a write long characteristic to a CSR101x hosting a user application running as a gatt server. There is no point to the function 'GattInstallServerWriteLongReliable'.
Hi CodeJingle
CSR is not doing hardware chip design. It has been licensed from other (from cambridge consulting).
So that is probably the hardware core problem of cambridge consulting.
To fix hardware bug you can't do with software SDK.
To make a new chip cost more than 0.5 M USD. And can injects new hardware bug due to that.
Maybe the new family CSR102x fixed that already.
The main problem is closed binary lib that CSR was freeing in SDK. Some had bugs and we the developers can't fix closed bin file. All my request in the past to open that closed lib was not answered.
And unfortunately many good developers leave to other competitors chips due to that.
Now with Qualcomm in charge and new managers, I hope the policy of hiding will end and we can get all application source code and change what needed to have fast product in the market.
Can you call my Skype nissim.test ?
It can be so nice to talk with colleagues, and I can share source code that you can find helpful.