2025 · [radar, rf, dsp, embedded, beamforming, startup]

Software is now a commodity thanks to Claude Code. So the next step is obviously hardware. I spent the last 6 months on building a hardware startup, which was fucking hard.

I made a radar that could classify materials, and this is the story of how I did it as my "end of studies" project. By the way, the project never ended (as you will see down this article, because of a lack of funding)

I live in Europe, where asbestos is a huge and common pain across every country here. That stuff fills walls, and requires people to come at your place to tell you if you have asbestos contaminated materials in your building. If so, you might have been breathing poison since you were a kid. Asbestos gives you cancer, and can fuck you up pretty bad.

The traditional ways of detecting it, is basically to pick a wall sample, send it to a lab, and they tell you if you have asbestos in your walls. Of course, there a lot of intermediaries that come into place to catch a good amount of money based on regulations and your fear of getting poisoned. So a 1$ analysis becomes a 60$ one to the end payer, and when you have to make tens of them, price skyrockets.

The idea

So my project was to build a radar that detects asbestos for you. It's based of material sciences, and wave physics, which happens to be my areas of expertise (recent eng grad). There I had my device plan : make an asbestos sensing radar.

Then, I had to design electronics, so because I am not a bozo, and I hope you are not one either, I ordered dev boards to quickly prototype. In my case : a Texas instrument IWRL6432 BOOST, and an ESP32 dev kit. Assembled them, and started tinkering with DSP algorithms to detect materials.

Built this test bench to test out the electromagnetic response of materials to my special material radar. I could hot swap materials and tighten materials to test out my device.

I finalised my approach with capon beamforming to get a density spectre, which I fed out to a neural network. And this allowed me to classify material surfaces, which under the "same surface, same layer" material hypothesis and "material change is sudden and discontinuous", would then allow me to say "hey this entire layer is made out of x,y,z material."

The Digital signal processing chain

The radar is FMCW : it doesn't emit a single tone, it sweeps its frequency upward over time (chirp). The whole job of the DSP chain is to turn the echoes of those chirps into a material signature. Here is how it works :

• Chirp generation and characterization the TX antennas emit a linear frequency sweep. Everything downstream depends on the exact shape of that sweep (start frequency, slope, bandwidth), so the first thing I had to do was characterize the chirp actually coming out of the front-end.
• Mixing and beat signal the received echo is mixed with the transmitted chirp. What comes out is a low-frequency "beat" tone whose frequency is proportional to the round-trip distance to the reflector.
• Range FFT an FFT on that beat signal turns frequency into distance. Each bin is a depth into the material, so I get reflected energy as a function of range.
• Capon beamforming (AOA) across the MIMO RX array, Capon (MVDR) beamforming resolves the angle of arrival for each range bin, giving a sharp angular density spectrum instead of one blurry return.

The output of all this is a per-range, per-angle density "spectre" the electromagnetic fingerprint of whatever surface sits in front of the radar. That spectre is exactly the tensor I fed to the neural network to classify the material.

I spent two months on this, getting the toolchain right, and on the infamous compile flash debug loop of embedded firmware.

AI part

Since everyone is using AI right now, might as well put some AI in your invention to put new capabilities that you could never before. So what we did is put neural network that ingests the output of the DSP chain, and outputs a class of material.

