ForgeFX research brief · August 30, 2026

No-PC heavy-equipment controls for Meta Quest 3+

Bridge real joysticks and CAN-bus controls directly into a standalone Unity application on the headset—without a Windows PC in the runtime loop.

Feasible nowUSB HID firstBluetooth HID second
1proven ForgeFX Quest test
3transport options compared
2headset models to validate
0PCs required at runtime

Executive takeaway

Carl’s test materially de-risks the idea: Quest 3 already accepted a wired game controller in a ForgeFX Unity application with no PC.1 The shortest path is to make the CAN bridge impersonate a standards-based USB gamepad/joystick. Unity’s Input System supports Android joysticks generically, while a deliberately gamepad-shaped HID report can preserve the familiar two-stick/button abstraction.23 Bluetooth HID is the wireless follow-on. Custom BLE characteristics should be the fallback, not the starting point.

Recommended architecture

1 · Recommended POC

CAN → MCU → USB HID → Quest

The bridge reads CAN and appears to Android/Unity as a joystick or gamepad. Android supports USB host mode and enumerates attached devices; USB HID is self-describing and designed for generic host drivers.45

Why first: least software, deterministic setup, easiest logging, and directly extends the working wired-controller test.

2 · Wireless follow-on

CAN → MCU → Bluetooth HID → Quest

Use Bluetooth HID over GATT so Quest sees a standard input device rather than a custom telemetry peripheral. Meta publishes an official game-controller pairing path, and Bluetooth SIG defines HID over GATT for low-energy devices.67

Tradeoff: cable-free operation, but pairing, reconnect behavior, radio congestion, battery state, and headset OS updates become acceptance criteria.

3 · Only when needed

CAN → MCU → custom BLE GATT → Unity plugin

Custom characteristics allow richer telemetry, diagnostics, firmware status, and more controls. They also require scanning, connection management, characteristic handling, Android permissions, and Unity-to-Android integration.89

Use only if: the simulator needs data that cannot be represented cleanly as axes, buttons, hats, or HID feature/output reports. Meta treats BLUETOOTH_CONNECT, BLUETOOTH_SCAN, and BLUETOOTH_ADVERTISE as review-requiring permissions and permits them for third-party devices that cannot otherwise pair through Quest’s Bluetooth interface.12

Not a transport problem

Unity remains on the headset

The Quest runs the Android Unity build. The bridge is an input adapter, not a compute host. OpenXR still handles tracked headset/controllers; the heavy-equipment controls enter through Unity’s Input System as a separate device.

Implication: no embedded Unity runtime is needed in the RWC hardware.

What “no custom Unity code” really means

Device behaviorLikely Unity workRisk
Known, correctly mapped gamepadExisting Input Actions may bind immediately.Low; verify every axis/button and disconnect state.
Generic USB/Bluetooth HID joystickBind generic joystick controls; normalize, dead-zone, invert, and label them.Medium; Unity warns generic HID gamepads surface as joysticks because mappings are not guaranteed.3
Custom HID report or many nonstandard controlsRegister a small custom Input System layout matched by vendor/product ID.Medium; still far smaller than a custom transport plugin.10
Custom BLE GATT serviceAndroid Java/Kotlin plugin plus C# bridge, permissions, reconnect UX, and protocol parsing.High; Quest OS compatibility must be regression-tested.

Hardware implications

CAN front end

  • Use a real CAN controller plus the correct external transceiver; ESP32’s TWAI controller is CAN-compatible but requires an external physical-layer transceiver.11
  • Match classic CAN vs CAN FD and the machine’s bitrate/termination.
  • Prototype listen-only wherever possible; never inject frames onto customer equipment by default.

Quest connection

  • USB consumes the headset’s only USB-C port; validate simultaneous charging with the exact powered hub/cable topology.
  • Wireless removes the tether but adds pairing and power management.
  • Do not infer Quest 3S or future OS parity from one Quest 3 test.

Control model

  • Start with two sticks, triggers, buttons, and a hat—the same shape Dave proposed.
  • Define neutral values, dead zones, calibration, disconnect behavior, and a visible “controls connected” state.
  • Reserve protocol version/device ID fields so hardware can evolve without silent remapping.

