Android串口通信中Block Check Character(BCC)校验结果不符问题

Let's work through your problem step by step: you're receiving a serial frame 01H 50H 30H 02H 28H 34H 45H 38H 39H 42H 42H 41H 43H 29H 03H 48H, where 48H is the Block Check Character (BCC). According to your docs, BCC should be the checksum of bytes from the second to the second-last (your array {0x50,0x30,0x02,0x28,0x34,0x45,0x38,0x39,0x42,0x42,0x41,0x43,0x29,0x03}), but your calculation gives 38H instead of the device's 48H.

1. Fix Manual Calculation Errors First #

Manual hex arithmetic is prone to mistakes—let's use code to get an accurate baseline. Here's a Java snippet to calculate the standard arithmetic checksum (sum all bytes, take the lower 8 bits):

byte[] inputByteArray = {0x50,0x30,0x02,0x28,0x34,0x45,0x38,0x39,0x42,0x42,0x41,0x43,0x29,0x03};
int sum = 0;
for (byte b : inputByteArray) {
    sum += b & 0xFF; // Handle signed byte values correctly
}
int bcc = sum & 0xFF;
System.out.println(String.format("0x%02X", bcc)); // Outputs 0xC8

This result (0xC8) doesn't match either your 38H or the device's 48H, which means your manual calculation had an error. The 38H you got is likely the two's complement of 0xC8 (0xFF - 0xC8 + 1 = 0x38), but that still doesn't align with the device's output.

2. Recheck the BCC Definition in Your Documentation #

The term "checksum" is ambiguous—here are common alternatives to rule out:

• XOR Checksum: Calculate bitwise XOR of all bytes instead of summing. For your array, the XOR result is 0x12, which doesn't match 48H.
• CRC8 Checksum: Many serial devices use CRC8 instead of a simple sum. Polynomials vary (common ones are 0x07, 0x31, 0x80), so check your docs for specifics. Example code for CRC8 with polynomial 0x31:

  public static byte crc8(byte[] data) {
      int crc = 0x00;
      for (byte b : data) {
          crc ^= b & 0xFF;
          for (int i = 0; i < 8; i++) {
              crc = (crc << 1) ^ ((crc & 0x80) != 0 ? 0x31 : 0x00);
          }
          crc &= 0xFF;
      }
      return (byte) crc;
  }
  

  This gives 0x70 for your array—try other polynomials if your doc lists one.
• Byte Range Misinterpretation: Double-check if "second byte to second-last byte" includes the starting 01H or excludes the ending 03H:
  • Including 01H gives a sum of 0xC9, not 48H.
  • Excluding 03H gives 0xC5, still not a match.

3. Validate the Received Frame #

It's possible your serial reception has issues:

• Check for framing errors (missed/extra bytes inserted by the serial driver).
• Ensure you're handling signed bytes correctly—always use b & 0xFF when doing arithmetic to avoid negative value bugs.
• Use a serial monitor tool to capture raw data and confirm the frame matches what you're processing in code.

4. Look for Custom Checksum Logic #

Some devices use non-standard rules, like:

• Summing only ASCII values of alphanumeric bytes (unlikely here since your frame includes control bytes like 02H, 03H).
• Splitting bytes into nibbles, summing nibbles separately, then combining results.
• Taking the sum modulo a value other than 256.

内容的提问来源于stack exchange，提问作者Akshay Anpat