Coder Legion - Recent posts tagged communication

How to Explain a Process with an Animation Explainer

Mon, 26 Oct 2026 09:17:49 +0000

An animation explainer is a short moving picture that makes one idea clear. When the idea is a process, a before and after can carry the whole point: show the starting state, then the ending state, and let the viewer feel the change. Use this shape when the start and end are easy to picture and the middle is short. If the middle is long or branching, show the steps instead.

What matters when you choose an animation explainer?

The starting state and the ending state are both easy to picture.
The change solves a problem the viewer already feels.
The middle fits in a few visible moves.
The viewer can hold both states in mind on one pass.
The ending state removes a real cost, not just tidies it.

If two or three of these are weak, the format is probably wrong. That is not a failure of the idea; it is a sign to choose a different shape.

The decision is not about style; it is about what the viewer needs first. If the change is the news, lead with the change. If the steps are the news, lead with the steps and let the ending state arrive last.

How do you judge each criterion?

Start with the two pictures, not the steps. If you cannot sketch the before and after in a few seconds, the viewer will not hold them either. A messy shared drive and a tidy folder system works because both are visible, while "better data hygiene" is not. If the pictures need the words to make sense, the pictures are not doing the work.

The change has to solve a problem the viewer already feels. If the after state only saves time for the team that runs the process, the before and after will feel like an internal memo dressed up as a story. Tie the ending state to something the viewer loses today: lost files, repeated questions, a task that takes too long, or a handoff that fails. The before picture should make that loss visible in one glance.

Count the moves between the two pictures, not the minutes. If the middle needs more than a handful of actions, the before and after will skip the part that actually matters. In the shared drive example, rename, sort, and remove duplicates is short; adding permissions, naming rules, and training is not. When the middle grows, switch to a step-by-step explainer video and keep the before and after as the first and last frames.

The viewer should see both states without scrolling back or replaying. That means one screen, or one clear transition, not a long tour of details that only make sense in order. If you need a second viewing to compare, the change is too large for this format. A single animated video can still show detail, but only after the main change is locked in and the viewer knows what to look for.

The after state must look like relief, not like a different kind of work. If the new process only moves the pain somewhere else, the before and after will read as a trade, not a win. Name the cost that disappears, and make sure it disappears in the picture, not only in the voiceover. Show the moment the old cost stops, and let the new state stay on screen long enough to feel earned.

The trade-off is simple: clarity now versus completeness later. A before and after buys attention and care; it does not buy a full procedure. If you need the full procedure, plan a second piece.

When you judge the criteria, judge them in this order: pictures first, then pain, then middle, then memory, then relief. If the first fails, stop; the rest do not matter. This order saves time and protects the idea.

Which red flags show it is the wrong choice?

Some processes fight this format. The signs usually show up while you are still planning, before anyone draws a frame or writes a line. If two or more of these are true, plan a step-by-step explainer video instead and keep the before and after for a single closing shot.

The before and after look almost the same on screen.
The process has branches, exceptions, or approvals that carry the real point.
The viewer needs numbers, labels, or a legend to see the change.
The after state needs a long explanation of why it is better.
The middle contains a decision that changes the outcome.
The same process looks different for different people.

These are not small flaws; they are format mismatches. A before and after in an animation explainer works when the change is the story and the steps are short enough to trust. When the steps or the rules are the story, show them in order and let the ending state arrive last. The viewer will still feel the improvement, but they will also understand how to reach it.

Do not force a process into this shape because the pictures look good. The format is a promise that the change is visible and short. Break that promise and the viewer stops trusting the next animation explainer you make.

If only one red flag is true, you may still use the format, but name the limit in the script. Honesty about the limit keeps the piece useful. Hiding it turns a small mismatch into a broken promise.

What should you ask before you commit?

These questions force the change into words before it becomes pictures. If an answer stays vague, the animation will stay vague too.

What exactly changes between the first frame and the last frame?
Can a newcomer name that change in one sentence?
Which step in the middle carries the risk, cost, or delay?
What would make the after state feel unearned?
How will you show the change with pictures before you add words?
Who in the audience will not feel the problem in the before state?

