Architecture
Every Park Road Designs device connects to the simulator the same way, through the same two pieces of software: SimLinkHub (a Windows app) and a CAN bridge (a small board that turns USB into a shared two-wire bus). This page explains that shape and why it's built this way, rather than each device talking to the sim directly.
One hub, not many
MSFS 2024 only talks one language — SimConnect — and it only runs on Windows. A microcontroller strapped to a throttle lever or a radio panel can't run SimConnect itself; it's a job for a proper PC application, not an 8-bit or Cortex-M0 chip.
So SimLinkHub owns the entire relationship with the simulator. It watches sim variables (frequencies, flap position, engine state, whatever an instrument is mapped to), and it fires the sim events that hardware inputs are supposed to trigger. Every device downstream of it is freed from ever needing to know SimConnect exists — a device only ever needs to speak CAN.
That single point of contact also means there's one place that owns "what is actually true right now." When a value from the sim and a value reported by hardware disagree — the classic case being a knob turned slightly out of sync with the sim's own state — SimLinkHub is the referee. It polls, compares, and corrects, instead of every device having to reason about drift on its own.
A bridge, not a USB device per panel
Hardware devices connect to SimLinkHub over a CAN bus — a shared, two-wire, differential bus originally designed for cars, and also used in a lot of real avionics. One USB-CAN bridge turns that bus into a single USB-CDC serial connection SimLinkHub can open, and every device on the bus rides over that same USB link.
The alternative — giving every panel its own USB connection and driver — doesn't scale: you'd run out of ports, and Windows would need to enumerate and track a growing pile of devices. With a CAN bus, adding a new device means running two wires to it and giving it a CAN node ID; the USB side of the picture never changes.
The PRD-225 radio can actually act as the bridge itself when it's connected by USB — useful if you only have one device and don't want a separate dongle. To SimLinkHub it looks identical to a standalone bridge; the hybrid mode is invisible above the CAN layer.
Devices only need to know CAN
Every device's firmware — whether it's an STM32 (the PRD-225, the bridge) or a plain Arduino with an add-on CAN controller (the throttle/flaps board) — only needs to do three things:
- Send small CAN messages when something changes (a knob turned, a switch flipped).
- Receive CAN messages telling it what to display or how to move.
- Reply to a poll so SimLinkHub knows it's still alive.
None of that requires knowing what a SimConnect event is, what Windows COM
ports are, or how USB works. That's deliberate — it keeps firmware small and
portable, so a future device built on completely different hardware can join the
same bus without needing to reimplement any PC-side integration.
The database is the map, not the firmware
SimLinkHub keeps a small local database (CanDevices, Instruments, Inputs) that maps CAN messages to sim variables and events — including things like scaling formulas and calibration ranges. That mapping lives in the database, not hard-coded into firmware.
The practical effect: adding a new device, remapping a button, or retuning a servo's range is a database edit inside SimLinkHub, not a firmware reflash. See Adding a Device for exactly how that works.
Why this matters going forward
This shape is what makes it realistic to keep adding devices over time — new cockpit panels, and eventually things well outside flight sim entirely — without redesigning anything at the hub or bridge level. A new device just needs a CAN node ID and a handful of database rows.