The current unicast audio is reported as a working prototype; tight synchronization across multiple speakers is not guaranteed. Scope: Android radio, handheld and future fixed cockpit-radio clients as peer Wi-Fi audio clients behind the same T-Dongle. The fixed cockpit radio is future work. Investigate actual playback skew, latency, buffering and recovery with multiple available clients; distinguish successful audio delivery from synchronized playback. Define a measurable acceptable synchronization target before selecting changes, without assuming an existing timing protocol. Acceptance: report measurements, tested clients/network conditions and prototype limitations; propose or implement the smallest justified RadioBridge/client change and show before/after evidence where implemented. This belongs to RadioBridge audio, not Cockpit Manager. It does not block initial single-client platform integration. No synchronized multi-speaker claim without measurements.
.png?locale=nl)
04 - RadioBridge
Independent optional radio subsystem owning radio state, PTT, audio, simulator-radio adapters, the T-Dongle gateway and peer Wi-Fi clients (Android, handheld and future fixed cockpit radio). Cockpit Manager handles lifecycle and displays RadioBridge-reported readiness only. DA62/MSFS is the first integration candidate; XP12/Phenom remains unqualified.
The handheld-radio Codex review reports an X-Plane 11 adapter and no confirmed XP12/Phenom support. Verify the exact adapter implementation and required changes; simulator auto-detection alone is not qualification. Acceptance Record tested repository commit/runtime version and simulator/aircraft versions. Verify simulator connection, supported radio state/control, PTT, usable transmit/receive audio, T-Dongle reachability, required client identity/readiness, and reconnect behavior. Identify unsupported features and remaining defects explicitly. Only then mark the capability qualified for the corresponding session profile. Verify the dependent AI-ATC path separately before claiming end-to-end XP12 ATC support. This is optional radio qualification, not a blocker for running the base XP12/broker session. Keep radio/device/audio logic inside RadioBridge.
Smallest platform integration: inspect the current start-radio.cmd and instance-detection/status mechanisms, then let Cockpit Manager launch the script or reuse a suitable RadioBridge instance. Start with DA62/MSFS as the most concrete candidate; do not claim XP12/Phenom qualification. Ownership boundary RadioBridge owns radio state, PTT, audio routing, radio protocol, simulator-radio adapter, T-Dongle gateway and client/device logic. Manager only starts, reuses, observes and stops it according to process ownership. Do not duplicate radio logic in the manager. Readiness contract First inventory which signals already exist. Define how RadioBridge reports: (1) process active, (2) simulator adapter connected, (3) gateway reachable, (4) audio client connected, and (5) audio/PTT usable. Include client identity, required-client availability and explanatory failure/waiting states. Do not invent an existing endpoint or infer Radio ready from a running process. Android, handheld and future fixed cockpit radios are peer Wi-Fi audio clients behind the same T-Dongle, not Broker/nodes. At least one client is a minimum; a profile's selected required client must actually be ready. Acceptance The manager displays each state separately and no false Radio ready appears when the simulator, gateway, required client, or usable audio/PTT is absent. Reusing an instance does not create duplicates; stopping respects ownership. AI-ATC can wait for this readiness contract. Keep local installation/device configuration private. Multi-speaker synchronization is a separate RadioBridge follow-up and does not block the first single-client integration. Static audit sequencing correction (knowledge item 117) RadioBridge .NET 10 version 0.8.2 currently has no structured local health API. It runs on the simulator PC because of the USB Radio Gateway/local simulator access. The xplane11 adapter uses legacy UDP 49000-49002; AI-ATC context is sent over UDP 49020. The script-start/reuse integration above is a later stage. First coordinate a usable readiness contract with the handheld-radio Codex and implement/verify missing status reporting. In the first read-only preflight, report unknown where signals are absent; add no automatic RadioBridge startup until that contract is available.
Kennis
1 itemSources and evidence Initial cockpit-Codex inventory and subsequent handheld-radio Codex review supplied by the user on 18 September 2026. Repository/runtime checks were reported by those Codex sessions; they have not been independently repeated in this conversation. Current baseline and qualification RadioBridge is started with start-radio.cmd or reused if an appropriate instance already runs. It is an optional session-profile component, not a prerequisite for starting MSFS or X-Plane. DA62/MSFS is the most concrete initial integration candidate. The earlier inventory reported automatic simulator selection, but the handheld-radio repository review identifies an X-Plane 11 adapter, not confirmed X-Plane 12/Phenom support. XP12/Phenom radio functionality remains unqualified; automatic detection is not proof of compatibility. The reported installation requires physical separation between the radio USB dongle and Jabra dongle. Ownership RadioBridge is an independent submodule under Cockpit Platform. It owns radio state, PTT, audio routing, radio protocol, simulator-radio adapter, T-Dongle gateway and device logic. Cockpit Manager may start, reuse, observe and stop the component subject to process ownership. It must not duplicate radio state handling, audio routing, radio protocol or device logic. Android radio, handheld radio and the future fixed cockpit radio are peer Wi-Fi audio-client roles behind the same T-Dongle. They belong to the RadioBridge domain, not Broker/nodes. The fixed cockpit radio remains future work. Minimum integration Launch start-radio.cmd or reuse a suitable running instance. RadioBridge must report separately: process active, simulator adapter connected, gateway reachable, audio client connected, and audio/PTT usable. The manager displays these signals and their waiting/failure reasons; it must not infer Radio ready from process liveness. Inspect which status signals already exist before defining the transport/schema. Profile-required client identities must be visible, so an unrelated connected client cannot conceal a missing selected handheld. AI-ATC and audio follow-up AI-ATC may start only after the simulator connection and usable audio/PTT are reported, in addition to its own Ollama prerequisites. Current unicast audio is reported as a working prototype, without guaranteed tight synchronization between multiple speakers. Multi-speaker synchronization is a RadioBridge follow-up, not a Cockpit Manager responsibility; it need not block initial single-client integration.