Actions
Forum Thread Details
  • Replies 41 replies
  • Subscribers 338 subscribers
  • Views 9552 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?

  • in reply to shabaz

    I am planning to put one inside the hive the other outside the hive on the same microcontroller. I am thinking to put them roughly 10cm away from each other located on the top of the hive. However, the configuration may change as there are various thermal spots inside the hive. Actually, I may need more than two still researching characteristic of the hive temperature. 

  • in reply to msimon

    I see; in that case, perhaps something like this could be useful, it's a low-cost component (PCA9548A), called an I2C Multiplexer if you're looking for such types of parts. Then you're free to add quite a lot of sensors. 

    Personally I'd do it in software though (i.e. using GPIO pins) if there are enough pins. But this could be a scalable way for up to 8 devices (actually up to 64 devices, since you can install many of these PCA.. chips but that seems an unlikely scenario).

    image

  • 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 shabaz
    shabaz said:
    Ordinarily, the distance cannot be too great with I2C (i.e. i2C not normally used for local/remote sensing, unless remote is something inside the same enclosure (usually).

    I've seen some pretty long VGA cables in my time... Slight smile

    DDC uses I²C to access the EDID data in the display device to report it back to the source device.

  • in reply to beacon_dave

    There are quite long lengths within large equipment chassis' too, since it's quite common for health/alarms etc from cards plugged into a motherboard, although they may use separate I2C bus segments in some situations. VGA etc is a bit of an exception, since it's only intended for one device, and the cable is designed for it (plus little will go wrong if someone extends it, because either they will get a display or they won't). Whereas for the more general use, I2C needs to configure chips, take measurements, etc.

  • in reply to beacon_dave

    "DDC uses I²C to access the EDID data..."

    But not at the standard clock rate of 400kHz. They slowed it to about a tenth of that.

  • 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 shabaz

    Actually, there may be a translation error. It works with TMP102 sensor. I also think GPIO is a good option.

    I won't invest in a mux for these unreliable sensors. I just want to play with them and see how I can mitigate it. If things not sorted, I will buy a better sensor.

  • in reply to BigG

    I connected two sensors on the same bus and then connect their Vin pins to GPIO. I also attach another I2C sensor TMP102.  It looks like working but there is a reliability issue. Sometimes it stops. I also suspect the serial port of Arduino IDE. I will check that. 

  • 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.