Read characteristic help

[T IJ]

Hello,

I'm currently working on creating a custom characteristic so that my client can read a set of data from the server.

My intention is to have a server gather information and put this inside a buffer(200 ish bytes), the client initiates a read and reads the entire buffer from the server.

I've used an example and tutorial to create a custom characteristic (nRF52-Bluetooth-Course), which works except for the read part.

I've copied/pasted the add function and added an extra custom handles (ble_gatts_char_handles_t      custom_array_handles;)

I can toggle an LED on the board if I enable or disable notifications for this characteristic in the on_write function but I do not know how to set up my data for reading.

If I use the app to read from this characteristic I get 200 bytes but I do not know where these bytes are located or how to link it to my buffer. Its just random data from somewhere in memory. 

I do not intend to use the ble_nus services which are described in a lot of examples for reading from Bluetooth because (correct me if I'm wrong) it is limited to a small data payload and I need to send the 200 ish bytes in one packet.

I saw something about "BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST" but I do not know how to implement this properly.(https://devzone.nordicsemi.com/f/nordic-q-a/14215/nrrf2-gatt-attribute-read-callback)

I can post my current settings for this characteristic if that is necessary to help me out.

Kind regards,

T IJ

[T IJ]

Well, this is awkward. It seems like every time I post a question on the devzone, somehow all the stars seem to align and it magically seems to work after a while.

None the less I do still have some other questions regarding the reading characteristic.

I am able to successfully read 394 bytes from my devkit using the Android app. I can detect the packages using Wireshark and a second devkit with the proper BLE sniffer stuff in it. I can see that I'm able to transmit those 394 bytes in a single timeslot of 7.5ms (picture), but I saw something funny which I cannot explain. I've set my MTU to well above the maximum packet size, I've also changed my DLE to 197 (to split my buffer in to two equal sized packages)

When the master initiates a read from the slave, the slave responds with an empty PDU.

Roughly 194ms the master transmits an empty PDU and the slave responds with the first data chunk.  (probably due to Android BLE stuff but cannot be sure)

After sending the first chunk of data the master sends an empty PDU, the slave responds with the second data chunk. (so far so good)

To my surprise I see that the master sends out another empty PDU and the slave responds to that with 5 bytes of data.

After searching around I found out that there is 5 extra bytes in the first data chunk(picture) which results into a roll over into the second frame and thus needing to create the third frame. 

I cannot find out what these 5 bytes mean or where they come from. The value of these bytes is 0x - 8B 01 04 00 0B

Can anyone with a great mind tell me what those 5 bytes are and if that is explainable or just something I have to deal with.

Kind regards,

T IJ

[T IJ]

[Simon]

I am sorry for the long delay, I have been quite busy lately. Have you been able to figure this out?

Best regards,

Simon

[T IJ]

I've found out that it is the L2CAP header and its unavoidable in my situation.