Forums - BLE Write Long Characteristic

9 posts / 0 new
Last post
BLE Write Long Characteristic
CodeJingle
Join Date: 6 Jun 16
Posts: 13
Posted: Mon, 2016-06-06 12:12

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.

  • Up0
  • Down0
Ryan Chen
Join Date: 2 Jun 16
Location: Taiwan
Posts: 3
Posted: Tue, 2016-06-07 03:26

Hi,

Could you help confirm if you invoke GattInstallServerWriteLongReliable() in AppInit()(you can place it right after GattInit())?

Thanks.

Ryan

  • Up0
  • Down0
CodeJingle
Join Date: 6 Jun 16
Posts: 13
Posted: Tue, 2016-06-07 11:03

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.

  • Up0
  • Down0
CodeJingle
Join Date: 6 Jun 16
Posts: 13
Posted: Tue, 2016-06-07 15:09

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.

  • Up0
  • Down0
CodeJingle
Join Date: 6 Jun 16
Posts: 13
Posted: Tue, 2016-06-07 22:29

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.

  • Up0
  • Down0
Dr. Nissim Zur
Profile picture
Join Date: 6 Jun 16
Location: Skype: nissim.test CSR1010 External design house
Posts: 235
Posted: Wed, 2016-06-08 23:43
CodeJingle, CSR1010 RF buffer does not support of Characteristic Long Write. See the old CSR forum. You can easily overcome it by high level enumerated buffers.
  • Up0
  • Down0
Dr. Nissim Zur
Profile picture
Join Date: 6 Jun 16
Location: Skype: nissim.test CSR1010 External design house
Posts: 235
Posted: Wed, 2016-06-08 23:45
Its hardware buffer limitation, no software. Maybe the new famey CSR102x solved it.
  • Up0
  • Down0
CodeJingle
Join Date: 6 Jun 16
Posts: 13
Posted: Thu, 2016-06-09 10:16

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'.

  • Up0
  • Down0
Dr. Nissim Zur
Profile picture
Join Date: 6 Jun 16
Location: Skype: nissim.test CSR1010 External design house
Posts: 235
Posted: Thu, 2016-06-09 22:31

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.

  • Up0
  • Down0
or Register

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.