Attribute long value, ATT_ReadBlobReq, How to decrease the interval between the blob response packets

Hi,

    I've modified the project 'SimplePeripheral' @ CC2541/CC2540 BLE stack 1.4.2, expanded the character 2 with 200-byte buffer. When I tried to read character 2 using ATT_ReadBlobReq, it appeared that several ATT_BlobReadRsp packets came out slowly. The time interval between 2 contiguous  response packets is almost 200 millisecond, experiment results are detailed below. So so so, here's the question, how to decrease the time interval between the contiguous response packets?

 Experiment settings:

  1. Connection interval is 1000ms, and i tried 7.5ms, but the results are the same.

  2. I've tried to add code ' HCI_EXT_OverlappedProcessingCmd( HCI_EXT_ENABLE_OVERLAPPED_PROCESSING )', but it didn't work.

 Experiment results:

  

Hi,

Can you try make sure the MCU is not halted using the HCI_EXT_HaltDuringRfCmd() API by setting it to HCI_EXT_HALT_DURING_RF_DISABLE?

Best wishes

Hi Zahid Haq,
All the experiments above are based on codes below.

HCI_EXT_ClkDivOnHaltCmd( HCI_EXT_ENABLE_CLK_DIVIDE_ON_HALT );
HCI_EXT_HaltDuringRfCmd( HCI_EXT_HALT_DURING_RF_DISABLE );
HCI_EXT_NumComplPktsLimitCmd( HCI_MAX_NUM_DATA_BUFFERS, HCI_EXT_ENABLE_NUM_COMPL_PKTS_ON_EVENT );
HCI_EXT_OverlappedProcessingCmd( HCI_EXT_ENABLE_OVERLAPPED_PROCESSING );
//LL_EXT_OverlappedProcessing( LL_EXT_ENABLE_OVERLAPPED_PROCESSING );

Hi Zahid Haq,

The info in the table above was copy from the BTool, and today I found that the log info came out from the BTool was not strictly in real-time.

The instruments in this experiment are: 1. USB dongle assosiated with the BTool, 2. the Peripheral running stack 1.4.2 @ CC2541.

The experiment actions flow are detailed below:

First, connect the peripheral to the USB dongle(master), and then start the communication by continuously sending notification to the dongle from the peripheral. At this time, I shut down the peripheral, but the log info was still coming out to the window of BTool. Amazing!
And a few seconds later, the log info stopped and a message of 'Device Disconnected' came out.

So, it seems that something wrong with the experiment. And I'll try to mesure the current changing by oscilloscope later.

Thanks still.

Hi,

    I get the figure from the oscilloscope of my new experiment.

    Experiment settings:

    1. BLE stack 1.4.2 @ CC2541

    2. Disable POWER_SAVING.

    3. Disable the automatic parameter update request routine in the stack.

    4. Expand characteristic 2 with 200-byte buffer. Add code in ' simpleProfile_ReadAttrCB - case SIMPLEPROFILE_CHAR2_UUID ',  let peripheral output a pulse when central try to read char 2 using ATT_ReadBlobReq.

    5. Set the connection interval as  20ms. Set slave latency as 0.

    6. Connect usb dongle to the peripheral. ( BTool program )

    7. Send command 'ATT_ReadBlobReq'  to the peripheral. And capture the pulse at specified GPIO port of CC2541.

    Result:

    1. The usb dongle (BTool) received 11 packets of ATT_ReadBlobRsp ( The former 9 packets contain 22-byte payload each,  the second last contains 2-byte payload, the last one is of zero-byte payload, that is, 9 x 22 + 2 + 0 = 200 )

    2. Figure below, pules in yellow-line indicate connection event, and pules in blue indicate responses to the ATT_ReadBlobReq.

3. Refer to the spec of BLE 4.0, the flow chart of read long characteristic follows the figure below. And it seems that the BTool didn't print out all the 'ATT_ReadBlobReq' log.

4. But the problem is still over there. Why did the several routines ' ReadBlobReq - ReadBlobRsp ' persist  that long ? The ten(or may be eleven )  ' ReadBlobReq - ReadBlobRsp ' routines last almost 400ms in total. Is there anyway to put one or more 'Req-Rsp' routine in one connection event ? Or how to increase the speed when using Blob operations ?

 

 I really need your help. Thanks.

Hi,

Can you attach the entire BTOOL log or an complete air sniffer trace using the fastest connection interval?

Best wishes

Hi,

1. Log and figures @ 20ms connection interval:

2. Figure  @ 7.5ms connection interval.

Comparison between 7.5ms instance and 20ms instance ( The log of 7.5ms instance is the same except the time stamp )

Command/Event	Log Info @ 7.5ms connection interval	Interval between packets @7.5ms		Log Info @ 20ms connection interval	Interval between packets @20ms
ATT_ReadBlobReq	[1] : <Tx> - 10:30:19.928			[1] : <Tx> - 10:37:09.873
GAP_HCI_ExtentionCommandStatus	[2] : <Rx> - 10:30:19.947			[2] : <Rx> - 10:37:09.885
ATT_ReadBlobRsp 22	[3] : <Rx> - 10:30:19.957			[3] : <Rx> - 10:37:09.925
ATT_ReadBlobRsp 22	[4] : <Rx> - 10:30:19.977	00:00.020		[4] : <Rx> - 10:37:09.965	00:00.040
ATT_ReadBlobRsp 22	[5] : <Rx> - 10:30:19.988	00:00.011		[5] : <Rx> - 10:37:10.005	00:00.040
ATT_ReadBlobRsp 22	[6] : <Rx> - 10:30:20.017	00:00.029		[6] : <Rx> - 10:37:10.045	00:00.040
ATT_ReadBlobRsp 22	[7] : <Rx> - 10:30:20.037	00:00.020		[7] : <Rx> - 10:37:10.085	00:00.040
ATT_ReadBlobRsp 22	[8] : <Rx> - 10:30:20.047	00:00.010		[8] : <Rx> - 10:37:10.125	00:00.040
ATT_ReadBlobRsp 22	[9] : <Rx> - 10:30:20.067	00:00.020		[9] : <Rx> - 10:37:10.165	00:00.040
ATT_ReadBlobRsp 22	[10] : <Rx> - 10:30:20.087	00:00.020		[10] : <Rx> - 10:37:10.205	00:00.040
ATT_ReadBlobRsp 22	[11] : <Rx> - 10:30:20.097	00:00.010		[11] : <Rx> - 10:37:10.245	00:00.040
ATT_ReadBlobRsp  2	[12] : <Rx> - 10:30:20.107	00:00.010		[12] : <Rx> - 10:37:10.285	00:00.040
ATT_ReadBlobRsp  0	[13] : <Rx> - 10:30:20.117	00:00.010		[13] : <Rx> - 10:37:10.295	00:00.010

Hi,

Since you are using the network processor configuration with USB as the GATT Client (i.e., BTool), you will need to account for the transport processing time before the Client can request the next read blob PDU. The fastest response time will be if you use an embedded GATT Client project.

A packet sniffer trace will help confirm likewise as it will shown the time timestamp for the Read Blob Request, which is not shown in the BTool log.

Best wishes