FSP-BP121 Sensor Data Data Frame

ccervo1

I have a HCI BLE based app that reads advertising frames. I'm trying to read and parse the advertising frame for sensor data. The Feasy document "FeasyBeaconAdvertisingProtocol.pdf" chapter 5 page says the frame is:
0xFF 0xFF 0xF0 0x01 0x05 0x01 0x?? 0x?? 0x?? 0x??
where the first two ?? bytes are temperature and the next two bytes are humidity.
I have discovered that my devices are sending
0xFF 0xFF 0xF0 0x02...
Apparently Feasy has changed the Sensor Data Frame to version 2.
It appears the new format include module type "FSC-BP121C" and the temperature and humidity are BCD encoded.
Does anyone know where to get documentation on the new frame format?

FAE_Gavin

ccervo1 The sensor data frame has been updated to Version 0x02 (the byte you observed as 0x02 is the protocol version). The structure is as follows:

Frame format:
Len + Tag + Company + Ver + Temp + Humidity

Detailed breakdown:

Len (1 byte)

Tag (1 byte): 0xFF (vendor specified field)

Company (2 bytes): 0xFFF0

Ver (1 byte): 0x02 (protocol version)

Temp (2 bytes): first byte = integer part (signed), second byte = fractional part; unit: °C

Humidity (2 bytes): first byte = integer part, second byte = fractional part; unit: %

Example full frame:
0x08 0xFF 0xF0 0xFF 0x02 [Temp] [Humidity]

No official document is available yet, but the format above has been confirmed by our R&D team.

ccervo1

FAE_Gavin how is negative temp indicated? Is it high bit of integer portion set? Does ghis mean temperature has limit of 79.99 °C?

FAE_Gavin

ccervo1 Negative temperature is represented in two's complement format, as confirmed by our R&D team.

For example:

-10°C → integer part = 0xF6 (which is -10 in two's complement).

The integer part is a signed 8‑bit value (range –128 to +127). Together with the fractional part (0–99), the theoretical maximum temperature is 127.99°C, not limited to 79.99°C.

ccervo1

FAE_Gavin That doesn't match what I'm seeing. In version 1 the integer portion of temperature was a signed char. In version 2 it appears to be encoded as BCD (binary coded decimal). In that form 2's complement doesn't make sense.

FAE_Gavin

ccervo1
For Version 2 (Ver=0x02): positive temperature uses BCD encoding, negative temperature uses two's complement.

ccervo1

FAE_Gavin You've got to be kidding. That is rediculously complicated. Is it only the integer portion of temperature that this applies to or are both integer and fractional portions two's complement for negative temperarures?

FAE_Gavin

ccervo1 Final rule for V2

Integer ≥ 0: BCD (e.g., 25 → 0x25)
Integer < 0: two's complement of (BCD of absolute value) (e.g., –10 → 0xF0)
Fraction: always positive BCD, does not carry its own sign; the sign follows the integer part.

We admit this is an early design flaw. Improvements are planned in future firmware.

ccervo1

Version 1 was fine. What justified changing?

ccervo1

If I'm not mistaken this limits temperature readings to +-79.99. 7 is 0111 binary. 8 is 1000 bianry. 2's complement of 7 is 1001. 2's complement of 8 is 1000. In this scheme +- 8 are identical. It works because +-79°C is large enough for normal useage. The sensor would malfunction at 79°C.

FAE_Gavin

ccervo1 We have provided a decoding function to convert the broadcast temperature value into the actual temperature value. Please refer to the code example below:

int bcd_to_temp(int8_t integer_part_dcd, int8_t fractional_part_dcd, double* temp)
{
  if(integer_part_dcd>=0 && (((integer_part_dcd >> 4) & 0x0F) > 9 || (integer_part_dcd & 0x0F) > 9))
    return -1;
  else if(integer_part_dcd<0 && (((-integer_part_dcd >> 4) & 0x0F) > 9 || (-integer_part_dcd & 0x0F) > 9))
    return -1;

  if (((fractional_part_dcd >> 4) & 0x0F) > 9 || (fractional_part_dcd & 0x0F) > 9) 
    return -1;
  int frac_part = ((fractional_part_dcd >> 4) * 10) + (fractional_part_dcd & 0x0F);
  if(integer_part_dcd>=0)
  {
    int int_part = ((integer_part_dcd >> 4) * 10) + (integer_part_dcd & 0x0F);
    *temp = (double)(int_part * 100 + frac_part) / 100.0;
  }
  else
  {
    int int_part = -(((-integer_part_dcd >> 4) * 10) + (-integer_part_dcd & 0x0F));
    *temp = (double)(int_part * 100 - frac_part) / 100.0;
  }
  return 0;
}

ccervo1

FAE_Gavin thank you

ccervo1

I truely don't understand your code. Please show me how 80.00 degrees C and -80.00 degrees C are encoded.
.

FAE_Gavin

ccervo1 +80°C → 0x80 0x00
-80°C → absolute BCD = 0x80 → two's complement = 0x80 (same encoding)

This is a design flaw. We recommend avoiding this temperature value.

ccervo1

FAE_Gavin As I said my previous response your version 2 format for sensor data frame restricts temperature values to |temperature|<=79.99C. You should provide documentation.

FAE_Gavin

ccervo1 You are correct.
We have submitted an improvement plan to our R&D team, and future firmware will be optimized.

ccervo1

FAE_Gavin My suggestion is revert to version 1.