Everything you need.
From unboxing to your first 100 hours.

AeroCP is a portable, automatic flight logger. Plug it in (or turn it on, for the battery model), and it records every leg you fly — engine start, takeoff, cruise, every touch & go, every landing, and engine shutdown — without any buttons or apps in the air.

Six sensors run at 100 Hz: GPS (L1/L5 dual-band), accelerometer, gyro, magnetometer, barometer (altitude), and a calibrated microphone for engine acoustic signature. The device fuses them in real time. If one channel drops, the other five carry the airframe state.

AeroCP is built for general aviation pilots who keep a logbook — student pilots, private pilots, CFIs, owners of light aircraft, and flight schools that want consistent leg data across their fleet.

If you currently write down engine start time, takeoff time, landing count, and engine shutdown time by hand at the end of every flight, AeroCP does all of that automatically. The data ends up in the companion WeChat mini-program, ready to copy to your paper logbook or export as CSV.

No. AeroCP is a personal flight-logging accessory. It does not navigate the aircraft, does not display traffic, and is not certified to any aviation standard (DO-178C, DO-160, TSO, etc.).

Treat it like a Hobbs meter you don't have to remember to write down — supplemental information, never primary. Cross-check every log entry against your actual flight before submitting it to a flight school, examiner, or regulator.

The device runs a state machine that watches all six sensors at once. It transitions between phases based on physical signatures:

• Engine start — IMU vibration + microphone engine harmonic both rise sharply above the idle baseline
• Taxi — engine running but speed below ~30 km/h
• Takeoff — GPS speed crosses VS0 with positive climb rate, OR roll signature (speed 30–80 km/h + accel spike + mic at takeoff dB)
• Cruise — airborne, sustained speed above VS0
• Landing — speed drops below VS0 + sustained low speed (full stop), OR strong touchdown vibration spike (T&G)
• Engine off — vibration + mic both drop below thresholds, GPS reports stationary, sustained 3 seconds

Calibration tunes the thresholds for your specific airframe and engine. Without calibration, factory defaults work for most light piston singles — but expect a few false events until you calibrate.

V1 Plug — powered from the cigarette/USB plug in the cockpit. No internal battery. Powers on when you plug it in, off when you unplug. Best for owner-flown aircraft where you can plug in once and forget.

V2 Battery — has a built-in rechargeable battery (~6 hours runtime). Carry it with you, power button to turn on. Best for rental pilots flying many different aircraft, or if your panel has no convenient 12V outlet.

Both models record identically. The mini-program and FAQ apply to both.

V1 Plug: plug into a 12V cigarette outlet or USB-C source (5V/2A minimum). Boot takes about 3 seconds. The startup screen counts down 5 seconds, then transitions to the WAITING screen.

V2 Battery: long-press the side button (PEK) for ~2 seconds. If the battery is flat, charge for at least 10 minutes via USB-C before first power-on.

The companion app is a WeChat mini-program — there's no separate download from an app store. Open WeChat, scan the QR code on the back of the device or on the packaging, and the mini-program loads inside WeChat. It stays in your "Recent" list for next time.

Search "AeroCP" in WeChat as a backup if you've lost the QR code.

1. Power on the device. Wait for the WAITING screen (steady red cogs blinking).
2. Open the AeroCP mini-program in WeChat.
3. Tap the BLE status pill at the top of the home screen — it'll show "Disconnected" initially.
4. Pick your device from the scan list. The name is AeroCP-XXXX where XXXX is the last 4 hex digits of the BLE MAC, also printed on the device's status bar.
5. WeChat will prompt you to allow Bluetooth permission — accept. Pairing completes in 1–2 seconds.

After first pairing, the device auto-reconnects whenever both are powered on and within ~10 meters. You don't need to re-pair.

Only one BLE central can be connected at a time. The device's bond table holds up to 4 paired phones, but only one active connection. If a second phone tries to connect while another is paired, the existing connection is dropped first.

Practical use: pair the pilot's phone and the owner's phone both; whichever opens the mini-program first claims the connection.

1. Confirm the device is on the WAITING screen (not a flight phase). BLE advertising only runs when the device is idle, not in flight.
2. Make sure your phone has Bluetooth on and WeChat has Bluetooth permission. iOS users: Settings → WeChat → Bluetooth Sharing.
3. Try closing and reopening the mini-program — WeChat occasionally caches a stale scanner state.
4. If still nothing: power-cycle the device (V2: hold PEK 8 seconds to force off; V1: unplug, wait 5s, plug back in).

