RS485 Breakout with 48 V Passthrough Building Block Board — Part 6

RS485 Breakout with 48 V Passthrough Building Block Board — Part 6#

Yesterday I had the opportunity to continue testing the RS485 breakout with 48 V passthrough building block board.

This round of testing covered both the 48 V power side of the board and the RS485 signalling side. Overall, the results were encouraging. The board behaved largely as intended, although I did identify a few errata that I can live with for this first batch and address properly in a second revision.

That is part of the point of these early building block boards. The first version is not only about proving that the core idea works, but also about finding the rough edges that only become obvious once the design exists as a real physical board.

Testing the 48 V Side#

Now that I have received the 48 V power supply, I was able to properly test the 48 V side of the board.

On the whole, this went well, with one important exception.

The first thing I wanted to verify was the reverse polarity protection on the main 48 V input. This protection is provided by a JMGK540P10A P-channel MOSFET on the J2 input terminal.

When 48 V was connected to J2 with the polarity reversed, the protection circuit behaved as expected. No voltage appeared on the downstream 48 V outputs:

• J5 — 48 V output
• J4 — secondary RS485 + 48 V terminal
• J3 — primary RS485 + 48 V terminal

When the 48 V supply was connected to J2 with the correct polarity, 48 V was delivered correctly to J5, J4, and J3.

So, from the point of view of protecting the main 48 V input against reverse polarity, the circuit worked as intended.

Backfeed Issue Identified#

A problem appeared when testing with a second connected board.

When 48 V was supplied through one of the RS485 + 48 V terminals, either J3 or J4, I observed that 48 V was also present back at the J2 input terminal.

That means if two boards are connected together and both have their own 48 V supplies connected to J2, there is a real possibility of one supply backfeeding into the other.

That is not behaviour I want in the long term.

Ideally, J2 should behave as the main power input only. If 48 V is being fed into the board through one of the RS485 + 48 V passthrough terminals, I would prefer J2 to be isolated or otherwise protected so that voltage is not driven back into an attached power supply.

This is not a catastrophic problem for the way I am currently testing the boards, but it is a useful design finding.

For a future revision, I need to think more carefully about the power routing and protection strategy. In particular:

• Should J2 be protected against backfeed from J3, J4, and J5?
• Should each 48 V terminal have its own reverse polarity protection?
• Should the board support multiple possible 48 V injection points, or should one terminal clearly be treated as the only valid power input?
• Should the passthrough terminals be protected with ideal-diode style MOSFET arrangements, Schottky diodes, or a simpler documented usage constraint?

At the moment, I am leaning towards improving the protection rather than relying entirely on documentation.

Reverse Polarity Protection on All 48 V Terminals#

The current board protects the main 48 V input, but not every possible 48 V entry point.

That was acceptable for this first version because J2 was intended to be the main supply input. However, the board also exposes 48 V on the RS485 + 48 V terminals to make daisy-chaining easier. Once a connector can deliver power out, there is always the possibility that it can also receive power in.

That makes the design slightly more complicated.

For a proper field-ready version, I may need to treat every 48 V terminal as a possible power entry point. That would mean protecting against:

• Reverse polarity on J2
• Reverse polarity on J3 and J4 if power is fed in through the RS485 + 48 V terminals
• Backfeeding into another connected supply
• Accidental connection of more than one 48 V source

This is a good example of where a board can be electrically correct for the expected use case, but still need refinement once more realistic usage scenarios are considered.

Current Assessment of the 48 V Side#

The positive result is that the main reverse polarity protection circuit works.

When power is applied correctly to J2, the 48 V rail is distributed as expected. When power is applied incorrectly to J2, the downstream 48 V outputs remain protected.

The errata is that the current design does not prevent 48 V from appearing back on J2 when the board is powered through one of the passthrough terminals.

For this first batch, I can work around that limitation by only using one 48 V supply in a connected chain and by being careful about how the boards are powered during testing.

For a future revision, I would like the board to be more robust and less dependent on careful usage.

RS485 Testing#

The RS485 testing was more straightforward.

This has made me think about creating an additional spin of the board: a simplified RS485 breakout without the 48 V passthrough side. That would give me another variant of the RS485 design for situations where a distributed 48 V supply is not required.

This time around I was testing serial communications over the RS485 section of the board. The setup consisted of:

• 2 x RS485 breakout boards
• 2 x USB-C + 3.3 V regulator breakout boards
• 2 x Raspberry Pi Pico 2 W boards
• 20 m of Cat6 cable
• Jumper wires

I configured one Raspberry Pi Pico 2 W as the transmitter and the other as the receiver. Each Pico was connected to one of the RS485 breakout boards, with the two RS485 boards connected together over approximately 20 m of Cat6 cable.

The aim at this stage was simple: confirm that basic UART serial communication would work over the RS485 link.

I uploaded the following MicroPython script to the transmitter Pico:

from machine import UART, Pin
import time

# Configure UART
uart = UART(0, baudrate=9600, tx=Pin(0), rx=Pin(1))

# Define the Driver Enable / Receiver Enable pin for RS485
de_re = Pin(2, Pin.OUT)

# Send data
while True:
    de_re.value(1)  # Enable transmit
    message = "Take me to your leader!!!"
    uart.write(message.encode("utf-8"))
    uart.flush()
    time.sleep(1)

I then uploaded the following script to the receiver Pico:

from machine import UART, Pin
import time

# Configure UART
uart = UART(0, baudrate=9600, tx=Pin(0), rx=Pin(1))

# Define the Driver Enable / Receiver Enable pin for RS485
de_re = Pin(2, Pin.OUT)

# Set board into receive mode
de_re.value(0)
print("Waiting for data...")

while True:
    if uart.any():
        data = uart.read()
        try:
            decoded_text = data.decode("utf-8")
            print("Received Raw: ", data)
            print("Decoded Text: ", decoded_text.strip())
        except UnicodeError:
            print("Received data, but couldn't decode it as UTF-8.")

    time.sleep(0.1)  # Small delay to avoid hogging the CPU

These were deliberately simple scripts. The goal was not to implement a complete protocol, but to confirm that the hardware could pass basic serial data over the RS485 link at 9600 baud.

The test worked as expected. With Thonny connected to the receiver Pico, I was able to observe the received data in the debug output.

I still need to test higher-speed communication when I get back to the bench, but this was a positive first result.

Lessons So Far#

This round of testing has been useful because it has shown that the board is broadly heading in the right direction, while also highlighting one area that needs more design attention.

The important lesson is that passthrough power changes the design problem.

If a board only has one power input, protection can be relatively straightforward. Once power can move through the board and appear on multiple connectors, the board needs to be designed with backfeed paths, multiple supplies, and incorrect connection scenarios in mind.

That does not make the idea wrong. It just means the next revision needs a slightly more deliberate power architecture.

The RS485 side, on the other hand, has shown encouraging results. Basic serial communication over approximately 20 m of Cat6 cable worked using two Raspberry Pi Pico 2 W boards and a pair of RS485 breakout boards.

For now, the board remains useful as a prototype and test platform. The 48 V polarity protection on the main input works, the passthrough concept works, and the RS485 side has now passed a basic communication test.

The next step is to test the RS485 side at higher baud rates, try longer cable runs, and then decide how much additional 48 V protection should be built into the second revision.

If you are looking for reusable open hardware modules to speed up your bench testing, or need support designing custom breakout circuits, check out our catalog at Protoworks (NI).