AHT10 - I2C problem

Just curious, what is the scenario where they will both be deployed connected to the same microcontroller?
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). Do you intend to have the sensors connected over a long distance?

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

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

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.

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

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.

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.

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

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.