Decoding WiFi using LimeSDR


I’ve recently given up on using the HackRF One for my purposes of receiving the 2.4GHz WiFi channels (just seems like too many modifications need to take place before the board is capable).

Since looking into LimeSDR, I’ve seen mixed reviews, and haven’t found a concrete answer regarding the question of whether or not LimeSDR is capable of decoding WiFi packets.

As a prospective buyer, any guidance is greatly appreciated,

Thanks in advance

@sfog - Sandy,

In the original design of the LimeSDR, the (then) SoDaRa (what the LimeSDR became - same design) radio was designed for WiFi and Cellular use and marketed that way. Later, with further experimentation, the LimeSDR was found to be a great SDR from HF (2 - 30 MHz) to 3.8 GHz. But the stock LimeSDR is a VERY acceptable SDR for WiFi use and many have already exploited that capability along with GPS, Cellular, Bluetooth and other streaming data modes.

Hope this helps -

Marty (KN0CK)

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: )

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.


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.