RfDownlinkFootprint

Default raster resolution. 128x128 is ~12,900 cells inside the horizon disc, each one link-budget call — measured at 70-190 ms against the protected kernels, which is the same interaction budget the terrain solve holds itself to.

Solve the footprint synchronously. This preserves the original API while sharing the exact same row generator as the non-blocking form.

Solve a footprint in bounded row slices without exposing a partially-filled raster. This is generation-friendly: callers may attach a generation token, cancel superseded work, and swap the returned raster into a primitive only after the promise resolves. RF physics remains in the injected propagation port. The asynchronous boundary only yields between rows of scalar WASM calls; it neither changes the numerical path nor introduces a JavaScript approximation.

Where the transmitter's horizon is.

Everything is derived from two radii and one angle, on the sphere through the sub-satellite point. Using the LOCAL geocentric radius rather than a global mean is what keeps this honest on an oblate Earth: the radius varies by 0.34% from equator to pole, and it is the radius UNDER THE TRANSMITTER that sets its horizon.

With the receiver's elevation angle eps and the nadir angle eta at the transmitter, sin(eta) = (R / r) cos(eps) and the central angle is 90 - eps - eta. At eps = 0 that reduces to the familiar acos(R / r).

The horizon circle, as ground positions.

Drawn as a clamped polyline this is the CRISP boundary of the footprint — the raster fades into it at whatever resolution it was solved at, and a viewer asking "where does this stop" deserves a line rather than a gradient. It is ground geometry, not an orbit, so the path-visualizer law does not apply to it.