At full capture rate, the W1700K router's radio produces more raw sample data than its 10Gb Ethernet port can carry. The open-source W1700K SDR project squeezes that stream onto the wire by packing samples on the radio itself. For developers, the result is access to a wide slice of radio activity, provided the receiving computer can keep up. The project's architecture notes put the uncompressed output at 1.28 gigabytes per second.
The repository targets the Gemtek W1700K, using its MediaTek MT7996 radio and Airoha AN7581 system-on-chip to turn the router into a software-defined receiver. It reports capture rates up to 320 million complex samples per second, with 14-bit I and Q components, across its 2.4GHz, 5GHz and 6GHz radio bands. The included browser interface displays a live spectrum and waterfall. These capabilities are documented by the project. MrKeyoor has not tested the hardware.
A sample stream is the material software uses to analyze a radio signal. The I and Q values are its two components, supplied together as a complex sample. Receiver maker Ettus's bandwidth guide explains why sampling rate, usable analog bandwidth and throughput to the host must be assessed separately. A high sample-rate number alone doesn't establish how much spectrum a complete setup can usefully process.
Making the samples fit
At the highest rate, storing each I/Q pair in 32 bits generates that 1.28GB-per-second flow. The architecture document estimates about 1.24GB per second of payload capacity on the Ethernet link. Its solution is to pack half the stream's chunks into 28 bits per pair, without discarding sample information. The radio does the packing before the data reaches Ethernet. A 1GiB buffer on the router absorbs roughly 0.8 seconds of interruption at full rate, according to the data-path description. Buffering at that rate buys fractions of a second.
The router's Linux driver sends buffer slices as UDP datagrams without copying their contents into another buffer. The driver also disables PCIe Active State Power Management: the author reports that leaving it enabled limits device DMA transfers to about 0.33GB per second, below the stream's requirement. Sustaining the advertised rate therefore depends on the bus and network path as well as the capture engine.
Replacing the radio firmware
The firmware documentation describes code built from the repository for the MT7996's RISC-V processors. One image initializes and controls reception, while another handles sample packing. A ROM patch lets the project's images load and reserves memory for capture. The system doesn't load a DSP image. This gives contributors source they can inspect and rebuild for the radio's behavior, rather than requiring a downloaded MediaTek radio firmware binary.
Getting that code to work from a cold start took tracing. The author's development account describes recording register accesses over 69 cold loads of MediaTek's firmware, then reconstructing the operations needed for reception. Capturing from a radio already initialized by vendor firmware was an intermediate step. The replacement had to make reception work after a power cycle, too.
The replacement firmware keeps the MAC transmit path disabled and omits transmit calibration, according to its implementation notes. The project is a receiver. Its tuning and filter controls act through commands to the new firmware, and control operations run in slices between stream chunks so retuning doesn't stall capture. The host can change tuning, gain and the filter while samples continue arriving.
One stream, several consumers
On the receiving Linux machine, w1700k-stream orders incoming datagrams, unpacks samples and publishes them through shared memory. The service documentation specifies a minimum MTU of 8,236 bytes and socket-buffer capacity of 48MiB. It warns that insufficient socket buffers can cause dropped datagrams under load. One service receives the network export; analysis programs attach to its shared ring. Starting a second network receiver would divide the datagrams between receivers.
The same service tags missing samples and checks for stale data repeated from an earlier lap of the capture buffer. Those checks give developers evidence to inspect when a recording looks wrong. Its optional passband correction also changes the samples supplied to every consumer, rather than only changing the display. The correction compensates for the radio's falling response near the band edges, using measurements from the author's unit, as the stream notes explain.
The spectrum server reads that shared stream and presents receiver controls in a browser. It excludes FFT blocks that would cross a sample gap or firmware event. During tuning changes, it also drops affected frames rather than displaying samples from one tuning under another frequency label. That behavior matters if you're using the waterfall to decide when and where a burst appeared.
There are practical limits to the interface. It serves one browser at a time, with a new connection taking over from the previous one. The spectrum server's own default address is localhost on port 8073. Its documented tests use a fake controller and a simulated export over loopback, according to the server README. Those tests exercise software behavior without establishing how a different router or host will perform.
A second of recording is already large
Once the receiver and shared-stream service are running, the included recorder can save samples:
sdr-recv --seconds 1 --out capture.ci16
At 320 million samples per second, the recorder's output format of two 16-bit components makes a one-second capture about 1.28GB before metadata. That's a calculation from the documented rate and format. The recorder allocates recording memory upfront, with a default capacity of 4,096MiB. A ten-second capture at full rate would exceed that default, so duration and memory capacity need to be chosen together.
Lost slices become zeros in the output, preserving their place in sample time. A companion JSON file records losses and overruns, alongside information about the saved run. The recorder's description makes those gaps visible to downstream analysis. A saved file's length alone therefore won't tell you whether every sample arrived.
Installation changes the router
The installation guide requires a 3.3V USB serial adapter connected to the console, a Linux host and an Ethernet connection to the router's lan3 port. The sample stream uses a separate 10Gb Ethernet connection. Before writing the SDR system, the installer makes a whole-NAND backup and extracts the unit's radio calibration. Trying it requires access to the router's console and a host with the right network connection.
Keep that backup. The guide says it contains the stock firmware and factory data, including stock passwords. Installation replaces the operating system, and returning to stock requires a raw NAND writer that the repository doesn't provide. The installer offers a backup-only mode and a serial-number check before writes, described in the same guide. Those provisions help manage the conversion, but the backup doesn't provide a ready-made restore procedure.
The replacement platform runs Linux from a read-only filesystem with a RAM overlay and starts Dropbear for SSH logins using keys. Its build pins upstream inputs by commits or hashes and checks downloaded sources. The author estimates an initial build at about ten minutes plus downloads on a 20-core host. That estimate describes the development setup, rather than a promised build time for your machine.
The next evidence needs another unit
The release checklist says a clean clone builds and passes checks on the development machine. A fresh-machine build and installation, update and recovery on a second unit remain unchecked. The roadmap also lists calibrated power levels and a validated 24-hour stream as unfinished work. Those are concrete limits on how far readers should generalize the author's results.
Watch for the second-unit installation and recovery results, followed by the validated 24-hour capture named in the roadmap. Together, those checks would give a developer evidence about both getting a converted router running and keeping its sample stream intact. They're the next results to examine before planning an experiment that needs to run overnight.