请查看附加的PDF中的详细信息。
谢谢，
Paul.
Attachment:
设备：
⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.xmece.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.xmece.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
嗨pvmellor，
谢谢你的屏幕截图。让我检查一下，我会尽快回复你。你能澄清你如何发送数据吗？你在使用通知吗？此外，嗅探器日志将非常有帮助，以了解如何在空中交换Tha数据包。
谢谢，PM_Dialog
数据从智能手机（Android和iOS）发送到DA14850。它通过简单的特征写入，无需响应（或发送）。数据包嗅探器已订购，但我们希望您可以帮助我们从DA14580软件方面跟踪该过程。
我们尝试了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?
嗨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.
谢谢，PM_Dialog
好的试过这个 - 没有区别我害怕。任何其他想法？你能重现这个吗？一个简单的应用程序反复写入256byte特征应该展示问题。
We've done quite a bit of work on this now. We can sucessfully send a L2CAP Connection Parameter Update Request
我们看到主设备（智能手机）更改的连接间隔，新参数符合我们在响应消息中看到的步骤
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.
所以我有一些问题：
Appreciate your timely support as we have customers waiting...
谢谢，
Paul
嗨pvmellor，
Let me check your questions and try to replicate your issue and I will get back to you as soon as possible.
谢谢，PM_Dialog
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.
谢谢！
嗨pvmellor，
设备在连接间隔期间发送的数据量取决于中央允许发送外围设备的数据包。具有标准MTU选择的每个数据包的有效载荷为20字节。所以您发送的每个数据都可以载有20个字节。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.
具体地，设备可以通过空中发送的字节数由MTU（最大传输单元）限制，默认情况下MTU受限于包括ATT层开销的23个字节，因此有效载荷是20个字节。通过增加MTU大小，意味着您可以通过空中发送更多字节。在您的情况下，最大传输单元应该是您想要发送+ 3额外字节的字节数。您应该更改user_config.h头文件的user_gapm_conf结构的.max_mtu。在此之后，为了执行与中央的交换，您应该在具有连接时发送GattC_EXC_MTU_CMD（在USER_ON_CONNECTIONCE）中，580将执行交换。对于MTU Exchange功能而言，没有实现API，但您可以使用以下代码段：
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.
谢谢，PM_Dialog