The Longest Wave: Testing a VLF Space Link Before Any Hardware Exists

The Longest Wave: Testing a VLF Space Link Before Any Hardware Exists

4
calendar_today agoschedule8 min read
— Originally published at sup4ikxprojects.hashnode.dev

Subtitle: First notes on a jamming-resilient satellite communication channel in the 3–30 kHz band — and the multi‑method computational suite I built to validate it.


Hello, Coderlegion.

This is my first post here — and it starts with a confession: I have spent the last year working on the least trendy part of the radio spectrum. The 3–30 kHz band. Very Low Frequencies. The kind of frequencies that RF engineers usually avoid. The antennas are impossibly long. The data rates are laughable. The components barely exist.

And that is exactly why I think they matter.

This post opens a series of working notes. I will describe the physics, outline the tools I use, and clearly mark what has been validated and what has not. No polished demonstrations — just raw notes from the process.


Why VLF in 2026?

VLF is the band that most engineers would rather forget. Yet for a specific set of missions, it offers something no other band can match: a communication channel that is extremely difficult to disrupt.

Three physical reasons explain this.

1. The Earth–ionosphere waveguide

VLF waves do not readily escape the planet. Between the conductive ground and the lower ionosphere, there is a natural horizontal channel — the Earth–ionosphere waveguide. Signals travel through it for thousands of kilometers with moderate loss. One path can cover a continent. UHF and microwaves have no such mechanism; they rely on line-of-sight or relay networks.

2. Penetration through conducting materials

At kilometer-scale wavelengths, skin effect in seawater and soil is significant but not catastrophic. This is why VLF has been the primary means of communicating with submerged platforms for decades. Regardless of its low throughput, the band offers physical reach through materials that no other band can provide. It reaches places where one would assume communication is impossible.

3. Resistance to jamming

Jamming is a battle of power. To jam a VLF signal, an adversary must overpower a mode that propagates across the entire waveguide over vast distances. It is not impossible — but it is expensive and inefficient. A system that rides the waveguide is harder to knock out than a point-to-point link that depends on a clear line-of-sight.

The tradeoff is well known. VLF provides low data rates: kilobits per second at best, and often just a few bits per second in practice. That is enough for a distress beacon, a navigation fix, or a "still alive" signal — but not for anything resembling broadband. The point is not speed. The point is survival.


The orbital challenge

Putting VLF on a satellite is awkward. A quarter-wave antenna at 10 kHz is 7.5 kilometers long. At 3 kHz, it stretches to 25 kilometers. You cannot fold that into a 10‑kg satellite bus — at least not by any conventional means. And even if you could, the mass, volume, and power consumption would compromise everything else on board.

The real bottleneck is not the antenna itself — it is the entire system budget. Every payload has strict limits on mass, thermal dissipation, and electrical power. The practical threshold for a VLF link from orbit sits at the very edge of what a modern small satellite can support. Engineering operates at that edge, not around it.

This is why simulation is not just an accessory — it is the primary tool. A design that exists only in equations costs nothing to launch. I built a computational framework to obtain quantitative estimates before committing to hardware decisions.


Why multiple methods are necessary

There is no single perfect simulator. Every method — analytical or numerical — provides a partial view. I use these solvers in a hierarchy: from fast approximations (minutes) to full-wave simulations (days). Each serves a different purpose, and none is a substitute for the others.

My rule: a result is accepted only when independent methods, written and run separately, converge to the same answer. This takes more time, but the results withstand scrutiny.

1. Analytical waveguide modes

The oldest tool in the VLF toolbox is the analytical representation of the Earth–ionosphere waveguide as a set of discrete vertical modes. The phase velocity of each mode depends on the effective reflection height, which varies between day and night, across seasons, and during geomagnetic disturbances. These models produce fast, reproducible estimates of phase and amplitude at the receiver. They serve as the foundation for all other solvers.

2. 3D FDTD — full-wave numerical solver

Where analytical models break down — in inhomogeneous media, plasma gradients, localized disturbances — Maxwell's equations must be solved numerically. I use a 3D Finite-Difference Time-Domain implementation with perfectly matched layer (PML) absorbing boundaries and dispersive material models for plasma. The solver has been validated against dipoles and half-space geometries.

Scale: the grid currently runs at several million cells. A single scenario takes about 8–12 hours on 64 cores. This is the most comprehensive — and the most expensive — method in the toolkit.

3. Born approximation — fast estimation

For weak, thin disturbances, the scattered field can be computed using first-order perturbation theory. The 3D Born approximation produces results in minutes, whereas a full FDTD run would take days. This is not a replacement — it is a tool for rapid parameter sweeps. Its results provide a useful baseline as long as the disturbance remains weak.

4. Monte Carlo model for the Bragg peak

Not everything in this problem is an electromagnetic wave. Part of the chain involves energy transport through matter. For this, I use a Monte Carlo model that reproduces the classical Bragg energy-loss curve, including Landau straggling and Molière multiple scattering. The faster transport model is cross-checked against the reference engine described below whenever necessary.

5. Reference engine: GEANT4

When I need a trusted reference for the matter-related part of the problem, I turn to GEANT4. This particle transport framework has been used for decades in thousands of projects on Earth and in space. The atmosphere is modeled in altitude-resolved layers with appropriate densities and elemental compositions. The physics includes standard electromagnetic processes. The output is an altitude-resolved energy deposition profile that the lighter models must reproduce.

