top of page

The Best $20 Investment I Ever Made in: USB to RS-485 Adapter

  • Writer: Alex Khachaturian
    Alex Khachaturian
  • Oct 29
  • 9 min read

Updated: Nov 3

USB to RS-485 adapter on stacked US bills. Adapter is black with green terminals.

Promise: This tiny adapter turns your laptop into an MS/TP & Modbus stethoscope, so you stop guessing, start reading the line, and fix problems in minutes.


TL;DR

  • A USB-to-RS-485 adapter lets you capture BACnet MS/TP and Modbus RTU directly from the trunk.

  • With one 5-minute capture, you can prove baud mismatches, duplicate MACs, bad terminations, VFD noise, and slow token cadence.

  • It pays for itself the first time you convert an argument into a screenshot.


Key Takeaways

  • Visibility beats opinions: frames don’t lie.

  • Tap in parallel (don’t break the loop), match baud, and keep stubs short.

  • Add a 3-pin screw-terminal breakout, labeled pigtails, and a 120-Ω for bench rigs.

  • Use mstpcap → Wireshark to see token flow, PFM bursts, retries, and MAC offenders.

  • Tighten Max Master, fix polarity/termination/bias, and stop the “mystery” dropouts.


Quick Links


Next Read



Story: The day “lucky” became repeatable

The first time I used this thing, I didn’t even know what to call it. I just knew my network was haunted, devices dropping, commands landing late, alarms that came and went like bad radio static. Someone had mentioned a program called Ethereal (it would later become Wireshark) that could “see” what was passing along the wire. That sounded like a myth… but I was desperate to stop guessing.


Back then, the field sorted itself into two tribes:

  1. The techs who waited for someone else to tell them what broke.

  2. The techs with backpacks full of twisted, beat-up cables—nulls, swaps, gender changers, 3-pin pigtails with electrical tape and Sharpie labels. If you knew, you knew. The cable pouch was your résumé.


There wasn’t a clean way, at least not one I knew, to simply watch the token on an MS/TP trunk. So I did what we all did before YouTube tutorials and slick vendor portals: I went digging. HVAC-Talk threads, ancient PDFs, and the old Schneider Electric “Lessons Learned” pages (which would evolve into a real community). Buried in those posts was a blip about tapping the RS-485 line with a USB doodad and pushing the bytes into a serial-to-pcap converter so Ethereal/Wireshark could make sense of it.


I ordered the adapter, printed a pinout, and showed up at 6:30 a.m. before anyone else. That job had a trunk that “felt” wrong, like a song with a drummer lagging half a beat. I landed A/B/COM on a tiny screw-terminal breakout, parallel tapped the line, matched baud by guess-and-check, and hit Start.


Then it happened.


Frames. Tokens. Poll-For-Master pings I didn’t even know existed. A MAC address that was way too chatty for its role. The network went from superstition to subtitles. I could see the moment the token got stuck, the retries spiked, and the whole dance fell out of rhythm. Ten minutes later, I had a screenshot that ended a week of arguments. “Replace that VFD comm card. Here’s the MAC. Here’s the timestamp. Here’s the pattern.”


That single morning rewired how I troubleshoot. The adapter stopped being a $20 trinket and became a translator. It turned the “feel” of a bad network into evidence, repeatable, teachable, defensible. It made my rat’s-nest pouch of custom cables feel like a relic from a different era. The forums were right: if you can see the line, you can fix the line.


Years later, the stack has better tools, drivers are cleaner, and Wireshark can dissect MS/TP like it was born for it. But the core lesson hasn’t aged a day: when you clip onto a trunk and watch the token hand off in real time, you stop chasing ghosts. You find the one device stepping on toes and you show your team, your PM, and your customer why.


That’s the moment “lucky” became repeatable, and a $20 adapter became one of my best investments.


Quick Win: first capture in 5 minutes

  1. Parallel tap at any controller on the segment (don’t break the loop). Land A/B/COM via a 3-pin breakout and short pigtails.

  2. Polarity: Keep the site’s convention, A(–) with A, B(+) with B. If you see nonsense, you can try one swap.

  3. Baud: Match the segment (common: 19 200 / 38 400 / 76 800).

  4. Capture: Use mstpcap to record serial → pcap, then open in Wireshark.

  5. Watch the token: healthy cadence = steady Token(0) with sparse PFM(1) and consistent data bursts.

  6. Screenshot when the symptom appears (PFM storm, duplicate MAC behavior, retries). That image gets approvals.


Mid-post Subscribe: Want the exact columns/filters + printable checklist? Join free, new plays each Monday.


Recommended Gear



Playbook: BACnet MS/TP from plug-in to proof

