• TI Thinks Resolved

HDC1080: Temp and humidity data become 0xFFh rarely.

Guru 13685 points

Replies: 26

Views: 223

Part Number: HDC1080

 Hello guys,

 One of our customers is evaluating HDC1080 on their own board for their next products.

 In the evaluation, when they read temperature and humidity data repeatedly through I2C from HDC1080, the both data become 0xFFh rarely.

 I2C clock frequency is 400kHz.

 Could you tell me what could be the cause?

 Your reply would be much appreciated.

 Best regards,

 Kazuya.

  • Hi Kazuya-san,

    Do you have a logic analyzer capture of the I2C read that you can share?

    Additionally, what are the set conversion times?

    Best regards,

    Nicole

  • In reply to Nicole Khoury:

     Hello Nicole,

     Thank you very much for your reply.

     They are trying to get total I2C data logic capture or oscilloscope waveform of the 0xFFh reading case.

     I will send you the data as soon as I get it

     Also I confirmed they set configuration register to 0x00h.

     So I think each parameter setting should be as the follows.

     // Humidity MeasurementResolution = 14bit 

    // Temperature MeasurementResolution = 14bit

     // Mode of acquis = Temperature and Humidityare acquired insequence, Temperature first.

     // Heater = Heater Disabled

     // Software reset = Normal Operation

     

     Thank you again and best regards,

     Kazuya Nakai.

  • In reply to Kazuya Nakai59:

     Hello Nicole,

     The customer took some waveforms when temp and humidity data was 0xFFh as the attached.

     As a n additional information, one 0.1uF ceramic capacitance is placed jusy nearby HDC1080.  

     Could you please check their waveforms and give me your comment?

     Your reply would be much appreciated.

     Thank you and best regards,

     Kazuya.

    /cfs-file/__key/communityserver-discussions-components-files/1023/HDC1080_5F00_I2C_5F00_Waveform070720.pdf

     

  • In reply to Kazuya Nakai59:

    Hi Kazuya,

    Thank you for the data.

    I believe the I2C stop condition is being violated, which can be seen in your 6th waveform image. In this capture the SCL line stays low while the SDA line transitions from low to high. To signal a stop condition SCL should be high while SDA is transitioning.

    Best regards,

    Nicole

  • In reply to Nicole Khoury:

     Hello Nicole,

     Thank you very much for your reply.

     I understood well what you said.

     Could I ask you a few additional questions as the follows?

     Q1. Is the stop condition needed to insert to the end of Frame 2 (Pointer register byte write timing)

           because we can't see the stop condition at the timing in figure 12 on page 12 of the device dtasheet?

     Q2. The customer is using figure 12 and figure 14 together to trigger measurement and measurement data reading as the follow.

           Frame 1 + Frame 2 (Figure 12) sending -> Wait 20ms for Temp/Humid measurement -> Frame 3 ~ Frame7 (Figure 14) sending using repeated start.  

           Is this sequence wrong to trigger measurement and read the measument data?

     Thank you again and best regards,

     Kazuya.

             

  • In reply to Kazuya Nakai59:

    Hi Kazuya,

    A1. You're correct that figure 12 does not have a stop condition pictured, but a stop is usually issued after the measurement trigger command. A stop, or at least releasing the SCL line, is preferred to holding SCL low.

    A2. The sequence seems correct, but SCL is being held low and a stop would be preferred. 

    Best regards,

    Nicole

  • In reply to Nicole Khoury:

     Hello Nicole,

     Thank you for your reply.

     I asked them to try to change SCL lever to high and to check whether 0xFFh output phenomenon is solved or not.

     At this moment, they have a question as the follow. Could you please give me your reply?

     Q. Has TI ever seen this 0xFFh output phenomenon?

     Thank you again and best regards,

     Kazuya.

  • In reply to Kazuya Nakai59:

    Hi Kazuya,

    Here was a similarly presenting issue regarding humidity readings with the HCD1080: https://e2e.ti.com/support/sensors/f/1023/t/621625?tisearch=e2e-sitesearch&keymatch=HDC1080

    In this scenario, increasing the conversion time to 100 ms seems to have resolved the problem.

    Best regards,

    Nicole

  • In reply to Nicole Khoury:

       Hi Nicole,

     Thank you for the information.

     I will ask them to try to read the temp and humid data after 40ms or longer wait time.

     But HDC1080 datasheet says like the follow on page 12 of the device datasheet.

    4. Read the output data:
    Retrieve the completed measurement result from register address 0x00 or 0x01, as appropriate, as shown in
    Figure 11. A read operation will return a NACK if the measurement result is not yet available, as shown in
    Figure 13 on page .

     According to their waveform, The acknowledge of Frame 3 is low and it means read data is active.

     Is my understanding wrong?

     Could you please give me your comment or advice?

     Thank you again and best regards,

     Kazuya.

      

  • In reply to Kazuya Nakai59:

     Hello Nicole,

     Thank you for your strong support.

     The customer read Temp/Humid data with 40ms wait time.

     But 0xFFh was still read.

     Do you have any idea to solve this 0xFFh reading problem?

     Thank you again and best regards,

     Kazuya.