Yes. The device won't write a flight log until at least one aircraft with a valid registration is configured. This is intentional — a leg without a tail number can't be matched to a logbook later.

The fastest path: pick a preset that matches your aircraft type from the device's Aircraft page, change the registration to yours, save. About 20 seconds.

Six built-in templates cover the most common GA airframes. Pick one as a starting point — you can adjust any parameter afterward.

The Custom tile lets you build from scratch.

VS0 is your aircraft's stall speed in landing configuration (flaps full, gear down for retractables). The device uses it to derive every speed gate in the flight detector:

• Airborne speed = VS0 × 1.0 (the speed at which the device considers you airborne)
• Landing stage 1 = VS0 × 1.0 (speed dropping below this starts landing detection)
• Landing confirm = VS0 × 0.7 (speed must drop below this to confirm a full-stop landing)
• Taxi-out speed = VS0 × 0.4 (speed considered "taxi" not "static")
• T&G vibration speed gate = VS0 × 1.5 (touchdown vib can fire landing up to this speed)

Get VS0 wrong by 10 km/h and the entire detection chain shifts. Check your aircraft's POH for the exact figure — it's usually in the "Airspeed Limitations" section.

On the device: Settings → Aircraft → tap the row → Edit. Use the on-screen keyboard for registration; numpad for VS0, fuel, engine hours.

From the app: Aircraft → tap the card → Edit. The changes push to the device on the next BLE sync (within 1–2 seconds if connected).

Registration is auto-normalized: trimmed of whitespace, uppercased, and a dash is auto-inserted between the country prefix and the letter/number suffix (e.g., b12y2 becomes B-12Y2). This keeps the same aircraft consistent across device and app.

Up to 5 aircraft on the device, unlimited in the app. The active aircraft (used for the next log entry) is whichever you set as "active" — there's a star indicator on its tile.

If you fly more than 5 aircraft, store the most-flown 5 on the device and rotate via the app when needed.

The app pushes changes over BLE on the next sync. If BLE is disconnected, your change is queued and applied when the device reconnects. Open the BLE status pill in the app to confirm "Connected" before expecting parameters to match.

If they still differ after a successful sync, navigate away from the Aircraft page on the device and back — the page rebuilds from saved values. Firmware v1.0.8+ does this automatically (live refresh).

Strongly recommended for the first flight, but not strictly required. Without calibration, the device uses factory defaults derived from a real SA60L flight session. These work for most light piston singles — you'll get usable but slightly noisy detection.

After one good calibration, false events drop significantly and the engine-on, engine-off, and takeoff/landing transitions feel snappier.

Quick — captures one takeoff peak + one landing peak, derives thresholds with safety margins. Takes one flight. Good enough for most pilots. Marked POOR quality because of the small sample size.

Thorough — gap analysis between event peaks and cruise/taxi noise. Needs at least 2 takeoffs and 2 landings to mark GOOD, and 3+ each to mark EXCELLENT. Plan a session of 3 touch-and-goes followed by a full-stop landing.

1. Park the aircraft, engine off. Open Settings → Calibrate.
2. Pick mode (Quick or Thorough).
3. Confirm your VS0 — this number must already be correct in the aircraft profile.
4. Start the engine and let it stabilize at ground idle. Tap START IDLE CAPTURE. The device records 30 seconds of idle mic + vib baseline. Stay seated, don't tap anything else.
5. When idle capture completes, tap BEGIN FLIGHT and fly normally. The device watches the takeoff(s) and landing(s) in the background.
6. After landing and taxi back, tap END CALIBRATION on the calibration page.
7. The device computes new thresholds and shows a comparison page. Review, then tap APPLY to save, or DISCARD to keep defaults.

Starting in firmware v1.0.9, POOR-quality calibrations are not applied automatically — the device keeps factory defaults until you record at least 2 takeoff + 2 landing samples (which Thorough mode requires for GOOD quality).

This protects you from single-sample artifacts. Earlier firmware would happily save a POOR calibration that, for example, put the takeoff mic threshold below the idle baseline — causing the engine to be detected as taking off the moment it started running.

