Open engine and air data node for Part 103 and experimental aircraft.
Junco instruments an ultralight or experimental aircraft and streams flight and engine data to the pilot's phone or tablet. It logs everything to an SD card, emits GDL90 so existing electronic flight bag apps display it without any custom software, and generates draft logbook entries after each flight.
Target cost is under $250 in parts. Target build is one person with a soldering iron, no hot air station and no PCB order.
Pre-Phase 0. Nothing has flown. Nothing has been built. This repository currently contains requirements and specifications only.
See docs/prd.md section 16 for the phase plan and section 15 for the assumptions that only flight testing can resolve.
These constrain the design. They are not disclaimers.
- The sensor node is advisory only, enforced by being publish-only. It publishes data and subscribes to nothing that influences its own outputs, so it structurally cannot be commanded. This scopes to the node, not the product family.
- Mechanical gauges stay installed. Junco supplements a panel, it does not replace one.
- Draft, never file. Logbook entries are proposed. The pilot reviews and confirms.
- The owner owns the data. Logs live on the owner's card. Recording is disableable.
- Config, not code. Adapting Junco to a different aircraft must never require a toolchain.
- No claim of crash survivability. It is a flight data logger, not a black box.
- A unit always declares what it is. Firmware reports build class, hardware revision, and calibration date.
Junco is not a certified aviation product and is not tested to any aviation standard. If you build one, you are responsible for the result. That responsibility does not transfer to anyone else and it is not affected by anything in the licenses below.
Do not use Junco as a primary flight instrument. Do not remove working mechanical instruments because Junco duplicates them. Do not connect it to anything that moves a control surface.
If you feed Junco data into an autopilot, you have made Junco flight-critical for that installation even though Junco itself never actuates. It is not designed or tested to that standard.
| Path | Contents |
|---|---|
docs/ |
Product requirements, design rationale |
spec/ |
Protocol and format specifications. The artifacts most likely to outlive the hardware |
firmware/ |
Node firmware |
hardware/ |
Schematics and board files |
enclosure/ |
Printable enclosure, pitot, static plenum |
app/ |
Android reference client |
tools/ |
Log recovery and analysis |
Different artifacts, different licenses. See LICENSE, LICENSE-HARDWARE, and LICENSE-DOCS.
| Artifact | License |
|---|---|
| Firmware, app, tools | MIT |
| Board files, enclosure models | CERN-OHL-P-2.0 |
| Documentation and specifications | CC-BY-4.0 |
You may build Junco for yourself. You may sell assembled units. You may fork it, rename it, and compete with it. That is intentional.
Junco is built to outlive whoever is maintaining it. That drives several decisions that would otherwise look like overkill:
- Sensors are specified by requirement, not part number, so a builder in 2034 can substitute what exists then
- Log files are self-describing, so a 2027 flight is readable in 2040 with the file and nothing else
- Protocols are documented separately from the implementation
- Rationale is recorded alongside decisions, because successors break what they do not understand the reason for
See MAINTAINERS.md.