Comment by ChuckMcM
6 hours ago
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?
> 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.
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.
> 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.
2 replies →
> 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.