ESP32 I2C power/distance problem?

[antonyc]

Ok,

It seems that this problem is to do with the clock line. There is some documentation online about it.

First of all, I'm going to do a logic analysis of the clock and data lines with the 3.9k which I've got.

Then I'm going to wire in the 2.2k instead of the 3.9k, and look for any difference.

Then I'm going to leave it for a few hours.

Steps to take after this:

Wire the thing with 1 signal wire with one ground wire and repeat for the other data wire.

Shield with grounded aluminium foil.

[Archibald]

I know Ethernet cable such as CAT5e is often recommended for I²C over in the Arduino forum but, as you are not using balanced transmission, I would expect use of a screened cable to be much better (some Ethernet cables are screened). I've found these multi-core screened cables for example:
https://www.rapidonline.com/sommer-cabl ... wg-59-1181
https://www.rapidonline.com/lappkabel-2 ... mm-63-4858

Especially over your short distance, I would expect screened audio cable to be virtually as good.

Of course an alternative is to use separate coaxial cables for SDA and CLK. You would want coaxial cable with a decent screen, not UHF aerial cable.

Anyway I still think slowing down the I²C is the best thing to try first.

I see the datasheets for both the BH1750 and ADS1115 say the SDA output voltage with 3mA sink current is less than 0.4V. So you could try reducing the pull-up resistors to 1kΩ: that should reduce the effect of cable capacitance.

[antonyc]

Ok, I reset the ESP32... I2C started working fully.

I added the logic analyser and the moment I plugged it in to the laptop, I2C instantly failed. I tried again and it eventually worked. With the analyser, I can see that when I2C works, the pulse train is crystal clear, even with the 3.9k. With the logic analyser plugged in, I2C is sometimes unable to work. When I unplug and reset, I2C works again most of the time.

When it is working, it makes no difference if I wiggle wires, touch metal contacts, etc... I used a magnet to try to induce some noise into the wires.. It didn't cause it to break.

I've read lots of articles and stuff, and can get some ideas of what is happening, but it seems that the problem is to do with the ESP32's I2C library.

I've had a problem with ESP32 Modbus too, but fixed it. The problem with that was that the ESP32's timing was all over the place because of the library.

I've changed the resistors to the 2.2k one now... Let's see what happens.

[antonyc]

I know Ethernet cable such as CAT5e is often recommended for I²C over in the Arduino forum but, as you are not using balanced transmission, I would expect use of a screened cable to be much better (some Ethernet cables are screened). I've found these multi-core screened cables for example:
https://www.rapidonline.com/sommer-cabl ... wg-59-1181
https://www.rapidonline.com/lappkabel-2 ... mm-63-4858

Especially over your short distance, I would expect screened audio cable to be virtually as good.

Of course an alternative is to use separate coaxial cables for SDA and CLK. You would want coaxial cable with a decent screen, not UHF aerial cable.

Anyway I still think slowing down the I²C is the best thing to try first.

I see the datasheets for both the BH1750 and ADS1115 say the SDA output voltage with 3mA sink current is less than 0.4V. So you could try reducing the pull-up resistors to 1kΩ: that should reduce the effect of cable capacitance.

I'll try that, thanks...

I do use UTP now, but it's not shielded. I could be wrong, but I no longer thing that noise is the problem. Let's see I guess...

[Archibald]

I guess the problem is caused by cable capacitance. You would need an oscilloscope, not a logic analyser, to see the effect of capacitance on the rising and falling edges of the SDA and CLK signals.

I have wondered if the default clock rate is higher with the ESP32 than with an Arduino.

[antonyc]

This is ridiculous...

It's as if this thing is completely random. This thing seems to randomly flit between working and not working on a whim.

I can reset the device and whether it works or not is just potluck!

I'm going to try 1k now.

Should I put pullups on the light sensor too as well as the bus?

Diagnosing it is really difficult. I want to measure it in situ, but it's up a ladder!

Antony

[Archibald]

I now have the I²C scanner working with a slave on the end of 5m of unscreened 4-core burglar alarm cable.

I've found the default clock rate is 100kHz; I had wondered whether it was significantly faster than this with the ESP32. I have reduced the rate to 50kHz to confirm the rate can be readily changed (for EPS32 use setClock, not SetClock).

There's something fishy going on here. I sometimes have to remove the power to the slave several times before the bus signals restart. Watch this space!

[Hexman64]

The compiler (only) accepts Wire.setClock(xxx), but with my cheap DSO138 oscilloscope I cannot see a difference no matter what speed I set.
I'm using the DS3231.h, LiquidCrystal_I2C.h and "Adafruit_LEDBackpack.h" (which are then using wire.h) and do not need to include the Wire.h to run them. So I'm afraid to change my bus speed I might have to use Wire.h ONLY and control I2C devices using Wire.h internal commands only. That would make life pretty hard.
On the other hand, I can use Wire.Reset() (at least when I include Wire.h, did not try without) and it works, so why doesn't Wire.setClock have any impact???

Anyway... what I read and linked here says that the I2C bus on the esp32 is not stable without some modifications. As I did not investigate if I can still use the I2C bus of any other Arduino processor after applying these modifications, I did not apply them, but reset my bus everytime a time value is greater than 23 or 59. That clock is running.. ahm.. two days? now. It logged several bus errors (minute=165), but recoverd instantly by using Wire.Reset().
Too bad this cannot be done for I2C devices that are supposed to read values from 0 to 255.

[Archibald]

Evidence from my I²C bus here points towards serious issues with the Wire library for ESP32 when there is a short length of cable.

Don't worry about looking at signals on an oscilloscope. I have signals here on my oscilloscope. The rise and fall times (with 1kΩ resistors) look as if they should be easily fast enough.

I am continuing my investigations. I have a touch sensor breakout board on order and I want to make sure I have a reliable I²C link to it.

[antonyc]

Alright, I'm going to do some more investigations today.

I believe my logic analyser can detect rising and falling edges as it's 24MHz. It's more of a scope than a logic analyser. I have a scope too but I prefer the logic analyser for this sort of thing.

Changing the clock rate and/or the resistor has no effect in my case but resetting the ESP32 often temporarily fixes it. I have tried 3.9k and 2.2k resistors and the rise/fall edges were sharp on both. I suspect that Wire.Reset will also fix it, but I'll try this later.

The last hard reset lasted < 5 minutes before failing again.

Now, I'm going to check with the logic analyser what is showing on the ESP32 when the I2C bus isn't working. When it is working, the pulse train is perfect. Then I'm going to test what is happening at the device end to see if it is scruffy.

Post back soon!