If you want to override and apply anyway, the compare page still lets you tap APPLY — but the recommended fix is to fly a Thorough-mode session with 2+ takeoffs and 2+ landings.

Idle capture needs a stable, running engine for 30 seconds. If the device detects the engine is off (vibration below baseline), it won't start counting.

• Engine actually running at ground idle? Check that the prop is spinning, RPM is at idle (around 600–1000 RPM).
• Device sitting where it can feel airframe vibration? Loose-fitting suction-cup mounts dampen vibration. Tighten or rest the device on a hard surface in the cockpit.
• If it completes in <5 seconds, that's a bug from an older firmware. Update to v1.0.9+ via OTA.

If you fly the same aircraft type, no — once is enough. The detection model uses thresholds normalized to your aircraft profile (VS0 + calibrated peaks), so it tolerates day-to-day variation (different OAT, different fuel load, etc.).

If you switch between very different types (e.g., a C172 one week and an SR22 the next), keep separate aircraft profiles for each, and ideally calibrate each once. The device stores up to 5 profiles, each with its own calibration data.

The device cycles through 9 screens during a flight. You don't interact with any of them in the air — they're displayed for reference and after-the-fact verification.

Auto (default) — sensors decide every phase transition. Press nothing during the flight. Best for stable, predictable aircraft you fly often.

Manual Confirm — sensors propose transitions; you confirm each one by pressing the side button (PEK short-press). Useful for first flights when you don't trust auto yet, or for unusual aircraft where defaults might mis-fire. Toggle in Settings → System.

Most pilots run Auto after the first 5–10 successful flights.

Eco Mode lowers screen brightness and disables non-essential UI animations to extend battery life. On V2 (battery), it can roughly double runtime — from ~6 hours to ~10 hours. Toggle in Settings → System.

Eco Mode does not change the detection algorithm or sampling rates. Logs are identical with or without it.

Common causes, in order of likelihood:

• VS0 wrong — too high means landings don't trigger (speed never crosses below); too low means cruise turbulence triggers landings.
• landing_vib calibration too strict — if calibration captured an unusually hard landing, the threshold is set too high and softer subsequent landings don't trigger.
• landing_vib calibration too loose — opposite: gusts trigger phantom landings.
• Short approach + immediate touch & go below 1.5×VS0 — covered in firmware v1.0.9. If you're on older firmware, T&Gs above ~1.1×VS0 don't count. Update via OTA.

Solution: re-calibrate in Thorough mode with 3 T&Gs + 1 full-stop on a single session.

This was a known issue in firmware ≤1.0.8 and is largely fixed in v1.0.9. The cause: a piston engine's prop windmills for 3–8 seconds after the magnetos cut, so vibration decays slowly. Combined with a 1-second IMU smoothing window and a 3-second hold timer, end-to-end latency could reach 12+ seconds.

v1.0.9 adds a "fast path" — when vibration and microphone and the engine-harmonic detector all drop below their engine-off thresholds simultaneously, the device declares ENGINE OFF without waiting for the weighted score to crawl down. Typical lag now: 5–7 seconds, of which 3–5s is unavoidable physical spool-down.

Update via OTA if you're still seeing 10s+ delays.

Two-step process:

1. Stage 1 — touchdown: either GPS speed drops below VS0, or a vibration impact spike fires above the calibrated landing_vib threshold (with strict multiplier ×1.5 in v1.0.9). The device records the touchdown moment.
2. Stage 2 — re-takeoff: after the LANDING screen flashes for 5 seconds, the device enters TAXI_AFTER mode. If GPS speed is above VS0 again and vertical speed is climbing >15 m/min for 5 continuous seconds, T&G is confirmed and the device returns to CRUISE.

The recorded touchdown time goes into the leg's tng_times[] array (up to 10 per leg) and both landing_count and tng_count increment by 1.

Yes, starting in firmware v1.0.9. The vibration-path speed gate was raised from VS0 × 1.10 (= 88 km/h for VS0=80) to VS0 × 1.50 (= 120 km/h for VS0=80). Combined with a stricter vibration magnitude requirement, this covers fast touch-and-go practice without producing false-positive landings during cruise turbulence.

On older firmware (≤1.0.8), the same T&G is ignored because the touchdown vibration is gated to speeds under 88 km/h. Update via OTA.

The vibration path accepts touchdowns up to 1.5 × VS0:

Above 1.5 × VS0, the detector ignores the impact to avoid mistaking cruise turbulence for a landing. If your aircraft routinely touches above this, set a higher (more conservative) VS0 in the profile — at the cost of slightly later cruise/landing transitions.

The device runs a unified state machine for full-stop and touch & go. Both transition through PHASE_LANDING for the 5-second flash, then into TAXI_AFTER which decides which one it actually is (full stop = static + engine off; T&G = re-airborne + climb).

You can't tell the device "this was a T&G" in advance — it figures it out after the fact based on whether you climb out again. The flash is brief and doesn't affect the recorded times.

If a touchdown's vibration spike is weak — short runway contact, very smooth landing — it may not exceed the calibrated landing_vib × 1.5 threshold. Re-calibrate with at least one of your typical "softer" T&Gs so the threshold reflects your normal touch firmness.

Alternative: temporarily lower vib_landing in Settings → Flight Params → Landing. Cut it by 20% and re-fly. If false positives don't appear in cruise, that's the new sweet spot.

BLE 5.0, custom GATT service. On every BLE connect, the app:

1. Drains any pending aircraft delete commands queued while offline
2. Pulls all aircraft profiles from the device
3. Ensures every app-side aircraft is also on the device
4. Pushes any aircraft / flight-params changes the user made offline
5. Pulls all flight legs newer than sinceLegId stored locally

Typical full sync: under 2 seconds for 50 legs. Subsequent reconnects only sync deltas.

Fixed in v1.0.8. The app uses "tombstone" deletes — a leg is marked deleted in flash, not physically removed. When BLE syncs, the app filters tombstones from its display. Firmware v1.0.7 and earlier displayed all legs (including tombstones) on the device's Summary page; v1.0.8+ filters them correctly.

Update via OTA to v1.0.8 or v1.0.9.

A conflict modal appears when the same registration exists with different parameters on the device and in the app — for example, you edited the aircraft in the app while disconnected, then connected and the device version differs.

Pick the version you want to keep:

• Keep app version — overwrites the device with what's in the app
• Keep device version — overwrites the app with what's on the device

If you dismiss without choosing, the conflict re-appears on the next sync. Don't ignore — eventually one side's edits will get overwritten silently.

30-second timeout protection is built in — if a sync stalls, the loading spinner disappears automatically and the app falls back to whatever it has cached locally. If you see "Syncing…" beyond 30 seconds, something's wrong:

1. Pull down to refresh on the home screen — this re-attempts the sync.
2. Confirm BLE is connected (pill at top should be green).
3. Force-quit and reopen the WeChat mini-program.
4. Power-cycle the device.

Persistent failures usually mean the device is in a flight phase (BLE writes pause during phases ≥ taxi to protect log integrity). Wait for engine off to complete sync.

Two possibilities:

• The device didn't write a log. Most common: no aircraft was set up with a registration before the flight. The device refuses to write a leg without a registered aircraft. Check the device's home screen — if it shows "ADD AIRCRAFT" in red, no logs were written.
• The leg ID is already known to the app. The app remembers the highest leg_id it has synced. If you deleted the leg from app side after sync, then synced again, the device says "no legs newer than X" because X already covers everything.

The mini-program needs WeChat to load the first time, which requires internet. Once loaded, all sync to the device runs over local BLE — no internet needed for the actual flight logging. Storage is local to WeChat's per-user data.

Note: weather, airport info, and CSV upload all require internet. Plan for offline by syncing legs to your phone via BLE during taxi back, then export later.

On the device: Settings → Language. Slider toggle between EN and 中文. Changes apply immediately to all UI text.

The app's language follows your WeChat language preference — set there if you want a different language for the app vs the device.

Yes. Settings → Units toggles between KMH (metric) and KNT (imperial). Note that internal storage and BLE always use metric — the conversion is display-only. If you switch units, your saved aircraft VS0 doesn't change; it just renders differently.

Altitude is currently meters-only. Imperial altitude (feet) is on the roadmap.

Eco mode lowers screen brightness and slows UI animations. It does not reduce sensor sampling rates, so detection accuracy is identical.

If you're on V2 (battery), Eco roughly doubles runtime. On V1 (plug), there's no battery benefit but you may prefer the dimmer screen at night.

The device's RTC sets itself from GPS time on every flight (once GPS gets a fix). You normally never need to set it.