1) Physical layer (do this clean)

  • Topology: True daisy-chain, no stars/tees. Keep stubs inches long.

  • Cable: Shielded twisted pair (22–24 AWG), low capacitance, ~100–130 Ω impedance.

  • Shield: Bond one end to ground (usually controller/router). Don’t bond both, avoid loops.

  • Bias & termination: One bias point per segment; 120-Ω at each physical end. Don’t scatter extra terminations “just because.”


2) Safe tapping (live systems)

  • Parallel tap under the same screws as existing conductors or via Wagos.

  • Never cut the trunk inline on a live system to “insert” your adapter.

  • Polarity must follow the site standard end-to-end. Different vendors swap A/B naming, trace terminals, not labels.


3) Communications parameters

  • Baud: Common values are 9 600, 19 200, 38 400, 76 800 (verify in controller/router).

  • Framing: 8-N-1 for BACnet MS/TP.

  • MAC addressing: Know expected range and Max Master. If the segment’s top MAC is 43, set Max Master to ~48, not 127.


4) Software setup

  • Drivers: Confirm the adapter enumerates as a COM port (Windows Device Manager).

  • mstpcap (offline capture)

    • Open terminal in your working folder.

    • Run:

  • mstpcap.exe COM4 76800

    • (Replace COM & baud as needed.)

    • Hit Ctrl+C to stop; you’ll have a .pcap.

  • Wireshark (live via extcap)

    • Place mstpcap.exe in Wireshark’s extcap folder.

    • It shows up as a capture interface; pick COM & baud, click Start.


5) Wireshark columns, set these once

  • mstp.src (Source MAC)

  • mstp.dst (Destination MAC)

  • mstp.frame_type (0=Token, 1=PFM, 2=ReplyToPFM, 5=DATA+Reply, 6=DATA No Reply)

  • frame.time_delta_displayed (gap between frames, your latency/jitter proxy)

  • Optional (on IP captures): bvlc.function, bacnet.hopc (BBMD/hop behavior)


6) Core display filters

  • All MS/TP: mstp

  • PFM/reply storms: mstp.frame_type == 1 || mstp.frame_type == 2

  • Confirmed app data only: mstp.frame_type == 5

  • Unconfirmed data (COVs, who-is): mstp.frame_type == 6

  • IP side (if you’re also on BACnet/IP): bacnet || bacapp || bvlc


7) Read the dance

  • Healthy cadence: Token(0) passes predictably, data frames (5/6) cluster near the token holder, PFM(1) appears sparingly (about every 50 tokens).

  • Red flags: long time-deltas, bursts of PFMs, repeated token re-claims, one MAC hogging talk time, spikes in retries/CRC errors.


8) Create proof, not prose

  • While reproducing the symptom (e.g., command delay), capture 1–3 minutes.

  • Filter to the window, highlight the pattern and offending MAC.

  • Screenshot the frame list (show columns), add one-line:

    • “PFM burst after token at MAC 41; retries spike; duplicate MAC suspected with 37.”

  • Paste into your ticket with Symptom → Cause → Fix + estimated material/labor. Approvals happen fast when you show the picture.


USB to RS-485 Adapter With Modbus RTU (same adapter, different rules)

Electrical layer: Still RS-485 2-wire half-duplex. Same topology/termination/biasing discipline.


Serial settings (must match)

  • Baud: 9 600 / 19 200 / 38 400 (sometimes 57 600)

  • Framing: Often 8-E-1 (Even parity), sometimes 8-N-1.

  • IDs: Each slave must have a unique address; masters poll, slaves reply.


Procedure

  1. Parallel-tap A/B/COM as above.

  2. Confirm baud & parity in the gateway or device.

  3. Use a simple master (e.g., vendor config tool or modpoll) to read a few Holding Registers from a known good slave.

  4. If you see timeouts/CRC errors, suspect A/B swap, wrong parity/baud, missing termination, or duplicate IDs.

  5. Log request/response timing and exception codes; screenshot the master tool’s status window to prove cause (bad device, wiring fault, or parameter mismatch).


Field tells

  • Even one wrong parity bit makes everything look “dead.” Double-check parity first.

  • VFD EMI wreaks havoc: route away from power leads, keep shield integrity, add ferrites if needed.


What “good” vs “bad” looks like

Good MS/TP

  • Token rhythm is consistent: 0 (Token) → 5/6 (data) bursts → 0 … occasional 1 (PFM).

  • frame.time_delta_displayed is tight across cycles.

  • mstp.src cycles through legitimate masters without one node hogging.


Bad: PFM/Reply storms (lost token)

  • Many frame_type 1 / 2, re-claims, and erratic cadence.

  • Likely termination/bias issues, severe baud mismatch, duplicate MAC, or a slow device missing turn windows.

  • Fix: Correct baud, tidy termination/bias, remove duplicate addresses, replace or isolate the slow/chatty node.


Bad: Garbage/silence

  • Immediately on start, frames are nonsense or nothing appears.

  • Fix: Verify baud and A/B polarity; confirm adapter COM and enumeration. Test on a bench loop.


