With the ESP32 series of microcontrollers having had hidden software-defined radio (SDR) facility revealed, we’re now moving on from the announcement into projects making use of the finding. [Twotoz] has one using an ESP32-C5, to receive and demodulate analog FM video.
You might think that video is something which has largely gone away in 2026, with TV transmissions having made the switch more than a decade ago, and home entertainment appliances having used HDMI for longer. But it’s still very popular in the world of drones however, where it exists as 5 GHz FM transmission. There’s no digital cliff-edge to lose your picture if you fly into somewhere with bad propagation of radio waves, and perhaps more importantly, it has an extremely low latency. This receiver uses a Seeed Studio Xiao ESP32-C5 board with a simple resistor-ladder DAC to produce the video. It has a simple button channel interface, and a serial link for more in-depth options.
It’s good to see these projects appear, especially as this one’s 5 GHz and shows those chips work too with the hack. We’d be interested to know whether the latency of the SDR affects its usability though. You may be interested to know this isn’t the first time we’ve seen an SDR do video.
Thanks [Ink] for the tip!
Shouldn’t this article get a “llm-assisted project” tag? AGENTS.md is way longer than README.md and the language is, well, kind of strange. Not that I mind, it still looks like an impressive project nonetheless, but the usual pitchfork-wielding crowd might be upset.
It’s a spectacular piece of work.
With the LLM assisted tag, I think the problem is it’ll be increasingly rare any complex project won’t have LLM input if not already, then in the immediate future.
I think it’s a good thing if it means we get fewer sourceless projects that happen people the maker ones just one more look over the code before they make it public.
The LLM should not be used at the top level of the project because it is liable to generate an “unstable architecture”, i.e. it may claim to implement some plan but it doesn’t actually follow it consistently, so letting the LLM be the project architect and designer is a bad idea and leads to unmaintainable projects as the complexity rises. Likewise, letting it be in charge of the documentation (i.e. generating essentially all of it) is liable to introduce hallucinations where the documentation does not match the actual code or the architecture of the program, and that will compound because the LLM will later get confused by its own erroneous comments in the code etc.
It’s so bad at it, that asking for a simple two-state diagram with two conditional state transitions results in errors about 5-10% of the time, so the probability that the AI agent messes something up over hundreds of iterations of “Do this and don’t do anything else” is pretty likely. Yet people believe that telling the LLM “Clean it up but don’t change the logic of this program” will actually make it happen.
That’s why the AGENTS.md is more of a wish list to Santa. If there isn’t a disclaimer that the project is explicitly human designed, managed and validated over the LLM assist, the street-wise approach is to treat it as AI slop by default.
Yes, LLMs can certainly make errors. But the situation is not so dire as you describe. LLMs can find discrepancies in plans and implementation. Maybe not all the time, but that is why your should not be expecting oneshot victories. I am very happy with the results I get with a workflow that can be more or less described as plan->TDD development-> Manual test -> review -> merge
The situation keeps improving, the code you would get one year ago would not be as good as today.
Give me a good reason why I should not treat the actual coding as a black box if it does what I ask it to and I can ask detailed questions about the code (and tests!), so I really be worried what is in the code exactly?
If it works for you, great. But remember that LLMs are fundamentally not reasoning engines, they’re stochastic mad-libs generators. No matter how much they improve, they’re chasing diminishing returns, because there’s always a random chance that the result will be gibberish. If you let the LLM run the project end-to-end, you’re stacking up probability for failure.
If you treat it like a black box and trust what it says it’s doing, that’s like crossing the street eyes without looking because you haven’t been hit by a bus so far…
Because an LLM is not a real reasoning AI, it’s a stochastic mad-libs generator. Treating it as a black-box is like crossing the street without looking because you haven’t been run over by a bus so far…
On the point of “it gets better”, there’s a fundamental limit to random statistical inference – the error rate reduces, but never goes to zero. You’re playing russian roulette with a revolver that has more holes in the drum, but one is always loaded with a round.
“liable to introduce hallucinations where the documentation does not match the actual code or the architecture of the program,”
You mean worse than the documentation most human-documented programs have had since forever? I have doubts.
I’d rather have missing documentation over complete porkies. The point is that most humans can be mostly trusted to not write what they haven’t done or what they don’t know, because of fundamental laziness, instead of making up complete elaborate fabrications simply because it was requested.
I have had absolutely great success using llm building complete projects. Never really had an issue. The best one is my transdroid v3. The original coder actually used most of my code in his update. https://github.com/evilgenius79/transdroid
Yes I also need to clean out my repos of clutter and junk stuff lmao
In this case It is pretty obvious. formatting is the stuff of nightmares in regards of readability (why are LLMs so afraid of newline?) and the project has seen over a 100 releases and nearly 800 deployments within a a month of existing with zero breaks. Does raise some concerns on how stable and if this even works honestly.
Some generated projects are exactly for that point: to look impressive in order to bring credit and credibility to the owners, provided the viewer isn’t an expert and doesn’t actually try to use the code.
Yes, maybe. But why would you if you can make the real thing almost as easy?
Because it isn’t “almost as easy”, the actual coding takes 20% of the time and the testing and debugging takes 80%. The point isn’t making the project, it’s making it look like you did, so you can fool someone into hiring you, or giving you a diploma, etc.
Calm down dude. Its a fckn analog video link on a cheap mcu
Don’t worry about them getting upset. It’s self-inflicted. They could stop being butthurt over others’ projects at any time if they wanted to.
I worry about the signal-to-noise ratio in the comments, that’s all.
😂👍
Hey everyone, Twotoz here!
Just to clarify something: C5VRX was actually the project that first explored and demonstrated the ESP32-C5’s SDR capabilities, roughly six weeks before the other projects appeared. I’m not building on someone else’s recent discoveries. We were exploring this hardware before those findings became widely known.
And yes, C5VRX is heavily AI-driven. Is that a bad thing? Maybe. But it works, and it keeps getting better. :)
As far as I’m aware, C5VRX is currently the only project developing a working analog FPV receiver on the ESP32-C5. If you think you can build something better, please do! Seriously. It’s open source for a reason.
At the end of the day, I’m just a guy trying to build an affordable, open-source alternative to the increasingly expensive traditional analog FPV receiver solutions, so people in the FPV community can enjoy flying analog without spending a fortune.
I’m not claiming the code is perfect. Far from it. Please use your own judgment when reading, using or forking it. Question the code, test it, improve it, or rewrite it entirely. That’s what open source is about.
I’d rather see ten better receivers emerge from this project than keep one imperfect receiver to myself.
The major complaint is about proof and reliability of reporting: the HaD writing staff should not pass projects that are insufficiently validated and verified, because that’s putting the burden of proof on the reader instead of the reporter or the project.
Passing claims and then sending people on a goose chase to confirm that the claims are true is bad reporting.
I have not asked or requested to be posted on this website though.
Although its nice to see the project getting love. But yeah, the project is still very young and needs tons of work.
No, I think that’s outside of the scope of a little blog
Aircraft stuff usually needs a decent risk analysis and some efforts made to get a few more slices of swiss cheese in place to keep people safe. People like YOLO-coding and I get that, but aircraft (even a 200g quadcopter) still carry a potentially risk-profile.
People being people, will simply trust the eyes this code provides them to be faultless, and think they are invincible likely going “WOO \o/ 10kM range across an airport approach”.
I do wonder, could there be even minor regulator or legal blowback on the project where the operator loses video solely due to a edge-case bug and the blinded aircraft goes on to damage to person or property due to that bug? Is there any situation where the responsibility could even remotely shift from operator to maintainer?
Don’t throw the legal side at AI, but hopefully the token-burner can ask the markov-chain: “please list five ethical issues if a bug in this code causes a blinded aircraft, and that goes on to hurt people”.
Maybe the AI might suggest something like; enforced safety click throughs and a GPIO holding a dead-man’s signal high for any other safety system to force descend the aircraft to a safe height when the video stream stops being acknowledged.
Thanks for stopping by.
How does your project compare to TBS Fusion, RapidFire or similar?
I currently have FuriousFPV TrueD in my Fatsharks, but Im always interested in paying less than the $168.99 TBS Fusion is listed for :)
It’s generally a bad idea to pander to that crowd
Do we actually know that this works? Like do we have examples of it in operation?
The project is utterly arcane and the snippets that show how the agent that made all this is operating, suggests that there is very limited testing for the most part. Most if not nearly all releases seem to be a case of “works in theory as it didn’t fail building…” and expecting us to just to trust the agent.
These kind of Agent-made projects tend to make me wary. They look impressive, Monumental even, but despite coming with the standard stuff like a contributors discord and big read-me files. Are rarely meant to be actually used or understood by anyone. I can say it looks impressive, but that is genuinely all i (as a human) can do.
To clarify: by “use” i mean stuff like forking, modifying, integrating, contributing, etc. as usual with open-source. Not just flashing it to a device and then use as is.
I don’t see any.
This is why I’ve been saying that when HaD makes articles about vibe code, they should take the burden of proving that it works to us. If no such proof can be found, don’t make the article.
Otherwise it degrades HaD itself as a meaningful source of information.
Do you mean you don’t see any in the article? I found photos in around 1 minute of looking.
Apparently around the time the article went up. One example popped up. So there is something at least.
But there is a point to be made in that we gotta be carefull in blindly trusting whatever is put in front of us. It is now extremely easy to make something that looks incredibly impressive at a glance only for it to turn out to be ineffective or even just not work.
That or Language models and the agents they power get to the point it can be blindly trusted to make whatever you want without fault or testing. An extremely boring reality that would be, but i know better than to bet against such things.
Looks like it is working to me:
https://github.com/Twotoz/C5VRX/blob/main/docs/hardware/dac-test-pattern.jpg
If you look around the repository, there are images of the prototype and photos of screen output, etc.
Well that is something at least. Though i’m still rather concerned about how that example is one day old, by a 3rd party and kind of squirreled away among a whole heap of documentation meant for agents.
That picture only shows that the DAC works, I couldn’t find anything showing the received signal or any comparisons against conventional video receivers.
I think that might be a good threshold for featuring this type of project on Hackaday in the future: show it actually working first. Doesn’t need to work well, but I can’t judge an FM-demodulating ESP32 beyond “that would be a neat idea” unless I actually see some video from it.
Get used to it. And AI-assisted projects are usually extremely densely documented and easy to understand, I don’t know where people get this myth that AI projects are opaque. Have you ever seen their output? They don’t ever shut up, they document obsessively.
Have you seen the documentation in this repository? It is just endless streams of an agent penning down what it did, what it noticed and that by doing A in hypercombulator B, fresnel C will improve by D without any explanation. While a good chunk of the actual code has no annotation and doing the hard-to-read stacking of instructions into a single line thing.
And this is not isolated. The agents presently being tasked to execute entire projects simply aren’t as chatty as the models we used merely tried to assist with coding last year. Human readability is simply not a concern anymore.
Yes. There is video of it being tested on their discord.
I’ve been doing things in a similar vein with the Xiao C5. I have a few repos with some interesting sdr playground stuff for the c5 on my GitHub, though I don’t think I have made a repo for my FPV research playground. This is yet more great stuff. The last month has been really exciting with all the new capability added, I actually bought an FPV drone. And more esp32’s. A month ago I bought the Cardputer ADV, didn’t take long to become fully addicted.
If you’re into this stuff check my GitHub, I try to fork as much related and interesting material as possible and have some interesting stuff of my own here and there, including SDR for Cardputer ADV which works with espsoup and some other companion app I can’t remember right now. It’s nearly 6am sigh 😔
“You might think that video is something which has largely gone away in 2026” – Hmm, shouldn’t that read “analog video”? Because video is very much still something we use in 2026.