Actions
Forum Thread Details
  • Replies 41 replies
  • Subscribers 337 subscribers
  • Views 9300 views
  • Users 0 members are here
Related

AHT10 - I2C problem

msimon

I just bought AHT10 humidity and temperature sensor. I have seen that it supports I2C and it is cheap so I didn't think thoroughly and bought two. I wanted to try them then I encounter a problem that only a single AHT10 can be connected to single I2C bus. I thought it is related to static address but it is worse (breakout board also showing two address but no details in the datasheet). The datasheet says that "Only a single AHT10 can be connected to the I2C bus and no other I2C devices can be connected." It sounds like traditional serial communication like RS232 not I2C. 

Is it normal to advertise it as an I2C device? and I also wonder what is the technical issue preventing to connect other devices with different address. Did you have any experience similar to this on any other sensor?

Parents

  • Have you tried using the AHT10 with another device on the same I²C bus to see what happens ?

    It may be that it doesn't observe the stop condition so doesn't release itself from the host and continues responding to any data present on the bus. 

    If so, issuing a soft reset after the last measurement might be worth a try.

  • in reply to beacon_dave

    I haven't tried it yet. It is said on the data sheet. However, I will try it when I get another I2C device. It has a soft reset so it is good point to check. 

  • in reply to msimon

    Perhaps keep in mind that the data sheet may have some language translation errors.

    Running the Chinese data sheet through the likes of Google translate results in:

    "I2C Only a single AHT10 can be connected to the bus, and other I2C devices."

    which would make more sense. 

    However you would need to test it.

  • in reply to beacon_dave

    If there is a translation error, it makes more sense. On AHT20 datasheet, it also says you can connect other devices. I will test it and see. It is also weird that the breakout board has two address (0x38 and 0x39) written on the PCB but no mention of 0x39 on the datasheet. 

  • in reply to msimon

    Pin 1 is labelled as 'ADR' on the AHT10 datasheet which may have been intended for address selection at some point. It is shown on the datasheet to be connected to ground.

    On the AHT20 datasheet it has been changed to NC and no ground connection shown. 

    Is the unused pad next to 0x39 connected to VDD per chance? If so looks like it was originally intended that pulling ADR down to GND set the address to 0x38 and pulling ADR up to VDD set the address to 0x39.

  • in reply to beacon_dave
    beacon_dave said:
    Is the unused pad next to 0x39 connected to VDD per chance? If so looks like it was originally intended that pulling ADR down to GND set the address to 0x38 and pulling ADR up to VDD set the address to 0x39.

    image

    I suspect that 10k resistor is connected to pin1 which is ADR. The empty connection should be pin6 which is stated no connection. Maybe pin1-pin6 is address select. I will try to desolder it and change position. 

    I have attach TMP102 and AHT10 on the same I2C bus. Actually, it works. Occasionally, it stops but not sure it is related to I2C. I will be running the code for a long duration and see how it works.  It looks like, there is a translation error.

  • in reply to msimon

    I suspect that the middle of the three pads is Pin1 (ADR), the left pad is GND and the right pad is VDD. You could confirm that with a meter test onto the 3V3 regulator. 

    I suspect that the intention was pulling low sets it to 0x38 (default) and pulling high sets it to 0x39, but perhaps something went wrong and 0x38 only worked. However you could give it a go in the 0x39 position and see if it responds to that address.

    If you can get a scope on the I²C bus then you should be able to confirm if it is behaving nicely or not.

  • in reply to beacon_dave

    You are right   100 The left is ground and the right one is power. I had a horrible soldering but at least make it work on 0x39.  However, when I connect both sensors it stops after sometime. I need a scope to see what is going on. 

    image

  • in reply to msimon

    You may be able to work around the stopping issue by issuing a soft reset or by powering off a GPIO pin to allow you to cycle the power.

    If you are putting the device to sleep to conserve power anyway, then you would likely be powering up the sensors, taking a reading, powering the sensors down, transmitting the data, putting the microcontroller back into deep sleep, in which case you aren't likely to encounter the stopping after sometime problem.

    However it would be interesting to see what is going on seeing as you've got this far.

  • in reply to beacon_dave

    The power consumption is important as this should be a battery powered device. I still don't have a complete design. If pin count will not be an issue, it is better to activate sensors via GPIOs. Also, I will make the whole bus to sleep as natural temperature doesn't change significantly in a short period of time. Maybe the issue will not occur in the system.

    However, I wanna learn what is going on. It is over an hour and 0x39 is still working alone without an issue. Hope, I will have a chance to check this on a scope soon. 

Reply
  • in reply to beacon_dave

    The power consumption is important as this should be a battery powered device. I still don't have a complete design. If pin count will not be an issue, it is better to activate sensors via GPIOs. Also, I will make the whole bus to sleep as natural temperature doesn't change significantly in a short period of time. Maybe the issue will not occur in the system.

    However, I wanna learn what is going on. It is over an hour and 0x39 is still working alone without an issue. Hope, I will have a chance to check this on a scope soon. 

Children
No Data