article / 13 min
Set up your FRC robot radio and networking right: the VH-109, the 10.TE.AM.x IP scheme, the 2026 direct-wire power change, and fixing connection drops.
/ 2,848 words / 10 sections
Every wireless thing your robot does on the field — driver control, dashboard telemetry, camera streams, that fancy coprocessor pipeline — rides on one small box bolted to your frame: the radio. When it's set up right, you forget it exists. When it's set up wrong, you get the two worst words in FRC: "no communication." Most of the connection problems teams blame on code or the field are really networking problems, and networking on an FRC robot is more learnable than it looks.
This guide walks through the current (2026) FRC radio and networking stack from the ground up: what the radio does, how you configure and flash it, the 10.TE.AM.x IP scheme that ties every device together, how to wire the radio for power (including the shift away from the old barrel-jack setup), and how to get your driver station and coprocessors talking. Specs on this hardware change year to year, so treat the exact numbers here as a map and confirm the live details against the WPILib docs and the official FRC Radio documentation before you commit.
The radio is your robot's wireless bridge. On one side it holds an Ethernet link to the roboRIO (your robot controller); on the other it broadcasts a Wi‑Fi network that your driver station laptop joins. Everything the two ends say to each other — joystick values going out, battery voltage and match state coming back, NetworkTables traffic, camera frames — passes through it.
It is also a small router. It runs a DHCP server that hands out IP addresses to devices that ask, and it enforces the addressing scheme the field expects so that 40+ robots can run on the same venue without stepping on each other. When you're tethered in the pit it's just your robot's private network; when you're on the field, the Field Management System (FMS) takes over the wireless side and the radio switches to talking to the field's access points instead of broadcasting its own.
The radio is not the same thing as the roboRIO. The roboRIO runs your code; the radio moves the packets. If your driver station connects but your code never starts, that's a roboRIO/code issue, not a radio one — see No robot code? Driver Station troubleshooting.
If you want the full picture of how the radio fits alongside the roboRIO, PDH, and driver station, the FRC control system explained walkthrough is a good companion to this one.
For years FRC ran on an OpenMesh OM5P‑AC access point flashed with FRC firmware. That radio has been replaced by the VH‑109, a purpose‑built FRC radio from Vivid‑Hosting. If your program is coming back after a couple of seasons away, this is the single biggest hardware change to plan around — the mounting, the power wiring, and the configuration flow are all different from the OM5P‑AC.
A few things worth knowing about the VH‑109:
Because it's newer hardware, minimum firmware versions and exact configuration screens move over time. Assume any specific version number you read — including in this article — may have advanced, and check the current requirement on the official FRC Radio docs before an event.
Configuring the VH‑109 means telling it your team number and setting up its network. There are two contexts where this happens, and they work differently.
To program the radio yourself:
http://radio.local/. If mDNS name resolution isn't cooperating on your machine, you can give your laptop a static IP on the radio's configuration subnet and reach the dashboard by its numeric address — the FRC Radio docs list the exact fallback address to use.Program and test your radio before your first event, not the morning of. A radio that won't take a configuration is a much calmer problem to solve on your bench than in the queue line.
At an official event you generally do not hand‑configure the radio. There's a provided kiosk computer that flashes your radio with the event's settings and your team number for you — it programs the radio's static 10.TE.AM.1 address and the field credentials in one shot. Your job is to bring a robot whose radio is wired correctly and physically accessible, drop it on the kiosk, and get it programmed during load‑in. If you've been driving at home in Access Point Mode, the kiosk flip back to field mode is automatic as part of that process.
FRC uses a predictable private IP scheme built around your team number so that every robot's network looks structurally identical. The magic phrase is 10.TE.AM.x. You build the middle two octets from your team number by taking the last two digits as AM and everything before that as TE.
Some worked examples make the rule obvious:
10.16.78.x10.2.54.x10.0.12.x10.34.56.xOnce you know your prefix, the rest of the addresses fall into fixed slots. Using team 1678 (10.16.78.x) as the running example:
| Device | Address | How it's assigned | Notes |
|---|---|---|---|
| VH‑109 radio | 10.16.78.1 | Static, set by the field kiosk / your config | Always the .1 of your subnet |
| roboRIO (Ethernet) | 10.16.78.2 | DHCP from the radio, or static | Static in the .2–.19 band is common |
| Driver Station laptop | 10.16.78.20–.199 | DHCP from the radio | Field hands it an address in this pool |
| Coprocessor (Pi / Jetson / Limelight) | 10.16.78.11 (example) | Static, chosen in .2–.19 | Pick an unused low address |
| Field network (reserved) | 10.16.78.3, 10.16.78.4 | Reserved by FMS | Don't assign these yourself |
| roboRIO over USB | 172.22.11.2 | Fixed | Same for every team; USB tether only |
Two ranges matter most. The radio's DHCP pool runs from .20 to .199, so any device you configure for DHCP lands there automatically. If you assign static IPs, keep them in the .2 to .19 band and subnet mask 255.255.255.0, so they never collide with a DHCP‑assigned device on the field.
You rarely need static IPs anymore. WPILib resolves devices by mDNS hostname — your roboRIO answers to
roborio-1678-frc.local(swap in your number). Coprocessors are the main reason to reach for static addressing, because a fixed IP is easier to point vision code at than a hostname that has to resolve first.
That 172.22.11.2 in the table is worth memorizing: when you plug a USB cable straight from your laptop into the roboRIO, the roboRIO is always at 172.22.11.2, on every robot, regardless of team number. That's your lifeline when the radio or Wi‑Fi is misbehaving and you just need to reach the roboRIO to fix it.
Here's the part that trips up returning teams. The old OM5P‑AC radio was powered through a barrel‑jack connector, typically fed 12V passive PoE from the Voltage Regulator Module (VRM). The VH‑109 does not work that way. There's no barrel jack. You wire it directly into robot power.
The VH‑109 gives you two power inputs:
12V terminals.The recommended setup uses both at once — 12V DC and PoE — so the radio has a redundant power path. If one connection shakes loose mid‑match, the other keeps the radio alive. On a REV PDH, the typical guidance is to feed the radio from a non‑switchable fused channel with a 10A fuse; on a CTRE PDP you land it on one of the dedicated always‑on terminal pairs. Because the exact channel and fuse guidance can be revised, confirm the current recommendation on the official FRC Radio wiring page before you build.
The VH‑109 tolerates a range above 12V (up to roughly 19V per the docs), but do not power it from two different sources at once. In particular, do not feed it from both a REV Radio Power Module (RPM) and the 12V input simultaneously — the docs warn this can damage the radio. Pick your power path and stick to it.
The radio's Power‑over‑Ethernet output is off by default. If you're powering a downstream device (like a switch or a camera) through one of the radio's AUX ports, you have to flip the small PoE‑enable switch on the bottom of the radio for that port — otherwise the port carries data but no power.
Two practical build notes. First, mount the radio where you can reach its ports and status LEDs without disassembling the robot — you'll be plugging the kiosk and your laptop into it repeatedly. Second, strain‑relieve every connection; a radio that loses power or Ethernet when the robot gets hit is the single most common cause of mid‑match dropouts. For the broader power‑distribution picture, the how to wire an FRC robot guide covers where the radio sits relative to the PDH, main breaker, and roboRIO.
With the radio configured and powered, the driver station connection is mostly automatic:
10.TE.AM.20–.199 range.roborio-TEAM-frc.local under the hood.If Communications is red, the problem is between the laptop and the roboRIO (Wi‑Fi, radio, or IP). If Communications is green but Robot Code is red, the network is fine and the issue is your program. Keeping that distinction straight saves a lot of wasted debugging; the driver station troubleshooting guide goes deep on reading those indicators.
Vision coprocessors — a Raspberry Pi, an NVIDIA Jetson, a Limelight, a Photon setup — join the robot network as just another device on your 10.TE.AM.x subnet. You have two ways to plug them in:
Give the coprocessor a static IP in the .2–.19 range (say 10.16.78.11) so your robot code always knows exactly where to reach it. That's cleaner than relying on hostname resolution for a real‑time vision feed. Note that a coprocessor talks to the roboRIO over Ethernet, not the CAN bus — CAN is for motor controllers and sensors, and if you're wiring those, the FRC CAN bus guide covers that side of the robot.
On the field, coprocessor traffic shares the same limited wireless bandwidth as everything else. Keep camera stream resolution and framerate modest, and do heavy vision processing on the coprocessor — send the roboRIO small results (a target angle, a distance), not raw video.
When the connection drops, work the chain from the robot outward. Most dropouts are physical, not mysterious.
172.22.11.2) to confirm the roboRIO and your code are alive independent of the radio. If USB works and Wi‑Fi doesn't, the problem is downstream of the roboRIO — radio, IP, or Wi‑Fi..2–.19.FRC uses the VH‑109 radio from Vivid‑Hosting, which replaced the older OpenMesh OM5P‑AC access point. It's a dual‑band FRC‑specific radio configured through a web dashboard rather than a desktop flashing tool.
Take your team number, use the last two digits as the third octet and the digits before that as the second octet, in the form 10.TE.AM.x. Team 1678 is 10.16.78.x; the radio is .1, and your roboRIO and driver station take addresses on that subnet.
172.22.11.2 is the fixed address the roboRIO uses over a direct USB tether — it's the same for every team. Your 10.TE.AM.x address only applies over the Ethernet/Wi‑Fi path through the radio. USB is your reliable backup when the wireless side is down.
No barrel jack. The VH‑109 is wired directly into robot power: 12V from the PDH/PDP through its Weidmuller connector, and/or passive Power‑over‑Ethernet on the RIO port. Running both together gives you a redundant power path. Don't power it from two different sources (like an RPM and 12V) at once.
Usually not for the roboRIO and driver station — WPILib finds devices by mDNS hostname (roborio-TEAM-frc.local). The main reason to set a static IP is a coprocessor, where a fixed address in the .2–.19 range makes vision code easier to point at.
No. At an official event a provided kiosk computer flashes your radio with your team number and the field settings during load‑in. You configure the radio yourself only for home and pit use; make sure it's programmed and tested before you arrive.
Get the radio wired cleanly, learn your 10.TE.AM.x prefix, and keep a USB cable in your pit for the days Wi‑Fi lets you down — that's 90% of FRC networking handled. The exact firmware versions, fuse channels, and configuration screens will keep evolving with the hardware, so make a habit of checking the official FRC Radio and WPILib docs at the start of each season and before every event. If you want the rest of the control system to make the same kind of sense, the guides pick up from here.
where this came from
This article is AI-assisted: drafted from primary sources, then reviewed and edited by hand. Errors still get through. When one is reported we fix it and write down what changed, in public, in the corrections log.
dept / electrical-wiring
You came for one answer. These teach the same subject properly, in the order a team actually learns it. All 35 are free, and none of them need an account to read.
if you want to keep the ticks
Pit problems repeat. A free account lets you bookmark troubleshooting guides and checklists so they are one tap away at competition.
Create a free accountReading never needs one. This is only for saving where you got to.
these are the closest, not the newest
13 min read
Decode every FRC status light: roboRIO, PDH/PDP, SPARK MAX, Kraken/Talon FX, CANcoder, VH-109 radio, plus Driver Station error codes. Verified against.
read it13 min read
Image, set up, and wire the roboRIO 2.0 and 1.0: the roboRIO Imaging Tool workflow, microSD flashing, team number, I/O ports, power, and deploying code.
read it7 min read
A verified, step-by-step FRC troubleshooting decision tree for "No Robot Code" and a Driver Station that won't connect to the roboRIO — most common causes first.
read itend of sheet
Keep going with the other 102 articles, or work through all 394 lessons across 11 departments.