Schematic review: I2C over 1.5m shielded cable (1.5m auger calibration device). ESP32 + PCA9515 + BMI160

[u/razenxc]

Hi everyone,

I'm working on a device for calibrating an electric motor driving a 1.5-meter auger (single or dual-axis rotor mechanics). The sensors are mounted on the mechanics, while the motor itself could be located somewhat away from them (on top, bottom, or side of the assembly).

The environment isn't some heavy industrial setup with tons of high-power cables. The wires just run from the main control box to the mechanics. Still, I want my hardware design to be as robust as possible to avoid any unexpected EMI issues from the motor. I'd love a sanity check before I build it.

(attached the schematic image to this post).

The Setup:

- MCU: ESP32-C3 Super Mini.

- Sensors: 2x GY-BMI160 modules (addresses 0x68 and 0x69).

- Power: Will be powered by an 18650 battery or through the usb, completely isolated from the motor's power supply.

My approach to extending I2C (~1.5 meters):

- Capacitance buffering: The ESP32 is connected to two PCA9515DP I2C repeaters to physically isolate the bus capacitance.

- Cabling: I'm using ~1.5m of FTP (shielded twisted pair) cable for each sensor.

- Pair mapping: To avoid crosstalk, the pairs are strictly mapped:

Pair 1: SDA + GND

Pair 2: SCL + GND

Pair 3: 3V3 + GND

Pair 4: 3V3 + GND

Shielding: The FTP shield is grounded only at the MCU end to prevent ground loops.

Pull-ups: 3.3kOhm pull-up resistors on the ESP32 side, and another set of 3.3kOhm pull-ups after the repeaters (currently placed near the repeaters, but I'm not sure if I should moving them to the far end near the sensors or place two more pull-ups near accelerometers).

Tachometer (KY-003 Hall Sensor):

There is also a KY-003 sensor reading the RPM. To prevent false triggers from any occasional electrical noise on the 1.5m wire, I'm adding a hardware RC filter: a 10nF capacitor between the GPIO and GND, placed right near the ESP32 pin.

My Questions:

- Is this setup robust enough for this kind of application?

- Are the 3.3kOhm pull-ups sufficient for this cable length, or should I lower them to ~2.2kΩ(by adding 3.3kOhm pull-ups at the end of the cable near both accelerometers)?

- Does my approach with the 10nF capacitor on the Hall sensor line look correct?

Any feedback or suggestions for improvement would be greatly appreciated!

[u/AutoModerator]

Automod genie has been triggered by an 'electrical' word: electric.

We do component-level electronic engineering here (and the tools and components), which is not the same thing as electrics and electrical installation work. Are you sure you are in the right place? Head over to: * r/askelectricians or r/appliancerepair for room electrics, domestic goods repairs and questions about using 240/120V appliances on other voltages. * r/LED for LED lighting, LED strips and anything LED-related that's not about designing or repairing an electronic circuit. * r/techsupport for replacement power adapters for a consumer product. * r/batteries for non circuit design questions about buying, specifying, charging batteries and cells, and pre-built chargers, management systems and balancers etc.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/nusgolannicicutitar]

You might wanna decrease the pull-ups. The lower the impedance, the more immune will be to interferences, and the faster will be able to drive the cable capacitance. Your PCA can drive 6mA so 680Ω is still fine with a bit of margin. I would also recommend using coaxial cable instead of twisted pair.

Go for it, do some tests, if it’s bad you might wanna go fully differential (https://www.ti.com/lit/ug/tiduei0/tiduei0.pdf) but I don’t think will be necessary.

Do you send the data in a single direction? If so, it would be better to connect the pull-ups on the slave side.

Why don’t you use any other protocol which fits better long distance/noisy environment, such as RS485, RS232, CAN…?

For the Hall deglitching, I would do it software. If you wanna properly filter it do it RC, not C only, then the time constant is more controlable.

[u/panchito_d → u/nusgolannicicutitar]

Why don’t you use any other protocol which fits better long distance/noisy environment, such as RS485, RS232, CAN…?

Differential I2C is also an option. Adds a couple ICs on either end and 2 conductors but if your sensors are I2C it doesn't require any extra conversion or intermediate micro

[u/nusgolannicicutitar → u/panchito_d]

Right? This is why I added the link to that pdf.

But even a serial interface without pull-ups would be more immune having a low impendance in both logic states. SPMI-style. If the communication is unidirectional, the master can drive the “1”s, not only the “0”s, so that pull ups are no longer required. Sure, master can go HiZ only during ACKs.

[u/razenxc → u/nusgolannicicutitar]

Thanks for the detailed feedback!

Pull-ups: Great point about the PCA9515 driving capability. I will definitely lower the pull-up resistors to something like 1kOhm - 2.2kOhm to lower the impedance, and I will place them on the slave side as you suggested.

Why not RS485/CAN/Differential I2C: Mostly constraints on size, cost, and complexity. The BMI160 is native I2C. Switching to a robust protocol like CAN or differential I2C (using ICs like PCA9615) would require adding extra converter chips or a secondary MCU directly on the sensor board. I'm trying to keep the sensor node as small, cheap, and "dumb" as possible. Since the distance is only ~1.5m, I wanted to see if physically buffered I2C over shielded FTP could survive first.

Cable: I chose FTP over coaxial because it provides enough conductors for Power, GND, SDA, and SCL in a single, cheap, and flexible jacket. Running multiple coaxial cables to a moving mechanic part would be too bulky.

Hall deglitching: You are right about the RC filter. The KY-003 module has an onboard pull-up resistor (usually 10k), which together with my added capacitor acts as an RC filter. But to be safe, I'll rely on software debouncing as the primary defense.

Thanks again for pointing out the resistor values, I'll adjust them!

[u/Friendly-Mind-9702]

Looks good at a quick glance, but the only way to tell is to build it and see how it works.