If a FILT has ctype 0 its value is determined by its temperature, so you're basically reading the temperature of the FILT the LDTC is pointing at.

This means you always have to set at least one bit of a FILT ctype and ignore that bit in your results (the bit functions as a carrier for the value). By convention the most significant 30th bit is used with value 536870912 (hexadecimal 0x20000000).

FILT's value with ctype=0 is 0x1f (31 in decimal) at 0-39C and left-shifted (multiplied by 2) every +40C, until 1000C. For compatibility with FILT serialisation setting 29th bit to 1 (0x10000000) instead of 30th (0x20000000) might be better

@12034056 (View Post)

 Technically serialization format doesn't *set* the 29th bit but *inverts* it (meaning negative values don't have the 29th bit set). That's why I advise people to use the simpler 30th bit set format and convert to serialization format (by XORing with value 0x30000000) when needed.

@Jerehmia (View Post)

 In the source code, it actually adds 0x10000000 to the serialization value, for example, from LSNS.cpp: 

152    parts[ID(r)].ctype = 0x10000000 + life;

 and for deserialisation:

164    parts[ID(r)].life = life - 0x10000000;

 Actual negative values are a bit more complicated, since they can be deserialised but cannot be serialised, since the serialisation value is always checked to be greater or equal to 0 before being written to FILT. LSNS.cpp:

105    if (TYP(r) != PT_LSNS && TYP(r) != PT_FILT && parts[ID(r)].life >= 0)

 FILT always stores and works with 32-bit signed integer values, but only shows the first 30 bits of it, that's why serialisation still works with values above 536870912, and why negative values can be partially serialised.