Editorial collage in Bend Privacy Alliance style showing a drone over Bend, Oregon, with radar and tracking overlays leading to a highlighted pilot/controller location on the ground.

From Drone to Pilot

Investigation

Bend Privacy Alliance  /  Axon patents series, Part 8 of 11  ·  September 2026

How Axon Dedrone turns airspace detection into person-level location intelligence

A drone appears overhead. For most people, that sounds like a fairly simple event: there is an aircraft in the sky, a security system notices it, and someone decides whether it belongs there. Modern counter-drone systems can do considerably more.

Axon completed its acquisition of Dedrone in October 2024, bringing the company’s airspace-awareness and counter-drone technology into Axon’s broader public-safety platform. By 2026, Axon was describing counter-drone and Drone as First Responder as among its fastest-growing categories and presenting Dedrone C2, its command-and-control platform, as a common operating layer for mixed sensors and mitigation systems.

That matters because Dedrone is not merely designed to say that a drone is present. Current Axon materials describe systems that can combine different sensors, identify and track aircraft, reconstruct flight paths, surface potential pilot locations, direct cameras toward detections, share those locations into real-time operations systems, and support decisions about what happens next. The privacy question is therefore not simply whether police can detect drones, but how a detection becomes information about a person and how that information can move through the rest of the public-safety platform.

Dedrone is not just a drone detector

The easiest way to misunderstand Dedrone is to picture a specialized antenna listening for drones.

Radio-frequency detection is part of the architecture, but it is only one part. Axon’s patent portfolio now includes an RF-based UAV detection family, a radar-based UAV identification and tracking family, and a broader multi-sensor identification, tracking, and management family. Google Patents records March 2026 assignments from Dedrone Holdings to Axon Enterprise on key active branches of those families.

The commercial architecture points in the same direction. In its 2026 materials, Axon describes Dedrone C2 as improving sensor fusion across combinations of hardware sensors and expanding integrations with third-party sensors and effectors. For World Cup 2026, Axon described an Advanced Trailer combining long-range radar, RF detection and decoding, and EO/IR cameras within the same operational environment.

Different sensors answer different questions. Radar can establish that a physical object is present. RF analysis can characterize signals and, in some configurations, help associate a drone with its control system. Remote ID is a cooperative broadcast source, while cameras can provide visual confirmation. When those observations are fused, the result is an airspace intelligence picture rather than a single alarm.

Infographic showing one drone observed by radar, RF sensors, Remote ID, optical/EO-IR cameras, acoustic sensors, and third-party systems, with the inputs feeding a fused operational picture and downstream location, history, assessment, and response functions.
Dedrone can combine RF, radar, Remote ID, optical/EO-IR, acoustic, and third-party inputs into a fused operational picture.

From detection to action

Dedrone describes the operational sequence in similarly staged terms. Its DedroneTrailer+ product page says DedroneTracker.AI can detect, identify, and locate a drone, provide a pilot location, and support officers approaching the pilot. A useful way to understand the broader architecture is as a chain:

DETECT → IDENTIFY → TRACK → LOCATE → VERIFY → ASSESS → SHARE → ACT

Each transition creates a different kind of information and a different kind of governmental power.

Detect

A sensor observes something that may be an unmanned aircraft.

Identify

The system may attempt to determine a make, model, signature, identifier, or whether the aircraft matches some known or authorized category.

Track

Once a system establishes a track, the event can become a sequence of locations rather than a single point: flight path, direction, speed, altitude, and time.

Locate

The system may also surface information about a controller, pilot, or likely launch location. This is where an airspace-monitoring system can begin producing person-level location intelligence.

Verify

Optical or thermal cameras can be used to visually confirm a detection.

Assess

The aircraft may move from detected to categories such as known, unknown, authorized, unauthorized, or threatening. Those labels represent different stages of assessment and should not be treated as interchangeable.

Share

The resulting intelligence can move beyond the original counter-drone interface. Axon states that Dedrone can push drone flight paths and potential pilot locations directly into Axon Fusus.

Act

The information can guide field response and, in circumstances where legal authority exists, support a mitigation decision. Axon’s own current materials describe C2 as including mitigation management and integrations with third-party effectors.

