Why I Build RF Tools in Rust

I built gainlineup to move RF signal-chain analysis out of Excel. The same goal runs through my RF libraries: put recurring calculations in reusable, testable code. The calculation itself was only part of the work. I also wanted a way to inspect the assumptions, repeat an analysis, and understand what changed between versions.

That is what draws me to Rust for engineering tools. A calculation becomes a named function with inputs, examples, and tests. A model can live beside the configuration that produced its result. Those are useful properties when another engineer needs to review the work.

Separate the questions

My RF tools cover related problems, but I keep their responsibilities distinct.

rfconversions handles scalar quantities: power, frequency, wavelength, noise, and compression conversions. It gives repeated equations a name and a place to be checked.

touchstone starts from measured or simulated S-parameter data. Parsing a network file and examining its frequency response is a different problem from describing a chain with scalar gain and noise values.

gainlineup models the stages in that chain. It reports how signal power, noise, and linearity change along the path. I want to see where a constraint enters the system, rather than only a final number.

linkbudget asks whether the whole communications link closes. Transmitter performance, propagation, receiver performance, and modulation assumptions meet there.

These boundaries make the tools easier to explain. They also make it easier to choose the appropriate level of detail for a question. A scalar model should not quietly stand in for a measured network response.

Types help when the model uses them

Rust does not automatically know that one floating-point number represents dBm and another represents watts. A conversion function taking an f64 still depends on its caller supplying the documented unit. Several of my RF interfaces use that approach.

Distinct types can make invalid combinations harder to express. The Rust book describes the newtype pattern for this purpose. But the protection has to be designed into the interface. Choosing Rust alone does not make an RF model unit-safe or physically correct.

That keeps the emphasis where I think it belongs: explicit units, useful tests, and assumptions that another engineer can inspect.

Keep the reasoning next to the result

Python remains useful for quickly exploring a calculation or plotting a result. A spreadsheet can still be a convenient sanity check. I reach for a reusable tool when the same analysis needs to survive changes in inputs, repeated use, or review by someone else.

The result I care about is an analysis whose inputs and behavior are visible. A reviewer should be able to ask which assumption changed and follow that change through the model.

The project outlines describe what these tools currently do. Their repositories hold the installation instructions and examples. Here, the point is the engineering choice: give each calculation a clear responsibility, and make the work possible to repeat.