Troubleshooting

Within about one second of clicking Connect you should see two changes:

• RP2040 LED: from solid red to blinking.
• TX LED: from orange-blinking to blue dimming.

If neither reacts, by far the most common cause is the three wires between the RP2040 and the TX. Most users get this wrong on the first try.

What to check, in order

1. Wire colors. Black, Red, White. Each one goes to its matching pin on both boards. Swapping any of them silently breaks the link.
2. Pin positions on the RP2040. Even if the colors are correct, plugging them on the wrong GPIO breaks the link. See the wiring diagram in Configuration Guide, Step 3.
3. Pin positions on the TX module. Same: the back-of-module pinout varies between modules. Double-check the manual of your specific TX.
4. Power. If you are using setup B (PC powering both), the TX may not have enough current. Plug the TX into a 5V / 3A USB charger instead.

If you are using Direct USB instead of an RP2040, the LEDs to watch are slightly different. See the Direct USB guide.

If you use the RP2040 (Pico Zero)

1. Confirm the RP2040 is plugged into the PC. Listen for the Windows USB chime.
2. Confirm you flashed the uart_bridge.uf2 firmware. Without it, the board only mounts as a USB drive but never shows up as a COM port. See Configuration Guide, Step 2.
3. In Windows search, type “Device Manager” and open it. Under Ports (COM and LPT), look for the RP2040 entry. If it shows a yellow exclamation mark, install the driver. If absent entirely, the firmware did not stick.

If you use Direct USB

The TX module needs the correct USB-to-serial driver. Two common families:

• Silicon Labs CP210x for Radiomaster Ranger Micro, Ranger Nano, etc.
• STMicroelectronics Virtual COM Port (STSW-STM32102) for BetaFPV 1W Micro and similar STM32-based modules.

Install the matching driver from the manufacturer site, unplug and replug the USB cable, then check Device Manager again.

If still nothing, try a different USB cable. Many phone charging cables only carry power, not data.

This is a quirk of the Logitech G29 driver, not a SimuRC-PRO bug. The G29 pedals report 50% at idle until you physically touch each pedal once after plugging the USB cable. From the first touch onward, the pedals report their real rest position (around 0%) for the rest of the USB session.

Fix

1. Before launching SimuRC-PRO (or before clicking Connect): press the throttle pedal briefly, then the brake pedal briefly. They will jump from 50% to near 0%.
2. If you forgot and clicked Connect already: the buggy will not move (the throttle safety hold sees 50% and refuses to forward any throttle). Press the pedals once each, the safety hold will release on the next tick, and you can drive.

Same behaviour applies to a few other older wheels that use a similar driver pattern. If you see the same symptom on a different model, drop a note on the Discord so we can list it here.

This is the throttle safety hold protecting you. SimuRC-PRO refuses to forward any throttle until it sees the pedal physically at rest (under 5%) at least once after clicking Connect. This protects you from a stuck or uncalibrated pedal that would otherwise launch the buggy at full throttle the second the link goes live.

Fix

1. Fully release the throttle pedal. Make sure no foot, no chair, nothing is pressing on it.
2. The safety hold lifts as soon as the app sees the input under 5%. From then on, throttle works normally for the rest of the session.

If the bar still shows above 5% with no pressure on the pedal, your pedal calibration is wrong: re-run Axis Calibration, making sure to press the pedal to its real “rest” position when prompted for the minimum.

If you have a Logitech G29 and never touched the pedals after plugging USB: see Logitech G29 pedals at 50% first.

Related: explicit arming

If you have Arming Required on (default), throttle also stays at zero until you do a long press of 3 seconds on the ARM button mapped on your wheel or button box. See Safety features.

Recent MOZA wheel firmwares expose the wheel only through a proprietary MOZA HID protocol. DirectInput and Windows joy.cpl see nothing. SimuRC-PRO uses the official MOZA SDK to read the wheel and exposes it as a virtual device named MOZA Wheel Base (SDK) in the calibration list.

Requirements

1. Pit House must be installed on the same Windows machine. Download it from mozaracing.com/pages/download-center.
2. You do not need to keep the Pit House UI open. The MOZA Device Service (a Windows service installed alongside Pit House) is what SimuRC-PRO needs, and it starts automatically with Windows.

Diagnostic

1. Open Windows Services (search services.msc). Confirm MOZA Device Service is in “Running” state. If not, right-click and Start.
2. If the service is running but the wheel still does not appear in SimuRC-PRO, check application.log (next to the SimuRC-PRO executable) for lines starting with MozaHidReader. The log line MOZA SDK active — injected MOZA Wheel Base virtual device confirms the wheel is detected on our side.

If Pit House does not detect the wheel either, the problem is with Pit House or the wheel firmware, not SimuRC-PRO.

Some wheel models interpret the magnitude sign of constant force feedback opposite to the standard. SimuRC-PRO has a one-click fix.

Fix

1. In the main window, find the FFB section (under the sliders).
2. Tick the Invert FFB checkbox next to the Test FFB button.
3. Click Test FFB again to verify. Pull left should now pull left.

The Invert FFB setting is persisted. You only need to set it once per machine.

