请查看附加的PDF中的详细信息。
谢谢，
保罗。
设备：
⚠️
嗨，...感谢您来论坛。令人兴奋的消息！我们现在正在迁至我们的新论坛平台，将提供更好的功能，并包含在主对话框网站中。所有帖子和帐户都已迁移。我们现在只接受新论坛上的流量 - 请发布任何新线程https://www.dialog-seminile.com/support.。我们将在未来几天修复错误/优化搜索和标记。
嗨，...感谢您来论坛。令人兴奋的消息！我们现在正在迁至我们的新论坛平台，将提供更好的功能，并包含在主对话框网站中。所有帖子和帐户都已迁移。我们现在只接受新论坛上的流量 - 请发布任何新线程https://www.dialog-seminile.com/support.。我们将在未来几天修复错误/优化搜索和标记。
嗨pvmellor，
谢谢你的屏幕截图。让我检查一下，我会尽快回复你。你能澄清你如何发送数据吗？你在使用通知吗？此外，嗅探器日志将非常有帮助，以了解如何在空中交换Tha数据包。
谢谢，PM_DIALOG.
数据从智能手机（Android和iOS）发送到DA14850。它通过简单的特征写入，无需响应（或发送）。数据包嗅探器已订购，但我们希望您可以帮助我们从DA14580软件方面跟踪该过程。
我们已经尝试更改user_gapm_conf和user_connection_param_conf的user_config.h中的参数，但没有任何对实际传输速度的差异。您有任何想法/建议可以帮助吗？它的速度很慢。有没有办法讲述运行时在运行时使用的参数？
嗨pvmellor，
你能检查一下我的最大mtu大小吗？请在user_config.h中设置user_gapm_conf结构的max_mtu项到256。
谢谢，PM_DIALOG.
好的试过这个 - 没有区别我害怕。任何其他想法？你能重现这个吗？一个简单的应用程序反复写入256byte特征应该展示问题。
我们现在已经完成了很多工作。我们可以成功发送L2CAP连接参数更新请求
我们看到主设备（智能手机）更改的连接间隔，新参数符合我们在响应消息中看到的步骤
这些也匹配GTL流开/关投票时间。所以这一切都在正常工作，我们可以设置15ms的连接间隔让我们说。
但是，对于256字节特性写入，它仍然需要太多的连接事件期限：约44。即使我们将特性的大小降低到64字节，也需要10个连接事件以将其写入DA14580。如果需要，我可以提供追踪（遗憾我们不能只添加JPEG到这些票证）。并且只需16个字节，特征仍然需要2个连接事件来传输。
所以我有一些问题：
感谢您及时支持客户等待......
谢谢，
保罗
嗨pvmellor，
让我检查你的问题并尝试复制你的问题，我会尽快回复你。
谢谢，PM_DIALOG.
嗨，抱歉唠叨，但是你能够在这个方面取得任何进展吗？我们现在被困在你最后等待回复/帮助。请参阅上面的具体问题。
谢谢！
嗨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，但您可以使用以下代码段：
静态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）;
}
请检查附带的截图。我已经实施了256bytes - “没有回复写作”特征。此外，.max_mtu = 259，我在user_on_connection中使用上面的代码片段。为您的信息，我工作在SDK5.0.4的BLE_APP_PERITELAL示例上。正如您可以在附加的快照中看到的，则256bytes划分为较小的数据包。256bytes以1个连接间隔从BLE通用应用程序发送到外设。您可以看到，在空中发送数据时，仅使用通道-30，这意味着只有1个连接间隔。有效载荷通过7400位/秒。为什么您获得较小吞吐量的可能原因是您可能没有完成MTU Exchange，因此对于发送256bytes，需要超过1个以上的连接间隔。请注意，可能会发生重新传输。 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.