AHT10 - I2C problem

You are right  beacon_dave  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. 

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.

shabaz said:

VGA etc is a bit of an exception, since it's only intended for one device

Perhaps not strictly true as about 20 years ago VESA (and Philips) had already considered 'Internal Display Dependent Devices' and 'External Display Dependent Devices' to share the same I²C bus.

The spec lists stuff like:

• Smart Battery, Charger, Selector
• Audio Processor
• PAL/NTSC Decoder
• DDC2B Monitor(memory) 

and:

• Touch Screen, Light pen or Remote Control Track Ball
• Speaker / Microphone
• Home Network IF (power line modem)
• Luminance Probe or Colorimeter
• IR keyboard and remote control pad (shared IR channel)

As it progressed into DVI and then HDMI you then had HDCP handshaking on the bus as well.

I've unfortunately encountered display equipment with loop through ports which can result in additional devices appearing on the bus often with the same address. 

I seem to recall that the early days DDC used the VSync clock, so was very slow in comparison.

Isn't Standard Mode clocking 100kHz and Fast Mode is 400kHz ? Or is the new standard now fast mode ? 

I seem to recall that there is also a Slow Mode (at around 10kHz ?) which would probably have been more appropriate for EDID.

With the introduction of bidirectional mode though I think 100kHz was standardised with the option to use 400kHz.

It looks like the I²C peripheral SAM D21 in the MKR WAN can't be set below 100kHz which is unfortunate as the AHT10 has no minimum clock speed.

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. 

Yes, you're right. The original I2C standard was 100kHz, but I got so used to working at 400kHz that I always misremember that as being the standard.

The only reason I know anything about DDC/EDID is that I once designed a box to sit in place of a monitor, to take VGA, digitise it, and process it with an FPGA to drive LED screen modules that the company I worked for made. Long time ago, though. All the PC graphic cards we had at the time were driving the EDID somewhere around 30 or 40kHz. I don't know what the VESA standard said - we didn't want to pay thousands of dollars to join and find out - we just wanted it to work with real PCs that it might be connected to (the EDID, at our pseudo-monitor end, was just an EEPROM powered from the cable with appropriate data in it, so it was a very minor part of the system).

I'm surprised they considered sharing an I2C bus on multiple external devices (plus internal), but I guess they were trying to get as much use out of their patent as they could. There's no error-checking on I2C, and risky if internal devices could be misconfigured dependent on the length of external cables. I guess it's feasible with care, but not something that could be recommended for normal uses.

That sounds an interesting project as about 15 years ago was after something similar as I wanted to be able to grab part of a VGA display and simultaneously display it on a large LED matrix.

The EDID data causes an interesting issue with some FPGA designs as the source is supposed to be able to read the EDID data even when the display device is powered off. Hence why the source supplies  a limited +5v to power the EDID memory device in the display.

Even within the VESA standard documentation it keeps referring back to the I²C standard for more info on timing.

Hi msimon ! I just ordered a couple ATH10 sensors without thinking much about it and when I downloaded the datasheet to start coding in advance I found the very sentence you are mentioning: "Only a single AHT10 can be connected to the I2C bus and no other I2C devices can be connected". I read this whole thread but I wanted to ask if you were able to share the I2C bus with other devices and if so, which ones ? 

My idea is to also include a BMP180 atmospheric pressure sensor, as well as a I2C LCD display. Of course, they have different addresses, so in theory it should work, but this claim on the datasheet is alarming. I read about that library to make I2C work with any two pins, but I just couldn't understand how to couple that with the AHTxx or AHT10 library. It goes a bit over my head, and I couldn't find any examples.

On a side note, were you able to change the address by moving the resistor? Did it work normally with address 0x39? 

Thanks in advance, this thread alone has been super informative so far. 

UPDATE: 

Sensors have arrived. It definitely seems like a translation error, as I was able to share the bus with the BMP180 sensor with no issues.

Regarding the address change, I managed to move the resistor to the 0x39 spot and after wrestling a bit with the library I managed to get it working in said address. I'm yet to connect two sensors (0x38 & 0x39) simultaneously, but I think it'll work.

Maybe the ATH10 wasn't as bad as I expected when reading about it in forums!