If the last question has no clear answer, the before picture is probably too generic. Fix the before state first; the after state depends on it.

Answer them in plain words before you sketch. If an answer needs a diagram to make sense, the picture is not ready yet. The questions are a filter, not a script.

Frequently asked questions

Can a before and after replace the whole process?

It can replace the overview, not the training. Use it to make someone care about the change, then use a step-by-step format for the actions. If you try to teach every step inside the before and after, the middle will blur and the ending will feel unearned. The viewer remembers the feeling of the change, not the procedure.

A good handoff is to end with one clear next step and a place to find the full steps. That keeps the animation explainer focused on the change while still respecting the viewer who wants to act. The feeling comes first; the procedure follows.

What if the process has more than one good outcome?

Pick the outcome that removes the pain the viewer already knows. Showing two or three endings turns the piece into a comparison chart, which is a different job with different pacing. If the outcomes depend on context, say so in one line and keep the main change simple. You can always end with a short note that other paths exist.

When context matters, name the condition in the voiceover and keep the picture on the main case. The viewer can hold one exception in mind if it is stated plainly. Two exceptions usually need a different format.

How long should the middle part be?

Short enough that the viewer does not lose the thread. If you need to pause, rewind, or add a label to keep up, the middle is too long for this shape. Cut the middle to the moves that change the picture, and move the rest into a later section or a separate explainer video script. The middle is not the place to be complete; it is the place to be believable.

A believable middle has fewer moves than a complete one. When in doubt, cut the middle by half and see if the change still makes sense. Most middles survive the cut better than their authors expect.

Try sketching the before and after on paper before you write a script. If both pictures are clear and the middle fits in a few moves, you have a strong shape for an animation explainer. If not, switch to steps and save the before and after for the final frame.

Unjammable by Physics, Not by Architecture: A VLF Channel from Orbit

Mon, 10 Aug 2026 12:56:50 +0000

Subtitle: Resistance to counter-jamming built into the nature of the band, not into the number of nodes. Slow. Physical. Hopeless for video.

This is the second post in the series. The first one covered the tooling; this one is about what a VLF channel from orbit can do at all, where its limits are, what it depends on, and what that costs.

A fair warning, so nobody builds false expectations: below there will be plenty of talk about "fundamental" and "unjammable", but precisely as much as justified, and not a bit more. We will stop at the honest boundaries of the idea, including the ones behind which our optimism ends.

Why all modern communication is hostage to architecture

Let us start with what happens to fast communication in the moment things turn bad.

Every modern terminal depends on a chain where breaking one link is enough: a repeater, a cable, a beam, an allocated band, a physical object. That is exactly what an adversary with modern electronic-warfare tools does: it does not have to destroy the network wholesale — one careful strike at the right point is enough. At night, at dawn, at the least convenient moment — and the city goes silent, the continent goes silent, the terminal goes silent.

The familiar counter-measure to this disease is to multiply channels. The concept of a dense constellation, where each terminal works with many vehicles at once and losing one node does not kill the link, is not new: this principle, a network of many independent carriers, was originally developed in the Soviet Union back in the 1970s, and today it underlies systems such as Starlink. When people say "unjammable satellite internet", they mean exactly this.

But look closely at the nature of that survivability. It is architectural. It relies on quantity: while there are many components, the network survives; when the enemy removes a sufficient share, it degrades into weak isolated segments, and each becomes a target again. Survivability here is built on duplication, not on the property of the physical channel itself. Many copies make the network blind to one jammer; the essence does not change.

The watershed: architecture today, physics tomorrow

Why now? Because over recent decades electronic warfare has become cheap and mass-produced: a portable jammer can be worth more than an entire network built as a collection of duplicates. The more duplicates, the higher their running cost, and quantity stops helping — for example when many vehicles all work within the same narrow focused beams. A lot of targets does not save you when all targets are cut from the same yarn.

