How HawkEye 360 Finds RF Signals from Space
Your IoT deployment spans 4,000 miles of pipeline, three ports, and a wind farm in the North Sea. A device goes quiet. Is it dead? Jammed? Sitting next to a rogue transmitter that’s stomping all over your band? Your gateways can’t tell you. Your NMS can’t tell you. The device itself, by definition, can’t tell you.
There’s a constellation of satellites overhead that can.
HawkEye 360 runs the first commercial RF geolocation satellite system, and for IoT architects it’s quietly becoming one of the more interesting data feeds on the market. It works as a wide-angle view of the spectrum your devices actually live in, not as a connectivity layer (it won’t carry your packets). Here’s how the system works, what it detects, and where it fits in a real IoT stack.
What HawkEye 360 Actually Is
HawkEye 360 operates a growing fleet of small satellites in low Earth orbit, flown in tight formations of three. Each trio is called a cluster, and the cluster is the unit that does the work. A single satellite can hear an RF emission. Three satellites flying in formation can locate it.
The constellation covers roughly 144 MHz to 15 GHz. That sweeps in maritime VHF, push-to-talk land mobile radio, UHF tactical bands, satellite phones (Iridium, Thuraya), marine radar, some GNSS bands, and plenty of ISM activity. It’s passive: the satellites receive only. The emitter on the ground has no idea it’s being observed, which matters for unauthorized transmitter work and for any monitoring where you don’t want to tip off the source.
Competitors exist. Unseenlabs flies a French constellation focused heavily on maritime. Spire Global plays in adjacent space data. On the ground, RFeye and CRFS run terrestrial SDR networks. HawkEye 360’s edge is the combination of frequency coverage, commercial availability, and global reach without ground infrastructure.
How the Geolocation Works
The trick is that three satellites moving through orbit see the same RF emission three slightly different ways.
TDOA (Time Difference of Arrival). A signal leaves the emitter and reaches each satellite at a different instant, because each satellite is a different distance away. Take any pair of satellites. The gap between their arrival times pins the emitter to a hyperbola on the ground. Two pairs give you two hyperbolae, and they cross.
FDOA (Frequency Difference of Arrival). Each satellite is moving at a different velocity relative to the emitter, so each one sees a slightly different Doppler shift on the carrier. The differences in observed frequency add a second, independent set of constraints.
Stack TDOA and FDOA together and you get a fix. Accuracy depends on signal duration, bandwidth, SNR, and geometry, but it’s typically in the few-hundred-meters to few-kilometers range. Good enough to point a follow-up sensor at the right pier, the right oil pad, the right cell of a wind farm.
Sat A Sat B Sat C
(•) (•) (•)
\ | /
\ | /
\ TDOA/FDOA | hyperbolae /
\ | /
\ | /
\ | /
\ | /
\ | /
\ | /
\ ___▼___ /
\ / \ /
✕ emitter
/ \ / \
/ \___/ \
ground intersectionThe Processing Pipeline
Geolocation is the headline, but the data path matters for how you’d actually wire this into your systems.
- Onboard collection. Each cluster captures raw RF over a tasking window. You either subscribe to a recurring sweep of a region/band or task collections against specific areas of interest.
- Downlink. Raw IQ data gets shipped to ground stations on the satellites’ next pass over a station.
- Signal processing. The ground pipeline separates emissions, classifies them by waveform, and runs the TDOA/FDOA solutions.
- Characterization. Each detection gets tagged with frequency, bandwidth, modulation hints, duty cycle, and a confidence-bounded location.
- Delivery. Output flows through HawkEye 360’s products (RFGeo, Mission Space, and their analytics layers) via API or dashboard.
The big architectural caveat: this isn’t real-time. End-to-end latency is hours, sometimes longer, depending on tasking and pass geometry. Treat HawkEye 360 outputs the way you’d treat a daily satellite imagery feed, not the way you’d treat a live MQTT stream.
What This Means for IoT Architects
Two use cases tend to justify the spend on their own.
Spectrum monitoring at scale. You’ve got assets across geographies where you can’t realistically drop terrestrial SDRs. A pipeline corridor, a fleet of offshore platforms, agricultural deployments across a country. HawkEye 360 lets you ask: what’s transmitting in our bands of interest across this whole footprint, and how is it changing? You see congestion, persistent interferers, and shifts in the RF environment without trucking a single antenna.
Unauthorized transmitter detection. Critical infrastructure operators care a lot about emitters that shouldn’t be there. Think a new transmitter near a substation, an off-spec radio in a port, a GNSS jammer parked next to a logistics hub. Space-based detection surfaces these without a ground footprint and without alerting the operator.
Secondary applications worth flagging: GNSS interference mapping (jamming and spoofing are growing problems), dark-vessel and dark-asset tracking when AIS is off, and post-incident RF forensics where you need to know what was on the air during a window of interest.
What HawkEye 360 explicitly doesn’t do: it doesn’t connect your devices, it doesn’t decode payloads, and it doesn’t replace LPWAN or cellular IoT backhaul. For per-device telemetry, especially across the long tail of Bluetooth-enabled assets, you still need a device-native connectivity layer. That’s where pairing it with something like Hubble’s Bluetooth-to-satellite network makes sense: HawkEye 360 tells you what the RF environment looks like; Hubble tells you what each of your specific devices is doing inside it.
Architectural Placement
HawkEye 360 sits above your network monitoring, not inside it.
Layer | Purpose | Example
-------------------|--------------------------------|------------------
Device connectivity| Per-device telemetry/payloads | Hubble (BLE), cellular IoT
Network monitoring | Gateway/edge health, traffic | LPWAN NMS
RF environment | Spectrum + emitter geolocation | HawkEye 360Practical ingestion notes: you’ll pull via API on a schedule, scope queries by geofence and band, and join results against your own asset inventory by location and frequency. Expect to write some enrichment logic: a detection at 915 MHz near pad B-17 matters a lot more if pad B-17 is supposed to be running a 900 MHz LoRa link. Budget for an analyst who can interpret detections; this isn’t a feed you just dashboard and forget.
When It’s Worth It
HawkEye 360 earns its keep when your deployment is geographically wide, partially remote, or security-sensitive. Pipelines, maritime fleets, border infrastructure, energy grids, and multi-site logistics networks all fit the pattern. The wider and more inaccessible your footprint, the better the economics get against terrestrial sensors.
It’s the wrong tool for a single dense urban site. A campus, a warehouse, a port terminal where you can drop a CRFS or RFeye node will get you faster, cheaper, lower-latency answers. Pricing is tasking and subscription based, so model it against the cost of equivalent ground coverage before you commit.
Add a Row to Your Data Sources Table
If you’re sketching the next version of your IoT architecture, add a row to your data sources table for “RF environment” and decide whether HawkEye 360 (or Unseenlabs for maritime-heavy work, or a terrestrial SDR mesh for dense sites) belongs in it. Then make sure your device-level connectivity layer is solid enough that when the satellite feed flags something interesting, you can correlate it down to specific assets. Space-based RF geolocation used to be classified. Now it’s an API call. Use it for what it’s good at, pair it with per-device visibility, and you’ll see your spectrum the way it actually is, not the way your own devices report it.
Hubble Network provides per-device Bluetooth connectivity from space, so when an RF anomaly surfaces you can correlate it to the specific asset reporting in. See how it works →