为什么我收到的串行数据BT得到切碎了呢？ [英] Why does the serial BT data I received get chopped out?
问题描述
我从BT串行连接接收数据应该是：
The data i receive from a BT serial connection should be:
0
1
2
3
.
.
.
27
28
29
0
1
2
3
.
.
.
etc
但我实际得到的一些数据都碎了。像这样的：
But what i actually get are some of the data are chopped out. Like this:
11
12
1
3
14
15
1
6
1
7
18
19
2
0
在BTSerialService.java
/ **
*此螺纹与远程设备的连接过程中运行。
*它可以处理所有传入和传出传输。
* /
/** * This thread runs during a connection with a remote device. * It handles all incoming and outgoing transmissions. */
private class ConnectedThread extends Thread {
private final BluetoothSocket mmSocket;
private final InputStream mmInStream;
private final OutputStream mmOutStream;
public ConnectedThread(BluetoothSocket socket) {
Log.d(TAG, "create ConnectedThread");
mmSocket = socket;
InputStream tmpIn = null;
OutputStream tmpOut = null;
// Get the BluetoothSocket input and output streams
try {
tmpIn = socket.getInputStream();
tmpOut = socket.getOutputStream();
} catch (IOException e) {
Log.e(TAG, "temp sockets not created", e);
}
mmInStream = tmpIn;
mmOutStream = tmpOut;
}
public void run() {
Log.i(TAG, "BEGIN mConnectedThread");
byte[] buffer = new byte[1024];
//final byte[] buffer = new byte[1024];
int bytes;
// Keep listening to the InputStream while connected
while (true) {
try {
// Read from the InputStream
bytes = mmInStream.read(buffer);
//Send the obtained bytes to the UI Activity
mHandler.obtainMessage(FinalSetting.MESSAGE_READ, bytes, -1, buffer).sendToTarget();
} catch (IOException e) {
Log.e(TAG, "disconnected", e);
connectionLost();
break;
}
}
}
然后在FinalSetting.java
案例信息阅读：
Then in the FinalSetting.java Case Message Read:
case MESSAGE_READ:
int i;
byte[] readBuf = (byte[]) msg.obj;
// construct a string from the valid bytes in the buffer
String readMessage = new String(readBuf, 0, msg.arg1);
Log.i(LOG_TAG, readMessage);
mTextView.setText(readMessage);
String [] numbers = readMessage.split("\n");
int [] intNumber = new int[numbers.length];
for (String number : numbers) {
if(number.trim().length()>0){
try{
for (i=0;i<numbers.length;i++){
intNumber[i] = Integer.valueOf(number.trim());
if (intNumber[i]<0 || intNumber[i]>95){
//some action
}
}
} catch (NumberFormatException e){
Log.i(LOG_TAG, "Unable to parse integer" + e);
}
}
}
break;
什么LogCat中显示：
05-06 17:28:07.079: I/HBAS(15090): 10
05-06 17:28:07.079: I/HBAS(15090): 11
05-06 17:28:07.079: I/HBAS(15090): 12
05-06 17:28:07.969: I/HBAS(15090): 1
05-06 17:28:08.029: I/HBAS(15090): 3
05-06 17:28:09.019: I/HBAS(15090): 14
05-06 17:28:09.979: I/HBAS(15090): 1
05-06 17:28:10.029: I/HBAS(15090): 5
05-06 17:28:10.989: I/HBAS(15090): 16
05-06 17:28:12.009: I/HBAS(15090): 17
05-06 17:28:12.999: I/HBAS(15090): 18
05-06 17:28:13.999: I/HBAS(15090): 19
05-06 17:28:14.999: I/HBAS(15090): 20
05-06 17:28:16.009: I/HBAS(15090): 21
因此，没有人知道如何解决这个问题？
在此先感谢..
So does anyone knows how to solve this??? Thanks in advance..
推荐答案
再看看你的数据 - 你实际上正在接受这一切，你刚才提出的无效假设你会收到你发送到相同大小的块英寸
Look at your data again - you actually are receiving it all, you have just made an invalid assumption that you will receive it in the same size chunks you sent it in.
05-06 17:28:07.079: I/HBAS(15090): 11
05-06 17:28:07.079: I/HBAS(15090): 12
05-06 17:28:07.969: I/HBAS(15090): 1
05-06 17:28:08.029: I/HBAS(15090): 3
请参阅你有你的'13' - 只有它进来作为一个'1'，然后是'3'。
See you got your '13' - only it came in as a '1' and then a '3'.
这是完全允许的，你应该期望有相当频繁发生。您将需要引入重组数据并分割它成有用的片段的一些手段。
That's perfectly allowed and something you should expect to have happen quite frequently. You will need to introduce some means of regrouping your data and dividing it up into useful pieces.
您可以做类似发送
0011
0012
0013
等，并尝试分析前要组装四字节块。如果传输是一个保证，这实际上会工作，虽然感觉风险 - 如果它全球有机纺织品标准不同步，它会留出同步的，直到系统复位或随机漫步回。但是，如果运输保证不会删除或重新排序任何东西（没有至少警告你，它有），然后在理论可能不会看到（以外的错误处理）。
etc and always assemble four-byte chunks before attempting to parse them. If the transport is one that is guaranteed, this actually will work, though it feels risky - if it ever gots out of sync, it would stay out of sync until the system was reset or randomly wandered back on. But if the transport is guaranteed not to drop or re-order anything (without at least warning you that it has), then in theory that probably won't be seen (outside of your error handler).
另一种常见的想法是引进不能在数据中出现的分隔符，例如：
Another common idea would be to introduce delimiters which cannot occur in the data, for example
11\n
12\n
13\n
和尝试分析前为结尾的换行符。这样做，你可以抛弃一些乱码和synching你找到下一个新行恢复优势。
And look for the terminating newline before attempting to parse. This has the advantage that you could discard something garbled and recover by synching to the next newline you find.
最后，是所有值是可能的数据，因此你不能保留一个分隔符/终结的情况。在这种情况下，这是常见的保留一个作为precedes的特殊含义序列转义字符，并让这些特殊的序列中的一个代表转义字符的文字出现 - 这就像\\在带引号的字符串处理其中，\\ n表示换行和\\\\是指文字\\
Finally, there is the case where all values are possible in the data, so you cannot reserve one for a delimiter/terminator. In that case, it's common to reserve one as an escape character which precedes a sequence of special meaning, and have one of those special sequences stand for a literal occurrence of the escape character - that's like the handling of \ in quoted strings where "\n" means newline and "\\" means a literal \
编辑：哦，幽默，我不得不逃离双反斜杠，让他们展示，而不是反斜杠ñ
oh, the humor, I had to escape the double backslashes to get them to display, but not the backslash n
这篇关于为什么我收到的串行数据BT得到切碎了呢？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
