Yeah, reading stuff like:

"BRINGUP, from a cold radio: what MediaTek's ROM patch does at download (XO, pin mux, the CONN AFE calibration pulse per band, the A-die TOP init by chip ID, pads and CONN switch, the A-dies' eFuse trims); the UMAC pool layout; the common and per-band PHY initialisation; on each A-die the RF init tables, the resistor calibration and the RC filter calibration; the FEM outputs and the crystal trim."

That's not even some other language poorly translated to English, that's just a bunch of words.

Between stuff like this and math "proofs" that aren't readable either I'm really challenged to see the benefit here.

What I get out of this is that one could, if you had the documentation, write a more generalized SDR application for this hardware than the Wifi7 application. That an LLM model can provoke this behavior seems as a good existence proof perhaps?

▲

Aurornis 6 hours ago | parent | next [-]

> That's not even some other language poorly translated to English, that's just a bunch of words.

The language makes sense if you've worked with radio chips or firmware.

Terms like XO (crystal oscillator) and pin mux (chip pin multiplexer, basically assigning pins to their role) are common for embedded work, not just radio work.

Usually in a project you get that language hidden in a separate implementation doc where casual readers won't get confused by it.

▲

ChuckMcM 6 hours ago | parent [-]

Yes there are radio terms in there. :-) That said, I've written combined firmware/gateware drivers for dedicated radio chips and that paragraph makes little sense to me. Even the RFSoC docs from AMD/Xilinx are better written and they are pretty damn dense.

▲

Aurornis 5 hours ago | parent [-]

> Even the RFSoC docs from AMD/Xilinx are better written

This project isn't meant to be vendor-quality documentation of the chipset. It's a reverse engineering project that succeeded and included enough documentation to build upon.

Comparing a freely shared reverse engineering proof of concept to vendor-provided 1st party documentation is a ridiculous high bar.

This is a cool project that was just shared hours ago. Criticizing it for not being 1st party vendor documentation quality is a really bad faith criticism.

▲

ChuckMcM 4 hours ago | parent [-]

Okay. So let's pretend it is simple a proof-of-concept (PoC) rather than a full blown project, it's opening paragraph in README.md is:

"Turns a Gemtek W1700K Wi-Fi 7 router into a wideband software-defined receiver. The router's MediaTek MT7996 radio captures raw 14-bit IQ at up to 320 Msps, its Airoha AN7581 SoC streams it over 10 GbE, and a Linux host shows it as a live spectrum and waterfall in the browser, with the receiver's controls next to it."

Does that read paragraph say "Hey check out this PoC!" to you?

So a human, used Claude code to reverse engineer a device. Fine, let THAT be the readme. If it had said, "This is something that was accomplished with Claude code reverse engineering this thing, I have no idea how it works, but that it does work is evidenced by the spectrum I can show."

For those of us who are "skilled in the art" as they say, this reads like "Hey check this out, I bypassed the paywall by putting in my Mom's credit card number!" The lede here is that Claude can reverse engineer things. That was most informatively shown with an article that showed up here titled "All the things I own, owned."

The comment I replied to simply said, "Thanks Claude." Which is droll, but accurate. And, for me, the criticism of showing off something you "did" with a tool you don't understand and whose outputs you don't understand, reminds me strongly of the script kiddies of the 90's and naughts who would boldly proclaim "Hey, check it out, I got root on <website>." when all they had done was run Metasploit and walked through a bunch of scripts until they hit an RCE vulnerability and then used it to gain root (with another script).

So at some point the vendor will go through and patch the holes which the model had exploited and they will have to rewrite their admin architecture, and maybe be liable to some fines with the chip companies if "Intellectual Property" was improperly disclosed by their failure to write good software. And are we any closer to using the products as a general purpose SDR? No, we are not.

Contrast that with the folks who reverse engineered the RealTek DVB-T tuner chip, and had an understanding of what they had done and how it worked, and it spawned a bunch of RTL-SDR dongles that introduced lots of people to SDRs.

It is a really cool project, and it is an interesting proof of concept which could be the starting point for reverse engineering these boxes. But the author chose to present it as a complete ready to go project with documentation of things like their "architecture."

I suspect it is also true that neither the author, and certainly not the large language model, has any idea about how this firmware even works.

	▲	bri3d 2 hours ago \| parent [-]
		> So at some point the vendor will go through and patch the holes which the model had exploited and they will have to rewrite their admin architecture, and maybe be liable to some fines with the chip companies if "Intellectual Property" was improperly disclosed by their failure to write good software. And are we any closer to using the products as a general purpose SDR? No, we are not. What? It tunes and it's streaming IQ over Ethernet. It is a general purpose SDR! You can use it as a general purpose SDR immediately. I'd like a little more information from someone who actually knew what they were doing (or even just asked Claude to write it out in more detail) about the "real" nuts and bolts of the receiver, too (how's does IQ imbalance calibration work? How much dynamic range does it really have? How much can we configure the frontend, in detail?), but I don't think it's fair to claim this project is skiddie-level or not useful at this stage just because it was written by Claude. Also, who's going to fine Mediatek for exposing Mediatek IP?

▲

NitpickLawyer 6 hours ago | parent | prev [-]

> I'm really challenged to see the benefit here.

> write a more generalized SDR application for this hardware

Yeahhh, no. Sorry but the entry barrier is now extremely lowered, especially in effort.

~20 years ago this would have been literally sci-fi. Back then just getting an USRP to work with gnu-radio, then finding the proper hardware external clock, then doing lots of work on reading / trying stuff / writing scripts etc. took a ton of effort and time. Having the ability to throw tokens at it and have at least a starting point is amazing, IMO.