Decoding WiFi using LimeSDR

Do you mean RX only, TX only or an actual RX+TX ?

RX only should work for some or part of the current 802.11 protocols:

802.11-1997 freq: 2.4GHz                bandwidth: 22MHz
802.11a     freq: 3.7GHz(US only),5GHz  bandwidth: 20 MHz
802.11b     freq: 2.4GHz                bandwidth: 22MHz
802.11g     freq: 2.4GHz                bandwidth: 20MHz
802.11n     freq: 2.4GHz,5GHz           bandwidth: 20/40 MHz       MIMO: up to 4
802.11ac    freq: 5GHz                  bandwidth: 20/40/80/160MHz MIMO: up to 8 
802.11af    freq: 54-790MHz             bandwidth: 6/8MHz          MIMO: up to 4
802.11ad    freq: 60GHz                 bandwidth: 2160 MHz
802.11ah    freq: 900MHz                bandwidth 1-16MHz          MIMO: up to 4

(ref: https://en.wikipedia.org/wiki/IEEE_802.11#Protocol )

So on paper the following should be possible - 1997, a(3.7GHz only),b,g n(MIMO 2* and below), n(2.4GHz only and MIMO 2* and below), af(MIMO 2* and below) ah(MIMO 2* and below)

  • provided that all MIMO channels are within the same 61.44MHz.

e.g. https://www.crowdsupply.com/lime-micro/limesdr-mini/updates/wi-fi-analysis-with-gr-802-11-and-wireshark

TX only would be the restricted to the same 802.11 protocols as RX.
e.g. Wifi signal generator and analyzer application

RX+TX to meet the timing requirements of WiFi protocols would require that the physical layer is implemented inside the LimeSDR on the FPGA, which would be complex and might not be possible (depending on space). The reason is that USB 3.0 has an average latency of 30 μs (one way), so you would double that and allow time for actually processing the data on the host which is going to be way way longer than the WiFi protocol timeout.

The reality is that using multiple WiFi cards in promiscuous mode would be easier for most things, and require much lower processing power on the host computer.

2 Likes