Problems with Bluetooth Communication

[Edited]
I used Robin2’s “Serial Input Basics”-tutorial (http://forum.arduino.cc/index.php?topic=396450) for communication between two Teensy 3.2 boards via bluetooth (HC-05-modules). Receiving and splitting data works just fine, but every time I try to receive AND send data alternately, I mostly receive the right characters with a lot of garbage between them. So the splitting method can’t work properly. Is there a way to send and receive alternately, so the sending- and receiving-method don’t interfere with each other?

Here’s an example of my code. One teensy (slave) uses an accelerometer and gyro-board to measure his roll and pitch (floats) and sends it to the other one via bluetooth. This one (master) compares the values with his own roll and pitch and sends an “OK” (boolean state) to the other one:

void loop() {
sendVal();
receiveData();
}
//=============================
void sendVal () {
String sendVal;
sendVal = "<";
sendVal = sendVal + state;
sendVal = sendVal + ">";
char sendChar[row];
sendVal.toCharArray(sendChar, row);
Serial1.println(sendChar);
}
//=============================
void receiveData() {
static boolean rxInProgress = false;
static byte idx = 0;
char startChar = '<';
char endChar = '>';
char rx;

if (Serial1.available() > 0) {
while (Serial1.available() > 0 && newData == false) {
 rx = Serial1.read();

 if (rxInProgress == true) {
   if (rx != endChar) {
     rxChars[idx] = rx;
     idx++;

   }
   else {
     rxChars[idx] = '\0';
     rxInProgress = false;
     idx = 0;
     newData = true;
   }
   splitData();
 }

 else if (rx == startChar) {
   rxInProgress = true;
 }
}
}
}
//=============================
void splitData() {
char * strtokIdx;
if (newData == true) {
strtokIdx = strtok(rxChars, ",");
slaveRoll = atof(strtokIdx);
strtokIdx = strtok(NULL, ",");
slavePitch = atof(strtokIdx);
}
newData = false;
}

The baud rate for both hc05 modules is 9600 with odd parity, but it works also at higher speeds, e.g. 38400. The problem stays the same at any baud rate. I know this is a Arduino forum, but the teensy uses the same code and I had the same problems when I used this code on my Arduino 101. I also used the SoftwareSerial library, but that’s much worse than the hardware serial.

Hope someone can help me with this.

Leo

I suspect the problem is that you are not making a copy of the data before you start parsing. The strtok() function modifies the array it is working on. Have you studied my parse example carefully?

I would also recommend that you use the functions of my program as much unchanged as possible and just add your own functions into that. It avoids missing important pieces; it also makes it easier to help you; and it will make it easier to use the techniques in another program in future. If this was my project I would just extend loop() like this

// Example 5 - Receive with start- and end-markers combined with parsing


void loop() {
    recvWithStartEndMarkers();
    if (newData == true) {
        strcpy(tempChars, receivedChars);
            // this temporary copy is necessary to protect the original data
            //   because strtok() used in parseData() replaces the commas with \0
        parseData();
        showParsedData();
        sendVal();
        newData = false;
    }
}

You have not posted a complete program. For the future please do so and and use the code button </> so your code looks like this and is easy to copy to a text editor. See How to use the Forum

…R

Hi Robin,

thanks for your advice. Obviously I didn’t read your tutorial as properly as I thought. I corrected the code and ran it again, but the problems persisted. I received a lot of wrong characters on the master side and after a while the program stopped.

I now know the reason for this: the input and output buffers filled up, while the teensy was computing other stuff (e.g. the roll and pitch of the IMU-sensor). After I used Serial.clear() in recvWithStartEndMarkers() and Serial.flush() in sendVal() everything worked perfectly.

Leo

leo900:
I now know the reason for this: the input and output buffers filled up, while the teensy was computing other stuff

That suggests that the code for the other stuff could do with improvement so it does not hog all the processor time.

...R