Dear Engineering Team,
I am writing to provide technical feedback regarding the encoding format used for FSC-BP121C sensor data frame in version 2 of your BLE advertising protocol.
After analyzing the current implementation, I believe the transition from a straightforward binary representation in version 1 to the current BCD-based encoding in version 2 introduces unnecessary complexity without delivering measurable benefits.
In your version 1 approach, temperature could be represented cleanly using two bytes: - One signed byte for the integer portion - One byte for the fractional portion (in hundredths) This approach provides a compact, efficient, and unambiguous representation: - Full utilization of byte range (±128 for integer portion) - Simple encoding and decoding logic - No need for digit validation or special-case handling.
By contrast, the current version 2 BCD-based approach: - Does not reduce storage requirements (still requires two bytes) - Does not increase precision or range - Introduces additional validation requirements (nibble-level BCD checks) - Requires more complex decoding logic - Relies on less robust handling of sign and magnitude. Additionally, combining sign representation with BCD digit encoding in a single byte reduces clarity and introduces
avoidable edge cases. This design choice complicates implementation without offering offsetting
advantages in efficiency or interoperability.
From an engineering perspective, the binary representation of version 1 is both simpler and more robust, and it avoids the need for redundant checks and implementation-specific behavior.
I respectfully suggest you reconsider the use of BCD for this purpose and return to a binary format for sensor values. This would improve reliability, simplify integration, and reduce the likelihood of decoding errors across platforms. Thank you for your time and consideration.