Safety and serviceability

  • Use galvanic isolation and protected power when connecting to real equipment.
  • Fail neutral on stale data, CAN bus-off, USB removal, Bluetooth loss, or app pause.
  • Expose packet age, reconnect count, firmware version, and calibration diagnostics during the pilot.

Two-stage proof plan

Prove the software contract with commodity controllersOn Quest 3 and Quest 3S, test wired USB, Bluetooth-paired, and USB-dongle controllers against the same Unity Input Actions. Record device descriptors, mappings, reconnect behavior, and whether charging can continue.
Build the smallest CAN-to-HID bridgeRead a bench CAN source in listen-only mode and emit a conventional two-stick gamepad report over USB. No custom BLE, no machine-side transmission, no extra telemetry.
Run a 30–60 minute soak testMeasure end-to-end input age, missed/stuck inputs, reconnect time, thermal/power behavior, and behavior across headset sleep/resume. Use measurements—not assumptions—to decide whether USB is sufficient.
Add Bluetooth HID only after USB passesPreserve the exact same logical control map. Compare latency distribution, dropout/recovery, pairing friction, battery life, and RF behavior in the intended simulator environment.

Decision

Green-light a narrow prototype. Build a CAN-to-USB-HID adapter first, using the existing Quest controller mapping as the acceptance target. Treat Bluetooth as a transport swap after the control contract is proven. Do not begin with custom BLE GATT unless the required inputs cannot fit a standard HID model.

Distribution caveat: keep a Quest-native fallback for core menu access. Meta’s input requirement says in-app menus should open from either the gamepad menu button or the left Touch controller menu button.13

Evidence coverage

Internal

Direct ForgeFX proof

Reviewed the complete Slack thread. Carl’s 15.6-second video is a direct internal smoke test of a wired controller driving the John Deere Quest 3 application. It proves one headset/app/controller combination—not product-wide compatibility.1

External

Primary documentation

Cross-checked Meta’s controller setup page, Android USB/Bluetooth/game-controller documentation, Unity Input System/HID documentation, USB-IF and Bluetooth SIG profiles, and Espressif’s CAN-compatible TWAI documentation.

Footnotes

  1. ForgeFX Slack, “RWC without a computer” thread, August 21–30, 2026. Carl Lowther reported and attached a video showing a wired controller operating the John Deere app on Quest 3 without a PC.
  2. Unity Technologies, “Supported Input Devices,” Input System 1.14.2. Android is listed with generic joystick support.
  3. Unity Technologies, “Gamepad Support,” Input System 1.14.2. Generic HID gamepads surface as generic joysticks unless Unity has or is given a specific mapping.
  4. Android Developers, “USB host overview”. In host mode Android powers the bus, enumerates devices, and exposes USB host APIs.
  5. USB Implementers Forum, “Human Interface Devices (HID) Specifications and Tools”. HID 1.11 defines self-describing reports and generic host extraction of device data.
  6. Meta, “Set up a game controller with Meta Quest”. Official support documentation for pairing/using a game controller with Quest.
  7. Bluetooth SIG, “HID Over GATT Profile 1.1”. Defines Bluetooth Low Energy HID services over GATT.
  8. Android Developers, “Connect to a GATT server”. Documents connection callbacks, service discovery, notifications, disconnect handling, and cleanup.
  9. Unity Technologies, “Calling Java and Kotlin plug-in code from C# scripts”. Unity provides JNI-backed APIs for Android-specific integrations.
  10. Unity Technologies, “HID Support,” Input System 1.14.2. Documents custom HID state layouts and matching devices by manufacturer/product or vendor/product ID.
  11. Espressif Systems, “Two-Wire Automotive Interface (TWAI)”. The controller supports ISO 11898-1-style standard/extended frames; an external transceiver is required, and base ESP32 does not support CAN FD.
  12. Meta Horizon OS Developers, “Review-requiring Android permissions”, updated November 26, 2025. Bluetooth connect/scan/advertise permissions require a use-case explanation and are permitted for a third-party device that cannot otherwise pair through Quest’s Bluetooth interface.
  13. Meta Horizon OS Developers, “VRC.Quest.Input.1”, updated July 31, 2024. In-app menus should be activated by a gamepad menu button or the left Touch controller menu button.