The problem Azimuth solves

The Problem Azimuth Solves

Traditional satellite ground station networks are centralized, expensive, and opaque. A handful of corporations control who receives satellite data, where it's stored, and who gets access, creating single points of failure, coverage gaps, and zero incentive for independent operators to participate.

Research teams and businesses that need satellite data are priced out by the enormous costs of cloud infrastructure (AWS, Azure) and the prohibitive expense of building and maintaining their own ground stations - hardware, licensing, maintenance, and operational overhead that only the largest organizations can afford.

Azimuth makes satellite ground infrastructure accessible to anyone.

---

What Azimuth Changes

Fragmented reception → Collaborative recovery
A single ground station only catches a fraction of packets as a satellite passes overhead. Azimuth coordinates multiple independent stations to receive the same pass simultaneously, merging their data into a complete image recovering packets no single station could alone.

Centralized storage → Permanent, uncensorable record
Every merged satellite image is uploaded to Arweave and its transaction ID anchored on Hedera, making it permanently retrievable by anyone, forever no corporation can delete or gatekeep it.

Trusted intermediaries → On-chain proof
Reception events are cryptographically proven on-chain via PoRx (Proof of Reception).
Anyone can verify which station received which packets, when, and how many no trust required.

Unpaid operators → Token incentives
Station operators earn AZM tokens automatically for every heartbeat (PoA) and every satellite pass they receive (PoRx), paid out by a self-executing smart contract with no human in the loop.

---

Who Can Use It

Use case	How Azimuth helps
Research teams	Access raw satellite imagery without AWS/Azure bills or the $100k+ cost of building a dedicated ground station
Universities	Run a student-operated node on a Raspberry Pi — no enterprise contracts, no gatekeepers
Startups & SMBs	Get satellite data coverage at a fraction of traditional infrastructure costs
Disaster response teams	Redundant, decentralized reception ensures data survives infrastructure outages
Hardware hobbyists	Turn a Raspberry Pi + LoRa radio into a revenue-generating ground station
Web3 developers	Build applications on top of a verifiable, permanent satellite data layer
DePIN investors	Stake in physical infrastructure with transparent, on-chain proof of contribution

Challenges I ran into

Challenges I Ran Into

Building Azimuth meant going well beyond software I was dealing with radio physics, antenna geometry, hardware signal integrity, and the brutal reality that satellites don't wait for your code to be ready.

---

1. Receiving a Signal That Wasn't Designed for You

The hardest part of building a DePIN ground station isn't the blockchain layer, it's actually receiving a usable signal from a satellite traveling at 27,000 km/h, hundreds of miles overhead, transmitting with a few watts of power.

LoRa was not designed for satellite reception. It was designed for low-power IoT sensors a few kilometres apart. Adapting it to receive downlinks from LEO satellites meant tuning every radio parameter by hand, spreading factor, bandwidth, coding rate, preamble length, sync word and validating them against live passes. A single wrong parameter means the radio decodes nothing, and you don't find out until the satellite has already moved out of range.

Getting a consistent lock on the signal required dozens of failed passes before we found the configuration that worked.

---

2. A Satellite Pass Lasts About 10 Minutes — Then It's Gone

LEO satellites are only above the horizon for roughly 8–12 minutes per pass, and the usable high-elevation window where signal is strong is often just 3–5 minutes. There are no retries. If your hardware isn't ready, powered, and listening at exactly the right moment, you get nothing.

This forced the entire system to be always-on and interrupt-driven. The ground station software has to be running continuously, the serial port has to be open, and the LoRa radio has to be in receive mode before the satellite crests the horizon. Any boot delay, crash, or missed wake-up means a wasted pass and no data until the next orbit, roughly 90 minutes later.

---

3. Packet Loss Is the Default, Not the Exception

Even with a good antenna and correct radio settings, packet loss on a satellite downlink is normal and expected. Atmospheric absorption, Doppler shift as the satellite moves, brief obstructions, and the radio's sensitivity floor all cause individual packets to be lost or corrupted mid-pass.

This is the core reason Azimuth uses two ground stations. No single station reliably captures every packet. Station A might receive packets 0–60 cleanly while Station B catches 45–103. The DePIN architecture exists precisely because the physics of satellite reception makes redundancy not optional but fundamental. Getting the packet merging logic right — union of received indices, zero-filling gaps, preserving the JPEG byte order required careful testing against real corrupted captures.

---

4. Running a Node on a Raspberry Pi in the Field

The Raspberry Pi 5 as a DePIN node introduced a different class of hardware challenges.
The Pi had to run headlessly (no monitor, no keyboard), stay connected over WiFi, maintain a stable serial connection to the LoRa radio, run the Node.js hedera-client, and survive being restarted without losing state.

GPIO-to-LoRa wiring had to be solid, a loose SPI connection causes intermittent receive failures that look like software bugs. We had corrupted captures that turned out to be a grounding issue. Power stability also matters: an underpowered Pi under load drops packets at the serial layer, not the radio layer, which is almost impossible to diagnose without an oscilloscope.

---

5. Two Stations, Two Operators, One Shared Infrastructure Layer

In a traditional system, two receiving stations would send their data to a central server for merging. We had no central server, so the coordination had to happen entirely via Hedera HCS, with each station acting as a fully independent peer.

Getting two physically separate machines, one a Mac, one a Raspberry Pi on the other side of the room to autonomously agree on which satellite pass they both received, independently upload their data to Arweave, and trigger a merge purely through on-chain messages required careful design of the announcement and deduplication logic. This is what makes it DePIN rather than just distributed software: the trust and coordination layer is the blockchain, not a server we control.

Use of AI tools and agents

Use of AI Tools and Agents

Azimuth uses AI at two distinct layers: on-device signal processing at the ground station hardware level, and autonomous agent orchestration across the decentralized network layer.

---

1. Claude Code - Development Agent

The Azimuth system was architected and built in collaboration with Claude Code, used as an active development partner throughout the project.

Claude was used for:

• Smart contract design- architecting the

  OrbitalVault

  contract, designing the PoA epoch settlement logic, PoRx proof verification, and HSS schedule automation
• Multi-node coordination protocol - designing the HCS announcement protocol between ground stations, the Arweave upload pipeline, and the packet merge logic
• Debugging hardware-adjacent software - diagnosing serial communication issues between the LoRa radio and the ground station, packet decoding algorithm design, and headless Pi deployment

---

2. AI-Assisted Packet Decoding

The ground station software uses a learned decoding algorithm to reconstruct satellite image packets from raw LoRa radio bytes. Satellite downlinks don't arrive with clean headers the signal contains noise, partial packets, and protocol-specific framing that varies by satellite.

The decoding logic was developed iteratively using AI assistance to:

• Identify packet boundaries from raw byte streams
• Detect and discard corrupted packets based on checksum patterns
• Reconstruct packet indices for out-of-order reception
• Normalise RSSI and SNR readings across different hardware configurations

This layer runs entirely on-device at the ground station no cloud call, no latency ensuring that even in a field deployment with no internet, the station can decode and store received packets locally before uploading to Arweave.

---