FRC Status Lights & Blink Codes: The Complete Decoder

Every status light on an FRC robot is a free diagnostic. The problem is that four vendors invented four different color languages, so "blinking orange" means healthy, waiting to be enabled on a Kraken X60 and something is wrong on a SPARK MAX. That mismatch is why pits waste twenty minutes chasing a motor controller that was never broken.

This page collects the current vendor-documented codes for the devices actually on your robot: the roboRIO, the REV PDH and CTRE PDP, SPARK MAX and SPARK Flex, Talon FX / Kraken / Talon FXS and CANcoder, the VH-109 radio, and the Driver Station's own indicators and error strings. Every table below was checked against the vendor's own documentation on August 6, 2026 — WPILib's Status Light Quick Reference, REV's SPARK MAX and SPARK Flex status-LED pages, CTR Electronics' Phoenix 6 stable hardware reference, and Vivid-Hosting's LED status page. Where a vendor and WPILib disagree, I say so instead of quietly picking one.

Before any table, one habit worth more than memorizing colors: read lights in dependency order — power, then roboRIO, then radio, then CAN devices. A Kraken blinking red because it "does not have a valid CAN signal" is not a Kraken problem if the roboRIO's Power LED is amber. The 60-second triage order near the bottom of this page is that habit written down.

Start at the roboRIO

The roboRIO has five indicators, and between them they tell you which half of the robot is broken.

Power LED

Amber is the one that ends matches. Red is different and more specific: it points at a short on the 6V / 5V / 3.3V user rails, which usually means a sensor got pinched or a servo is wired backwards — not a battery problem.

Status LED — this one is a count, so watch it for a few seconds before deciding.

Comm LED

Mode LED: off = outputs disabled (disabled, brownout, etc.), orange = autonomous enabled, green = teleop enabled, red = test enabled.

Radio LED: WPILib's reference lists this one as "Not currently implemented." It does not indicate radio health and it never will. Teams lose real time to this every season — if your roboRIO's Radio LED is dark, that is expected, and you should be looking at the radio's own lights instead.

RSL (Robot Signal Light): solid on = robot on and disabled; blinking = robot on and enabled; off = robot off, roboRIO not powered, or the RSL is not wired properly. A dark RSL on a robot that is otherwise alive is a wiring problem in the RSL circuit, not a robot problem — but it will still fail inspection.

The brownout numbers, exactly

Amber Power LED means the roboRIO hit stage 2 of its brownout ladder. WPILib documents three stages, and the thresholds are worth knowing precisely because they are commonly misquoted:

• Stage 1 at 6.8V — the 6V output on the PWM pins starts to drop. Nothing is disabled yet, but servos and anything else on that rail begin to misbehave.
• Stage 2 — outputs disabled. The trigger is 6.3V on the roboRIO 1.0 (fixed; the roboRIO 1.0 does not support custom brownout voltages) and 6.75V by default on the roboRIO 2.0. PWM outputs are disabled after a neutral pulse is sent, the 6V/5V/3.3V user rails are disabled, GPIO outputs go high-Z, relay outputs are driven low, CAN motor controllers receive a disable command, and pneumatics are disabled. The Power LED turns amber, the Driver Station voltage background turns red, the status string reads Voltage Brownout, and the 12V fault counter increments. It stays in this state until voltage rises above 7.5V.
• Stage 3 below roughly 4.5V — the roboRIO may black out entirely. It resumes with a normal boot once voltage rises above 4.65V.

If you are seeing stage 2 regularly, the lights are doing their job and the fix is upstream — current limits, battery health, and load scheduling. Our guide on brownouts covers that side of it.

Power distribution: PDH and PDP

These are the most underused lights on the robot. Both boards tell you which channel died without you touching a multimeter.

REV Power Distribution Hub — status LED (these patterns apply to PDH firmware 21.1.7 and later):

WPILib's reference lists one additional row, orange/red blinking = "Fail Safe," which REV's own current status-LED page does not include. Treat orange/red as "check REV's page for your firmware version" rather than a settled meaning.

PDH channel LEDs are the part worth teaching every rookie: off means the channel has voltage and is fine; red solid means the channel has no voltage and there is an active fault — check for a tripped or missing breaker (or, on the switched/fused channels, a blown or missing fuse); red blinking means a sticky fault, i.e. it happened earlier and the indicator stays until cleared manually. A red-solid channel LED finds a popped 40A breaker in about two seconds.

