GATT Client - Write Request

[briandunham]

Hi Mike,

I'm trying to do a write request from a GATT client using your framework but I'm unsure how to do this. I am currently using m_pGattClient->WriteCharacteristicValue(s_rxDataCharacteristic, data, sizeof(STRUCT_BT_MESSAGE), plNone); without errors and was able to successfully poll for that data on the server side.

But the GATT server isn't receiving an event when new data is written from the client. I'm assuming my GATT client is doing a write command instead of a write request. I've tested this by using the nRF Connect app to do a "write request", and the GATT server successfully receives the data with an event. How can I do a write request using your framework?

Thank you,
Brian

[Mike Petrichenko]

Hi,

There is no Write Request. However there is Write with and write without response. You can control it by changing the characteristic's WriteWithoutReposnse property (in the characteristic structure). Set it to false before calling Write method to execute Write with response. Set the property to true to execute write without resposne. (Server must support preffered way). Also you can execute long write (WriteWithoutResponse must be set to false) and the length of the value must be more than 30 bytes.

[briandunham]

It looks like people call it different names on the internet, but yes a write with response is what I'm looking for. Setting the IsWritableWithoutResponse property to false still doesn't do what I'm expecting.

Section 3.4.5.1 in the article here: https://iotexpert.com/ble-write-request-write-command-signed-write-command-prepare-write/ shows what I'm looking for. I basically just need to get the attribute opcode to be equal to 0x12 in order for it to trigger the attribute changed event on the server.

If you test using Nordic nRF Connect mobile app to write to a GATT server, you will see the advanced options to do the different type of writes. And using "request" is what triggers the event properly on the server. I need to get the same behavior using this framework. Do you have any other ideas what might be going wrong here?

[Mike Petrichenko]

I have no idea about what that specification defines but GATT specification defines the following commands:

Attribute Write - used for short write without response.
Write Command - used for short write with response
Prepare write - used for long and reliable writes always with response.
Execute Wriute - used after prepare write to confirm or decline transaction.

Short write - data size <= 20 bytes (common PDU size).
Long write - data size > 20 bytes.

Bluetooth Framework with BLEd112 controls the write by following way: If it is short write without reponse the Attribute Write is used. If it is shirt write with response the Write Command is used. If it is long write the Prepare/execute write is used.

Bluetooth Framework can not control when MS driver uses Write/Write Command but it can control when it uses short or long write by switching between Write with and Write without response.

[Mike Petrichenko]

Ok, i have checked what windows does with different options.

* If the characteristic is writable without response MS driver uses Write Command
* If the characteristic is not writable without response MS driver uses Attribute Write
*  If the characteristic is long and not writable without response MS driver uses Prepare Write/Execute Write.

[briandunham]

Hi Mike,

Thank you for sharing your knowledge on this subject. When I lowered the data size down to 20 bytes, it sent the proper Attribute Write and the expected event was received by the server.

So I will now try doing a long write from the GATT client and look to handle the proper Prepare and Execute Write responses on the server side.

Thanks again,
Brian

[briandunham]

I'm handling the long write events on the server side, but they do not get triggered when doing a long write from the GATT client. In fact, zero events get triggered so I'm not sure the packets are even making it to the server. The MTU is already set to 64 bytes and I verified that gets exchanged when establishing connection. Not sure what else could be causing the issue.

Here is what the characteristic on the GATT server looks like:
      s_rxDataCharacteristic.ServiceHandle = 0x0006;
      s_rxDataCharacteristic.Uuid.IsShortUuid = FALSE;
      s_rxDataCharacteristic.Uuid.ShortUuid = 0xCCCC;
      s_rxDataCharacteristic.Uuid.LongUuid = { 0x3347AB02, 0xFB94, 0x11E2, {0xAB, 0xE4, 0xF2, 0x3C, 0x91, 0xAE, 0xC0, 0x5E} };
      s_rxDataCharacteristic.Handle = 0x000A;
      s_rxDataCharacteristic.ValueHandle = 0x0000;
      s_rxDataCharacteristic.IsBroadcastable = FALSE;
      s_rxDataCharacteristic.IsReadable = TRUE;
      s_rxDataCharacteristic.IsWritable = TRUE;
      s_rxDataCharacteristic.IsWritableWithoutResponse = FALSE;
      s_rxDataCharacteristic.IsSignedWritable = FALSE;
      s_rxDataCharacteristic.IsNotifiable = FALSE;
      s_rxDataCharacteristic.IsIndicatable = FALSE;
      s_rxDataCharacteristic.HasExtendedProperties = FALSE;

[Mike Petrichenko]

The long write starts only if the data length is more then MTU/PDU length. BLED112 and BlueSoleil always uses 20 bytes PDU/MTU (by docs for BLED112 and by experience for BlueSoleil). But Microsoft dinamically changes that.

Internally Bluetooth Framework checks only that Data Size must be less then 20 bytes and WriteWithoutResposen can be any value. If the data size if more then 20 bytes the WriteWithoutResponse must be set to false (Bluetooth Framework assumes long write in this case). However once WIndows changes it when needed you sould write data packet more than 20 bytes. 64 in your case (62 actually, but 64 should definatelly start long write operation).

Unfortunately currently there is no way to get MTU/PDU size but I think in next release we will add such feature.