Overview

Altitude Angel is the only company in the world to currently offer this capability. It has been designed to help drone pilots monitor their Area of Operation for specific important safety-related events, such as the detection of low-flying manned aircraft or the activation/deactivation of a no-fly zone.

Other services are available which will provide you with a delayed feed of all aircraft operating, but offer no trajectory analysis or specific enhancements to take into account the Human Factors associated with displaying too much, usually irrelevant data to a drone pilot.

That's where Airspace Alerts is different.

We understand that a drone operator is busy operating their drone and keeping their eyes on the sky and their drone. Airspace Alerts will watch for conditions that you specify and notify you at the right time, with the minimum amount of data required to safely convey the message to your customer. In this way, irrelevant data, such as the activation of a 5,000nm radius NOTAM or the flyover of a 747 at 35,000 ft get filtered out server-side.

🚧

Safety notice

Airspace Alerts is intended to supplement the generally accepted operating standards and best-practices appropriate for drone operators during their normal due-diligence and awareness activities, not as a replacement for them, or their legal obligations. Airspace Alerts assists with "plan-to-avoid" scenarios, not to serve as a replacement for "see-and-avoid".

Characteristics and limitations

We have designed Airspace Alerts to be extensible and to handle data in real-time from a variety of different sensors and providers. We are always seeking ways to improve our services, and it is our commitment to you that as we secure additional data relevant to Airspace Alerts, this will automatically be included.

One important limitation of Airspace Alerts is that it is - necessarily - based upon commercially available ADS-B feeds. These feeds vary in quantity and quality and also latency. Where possible, we work hard on the server-side to mitigate the effect of latency from our providers by expanding the monitoring area automatically and compensating for any detected delay. It is also extremely important to be aware that not all aircraft are required by law to carry an ADS-B transmitter or to have it switched on. Likewise, ADS-B is currently a ground-based detection network and it is, therefore, possible that an aircraft will not be visible to (be within the range of) a ground-based receiver, for example, if the receiver is at the top of a valley and the aircraft is below this.

It is important to note these limitations exist for everybody today, and is something we are actively working to find solutions to in order that everyone can benefit.

In relation to other types of alerts, such as those for NOTAM and Weather, these are "best-efforts" systems which alert based on the data available to us at the time. While we take great pride in the quality of our data feeds and partners, we cannot guarantee that we will notify you about everything that (with hindsight) we probably should have. It is always the end-user's responsibility to maintain the safe operation of their drone, and these systems can be used to help inform their decisions.

Bearing in mind these caveats, Airspace Alerts can offer a tremendous enhancement over the data normally available to a drone operator.

Typical coverage maps for our ADS-B data feeds:

Images courtesy of one of our data providers and are illustrative only.

Continuous improvement

We work with a number of partners and providers around the world to continuously expand the effectiveness of Airspace Alerts. In this regard, it is important to note that:

• Airspace Alerts is not solely based on ADS-B data feeds. In some regions, we work with radar manufacturers to ingest Primary Radar data or data from other telemetry systems.
• Some drones (although very few) carry ADS-B transmitters, and we monitor these too.
• Some emergency services aircraft do not carry ADS-B transmitters, however, we do have agreements in place with some operators to receive a declaration of the intended area of operation of these aircraft which we subsequently 'feed' into the Airspace Alerts system.

Regardless of the tracking mechanism we use, we aim to de-duplicate incoming messages and normalise our tracking output so that you don't have to make any changes to your implementation when we add new, higher-resolution tracking mechanisms.

Enabling Airspace Alerts programmatically

To set up an Airspace Alert, developers need to first create a Flight Report (see the Flight Reports service). To monitor a specific region, you must have an interest in that region during a specified time period and that declaration from you is that you are carrying out (or planning to carry out) a drone operation in that area at the specified time.

Mechanism

Once you have created a Flight Report and configured it to receive Airspace Alerts, we will begin monitoring as requested at the start time specified.

If an alert is triggered, we will then notify you by sending a JSON object via an HTTP POST request to your configured Webhook URL.

Lifecycle of messages

Below is the typical message flows you can expect to receive from us at your Webhook URL:

• At the start time of your Flight Report, we will send a notification alerting you that we have begun monitoring.
• At the end time of your Flight Report, we will send a notification alerting you that we have ended monitoring.
• During your flight report, if any condition matches the criteria you have asked us to alert you for, we will send you the appropriate message.

🚧

Placeholder

We are in the process of copying over our documentation for this section and it will be available shortly. In the meantime, if you require this documentation, please contact us.