Hi Andrzej >> >> Mantissa values must not always be 2^23-1 on special cases. >> Information provided here is required for upper profiles which are >> implementing an 11073-20601 protocol layer because they have to >> differentiate among these values. In my opinion, documentation about >> passible values for the mantissa should remain as they are. > > > HTS specification states (see quote below) that measurement value field may > be NaN in case sensor is not able to provide valid measurement. So I assume > here that either it has valid data or NaN otherwise and thus there's no need > to specify other special values as they should not be received here. > > <quote> > The Temperature Measurement Value field may contain special float value NaN > (0x007FFFFF) defined in IEEE 11073-20601 [4] to report an invalid result > from a computation step or missing data due to the hardware’s inability to > provide a valid measurement. > </quote> > IMHO that doesn't justify you to force all mantisse values to be 2^23-1, first of all because the value type for this characteristic is a FLOAT type, so any value that a thermometer could send, it does it using the format defined for FLOAT types which is explained in IEEE-11073-20601, [http://developer.bluetooth.org/gatt/Pages/FormatTypes.aspx] On the other hand, I understand from this quote that thermometers MAY set NaN in case sensor is not able to provide valid measuremen due to an invalid result or missing data, but it doesn't say anything about other values that a FLOAT types can take, so you are forcing to be NaN other special cases that are defined for this kind of type. If you had a look to that spec you could see wich other special values a FLOAT type could take, if not, you could at least have a look to one of the whitepapers defined in bluetooth sig for transcoders. Regards -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
