> ## Documentation Index
> Fetch the complete documentation index at: https://docs.altnautica.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Operating Limits
> What has been measured on ADOS hardware, and what has not yet been characterised.
# Operating Limits
This page separates two things that often get printed side by side: what the radio and the software are capable of in principle, and what has been measured on ADOS hardware. Only the second kind is on this page.
Where a figure has not been measured, this page says so rather than estimating. A number you can plan a flight against has to come from somewhere, and a plausible number with no measurement behind it is worse than an admitted gap.
## Measured: the radio link
From two separate bench runs on a paired drone and ground station, with `ados diag link` and the receiver's own counters as independent sources:
| Reading | First run | Second run |
| ----------------------------- | -------------- | -------------- |
| Signal strength | -36 dBm | -41 dBm |
| Decoded packets | 232 per second | 308 per second |
| Throughput | 1.396 Mbps | 1.6 Mbps |
| Decrypt errors | 0 | 0 |
| Packet loss | 0 | not measured |
| FEC blocks recovered / failed | 18 / 0 | not recorded |
Read these for what they are: healthy links at close range, confirming the pipeline decodes cleanly end to end. Neither is a range figure, and the throughput in each is what that session happened to be carrying rather than a ceiling.
Two things they do establish. Zero decrypt errors alongside a recovered-FEC count means the crypto and error correction are working on real radio frames, not on a loopback. And a signal this strong with zero loss is the shape of a healthy short-range link, which is the baseline to compare a degraded one against. The second run reached the same shape independently, after both ends were re-paired from scratch.
The agent reports a link as degraded once loss passes 50 percent or signal falls below -85 dBm.
## Measured: latency
Glass-to-glass video latency over the ground station's WiFi access point sits under 100 ms in normal operation. This is the figure the video pipeline is built around and is quoted elsewhere in these docs.
## Not yet characterised
Each of the following would need controlled flight testing that has not been done. Do not plan against a number that is not here.
### Range
**Not characterised by our own flight testing.** The protocol and hardware are capable of long-range operation, and the [WFB-ng page](/drone-agent/wfb-ng) describes what the link is capable of with directional antennas. What has not happened is a measured range test on an ADOS aircraft producing a distance at which the link degrades, with the antennas, transmit power, and terrain recorded alongside it.
Range depends on antenna gain and pattern on both ends, transmit power, terrain and line of sight, interference, and the regulatory limit where you fly. Any single number without those conditions attached would not transfer to your setup.
If you need a range figure you can rely on, fly it yourself, incrementally, with the aircraft in sight and a working RC failsafe.
### Endurance
**Not characterised.** Flight time is a property of your airframe, battery, and payload, not of ADOS. The companion computer and radio draw power that shortens it, and that draw has not been characterised per board.
### Altitude
**No altitude ceiling has been measured**, and ADOS does not impose one. Your altitude limit is whatever your jurisdiction sets and whatever you configure in `FENCE_ALT_MAX`. See [Regulatory](/operations/regulatory).
### Link budget
**Not characterised.** No measured curve of signal strength against distance, transmit power, and antenna gain exists for ADOS hardware, so there is no link budget table to publish. The -36 dBm reading above is one point at close range, not a curve.
### Client capacity
Roughly 3 to 4 devices can stream video simultaneously over the ground station's 2.4 GHz access point before throughput degrades. This is a working figure from bench use rather than a characterised limit. Telemetry over WebSocket is far lighter and supports more clients.
## Limits ADOS does enforce
These are real and in the code, unlike the figures above.
| Limit | Value | Why |
| ----------------------------------- | --------------------------------- | ------------------------------------------------------------------------------------------------------- |
| Transmit power floor | 5 dBm | Bring-up default |
| Transmit power ceiling | 15 dBm | Configured maximum. The margin above it is a brownout guard, not a measured threshold |
| Degraded link threshold | 50 percent loss, or -85 dBm | Reporting threshold |
| Flight controller heartbeat timeout | 4 seconds | Past this the link is reported as not alive, and vehicle telemetry is withheld rather than shown frozen |
| Default takeoff altitude | 10 m | Used when a takeoff command carries no altitude |
| Takeoff altitude from an extension | 1 m to 120 m | Clamped. Extensions cannot command arm, disarm, motor test, calibration, or reboot at all |
| Video recording segment | 30 minutes | Maximum duration before a new segment starts |
| Log store size | 1 GB | Includes the write-ahead log. Oldest data is evicted first |
| Log retention | 30 days raw, 365 days for rollups | Rollups survive the raw data they were derived from |
| Cellular data cap | 5 GB per period by default | Warns at 80 percent, throttles to 256 kbps at 95 percent, blocks at 100 percent |
### Video defaults
The primary camera defaults to **1280x720 at 30 fps, 4000 kbps**. On a fleet, non-primary
aircraft stream a thumbnail at **320x180 at 1 fps, 50 kbps** instead, so that adding aircraft
costs a small fraction of the channel rather than another full video stream.
### Fleet size
The radio addressing scheme supports up to **24 aircraft** on one ground station.
Do not read 24 as a supported configuration at default settings. At the default modulation
rate, one full-rate video stream alone occupies roughly half the channel, and a fleet of 24
would need more airtime than the channel has.
**The committed fleet size at default settings is 8**: one aircraft streaming full-rate video
and seven on thumbnails. Reaching 24 requires the adaptive modulation ladder to be holding a
higher rate, which depends on signal quality and is not guaranteed at range.
### Guided setpoints decay
Anything commanding the aircraft through guided setpoints, including follow behaviours and
swarm control, has to keep sending. Most autopilots brake roughly **3 seconds** after the last
setpoint and then run their own failsafe. A single setpoint does not hold; it decays.
This is a property of the flight controller, not of ADOS, and it is the reason a companion-side
behaviour that stops emitting causes the aircraft to hold position rather than continue.
The transmit power clamp is a hardware protection, not a regulatory one, and it stays in force in every operating region posture. Raising transmit power past what the adapter's power supply can carry does not increase range, it drops the link. If you are running an adapter on a powered hub or external 5 V rather than host power, set `video.wfb.topology` accordingly so the brownout warning reflects your setup.
The exact power at which a given adapter browns out has not been characterised. It depends on the adapter, the cable and the supply, so treat the ceiling as the tested configuration rather than a measured cliff.
## Where to next
* [Safety](/operations/safety) - what to configure before the first flight.
* [Regulatory](/operations/regulatory) - the limits that are legal rather than physical.
* [WFB-ng](/drone-agent/wfb-ng) - the radio link, its configuration, and its counters.