Building a Satellite Hub Monitoring Platform from Scratch

Building a monitoring platform for satellite hub stations started with a simple problem: commercial software was too expensive and too inflexible. We didn't just need a dashboard — we needed a tool that could integrate into our daily operations workflow.

Requirements Analysis

The first step wasn't writing code. I spent two weeks shadowing the operations team during their shifts, recording what they did, what they watched, and which tasks were the most repetitive. Several core requirements surfaced:

• Real-time signal monitoring: live display and alerting for carrier power, SNR, BER, and other key metrics
• Remote terminal management: batch configuration, firmware upgrades, status queries
• Operations logging: automatic history recording for traceability and audit
• Report generation: automated daily/weekly/monthly operations reports

Technology Choices

We chose React + TypeScript for the frontend — not because it was trendy, but because it was what the team knew best. The backend runs on Python (FastAPI), since we needed to communicate with many hardware devices, and Python's ecosystem is the most mature for this. For the database, PostgreSQL with the TimescaleDB extension handles time-series data beautifully.

For the message queue, we went with MQTT — it was designed for IoT scenarios and naturally fits satellite terminal communication protocols.

Architecture

We adopted a microservices architecture, but not the textbook kind with over-splitting. Based on actual business boundaries, we divided it into four core services:

1. Data collection service: communicates with hardware devices, collects telemetry
2. Alert engine: rule-based alerting with multi-level escalation
3. Web service: API gateway and frontend serving
4. Report service: async generation of operational reports

Lessons Learned

The biggest pitfall was timezone handling. Hub station equipment comes from different manufacturers — some use UTC, some local time, some GPS time. The principle of normalizing everything to UTC on ingestion and converting to user timezone on display sounds simple, but executing it required refactoring time-handling logic across the entire system.

Another lesson: don't underestimate network complexity. Satellite links inherently have high latency and packet loss. If the monitoring system is designed too "internet-native" (frequent requests, heavy real-time pushing), it actually makes already-tight bandwidth worse.

Outcome

The platform has been running since launch, covering all the hub stations and hundreds of remote terminals we manage. What makes me most proud isn't a technical metric — it's what an operations colleague said: "Now I don't have to stare at the screen all night shift. If there's a problem, it tells me."

Good tools don't make people look busier. They let people focus their energy on the things that actually require judgment.