Hi Dialog,
I know you've said "In short, DA1458x is now officially qualified as a BT 4.2 device, without supporting optional features." but it isn't clear to me is the BLE PDU extension to 251 bytes is considered an optional feature. If it's supported in SDK 5.0.3, is there some configuration needed for it?
I did read the post on using GATT_EXC_MTU_CMD to define a larger MTU and I'm looking into that.
Thanks, Max
设备：
嗨，Max44，
The new feature of 4.2 extends the Link Layer PDU of LE from 27 to 251 bytes of payload, this is not supported on the 580, since its an 4.2 optional feature. When choosing a larger MTU you dont change the LE's PDU but the abbillity that upper layers, above the L2CAP to accept larger payloads, the actual payload of the transmitting packets stays the same.
Thanks MT_dialog
MT,
OK, thanks.
As you may guess from previous questions, I'm experimenting with sending back some sensor data logged into an EEPROM. I'd like to send pages of EEPROM data (256 bytes). I tried sending a single page with multiple reads using the custom characteristic of 20 bytes of data set up in ble_app_peripheral and it took almost 1 second to do it.
我不确定创建一个具有更大字节数的特征并增加MTU值是否会导致更快的数据传输。你认为这会有帮助吗？
Regards, Max
为了能够在一个连接事件中发送多个20字节的数据包，您应该使用Write Without Response而不是Write With Response。这将使您获得与增加MTU相同的性能。
Joacimwe,
Thanks for the input, My data flow is from the DA to an Android tablet/phone that is reading the data stored in an EEPROM connected to a DA14580. I had looked into using notify for the data reads, but from recent discussions with MT_Dialog there wasn't any feedback that the tablet/phone had read and stored the data. I was concerned this might result in loss of data if I just pushed data into the data characteristic, so I implemented a flow control characteristic as an acknowledge. Of course, this increases BLE overhead and further slows data transfer. If you know of some better techniques to handle this, please let me know. For now I'm planning to look at increasing the number of bytes in the data characteristic .... and perhaps increasing the MTU value if that doesn't appear to do much. This is new territory for me, so I'm taking small steps.
Regards, Max
我懂了。我以为你在往另一个方向写数据。
If you just push the data with notifications (send them one by one and wait for GATTC_CMP_EVT to send the next one), they will be sent in order with maximum speed and no packets will be dropped on the air thanks to the Link Layer which waits for acknowledgement of the previous packet before the next is sent.
Android的构建方式也是这样的，它从不丢弃传入的通知，而是以正确的顺序将所有通知转发给正在侦听该特性的应用程序。
唯一可能发生的事情是连接丢失，这意味着传输被中止，但所有接收到的通知仍然以正确的顺序接收。这里最简单的方法就是重启一切。
如果你想让外设知道Android设备已经收到了所有的通知，只需在任何表示这一点的特征上写一些值。您不需要确认中间数据包，只需要确认最后一个数据包。
谢谢您！我给你一个机会try.
不幸的是，我不能让这个工作。我修改了DA代码，为数据特性添加了一个notify属性，并看到它正在按预期输出数据。然而，Android端并不起作用。我无法启用通知，进程中出现写入声明错误。我被困在这一点上了。
我运行的是三星Galaxy Tab平板电脑，搭载Android 6.0.1。测试应用程序由Bluetooth Developer Studio生成，非常简单。每个自定义特性（仅从ble\u app\u peripherals SDK示例稍作修改）都有用于写入、读取和启用特性定义通知的按钮。。所以。。。。我可以扫描、连接以及读写其他特性，但是当我单击数据特性上的enable notifications按钮时，会导致写声明错误（通过androidstudio的调试模式可以看到）。应用程序中用于启用通知的BLE代码看起来与Android开发人员示例几乎相同。。。。。所以我不明白为什么它没有像宣传的那样工作。错误消息没有任何帮助。。。。状态代码129。
如果你知道任何微妙的事情来纠正这个错误，让我知道。我不认为在这里进行详细的Android讨论是合适的，但是如果你想离线讨论，我可以发布一个电子邮件地址。我在网上看到很多人抱怨三星版的棉花糖，所以也许我在里面碰到了一些不起作用的东西。我没有其他Android设备可以尝试，但可以考虑在三星平板电脑上使用Android 5。
如何在DA14580端启用通知？你们两个都需要设置ATT权限，还需要在GATT特性声明上设置一点。客户端特征配置描述符也必须存在。
最简单的方法是只遵循具有通知特性的现有示例代码。
On the Android side, you need to both write the descriptor and to also locally register for notifications.
打得好！我回去found some errors in my user_custs_config.h file. I had followed an existing example as you suggested, but it was for an indicate attribute. I missed editing all of the places to change it to notify.
我现在能够在Android端成功地编写描述符，并且至少能够启用通知。我还有一点工作要做，看看我是否可以完成我的测试用例中的数据传输，但会报告回来。
谢谢你一直以来的帮助。非常感谢。
Max
Joacimwe,
My test case of sending 200 bytes (10 consecutive reads of 20 bytes) worked after correcting the enabling notify problems. I measured 30 msec on the Android tablet from the time I got a response back from a write command to initiate sending the data to getting all 200 bytes from the DA stored in an array on the tablet.
这是一个巨大的进步！！！再次感谢您的指导。
I'm going to see if I can expand the test to a 1KB transfer. Do you know if there's a limit to how much data I can stream in this manner? My EEPROM is a 2 Mbit which I'm also planning to use as a boot memory. I could potentially have around 230KB of logged data to send.
向你问好，麦克斯
我想最重要的是less than the EEPROM, so the EEPROM is not the bottleneck.
建议降低连接间隔（查找连接参数更新请求）以更快地发送数据。否则，据我所知，你能流多少是没有限制的。
我的数据速率急剧下降，1KB的数据块更大，820毫秒。传输时间。我相当肯定这不是由于任何EEPROM的时间，因为我读到一个大数组的数据之前，运行测试，但我会检查它。我想这可能是因为你提到的连接间隔？在DA端，我在user_config.h中看到了连接间隔值，最小值为10毫秒，最大值为20毫秒。如果它们是默认的连接参数，这看起来是正常的。我试图改变user\u config.h中的值。如果我把两者都设为10毫秒，事情就停止了。如果我把最大值设为11.25，我只得到一个稍微好一点的传输时间，791毫秒。时间似乎也随着测试的迭代而变化。
Upon connection, I see the Android Studio debugger reporting: onClientConnParamsChanged() - Device=80:EA:CA:00:00:03 interval=9 status=0
我认为DA14580根据注释将间隔设置为1.25毫秒，那么9就是11.25毫秒？
And with the max interval at 20 msec I was getting: onClientConnParamsChanged() - Device=80:EA:CA:00:00:03 interval=15 status=0 15 x 1.25 = 18.75
So it appears I can tweak things a little, but not much of a significant improvement.
我意识到我在利用时间on the DA to write debug messages on the UART. I configured all that off and turned off development debug mode. Now with the connect interval max set to the 11.25 msec as above, I'm getting a transfer time of 161 msec for 50 packets of 20 bytes each. This is good!