I'm not sure if creating a characteristic with a larger number of bytes and increasing the MTU value would result in a faster data transfer. Do you think it will help?
What you should do is use Write Without Response rather than Write With Response in order to be able to send multiple 20 bytes packets in one connection event. That will give you about the same performance as increasing the MTU.
Android is also built in such a way that it never drops incoming notifications but forwards all of them in the correct order to the app that is listening for the characteristic.
The only thing that can happen is that the connection is lost which means transmission is aborted, but all received notifications have still been received in the correct order. The most simple way here is to just restart everything.
Unfortunately, I'm not getting this to work. I modified the DA code to add a notify attribute to the data characteristic and see that it is pushing out the data as expected. The Android end is not working, however. I can't enable notifications, getting a write declaration error in the process. I'm stuck at this point.
I'm running a Samsung Galaxy Tab A tablet with Android 6.0.1. The test app is generated by Bluetooth Developer Studio and is fairly simple. Each custom characteristic (only slightly modified from the ble_app_peripherals SDK example) has buttons for write, read, and enable notifications for what has been defined for the characteristic.. So .... I can scan, connect, and read and write other characteristics, but when I click the button for enable notifications on the data characteristic it results in the write declaration error (seen via debug mode of Android Studio). The BLE code in the app to enable notifications looks almost identical to the Android Developer examples ..... so I don't understand why it's not working as advertised. The error message isn't any help .... status code 129.
如果你知道任何细微的事情要纠正这种error, let me know. I don't think it's appropriate to get into a detailed Android discussion here, but I can post an email address if you'd like to take the discussion offline. I've seen a great deal of complaining online about Samsung's version of Marshmallow, so perhaps I have run across something in it that doesn't work. I don't have another Android device to try, but could consider backing down to Android 5 on the Samsung tablet.
您是如何启用的notifications on the DA14580 side? You both need to set the ATT permission, and also set a bit on the GATT characteristic declaration. A client characteristic config descriptor must also exist.
Easiest is to just follow existing sample code that has a notification characteristic.
I'm now able to successfully write the descriptor on the Android side and at least enable notifications. I have a little more work to do to see if I can complete the data transfers in my test case but will report back.
Thanks for the continued help. Very much appreciated.
A tip is to lower the connection interval (look for connection parameter update request) to send data faster. Otherwise there is no limit how much you can stream as far as I know.
My data rate fell off dramatically with a larger 1KB block, 820 msec. transfer time. I'm fairly sure this isn't due to any EEPROM timing as I read the data into a large array prior to running the test, but I'll check on it. I suppose this might be due to the connection interval you mentioned? On the DA side, I see in user_config.h there are connection interval values which appear to be 10 msec min and 20 msec max. This looks OK if they're the default connection parameters. I tried altering the values in user_config.h. If I set both to 10 msec, things stop working. If I set the max value to 11.25, I only get a slightly better transfer time, 791 msec. Times also seem to vary over iterations of the test.
Hi Max44,
4.2的新特性将LE的链路层PDU有效负载从27字节扩展到251字节，这在580上不受支持，因为它是4.2可选特性。当选择一个更大的MTU时，你不会改变LE的PDU，而是改变上层的缩写，在L2CAP之上接受更大的有效载荷，传输包的实际有效载荷保持不变。
谢谢你的对话
MT公司，
好的，谢谢。
正如你可能从前面的问题猜到的，我正在尝试发回一些记录在EEPROM中的传感器数据。我想发送EEPROM数据页（256字节）。我试着用ble\u app\u peripheral中设置的20字节数据的自定义特性发送一个包含多个读取的页面，几乎花了1秒。
I'm not sure if creating a characteristic with a larger number of bytes and increasing the MTU value would result in a faster data transfer. Do you think it will help?
你好，麦克斯
What you should do is use Write Without Response rather than Write With Response in order to be able to send multiple 20 bytes packets in one connection event. That will give you about the same performance as increasing the MTU.
乔奇姆，
感谢您的输入，我的数据流是从DA到Android平板电脑/手机，该平板电脑/手机正在读取连接到DA14580的EEPROM中存储的数据。我曾研究过使用notify读取数据，但从最近与MTèu Dialog的讨论来看，没有任何反馈表明平板电脑/手机读取并存储了数据。我担心如果我只是将数据推入数据特性中，可能会导致数据丢失，所以我实现了一个流控制特性作为确认。当然，这会增加不可伸缩的开销，并进一步降低数据传输速度。如果你知道一些更好的技术来处理这个，请让我知道。现在，我计划增加数据特征中的字节数。。。。如果这看起来没什么用的话，也许可以增加MTU值。这对我来说是一个新的领域，所以我正在迈出一小步。
你好，麦克斯
I see. I thought you were writing data in the other direction.
如果您只是推送带有通知的数据（逐个发送并等待GATTC\u CMP\u EVT发送下一个），它们将以最大速度按顺序发送，并且由于链路层在发送下一个数据包之前等待上一个数据包的确认，因此不会在空中丢弃任何数据包。
Android is also built in such a way that it never drops incoming notifications but forwards all of them in the correct order to the app that is listening for the characteristic.
The only thing that can happen is that the connection is lost which means transmission is aborted, but all received notifications have still been received in the correct order. The most simple way here is to just restart everything.
如果希望外设知道Android设备已收到所有通知，请在任何指示此的特征上写一些值。您不需要确认中间数据包，只是最后一个数据包。
谢谢您！我试试看。
Unfortunately, I'm not getting this to work. I modified the DA code to add a notify attribute to the data characteristic and see that it is pushing out the data as expected. The Android end is not working, however. I can't enable notifications, getting a write declaration error in the process. I'm stuck at this point.
I'm running a Samsung Galaxy Tab A tablet with Android 6.0.1. The test app is generated by Bluetooth Developer Studio and is fairly simple. Each custom characteristic (only slightly modified from the ble_app_peripherals SDK example) has buttons for write, read, and enable notifications for what has been defined for the characteristic.. So .... I can scan, connect, and read and write other characteristics, but when I click the button for enable notifications on the data characteristic it results in the write declaration error (seen via debug mode of Android Studio). The BLE code in the app to enable notifications looks almost identical to the Android Developer examples ..... so I don't understand why it's not working as advertised. The error message isn't any help .... status code 129.
如果你知道任何细微的事情要纠正这种error, let me know. I don't think it's appropriate to get into a detailed Android discussion here, but I can post an email address if you'd like to take the discussion offline. I've seen a great deal of complaining online about Samsung's version of Marshmallow, so perhaps I have run across something in it that doesn't work. I don't have another Android device to try, but could consider backing down to Android 5 on the Samsung tablet.
您是如何启用的notifications on the DA14580 side? You both need to set the ATT permission, and also set a bit on the GATT characteristic declaration. A client characteristic config descriptor must also exist.
Easiest is to just follow existing sample code that has a notification characteristic.
在Android端，您既需要编写描述符，也需要在本地注册通知。
打得好！我返回并在我的user\u custs\u config.h文件中发现了一些错误。正如你所建议的，我遵循了一个现有的示例，但它是针对indicate属性的。我错过了编辑所有的地方，以改变它通知。
I'm now able to successfully write the descriptor on the Android side and at least enable notifications. I have a little more work to do to see if I can complete the data transfers in my test case but will report back.
Thanks for the continued help. Very much appreciated.
马克斯
乔奇姆，
我发送200字节（连续10次读取20个字节）的测试用例在纠正了启用notify问题后工作正常。我在Android平板电脑上测量了30毫秒，从我收到一个write命令的响应开始发送数据到从存储在平板电脑阵列中的DA获取所有200个字节。
This is a huge improvement!!! Thanks again for your guidance.
我要看看能不能把测试扩展到1KB传输。你知道我用这种方式传输的数据量有没有限制吗？我的EEPROM是一个2兆比特，我也打算用它作为启动内存。我可能有大约230KB的日志数据要发送。
Best regards, Max
我猜BLE的吞吐量比EEPROM小，所以EEPROM不是瓶颈。
A tip is to lower the connection interval (look for connection parameter update request) to send data faster. Otherwise there is no limit how much you can stream as far as I know.
My data rate fell off dramatically with a larger 1KB block, 820 msec. transfer time. I'm fairly sure this isn't due to any EEPROM timing as I read the data into a large array prior to running the test, but I'll check on it. I suppose this might be due to the connection interval you mentioned? On the DA side, I see in user_config.h there are connection interval values which appear to be 10 msec min and 20 msec max. This looks OK if they're the default connection parameters. I tried altering the values in user_config.h. If I set both to 10 msec, things stop working. If I set the max value to 11.25, I only get a slightly better transfer time, 791 msec. Times also seem to vary over iterations of the test.
连接后，我看到Android Studio调试器报告：onClientConnParamsChanged（）-Device=80:EA:CA:00:00:03 interval=9 status=0
I think the DA14580 sets the intervals in increments of 1.25 msec according to the comments, so 9 would be the 11.25 msec?
最大间隔为20毫秒时，我得到：onClientConnParamsChanged（）-Device=80:EA:CA:00:00:03 interval=15 status=0 15 x 1.25=18.75
所以看起来我可以稍微调整一下，但没有太大的改善。
我意识到我是在用DA上的时间在UART上写调试消息。我配置了所有这些，并关闭了开发调试模式。现在，将连接间隔max设置为11.25毫秒（如上所述），对于每个20字节的50个数据包，我得到了161毫秒的传输时间。这太好了！