Technical support request: DXL355Z → Midpoint → RJ45 network cable → Endpoint → TCA9548A Qwiic Mux → JST connection → Raspberry Pi 5

Other
1

I am writing to request technical support for a project we are currently developing, which involves the following components:

1.- ADXL355Z Accelerometer
2.- SparkFun QwiicBus – Midpoint
3.- SparkFun QwiicBus – Endpoint
4.- SparkFun Qwiic Mux Breakout – 8 Channel (TCA9548A)
5.- Raspberry Pi 5

Our current configuration is as follows:

ADXL355Z → Midpoint → RJ45 network cable → Endpoint → TCA9548A Qwiic Mux → JST connection → Raspberry Pi 5

With this configuration, we have successfully established communication with the accelerometer. In other words, by connecting the ADXL355Z to the MidPoint via RJ45, then to the EndPoint via a network cable, and from there to the TCA9548A multiplexer, the accelerometer is correctly detected and read by the Raspberry Pi 5.

However, we encountered a problem when trying to connect the accelerometer directly to the JST connectors available on the MidPoint, or via the solder points on the board.

Under these conditions, the accelerometer is not detected by the Raspberry Pi, while it works correctly when using the MidPoint’s RJ45 connection.

To rule out a possible accelerometer failure, we performed tests using different ADXL355Z units, obtaining the same result: communication works via RJ45, but not via the JST connectors or a direct connection to the MidPoint’s solder points.

Therefore, we would appreciate your guidance on the following points:

Is it necessary to make any modifications, configurations, or jumpers on the QwiicBus MidPoint board to use the JST connectors or solder points?
Is there any electrical or wiring difference between the RJ45 interface and the MidPoint’s JST connectors that we should consider?
Are there any specific requirements regarding power, GND, or other signals that we should consider when connecting the accelerometer directly to the MidPoint?
Is the MidPoint designed to allow the direct connection of a sensor using the JST connectors or solder points, without using the RJ45 interface?
Finally, is it possible that the MidPoint we are using has a fault?

Our goal is to correctly use the ADXL355Z → MidPoint → EndPoint → TCA9548A → Raspberry Pi 5 architecture, so any recommendations regarding the correct configuration or wiring of the MidPoint would be very helpful.

We look forward to your comments and recommendations.

2

Ok, so those can be a bit confusing…but the short answer/solution is to add an endpoint between the midpoint and the ADXL. The MidPoint has no terminating resistors, and controllers must connect to an EndPoint, not a MidPoint. Per our hookup guide: the PCA9615 requires terminating resistors on both ends of the bus to function properly. The EndPoint includes these resistors but as the MidPoint’s name suggests, it is intended to only act as a node (middle point) and therefore does not have terminating resistors. The QwiicBus only functions with controllers (Arduino/SBC/etc.) connected to the EndPoint. As the name may suggest, the EndPoint design includes the required terminating resistors to act as the ends of the QwiicBus. The MidPoint does not include these resistors since they are intended to be inserted in between the EndPoints as nodes

Below I’ll field the other questions though:

1. Jumpers/config needed for JST or solder-point use on the MidPoint?
No special jumper is required just to use the JST/solder points as such — that’s the intended local I2C tap point for a sensor. The failure isn’t about the JST pads themselves; it’s about what’s on the other end of the bus. If your host (RPi5/TCA9548A) is connected directly to the MidPoint instead of through an EndPoint, the bus lacks termination and won’t work reliably (if at all).

2. Electrical/wiring difference between RJ45 and JST paths on the MidPoint?
Yep, fundamentally different. The RJ45 side carries the differential I2C signal (4 wires: SDA+/SDA-, SCL+/SCL-) converted by the PCA9615. The Qwiic/JST side (and the solder points) carries standard single-ended I2C (SDA/SCL)

3. Power/GND considerations connecting a sensor directly to the MidPoint?
A few things:

  • Each MidPoint needs its own I2C pull-ups enabled (default closed via the I2C jumper). We recommend disabling pull-ups on the ADXL355Z breakout itself if it has its own, to avoid over-strong parallel pull-up resistance
  • Confirm your power configuration jumpers (Bypass/PSEL/GND1/GND2) are consistent with whichever power scheme you’re using — if you’ve deviated from the default 3.3V-everywhere config, mismatched jumpers between MidPoint and EndPoint will cause exactly this kind of “detected here, not there” symptom

