You built it. You bolted an ESP32 to a tiny screen, watched planes glide across your desk, and felt that rush of I made this. Except you didn’t. Not really.
The project is beautiful. A sleek desk ornament that shows every aircraft within 200 miles. But here’s the uncomfortable truth: that device is not a radar. It’s a dashboard. A glorified API client.
You’re pulling data from adsb.fi, a crowd-sourced cloud service that aggregates feeds from thousands of real receivers. The ESP32 isn’t listening to the sky. It’s listening to the internet. The actual engineering—the radio wave detection, the decoding, the signal processing—is outsourced to strangers with SDRs and antennas. You’re just the front-end developer of someone else’s infrastructure.
I get it. That stings. Because it touches the raw nerve of what the maker movement has become: a vast ecosystem of beautiful boxes that consume APIs.
We used to build things that sensed the world. A photoresistor that measured light. A thermistor that felt heat. A radio that actually heard the air. Now we build things that fetch the world. Temperature? Here’s an HTTP call to OpenWeatherMap. Plane location? Here’s a WebSocket to adsb.fi. The hardware is just a screen with a Wi-Fi chip.
Look at the comments on that project. People called it out: “Well, a radar-like display, then. But not a radar.” They’re right. And the defensive reply—”It’s a radar display”—misses the point. The point is we’ve lost the appetite for the hard parts.
We’ve become assemblers, not builders. We solder pins, write JSON, and call it hacking. The real engineering is invisible, running on servers we don’t own, maintained by people we don’t know, funded by means we don’t understand. The moment adsb.fi goes down, your radar becomes a brick. The moment they change their API, your firmware breaks. You built a fragile interface to a dependency you can’t control.
This isn’t a rant against the project. It’s a mirror held up to the community. Every time we choose the easy API over the hard circuit, we make a trade. We gain speed. We lose resilience. We gain convenience. We lose understanding.
I remember building a simple AM radio as a kid. The satisfaction wasn’t just hearing a station—it was knowing that the electrons in the wire were literally dancing to the broadcast. That I had made that connection. That’s missing when your “radar” is just a WebSocket client.
So here’s the challenge: next time you build something, ask yourself—am I building a sensor or a sign? Am I reaching into the real world, or am I just fetching from someone else’s database? The maker movement was supposed to be about reclaiming the physical. Not about becoming a better API consumer.
Build a real radar. It’s harder. It’s slower. It might not fit on your desk. But when you see a blip that you detected, with your own antenna, your own decoder, your own code—that’s the feeling we’re all chasing. Don’t settle for the dashboard.
FAQ
Q: Isn't it still impressive to build a device that displays live plane data?
A: Sure, it's a neat project. But it's not a radar. Calling it a radar is misleading—it's a display. The engineering challenge is trivial compared to actually receiving and decoding ADS-B signals. The real impressive work is done by the thousands of people feeding data to adsb.fi.
Q: What's the practical takeaway for makers?
A: Choose your projects wisely. If you want to learn, build the hard part yourself. If you want a quick result, use an API. But be honest about what you built. Don't inflate your effort. The maker movement loses its soul when we mistake assembly for creation.
Q: But isn't using APIs just 'standing on the shoulders of giants'?
A: There's a difference between using a library and outsourcing the entire core function. Using a motor driver chip is standing on shoulders. Pulling all your data from a cloud service is asking for a piggyback ride. The maker spirit is about making things yourself, not just assembling pre-built abstractions.