Verify both simulator paths on the existing cockpit displays. Aerobask/X-Plane 12: test captain PFD, center MFD and the GCU 477 2D popup or another useful avionics controller on the fixed 7-inch capacitive touchscreen. FSReborn/MSFS 2024: test captain PFD, center MFD and captain-side GTC on that same touchscreen. For both, record external pop-out behavior, touch input, focus, persistence, startup/reconnect behavior and any helper-tool dependency. A second GTC and copilot PFD are not initial requirements.
Simulator Integration Framework
Keep functional cockpit controls independent from MSFS/X-Plane details and map them through simulator and aircraft profiles.
Knowledge (2)Tasks (3)
TASK LIST
3 tasks
Design and implement the broker abstraction for multi-aircraft cockpit operation. Support at least `da62` and `phenom300e` profiles. Physical nodes should expose stable logical hardware controls; the active profile maps these to aircraft-specific simulator interfaces. DA62-only and Phenom-only controls must be muted/ignored outside their profile, while genuinely shared controls remain active with profile-specific bindings. Profile switching must not rewrite ESP32/node configuration. Detect the loaded aircraft where possible and provide a clear warning when the selected cockpit profile does not match it. Document how future aircraft profiles can be added.
Perform a complete FSReborn Phenom 300E control/interface audit before final hardware design. For each required cockpit control and indicator, determine: physical function, logical broker name, write method (standard SimConnect event, MSFS 2024 Input Event/B-event, SimVar set, LVar or other workaround), readable state/feedback, and whether the aircraft/system actually responds correctly. Include center console, GTC-related controls, electrical, fuel, bleed/ECS, hydraulics, ice protection, fire, gear and shared DA62 controls. Record unsupported or partially simulated functions explicitly rather than hiding them behind hardware workarounds.
Knowledge
2 items📝
Simulator-independent broker architecture for DA62, Phenom 300 and 300E
ESP nodes must contain no MSFS events, LVars, X-Plane commands/datarefs or other simulator-specific implementation details. Nodes expose stable functional cockpit keys; the broker translates these through simulator and aircraft profiles. Examples: - cockpit.gear.handle - cockpit.thrust.left - phenom.electrical.batt1 Do not expose simulator-bound identities such as msfs.k.*, msfs.lvar.* or sim/cockpit/... from the nodes. Required profiles include at least: - DA62 - Aerobask Phenom 300 / X-Plane 12 - FSReborn Phenom 300E / MSFS 2024 The existing broker-to-node transport layer is designed elsewhere and is assumed to be event-driven; this project does not redesign that transport. Its concern is the physical control inventory and stable functional key contract. Simulator/model differences should be resolved in broker profiles wherever possible.
📝
Broker architecture for DA62 and Phenom profiles
Use one cockpit broker with aircraft-specific profiles rather than rewriting ESP32/node configurations when switching aircraft. Architecture: - Maintain at least two broker profiles: `da62` and `phenom300e`. - Physical nodes expose stable, hardware-oriented logical control identities. Aircraft profiles translate those identities to simulator-specific commands, Input Events/B-events, SimVars, LVars or other mechanisms. - DA62-only controls/nodes are muted or ignored while the Phenom profile is active. - Phenom-only controls/nodes are muted or ignored while the DA62 profile is active. - Truly shared controls remain active in both profiles with aircraft-appropriate bindings. - Do not rewrite or flash node configuration when changing aircraft; switching occurs at the broker binding/profile layer. - The broker should detect the loaded aircraft where possible and warn when the selected cockpit profile does not match the loaded simulator aircraft. - Prefer one ESP32 per physically removable module. If a systems panel is one compact physical assembly, one ESP32 plus local I/O expanders is acceptable; split modules should normally have separate controllers/connectors. Implementation principle: Keep hardware independent from specific MSFS implementation details. For example a physical function may be exposed as a logical control such as `GEAR_HANDLE`, `ENGINE_START_LEFT` or `THRUST_LEVER_LEFT`; the active aircraft profile decides which simulator interface implements it. Before final hardware is built, perform a Phenom control audit to determine for every required physical input/output: command method, readable state, feedback availability and any simulator/model limitations.