BLE Throughput too low (for large characteristic) | Dialog Semiconductor customer support - 亚博全网,亚博电竞菠菜,亚博国际官网平台网址

Mon, 2019-06-03 17:34

#2

PM_Dialog

Offline

Last seen:13 hours 25 min ago

加入:2018-02-08 11:03

Hi pvmellor,

Thanks for your screenshot. Let me check it and I will get back to you as soon as possible. Could you please clarify how you send data? Are you using notifications? Also, a sniffer log would be very helpful in order to understand how tha packets are exchanged over the air.

Thanks, PM_Dialog

Mon, 2019-06-03 20:32

#3

pvmellor

Offline

Last seen:1 year 5 months ago

加入:2017-04-27 20:30

Data is sent TO the DA14850

Data is sent TO the DA14850 FROM a smart phone (Android and iOS). It is sent via a simple characteristic WRITE with no response required (or sent). Packet sniffer has been ordered, but we had hoped you may be able to help us trace the process from the DA14580 software side.

Thu, 2019-06-06 10:44

#4

pvmellor

Offline

Last seen:1 year 5 months ago

加入:2017-04-27 20:30

我们尝试了changing the

我们尝试了changing the parameters in user_config.h for both user_gapm_conf and user_connection_param_conf, but nothing makes any difference to the actual speed of transfer. Do you have any ideas/suggestions to help with this? It is very slow as is. Is there a way to tell what parameters are being used at runtime?

Thu, 2019-06-06 17:13

#5

PM_Dialog

Offline

Last seen:13 hours 25 min ago

加入:2018-02-08 11:03

Hi pvmellor,

Could you please check I much is the maximum MTU size? Please set the max_mtu item of user_gapm_conf structure in user_config.h to 256.

Thanks, PM_Dialog

Thu, 2019-06-06 20:15

#6

pvmellor

Offline

Last seen:1 year 5 months ago

加入:2017-04-27 20:30

好的尝试——没有

好的尝试——没有difference I'm afraid. Any other thoughts? Can you reproduce this? A simple app to write a 256byte characteristic repeatedly should demonstrate the problem.

Fri, 2019-06-07 14:22

#7

pvmellor

Offline

Last seen:1 year 5 months ago

加入:2017-04-27 20:30

We've done quite a bit of

We've done quite a bit of work on this now. We can sucessfully send a L2CAP Connection Parameter Update Request

app_easy_gap_param_update_start(connection_idx);

We see the connection interval changed by the master (smart phone), the new parameters match those we see in the Response message

user_catch_rest_hndl() ... GAPC_PARAM_UPDATED_IND

These also match the GTL flow on/off polling period. So this is all working fine and we can set a connection interval of 15ms lets say.

However it still takes far too many connection event periods to transfer the data: about 44 for a 256 byte characteristic write. Even when we reduce the size of the characteristic to 64 bytes, it takes 10 connection events to write this to the DA14580. I can supply traces if required (pity we can't just add a jpeg to these tickets). And at just 16 bytes long, a characteristic still takes 2 connection events to transfer.

So I have some questions:

Would you expect to get this result? We get a throughput of 256 bytes in 0.66 seconds - this is 384 bytes/second: surely we can expect more than this!
Can you reproduce this and test it your end to see if you have the same issue? We run with an external processor and GTL enabled.
Can you offer an explanation as to why it takes so many connection events to send even a small amount of data? This seems to be the crucial consideration.
We tried an Adafruit "Bluefruit LE Sniffer", but it could only see advertising packets, it could not sniff the connection packets. Can you recommend a sniffer that would work with the DA14580 so we can trace what is happening over the air?
Is there a way to tell what the currently active connection parameters used in the link layer are?
Our problem seems to be getting less than one packet per connection event, but it would also be interesting to know:
- How many packets per connection event does the DA14580 support?
- There are min and max connection event parameters in "user_connection_param_conf". Do these control the number of packets sent per connection event? If so, how - could you detail them?

Appreciate your timely support as we have customers waiting...

Thanks,

Paul

Fri, 2019-06-07 16:13

#8

PM_Dialog

Offline

Last seen:13 hours 25 min ago

加入:2018-02-08 11:03

Hi pvmellor,

Let me check your questions and try to replicate your issue and I will get back to you as soon as possible.

Thanks, PM_Dialog

Wed, 2019-06-12 17:13

#9

pvmellor

Offline

Last seen:1 year 5 months ago

加入:2017-04-27 20:30

Hi, sorry to nag, but have

Hi, sorry to nag, but have you been able to make any progress on this? We are stuck now waiting for a response/help from your end. Please see specific questions above.

Thanks!

Thu, 2019-06-13 13:32

#10

PM_Dialog

Offline

Last seen:13 hours 25 min ago

加入:2018-02-08 11:03

Hi pvmellor,

期间设备发送的数据量connection interval depends on the packets that the central allows to a peripheral to send. The payload for each packet with the standard MTU selection is 20 bytes. So each data that you send can carry up to 20 bytes. You can't control the how many packets the BLE will send during a connection interval because is up to the master of the connection, if he doesn't want to accept the data he just won’t accept it even if you indicate that you have more data to send. If you would like to send more than 20 bytes of data you will have to increase your MTU size, then the L2CAP will take of the rest, chop the data and fit them in more than one packets.

Specifically, the number of bytes that a device can send over the air is limited by the MTU (Maximum Transfer Unit), the MTU by default is limited in 23 bytes including the ATT layer overhead, so the payload is 20 bytes. By increasing the MTU size that means that you can send more bytes over the air. In your case the maximum transfer unit should be the number of bytes you would like to send + 3 extra bytes. You should change the .max_mtu of the user_gapm_conf structure of the user_config.h header file. After doing that in order to perform the exchange with the central you should send the GATTC_EXC_MTU_CMD when you have a connection (in the user_on_connection) and the 580 will perform the exchange. There is no API implemented for the MTU exchange functionality but you can use the snippet below:

static void user_gattc_exc_mtu_cmd(uint8_t conidx)

{

struct gattc_exc_mtu_cmd *cmd = KE_MSG_ALLOC(GATTC_EXC_MTU_CMD,

KE_BUILD_ID(TASK_GATTC, conidx), TASK_APP,

gattc_exc_mtu_cmd);

cmd->req_type = GATTC_MTU_EXCH;

ke_msg_send(cmd);

}

Please check the attached screenshots. I have implemented a 256bytes - “Write with no response” characteristic. Also, the .max_mtu=259 and I used the above code snippet in the user_on_connection. For your information, I worked on the ble_app_peripheral example of SDK5.0.4. As you can see in the attached snapshot, the 256bytes are divided in smaller packets. The 256bytes are sent from a BLE generic application to the peripheral in 1 connection interval. You could see that while sending the data over the air only the Channel-30 was used, which means that was only 1 connection interval. The payload through is 7400 bits/sec. Possible reason why you got a smaller throughput would be that you might not have done the MTU exchange, so for sending 256bytes more than 1 connection interval was needed. Be aware that re-transmitions might be happened. You are able to use API uint16_t gattc_get_mtu(uint8_t idx) to poll the negotiated MTU. Regarding you question for the sniffer; I used the Frontline sniffer products for debugging BLE protocol.

Thanks, PM_Dialog

Attachment:

mtu_exchange.zip