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
Device:
Hi 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.
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?
Regards, Max
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.
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
I see. I thought you were writing data in the other direction.
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 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.
如果你想知道Androi的外围d device has received all notifications, just write some value over any characteristic indicating this. You don't need to acknowledge intermediate packets, just the last one.
Thank you! I'll give it a try.
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.
How did you enable 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.
On the Android side, you need to both write the descriptor and to also locally register for notifications.
Good call! I went back and 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.
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.
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.
This is a huge improvement!!! Thanks again for your guidance.
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.
Best regards, Max
I guess the BLE throughput is less than the EEPROM, so the EEPROM is not the bottleneck.
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.
Upon connection, I see the Android Studio debugger reporting: 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?
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.
I realized I was using time 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!