I've been testing different sensors for the I²C bus with two host devices: Raspberry Pi 3B (3.3V), and Sitec S4 (5.0V).

Since one of them, namely the Sensirion SCD30, had communication problems every few seconds, I looked at the bus with a scope and found that the voltage both on SDA and SCL drops below ground level to about -0.3V at the beginning of each communication. Here is what the scope showed: Scope image of I2C communication between Raspi and SCD30 There is no difference when all devices and cables are diconnected from the I²C bus, except for the obvious fact the the host does not receive an answer when using i2cdetect.

The I²C specification allows the low level voltage to drop to -0.5V, so this undervoltage should not be a problem. The SCD30 only accepts a low level voltage above -0.3V, so this is most presumably what is causing trouble.

[EDIT] I have experimented a bit with series resistors in the bus lines (22R and 100R). 100R rounden the signals too much, but with 22R series resistance both in SDA and SCL, it looks a bit better: Scope image of I2C communication of Raspi, 22R series

[EDIT2] The communication problem seems to be caused by clock stretching, not by the undervoltage. This is what a regular transmission looks in detail: Scope image of I2C communication of Raspi with SCD30, works When clock stretching has not been enabled as described here, there are communication failures. Undervoltage does not seem to be the cause.

My problem is probably solved, but the original questions are open:

  1. What causes the undervoltage? (Inductance?)
  2. Is it possible (though not necessary) the make sure that the I²C bus voltage does not drop below a certain level, e.g. be adding a diode between each bus line and ground with a low enough forward voltage? Such devices seem to be difficult to find...
  • 3
    \$\begingroup\$ It may not be a real voltage but just a problem with the way you are grounding your measurement. IMO voltage below ground is probably not the cause of your communication issues. (But it may be a symptom of a common problem) \$\endgroup\$ – Reinstate Monica Mar 28 at 13:31
  • \$\begingroup\$ Are all of the devices on the bus using the same supply voltage? \$\endgroup\$ – Reinstate Monica Mar 28 at 13:34
  • 1
    \$\begingroup\$ I agree that what you're seeing on the scope should work; I'm not worried about what appears to be a hybrid capacitive coupling that throws your a few tenths out of range after a long period at one level. I'd like to see the schematic, the error patterns, and a faster scope trace where we could compare clock edges with data edges. The voltage variation is interesting, but it may not be at proximate cause. \$\endgroup\$ – Cristobol Polychronopolis Mar 28 at 14:49
  • 1
    \$\begingroup\$ The mentioned clock cycle issue is caused by the SCD30 stretching the clock, which does not work on the Raspi reliably, but seems to be fixable: link \$\endgroup\$ – Gunnar Arndt Mar 28 at 16:04
  • 2
    \$\begingroup\$ It looks like your scope probe compensation is off. Simply forget about this "undervoltage". it is likely a measurement artifact. \$\endgroup\$ – Ale..chenski Mar 28 at 17:16

@Ale..chenski is right: After freshly compensating the probes, the undervoltage was gone. I had compensated the probes with the attenuation set to 1x, at which setting they were still perfect, but had recently switched to 10x, not knowing that this requires recalibration. The I²C communication problem could be fixed by turning on clock stretching, as described in the updated question. Thanks everybody.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.