If you want to set it manually: Settings → Date & Time. Numpad entry for each field. Save commits to RTC.

Time zone: the device stores UTC internally and displays local time based on your Settings → Time Zone setting. Set this once for your home base.

If a microSD card is inserted, the device backs up flight logs and calibration data to /flightlog/backup/. This is a safety net — primary storage is internal NVS flash (10,000+ write cycles guaranteed).

The SD card page shows: card present (Y/N), free space, last backup time. Tap Backup Now to force an immediate backup.

SD card is optional. Logs work without it.

Settings → System → Factory Reset. A confirmation modal explains exactly what will be wiped:

• All saved aircraft profiles
• All flight logs (legs)
• Calibration data
• System preferences (language, units, time zone, etc.)
• BLE bond table — paired phones will need to re-pair

What's preserved: firmware version. A factory reset does not roll back the OTA.

This is irreversible. Make sure your legs are synced to the app first.

1. Open the AeroCP mini-program. Confirm BLE is connected (status pill green).
2. Go to My → Firmware Update.
3. The app checks the latest version on the server. If newer than your device, it shows release notes and UPDATE.
4. Tap UPDATE. The download takes 10–30 seconds depending on your phone's internet. Then the binary streams over BLE to the device — about 3 minutes for ~1.5 MB.
5. The device reboots into the new image, runs a self-check on boot, and confirms with a success page.

If the new image fails its self-check (very rare), the device automatically rolls back to the previous version. You can't brick it via OTA.

Two safety gates:

• Battery — V2 must be >30%, OR plugged in. Mid-update battery drop would brick the OTA.
• Flight phase — must be OFF (waiting screen) or SUMMARY (after engine shutdown). The app refuses to OTA mid-flight.

If preconditions fail, the app tells you which one — e.g., "Low battery — plug in to update."

BLE OTA streams chunks; if it loses connection mid-transfer, the partial image is discarded and the device boots its previous (still-good) image. Just reconnect and re-attempt.

If multiple retries fail:

1. Stay within 1 meter of the device during the transfer.
2. Don't switch apps mid-update — WeChat may suspend the BLE connection.
3. Power-cycle the device and try again on a cleaner phone (close other Bluetooth apps).

If still failing after 5 attempts, file a bug report — we'll likely send you a fresh image to flash via USB-C.

Stable updates ship every 4–8 weeks. Each one is listed at cdn.andylixu.uk/ota/latest.json with release notes (the app fetches and displays this).

