Building VadelmaSky.live — From a Simple Idea to a Living ADS-B Dashboard

There are projects that begin with a detailed masterplan.

And then there are projects like VadelmaSky.

A simple idea: “What if I built my own lightweight aircraft tracking page from local ADS-B reception?”

That single thought slowly evolved into a surprisingly polished live aviation dashboard powered entirely by local SDR receivers.

The Beginning

The original goal was intentionally simple:

• Read aircraft data from readsb
• Save daily logs
• Generate static HTML
• Publish automatically to GitHub Pages

The system was built around:

• Raspberry Pi 3B+

• DietPi

• RTL-SDR Blog v3

• ultrafeeder / readsb

• Python

• GitHub Pages

• No databases.

• No frameworks.

• No cloud backend.

Just SDR hardware, JSON, Python and static files.

Exactly the kind of engineering that feels fun.

The Philosophy

One of the core ideas behind VadelmaSky was keeping things lightweight and understandable.

The entire site is generated from local data.

Every aircraft visible on the page was actually received by the local station in Jyväskylä, Finland.

That creates a completely different feeling compared to global flight tracking services.

VadelmaSky is not trying to track the world.

It is documenting: “What did my station hear today?”

That small philosophical difference shaped the entire project.

Features Added Along the Way

The project quickly evolved beyond a simple table.

Live Aircraft Cards

Aircraft are now displayed as responsive cards containing:

• flight number
• ICAO hex
• registration
• aircraft type
• altitude
• speed
• track
• last seen timestamp
• aircraft photo / ADS-B Exchange links

The design gradually evolved into a dark SDR-inspired dashboard aesthetic.

Interactive Map

Leaflet.js was integrated to create a live aircraft map.

Features include:

• dark CARTO basemap
• local receiver marker
• altitude-based colors
• live aircraft positions
• popup information windows

The map became one of the visual centerpieces of the site.

Aircraft Database Integration

tar1090 aircraft database support was added:

/usr/local/share/tar1090/aircraft.csv.gz

This enabled:

• registrations
• aircraft type codes
• richer metadata
• external aircraft photo searches

Without relying on external APIs.

ACARS Integration

The project later expanded beyond ADS-B.

ACARS message logging was added:

• latest messages shown directly on the front page
• tail numbers
• frequencies
• message labels
• signal levels
• raw message contents

This gave the site an authentic monitoring-station feel.

Daily History System

One of the most important design decisions was preserving full-day aircraft history.

Instead of only showing current aircraft, the system stores:

docs/data/YYYY-MM-DD.json

This enables:

• daily statistics
• historical browsing
• aircraft replay potential
• future analytics

Each UTC day automatically becomes part of permanent history.

The “2-Hour Window” Problem

At one point the system experimented with a rolling 2-hour “live window”.

Technically it worked.

Philosophically it failed.

The front page suddenly felt empty and lifeless during quiet periods.

The realization came quickly:

The real value was not: “What is visible right now?”

The real value was: “What has been heard today?”

The system was redesigned back to full-day accumulation while preserving clean history handling.

That change immediately restored the character of the project.

GitHub Pages Automation

The site fully auto-publishes itself.

Pipeline:

• SDR receives aircraft
• Python logger updates JSON + HTML
• Git commit created automatically
• GitHub Pages deploys updates
• Site refreshes globally

The entire site is effectively generated by a Raspberry Pi and SDR receiver.

Which feels wonderfully absurd in the best possible way.

HTTPS, DNS & Git Adventures

Naturally, no real project is complete without a few late-night infrastructure adventures.

Along the way:

• Git rebase conflicts appeared
• GitHub Pages HTTPS provisioning broke temporarily
• Namecheap DNS records needed manual fixing
• stale aircraft logic accidentally erased history
• malformed Python indentation broke builds
• UTC day rollover logic required redesign

Several moments included staring at terminals thinking:

“Why does this suddenly show zero aircraft?”

But each issue refined the architecture.

Visual Identity

VadelmaSky eventually received:

• custom favicon set
• dark dashboard styling
• aircraft cards
• responsive layout
• GitHub Pages custom domain
• polished history pages

At some point the project stopped feeling like “a script”.

It started feeling like an actual service.

Current Architecture

Current stable architecture:

live page keeps full-day aircraft history history pages generated automatically aircraft cards on both live and history pages ACARS integration map visualization automatic Git publishing static GitHub Pages deployment no external backend required

Locked Future Roadmap

The future roadmap is intentionally modest and focused. Planned additions include:

• subtle animations
• aircraft trails on map
• “Top DX Aircraft” of the day
• country statistics
• operator statistics
• aircraft type statistics
• sunrise/sunset information
• reception distance calculations
• lightweight heatmap visualization

The goal is enhancement — not feature bloat.

Final Thoughts

Projects like this are a reminder that some of the most satisfying software is deeply personal.

• Not optimized for scale.
• Not monetized.
• Not chasing trends.

Just a local SDR receiver quietly listening to the sky above Finland and turning radio signals into a living visual archive. And honestly?

That is pretty magical.