Each stage carries a different evidentiary and legal weight. Detecting an object does not establish its identity or threat status; a location estimate may be less certain than a direct measurement; and the technical ability to recommend a countermeasure does not by itself establish authority to use one.

A drone location is not the same thing as a pilot location

The phrase pilot location can describe information produced in different ways.

The FAA’s Remote ID guidance makes one important distinction explicit: a Standard Remote ID drone broadcasts the drone’s location and the control-station location, while a retrofit broadcast module transmits the drone’s location and its takeoff location instead. Those are different data fields with different meanings.

Dedrone also markets RF-based localization independently of Remote ID. Its RF sensor documentation says the RF-360 and RF-560 can localize drones and their remote controls, and explains that multiple direction-sensing sensors can be used to calculate position through triangulation. Dedrone’s fixed-site product page says its C2 software can produce drone and pilot locations from multi-sensor and track-fusion algorithms.

Axon’s 2026 World Cup materials add a third phrase: “likely launch location.” A control-station location, an RF-localized remote control, and a likely launch location should not be treated as interchangeable simply because each can appear as a point on a map.

The practical safeguard is straightforward: the interface and audit record should preserve what kind of location was shown and when it was generated. That is enough to let an operator distinguish a directly broadcast control-station location from an RF-derived pilot location or a likely launch point without overstating what the underlying data proves.

When the camera turns toward the person

Dedrone’s sensor fusion does not stop at RF and radar. Its fixed-site product page describes PTZ cameras used for visual verification and auto-tracking, while its Remote ID explainer says a multi-sensor deployment can add cameras to identify payloads and even capture images of pilots.

That changes the privacy character of the system. An airspace-security platform can begin with a drone detection and then produce visual information about the person believed to be operating it.

Dedrone’s own product materials also distinguish authorized from unauthorized aircraft and describe risk-prioritized targets. Those classifications matter because detected, unauthorized, and threatening are not the same state. The system can help operators make that distinction, but the mere fact that a drone or pilot has been located does not itself establish unlawful conduct.

When airspace intelligence enters Fusus

The next transition is from collection to dissemination. Axon describes Fusus as the operational environment into which Dedrone can push flight paths and potential pilot locations, alongside other live information sources.

A location generated by an airspace-security system can therefore sit beside terrestrial cameras, dispatch information, officer locations, incidents, and other sensor feeds. The drone event is no longer isolated inside a specialized counter-UAS console; it becomes another layer in a larger operational picture.

This is the same integration problem Bend Privacy Alliance has documented elsewhere in Axon’s platform: reducing the friction between separate systems can improve response, but it can also make surveillance easier to combine, retrieve, and act upon.

A link can be a surveillance channel

Axon’s World Cup 2026 materials describe another capability called Live View Sharing.

With a single link, Axon says, an operator can share a live view of a drone, its pilot, and its likely launch location with ground teams and partner agencies. The view updates in real time and can plot a route to the target.

This creates an important privacy and records distinction: viewing by link is still dissemination. A recipient does not need a formal export for sensitive information to leave the original interface. A live link can let another person view a pilot location, navigate toward it, take a screenshot, relay it, or create a new record somewhere else.

The practical questions are therefore straightforward:

  • Who can create a live-view link?
  • Does the recipient authenticate?
  • How long does the link remain valid?
  • Can it be forwarded?
  • Can it be revoked?
  • Are recipients logged?
  • Does it expose historical information or only the live event?
  • Does the pilot location continue updating?

Revoking future access is not the same thing as erasing what a recipient has already seen, copied, or incorporated into another record.

What happens after the drone is gone?

Counter-drone technology is easy to imagine as a real-time safety system: a drone appears, an alert occurs, someone responds, and the event ends. Dedrone also markets historical analysis as part of the product. Its “There Is a Drone in My Airspace! Now What?” white paper describes automated summaries of drone activity, including frequent times and days and recurring “hotspots,” and says historical flight patterns can be used to build a threat profile. A separate Dedrone article says the system records every drone incursion so operators can analyze trends, identify tactics, and refine security strategies.

