You have found a sensor that does what your prototype needs, but its cable does not match your development board. An adapter looks like the easy answer. Before ordering a custom cable or changing the PCB, check what the adapter actually connects: power, signal direction and the way data is sent all matter.
Two GraftSense adapter boards we designed make these differences concrete. A PH2.0-3P version connects the single status output of an MWFD liquid/bubble detector. An XH2.54 version carries UART communication for several Mysentech sensor modules. They share a Grove-style connector on the controller side, but they do different jobs.
Start with what the sensor sends
The MWFD interface has three functions: output, power and ground, labeled O, V and G in its documentation. The adapter routes the status signal to DOUT on the controller side, leaving one of the four Grove positions unused. Software reads a state rather than decoding a stream of measurement messages.
According to its documentation, the sensor drives the output low when liquid is detected and high when a bubble or lack of liquid is detected. That is the sensor's stated behavior. The adapter does not measure flow rate, and we did not take new sensor measurements as part of the adapter work.
The XH2.54 board, by contrast, has two signal paths for serial communication. One device sends on its transmit line, TX, and the other receives on RX. Having the right connector does not make a UART sensor work on an I2C port: these are different ways of communicating.
Seeed's Grove interface documentation describes digital, analog, UART and I2C uses of the same connector family, and it labels UART from the base unit's point of view. That is a good reason to name both ends of each connection instead of writing only "connect TX."
Read the labels from both ends
On our UART adapter, M means the controller side and S means the sensor side. MRX receives what the sensor sends through STX; MTX sends to the sensor's SRX. A sensor's transmit pin therefore connects to the controller's receive pin. That naming is more reliable than assuming a particular wire color always means transmit.
The interface table for the FDE sensor states the direction plainly: sensor TX goes to host RX, sensor RX goes to host TX, with power and ground as separate connections.
Then the water-level sensor introduced a real complication. Its manual's cable-color table and the label on the hardware we had did not agree. We followed the label on the actual unit: red is VDD, black is GND, green is sensor TX and yellow is sensor RX. For that unit, green therefore goes to the host's RX and yellow to its TX.
Do not extend that color rule to every water-level sensor or later revision. When records disagree, identify the exact part and revision, photograph the label, and confirm the signal functions before powering the connection. Otherwise a helpful-looking wiring table can send debugging in the wrong direction.
A voltage regulator does not settle every voltage question
Both adapter schematics show an XC6206P332MR regulator taking a rail marked 5 V and producing a rail marked 3.3 V for the sensor side. The signal lines are routed straight between the connectors; the circuits do not include a general-purpose logic-level translator on those paths.
That is why a short description like "supports 3.3 V" needs context. Does it describe the voltage supplied to the sensor, the controller's logic, or the adapter's input? An LDO regulator needs voltage headroom. A schematic marked 5 V in and 3.3 V out is not evidence that feeding 3.3 V into the same input will produce a regulated 3.3 V output under load.
The distinction has confused other builders. In a September 2022 Seeed forum thread, a developer already receiving changing sensor readings still needed to work out which supply and input-voltage assumptions applied to the Wio Terminal. A changing value proved activity, but it did not answer the interface questions.
For your prototype, confirm the sensor supply at its connector, the sensor's output-voltage range, and the receiving pin's permitted range. If those do not match, a pin adapter alone is not enough. Likewise, a UART cable cannot turn an RS485 version of a sensor into a logic-level UART device; check the actual interface variant, not just the product family name.
Make a connection record someone else can follow
Before routing the cable into the enclosure, make a short map for the exact assembly:
- controller pin and adapter label;
- sensor function at the other end;
- supply voltage at the sensor connector;
- connector orientation;
- for UART, the baud rate and message format the sensor's driver expects.
Keep a photo of the sensor's own label with the map.
The soil sensor in the same family adds another naming variation: R means the sensor receives and T means it transmits, with minus for ground and plus for supply. So R goes to host TX and T to host RX. Mapping by function makes that variation straightforward. Copying positions or colors from an unrelated four-wire cable does not.
With power disconnected, check the cable routing against the map. Then verify the intended supply and signal levels before testing communication. Once the interface is established, a sensor-specific test can tell you whether the readings make sense. The adapter work alone provides no calibration, no measured communication error rate and no completed enclosure test.
If your prototype combines modules from several suppliers, start with photos of both cable ends, the exact sensor variants and the controller you plan to use. That is usually enough to decide whether you need a cable change, a small adapter, or an electrical interface redesign.