4. Is the MidPoint designed for direct host connection via JST/solder points, without RJ45?
No. The MidPoint is architecturally a pass-through node only — it needs to sit between two EndPoints (or an EndPoint and another MidPoint) via RJ45 to have valid bus termination. The host/controller must always terminate at an EndPoint

5. Could your MidPoint units be faulty?
Extremely unlikely…the behavior you’ve described is expected

Check out the other sections of the hookup guide linked a few paragraphs above for more details…but the simplest solution is to place an endpoint between the midpoint and accelerometer :slight_smile:

3

First, thank you for the prompt response. Next, a new, more detailed question.

I am writing to request further technical guidance regarding a multi-sensor setup using the QwiicBus architecture.

Current Hardware Topology:

  1. Raspberry Pi 5

  2. SparkFun Qwiic Mux Breakout – 8 Channel (TCA9548A)

  3. SparkFun QwiicBus – EndPoint 1

  4. SparkFun QwiicBus – MidPoint

  5. SparkFun QwiicBus – EndPoint 2

  6. Sensor 1: ADXL355Z (Address 0x56, connected at EndPoint 2 via RJ45)

  7. Sensor 2: ADXL355Z (Address 0x1D, connected locally to the MidPoint via JST / solder pads)

System Connections:

  • Raspberry Pi 5 → TCA9548A Mux → EndPoint 1 → (RJ45 Cable) → MidPoint → (RJ45 Cable) → EndPoint 2 → Sensor 1 (0x56)

  • Sensor 2 (0x1D) is wired directly to the MidPoint’s local JST / solder pads.

The Issue:

  • Sensor 1 (0x56) connected at EndPoint 2 communicates perfectly and is detected by the Raspberry Pi 5.

  • Sensor 2 (0x1D) connected locally to the MidPoint (via JST or solder points) is not detected on the I2C bus (i2cdetect), even though its hardware pins have already been configured for I2C mode and address 0x1D.

Verification Steps Performed:

  1. I2C & Address Verification: Sensor 2 was tested individually and confirmed working in I2C mode with address 0x1D.

  2. Bus Termination: EndPoint 2 is present at the end of the RJ45 chain to provide proper PCA9615 differential bus termination ($120\ \Omega$).

  3. Direct Host Test: Connecting EndPoint 1 directly to the Raspberry Pi 5 (bypassing the TCA9548A Mux) yields the exact same result: 0x56 responds, but 0x1D at the MidPoint does not.

    NOTE:
    Pull-Up Resistors ADXL355Z:     Since the official Analog Devices EVAL-ADXL355Z breakout board does not feature built-in I2C pull-up resistors on SDA/SCL, we are relying on the MidPoint’s internal pull-ups. We would like to verify if additional external pull-ups (e.g., $2.2\text{ k}\Omega$ – $4.7\text{ k}\Omega$) are required directly at the MidPoint’s local I2C taps to maintain signal integrity across the PCA9615 single-ended bus.

Questions:

  1. Are any specific jumper configurations required on the MidPoint (such as PSEL, BYPASS, or I2C pull-ups) to enable voltage pass-through and communication for a local sensor attached to its JST/solder pads while an active differential bus passes through it?

  2. Does the PCA9615 on the MidPoint require a specific ground reference or pull-up modification on the local single-ended side when tapping into the node?

  3. What could cause a local sensor on the MidPoint to be ignored by the bus while the downstream EndPoint sensor communicates without issues?

Thank you for your time and assistance. We look forward to your recommendations.

4

Wait, I have questions.

In other words, by connecting the ADXL355Z to the MidPoint via RJ45

How are you connecting the ADXL355 via RJ45?

Also, it sounds like you have a midpoint connecting on one end to an end point and nothing on the other side. Have you tried using just two end points and no mid point?

5

