I am using a two Arduino setup with two XBee radios. One radio is sending data and the other is receiving data. I am sending three sensor readings following a protocol which uses three bytes for each sensor reading. Byte one is sensor information, byte two is data, and byte three is for error checking. When I run the set up for about 5 minutes I get approximately 47% errors in transmission. Once one error occurs, there seems to be an avalanche of errors. However, when I add delay in between sending bytes (100ms between bytes and 1s between sensor) it works perfectly. I've tried expanding the hardware buffer, but this didn't work.


        // Calcuate weather parameters for serial and web
        calcWeather(); // Go calc all the various sensors

        // send weather out to serial port
        if (prevtemplm34_1 == templm34_1) // 2 in a row must be the same to send
            Serial.write(templm34_1 ^ 0);

        // send weather out to serial port
        if(prevtemplm34_2 == templm34_2) // 2 in a row must be the same to send
            Serial.write(templm34_2 ^ 1);

        // send weather out to serial port
        if(prevtemplm34_3 == templm34_3) // 2 in a row must be the same to send
            Serial.write(templm34_3 ^ 2);

The code for parsing received data is:

int readData ()
// There must be at least three available bytes to satisfy the protocol
// Otherwise, wait until three bytes have arrived to read anything
if (Serial.available() >= 3) {

      // Read the next three byte in the serial buffer
      incomingByteOne = Serial.read();
      Serial.write("Byte One: ");
      incomingByteTwo = Serial.read();
      Serial.write("Byte Two: ");
      incomingByteThree = Serial.read();
      Serial.write("Byte Three: ");

      // XOR the first and second incoming bytes so that the result can be checked against the third error checking byte
      byte xorValue = incomingByteOne ^ incomingByteTwo;
      Serial.write("XOR VALUE: ");
      Serial.println("Number of Errors: ");
      if(xorValue != incomingByteThree) {
        numberOfErrors++; // Add one to the total count of number of errors in transmission
      else {
        // Mask for retrieving the five rightmost bits from incomingByteOne (00011111)
        byte maskForSensorNumber = 0x1f;

        // Shift incomingByteOne right 5 times in order to obtain the three bits representing the unit number
        int unitNumber = incomingByteOne >> 5;

        // AND incomingByteOne with the mask in order to retrieve only the five righmost bits representing the sensor number
        int sensorNumber = incomingByteOne & maskForSensorNumber;

        // Store the data for the correct sensor on the correct unit
        data[unitNumber][sensorNumber] = incomingByteTwo*1;

What could be causing the transmissions to work fine with delay, but not otherwise?

1 Answer 1


You are probably just transmitting too fast.

Your receiver is writing at least 80 bytes of debugging information (if I counted it right) for every 3 bytes of incoming data. Since both input and debug output happen at the same baud rate, this means the receiver can only cope with an input data rate equal to 3/80 = 3.75% of the nominal baud rate.

I would expect no errors at the very beginning of the program run, because the debugging info is written to a RAM buffer. Only when that buffer fills up the receiver is slowed down by every Serial.write() and Serial.println() it performs.

  • Thanks @EdgarBonet. When I expanded the receiving and transmitting buffers of the receiver unit to 1,024 bytes, I still had errors after just 7 or so transmissions (just under 600 bytes including debugging). Do you think adding delay is probably one of the better ways to fix this?
    – tpm900
    Oct 25, 2016 at 20:06
  • @tpm900: Yes, or maybe show less debugging info. Oct 25, 2016 at 20:13
  • I actually only added the debugging after I saw issues with the transmissions. However, I do have approximately 100 writes to a Client (e.g. client.println("..."). Does this also affect the buffer?
    – tpm900
    Oct 25, 2016 at 21:16
  • I do not know what your client looks like, but it is likely that the println() can block. Oct 26, 2016 at 8:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.