How I Would Learn RF Engineering

A comprehensive electronics reading list can be overwhelming. Circuit analysis, electromagnetics, antennas, microwave networks, digital communications, and signal processing each offer enough material to occupy years.

After more than a decade in satellite communications at Viasat, working across Ka, Ku, V, and X-band systems, I would organize my learning around questions I want to answer. A book or tool becomes useful when it helps me understand a part of a real system.

Build a foundation you can use

I would still begin with circuit analysis and electromagnetics. Impedance, phasors, transmission lines, and radiation are ideas that return throughout RF work. Skipping them makes later calculations harder to interpret.

But I would connect the theory to something observable as early as possible. What does a filter do to a signal? What changes when a cable becomes part of the circuit? What would I expect to see in a measurement?

The goal is to explain the behavior well enough to predict it, then find out where that prediction stops being useful.

Keep the system question in view

Satellite communications taught me to look across discipline boundaries. An antenna, an RF chain, and a waveform can each look reasonable on their own while leaving a problem at the system level.

A link budget brings those assumptions together. It asks whether the transmitted signal can arrive with enough quality for the receiver and waveform to do their jobs. Learning that view gives the component-level work a purpose.

I would use a simple link as a thread through the learning: understand its transmitter, path, receiver, and modulation, then return to each part with better questions. The model does not need to be elaborate at the start. It needs to make its assumptions visible.

Build tools when the question repeats

I built my RF libraries to move recurring analysis out of Excel into reusable code. gainlineup handles signal chains, linkbudget tackles the larger communications path, rfconversions replaces repeated conversion formulas, and touchstone works with S-parameter files.

Writing those tools gives the calculations explicit inputs and outputs. It also creates a place for examples and tests. That makes an analysis easier to revisit than a number whose origin has disappeared into a worksheet.

I would not make a new tool for every exercise. A quick plot or calculation can be enough to explore an idea. The reason to build something reusable is that the question keeps coming back and the assumptions need to remain inspectable.

Measure, then return to the model

Theory and simulation give a prediction. Measurement asks whether it describes the hardware in front of you.

I would learn to read network-analyzer and spectrum-analyzer results alongside the underlying concepts. A discrepancy is a useful learning prompt: does the model omit something, does the setup need attention, or have I misunderstood the result?

That loop matters more to me than a fixed timetable for becoming an RF engineer. The work keeps offering new questions.

The path I would keep is to learn enough theory to form a prediction, build or measure something, and use the result to choose the next question. My RFD collection holds the working ideas and references that develop along the way. The portfolio is where I share what that process means for how I work.