An idea that rests on the nature of the band

My approach is different: a bet on a band where resilience against suppression is baked in at the physics level, not at the level of quantity. Meaning not "add a thousand more nodes", but "the wave carrier itself is arranged so that jamming it means jamming the medium, not the equipment".

This is the key difference: the jammer targets the channel, not a transceiver. In the first case it fights numbers; in the second it would have to rewrite the law of propagation.

Meet VLF. The key numbers are simple: a few kilohertz at the top, wavelengths in the kilometers range — radio waves comparable in size to the terrain they travel along.

Here physics works in favor of communication:

the extreme wavelength does not let the wave hide behind relief or below the horizon — the planet guides it, in the waveguide between the conductive Earth and the lower ionosphere, thousands of kilometers with zero repeaters;
reception does not require line of sight — the wave hugs the surface;
the receiver already sits inside the signal, because the wave embraces the surface.

The main consequence: to jam a VLF, a jammer does not need to aim at one point. Interference travels in the same waveguide as the useful wave, and to choke the path, one must cover the whole territory with noise at once — a huge footprint, or nothing.

Suppression stalls not because there are many nodes. It stalls because the wave has no single point of application that one jammer can "eat".

Where honesty begins: what the channel still depends on

I will not turn the desirable into the actual and promise "vacuum independence". That would be precisely the kind of marketing promise we criticize today.

The channel does not exist on its own. The wave that feeds it is produced by powerful ground transmitters — of which there are a handful in the world. If those stations are down, nothing is transmitted: the source remains ground infrastructure, and it is just as fragile as any critical point.

What is physically protected from jamming is the receiving side and the wave itself inside the channel path. For the waveguide the concept of "switching off a node" does not hold: there is no "server" to attack, the wave is carried by the medium. Survivability belongs to the receiver and the path, not to the source.

So the lower bound of the estimate is precise: the physics of the channel cannot be bent by jamming, but the source remains a risk area. The advantage is real, direct, but bounded.

The speed, worth stating openly

Now for the thing VLF is traditionally laughed at for, and justifiably.

Speed is bits per second, at best kilobits. For a terminal used to megabits and video, this looks like a mockery from a past millennium. No video. No stream. A page takes hours.

But it is a trade-off, not a hole. On such a speed lives exactly what a catastrophe needs to deliver: a short command, an emergency word, a reserve call. Not a permanent stream, but the one key message that has to arrive when the rest of the communication is already silent.

If you need megabits, this channel is not for you, and I will not argue. If you need the last chance itself — here the math is different.

What would be the use, and in what configuration

If the hypothesis clears the run, the channel takes its place not where the bit is cheap, but where nothing else would be left:

a short command at the moment when habitual channels go silent;
a couple of emergency words from a site where a continuous network is no longer guaranteed;
a reserve thread "to survive", until the infrastructure gets back on its feet.

The common ground: they do not need bandwidth, they need the bare possibility. And that possibility has to fit on a platform of dozens of kilograms — an engineering question which, 40 years ago, would have required a station the size of a house. Today compact high-voltage hardware and dense power electronics make the "funny" solvable.

Status: as it is

Everything said so far is a hypothesis.

There is not a single experiment confirming that such a channel works in the real world. The numbers live in calculations, and calculations may give zero. If the idea turns out infeasible, I will publish an accurate negative result and show why: a story of "does not work" is legitimate physics, no less interesting than "works", if it is reproducible.

Instead of a conclusion

The essence is one formula: to build resilience not by repeating copies, but by the property of the wave itself. This transition, from architecture to physics, is what I consider significant — and even if this project never happens, the question is worth asking: can we build a channel for which "jamming" is poorly defined for a fundamental reason?

If you have a comment about the weakest point of this logic, write it — that is why I publish. At the bottom of the spectrum the community is small, but that way I can claim to know every nick.

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

Sat, 08 Aug 2026 17:39:24 +0000

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:

A bug in one solver becomes obvious when other methods diverge.
Results accumulate into a table that is easier to review than a single plot.
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.