This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Long write only writes 4 packets

Hello,

I'm implementing long write function to my project.

I managed to get it working, but i can't send more than 68 bytes of data. When i'm sending the data, I slice it into <18bytes chunks and send each chunk with correct offset, using "BLE_GATT_OP_PREP_WRITE_REQ" as sending type. When all the data is through i use this command to execute the write: "BLE_GATT_OP_EXEC_WRITE_REQ".

Now no matter how much i send (if it's more than 68 bytes), only 68 bytes come through. When i looked into what comes through i saw that only FIRST 4 packets are recieved, even thought i execute when all packets are sent.

Why are other packets lost?

Best regards, Nejc

Parents
  • Also, it is the sender that will see any errors. When you send a prepare write request, you get a BLE_GATTC_EVT_WRITE_RSP. All the GATTC events have a "gatt_status" flag that contains any error reported by the peer side. In this case, the peer knows that the queue is full, and responds autonomously.

  • The buffer needs to be big enough to contain all the data packets and their handles. See this table to see the layout of each packet. This means that you will have to account for 6 bytes of overhead per Prepare Write Request.

    That is what long writes (also called reliable writes) are about. You queue up a lot of write requests, then write them all at once. If you do not need this functionality, it is better to just send write commands with an offset. The upside of the feature is that you can choose to write to multiple characteristics at the same time, or to keep data consistent at all times.

    It is fairly strange that the write response does not generate any error though.

Reply
  • The buffer needs to be big enough to contain all the data packets and their handles. See this table to see the layout of each packet. This means that you will have to account for 6 bytes of overhead per Prepare Write Request.

    That is what long writes (also called reliable writes) are about. You queue up a lot of write requests, then write them all at once. If you do not need this functionality, it is better to just send write commands with an offset. The upside of the feature is that you can choose to write to multiple characteristics at the same time, or to keep data consistent at all times.

    It is fairly strange that the write response does not generate any error though.

Children
No Data
Related