User manual

Fleet

The Fleet cluster holds drones, batteries, payloads, equipment and satellite communicators. Every asset has a history, deadlines and — where it makes sense — someone responsible for it: this is the base that missions and the logbook rest on.

Drones

For each drone you record the name you use, the manufacturer and model, the serial number (mandatory: it is the key imports use to recognize the aircraft), the CE class from C0 to C6 or legacy for pre-marking aircraft, MTOM in grams, purchase cost, expected life in hours, firmware and insurance with an expiry date. The policy date turns red once it has passed and amber in the thirty days before.

Flight hours grow by themselves from the logbook and are never touched by hand: with every entry recorded, the drone's counter goes up by the flight's duration. Since logbook entries are immutable, that number never goes back down through a silent correction. A retired drone stays in the archive with its whole history.

The maintenance log covers interventions with a date, a description and the next due point by date or by hours, and alongside it sit the recurring maintenance schedules, based on hours, cycles or calendar, with a "mark done" action. From a drone you download the aircraft technical logbook (QTB) and the operational history certificate, which includes the hash-chain verification.

There is also a useful label: the Lost-drone label (QR) action generates a code to stick on the aircraft. Whoever finds it opens a public page and leaves a name, a contact, a message and — if they want — their position; Owners and Admins receive the report in the bell and by push. If you are inventorying a fleet from scratch, the Add from catalog action creates the drone and its first battery with the specifications already filled in for the most common models.

Batteries

Every battery has a label, an assigned drone, a serial number, a cycle count with an optional end-of-life threshold, a status (Charged, To charge, In storage, Out of service), a cost and a capacity in mAh.

There are two counters and they are independent, just as in real life. Cycles grow from the charge log: you record the start and end of a charge and the cycle is counted, the status goes back to "Charged" and the last-charge date is updated. Hours, on the other hand, grow from the flights the battery was fitted to. When the post-flight is signed — and already at the moment the battery is attached to a flight — the status moves to "To charge" on its own.

The cycle count turns red once you reach 80% of the expected life. And a LiPo battery left charged and idle for more than ten days raises a warning on the expiry board: it is the reminder to bring it down to storage voltage.

Continuous coverage

Next to the batteries sits the simulator that answers the long-day question: «with the drones, batteries and chargers I have, how many hours can I keep in the air continuously? and what is worth adding?». You set the scenario — drones airborne, endurance and charge times, charging slots, the horizon to cover — and the simulation tells you whether you cover the horizon, where the gaps open, and what the bottleneck is.

One outcome deserves attention: «covers the eight hours but cannot sustain beyond». It happens when the deficit between charging slots and demand only bites after the first hours, eroding the pool of charged batteries: the simulation catches it by trying twice the horizon, and the recommendation tells you how many extra batteries or slots close the gap. It is a simulator: you play with the numbers, nothing is saved.

Health score 0-100

Next to the battery you find a Health score from 0 to 100, recomputed from flights with attributed telemetry. Green from 80 up, amber from 50, red below 50.

The score is the weighted average of five components, and it is worth knowing what weighs what:

• cell imbalance (weight 30) — the average spread over the last ten flights; at 0 mV it scores full marks, and it falls to zero at 200 mV, twice the attention threshold;
• minimum cell voltage under load (weight 25) — the worst value of the last ten flights, running linearly from 3.30 V (zero) to 3.70 V (full marks);
• thermal exposure (weight 15) — the share of flights with overtemperature out of all flights carrying a temperature reading;
• deep discharges (weight 15) — every deep discharge in the battery's history costs a quarter: from the fourth on, the component is worth zero;
• cycle wear (weight 15) — cycles used against the expected life, which is your max_cycles if you set one, otherwise 200 cycles as a LiPo reference.

A component with no data drops out of the calculation and its weight is redistributed over the others, so a missing figure is never read as "all good".

The score is "n/a" when the battery has no flight with attributed cell or temperature telemetry — no history rows at all, or rows carrying only the charge percentage or only GPS. In that case no convenient value is invented: no data, no score, and no default 100 either.

The battery's page also shows cycles, hours, the number of deep discharges, how many flights actually carried data, the cell trend over the last thirty flights (minimum voltage and imbalance) and a temperature histogram in bands up to 60 °C and beyond. Owners and Admins can launch a Recalculate health over a window of days of their choosing; an automatic recalculation runs weekly regardless.

The limit to keep in mind is the same one as for telemetry: data is attributed to a battery only if it was the only one fitted on the flight. With two packs there is no knowing which cell belongs to which, so that flight leaves no history and does not enter the score.

Battery alerts