Major detection-algorithm changes (like v1.0.9's T&G fixes) are clearly called out. Cosmetic-only updates are quieter.

Power-cycle: V2 hold PEK 8 seconds to force-off, then long-press to start. V1 unplug for 10 seconds.

If the freeze persists, an OTA may have left the device in a partially-flashed state. Connect via USB-C and use the recovery flasher from cdn.andylixu.uk/ota/v1.0.9/firmware.bin. Contact support if you don't have the toolchain.

• GPS needs sky view — under a metal roof or in a hangar, it can take 5+ minutes or never lock. Roll the aircraft to a position with clear sky for the first lock.
• Cold start after long power-off can take 60–90 seconds. Subsequent starts are 5–10 seconds.
• Confirm the GPS module wiring is intact if you wired it yourself: GPS TX → ESP GPIO 18 (RX), GPS VCC → 3.3V, GPS GND → GND. Baud 115200.
• The device shows GPS quality on the status bar: green dot = GOOD, yellow = DEGRADED, red = no fix.

The AXP2101 power IC reports battery % from coulomb-counting. The first 5 charge cycles calibrate the counter — early readings may show 95–98% when actually full. Normal.

If after 10+ cycles it still won't reach 100%, the battery may be aging. V2 expected battery life: 500+ cycles to 80% capacity.

Almost always a calibration issue. If engine_on_db sits too close to ambient cabin noise (calibrated when the cockpit was quiet, then a noisy taxi triggered it), the device fires engine-on incorrectly.

Fix: re-calibrate with the engine running in a representative cockpit noise environment. If on firmware ≤1.0.8, a single-sample calibration could put thresholds in bad places — update to v1.0.9 which guards against POOR-quality auto-apply.

The aircraft profile has no registration set. The device refuses to log flights with empty registrations because legs can't be attributed later.

Fix: Settings → Aircraft → tap the row → enter a valid tail number → Save. Format: B-12Y2, N12345, etc. The device auto-formats spacing and case.

Older firmware (≤1.0.7) had a bug where empty-registration profiles collapsed when synced from the app. v1.0.8 fixed this with a normalization guard that only normalizes registrations containing alphanumeric characters.

If your list looks short: Settings → Aircraft → scroll to confirm the count, and check the app's Aircraft tab against it. If a profile is missing on one side, re-pair BLE and force a sync via pull-to-refresh.

The device's engine_hours_total field accumulates block time (engine start to engine stop) per leg, summed per aircraft. It's not synced to a real Hobbs meter — they're two separate counters.

To align: read the actual Hobbs at any point and enter that number into Settings → Aircraft → engine_hours. The device adds future leg block times to that baseline.

Note: AeroCP's block time is precise to ±5 seconds per leg, so it actually tends to be slightly less than a mechanical Hobbs (which usually runs at oil pressure regardless of taxi delays).

Yes. The ESP32-S3 SoC + LCD backlight draw ~250–400 mA during normal operation; the AMOLED panel reaches 35–40°C in ambient cockpit temps. Direct sunlight exposure can push it to 50°C — still safe but the auto-dim kicks in to reduce thermal load.

If it becomes uncomfortably hot to hold (>60°C estimated), shade the screen or move to a cooler location. There's a thermal cutoff at 80°C that hard-shuts down before damage.

The FT3168 touch controller occasionally needs a calibration reset after a firmware update. Power-cycle: long-press PEK 8s to force off, then on.

If still flaky, try a screen wipe — finger oil on AMOLED reduces touch sensitivity over time. Use a microfiber cloth, no chemical cleaners.

This happened in firmware ≤1.0.7 when certain Chinese glyphs in About / Calibration text weren't in the embedded font set. v1.0.8 added 54 missing glyphs. Update via OTA.

If you see missing glyphs in v1.0.8+, file a bug with a screenshot — likely a new term we haven't covered yet.

• Confirm WeChat has Bluetooth permission — sometimes iOS revokes it after an OS update.
• Check the device is on the WAITING screen, not a settings sub-page. BLE advertising runs during waiting, not during sub-page editing.
• Force-quit the mini-program (swipe up on the WeChat mini-program window). Reopen.
• If still nothing, the BLE bond may have desynced. Forget the device in iOS Bluetooth settings (Settings → Bluetooth → tap (i) → Forget), then re-pair via the app.

No certification. AeroCP is a personal electronic device (PED) — like your phone, headset, or watch. It does not meet TSO, DO-178C, DO-160, or any equivalent regulator approval for installed avionics.

Carry it in the cockpit; mount it for personal reference; use the logs as a memory aid. Do not use it to make safety-of-flight decisions.

Most jurisdictions accept self-reported flight times, and AeroCP's measurements are precise enough to support honest logbook entries. But you remain the legal author of your logbook — you're responsible for accuracy.

Before submitting AeroCP data to a flight school, examiner, or insurer, cross-check at least one leg against your manual notes. If the times agree, you can trust the rest.

For 14 CFR Part 61 / EASA Part-FCL purposes: AeroCP measures Hobbs-equivalent block time (engine on → engine off) and flight time (wheels-up → wheels-down). Note these are different from "block" time as some operators define it (chocks-off → chocks-on).

The device passes FCC Part 15 unintentional radiator limits. Its BLE radio operates in 2.4 GHz ISM, well clear of aviation com (118–137 MHz), nav (108–118 MHz), and transponder (1030/1090 MHz) bands.

That said: any PED can in principle cause issues with sensitive installed equipment. If you observe radio interference correlated to AeroCP being powered, turn it off and report it.

The device records GPS positions (start/end of each leg only — not a continuous track), sensor signatures, engine event timestamps, and the aircraft registration you configured.

This data stays on the device's internal flash and (after BLE sync) in WeChat's mini-program local storage on your phone. It is not uploaded to any cloud unless you explicitly export to CSV and share it.

The optional CSV export is a manual step — you choose where to send the file (email, cloud drive, your logbook software).

For now, contact us via the WeChat customer service in the mini-program. Include:

• Firmware version (Settings → About)
• Aircraft type
• What you expected vs what happened
• Screenshots if relevant

We read every report. Major bug fixes ship in the next OTA; feature requests are evaluated quarterly.