Once detections are retained, a series of events can reveal recurring routes, launch areas, aircraft identifiers, and activity around particular properties, organizations, or events. The public materials reviewed for this project establish historical storage as a capability, but they do not establish one universal retention period for RF observations, drone tracks, controller locations, Remote ID information, video, or related alerts. A system that deletes non-actionable activity quickly is materially different from one that keeps years of searchable flight and location history.

The data does not all belong to one bucket

Dedrone also complicates a familiar claim about Axon’s cloud products: that the customer owns its content.

Axon’s current Cloud Services Privacy Notice expressly excludes Dedrone Data from ordinary Customer Content. It defines Dedrone Data to include information Axon maintains about drone models and manufacturers, usability and performance information, aggregate or de-identified Collected Data, and other information made available through Dedrone software.

The same notice says Axon may use Dedrone Data for purposes including improving Dedrone products, analyzing product performance, and compiling or using aggregate or de-identified Dedrone Data with other customers, government entities, and law-enforcement entities.

The notice does not establish that every raw local detection, precise pilot coordinate, or video clip automatically becomes shared Dedrone intelligence. The more useful question is where the boundary sits between local Collected Data and Dedrone Data.

When is a controller coordinate de-identified? Do precise location fields leave the customer environment before that happens? Are raw RF observations used to improve signature recognition? Are aircraft identifiers retained? What opt-out or configuration controls exist?

Those are questions about architecture and governance, not merely who nominally owns a database.

DedroneDNA adds another layer

Dedrone has used the name DedroneDNA for its drone-recognition knowledge layer. A Dedrone airspace-security white paper describes DedroneDNA as a machine-learning system that recognizes different kinds of drones, can be updated as new drones appear, reduces false alarms, and helps operators understand an intruding drone’s capabilities. An earlier Dedrone product announcement likewise described DroneTracker using the DroneDNA database to recognize and classify RF, Wi-Fi, and autonomous drones.

Those sources support a shared recognition system for drone types and signatures. They do not establish that identifiable local pilot records automatically become part of that knowledge layer, so the article treats those as separate questions.

The patent trail has an unexpected split

Axon’s acquisition of Dedrone might suggest that the counter-drone patent portfolio moved neatly under one corporate roof, but the assignment history is more complicated.

Several major detection, tracking, and later counter-UAS families are now assigned to Axon, including RF detection, radar tracking, multi-sensor management, a later identify/track/disrupt family (US11233978B1, currently listed as active and assigned to Axon), and a newer countermeasure device with associated display (US20250157348A1, currently listed as pending and assigned to Axon).

But several foundational 2015-priority handheld countermeasure branches are currently assigned to Battelle Memorial Institute.

A particularly revealing example is US10567107B2. Its assignment history shows movement from Battelle to Dedrone Holdings, then to Dedrone Defense, and back to Battelle before Axon’s 2024 acquisition of Dedrone. Related branches such as US10574384B2 and US10790925B2 show the same broader Battelle-held countermeasure lineage.

The accurate description is therefore more complicated than “Axon owns Dedrone’s drone-jamming patents.” Axon owns important Dedrone detection, tracking, management, and later counter-UAS families, while Battelle holds several foundational handheld-jamming branches. Product branding alone does not resolve the underlying patent ownership.

Editorial infographic comparing Axon-assigned Dedrone detection and tracking patents with Battelle-held foundational handheld countermeasure patents, with a central stack diagram showing sensors, C2 software, intelligence, integrations, and mitigation.
The counter-drone patent landscape is divided: Axon now holds several major Dedrone detection, tracking, and later counter-UAS families, while several foundational handheld-countermeasure branches remain assigned to Battelle.

Detecting a drone does not create authority to disable one

The same separation is necessary for legal authority.

A system may detect an aircraft, track it, identify a potential pilot location, classify the event as a threat, and recommend a mitigation option. None of those facts alone establishes that a particular local police department has legal authority to jam, seize control of, or disable that aircraft.

Axon’s current materials frame mitigation as a separate stage from detection and tracking. Dedrone’s counter-UAS guidance describes its C2 software as fusing RF, EO/IR, and radar inputs and cueing mitigation systems through human-in-the-loop or human-on-the-loop controls. The relevant public question remains deployment-specific: who is legally authorized to use what technique, under what circumstances, and with what approvals?

