Ten times the bandwidth can cost you eight times the PHY latency. That result, from TI's characterisation of single pair Ethernet PHYs, is the single most useful thing to know before choosing the network that runs down the inside of a robot arm. Bandwidth and determinism are separate properties, and control loops care about the second one.
The measurement
Take a host and ten daisy chained subsystems, each receiving a frame, retransmitting it, and passing it along. Frame size 76 bytes, 64 of payload and 12 of overhead. TI tabulates PHY latency, MAC latency and frame serialization time per hop [1]:
| Link | PHY latency | MAC latency | Frame serialization | TI's per hop total |
|---|---|---|---|---|
| 100BASE-T1 | 860 ns | 480 ns | 5666 ns | 7006 ns |
| 1000BASE-T1, error correction enabled | 6900 ns | 320 ns | 566 ns | 7996 ns |
| 1000BASE-T1, error correction bypassed | 920 ns | 250 ns | 566 ns | 2016 ns |
Across ten subsystems and back, half duplex with each packet fully received before retransmit, TI's cycle times come out at 140.12 µs for 100BASE-T1, 158.92 µs for gigabit with error correction running, and 40.32 µs for gigabit with it bypassed [1]. TI's two tables disagree by 50 ns on the gigabit hop, 7996 ns in the per hop breakdown against 7.946 µs in the cumulative table; the cycle times follow the second, and we quote both as printed.
Read the middle row carefully. Gigabit with its Reed Solomon encoder enabled is slower end to end than the 100 Mbps link. Our arithmetic on TI's cells: the encoder accounts for about 6.0 µs of the gigabit PHY's 6900 ns, since the same PHY measures 920 ns with the block bypassed, while the serialization saving on a short control frame is only about 5.1 µs. The per hop penalty lands just under 1 µs, and it accumulates at every joint.
The trade that actually matters
Gigabit only wins when you bypass the forward error correction, which takes the loopback from 158.92 µs to 40.32 µs [1].
That is the argument worth having, because forward error correction is exactly what you want in the environment this cable runs through. The cable sits inside a manipulator next to three phase inverters switching at 8 kHz to 32 kHz [3], and IEC 61000-4-4 simulates the switching phases of a motor [1]. Bypassing error correction to buy determinism means giving up bit error resilience in the noisiest place you could have put the link. There is no clean answer, only a measurement you owe yourself on your own harness before committing.
Sizing against the control loop
A torque loop at 32 kHz has a 31.25 µs period [3]. TI's worked example puts seven to ten subsystems on one daisy chain down a robot arm [1].
TI rates all three cycle times as typically fast enough for the application [1]. The torque loop is where we would push back. The fastest configuration in TI's table, 40.32 µs for a full loopback through ten nodes, does not fit inside a 31.25 µs control period. It fits comfortably at 16 kHz, and at 32 kHz only if that chain is not in the torque loop path, meaning position feedback and current control stay local to the joint while the network carries setpoints and telemetry.
That is the real conclusion. The network latency budget decides whether your control loop closes locally in the joint or centrally in the torso, and it is worth deriving before choosing a PHY rather than after. It is also why our own drive closes the current loop on the board and treats the bus as a setpoint channel.
Why cable count is not the strongest argument
The obvious pitch is wiring. One pair carries 100 Mbps over 50 m unshielded or 100 m shielded, or 1000 Mbps over 15 m unshielded and 40 m shielded, against RS-485 at 20 Mbps over 40 m, CAN at 1 Mbps over 40 m, or standard Ethernet needing two to four pairs [1]. RS-485 is not going away for slower links: TI's THVD1424 and THVD1454 reach 256 nodes at one eighth unit load with switchable 120 Ω termination on chip [2], which is a good answer for sensor and auxiliary traffic. Fewer conductors means a thinner cable tree.
The better argument is maintenance. A manipulator cable tree is typically replaced every two to three years on the assumption of ageing, without anyone testing whether the cable actually failed [1]. TI's PHYs in this class carry built in diagnostics including time domain reflectometry, signal quality indication and self test with pseudorandom sequences [1]. That turns calendar based replacement into condition based replacement, and a scheduled production stop into an event you see coming.
The coupling decision that is not about size
For decoupling the PHY from the bus, the choice is galvanic or capacitive. TI's area and cost comparison for a 100BASE-T1 link is counterintuitive [1]:
| Galvanic | Capacitive, 100 V | Capacitive, 2 kV | |
|---|---|---|---|
| Total component area | 126 mm² | 236 mm² | 344 mm² |
| Normalised cost | 1.0 | 0.7 | 0.68 |
| Maximum component height | 2.9 mm | 2.8 mm | 2.8 mm |
Galvanic coupling is smaller and costs more, which inverts the usual assumption. The capacitive version needs a larger common mode termination and larger decoupling capacitors, and if you are building to IEC 62368-1 those capacitors want a 1.5 kV rating [1].
The result that settles it is not the table. In TI's initial EMC tests the capacitive coupled link dropped, while the galvanic link stayed up with minimal packet loss and achieved performance criterion A with no bit errors [1]. Capacitor mismatch leaves the capacitive circuit sensitive to noise [1], and a motor drive is a noise source by construction.
The liability nobody prices
One caveat that should temper the whole enthusiasm. As of TI's January 2024 revision, no common industrial protocol had been finalised for use over a single pair Ethernet physical layer, although standardisation efforts were ongoing and systems were already on the market [1].
So the 40 µs determinism number is achievable and unbankable at the same time. You either write a proprietary stack or adopt something unstandardised, and either way you own the interoperability and certification burden that a mature fieldbus would have carried for you.
For a vertically integrated robot where one company builds every joint, that cost is acceptable and the benefits are immediate. For anyone intending to sell joint modules into someone else's robot, the protocol gap is the real adoption barrier, and it is not a silicon problem.
References
- Texas Instruments, How and Why to Use Single Twisted-Pair Ethernet (SPE) for Industrial Robotics Environments, SNLA420A, September 2022, revised January 2024.
- Texas Instruments, Reduce System Design Time and Cost with Flexible RS-485 Transceivers, SLLA595C, March 2023, revised June 2023.
- Texas Instruments, An Engineer's Guide to Industrial Robot Designs, SSIY006, 2Q 2020, chapters 1 and 2.