Thank you for the quick follow-up. To clarify how our hardware is wired:

  1. How we connect the ADXL355Z via RJ45: We connect the EVAL-ADXL355Z directly to an EndPoint via short I2C wires. That EndPoint then connects via RJ45 to the rest of the chain.

  2. Full Chain Configuration (Yes, the bus IS properly terminated at both ends): We are not leaving one end of the MidPoint open. The MidPoint sits between two EndPoints, acting as a pass-through node for a distant sensor while hosting a second sensor locally on its JST/solder pads.

    Here is our exact topology:

    • Host Side: Raspberry Pi 5 → TCA9548A Mux → EndPoint 1

    • First Segment: EndPoint 1 → (RJ45 Cable) → MidPoint

    • Local Node at MidPoint: Sensor 2 (EVAL-ADXL355Z, Address 0x1D) connected directly to the MidPoint’s local JST / solder pads

    • Second Segment: MidPoint → (RJ45 Cable) → EndPoint 2

    • Far-End Node: EndPoint 2 → Sensor 1 (EVAL-ADXL355Z, Address 0x56)

      The Core Issue: Sensor 1 (0x56) at the far-end EndPoint 2 works without issues. However, Sensor 2 (0x1D) attached locally to the MidPoint’s JST/solder pads is completely ignored by i2cdetect, despite having its hardware pins properly configured for I2C (CS tied to 3.3V, ASEL tied to GND).

      Please see the topology diagram below for reference:

      ±-----------------+
      | Raspberry Pi 5 |
      ±-------±--------+
      |
      v
      ±-----------------+
      | TCA9548A Mux |
      ±-------±--------+
      |
      v (Single-Ended I2C / JST)
      ±-----------------+
      | EndPoint 1 | ← BUS TERMINATION #1 (120 Ohm)
      ±-------±--------+
      |
      | [ RJ45 Cable - Differential I2C ]
      v
      ±-----------------+
      | MidPoint | ← LOCAL NODE
      ±–±---------±–+
      | |
      | ±–(JST / Solder Pads)—> [ Sensor 2: ADXL355Z (0x1D) ]
      | (FAILS / NOT DETECTED)
      | [ RJ45 Cable - Differential I2C ]
      v
      ±-----------------+
      | EndPoint 2 | ← BUS TERMINATION #2 (120 Ohm)
      ±-------±--------+
      |
      ±–(Single-Ended I2C)—> [ Sensor 1: ADXL355Z (0x56) ]
      (WORKS PERFECTLY)

6

Hmmm… I don’t think the midpoint can go after an endpoint (in this case it seems to be a continuation from endpoint1?) Can you remove endpoint1and test?

Otherwise, maybe this is related?

“Each MidPoint will need its own set of pull-up resistors on the I2C side of the PCA9615.”

“This jumper connects the SDA and SCL lines to VDDA of the PCA9615 (normally 3.3V) via a pair of 4.7kΩ resistors. The jumper’s default state is CLOSED. To disable the pull-up resistors open the jumper by severing the trace between the three pads.”

So this is a per-board, independent, discrete solder jumper labeled I2C, closed by default. Is that i2c jumper trace intact or severed on your MidPoint?

Testing:

  • Unpowered: check continuity/resistance from the MidPoint’s SDA pad to its 3.3V pad, and SCL pad to 3.3V pad. Intact jumper → ~4.7kΩ each. Severed → open circuit.
  • Powered/idle: SDA and SCL at the MidPoint’s Qwiic/solder pads should sit at ~3.3V (VDDA, per the doc’s default 3.3V config). Near 0V or floating = missing pull-up.

One more hypothesis worth adding now that I’ve seen the full guide — this line stood out:

“Important! Make sure your QwiicBus circuit is not powered when adding or removing devices to your MidPoint(s) and EndPoint. Connecting and disconnecting devices while your QwiicBus is powered can cause voltage spikes and damage the PCA9615.”

If your jumper checks out fine (4.7kΩ present, 3.3V present) but Sensor 2 is still dead, consider that the MidPoint’s PCA9615 itself may have been damaged by hot-plugging during earlier testing/soldering. This might selectively kill that board’s local I2C driver stage while leaving the differential pass-through (and therefore Sensor 1’s path) working, since pass-through doesn’t require the local single-ended driver to be healthy. If you have a spare MidPoint, swapping it in as a quick A/B test would confirm or rule this out