The example si70xx.c masks off the low order 2 bits of the humidity measurement and then computes RH using that value.

Why is this done? I don't see any discussion in the data sheet that supports this operation. In the data sheet where the RH_Code comes from is a bit fuzzy, is it supposed to be the whole 16 bit value or only the high order 14 bits?

Same question for the Temp_code in the data sheet. I seem to get reasonable values for temperature by using all 16 bits of temperature code as the input to the calculation.

Sensors

Discussion Forums

Answered

Humidity Sensors

Answered

Generally there is no need to mask off the LSBs - they do not contain data related to temperature or humidity and are just stuffed with specific numbers. That said, the LSB data is in the noise so you can either mask the bits or not it does not make any practical difference.

0

Thanks, and we should use all 16 bits without any shifting as the RH_Code or Temp_Code?

0

The formulas:

RH% = code*125/65536 - 6

and

Temp (C) = code*175.72/65536 - 46.85

assume a 16 bit number for code.

Masking the LSBs makes little difference as the 2nd LSB of the 16 bit number is 2*125/65536 %RH = 0.003%RH and 2*175.72/65536 C = 0.005 C. In principle, the LSBs do not contain information related to the RH or temperature itself but in practice there is no good reason to mask them off.

0

Thanks, perhaps the errata you are working on could clarify this. The confusion occurs because RH_code and Temp_Code are not defined. To mask off the bits and then perform the calculation 'properly' I suggest the following:

RH_Code = ((MS Byte) << 8 + LS Byte) >> 2

TH_Code = ((MS Byte) << 8 + LS Byte) >> 2

%RH = ((125 * RH_CODE)/16384) - 6

Temperature (C) = ((175.72 * Temp_Code)/16384) -46.85

The description above clarifies the underlying intent, but, changes the equations. Using RH_code = ((MS Byte) << 8 + LS Byte) & 0xfffc and leaving the calculation alone would also be fine.

The data sheet implies that one could look at the low order 2 bits of the Code and determine if the value observed was a temperature (0x0) or a humidity (0x2). Is this the intent of providing a value in those bits? If so this intent could also be put into the errata.

Correct Answer

0

Than you for your comments.

There is really no need to mask off the lower bits when making the calculations. The lower bits are simply not significant in terms of the conversion result. That said, it also does not hurt to mask off the bits. I apologize if the code example where they were masked caused any confusion.

It is correct that the data in the LSB bits represents the type of data, but generally the type of data is already known so most people do not bother looking at the bits as an error check. The optional checksum is a more powerful way of doing error checking if error checking is desired. The function of these bits is properly documented in the data sheet.

## Humidity conversion

The example si70xx.c masks off the low order 2 bits of the humidity measurement and then computes RH using that value.

Why is this done? I don't see any discussion in the data sheet that supports this operation. In the data sheet where the RH_Code comes from is a bit fuzzy, is it supposed to be the whole 16 bit value or only the high order 14 bits?

Same question for the Temp_code in the data sheet. I seem to get reasonable values for temperature by using all 16 bits of temperature code as the input to the calculation.

Generally there is no need to mask off the LSBs - they do not contain data related to temperature or humidity and are just stuffed with specific numbers. That said, the LSB data is in the noise so you can either mask the bits or not it does not make any practical difference.

Thanks, and we should use all 16 bits without any shifting as the RH_Code or Temp_Code?

The formulas:

RH% = code*125/65536 - 6

and

Temp (C) = code*175.72/65536 - 46.85

assume a 16 bit number for code.

Masking the LSBs makes little difference as the 2nd LSB of the 16 bit number is 2*125/65536 %RH = 0.003%RH and 2*175.72/65536 C = 0.005 C. In principle, the LSBs do not contain information related to the RH or temperature itself but in practice there is no good reason to mask them off.

Thanks, perhaps the errata you are working on could clarify this. The confusion occurs because RH_code and Temp_Code are not defined. To mask off the bits and then perform the calculation 'properly' I suggest the following:

RH_Code = ((MS Byte) << 8 + LS Byte) >> 2

TH_Code = ((MS Byte) << 8 + LS Byte) >> 2

%RH = ((125 * RH_CODE)/16384) - 6

Temperature (C) = ((175.72 * Temp_Code)/16384) -46.85

The description above clarifies the underlying intent, but, changes the equations. Using RH_code = ((MS Byte) << 8 + LS Byte) & 0xfffc and leaving the calculation alone would also be fine.

The data sheet implies that one could look at the low order 2 bits of the Code and determine if the value observed was a temperature (0x0) or a humidity (0x2). Is this the intent of providing a value in those bits? If so this intent could also be put into the errata.

Than you for your comments.

There is really no need to mask off the lower bits when making the calculations. The lower bits are simply not significant in terms of the conversion result. That said, it also does not hurt to mask off the bits. I apologize if the code example where they were masked caused any confusion.

It is correct that the data in the LSB bits represents the type of data, but generally the type of data is already known so most people do not bother looking at the bits as an error check. The optional checksum is a more powerful way of doing error checking if error checking is desired. The function of these bits is properly documented in the data sheet.