This model actually "learns" the electromagnetic properties of materials (epsilon' and epsilon''), it's just a classic CNN.

Mechanical & RF

Then, came the mechanical casings, started making a look-a-like, when I finally came to the conclusion that designing around the devboards was a way better approach.

I also went into the rabbit hole of RF prototyping. Ask anyone, they will tell you that RF is straight up black magic. PDEs, Physics, and Chaotic systems, all packed in a single field. So I started modeling my antennas to capture what was happening in my circuit to reverse engineer it.

Here is how I optimized the antenna shapes so that they would have the same characteristics as the ones in the Texas Instrument's one.

Had a parametric simulation I coded inside OpenEMS, which calculated the antenna's characteristics, and then, by extrapolating the transfer functions from TX to RX (Mimo array), I could use convolution operations to simulate how my chirps were emitted, reflected on the surface, and received by the antennas.

I managed to get simulated signatures that were close enough to real measured outputs. And then, it was just a question of getting my hands on materials that contained asbestos.

Little tricks for reverse engineering TI's antennas

Firstly, I used openEMS, an open source alternative to Ansys HFSS (which costs basically a whole kidney to get a license). It uses FDTD simulation to model how the Maxwell equations propagate in materials.

More info about FDTD here : en.wikipedia.org/wiki/Finite-difference_time-domain_method (I used the Yee method).

However, the problem of openEMS is that it doesn't run on GPUs, so you better reduce the size of your simulation (both in the time and space domain) to get results fast, and iterate on it (notably if you are doing a parametric optimization to find the dimensions of your antennas :) ).

So how did I make fast simulations ? I "cheated a bit" : I only calculated the transfer function from TX to RX, and then I used convolution operations to simulate how the simulation would behave if I emitted a chirp, reflected it on a surface, and received it back. This way, I could reduce the simulation time from 1h to 2 minutes on my PC.

A little "Gotcha" : when you want to get the transfer function (this is good signal theory), send a dirac pulse, and you should get the transfer function of the system you are trying to identify. However, a dirac pulse makes the sim go unstable (it just can't converge), therefore, instead of sending a dirac pulse, send a gaussian pulse, and then, in the frequency domain, divide the output by the input to get the transfer function. (works in a funny way with MIMO because it's some sort of matricial division, but it works).

And so, at first I sent out gaussian pulses, and if you did signal theory you know that the fourier transform of a gaussian is a gaussian, but when looking at the output of the simulation, I was getting these weird sinusoidal shapes. Well, also according to signal theory, if the gaussian is NOT centered on zero, you actually get a sinusoidal shape, and the gaussian is just the envelope of that sinusoid.

Used the bode diagram to then convolve the chirp with the transfer function, and get a simulated received signal.

Looking at the results :

Quick side note on asbestos

Asbestos is not really a material as a whole, it is a mineral that looks like a fiber, which is tough to define because there is multiple families of asbestos. The essential part to understand is that it is made out of tiny shards that if breathed can cause severe inflammations in your lungs, and damages it very fast.

More info in this video:

https://www.youtube.com/watch?v=cMx139eTxoc&t=4s

When asbestos is present in a material, it changes it's electromagnetic properties (it's epsilon' and epsilon''), however the big question to answer was : is the radar sensitive enough to tell the difference consistently between a material, and it's same counterpart with asbestos shards and at what concentration ?

Proof of concept

We showed a POC of the material sensing radar, here is the video :

The classifier was trained on the beamforming signatures. Here's how accuracy held up across multiple material layers:

Here is the dict that states which materials are classified : class_dict = { "wood_alu":0, "wood_book":1, "wood_stone":2, "wood_plastique":3, "stone_alu":4, "stone_wood":5, "stone_book":6, "stone_plastique":7, "stone_plexiglas":8, }

Size of the dataset : 500 Kb of Spectral data in each class, in different environments and orientations.

Why we stopped

Unfortunately, due to a lack of funding, we stopped the project there. The details of the story, when I finally had demonstrated a POC, I went up to see customers, but I had a very hard time finding customers that believed in us, they didn't want to sign any LOI before they could get the product in their hands. They also wanted a product that had all European regulation clearances (yes my users were very skeptical). The fact that I had the POC didn't help that much.

However, we achieved a lot of things : making the actual radar work on basic materials (wood, copper, aluminum, plastic, etc), and I also learned a lot about embedded firmware programming, designing a product, and trying to build a hardware startup.

Lessons learned

• When building hardware, always always make a front page to validate willingness to pay : ask for preorders before you start building anything, with a connected stripe preorder system with refund.
• Make a launch video to get early preorders on this, and measure how much you are going to spend on marketing, if no one shows up, you don't have a startup, you have a business.
• Prototype using dev boards, quickly kill useless components, and make the design AS LEAN as possible.
• Design your 3D casings around your electronics, not the other way around, making a PCB is long and lead times even longer.
• Design your product to be upgradable as you get customer feedback, make it OTA updatable, and make the code backwards compatible. This one is my hottest take...
• If you don't know how to do this, use my open core tool that allows you to Claude Code hardware from afar : https://www.nanoforgeflow.com/
• RF is a pain in the ass, avoid it, or find open source tools that allow you to navigate through it.

← back