To be honest: GEANT4 is overkill for quick estimates. Its real value is reliability. It is a community-validated reference against which I benchmark my own code. A laboratory in software form.

6. NIST data as a reference standard

For stopping powers and electron continuous-slowing-down ranges, I use the NIST reference tables. These are old, well-documented, and reliable. I scale them by density to match the specific problem. Simple, dependable, documented — exactly what I need.

How I cross-validate

The rule is consistent throughout the project: no result is accepted if the methods disagree and I cannot explain the discrepancy. Trust emerges when independent solvers land in the same range. This gives three benefits:

  1. A bug in one solver becomes obvious when other methods diverge.
  2. Results accumulate into a table that is easier to review than a single plot.
  3. Every claim carries a trace of whether it was actually computed and how.

What has been completed

Here is a concrete list:

  • A 3D FDTD solver with absorbing boundaries, plasma dispersion, and tests for stability, energy conservation, and numerical convergence. The grid currently runs at several million cells; a single scenario takes about 8–12 hours on 64 cores.
  • A first-order Born scattering module, validated against reference cases.
  • An analytical mode solver with Sturm–Liouville eigenvalues.
  • A Monte Carlo transport model with straggling and scattering, cross-validated against GEANT4 and NIST tables.

All code is under version control with a test suite. This supports the most valuable habit in software work: the ability to rerun everything and observe what breaks.


What could kill this project

This is the most important part of the post — so please read it carefully.

Everything described above is simulation. No experiment has yet placed the concept — waveguide, plasma, beam — into the real world. There are entire classes of failure that the model does not yet cover.

Let me state this without euphemism: this project is unverified, unproven, and may fail entirely. It is a computational hypothesis, not a working system. Everything in this series should be read as "an idea being tested," not as "a technology that exists."

Here is what the model does not yet address — and any one of these could be fatal:

  • Antenna efficiency and system budget. A VLF antenna on a 10‑kg satellite will have an efficiency far below 1%. The question is whether it is 0.1% or 0.001% — and that difference is three orders of magnitude. I do not yet know where in that range the real system will land.
  • Attenuation budget. Real losses in the interaction layers are not fully known. The tables I use provide certain values, but actual losses could be several times higher in some parts of the channel.
  • Environmental variability. The waveguide height changes with solar activity, time of day, and season. A phase-based signal requires a stable background, which the real ionosphere rarely provides.
  • Mathematical convergence. The methods converge in the weak-disturbance regime. When disturbances become stronger, higher-order contributions diverge, and one of the solvers ceases to be valid.

The most common outcome of a project like this is not success. It is a negative result — and a precise one. If this is where the journey leads, I will publish it with the same level of detail as a success. A falsifiable negative result is as valuable as a plausible positive one — sometimes more.


Why a small satellite?

The satellite is small — about ten kilograms. Most communication satellites weigh hundreds or thousands of kilograms. The point is to see whether the physics of VLF propagation can be made to work from a platform that barely registers on the launch manifest.

The largest hidden risk is not the antenna — it is the entire power chain: supply to the radiating elements, charge balance of the platform, and the environment's own response. All of this is now in the simulation, as separate clocks that must agree. The link either works at the design point, or it does not exist.


What this series will be

A few commitments:

  • A working log. Every number published here will come with a description of how it was produced. A result without reproduction steps is a rumor.
  • A sharpening tool. Physics is best tested by someone who points to the weakest step in the method. If that costs me some false pride — so be it.
  • A dated record. When the final paper comes out — whether the concept lives or dies — this sequence will show who knew what and when. Honesty does not hide behind dates.

A note on omitted details

Some specifics — such as the exact geometry of the radiating element, the waveform structure, and certain link parameters — are not included here. This is a practical choice, not a matter of secrecy. These details are not essential for understanding the validation methodology, and they belong to a later stage of the work. The core physical models and the verification philosophy are fully described above.


So again: welcome. The entire series fits into three sentences. VLF is the most awkward channel in the spectrum. Space makes every antenna a tragedy. And I would rather close a thousand dead ends in the editor than surprise you with a margin that never existed.

If you have your own stories from the low-frequency world — or if you see a flaw in my validation strategy — I would like to hear it. The community at the bottom of the spectrum is small, and that is exactly why we need to keep each other honest.

Drop your questions and comments below. Let's test this hypothesis — together.

🔥 Join developers growing publicly
Share your knowledge, build in public, and grow your developer presence with a global community.

More Posts

The Zero-Net-Loss Fleet & The Mercenary Squad: A Live AI Economy

DEVPlank - Aug 4

The Sovereign Vault — A Comprehensive Guide to Protocol-Driven AI

Ken W. Algerverified - Jun 4

The Audit Trail of Things: Using Hashgraph as a Digital Caliper for Provenance

Ken W. Algerverified - Apr 28

I’m a Senior Dev and I’ve Forgotten How to Think Without a Prompt

Karol Modelskiverified - Mar 19

Local-First: The Browser as the Vault

Pocket Portfolio - Apr 20
chevron_left
126 Points4 Badges
Moscow
1Posts
0Comments
Moscow, building a monopoly, C++ Rust asm, full control, 3D modeling, electronics, system programming from firmware to drivers.

Related Jobs

View all jobs →

Commenters (This Week)

3 comments
1 comment
1 comment

Contribute meaningful comments to climb the leaderboard and earn badges!