你好Dialog，
我在我以前的一个线程中问过这个问题，但它被标记为已解决，可能没有被重新访问-我正在使用带有SPS配置文件的DA14580，并尝试使用它每80ms中继20个字节。DA通过UART从主uC获取数据，并将其发送到显示数据的便携式设备。我遇到的问题是，我的便携设备接收到的数据包大小不一致——有时数据包有20个字节，但有时单个20字节的传输是两个数据包，或者数据是20个字节宽，但有移位。
我通过UART发送20个字节，持续时间约为2ms，因此在下一个数据周期到来之前，DA应该有足够的时间接收数据并将其发送出去。
我需要数据包始终保持相同的大小，因为我的便携应用程序希望它们保持一致。你知道是什么导致了这个问题吗？
谢谢您，
svl0822
你好，你在用硬件吗flow control ? and which device is configured as central (I'm presuming the one taking date from a host MCU over UART) ?
谢谢你的对话
Hello JE_Dialog,
我没有使用硬件流量控制。我认为这是没有必要的，因为我得到了我发送的所有字节（通过BLE），但不同的是它们进入的数据包大小。
我正在DA14580上使用“设备”SPS项目。中央是我的主芯片，DA14580只作为蓝牙串行接口。
svl0822
你好，svl0822，
You are observing the expected behavior of the Dialog Serial Port Service. The serial port link is completely asynchronous with the UART and packet integrity is not guaranteed, and this certainly was never intended. The DSPS implementation is optimized for streaming data, and is not the ideal fit for your application.
根据您的描述，您实际上是在尝试发送离散数据包—这正是BT Smart的初衷。您应该实现一个具有20字节大小特征的定制服务。每次你有20个字节准备好进行BT传输时，你应该继续并将它们加载到characteristic（GATT数据库）中。通过这种方式，smartdevice（平板电脑/智能手机）的实现要简单得多，而且数据包的完整性也得到了保证。您可以使用GATT Notify来确保每次更新数据时都会将20字节的数据块发送到smartdevice。
Let me know if you need more information on implementing a custom service. It is not as scary as it may sound, and it will definitely be a better fit as far as your described use case. The code footprint will also be a lot smaller.
MHv\U对话框，
谢谢你的详细解释。你所描述的听起来好像有用。
有关于实现定制服务的文档吗？我看了《软件开发指南》，但没有详细介绍。
我是否可以使用SPS服务并在“SPS\u server\u task.c”文件中添加一个新特性？另外，当你说“20字节宽特征”时，你的意思是有一个名为“size”的属性，它的长度为20？我正在查看TX数据特性的声明，它具有固定长度的属性，因此我看不到可变性来自何处。你能给我解释一下吗？
Thank you for your patience. I am new to BLE programming and am not sure of the basics.
嗨，也许你应该参考sample128或spotar服务。
你好,我是面对同样的情况,communication with a micro that sends/receives a 13 byte packet. everything works fine for a single packet case, in both directions, but eventually things fall apart and I am receiving notification when only part of the packet has been put into the UART to BLE buffer. If there is a simple way to suspend the notify until the full 13 bytes are recieved on the UART, that would solve the problem. TX_WAIT_LEVEL seems to suggest this, but it is commented with //3 packets (20 + 2*27) and no further explanation. Any idea if this is the right approach?
嗨，克里姆，我能从高层次上问一下你想做什么吗？DSP是为纯流应用而设计的：没有任何东西可以保护数据包的完整性——它只是填充缓冲区并传输数据。我只是想知道是否有一个更简单的方法，可能会有所帮助，如使用AN-B-029建立一个简单的自定义配置文件，以满足您的需要。如果DSPS是一种方式，我们可以看看您关于添加TX\u WAIT\u级别的问题（这不是我们尝试过的东西）。BR JE\u对话框
嗨，我的对话，
我的解决方案是继续流式传输数据，但在应用程序中我分解/组装数据包。
我在数据包重组中包含了一个超时处理程序，因此如果给定的数据包花费太长时间来组装，那么我*假设*维护BLE连接时出现了问题。
在这种情况下，我重新尝试发送/接收数据包，最终失败到“通信丢失”异常处理程序。
到目前为止效果不错，如果以后我需要做更多的修改，我会把它们贴在这里。
Cheers, --klim
嗨，克里姆，谢谢你让我们知道这对你很好。。。查看反馈，BR JE\u对话框