Data transfer time

[Filya]

Hi

I had this problem.
In my program, I send an archive with various data. I send the data using the notification. The central device is a smartphone with Android OS.
If you transfer data up to 10 packets, the smartphone normally receives them and displays the data. If the number of packets exceeds 10, then the remaining packets are no longer accepted, on the 10 packet, data reception is stopped. Data transfer is carried out as follows: after the connection, a timer is started, while the timer is interrupted, data is sent in a for loop. In this cycle, the data of the entire archive is divided into packets and the data transfer function is performed, therefore the delay between packets is minimal. The packet size does not matter, sent packets up to 200 bytes.
In order for the smartphone to be able to accept all packets, you must set a delay of at least 50 ms. before sending each package. If you set a delay with less time, then again the data does not come to the smartphone.

I also tried to send packets using the indication, and in this case, the transmission is normal, because the delay, due to the reverse response from the smartphone about the received data, is 75 ms.

I would like to know why the smartphone can not take a large number of packages? It may be necessary to have a minimum delay between packets or for some other reason.

Chip: BT840F (analog nRF52840);

SDK: nRF5_SDK_15.2.0;

Softdevice: s132_nrf52_6.1.0_softdevice;

Thanks in advance for the answer

[Filya]

Hi

I do not have a sniffer, so I make a log on the phone.

2021.hci_snoop20190424172643.cfa
With the help of it, I understood the problem a little. The fact is that during the transfer I lost part of the packages, and if all the packages did not arrive on the phone, he did not send me a flag about the completion of the work. Because of this, it appeared that the program was hanging.
About the data transfer. I have an archive of 12800 bytes. I form 200 byte packets and send them. Sending is done in a while (1) loop in the main program body. If you send packets without delay before each sending, then ~ 95% of packets are lost. To transfer the entire archive (64 packets) I need to set a delay of 25 ms. before sending each package.
If the packet is lost, the sd_ble_gatts_hvx function generates an error NRF_ERROR_RESOURCES. I tried to send packets every time the BLE_GATTS_EVT_HVN_TX_COMPLETE event is executed, but then the delay between sending each packet is 75 ms, which is very much for my purposes.

Can I somehow increase the transmission speed (that is, reduce the delay that I need to set) or is there a limitation due to the transfer of data to the phone?
Here it is stated that the transfer for BLE 4.2 is 775 Kbps, but this is in the interaction between the two nRFs.

I work within BLE 4.2, since it is this version that my phone supports

Thanks in advance for the answer

[Filya]

Hi

A little figured out the speed of transmission. I assumed that the number of packets for one interval is set to the maximum possible, but it turned out to be wrong. Inserting this piece of code

  // BLE Configuration
  ble_cfg_t ble_cfg;
  // Max Packets Per Connection Event
  memset(&ble_cfg, 0, sizeof ble_cfg);
  ble_cfg.conn_cfg.conn_cfg_tag                            = APP_BLE_CONN_CFG_TAG;
  ble_cfg.conn_cfg.params.gatts_conn_cfg.hvn_tx_queue_size = 6;
  err_code = sd_ble_cfg_set(BLE_CONN_CFG_GATTS, &ble_cfg, ram_start);
  APP_ERROR_CHECK(err_code);

I increased the transmission speed and was able to reduce the delay to 10 ms. Now the transmission is ~ 760 ms, instead of 1800 ms. Perhaps you can still increase the transmission speed, since I ran into such a parameter as event_length, but I didn’t understand how to calculate it correctly for a particular connection interval. At the moment my connection interval is 15 ms.

Regarding the capabilities of BLE 5, all the same to no avail. The data transfer time is slightly less than that of 4.2 - ~ 720 ms. by reducing the delay to 5 ms., although it should be almost 2 times lower, as I understood from its description.