It works on MOZA SDK wheels and DirectInput wheels (Fanatec, Logitech G, Thrustmaster, etc.) uniformly.

Most likely cause: the baud rate sent to the COM port does not match what your specific TX module accepts on its USB bridge. The CRSF standard baud is 400000, but several modules require a different rate.

Fix

1. Disconnect (you cannot change the baud while connected).
2. Use the baud dropdown next to the Direct USB checkbox. Try the values in this order:
   1. 115200 (confirmed on Radiomaster Ranger Micro)
   2. 921600 (confirmed on BetaFPV 1W Micro)
   3. 400000 (CRSF standard, works on some)
   4. 1.87M, 3.75M or 5.25M as a last resort.
3. Click Connect again. As soon as the TX LED switches from orange-blinking to green-heartbeat, you have the correct baud. Persist it and you will not need to change it again.

See also the Direct USB guide for the full module compatibility list.

Toggling between the legacy serial path and the Direct USB native path while a connection is open causes the .NET serial port to close, which pulses the DTR line LOW. On STM32 and ESP32-based TX modules, that pulse is interpreted as a reset signal and the chip reboots.

Fix (current build behaviour)

The Direct USB checkbox is automatically greyed out while you are connected. You can only change it before clicking Connect or after clicking Disconnect. This is the workaround we ship today.

Recommended workflow

1. Launch SimuRC-PRO.
2. Tick the Direct USB checkbox before selecting a COM port.
3. Optionally close and relaunch SimuRC-PRO so the setting is persisted and locked in.
4. Select the COM port, click Connect.

The most common reason is that the TX is not actually transmitting ELRS frames during the pairing window. The RX waits for those frames to accept the binding handshake. As long as the TX is not in radio mode (blue dimming LED), no frames are emitted, even with the right passphrase.

Fix

1. Power up the TX (USB).
2. Click Connect in SimuRC-PRO. Watch the TX LED. It must change from orange-blinking to blue dimming. If it does not, see Connect does nothing visible.
3. Once the TX LED is blue, power the RC car (which powers the RX) within 60 seconds.
4. The RX should see the TX frames and link up (solid LED).

Full procedure with screenshots: Configuration Guide, Step 5: ELRS pairing and Step 6: Power-up timing.

Other reasons

• Passphrase mismatch. Verify by going back to http://10.0.0.1 on each device. Even a single character difference (case-sensitive) breaks the link.
• UART inverted is ticked. Must be unticked on both devices.
• Frequency mismatch. Both must be the same band (e.g. 2.4 GHz).
• Firmware version mismatch. Both must be on the same major branch (both 3.x.x or both 4.x.x).

The two cables on the RX are inverted. SimuRC-PRO sends steering on CH1 and throttle on CH2, with a fixed assignment that cannot be remapped from the app.

Fix

Inside the RC car, swap the two PWM cables on the RX so that:

• CH1 goes to the steering servo
• CH2 goes to the ESC (throttle and brake)

The throttle axis was calibrated in the wrong direction.

Fix

1. Re-run Axis Calibration and pay attention to the prompts. When the wizard asks for the maximum throttle position, press the pedal fully forward (not backward).
2. If after recalibration the behaviour is still reversed, your ESC may be using its reverse direction. Check the ESC manual: most ESCs have a small button or a programming sequence to invert direction.

Same logic applies if the steering goes left when you turn right: re-run Axis Calibration and follow the prompts in the correct direction. The buggy mechanical orientation (servo arm mounted upside down, etc.) is fixed by the Buggy Calibration wizard, not by Axis Calibration.

Updates are automatic. SimuRC-PRO checks for a new version on each launch, downloads it quietly in the background, and installs it the next time you start the app. A running session is never interrupted. There is nothing to download or copy by hand anymore.

Your settings and licence are stored in %APPDATA%\SIMU-RC-Pro (config, profiles, licence). They are kept across every update, so you never lose your calibration or have to re-enter your key. Paste %APPDATA%\SIMU-RC-Pro in the Windows Explorer address bar to see them.

Coming from an older version (manual ZIP)?

Older builds had no updater. Download and run the installer once from the product page. After that, every future update is automatic. Your existing settings and licence next to the old .exe are picked up automatically the first time, so you keep your calibration.

If you had deleted your old folder and lost your licence file, we can re-activate it: drop a message on the Discord with your licence key.

The app is not infected. Here is the honest story, because we’d rather explain it than hide it.

Windows trusts an app instantly only if it’s signed with a code-signing certificate. That certificate is not a one-time technical step: it’s an identity document a certificate authority sells, and it costs money every year (roughly 100 to 600 €/year depending on the type, plus dedicated signing hardware or a paid cloud service since 2023).

We made a deliberate choice: keep the licence affordable rather than bake that yearly cost into your price. SimuRC-PRO is built by a small operation, and that recurring fee would have to land on your licence. For now we prefer transparency and a fair price. The day we sign the app, that cost will show up in the price, and we’ll tell you why.

How to run it (10 seconds)

1. Right-click the downloaded file → Properties.
2. At the bottom, tick Unblock, then click Apply / OK.
3. Run the installer normally.
4. If a blue SmartScreen still appears, click More info → Run anyway.