Hello,
I am trying to implement a streaming application using a DA14681 as the source and a DA14580 as the sink. The DA14681 is in Central role and the DA14580 is in Peripheral role. Sleep is disabled at both ends.
The eventual goal is to stream data to two peripherals at a data rate of about 35 kbps to each. We have already done this successfully with a DA14580 in the Central role. For various reasons, we would like to use the DA14681 in its place.
The structure is essentially that of the Serial Port Service although the MTU and characteristic length has been increased to 325 and the flow control is currently unused. The connection interval is 40 ms and the slave latency is set to 0. Thus at each connection event, we need to transmit 177 bytes on average which includes a 2-byte header.
On the DA14681, I have enabled the notification for the BLE_EVENTEND via ble_event_notif_enable_end_event(). At each call, data is added to a ring-buffer - provided it was emptied previously. In the 'main' loop of the task a transmit routine is called which checks for data and successful completion of the previous write and then executes a ble_gattc_write_no_resp() and sets a tx_busy flag. The tx_busy flag is cleared when the BLE_EVT_GATTC_WRITE_COMPLETED event is caught thus allowing the next write to take place.
The problem I am seeing is that no more than about 73 bytes of data are transferred per connection interval. At higher payload sizes, it takes several Connection Events before the data is actually transferred. At the desired size of 177 bytes, it takes more than 4 CIs to transmit one packet.
It's not clear what I'm missing. Any help would be appreciated. Again, we have this working with a DA14580 at both ends so it does not appear to be a problem at the peripheral end.
As a secondary question, is it possible to implement L2CAP CoCs on the DA14580? If so, is there any code that does so?
Thanks,
Sandeep
------------
Hi Sandeep Sira,
Since the 580 doens't support the packet length extention or the CoCs, i assume that you application is using only the MTU exchange scheme in order to exchange data.
期间设备发送的数据量connection interval depends on the packets that the central allows to a peripheral to send, so check how many packets are exchanged when there is data transaction ? (the amount of 73 bytes in each connection interval occurs in both ends, i assume that since you are talking about notifications this occurs when the peripheral device is sending data). The fact that you see only 73 bytes in each connection interval seems a bit weird since with the MTU exchange if there are, lets say 3 packets then the amount of bytes that should be transfered should be: each notification packet fits 27 bytes, the first packet will include the ATT header for the specific characteristic and the L2CAP header and the rest 20 bytes are the payload so in 3 packets the amount of clean payload are 20 + 27 + 27 = 74 bytes (the rest of the packets have a 27 payload since with the MTU exchange you save the ATT and the L2CAP header information in the packet). So even if the stack doesn't allow more than 3 packets the amount of the information should about 74 bytes and not 73. Now, how many packets are going to be sent its a matter of the central (this is not controlled by the sw, but from the stack) normally the amount of packets during a connection interval are quite more than 3 that i suppose that you have, so, in the central there is a configuration that instructs the central how long is going to keep the event for each connection that it has ce_min and ce_max, so perhaps those values force your central to limit the amount of packets that it can receive during a connection interval.
Thanks MT_dialog
MT_Dialog,
Thank you for your detailed answer. The ce_min is set by default to 0 in ble_config.h. Changing it to 20 (12.5 ms), which is the default in the DA14580, solved the problem.
That of course, raises another question. Why is the change to ce_min relevant? It would appear that ce_max is the controlling parameter.
Sandeep
-------------
Hi Sandeep Sira,
Both of the values ce_min and ce_max are relevant, based on those values the central decides the actual time that the central will keep a connection event alive, although the values are informative they provide the expected minimum and maximum length of the connection event. So i suppose that both of the values should be declared in order for the central to be aware how to allocate the time when more than one connection should be maintained and in order to save power. The fact that you ve changed the minimum value to a specific default forced the central to stay awake longer in order to listen to the peripheral for additional data.
Thanks MT_dialog
Hello, Dialog experts.
I need to know if it possible to use DA14681 as central device and gather advertisement data?
After some time send that data using usb cdc. Usb cdc I already checked and it is working.
How about gathering advertisement data?
Hi Sparta,
Could you please clarify your question in order to understand which your requirement is? As I am able to understand correctly from what you mentioned, you would like to have a central DA14681 connected with a DA14681 peripheral, so the peripheral will be sending data to the central, is that correct? This is possible and we have a reference design for this scope, named DSPS. Please check the link below:
//www.wsdof.com/products/dialog-serial-port-service-dsps
if you mean something else, please clarify your question/ I would kindly suggest you to create a new forum thread for your question. If you don’t know the procedure for creating a new forum thread, please let me know and I will provide you the appropriate guidelines.
Thanks, PM_Dialog