Getting the testmode to run once is pretty easy to be honest. Getting it running continuously without gaps and then extrating the produced firehose of data is where most of the complexity was. At least for me. Also fuzzing for configurations that were not intended. For example, stock tables only allow for up to 40mhz @ 80msps on the 2.4ghz band.
The big advantage of the ESP32 discovery is its availability, while this device is a unique configuration that isn't available in most places.
Sipeed teased a similar hack using some (undisclosed) USB-wifi chip, though I don't take them seriously as none can get their hands on the chips they tend to use.
Many cheap USB 3 Wifi 5/6 dongles out there, based on RTL8852BU and such. Just one QFN IC and XO. Their "firmware" seems to be a binary blob loaded over USB. I'm skeptical that these "testmodes" can be figured out with just bruteforcing, wonder if they load custom firmware for compliance testing or just leave those routines hanging around in release firmware too.
2x 160 can be done pretty easily. Only on same band/LO though. So, only for things like multipath.
4x 80 might be possible, but needs a lot more effort. It is up to 2 ports per icap engine and only one icap engine got coerced into writing to pooled sram. The other 2 could only do their designated regions that are limited to 16KB if I remember right. So continuous reception gets more complicated/precise.
Everything above is from me experimenting with HW. There is no official reference for this stuff. So I may have missed something, and some mentioned limitations may be workaroundable.
