HDC1080: The humidity data is sometimes output as "0xFFFF"

Hi Tao_2199

1)Could you please tell us any possible causes , comment and advice?

Does your customer perform a separated reading for temperature and humidity at the end of the conversion?

In this case the possible implemented sequence could be the follow:
1. conversion trigger: I2C WRITE pointer 00hex (to trigger temperature + humidity conversion)
2. read temperature : I2C READ (because the pointer is already in position 00Hex)

If at this point a new I2C WRITE operation is performed to modify the pointer to 01Hex, a new humidity conversion is triggered and the HDC1080 doesn't lower the SDA line.

If my understand is correct what I suggest is to do not perform a new I2C WRITE, but directly read the 32 bits (16 temp and 16 hum) in a single shot

2)About humidity data format,
According to datasheet, the 2 LSBs D1 and D0 are always 0.
Is there possible that 2 LSBs make to both “1”?

It's correct the 2LSB D1 and D0 are always '0'. The only possibility to read 0xFFFF is related to I2C communication problem.

Regards
Massimo

Hello Massimo,

 

Thank you for reply.

 

You mentioned that if a new I2C WRITE operation is performed to modify the pointer to 01Hex,

a new humidity conversion is triggered and the HDC1080 doesn't lower the SDA line.

 

I have a question about above.

(Question)

According to reading humidity and temperature measurement in datasheet page 12,

To trigger the measurement, the address pointer to 0x00 and 0x01 are set.

This is meaning that a new I2C WRITE operation is performed to modify the pointer to 01Hex.

At that time, a new humidity conversion is triggered and doesn't It lower SDA line?

(Same as above behavior? )

 

Regards,

Tao2199

Hello Massimo

Additional question.
In case of reading humidity and temperature measurement in datasheet page 12,
Do they need to set the both address pointer (0x00(temp) and 0x01(hum)) for conversion trigger ?
I’m asking just in case.

Regards,
Tao2199

Hello Massimo,

Thank you for reply.
They have checked with wait time 100ms and this problem was solved.
(0xFFFF data is not happened. )
They had configured 50ms for the wait time until now.
They are asking some question about wait time for conversion.

(Question)
(1) How minimum times do they need to estimate for Temp+Hum conversion ? (configuration bit12: Mode=1)
(They think that many margin will be included in 100ms.)
According to other thread, minimum times is 40ms for Temp+Hum conversion.
e2e.ti.com/.../1794906 conversion time#1794906

(2) In case of the configuration bit12: Mode=0(individual acquisition),
Is the wait time need same as Mode1(100ms)?

(3) Is the conversion time affected by their application condition(for example, air flow, PCB layout)?

Regards,
Tao2199e2e.ti.com/.../2292523

Hi Tao2199

I'm happy that the customer problem is solved.

The humidity and conversion time is stated in the datasheet.
Humidity (11 bit resolution)= 3.85ms
Temperature (11 bit resolution) = 3.65ms
In the condition stated in the datasheet (VDD=3V, Temp = 30degC and Hum = 40%RH)

But at system level you have to consider the time to generate the command in the microcontroller and send the I2C command and this is not related to the HDC1080 performances.

Due to the fact that I don't know the customer system my suggestion is to perform some test to evaluate the minimum wait time in their system.

Regards
Massimo

Hello Massimo

 

Thank you for reply.

Their I2C speed is 100KHz(0.01ms).

Therefore, it takes about total 0.2 ms for the trigger measurement commands.(Please below.)

 

(Question)

(1) Even if considering the time to generate the command in the microcontroller and send the I2C command,

they think that the wait time 100ms is too long.

Is there any other possible causes?

 

(2) About your mentioned wait time 100ms,

Could you please tell us what the reason is for 100ms?

 

(3) According to other thread, minimum time is 40ms for Temp+Hum conversion.

e2e.ti.com/.../1794906 conversion time#1794906

 

Can they use this value as minimum wait time?

 

 

Regards,

Tao2199

Hello Tao2199

I suggested a "safe" wait time of 100ms because I don't know the system of your customer,

It's possible to reduce the wait time down to 40ms, but the customer has to verify this wait time in the his application.

Regards
Massimo