CTRE Power Distribution Panel — status/comm LEDs:

Multi-color states on the PDP: red/orange = damaged hardware, green/orange = in bootloader, no LED at all = no power or incorrect polarity. That last one catches reversed main leads.

REV SPARK MAX and SPARK Flex

REV encodes idle mode and motor type into the color and control-signal presence into solid vs. blink. This is the single most-searched blink code in FRC and the answer is almost always "that's normal."

Standard operation (both SPARK MAX and SPARK Flex):

Motor commands: partial forward = green blink, full forward = green solid, partial reverse = red blink, full reverse = red solid. Forward limit triggered = green/white blink; reverse limit triggered = red/white blink.

So a robot sitting disabled with a NEO on a brake-mode SPARK MAX shows blinking cyan, and one in coast shows blinking magenta. Neither is a fault. (REV's page does not spell out exactly what counts as a "signal," so read blink-versus-solid as "not currently being commanded" versus "being commanded.")

Identification and firmware states: device identify = white/magenta fast blink; CAN bootloader = white/yellow blink on bootloader v1.5.0 and green/magenta blink on the older v1.4.0; bootloader retry = white/blue blink; USB DFU and recovery mode = LED off.

Fault codes — all slow blinks, all with orange as the first color:

The one real difference between the two controllers: SPARK Flex adds orange/green slow blink = temperature cutoff. SPARK MAX's status-LED page lists no thermal blink code at all. If you are chasing a hot NEO on a SPARK MAX, the LED will not tell you — you need the fault data over CAN.

Two gotchas worth internalizing. First, orange/blue (12V missing) is what you see when a SPARK MAX is powered only over USB at a programming bench, which is expected there and alarming on a robot. Second, "LED off" is ambiguous: it means no power, USB DFU, recovery mode, or corrupt firmware. A dark SPARK MAX with a live channel LED on the PDH is a firmware problem, not a power problem — that distinction is exactly why you read the PDH first.

CTRE Talon FX, Kraken, Talon FXS, and CANcoder

Phoenix 6 devices use two LEDs, and the relationship between them carries the meaning: alternating (one then the other), simultaneous (both together), or offset. Get that distinction right and the table becomes obvious.

Talon FX — which is what a Kraken X60 or X44 contains. WestCoast Products' own Kraken documentation carries no table and instead says: "Please refer to the Status Lights page in the CTR Phoenix v6 documentation for the most up to date LED codes." So there is one authoritative table, not two.

The B/C CAL button LED is separate: solid red = brake mode, off = coast mode.

The three states people misread constantly: alternating orange means the bus is alive but your robot program is not talking Phoenix yet; simultaneous orange means everything is fine and the robot is simply disabled; alternating red means this device sees no CAN traffic at all. CTRE's own CAN troubleshooting page puts it plainly — "TalonFX and Pigeon2 typically blink orange when healthy."

Talon FXS shares that table with two additions: alternate orange/green = no motor selected in the motor arrangement (a configuration mistake, not a hardware fault), and its offset orange/off covers thermal cutoff or a missing temperature reading.

CANcoder encodes two independent things at once — CAN state in brightness, magnet strength in color.

A rapid-green-but-dim CANcoder is the classic swerve gremlin: the magnet spacing is perfect and the device is simply not on the bus. Brightness is the tell, and it is easy to miss in a bright pit — cup your hand over it.

For anything CAN-shaped beyond the LEDs, start with our CAN bus guide and the deeper CAN bus failures walkthrough. The two mechanical checks that resolve most of it: unique device IDs (every CTRE device ships as ID 0), and roughly 60 Ω measured between CANH and CANL with the robot unpowered.

The radio

The current competition radio is the Vivid-Hosting VH-109, now shipping as revision V1.5, which added voltage protection against spurious events from back-driven motors and fixed the RIO port bridging power from the 12V Weidmuller port. It has five LEDs: PWR, SYS, 2.4G, 6G, and RIO.

The failure mode worth memorizing: SYS, 2.4G, and 6G all blinking fast together means the radio is configured as an access point and it has detected a battery — wireless is disabled until that is corrected and the radio is power cycled. In plain terms, you flashed the radio in AP (home/practice) mode and then bolted it to a robot. It will not go wireless until you reflash it as a bridge. Vivid-Hosting lists the RIO LED in its hardware table but publishes no status patterns for it, so do not read anything into that one. Our radio and networking guide covers the flashing workflow.

What the Driver Station is telling you

Three indicators, and each one has a precise definition that makes it diagnostic rather than decorative.

Communications is split to show TCP and UDP separately. Robot Code is not a general health check — the DS decides it by watching whether the Driver Station task inside your robot program keeps updating the battery voltage. That is why a hard-looping command can turn Robot Code red while the roboRIO is otherwise perfectly alive. Joysticks is green when at least one recognized device is connected.

The Diagnostics tab is where you localize a comms failure, because it walks the chain:

• Enet Link — something is connected to your computer's Ethernet port
• Robot Radio — ping status to the radio at 10.XX.YY.1
• Robot — ping status to the roboRIO by mDNS, falling back to static 10.TE.AM.2
• FMS — receiving packets from FMS; note this is not a ping indicator

Whichever one of those is the first to be red tells you where the chain broke.

The CAN/Power tab is the underused one. It shows Comms Faults, 12V Faults (input power faults, i.e. brownouts, counted since the DS connected), 6V/5V/3.3V Faults (typically short circuits on the user rails), CAN Bus Utilization as a percentage, and counts of each of the four CAN fault types. If your Power LED went amber during a match and nobody saw it, the 12V fault counter still remembers.

Driver Station error strings, decoded

WPILib documents these with exact codes. The ones with a leading minus are errors; the rest are warnings.

-44009 — "A joystick was disconnected while the robot was enabled." Despite the wording, this appears even when the robot is disabled or not connected, and one instance shows up every time the DS starts. Do not panic at the boot-time copy.

44004 — "The Driver Station has lost communication with the robot." Printed when Communications goes green to red. One instance appears at DS startup before comms are ever established.

44002 — "Driver Station ping status has changed." Generated when ping status to a device changes while the DS has no roboRIO communication. You will see several during startup as the Ethernet link, radio, and roboRIO come up in sequence — and later, this is the message that tells you where in the chain a dropout happened.

44007 — "Time since robot boot." Prints roboRIO uptime in seconds when the DS starts talking to it. This is how you prove whether a comms loss was a reboot (uptime resets) or a network dropout (uptime keeps climbing). It is the single most useful line in the log for arguing a match replay.

44008 — "Robot radio detection times." Seconds since the radio was last lost and last seen, up to two of each since boot.

44003 — "No robot code is currently running." DS is talking to the roboRIO, but no code. Expected once during a boot; persistent means a crash or a failed deploy — see no robot code troubleshooting.

From CTRE's Phoenix 6 status codes, the strings you will actually see in a red console line:

• RxTimeout (-1003), "CAN frame not received/too-stale." The device stopped answering. Check CAN wiring, CAN bus utilization, and power to that device.
• CanMessageStale (1000), "CAN message is stale, data is valid but old." The softer version — data is arriving, just late.
• TxTimeout (-1004), "CAN Transmit timed out." and TxFailed (-1001), "Could not transmit CAN Frame." Usually a saturated or broken bus rather than one bad device.
• UnlicensedDevice (-10014), "Device is not licensed." Pairs with the alternate red/green LED on a Talon FX.
• FirmwareTooOld (-1008) and FirmwareTooNew (-10025) — a vendor library and device firmware from different seasons.

The 60-second pit triage order

Run this in order. Do not skip ahead, because each step tells you whether the next one is even meaningful.

1. PDH/PDP channel LEDs. Any red channel = tripped breaker or blown fuse. Fix and stop; nothing downstream is trustworthy.
2. roboRIO Power LED. Green, keep going. Amber = brownout (battery/current problem). Red = short on the user rails.
3. roboRIO Status LED. Count the blinks. 2, 3, or 4 means reimage or reboot before debugging anything else.
4. roboRIO Comm LED. Green solid = DS is connected and code is running. Red solid = connected but no user code. Off = go to the radio.
5. Radio SYS LED. Solid = it can reach the field. 1 Hz = it cannot. All three RF lights blinking fast = it is flashed as an AP with a battery attached.
6. Motor controller LEDs, as a group. All of them alternating red or alternating orange means the bus or the code is down, not the motors. One device odd means that device.
7. The one odd device. Now decode its specific color against the table above, and confirm with a self-test in Phoenix Tuner X or the REV Hardware Client.
8. DS Diagnostics and CAN/Power tabs. Confirm what you concluded, and check the 12V fault counter for brownouts nobody watched happen.

Steps 1 through 6 take under a minute and correctly localize the large majority of pit failures. The mistake to avoid is starting at step 7.

What changes in 2027

If you are reading this ahead of the 2027 season, know that the ground is moving. WPILib's 2027 documentation describes replacing the roboRIO with Systemcore — a Limelight-built controller on a Raspberry Pi CM5 with an RP2350 for reconfigurable I/O, quad-core Cortex-A76, 4 GB RAM, an onboard IMU, multiple CAN buses, and, notably, both LEDs and an onboard display. WPILib calls it "the biggest control system update since the introduction of the cRIO." Relay outputs, analog output, SPI IMUs, analog gyro, and DMA are among the removed features.

Alongside it, the 2027 FIRST Driver Station (announced April 24, 2026) is cross-platform across Windows, macOS, and Linux on x64 and arm64, supports up to six gamepads with 16-bit axes, writes driver logs in WPILog format readable by AdvantageScope, and makes E-stop resettable with a one-second Escape + I. It supports only Systemcore; the roboRIO continues to use the existing Driver Station.

What that means for this page: as of August 6, 2026 there is no published Systemcore LED reference table. The introduction page confirms the hardware "features LEDs, a display, and an onboard IMU" but documents no meanings, and the linked specification PDF is a June 2025 alpha document. I am not going to guess colors for hardware whose reference has not shipped. Everything above applies to the roboRIO-based system in your pit today, and this page will be updated when the Systemcore indicator documentation is published.

Frequently asked questions

Why is my SPARK MAX blinking cyan or magenta when the robot is disabled?**

That is normal and it is not a fault. On a brushless motor, cyan means brake idle mode and magenta means coast idle mode; the blinking (rather than solid) simply means the controller is not currently being commanded, which is exactly what a disabled robot looks like. Real SPARK MAX faults always blink slowly and always lead with orange — orange/blue, orange/magenta, orange/cyan, or orange/yellow.

My Kraken X60 is blinking orange. Is it broken?

Almost certainly not, but the pattern matters. If both LEDs blink together (simultaneous orange), the Talon FX has a valid CAN signal and is simply disabled — that is a healthy robot at rest. If they blink alternately, the device sees CAN traffic but no Phoenix running, which usually means your robot code has not started or has not constructed that device yet. Only alternating red means it sees no valid CAN or PWM signal at all.

My roboRIO's Radio LED never lights up. Is the radio dead?

No. WPILib's own status light reference lists the roboRIO's Radio LED as "Not currently implemented." It does not reflect radio state under any condition. Diagnose the radio from its own PWR and SYS LEDs, and from the Robot Radio indicator on the Driver Station's Diagnostics tab, which pings 10.XX.YY.1.

What does "CAN frame not received/too-stale" actually mean?

It is CTRE Phoenix status code -1003 (RxTimeout), and it means your code asked a device for a signal and the most recent frame is too old to trust. CTRE's guidance is to check three things in this order: CAN bus wiring, CAN bus utilization, and power to the device. Look at the offending device's LEDs first — if it is dark or blinking alternating red, it is a wiring or power problem. If every device looks healthy and utilization is high, you are saturating the bus and need to reduce status frame rates.

Why does my radio work on the practice field but not at competition?

Check whether SYS, 2.4G, and 6G are all blinking fast together. That specific combination means the VH-109 is configured as an access point and has detected a battery, so wireless is disabled until it is reflashed as a bridge and power cycled. AP mode is for a radio plugged into a wall at your shop; a robot radio must be flashed in the robot/bridge configuration.

**The Power LED flashed amber during a match but everything looks fine now. How do I confirm it was a brownout?

Open the Driver Station's CAN/Power tab and read the 12V fault counter, which counts input power faults since the DS connected. Then check the Driver Station log for warning 44007, "Time since robot boot" — if roboRIO uptime reset, you lost power entirely rather than merely browning out. On a roboRIO 1.0 outputs are disabled at 6.3V and re-enable above 7.5V; on a roboRIO 2.0 the default trigger is 6.75V.