<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>RS-485 on Intent</title>
    <link>https://intent.me/en-us/tags/rs-485/</link>
    <description>Recent content in RS-485 on Intent</description>
    <generator>Hugo -- 0.155.1</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 21 Sep 2026 12:00:00 +0800</lastBuildDate>
    <atom:link href="https://intent.me/en-us/tags/rs-485/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Modbus RTT Jitter at 30–80 ms: Gateway Measured 1–4 ms — the Root Cause Was the Test Bench</title>
      <link>https://intent.me/en-us/blog/tech/modbus-rtt-loopback-benchmark/</link>
      <pubDate>Mon, 21 Sep 2026 12:00:00 +0800</pubDate>
      <guid>https://intent.me/en-us/blog/tech/modbus-rtt-loopback-benchmark/</guid>
      <description>An industrial gateway (TI AM64x, Linux PREEMPT_RT) measured 30–60 ms Modbus-TCP RTT and 50–80 ms RTU jitter against a Windows simulator. After correcting the measurement semantics and running a three-step orthogonal isolation loopback (localhost → dual-NIC netns direct link → dual RS-485 crossover), the jitter is attributed to the test peer under these test conditions: board-side pure software stack 0.69 ms, physical NIC 1.02 ms, serial 4.15 ms (wire time about 70%); peer-side interventions such as the FTDI Latency Timer pinned the Windows bench&amp;rsquo;s measured lower bound at 45–50 ms, from which a reference timeout baseline is derived; a single gateway transaction consumes roughly 1%–15% of the end-to-end link budget — not a blocker.</description>
    </item>
  </channel>
</rss>
