A faster alternative to SPLAT!
If your coverage studies run overnight, this is what changes at 92 ms a map — and, just as usefully, what SPLAT! still does that BALROG does not.
Written for people who already know what an .lrp file is
SPLAT! is a good piece of software. It is free, it is open source, it implements Longley-Rice honestly, it reads SRTM data, it has been maintained for two decades and it has taught a generation of engineers what irregular-terrain propagation looks like. A large share of the people who evaluate BALROG arrive from it. So this page is not an attack on it — it is an answer to one specific question: what would I gain, and what would I give up?
The one thing that actually changes
Both tools compute the same model over the same terrain. The difference is what a single map costs, and therefore what workflow is possible on top of it.
An area coverage study is not one Longley-Rice call — it is millions. On a CPU, one core walks them in sequence. On the reference NTIA implementation, the 5.95 million receiver points of a 0.6° domain take 55 seconds on one core, or 11.4 s sharded across six. BALROG computes the same grid in 92 ms on a consumer RTX 3060, and each further scenario over the same ground — another frequency, another mast height, another reliability quantile — in 51 ms, because the terrain is solved once and not again.
At 55 seconds a map, you plan the runs. You pick three candidate sites because twenty would take the afternoon, you queue the sweep before lunch, and you interpret what comes back. At 51 milliseconds, the map returns inside the working loop: you drag the transmitter and watch the footprint follow it, sweep the band and see where the shadow moves, and ask questions you would not have bothered to queue.
Three things that stop being batch jobs
| Question | At ~55 s a map | At 51 ms |
|---|---|---|
| Twenty candidate sites, one band | 18 min | ~1 s |
| Coverage as a volume: six receiver altitudes, ground to 1000 m | 5 min 30 s | 347 ms |
| A transmitter moving along a track, recomputed at every node | a batch job | ~20 positions / s |
The second row is the one that changes what you can sell, not just how fast you work. A link to an aircraft or a drone is a stack of altitudes, not a footprint on a map — and a stack is unaffordable when one slice costs the best part of a minute. The third row is the same argument for anything that moves: a convoy, a flight path, a temporary mast.
What BALROG does not do
This is the part of a comparison page that is usually missing, so it goes above the pricing rather than below it.
- It is not a GUI, and it draws nothing. SPLAT! hands you a rendered coverage image with a legend and a site report. BALROG hands you a path-attenuation grid in dB — centred on the transmitter or resampled to your own geographic grid — and expects your GIS layer, tile server or mission planner to do the drawing. If you want a picture at the end of a command, SPLAT! is the better answer today.
- ITM only, and not "not yet". SPLAT! also ships ITWOM. BALROG implements the Longley-Rice ITM the FCC's OET-69 procedure rests on, and nothing else — because what was parallelised is that algorithm, not a shell any model can be dropped into. Another model would be new mathematics, not a port. If your study must be ITWOM, this is not a substitute and will not become one.
- It does not read your existing project files. No
.qth,.lrpor.sdf. Terrain goes in as SRTM1/SRTM3.hgtor ESRI ASCII grids; parameters go in as five plain-text files. Porting a study is a morning of scripting, not a click. - It needs an NVIDIA GPU. Any CUDA-capable card; the published figures are from a mid-range gaming one. But there is no CPU fallback that would keep the promise, and we are not going to pretend otherwise.
- It is not free. SPLAT! costs nothing and always will. BALROG is €6,000 per developer per year, with OEM and site terms above that. If your studies genuinely fit in the time you have, that is money for nothing — and we would rather you worked that out on this page than three calls in.
What carries over unchanged
- The same model, and the same parameters you already set: surface refractivity, ground permittivity and conductivity, polarisation, radio climate, the reliability and confidence quantiles, mast and receiver heights. Nothing is hidden behind a default you cannot see.
- The same terrain data. Standard SRTM tiles, one degree each, no conversion step into a private format.
- The same frequency range — 20 MHz to 20 GHz.
- Your existing tooling around it. A single binary and a container image, driven by text files, drops into a pipeline without a framework, a runtime or a network call.
On correctness, since it is the obvious worry
A rewrite that is 598× faster and quietly wrong is worse than an overnight job. BALROG is checked against the same NTIA/ITS reference implementation that sets its speed baseline — not against SPLAT!, and not against a CPU version of itself. On smooth ground the two agree to 0.000 dB across sixteen distances; on 108 m of relief the worst of sixteen probes is 1.122 dB, with fourteen inside 0.2 dB and a median of −0.01 dB. Two residuals are not yet explained, and they are named. The full validation note is here, including the 15 dB error the first honest comparison exposed and the two defects behind it.
How to find out in an afternoon
Two routes, neither of which requires trusting this page:
- Run it in your browser on a real rented GPU, on one of nine sample terrains or on a tile you upload. You will see the engine's own output and its own timings, not an animation.
- Take the 90-day evaluation: the full engine for Linux and Windows, the container image, nine SRTM1 tiles and a working scenario already filled in. Offline licence file, no activation server, no telemetry. Repeat every comparison above on your terrain, your machine, and whatever you use today.