波特率稳定蓝牙串行通信 [英] Baud rates for stable Bluetooth serial communication
问题描述
我有一个Arduino巨型通过蓝牙（bluesmirf金设备）沟通，我写了一个C＃应用程序。该Arduino是不断发送的32个字符的串行信号中，第一始终是一个S和最后一个E。使用腻子我可以证实，这个信号被发送的时间正确的99％以上。
I have an arduino mega communicating over bluetooth (bluesmirf gold device) to a C# application that I wrote. The arduino is constantly sending a serial signal of 32 characters, the first always being an "S" and the last an "E". Using putty I can confirm that this signal is being sent correctly 99% of the time.
现在我想读我的C＃应用程序，我用下面的code这样的信号：
Now I want to read this signal with my C# application, which I am doing with the following code:
public string receiveCommandHC()
{
string messageHC = "";
if (serialHC.IsOpen)
{
while (serialHC.ReadChar() != 'S')
{
}
messageHC = serialHC.ReadTo("E");
serialHC.DiscardInBuffer();
}
return messageHC;
}
serialHC是串行类的。
serialHC is of the serial class.
有时，这种完美的作品，但我有问题，其他时候，我找不到为什么它的工作原理，但有时则没有。
Sometimes this works perfectly but other times I'm having problems, I cannot find out why it works sometimes but others not.
这是我似乎遇到的问题是，有时我得到了，我从Arduino的读取数据相当大的滞后。我注意到这一点，因为我送的按钮状态，他们只改了几秒钟我居然preSS后或松开aurduino的按钮。我用蓝牙设备的标准波特率，这是115200，并想知道，如果改变这种以低得多的速度可能会产生更好的结果？如果任何优势会带来什么？我不需要HIGHT通信速率，甚至更新状态4-5次，第二个是我的应用程序可以接受的。
The problem that I seem to be having is that sometimes I get a rather large Lag in the data that I am reading from the arduino. I notice this because I am sending button states and they only change a few seconds after I actually press or release the button on the aurduino. I used the standard baud rate of the bluetooth device, which is 115200 and was wondering if changing that to a much lower rate could yield better results? What if any advantage would that have? I do not need hight communication rates, even updating the state 4-5 times a second would be acceptable for my application.
是否有可能滞后是从我的code正在添加？我想这可能与正在等待进来的S但我不while循环明白为什么它应该挂在那里，因为有新的信号总是在一个较高的速度正在添加英寸
Is it possible the lag is comming from my code? I think it may be from the while loop that is waiting for the incomming "S" but then i dont see why it should hang there since there are new signals always comming in at a high rate.
林。它是多，我正在读当前最新的数据，并作用于新鲜的数据更加重要。
Im using the DiscardInBuffer() because I do not care about outdated data and just want to skip over that. It is much more important that I am reading current up to date data and acting on that fresh data.
感谢您的帮助！
最好的问候，
本德尔
更新：
刚刚发现更多的信息，同时调试。这个问题似乎只出现：
Just found out a bit more information while debuging. The problem only seems to appear:
- 当连接蓝牙（通过USB电缆也绝对没有滞后）
- 当从PC建立到另一装置（不同的COM端口和不同波特率）的第二蓝牙连接
是否有人在运行两个不同的设备关闭电脑上相同的蓝牙适配器的erxperiances？我可以管理连接到这两个没有问题，但仍然有滞后问题，前面提到的。
Does anybody have any erxperiances running two different devices off the same bluetooth dongle on the PC? I can manage to connect to both no problem but still having the lag issue mentioned before.
感谢您的帮助。
推荐答案
您不是的真正的这里使用物理串行端口。蓝牙驱动程序仅仅模拟的之一。这是常见的，Windows的API有一个明确的API函数集跟一个串口。仿真人让该接口到驱动简单，供应商没有提供一个接口的DLL或记录一个复杂的DeviceIoControl（）协议。
You are not really using a physical serial port here. The BlueTooth driver merely emulates one. This is common, the Windows API has a well defined set of api functions to talk to a serial port. Emulating one makes the interface to the driver simple, the vendor doesn't have to supply an interface DLL or document a complicated DeviceIoControl() protocol.
这意味着一件事，实际通讯设置并不重要。波特率是在这种情况下没有意义的，这是蓝牙无线电信号，用于设置传输速率。司机将接受你选择什么，但，否则将忽略它。握手信号的可能的是间preTED，它是由司机来实现它们。通信错误报告很少实施，蓝牙有纠错协议，不像一个真正的串口。
Which means for one thing that the actual communication settings don't matter. Baudrate is meaningless in this scenario, it is the BlueTooth radio signaling that sets the transfer rate. The driver will accept whatever you select but will otherwise ignore it. Handshake signals might be interpreted, it's up to the driver to implement them. Communication error reporting is very rarely implemented, BlueTooth has an error correcting protocol, unlike a real serial port.
没有，数据的丢失这里是完全独立的诱导。显然，驱动程序的不的实施DiscardInBuffer（）。这无所作为，但扔掉驱动程序接收到的数据。这正好错的，如果你的code运行有点晚了，或得到由一个线程上下文切换中断。
No, the loss of data here is entirely self induced. Clearly the driver does implement DiscardInBuffer(). Which accomplishes nothing but throw away any data that the driver received. This goes wrong if your code runs a bit late or gets interrupted by a thread context switch.
删除DiscardInBuffer（）调用。
Delete the DiscardInBuffer() call.
这篇关于波特率稳定蓝牙串行通信的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
