+
It flies itself out of the box. A scripted circuit drives the attitude so the whole
+ layout is judgeable without any sensor at all. Drag anywhere on the display to fly it
+ by hand instead. The annunciator on the attitude indicator always names which source is driving it.
+
+
If “Enable phone sensors” does nothing
+
That is expected here, and the diagnostics panel above says why. This page runs inside an iframe,
+ and deviceorientation is gated by Permissions Policy: in a cross-origin frame it silently
+ never fires unless the parent sets allow="gyroscope; accelerometer; magnetometer", which a
+ page cannot grant itself. Desktop Chrome has no motion sensors to begin with.
+
Three ways to get real attitude:
+
— Desktop Chrome: DevTools → ⋮ → More tools → Sensors, then set
+ a custom orientation. It drives deviceorientation and this page will pick it up and flip
+ the annunciator to PHONE AHRS.
+ — Your phone, properly: save this page as an .html file and serve it
+ over HTTPS or from localhost as a top-level page, not framed.
+ — Or just don't. For judging layout, the demo flight is better than real sensors
+ anyway, because it exercises bank angles and climb rates you would not get waving a phone around.
+
+
What is real when sensors do work
+
Attitude, heading, track, ground speed, GPS altitude and position come from the device.
+ The attitude is low-pass filtered, because raw phone fusion is too jittery to look at even sitting
+ still on a desk — which is an early and not especially encouraging data point for a question the
+ PRD lists as open.
+
+
What's simulated
+
Everything on the engine strip, plus indicated airspeed, pressure altitude and vertical speed.
+ Those are node channels and no node exists yet. Values are plausible PM-2 cruise numbers.
+
+
Where design rule 8 went
+
Not twenty small tags. Real avionics annunciate a degraded or alternate source on the instrument
+ itself, so that's what this does: PHONE
+ AHRS · ADVISORY sits on the attitude indicator,
+ cyan labels mark node-plumbed channels, and
+ magenta marks GPS-derived data, which is already
+ the convention every pilot reads without thinking. Same rule, native idiom.
+
+
Worth saying plainly
+
A full PFD makes phone attitude look authoritative, and it isn't. PRD section 19 rejects phone
+ attitude for a control loop because OS fusion is tuned for handheld use and drifts in sustained turns,
+ and section 15 still lists “phone attitude is stable enough on a vibrating airframe to be
+ worth showing” as an open question. That question is exactly what this layout is for —
+ put it on the aircraft, run the engine, and see whether the horizon is steady enough to keep.
+ Design rule 2 stands either way: the mechanical gauges stay installed.
+
+
Layout mockup only. Not an instrument, not airworthy, not the Android client.
+