The final ACT step in the earlier chain can be unpacked further:

ACT: THREAT ASSESSMENT → AVAILABLE OPTIONS → RECOMMENDATION → LEGAL AUTHORITY → HUMAN DECISION → EFFECTOR → RESULT

This is not a competing framework; it is a closer look at the point where detection and analysis can turn into intervention. A common interface should not erase who was responsible for each step.

What this means in Central Oregon

None of this establishes that Bend, Redmond, or Deschutes County currently operates Dedrone. The local record does, however, show why this architecture matters in Central Oregon.

Bend has steadily expanded its relationship with Axon across body cameras, fleet systems, Evidence, Respond, Fusus, and Axon Air. In February 2024, the City’s Axon Air issue summary said Bend Police had used Axon services since 2021 as a “unified platform,” and that Axon Air supported the department’s drone fleet and remote-viewing capabilities. The same issue summary sought five additional pilot licenses and two additional drone licenses, on top of 10 pilot licenses and nine drone licenses already held at the time.

Redmond’s June 2026 official agenda packet described a proposed five-year, $410,762.16 Axon/Skydio package including two Skydio R10 indoor drones, four Skydio X10 outdoor drones, livestreaming software, and 38 Axon vehicle fleet cameras. The packet also identified DroneSense as the livestreaming platform used by Redmond Police and SWAT. Read the Redmond packet.

Deschutes County’s June 2026 Axon procurement included DroneSense-related services within a broader body-camera, fleet-camera, evidence, and software package. The reviewed quote did not list Dedrone as a purchased line item. A Dedrone appendix appeared among conditional standard terms, but that is not evidence that the County bought the product. Read the June 3, 2026 Deschutes County packet.

Those distinctions are exactly why product-level transparency matters.

The public should be able to tell the difference between a product appearing in a vendor catalog, a capability appearing in standard contract language, a license being purchased, a module being enabled, a sensor being connected, and the capability actually being used.

The local questions should come before deployment

For any Oregon agency considering or using Dedrone, the first questions are concrete:

  • Which modules are licensed?
  • Which are enabled?
  • What sensors are connected?
  • Does the system ingest Remote ID?
  • Can it generate or display controller or pilot locations?
  • Does the interface disclose whether that location came from Remote ID, RF triangulation, or inference?
  • How long are those locations retained?
  • Can historical flight paths be searched?
  • Can cameras be tasked automatically?
  • Does Dedrone information enter Fusus, and under what retention or sharing rules?
  • For any Live View Sharing capability, are the authentication, expiration, forwarding, revocation, and audit questions described above documented in agency policy or configuration?
  • What information becomes Dedrone Data?
  • When is local information de-identified?
  • What legal authority governs any mitigation capability?

These questions do not require assuming bad faith. They are the questions necessary to understand what the system actually does.

The most important record may be the provenance record

Surveillance policy often focuses on the final result: Was the right drone identified? Did officers find the right person? Did the alert lead to a legitimate response? A trustworthy system also needs to preserve the path by which that conclusion was reached.

For a controller-location event, that means preserving the aircraft identity, sensors involved, location method, whether the result was measured or inferred, uncertainty, timestamp, aircraft-controller association, camera verification, sharing history, officer response, and—if applicable—the mitigation recommendation and action.

Without those records, a map pin can become more authoritative than the evidence behind it, particularly when the source and age of the location are not visible to the person acting on it.

The aircraft is only the beginning

Airspace security can serve legitimate purposes, and dangerous or unauthorized aircraft can create real risks. The privacy problem is that the phrase drone detection describes only the first step of the architecture Axon now documents. The same system can move from sensing an aircraft to identifying it, tracking it, surfacing information about the person operating it, directing cameras, disseminating locations, and supporting a physical response.

Each transition changes what the government knows and what it can do with that knowledge. That suggests a simple oversight question:

What exactly does the government know now that it did not know one step earlier?

Meaningful oversight should answer that question before a location estimate drives a police response, before a live link carries the information to another recipient, and before historical flight records accumulate into a searchable intelligence archive.

A system that begins with a dot in the sky can end with officers moving toward a person on the ground; the public should be able to see the steps in between.