5

for some project I need 5 sensors. Their I2C address is fixed and can be changed to another fixed value by soldering. So without an I2C multiplexer (which I don't have), I need at least 3 I2C busses.

Hence, I added two additional I2C busses to my Raspberry Pi 3B by adding the following lines to /boot/config.txt:

# open another i2c bus on GPIO 20 (SDA4) and GPIO 21 (SCL4)
dtoverlay=i2c-gpio,bus=4,i2c_gpio_delay_us=1,i2c_gpio_sda=20,i2c_gpio_scl=21

# open another i2c bus on GPIO 20 (SDA3) and GPIO 21 (SCL3)
dtoverlay=i2c-gpio,bus=3,i2c_gpio_delay_us=1,i2c_gpio_sda=19,i2c_gpio_scl=26

On the breadboard, this works just fine and I receive the data reliably (using an adapted version of these instructions). Now I want to distribute the sensors at quite some distance from the Raspberry Pi using some 50m of data cable. I know that I2C isn't made for this and, in fact, it doesn't work out of the box. Using the built-in I2C bus (bus 1), I immediately get an IOError if I try to read the sensor over the data cable. However, if I alter the baud rate from the standard 100 kHz to 10 kHz by adding

i2c_arm_baudrate=10000

to /boot/config.txt, everything works fine.

My question is: How can I alter the baud rate of the additional I2C busses? Is this possible at all? I tried i2c_gpio_baudrate without success and couldn't find any reference on how to do that.

Thank you very much!

2
  • 1
    have you tried adding i2c_arm_baudrate to the list of parameters when you setup the aditional buses. "dtoverlay=i2c-gpio,bus=4,i2c_gpio_delay_us=1,i2c_gpio_sda=20,i2c_gpio_scl=21,i2c_arm_baudrate=10000"
    – Chad G
    Commented Sep 23, 2020 at 18:05
  • 1
    I tried that but it didn't change anything. I solved the problem, however, see below. Nevertheless, thank you for your help!
    – Kilroy
    Commented Sep 23, 2020 at 19:36

2 Answers 2

4

I think I can actually answer the question myself now.

You can change the baud rate of additional I2C busses on the GPIOs by changing the i2c_gpio_delay_us paramter, which defines some time constant in microseconds (check out /boot/overlays/README). The default seems to be 2, which supposedly corresponds to approx. 100 kHz. Changing that to 20 got me a working I2C bus over the 50m of data cable (at approx. 10 kHz I guess).

In short, the lines in /boot/config.txt now read

# open another i2c bus on GPIO 20 (SDA4) and GPIO 21 (SCL4)
dtoverlay=i2c-gpio,bus=4,i2c_gpio_delay_us=20,i2c_gpio_sda=20,i2c_gpio_scl=21

# open another i2c bus on GPIO 20 (SDA3) and GPIO 21 (SCL3)
dtoverlay=i2c-gpio,bus=3,i2c_gpio_delay_us=20,i2c_gpio_sda=19,i2c_gpio_scl=26

and everything works as expected.

0

If the distance is your concern, why not using a bus buffer dedicated for I2C communication over long distances? Like the P82B96? This can go up to 250m with bus speeds of 120kHz (much more than you apparently need).

The buffer converts the voltage level to a current, sends it to the other end of the cable and then another buffer converts it back from current to voltage.

2
  • This doesn't answer the question itself directly, but is relevant due to the background of the problem :) I'll definitely have a look at it, thank you!
    – Kilroy
    Commented Sep 29, 2020 at 6:39
  • Welcome... Well, you were talking about issues when using sensors at "quite some distances", so that's why I was homing in on that one.
    – GeertVc
    Commented Sep 30, 2020 at 7:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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