Hello Dialog,
I asked this in an earlier thread of mine but it was flagged as solved and may not have been revisited - I am using the DA14580 with the SPS profile and am trying to use to to relay 20 bytes every 80ms. The DA gets the data over UART from the main uC and sends it to a portable device that displays the data. The problem I am having is that the data packets that my portable receives are not consistent in size - sometimes the packet has 20 bytes as desired, but other times single 20 byte transmission comes as two packets or the data is 20 bytes wide, but shifted.
I send the 20 bytes over UART over the duration of ~2 ms, so there should be plenty of time for the DA to receive the data and send it away before the next cycle of data comes in.
I need the data packets to be the same size always because my portable's application expects them to be consistent. Do you know what could be causing this issue?
Thank you,
SVL0822

嗨,你在使用HW流量控制吗?哪个设备被配置为中心(我推定了从Uart的主机MCU拍摄日期)?
Thanks JE_Dialog
你好je_dialog,
I am not using HW flow control. I presumed that this wasn't necessary because i get all the bytes that I send (over BLE) but what varies is the packet size that they come in.
I am using the "device" SPS project on my DA14580. The central is my main chip, the DA14580 is only acting as bluetooth-serial interface.
SVL0822
Hi svl0822,
您正在观察对话框串行端口服务的预期行为。串行端口链路与UART和数据包完整性完全异步,无法保证,这肯定从未意图。DSP实现是针对流数据进行了优化的,并且不是您的应用程序的理想选择。
From your description, you are actually attempting to send discrete data packages - which is exactly how BT Smart was intended. You should implement a custom service with a 20byte sized characteristic. Every time you have 20 bytes ready for BT transmission, you should go ahead and load them into the characteristic(in the GATT database). The smartdevice (tablet/smart phone) implementation is far simpler this way, and the packet integrity is ensured. You would use GATT Notify to make sure that the 20byte data chunk is send to the smartdevice every time you update the data.
如果您需要有关实现自定义服务的更多信息,请告诉我。它不像它声音那样可怕,并且尽可能更好地适合您所描述的用例。代码占用脚印也会更小。
MHv_Dialog,
Thank you for the detailed explanation. What you described sounds like it would work.
Is there any documentation available on implementing a custom service? I looked at the software development guide but it does not go into detail on this.
Is it possible for me to use the SPS service and just add a new characteristic in the "sps_server_task.c" file? Also, when you say "20 byte wide characteristic" do you mean having an attribute called "size" which would have length 20? I am looking at the declarations for the TX data characteristic and it has attributes of fixed lengths, so I do not see where the variability is coming from. Could you explain this for me?
感谢您的耐心等待。我是新的节目,不确定基础知识。
嗨,也许你应该参考the sample128 or spotar service.
您好,我面临着同样的情况,与微量的微型沟通,发送/接收13字节数据包。在两个方向上,一切都适用于单个数据包外壳,但最终会分崩离析,当只有一部分数据包放入UART到BLE缓冲区时,我收到通知。如果有一种简单的方法来暂停通知,直到UART上收到完整的13个字节,那将解决问题。TX_WAIT_LEVEL似乎暗示了这一点,但它被评论// 3数据包(20 + 2 * 27),没有进一步的解释。任何想法如果这是正确的方法?
嗨Klim,我可以高举level what you are trying to acheive ? the DSPS has been designed for a pure streaming app : there isn't anything in the way of preserving packet integrity - it just fills buffers and transmits. I was just wondering if there was a simpler approach that might help, like using AN-B-029 to build a simple custom profile to meet your needs. If DSPS is the way to go, we can look at your question about adding the TX_WAIT_LEVEL (its not somethign we've tried yet). BR JE_Dialog
Hi JE_Dialog,
My solution was to continue to stream the data, but within the app I disassemble/assemble the packet.
I included a timeout handler on packet reassembly so that if a given packet takes too long to assemble, then I *assume* that there was a problem maintaining the BLE connection.
In this case I reattempt to send/receive the packet, and eventually fail out to a "communication lost" exception handler.
Works good so far, if later I need to make any more changes then I will post them here.
干杯, - klim
Hi Klim, thanks for letting us know it worked ok for you... apprecaite the feedback, BR JE_DIalog