The quiet resurgence of RF engineering
atempleton.bearblog.dev
atempleton.bearblog.dev
You make less money, often half. You need to commute to work. Work prospects are narrower and heavily military biased. You get exposed to harmful materials/chemicals. Hardware development is slow, tedious, and punishing compared to software. Having a home lab requires far far more than a laptop. Information is much more sparse so being around knowledgeable others is often critical.
The industry is packed with grey beards, I'm often the youngest guy by 20 years in customer meetings.
Maybe things will change now that we're in a period of uncertainty, but I see hardware as being a thing for the second world and unlikely to stage a big comeback.
To build a $100M software company you need 5 capable friends and a cloud account. To build a $100M hardware company you need $500M.
At least you don't hate your job, I hope? The recent maturation of AI revealed how many people in software seemingly loathe their own profession.
I always had an inkling this was the case, but man it's been depressing to see it laid so bare. So many proudly screaming "I hated programming!". Well, I don't, I love it, and have my entire life, and imagine I'll continue to as long as they will let me...
More relevantly to the article and comment we're replying to: I miss doing firmware engineering. Gosh that is so much fun.
The only thing I can see that acts as a bulwark is liability, bascially. The FW work I was doing requires a human and a large amount of careful review before acceptance. The "throw slop at the wall" that my current job is okay with won't fly there.
But there's _lots_ of FW jobs in consumer gear that is already filled with god awful slop, so maybe it won't take as long as I think.
For personal stuff? Sure.
But I certainly get why people get burned out on corporate programming. It's either tedious busywork following orders designed by architects whose last time writing code was 30 years ago and they never learned anything ever since, waterfall with glaring issues that the lowest rungs are supposed to magically make go away because upper management doesn't want to reset like they're supposed to, or it's "agile" in its various abominations. There's barely any time, budget or possibility left for actually experimenting a bit or for actually crafting out stuff that works. It's all output, output, output, and being micromanaged by Jira or whatever only adds to the dissatisfaction.
Personally, I left the field for good - I'm heading towards electrical engineering. Good luck coding a robot pulling physical wires.
Electricians might be temporarily safe from AI but EEs are knowledge workers too.
"This is wrong, fix it" + recompile, can happen twenty times in ten minutes, but "we discovered the layout is wrong, fix it" is precluded by the cost and time of a new board spin.
AI + text (code) seems like a good match but (E)CAD seems a lot harder to interface AI with. If I'm wrong, I'd like to share that with the EEs on my team, though.
I'm sure it'll happen -- if you can defeat the world Go champion you can certainly route traces -- but so far it seems to be an exception to the bitter lesson, where proprietary hand-tuned algorithms are still on top. Given the lack of large quantities of PCB CAD files that can be appropriated for training, it might be one of those things that has to be self-learned by the AI, again reminiscent of how Alpha Zero worked.
It's being worked on, and as the other commenter said, it's a data problem not a fundamental limitation. That's what's scary to me.
That said the SOTA tools in this space still suck, so it's not here yet :)
I remember my Apple II days (different platform, similarly constrained environment) where every game had a hard real-time multitasking core under all the code. In the Apple II it was particularly critical, because you didn't have programmable sound generators - you had to programmatically change the voltage of the speaker. If you were really crazy, you could do PWM and expect the electronics of the board would coerce your output square wave into something pleasant.
It never worked well, but it was still super cool.
The AI trend and yet another redundancy foreced me to reckon with what I hate about software, which is a tech ethos of "move fast and break things" that runs contrary to "measure twice, cut once". AI also transforms my strengths into executive functioning tasks, which are a mental bottleneck.
There will always be people who work to pay the bills, not to answer some inner call. I am happy - don't tell my boss, but I would do my work for free, including meeting users and extracting requirements (some colleagues say I'd be a master interrogator in another universe).
China has followed Japan and Korea's lead in providing a low cost of capital for domestic companies, so they now have a generation of under-employed technical graduates, as automation replaces the "grunt work".
Hopefully things have improved since then, but my perception at the time was that engineers in the field were paid and treated quite poorly compared to software engineers, despite having a significantly higher barrier to entry in engineering difficulty and technical knowledge.
The hardware team had a team lead at the staff level for years. Software, which had an equal headcount, was compartmentalized below the hardware team.
It was such a massive struggle to get equal salary, or a voice at the table for impacts to the software team.
At one point, IT added some new intrusion detection systems that increased our compile times from 10 seconds to over 600.... And we STRUGGLED to get our issue escalated because "it was a software problem" and the hardware team didnt really care about anything other than hardware issues.
Like imagine grinding an entire division to a halt, and not even raising that concern. Thats a Tier1 issue. It took over a month to get a workaround in place. IT wasnt ever really fixed. We were just told "youre not important enough so youre gonna have to deal with 3x compile times. tough"
But software in general - well, in America - got pulled up into the stratosphere by FAANG money. I feel that should have had more of an effect than it did on non-software orgs.
I’m still so dumbfounded by this. It’s almost 20 years since NVidia introduced CUDA. Developer tooling / experience appears to be something AMD does not understand, for some reason.
I remember my feelings when I learned how to use the Cell's SPUs and how much I didn't want to touch it with a barge pole after that.
I noticed that with mainframes and banks.
IBM makes some really amazing hardware at the very top of the market, but the companies who own those machines don't seem to think any competitive advantage can come from them - they are the cost of doing business. Because of that, the mainframe teams are often neglected.
I would even be happy to write code on the least sexy language ever invented, COBOL, just so it could run on the sexiest hardware ever built.
RF engineering, in particular, is punishing. The subject is viciously hard (you think shared mutable state is hard? Ha!) and, as people pointed out, for most companies, hardware engineering is considered a cost sink, not a revenue driver, something to be avoided if possible. The only parts where it's not is where companies do vertical integration instead of external suppliers.
The big difference to me was that when I was working as a firmware engineer, I was treated like an engineer. For example, if I brought a design concern to my boss it would be seriously considered. In software engineering, on the other hand, I'm basically treated like a bluecollar worker.
I cannot disagree more.
Actually the synergy of software and hardware (primarily due to the increasing popularity of electromagnetics EM spectrums sensing like Radar/LIDAR/mmWave/THz/etc compared to sound) will create unprecedented beyond human perception and intelligence embodied and enhanced by physical AI. Heck the EXG sensings including ECG/EMG/EEG/etc that are technically part of EM, are now generating hundreds of papers/patents/articles everyday in which this product/patent/paper by Meta and its subsidiary CTRL-labs is only the tip of the iceberg [1],[2].
Please check my other comments for more contexts.
[1] A generic non-invasive neuromotor interface for human-computer interaction (Nature article):
https://www.nature.com/articles/s41586-025-09255-w
[2] Meta Ray-Ban Display (2025 - 962 comments):
Apart from that I wonder how much of the resurgence can be traced back to more active conflicts around the world? There is a booming Drone and EW development within the military sector which could be what drives it?
Then you have a lot of work being done on new WiFi standards, satellie antennas, cell network development, and so on.
Also companies like Tarana are building a lot of unique things.
I gave up on OpenEMS.
It will actually be impossible to catch up with China on RF unless the US and Europe legislate for IP (not manufacturing!) to originate in the West. No Huawei 5G, no cheap Chinese SDN/ethernet, etc. Core switching and 5/6G edge. Remove patent protection for 5G designs.
This article also needs a huge (in the US) disclaimer on it as Europe, especially, has had a boom in automotive components and vehicle telemetry in recent years and obviously a lot of consumer devices and handset stuff comes out of China now.
So yeah, I would encourage any EE to look into it, because having an idea about RF can make any electronic design better (especially around things like EMC!)
Since you have an EE background, I would recommend a few strategies (in any order, except 0 should be first if you have major deficiencies):
0) Brush up on some of your math if you need to. Linear algebra (just up to Eigenvector/Eigenvalue), vector calculus, differential equations. Mostly just understanding the concepts is OK, because the major derivations for RF engineering are relatively simple problems. That said, RF engineering is just one big love letter to linear algebra.
1) Read Pozar, as another commenter have suggested, but you don't need to cover-to-cover it. You absolutely must know some network theory, the basics of transmission lines (characteristic impedance, propagation, loaded driving point impedance), and simple matching techniques (basic RF design is about 75% just making sure power goes where you want it to). Beyond that you can pick and choose depending precisely on what you're doing.
2) Read older papers (1940s-1980s depending on topic) on whatever you're interested in. They're going to assume relatively little starting information. The only caveats are that notation has changed and that a lot of the design techniques, while still valid, were more useful when simulators weren't readily available (i.e. they assume a really strong mathematical background).
3) Stay low frequency as much as possible early on. <6 GHz for sure, ideally lower. This makes things a lot cheaper (metrology, components) and makes mechanical tolerances less critical. Stuff just gets less "fiddly". There's of course a tradeoff where things start to get pretty big at low (10-100's MHz) frequencies.
4) Tear apart anything you can get your hands on -- broken metrology equipment for one. Try and figure out why people are doing what they're doing. Just because a system's cheap doesn't mean they aren't using some cool tricks.
People that have multiple degrees are usually pretty weird about it too.
Mostly, expensive tools became more accessible like TinySA, LiteVNA64 and NanoVNA.
For the amateur Ham hobby, it has been a bit of a golden age with <$50 rtl-sdr SDR kits. =3
https://www.mouser.com/c/?marcom=120135054
Combined with a good directional coupler and GPSDO, people do build very high-end pieces of equipment. Not user friendly for most students, but removes a lot of traditional DSP complexity.
Current design limits on bit-resolution and bandwidth are usually just people avoiding getting hit with export restrictions.
The Pluto SDR rich software ecosystem is likely a better option for students:
https://www.analog.com/en/resources/evaluation-hardware-and-...
Have a wonderful day =3
Since you mentioned pySDR: `sdr` is a newer Python library I like https://github.com/mhostetter/sdr
That's a pretty big clue that it is LLM assisted at least. That said, I don't mind. The article has substance and other than a few LLM markers like that, I think it's well-written.
Hubble does the deep RF work so that firmware engineers building IoT devices never have to.
Not an EE myself but honestly baffled how the author got that impression with the huge expansion of RF engineering in the consumer space - particularly with 3/4/5G/LTE networks and 802.1x. Maybe this is just an artifact of working on building weapons (i.e. defense) and being in the US?
Mil systems have severely constrained supply chain limitations too, while consumer vehicle systems can comfortably be produced in their millions from China.
Mil is huge
The product work is higher level system packaging, such as antennas and application-level manipulation of the whole RF block. But since so much is digital now, that is more software/computer architecture work rather than RF. The COTS RF circuit itself may have standardized serial or even packet interfaces to the rest of the product.
If you are budget constrained then you just design your signal chain in discretes like everyone else.
The fact that there is a large market for end-user products does not translate into lots of design teams in a global sense. Much like there are lots of computer use cases but not that many CPU design teams you can really hire into.
Lots of RF devices doesn't actually mean much RF engineering.
If you want 5G connectivity almost everyone buys an integrated module. Chip, antenna, and certifications included. No serious RF engineering required, no RF engineer in the building.
Those modules designers would be purchasing their chip from one of a few companies, like Qualcomm or MediaTek. Even then most of the work isn't RF engineering, it's stitching together a product and grinding through the certifications.
Much of the innovation is done away from the consumer space where certifications are less constraining.
Theres the whole thing where all the wigig chips that dell binned got upcycled into a companies flagship rf product.
Cambium v Ubiquiti has been an ongoing contest. Add Mikrotik in for good measure.
RF Elements is always trying to sell me something new.
Aviat has bought out NEC's famous flagship RF line, at least in terms of US distribution.
Theres enough happening.
Yes. I think American society will struggle to produce enough competent electrical engineers outside of the university system.
> there's going to be some big reorganization to reflect the fact that you can now learn just as well OUTSIDE of a university context
In my experience, very few people like learning the math needed to be competent at RF. It’s hard and exhausting and without a human connection most people are going to bounce. This isn’t like software where if you get it 80% right something still occurs.
I’ve worked with homeschoolers too, and unless they’re the small fraction of people for whom math comes naturally, they’re not going to study it on their own. But that’s exactly the audience one has to reach to grow the EE supply.
These are not topics you will just figure out on your own or "on the job".
People would if they have the incentive to.
I was always amazed at how many game developers learnt fairly deep mathematics and computer science without an academic background.
The other aspect is the professional engineering credentials. At least in Canada Engineering is a protected title. of which the easiest way to get your P.Eng is getting a degree through an accredited engineering program.
There is a reason why so many people from engineering can switch to software while the converse almost never occurs.
If you want to venture or pivot into RF, especially from software background this is the golden time that's made possible/feasible by software-defined radio (SDR) technology as mentioned in the OP article.
One very important thing that the article did not mention is the emerging and increasing popularity of physical AI [2]. RF can be the crucial enabler to to further enhance human limited sensing capabilities with EM based waveforms. A simple analogy is how the dog's powerful smelling capabilities is helping/enhancing human detection capability.
Rather than just training and inferencing on image based I/O, the physical AI now can feed on the much richer RF, mmWave, THz and LIDAR raw waveforms. The good news is that the latter processing of mmWave, THz and LIDAR, can be greatly enhanced by the former lower RF baseband (modulated information signals) that's not previously possible/feasible.
[1] Comments on "ADSY1100-Series: RF System-on-Module Assemblies":
https://news.ycombinator.com/item?id=47821336
[2] What is physical AI?
As a Ham, RF engineering seems interesting, but there's really not much for job prospects. Glassdoor shows 125k Software Engineer jobs and 7k RF Engineer jobs in the US.
Just wondering how an LLM replaces that job …
A basic RF design LLM good enough for low end work will kill the development of human talent, leading to an eventual crunch in lack of advanced skills.
Do undergrad EEs get work as RF engineers? Again, when I went to school, so many of the RF classes were mostly grad school classes, or at very minimum last year undergrad classes. I personally did not have any during undergrad. So many prereq courses.
Even as a dot point mentioning the whole WiGig -> IgniteNet thing? Is that not interesting to you?
cue rimshot
It's more business model than skillset, because RF engineering is, in many ways, so much more technically challenging.
People who care about pay should mostly be thinking about how their potential employers make money. Do they have fat variable margins? Is there volume? Do I have the opportunity to impact those margins in some way? If you do, there's a good chance you can make good money, regardless of the actual technical challenge at hand.
For a lot of RF engineering, the answers are generally no, at least enough such that the general market isn't getting set at a high clearing rate.
Read this https://www.microwaves101.com/encyclopedias/where-are-they-n... and tell me how well this next big surge is going to work out any differnt.
My criticism still stands. If I know what I am searching for, it's easy to find. But often enough have I seen authors use terms which can have multiple meanings and I would need to look at their definitions in parallel of the context of the article, just to understand what it's even about. No thanks, I'll just pick the next HN post instead.