RGB LEDs with SimHub

Which LEDs

WS2812b

The standard choice, sold as NeoPixel strips, rings and matrices. Three wires: 5V, ground and data. Each LED contains its own controller, so a whole strip runs from one Arduino pin.

PL9823

Also supported. Individual through-hole LEDs rather than a strip, which suits a build where each LED sits in its own drilled hole rather than in a line.

Strip density matters more than people expect. 144 LEDs per metre gives a continuous bar of light; 30 per metre gives visibly separate dots. For a rev bar the choice is aesthetic — a segmented bar is arguably easier to read at a glance, because you count segments rather than judge a length.

Wiring

• Data to any digital pin on the Arduino, assigned in the firmware wizard.
• Ground shared between the Arduino, the LEDs and the external supply. This is not optional — without a common ground the data signal has no reference and the LEDs behave randomly.
• 5V to the LEDs from the external supply.

Do not connect the external 5V to the Arduino's 5V pin. The official wiring guidance is explicit: connect the external supply's ground to the components and to the Arduino, but do not feed its 5V into the Arduino's 5V pin. The Arduino takes its power from USB; the LEDs take theirs from the supply; they share only ground.

Power budget. Roughly 60mA per LED at full white — all three channels at maximum. A 16-LED bar is therefore up to about 1A, which is twice what USB provides. In practice a rev bar rarely shows white and rarely lights every LED at once, but design for the worst case rather than the typical one, because the failure mode is the board resetting mid-session.

Two components that are conventional in these builds and worth including: a 330Ω resistor in series with the data line, and a 1000µF capacitor across the supply at the LED end. Neither is required for a working build; both make one that keeps working.

The configuration that actually matters

Once the hardware works, everything meaningful happens in SimHub. These are the settings that decide whether the result is useful or merely lit.

LED count

Must match the physical strip. Set it higher and the last LEDs never light; set it lower and part of your strip is dead. Obvious, and still the most common misconfiguration.

Fill direction, and right-to-left mirroring

Which end the bar fills from. This depends entirely on which way round you mounted the strip, and there is no way to know it in advance — you look at it, and if it fills the wrong way you tick the mirror option. It is one setting, and it is the single most common thing people cannot find.

The RPM percentage range

The bar does not usefully span 0–100% of the rev range, because the bottom two-thirds of an engine's range is not information you need. A range starting around 38% and ending around 98% puts the whole bar in the region where shifting decisions are made.

The colour gradient

Green through to red across the bar is the convention, and it is a convention because it works — the colour tells you roughly where you are without counting LEDs.

Redline behaviour

A blink at the top of the range. This is what actually triggers the shift, and it needs to be unmissable in peripheral vision.

Brightness

Lower than you think. A bar bright enough to read in a dark room at night is painful, and one set for daylight is invisible in the evening. Set it for your usual conditions and expect to change it seasonally.

A worked example

Concrete numbers are more useful than principles here, so here is one real configuration — 16 LEDs, filling right to left, green through to red, spanning 38% to 98% of the rev range, with a blink at the redline.

That is the setup on our own Rev Gauge, and it is offered as one implementation rather than as the correct answer. The numbers are the useful part: 38% as a floor keeps the bar dark while you are cruising, 98% leaves just enough room that the redline blink is a distinct event rather than the end of a gradual fill, and 16 LEDs is enough resolution to judge a fraction without becoming a smooth bar you have to estimate.

You can build exactly this yourself. A Nano, sixteen WS2812b LEDs, a 5V supply and an afternoon gets you the same behaviour — the configuration above is the whole recipe, and nothing about it is proprietary. Other commercial options exist too, from several of the brands in SimHub's device list. Which route you take is a question of whether you would rather spend the afternoon or the money.

The one hardware-specific note worth making. Anything that bolts to a wheelbase has to match that base's mounting. Ours is made for Fanatec bases and desk mounting; a DIY build can go wherever you can make a bracket, which is a genuine advantage of building it yourself.

Common mistakes

The last three are all power or physical. If a problem correlates with how many LEDs are lit or with touching the rig, stop adjusting settings.

Beyond a rev bar

The same LEDs can do far more than fill with RPM, and the tool for that is the LED editor — profiles, groups, conditional effects, layered assembly and a test data editor that lets you simulate RPM and fuel without running a game.

That is where a strip stops being a rev bar and becomes a configurable instrument: flags on one section, fuel on another, a blind-spot indicator at the ends. The LED editor page covers it.

Common questions

Sources

• SimHub wiki — Arduino setup
• SimHub wiki

Related guides

• Shift lightsRPM percent versus absolute, per-car calibration and blink patterns.
• The LED editorProfiles, groups and the test data editor — where a strip becomes an instrument.
• Arduino setupThe firmware wizard, and the pin rule that stops builds.