The data from each flight produces four kinds of alert. Two are critical, because they mark permanent damage to the chemistry: deep discharge, when a cell drops below 3.30 V, and overtemperature, when the pack reaches or exceeds 60 °C. Two are warnings, because they mark degradation to keep an eye on: cell imbalance of 100 mV or more, and low health, when the score falls below 60.

Every alert reports the measured value next to the threshold that was crossed, so you always know by how much you are out.

Alerts reach Owners and Admins in the bell and, for anyone who has enabled browser notifications, by push as well: one alert per battery per flight, not one per threshold. You find them again as a badge on the Batteries menu entry — red if there is at least one critical, amber otherwise — on the battery's page under Alerts, and at the top of the Expiry board, criticals first.

Two safeguards prevent avalanches. A flight that took off more than seven days ago writes its history but raises no alerts: a late import is not an emergency. And the low-health alert repeats at most once every seven days per battery, because a low score stays low for a long time.

You acknowledge an alert from the battery's page, with the Acknowledge action: it records who and when, takes the alert off the expiry board and brings the badge down. Taking note does not heal the battery, and indeed the alert stays in the history with the name and date of whoever acknowledged it.

On the dashboard, the Batteries at risk panel lists up to eight packs scoring below 60, worst first. When there is nothing to report the panel disappears, instead of telling you everything is fine.

Payloads and calibrations

Thermal cameras, multispectral sensors, LiDAR and RGB sensors are assets in their own right, with a manufacturer, model, serial number, target drone and the two calibration dates: when it was done and when it expires. The expiry turns red once it has passed and shows up on the expiry board and in the mission automatic checks.

Payloads have custody too: the table shows who holds one now and who used it last, and from the payload's page you open the Custody log — the member, the mission, when it was taken and when it was returned, with the notes. It is read-only: those rows are written by taking custody and returning it, they are not filled in by hand. What payloads do not have today is a calibration history: what you get is the two dates, Last calibration and Next calibration.

Equipment and custody

Under Equipment you inventory remote controllers, anemometers, radios, video links, ground stations, tablets and everything else, each with a short inventory code — free text, the suggestion is RC-01, ANE-01, and it has to be unique within your organization. For remote controllers you also set the compatible drones.

If the item has an internal battery, its charge status and cycles appear, and the charge log works exactly as it does for flight batteries: out in the field you can log the charge on the spot, with the same effect on the status. There are calibration dates and a maintenance log as well.

Custody answers the question that matters in the field: who has what. Take custody opens a custody record — you can also assign it to a colleague, not only to yourself — and Return closes it. The Custody log keeps the user, the mission, the pick-up and the return. On a mission a remote controller pairs with one drone only, and it must be one of the compatible ones: the same rule that applies in the field.

Satellite communicators

These are the organization's satellite communicators, the channel that carries an SOS where there is no network. You record the device type — Garmin inReach, SPOT, ZOLEO and Iridium SBD — an identifier, the IMEI and, if you want, the member it is assigned to.

Every ten minutes the platform polls the feeds and updates the device's last position; if a feed reports an SOS, the alert goes out to the ops room straight away. Owners and Admins can also force a sync with Sync now.

One honest clarification: today the inReach and SPOT feeds are actively polled. ZOLEO and Iridium SBD devices can be registered all the same, but their traffic does not go through this sync — Iridium SBD arrives by another route, via webhook.

Aircraft that aren't yours

It happens, and it isn't a rare exception: a volunteer's drone flying for the association, a student's drone at a flight school. The operation is yours, the aircraft isn't.

Before putting that drone in your fleet, stop: the fleet is the aircraft you answer for — class, insurance, MTOM, expiry dates, maintenance. Putting someone else's aircraft in there means signing for something you don't keep.

That's what the guest key is for, in Fleet → Guest keys. You issue it by declaring who is flying and why: two mandatory fields, plus their organisation if they have one. From then on they upload flights as usual, and three things happen:

• the flight enters your logbook, together with its recordings and their data — the evidence belongs to whoever commissioned the operation;
• the drone stays out of the fleet: no expiry board, no insurance, no maintenance. Its hours don't count towards the fleet, but the operational hours stay yours, because you really did fly that job;
• the declaration you wrote — who and why — enters the flight's evidence and can no longer be changed quietly. Six months from now that flight explains itself.

The key is shown once only: the database keeps just its fingerprint, so not even we can recover it. Lose it and you issue another. It expires after ninety days and you can revoke it sooner. ⚠️ Revoking closes the door to new flights, it does not touch those already recorded: they stay where they are, with their declaration inside the evidence.

The operational history certificate of an aircraft that isn't yours says what we can actually prove: its history with you, not its whole history — before and after it flew for others, and that we don't know.