Android InputStream fallen die ersten zwei bytes (modifiziert BluetoothChat)

Ive verwendet code von der BluetoothChat-Beispiel zum senden und empfangen von byte-Daten von einem Bluetooth-Waage.
Das Skala empfängt den Befehl von dem Gerät und sendet dann wieder ein byte-array.
{2,198,48,48,48,48,199,3}
Die 2 = STX, 198 = packet start, - und 199 = packet end, und 3 = ETX in unserem comms Protokoll.

Alles funktioniert Prima, außer, dass der folgende code in die BluetoothChatService.java reagiert seltsam, dass es Tropfen die ersten zwei bytes.

/**
     * 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, String socketType) {
            Log.d(TAG, "create ConnectedThread: " + socketType);
            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");
            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(BluetoothChat.MESSAGE_READ, bytes, -1, buffer)
                            .sendToTarget();
                } catch (IOException e) {
                    Log.e(TAG, "disconnected", e);
                    connectionLost();
                    //Start the service over to restart listening mode
                    BluetoothChatService.this.start();
                    break;
                }
            }
        }

Ich habe ein problem speziell mit dem folgenden code-Abschnitt:

 bytes = mmInStream.read(buffer);

                    //Send the obtained bytes to the UI Activity
                    mHandler.obtainMessage(BluetoothChat.MESSAGE_READ, bytes, -1, buffer)
                            .sendToTarget();

Beim Debuggen, und betrachten den Inhalt des Puffers in mmInStream.read(buffer), bevor es ausgeführt wird, wird der Puffer enthält die richtigen Daten, die gesendet wurde, zurück durch die Skalierung Gerät ie:

{2,198,48,48,48,48,48,199,3}

aber sobald der code trat, die ersten beiden bytes im Puffer sind abgestreift, und es jetzt fälschlicherweise enthält:

{48,48,48,48,48,199,3}

und es ist diese, dass der message-handler dann endlich geht auf die Aktivität.

Für mehr Klarheit, wie ich hinzufügen muss, dass der stream von bytes, die gesendet werden von der Skala sind Hex-Zeichen im Bereich von 00 bis FF.
Aus irgendeinem seltsamen Grund, der string sieht eigentlich so aus in den debugger:

{2,-58,48,48,48,48,48,-57,3}

und dann die 2,-58, werden gelöscht.

Ich bemerkt, dass wenn ich ein byte-array über eine Steckdose, die ich tun müssen, die folgenden:

byte[] sendBytes = {2,(byte)198,48,48,48,48,48,(byte)199,3}

Wenn der Inhalt dieses array wird gedebuggt wird es geben {2,-58,48,48,48,48,48,-57,3}

Bitte verstehen Sie, dass ich bin neu in Android - java, und haben eine Menge zu lernen. Alle Hilfe wird geschätzt.
Dank
Adrian

Habe ich Hinzugefügt, log.ich habe Einträge, um besser zu verstehen, was passiert ist, basierend auf Radu ' s Rat. Es scheint, dass, nachdem ich das schreiben von Daten auf mein Gerät über Bluetooth, antwortet Sie, und Lesen wir aus irgendeinem Grund nur die ersten zwei bytes, dann senden Sie diese an die message-handler, dann Lesen Sie den rest der Pakete, gesendet von dem Gerät, und dann schicken Sie dies ab, um den message-handler, aber bevor der Hundeführer hat sogar geantwortet, das erste mal, den Puffer bereits überschrieben worden sein, so durch die Zeit, die der handler versucht zu Lesen, die ersten zwei bytes, es ist das Lesen der 3. und 4. Byte des Antwort-Paket dann sofort reagiert wieder und liest das gesamte Paket aus 3-Platz 17.
Also wenn ich es einfach .. die message-handler nur eine Antwort auf die gesendete Puffer nach dem es überschrieben wurde. Siehe log unten:

09-05 13:16:52.093: V/BluetoothSocket.cpp(11279): writeNative
09-05 13:16:52.118: I/IN_BUFFER(11279): The entire buffer after read stream into buffer: 2 
09-05 13:16:52.118: I/IN_BUF_AFTER(11279): 2 
09-05 13:16:52.118: I/IN_BUF_AFTER(11279): -58 
09-05 13:16:52.118: I/IN_BUF_AFTER(11279): 0 
09-05 13:16:52.118: I/IN_BUF_AFTER(11279): 0 
...truncated to save space ... 
09-05 13:16:52.163: I/IN_BUF_AFTER(11279): 0 
09-05 13:16:52.163: I/IN_BUFFER(11279): We now send to handler.
09-05 13:16:52.168: I/IN_BUFFER(11279): Read Stream into Buffer:
09-05 13:16:52.168: V/BluetoothSocket.cpp(11279): readNative
09-05 13:16:52.168: I/IN_BUFFER(11279): The entire buffer after read stream into buffer: 17 
09-05 13:16:52.168: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:52.168: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:52.168: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:52.173: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:52.173: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:52.173: I/IN_BUF_AFTER(11279): 44 
09-05 13:16:52.173: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:52.178: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:52.178: I/IN_BUF_AFTER(11279): 49 
09-05 13:16:52.178: I/IN_BUF_AFTER(11279): 50 
09-05 13:16:52.188: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:52.188: I/IN_BUF_AFTER(11279): 44 
09-05 13:16:52.188: I/IN_BUF_AFTER(11279): 85 
09-05 13:16:52.188: I/IN_BUF_AFTER(11279): 13 
09-05 13:16:52.188: I/IN_BUF_AFTER(11279): -57 
09-05 13:16:52.188: I/IN_BUF_AFTER(11279): 3 
09-05 13:16:52.188: I/IN_BUF_AFTER(11279): 6 
09-05 13:16:52.188: I/IN_BUF_AFTER(11279): 0 
...truncated to save space ... 
09-05 13:16:52.188: I/IN_BUF_AFTER(11279): 0 
09-05 13:16:52.188: I/IN_BUFFER(11279): We now send to handler.
09-05 13:16:52.193: I/IN_BUFFER(11279): Read Stream into Buffer:
09-05 13:16:52.208: V/BluetoothSocket.cpp(11279): readNative
09-05 13:16:52.208: I/MESSAGE_READ(11279): I am reading 2 bytes
09-05 13:16:52.208: I/Content(11279): The entire array:
09-05 13:16:52.208: I/some hardcoded tag(11279): 0 
09-05 13:16:52.208: I/some hardcoded tag(11279): 0 
09-05 13:16:52.273: I/MESSAGE_READ(11279): I am reading 17 bytes
09-05 13:16:52.273: I/Content(11279): The entire array:
09-05 13:16:52.273: I/some hardcoded tag(11279): 0 
...truncated to save space ... 
09-05 13:16:52.283: I/some hardcoded tag(11279): 0 
09-05 13:16:52.283: I/some hardcoded tag(11279): 0 
09-05 13:16:54.528: V/BluetoothSocket.cpp(11279): writeNative
09-05 13:16:54.553: I/IN_BUFFER(11279): The entire buffer after read stream into buffer: 2 
09-05 13:16:54.553: I/IN_BUF_AFTER(11279): 2 
09-05 13:16:54.553: I/IN_BUF_AFTER(11279): -58 
09-05 13:16:54.558: I/IN_BUF_AFTER(11279): 0 
09-05 13:16:54.558: I/IN_BUF_AFTER(11279): 0 
...truncated to save space ... 
09-05 13:16:54.618: I/IN_BUF_AFTER(11279): 0 
09-05 13:16:54.618: I/IN_BUF_AFTER(11279): 0 
09-05 13:16:54.618: I/IN_BUFFER(11279): We now send to handler.
09-05 13:16:54.618: I/IN_BUFFER(11279): Read Stream into Buffer:
09-05 13:16:54.618: V/BluetoothSocket.cpp(11279): readNative
09-05 13:16:54.623: I/IN_BUFFER(11279): The entire buffer after read stream into buffer: 17 
09-05 13:16:54.623: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:54.623: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:54.623: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:54.623: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:54.628: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:54.628: I/IN_BUF_AFTER(11279): 44 
09-05 13:16:54.628: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:54.628: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:54.633: I/IN_BUF_AFTER(11279): 49 
09-05 13:16:54.633: I/IN_BUF_AFTER(11279): 50 
09-05 13:16:54.638: I/IN_BUF_AFTER(11279): 48 
09-05 13:16:54.638: I/IN_BUF_AFTER(11279): 44 
09-05 13:16:54.638: I/IN_BUF_AFTER(11279): 85 
09-05 13:16:54.638: I/IN_BUF_AFTER(11279): 13 
09-05 13:16:54.638: I/IN_BUF_AFTER(11279): -57 
09-05 13:16:54.648: I/IN_BUF_AFTER(11279): 3 
09-05 13:16:54.648: I/IN_BUF_AFTER(11279): 6 
09-05 13:16:54.648: I/IN_BUF_AFTER(11279): 0 
09-05 13:16:54.648: I/IN_BUF_AFTER(11279): 0 
...truncated to save space ... 
09-05 13:16:54.653: I/IN_BUF_AFTER(11279): 0 
09-05 13:16:54.653: I/IN_BUF_AFTER(11279): 0 
09-05 13:16:54.653: I/IN_BUFFER(11279): We now send to handler.
09-05 13:16:54.653: I/IN_BUFFER(11279): Read Stream into Buffer:
09-05 13:16:54.653: V/BluetoothSocket.cpp(11279): readNative
09-05 13:16:54.658: I/MESSAGE_READ(11279): I am reading 2 bytes
09-05 13:16:54.658: I/Content(11279): The entire array:
09-05 13:16:54.658: I/some hardcoded tag(11279): 0 
09-05 13:16:54.663: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/MESSAGE_READ(11279): I am reading 17 bytes
09-05 13:16:54.723: I/Content(11279): The entire array:
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.723: I/some hardcoded tag(11279): 0 
09-05 13:16:54.728: I/some hardcoded tag(11279): 0 
09-05 13:16:54.728: I/some hardcoded tag(11279): 0 
09-05 13:16:54.728: I/some hardcoded tag(11279): 0

Mein neuer code setzt auch den Puffer auf 0 vor dem Lesen in die neueste stream, also die message-handler sehen nur 0, bevor ich dies Tat der log erschien Sie wie folgt vor:

09-05 13:06:20.508: V/BluetoothSocket.cpp(10176): writeNative
09-05 13:06:20.533: I/IN_BUFFER(10176): The entire buffer after read stream into buffer: 2 
09-05 13:06:20.533: I/IN_BUF_AFTER(10176): 2 
09-05 13:06:20.533: I/IN_BUF_AFTER(10176): -58 
09-05 13:06:20.533: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.533: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.538: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.538: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.548: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.548: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.548: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.553: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.553: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.568: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.573: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.573: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.573: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.573: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.573: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.578: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.578: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.578: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.578: I/IN_BUFFER(10176): We now send to handler.
09-05 13:06:20.578: I/IN_BUFFER(10176): Read Stream into Buffer:
09-05 13:06:20.578: V/BluetoothSocket.cpp(10176): readNative
09-05 13:06:20.578: I/IN_BUFFER(10176): The entire buffer after read stream into buffer: 17 
09-05 13:06:20.578: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:20.578: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:20.583: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:20.583: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:20.583: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:20.593: I/IN_BUF_AFTER(10176): 44 
09-05 13:06:20.593: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:20.593: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:20.593: I/IN_BUF_AFTER(10176): 49 
09-05 13:06:20.593: I/IN_BUF_AFTER(10176): 51 
09-05 13:06:20.593: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:20.593: I/IN_BUF_AFTER(10176): 44 
09-05 13:06:20.593: I/IN_BUF_AFTER(10176): 85 
09-05 13:06:20.593: I/IN_BUF_AFTER(10176): 13 
09-05 13:06:20.598: I/IN_BUF_AFTER(10176): -57 
09-05 13:06:20.598: I/IN_BUF_AFTER(10176): 3 
09-05 13:06:20.613: I/IN_BUF_AFTER(10176): 6 
09-05 13:06:20.613: I/IN_BUF_AFTER(10176): 0 
...truncated to save space ... 
09-05 13:06:20.623: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:20.623: I/IN_BUFFER(10176): We now send to handler.
09-05 13:06:20.623: I/IN_BUFFER(10176): Read Stream into Buffer:
09-05 13:06:20.623: V/BluetoothSocket.cpp(10176): readNative
09-05 13:06:20.628: I/MESSAGE_READ(10176): I am reading 2 bytes
09-05 13:06:20.628: I/Content(10176): The entire array:
09-05 13:06:20.628: I/some hardcoded tag(10176): 48 
09-05 13:06:20.628: I/some hardcoded tag(10176): 48 
09-05 13:06:20.688: I/MESSAGE_READ(10176): I am reading 17 bytes
09-05 13:06:20.688: I/Content(10176): The entire array:
09-05 13:06:20.688: I/some hardcoded tag(10176): 48 
09-05 13:06:20.688: I/some hardcoded tag(10176): 48 
09-05 13:06:20.688: I/some hardcoded tag(10176): 48 
09-05 13:06:20.688: I/some hardcoded tag(10176): 48 
09-05 13:06:20.688: I/some hardcoded tag(10176): 48 
09-05 13:06:20.688: I/some hardcoded tag(10176): 44 
09-05 13:06:20.688: I/some hardcoded tag(10176): 48 
09-05 13:06:20.693: I/some hardcoded tag(10176): 48 
09-05 13:06:20.693: I/some hardcoded tag(10176): 49 
09-05 13:06:20.693: I/some hardcoded tag(10176): 51 
09-05 13:06:20.693: I/some hardcoded tag(10176): 48 
09-05 13:06:20.693: I/some hardcoded tag(10176): 44 
09-05 13:06:20.693: I/some hardcoded tag(10176): 85 
09-05 13:06:20.693: I/some hardcoded tag(10176): 13 
09-05 13:06:20.693: I/some hardcoded tag(10176): -57 
09-05 13:06:20.693: I/some hardcoded tag(10176): 3 
09-05 13:06:20.693: I/some hardcoded tag(10176): 6 
09-05 13:06:21.788: V/BluetoothSocket.cpp(10176): writeNative
09-05 13:06:21.803: I/IN_BUFFER(10176): The entire buffer after read stream into buffer: 2 
09-05 13:06:21.803: I/IN_BUF_AFTER(10176): 2 
09-05 13:06:21.803: I/IN_BUF_AFTER(10176): -58 
09-05 13:06:21.803: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.803: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.808: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.808: I/IN_BUF_AFTER(10176): 44 
09-05 13:06:21.818: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.818: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.818: I/IN_BUF_AFTER(10176): 49 
09-05 13:06:21.823: I/IN_BUF_AFTER(10176): 51 
09-05 13:06:21.823: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.828: I/IN_BUF_AFTER(10176): 44 
09-05 13:06:21.828: I/IN_BUF_AFTER(10176): 85 
09-05 13:06:21.833: I/IN_BUF_AFTER(10176): 13 
09-05 13:06:21.848: I/IN_BUF_AFTER(10176): -57 
09-05 13:06:21.848: I/IN_BUF_AFTER(10176): 3 
09-05 13:06:21.848: I/IN_BUF_AFTER(10176): 6 
09-05 13:06:21.853: I/IN_BUF_AFTER(10176): 0 
...truncated to save space ... 
09-05 13:06:21.853: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:21.853: I/IN_BUFFER(10176): We now send to handler.
09-05 13:06:21.858: I/IN_BUFFER(10176): Read Stream into Buffer:
09-05 13:06:21.858: V/BluetoothSocket.cpp(10176): readNative
09-05 13:06:21.858: I/IN_BUFFER(10176): The entire buffer after read stream into buffer: 17 
09-05 13:06:21.858: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.863: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.863: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.863: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.863: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.863: I/IN_BUF_AFTER(10176): 44 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): 49 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): 51 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): 48 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): 44 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): 85 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): 13 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): -57 
09-05 13:06:21.868: I/IN_BUF_AFTER(10176): 3 
09-05 13:06:21.873: I/IN_BUF_AFTER(10176): 6 
09-05 13:06:21.873: I/IN_BUF_AFTER(10176): 0 
...truncated to save space ...
09-05 13:06:21.893: I/IN_BUF_AFTER(10176): 0 
09-05 13:06:21.893: I/IN_BUFFER(10176): We now send to handler.
09-05 13:06:21.893: I/IN_BUFFER(10176): Read Stream into Buffer:
09-05 13:06:21.898: V/BluetoothSocket.cpp(10176): readNative
09-05 13:06:21.903: I/MESSAGE_READ(10176): I am reading 2 bytes
09-05 13:06:21.903: I/Content(10176): The entire array:
09-05 13:06:21.903: I/some hardcoded tag(10176): 48 
09-05 13:06:21.903: I/some hardcoded tag(10176): 48 
09-05 13:06:21.958: I/MESSAGE_READ(10176): I am reading 17 bytes
09-05 13:06:21.958: I/Content(10176): The entire array:
09-05 13:06:21.958: I/some hardcoded tag(10176): 48 
09-05 13:06:21.958: I/some hardcoded tag(10176): 48 
09-05 13:06:21.958: I/some hardcoded tag(10176): 48 
09-05 13:06:21.958: I/some hardcoded tag(10176): 48 
09-05 13:06:21.958: I/some hardcoded tag(10176): 48 
09-05 13:06:21.958: I/some hardcoded tag(10176): 44 
09-05 13:06:21.958: I/some hardcoded tag(10176): 48 
09-05 13:06:21.958: I/some hardcoded tag(10176): 48 
09-05 13:06:21.958: I/some hardcoded tag(10176): 49 
09-05 13:06:21.958: I/some hardcoded tag(10176): 51 
09-05 13:06:21.958: I/some hardcoded tag(10176): 48 
09-05 13:06:21.958: I/some hardcoded tag(10176): 44 
09-05 13:06:21.958: I/some hardcoded tag(10176): 85 
09-05 13:06:21.958: I/some hardcoded tag(10176): 13 
09-05 13:06:21.958: I/some hardcoded tag(10176): -57 
09-05 13:06:21.963: I/some hardcoded tag(10176): 3 
09-05 13:06:21.963: I/some hardcoded tag(10176): 6

Ich hoffe das ist nicht zu verwechseln die Frage, aber eigentlich zeigt ein problem, das so viele Menschen scheinen mit den BluetoothChat Demo-code, als passte für den eigenen Gebrauch.
Irgendwie müssen wir halten, der Puffer überschrieben wird, bis die message-handler hat es gelesen??
Hinsichtlich

Adrian Wreyford

Aktualisierten code besser arbeiten, weil der Schlaf!

public void run() {
            Log.i(TAG, "BEGIN  IN mConnectedThread");
            byte[] buffer = new byte[1024];
            int bytes;

            //Keep listening to the InputStream while connected
            while (true) {
                try {
                      try {
                        sleep(100);
                    } catch (InterruptedException e) {
                        //TODO Auto-generated catch block
                        e.printStackTrace();
                    }
                    bytes = mmInStream.available();
                    Log.i("IN_BUFFER", "mmInStream-available bytes: " + Integer.toString(bytes)+ " ");
                    if (bytes>0){ 
                    for(int i=0; i<30; i++){ 
                       buffer[i] = 0;}
                    //Read from the InputStream
                    Log.i("IN_BUFFER", "Read Stream into Buffer:");
                    bytes = mmInStream.read(buffer);

                    Log.i("IN_BUFFER", "The entire buffer after read stream into buffer: " + Integer.toString(bytes)+ " "); 
                    for(int i=0; i<30; i++) 
                         Log.i("IN_BUF_AFTER", buffer[i] + " ");
                    //Send the obtained bytes to the UI Activity
                    Log.i("IN_BUFFER", "We now send to handler.");
                    mHandler.obtainMessage(BluetoothScale.MESSAGE_READ, bytes, -1, buffer)
                            .sendToTarget();}
                } catch (IOException e) {
                    Log.e(TAG, "disconnected", e);
                    connectionLost();
                    //Start the service over to restart listening mode
                    BluetoothScaleService.this.start();
                    break;
                }
            }
        }

Nun die Protokolle wie folgt Aussehen:

09-05 20:57:15.833: V/BluetoothSocket.cpp(25368): availableNative
09-05 20:57:15.838: I/IN_BUFFER(25368): mmInStream-available bytes: 0 
09-05 20:57:15.888: V/BluetoothSocket.cpp(25368): availableNative
09-05 20:57:15.888: I/IN_BUFFER(25368): mmInStream-available bytes: 0 
09-05 20:57:15.943: V/BluetoothSocket.cpp(25368): availableNative
09-05 20:57:15.943: I/IN_BUFFER(25368): mmInStream-available bytes: 0 
09-05 20:57:15.958: V/BluetoothSocket.cpp(25368): writeNative
09-05 20:57:15.988: V/BluetoothSocket.cpp(25368): availableNative
09-05 20:57:15.993: I/IN_BUFFER(25368): mmInStream-available bytes: 2 
09-05 20:57:15.993: I/IN_BUFFER(25368): Read Stream into Buffer:
09-05 20:57:15.993: V/BluetoothSocket.cpp(25368): readNative
09-05 20:57:15.998: I/IN_BUFFER(25368): The entire buffer after read stream into buffer: 19 
09-05 20:57:15.998: I/IN_BUF_AFTER(25368): 2 
09-05 20:57:15.998: I/IN_BUF_AFTER(25368): -58 
09-05 20:57:16.003: I/IN_BUF_AFTER(25368): 48 
...truncated to save space ... 
09-05 20:57:16.033: I/IN_BUF_AFTER(25368): 85 
09-05 20:57:16.033: I/IN_BUF_AFTER(25368): 13 
09-05 20:57:16.033: I/IN_BUF_AFTER(25368): -57 
09-05 20:57:16.033: I/IN_BUF_AFTER(25368): 3 
09-05 20:57:16.038: I/IN_BUF_AFTER(25368): 6 
09-05 20:57:16.038: I/IN_BUF_AFTER(25368): 0 
...truncated to save space ... 
09-05 20:57:16.043: I/IN_BUF_AFTER(25368): 0 
09-05 20:57:16.043: I/IN_BUFFER(25368): We now send to handler.
09-05 20:57:16.058: I/MESSAGE_READ(25368): I am reading 19 bytes
09-05 20:57:16.058: I/Content(25368): The entire array:
09-05 20:57:16.058: I/some hardcoded tag(25368): 2 
09-05 20:57:16.058: I/some hardcoded tag(25368): -58 
09-05 20:57:16.058: I/some hardcoded tag(25368): 48 
...truncated to save space ...
09-05 20:57:16.063: I/some hardcoded tag(25368): 13 
09-05 20:57:16.063: I/some hardcoded tag(25368): -57 
09-05 20:57:16.063: I/some hardcoded tag(25368): 3 
09-05 20:57:16.063: I/some hardcoded tag(25368): 6 
09-05 20:57:16.093: V/BluetoothSocket.cpp(25368): availableNative
09-05 20:57:16.093: I/IN_BUFFER(25368): mmInStream-available bytes: 0

Beachten Sie, dass die mmInStream.available() gibt 2 zurück, bytes, dann auf die nächste Zeile des Codes beim Lesen der Puffer 19 bytes gelesen .. wirklich seltsam, wie es füllt sich zwischen diesen zwei vermeintlich unmittelbaren Schritte. Der Schlaf scheint damit ausreichend Zeit für die handler, um die Nachricht zu Lesen von übergebenen Puffer, bevor der Puffer wird umgeschrieben.

Hätte ich erwartet, dass der handler.obtainmessage... senden eine einzigartige Puffer, scheint aber senden Sie die Referenz auf das thread-buffer, damit die Mühe.
Wie kann ich senden eine einzigartige Puffer-jeder Zeit?
Thx
Adrian

InformationsquelleAutor Adrian Wreyford | 2012-09-02

9

Ich habe Menschen gesehen, die in dieser Art von problem, vor, wenn mit dem Bluetooth-Chat-Beispiel. Das problem mit dem Beispiel-code ist, dass die Meldung Objekt gesendet wird, um die Handler einfach enthält einen Verweis auf die eigentliche byte[] - array, das verwendet wird, für jede weitere read() Betrieb. Dies bedeutet, dass, sobald die Handler erhält die Nachricht und beginnt mit der Inspektion der array, der spätere read() Betrieb der Bluetooth-sockel sind bereits die Gelegenheit gehabt zum schreiben neuer Daten auf das array.

In dieser Codezeile:
```
mHandler.obtainMessage(BluetoothChat.MESSAGE_READ, bytes, -1, buffer)
                        .sendToTarget()
```
Array nicht kopiert werden; sondern die Botschaft ist einfach die Vermittlung eines Objekts Referenz auf das selbe array.

Der einzige Grund, warum die Bluetooth-Chat-Beispiel funktioniert für seinen ursprünglichen Zweck ist, weil sein Zweck ist, zu vermitteln, kurzen Trauben von Zeichen, die auf menschliche Eingabe der Geschwindigkeit. Wenn Sie uns etwas schneller als das, was die Handler liest aus diesem array dreht sich um Müll.

Ist die Antwort auf die übersendung einer Kopie des Arrays (z.B. System.arraycopy()) oder verwenden Sie einen einfachen Ringpuffer, das ist, was meine eigenen Bluetooth-Anwendung verwendet.

Die Tatsache, dass die ersten beiden bytes entstellt ist wirklich seltsam, aber vielleicht liegt es nur an der konkreten Umsetzung der zugrunde liegenden lese-Betrieb im Bluetooth-stack auf eurem Gerät ein. Die einfache Tatsache ist, dass, sobald Sie aufgerufen haben read() mit, dass die Puffer, Sie sollten sich nicht berühren, die Puffer in der Zwischenzeit oder zu interessieren, was in ihm ist. Vielleicht die bestimmten Bluetooth-socket-read-Implementierung auf dem Gerät hat etwas mit den ersten paar bytes in den Puffer, weil etwas zu tun mit seinen internen Betrieb. Aber Sie sollten sich nicht sorgen, welche Art von komischen Zwischenzustand, der Puffer ist, während read() ist blockiert, weil kein anderer thread sollten versuchen, einen Sinn zu diesem Zeitpunkt. Alles, was Sie über Pflege ist, dass der Puffer in einem gültigen Zustand mit gültigen Daten, wenn read() gibt.

Der Grund, warum mit der sleep() Betrieb offenbar teilweise "heilt" das problem ist, denn es ist eine rohe Möglichkeit geben, Ihre Handler Zeit zu schauen an der Reihe, bevor die nachfolgenden read() Betrieb bekommt seine Hände auf das array. Dies ist nicht eine gute Lösung wenn.

Das zweite Problem, das Sie haben, ist aufgrund der Tatsache, dass in Java byte unterzeichnet ist. Das ist, warum der debugger zeigt dir die bytes als vorzeichenbehaftete Werte. In Ihrer Anwendung, wenn Sie arbeiten müssen, ein bestimmtes byte als int und das byte ist ursprünglich nicht, Sie tun so etwas wie:
```
int someValue = myByteArray[someIndex] & 0xff;
```
- Thx Trevor, ich habe in der meentime dachte, mit der Kopie des Arrays. Was ist ein Ringpuffer?
- Sie würde am besten Googeln, wie es ist eine sehr häufige Puffer-Struktur. Für jetzt, sind Sie wahrscheinlich gut die Durchführung einer array-Kopie. Habe ich nur verwendet einen kreisförmigen Puffer, in meiner Bewerbung, denn ich bin den Umgang mit großen Mengen von streaming-Daten. In Ihrer situation, ich glaube, du bist den Umgang mit kleinen Mengen von Daten, so dass ich glaube nicht, dass Sie für Sie von Vorteil, eine aufwendige Pufferung System.
- können Sie bitte zeigen Sie der run-Methode code wie Sie haben, zu senden Kopie des Arrays, oder verwenden Sie einen einfachen Ringpuffer
InformationsquelleAutor Trevor
1

Ich denke, das Problem, das Sie zu sehen sind, z.B. mit dem 198 drehen in -58 ist, denn Java verwendet unterzeichnet bytes, also etwas mehr als 127 ist eine negative Zahl. So 198 binäre als -(256 - 198) = -58.

Die Lösung ist für die Konvertierung in einen int-mithilfe von code wie dem folgenden:
```
private int UByte(byte b){
        if(b<0) //if negative
            return (int)( (b&0x7F) + 128 );
        else
            return (int)b;
    }
```
InformationsquelleAutor Oli Glaser
1

Wie gesagt die Daten nicht gewährleistet ist, bluetooth ist ein offener stream von Daten wie UDP.

Ich nehme an, ein gewisses Verständnis für rs232 wird benötigt, um zu wissen, Wann bytes zusammen gepackt, gesendet oder individuell.

mit einem mikrocontroller-Projekt etwas vorstellen wie:
```
if (data_ready) echo read_byte();
```
mit PIC microchips die resultierenden Daten etwas wie:
```
0 0 0 0 0 0 0 h 0 0 0 0 e 0 0 0 0 0 0 l 0 0 0 0 0 0 l 0 0 0 0 0 0 o ...
```
Mit der Android-mikrocontroller-Projekt arbeite ich im moment mache ich etwas, wie:
```
do {instream.read()} while (!DELIMETER)
```
Habe ich gefunden, dass Sie brauchen, um effizient mit Ihrem code beim Lesen einer bluetooth-Daten-stream. Mit inputstream-Methoden andere als die von read(), würde ich fast immer verpassen das erste byte.

Ich habe gerade angefangen, mit bluetooth smart, ich glaube, das ist ganz anders, da die Daten nur gesendet, wenn es verfügbar ist.

InformationsquelleAutor Christian Lacdael
0

Nicht sicher, warum dies geschieht, aber es kann einige seltsame Rasse Zustand.
Eines der Probleme mit Ihrem code, der es Lesen will die ganze Zeit Daten! Auch wenn keine Daten vorhanden sind.

Also vielleicht liest du die ersten 2 bytes, dann wird eine nachfolgende iteration Lesen Sie den Eingabe-Puffer wieder ohne die ersten 2 bytes (der debugger zeigt dir das falsche Bild in diesem Fall).

Was Sie können versuchen, zu verbessern, ist durch hinzufügen der folgenden Zeilen(versuchen Sie nicht kopieren und einfügen, ich bin eine Anpassung der code zu deinem vorherigen - es kann funktionieren-oder auch nicht):
```
bytes = mmInStream.getAvailable();
if (bytes>0) {
    Log.i("some hardcoded tag", "I am reading " + Integer.toString(bytes) + " bytes");
    //you could also print the entire bytearray
    /*
    Log.i("some hardcoded tag", "The entire array:");
    for(int i=0; i<bytes; i++)
         Log.i("some hardcoded tag", buffer[i] + " ");*/
    mmInStream.read(buffer);

    //and your code ..
    //Send the obtained bytes to the UI Activity
    mHandler.obtainMessage(BluetoothChat.MESSAGE_READ, bytes, -1, buffer)
                        .sendToTarget();

}
```
Bemerken, dass ich Log.ich anstelle des Debuggers. Es ist besser für Multithread-Zeug, wenn Sie implementieren die Protokolle, und Sie nicht die Mühe, Sie - und es ist schneller umzusetzen und einfacher zu Debuggen.
- Thx Radu, ich nahm Ihren Rat an und richten Sie ein paar melden.ich, und es scheint, ich bin näher an der Suche nach der wirklichen Ursache des Problems. Bitte se meine ursprüngliche Frage .. ich bin das hinzufügen der Protokolle, um zu versuchen und zeigen, was Los ist.
- Hi Adrian, ich lese deine logs - auch wenn Sie nicht aktualisieren Sie Ihre code-Beispiel zu in-sync mit den logs... müssen Sie re-Lesen Sie meine Antwort: vielleicht liest du die ersten 2 bytes, dann wird eine nachfolgende iteration Lesen Sie den Eingabe-Puffer wieder ohne die ersten 2 bytes (der debugger zeigt dir das falsche Bild in diesem Fall). Warum machst du das? Es ist, weil Ihr 'Lesen' - Schleife wird ausgeführt, viel zu viele Male zu schnell!
- Betrachten Sie den code, den ich gepostet und vor allem die ersten 2 Zeilen! Nur Lesen, wenn es etwas zu Lesen! bytes = mmInStream.getAvailable(); if (Byte>0)
- Wenn die oben genannten fix immer noch nicht funktioniert - kopieren Sie die Zwischenablage in ein neues Objekt - senden Sie das neue Objekt jedes mal zum Ziel. Mach dir keine sorgen über spamming zu viele neue Objekte - Sie haben die garbage-collection! Kompilieren Sie Ihr array gibt!
- Ich habe jetzt implementiert ist Ihr Vorschlag - nur bei bytes>0 mmInStream.Verfügbar(); mit einigen Verbesserungen, aber immer noch das überschreiben des Puffers vor-message-handler immer auf den Puffer. Ich lege dann Schlaf in meinen code, und plötzlich lief es besser, aber immer noch nicht fehlerfrei. Aktualisiert code, der oben in der wichtigsten Frage.
- Es ist nichts falsch mit ständig ruft read(). Es ist eine blockierende socket-Aufruf zurückgeben wird, wenn es Daten. Bis der Aufruf zurückgegeben (verstopfte), das Gewinde ist im wesentlichen das warten auf ein semaphor; es ist nicht "busy-waiting". Außerdem werden die API-Dokumentation gibt Vorsicht zu nutzen .available().
- Sie sind wahrscheinlich Recht, Trevor. Bei mir hat es geklappt, also wollte ich Adrian zu bewegen, zu meinem code :). So wurde das problem in der Tatsache, dass er überlieferte eine Referenz auf den Puffer, die geändert werden kann.
InformationsquelleAutor Radu
0

War ich in der gleichen Lage wie Sie vor ein paar Wochen.

Entdeckte ich Das Lesen, zählen, ist zufällig bei der Verwendung von read(buffer). So werden Sie nie wirklich Vorhersagen
wie groß das nächste Daten-Paket.

Die einfache Lösung war für mich zu Lesen, dass ein einzelnes byte für byte mit read() und fügen Sie es zu einem lokalen Puffer, bis alle byte empfangen wird.

Hoffe, das hilft.

InformationsquelleAutor user2046976

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.