PRD revisions 3–5, copyleft relicense, BLE telemetry spec, and the PFD layout mockup

[allenmcghan]

Seven commits. Started as a comparison against the Levil iLevil / BOM line, ended up changing what the project is, and finishes with a working layout prototype and the repository's first CI.

Important

This relicenses the project. Code moves MIT → GPL-2.0-or-later, hardware moves CERN-OHL-P-2.0 → CERN-OHL-S-2.0. Specifications stay CC-BY. Read that section first — it is the least reversible thing here.

---

1. Relicensing to copyleft

Artifact	Was	Now
Firmware, app, tools	MIT	GPL-2.0-or-later
Board files, enclosure models	CERN-OHL-P-2.0	CERN-OHL-S-2.0
Documentation and specifications	CC-BY-4.0	unchanged

The purpose of the project is to put this capability into the world permanently, and a permissive license lets a better-funded fork take the work closed and outrun the original. Copyleft prevents that at no cost to any use the project cares about — building, selling, forking and competing all remain permitted.

GPL v2 or later specifically, because it matches MakerPlane. Verified from their source headers: version 2 of the License, or (at your option) any later version. That is GPL-2.0-or-later, not 2.0-only, so code moves in both directions without relicensing and GPLv3 stays reachable if ArduPilot code is ever wanted for the v2 bus.

Specifications stay permissive deliberately. A protocol nobody may adopt freely does not outlive its implementation. CAN-FIX is Creative Commons for the same reason.

LICENSE and LICENSE-HARDWARE are replaced with the canonical upstream texts, verbatim.

2. MakerPlane as a neighbour, not a competitor (new section 24)

Junco stays a separate project and contributes a plugin. FIX-Gateway is explicitly protocol-agnostic, so a Junco source is the shape it already expects, and that reaches pyEFIS as a panel display.

Six items leave Junco's scope because FIX-Gateway already has them: traffic (Stratux plugin), the second recording, annunciation, panel display, multi-source voting, and Pi baro/IMU.

What remains is the part nobody has built: a two-stroke with CDI ignition and no ECU. The existing open engine plugins are Grand Rapids EIS and MegaSquirt, and both assume an engine with a computer in it.

Section 20 stops being a business plan. The project ends at v2.

3. Traffic as a pluggable channel (new section 22)

The app sees targets, not a method, and the node is outside the path for every backend. Recorded as a display requirement rather than a footnote: a traffic screen must not imply completeness. Part 103 aircraft mostly carry no ADS-B Out, TIS-B only uplinks inside a service volume some other equipped aircraft triggers, and internet feeds have no coverage below roughly 1000–2000 ft AGL. The traffic most likely to conflict with a powered parachute at 800 feet is the traffic least likely to appear.

4. Compute platform opened to a Pi-class build (new section 23)

The 0–50°C rating is an enclosure and airflow requirement, not a disqualifier — the aircraft already routes a pitot line there, so ram air is available. Two distinctions survive the thermal work and become mandatory on that build: read-only root with the log on a separate card, and a supercapacitor sized for an orderly stop.

5. spec/ble-telemetry.md — the document that was blocking code

Four notify characteristics, one per rate class; a common header so an unrecognised characteristic can be discarded safely; value, source, status triples; monotonic node time with published timestamps explicitly not corrected after a clock write; and exactly two writable characteristics, neither able to influence a published value — design rule 1 expressed in the protocol rather than asserted alongside it.

The source tag enumeration is defined here and referenced from log-format.md rather than restated. Tag 0x41, mixed node-and-phone derivation, is load-bearing: such a value inherits the weaker assurance of its inputs, and vertical speed may never carry it.

6. Revision 5 — closing the open questions

Fifteen questions were decidable at a desk and blocking firmware. The three irreversible ones first:

Decision	Why
BLE UUID base frozen at 1761601a-XXXX-4e69-b9a1-b45cf63c7638	Future versions may allocate new slots, never redefine one
Log is a preallocated file on FAT32, not a raw partition	Design rule 4 — the owner reads the card on any laptop
Profile hash over the bytes actually stored	Otherwise changing the serializer invalidates every cached copy

Two came out better than proposed. Integer SI encoding made the NaN convention redundant, so it was deleted — the status bit is now the only validity signal. And log payloads are byte-identical to BLE payloads, so the node serializes once and the link and the card cannot disagree about what a flight contained.

Design rule 9 added — advisory-only data never raises an alert. New docs/open-questions.md indexes what remains. Spec open items drop 19 → 10.

7. Doc resync

Seven files still described the revision 1 product. Two were live ambiguities rather than stale text: log-format.md never required source tags on records, so a compliant logger could have shipped with none; and §22 didn't say where traffic backend selection lives (resolved app-side — a receiver is in the flight bag, not on the airframe).

8. PFD layout mockup, an APK, and the first CI

app/mockup/ is a primary flight display in the standard glass-panel layout — attitude centre, speed tape left, altitude tape right, VSI, HSI below, engine strip down the edge. It is not the client and not on the path to being it; it exists so layout questions get answered before anyone writes an APK.

It already answered one. Design rule 8 as twenty small source tags reads as noise. The answer it proposes is the one real avionics already use — annunciate the source on the instrument: PHONE AHRS · ADVISORY on the attitude indicator, cyan for node-plumbed, magenta for GPS-derived. Same rule, native idiom, almost no visual cost.

It half-answered another. The attitude needed low-pass filtering to be watchable sitting still on a desk. §15 asks whether phone attitude survives a vibrating airframe; that is an early data point and not an encouraging one.

Packaged as a PWA (offline via service worker, installs fullscreen and landscape-locked) and wrapped in an Android APK. The wrapper exists for exactly one reason: sensors require a secure context, so a WebView on file:// would silently kill them. It serves bundled assets over an https:// origin and intercepts locally — nothing leaves the device.

The APK is not committed. .gitignore already excluded *.apk and that decision stands. .github/workflows/mockup-apk.yml is where it comes from: artifact on every run, release asset on a mockup-v* tag. The workflow also checks the APK contains its web assets, since a wrapper shipped without its payload would still build and install cleanly. First run passed in 33 s.

Two build notes recorded in the script for whoever hits them: build-tools 34.0.0's d8 fails on JDK 21 on every class with an opaque String.length() NPE, and passing file lists to d8 via @argfile produces the identical error for a different reason (trailing newline → empty argument).

§19's PWA row is sharpened rather than reversed — Web Bluetooth reaches the node on Android, so the transport objection now applies to iOS alone; what still decides it is duration, since a web page has no background operation and drops the link when suspended.

---

Section numbering runs 1–25 contiguous after two renumberings. Design rules match at nine across README.md and docs/prd.md.

Needs the maintainer: ESP32-S31 appears three times and refers to no Espressif part that exists.

Phase 0 was never blocked — an ESP32, one baro, a breadboard, ground runs. Adding one thermocouple and a logging laptop closes four of the twelve open measurements at once, including both thermal rows that decide the Pi-class build.