Bad: Intermittent bursts + long quiet gaps

  • Classic reflection/EMI pattern; often tied to long stubs, missing EOL, or cables near VFDs.

  • Fix: Restore proper EOL/bias, shorten stubs, reroute, bond shield at one end.



Bad: One MAC “attracts” retries

  • Shows up in repeated confirmed data retries to/from the same MAC.

  • Fix: Check that device (firmware/comm card), verify address uniqueness, tighten Max Master to actual highest MAC.



Bad: Router/BBMD side effects (hybrid networks)

  • On IP, you see excessive Forwarded NPDU traffic or low hopc values; on MS/TP, pacing feels heavy.

  • Fix: Treat as routing config/loop issue upstream, not an MS/TP wiring fault; adjust BBMDs/netmasks/hops and re-test.


Troubleshooting (Symptom → Cause → Fix)

Symptom: Random devices drop off the bus.

Cause: Weak/missing termination or single-point bias; EMI near drives; long stubs.

Fix: Verify EOL at ends, confirm single bias source, shorten stubs, reroute away from VFDs, add ferrites if needed.


Symptom: Commands lag 5–10 seconds.

Cause: Token delays from duplicate MACs, low baud with too many nodes, or a slow device.

Fix: Eliminate duplicate MAC; raise baud (if all support it); reduce Max Master to realistic top MAC; repair/replace the slow node.


Symptom: New VFD went in and comms got weird.

Cause: A/B landed wrong, shield floating both ends, EMI coupling into RS-485.

Fix: Correct polarity, bond shield one end, increase separation from power leads, add ferrites; as a last resort, isolate via repeater.


Symptom: Total silence, I see nothing.

Cause: Wrong baud/parity (Modbus), wrong baud (MS/TP), adapter not enumerated.

Fix: Confirm COM & settings, test on bench loop, then return to site segment.


Symptom: PFM bursts every few seconds.

Cause: Token re-creation from noisy line, oversize Max Master on a small trunk, or marginal device missing turn windows.

Fix: Fix line noise/termination; set Max Master close to actual top MAC; swap out the suspect device.


Symptom: Modbus master timeouts.

Cause: Wrong parity or ID conflict; missing terminator; tiny response-timeout.

Fix: Set parity correctly (often Even), ensure unique IDs, add EOL, lengthen timeout to spec.


Symptom: Router to IP ‘feels heavy.

Cause: BBMD flood/loop or improper hop counts.

Fix: Verify single BBMD per subnet, correct BDT/FD tables, right hops; confirm relief on MS/TP cadence.


FAQ

Why FTDI-based adapters?

Stable drivers, odd-baud support, reliable enumeration. Other chipsets can work; FTDI avoids drama.


Can I break the loop and wire inline?

Not live. Parallel tap for diagnostics; build a proper terminated/biased loop on the bench.


How do I find baud without hunting?

Read the controller/router properties. If not accessible, take one short hunt pass (19.2 → 38.4 → 76.8) and stop.


How many terminations?

Exactly two, physical ends of the segment. Bias once.


Do I land COM/REF?

Yes. RS-485 needs a reference. Land COM/REF when provided; never float shields at both ends.


Is this only for BACnet?

No. Modbus RTU benefits equally (you’ll use a master tool for requests; the adapter/discipline is the same).


What’s a good first fix when everything looks “off”?

Polarity, baud, EOL/bias, Max Master. Then address duplicates or the misbehaving MAC.


Field Checklist

  • USB-to-RS-485 (FTDI) + 3-pin breakout + labeled pigtails

  • Parallel tap (don’t break loop), verify A/B/COM, shield bonded one end

  • Match baud (MS/TP 8-N-1; Modbus often 8-E-1)

  • mstpcap capture (or extcap live) → open in Wireshark

  • Columns: mstp.src, mstp.dst, mstp.frame_type, frame.time_delta_displayed

  • Filters: mstp or mstp.frame_type == 1 || mstp.frame_type == 2

  • Annotate Symptom → Cause → Fix with MAC/time; screenshot for approvals

  • Post-fix mini-capture to prove clean token cadence


Results & ROI

  • Time saved: 30–90 minutes per “weird comms” call.

  • Callbacks: Drop by 1–2/month when you replace opinions with packet evidence.

  • Approvals: Screenshots compress decision time from days to minutes.

  • Training: Juniors level up fast with a repeatable capture routine.

  • Hard math: At $150/hr billable, the adapter pays for itself in <10 minutes.


Wrap-Up

If you buy one thing this quarter, buy the USB-to-RS-485 adapter and build a tiny kit around it (3-pin breakout, labeled pigtails, two 120-Ω, a couple Wagos). Then run a 5-minute capture on the next site that “feels off.” Frames will tell you who’s guilty. Fix it. Screenshot it. Move on.

The day I learned to read the line, my career accelerated. Yours will, too.

Comments


bottom of page