[jmacd867]

Summary

Closes #274. On Windows and Linux the plugin sent only from the "Positional Flight Data" window's draw callback, so a window X-Plane never drew sent nothing. Sending now runs in a flight loop, as the macOS build already does. The window only displays values.

 XPluginEnable
   baton->start()
+  XPLMRegisterFlightLoopCallback(send_flight_loop, every 50ms)

+send_flight_loop                  # runs whether or not the window is drawn
+  send_sample
+    read_sample                   # the 16 values, unchanged from #184
+    log "[PDS PLUGIN] Send ->" to Log.txt
+    baton->send

 draw_pilotdatasync_plugin         # display only now
   draw values
-  every 50ms
-    build sample, log "Draw send", baton->send

 mouse_handler (Send Packet button)
-  build sample, baton->send
+  send_sample

 XPluginStart
   create window
+  log the window's position, then every monitor (X-Plane and OS coordinates)

The README, inference/README.md, AGENTS.md and docs/telemetry_schema.md no longer say that data needs the window open. The Log.txt guidance is limited to Windows and Linux, because the macOS build writes nothing there.

Evidence

• Before: On the lab X-Plane PC (Windows) on 2026-11-12, the plugin was loaded and ticked and baton finished its handshake, but the window was never drawn. Log.txt had no [PDS PLUGIN] Draw send lines, baton_debug.log had no Attempted to send lines, and the logger's CSV stayed empty.
  After: On the same PC with 2cfa261, telemetry reached the relay and data_logger wrote rows to the CSV.
• 7b3230f and 100a022 (shared send_sample(), the monitor logging and the docs) build and pass meson test but have not been run in X-Plane yet. meson test only covers test_threading_tools (gtest target tests a locally redefined function, not production code #191). The plugin calls the X-Plane SDK directly, so no automated test exercises it.
• The payload is the same 16 values, in the same order and with the same unit conversions, as main's draw-callback send. Both yaw halves and both G-force halves still carry the flightmodel value.

Merge Danger

Door: two-way

Reverting restores the draw-callback send. The payload, the relay, the CSV columns and the config are unchanged.

Blast Radius: plugin

• Lab PCs on Windows or Linux only get the fix after rebuilding the plugin and reinstalling PilotDataSync.xpl. The relay and inference need no change.
• Samples are now sent whenever the plugin is enabled, including on menus and with the window closed. Before, sending stopped with the window.
• Log.txt gets one line per sample (up to 20 a second), which was already the case while the window was drawn.
• The macOS build is unchanged.
• During the lab test the hardware throttles stopped responding. This was not reproduced, or tried with the plugin unticked. The plugin only reads DataRefs (no writes, commands or input hooks), so it is believed to be unrelated. Untick the plugin at the next lab session to confirm.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
1.8% Duplication on New Code

See analysis details on SonarQube Cloud

[Phlabry]

LGTM. The flight loop makes baton's per-sample log unconditional, so a window that never draws writes 20 lines a second to baton_debug.log all session instead of none. #262.