Can't do that, don't have the transverters to operate in that range.
bladeRF has a max of 3.8GHz out of the box. But would it be any
different if, keeping everything else the same, the frontend just
transmitted the waveforms on some different frequency (say in the
sub-GHz range) if both Rx and Tx bladeRFs are tuned to the same frequency?
Here, packetspammer is transmitting PDUs in channel 2 (and the AP is
also in the same channel).
On 26 March 2017 at 20:28, Bastian Bloessl <address@hidden
<mailto:address@hidden>> wrote:
Hi,
you should fix the sample rate to 20Msps. Normal WiFi uses 20MHz
channels, the other modes are for 11p or communication between SDRs.
On 03/26/2017 02:51 PM, Anshul Thakur wrote:
> Hi all,
>
> I'm trying to use the gr-ieee802_11 module with bladeRFs to
receive/send
> Wifi packets. However, I am not able to receive anything. Might I
add, I
> am not sure if it is transmitting anything valid either. Here are the
> things that I have done:
>
> 1. Replaced the USRP source/sink modules with osmocom source and sinks
> respectively.
> 2. Generated the hierarchical block.
> 3. Run the wifi_loopback flowgraph and it seems to work. (I am not
sure
> what am I supposed to look at? It shows me the constellation plots for
> various encodings when I change them, and not all of them are
distinct.
> For example, the 64 QAM 3/4 is very noisy and I believe the estimators
> are having a hard time decoding it). Console shows packets of the
form:
>
> new mac frame (length 524)
> =========================================
> duration: 00 00
> frame control: 00 08 (DATA)
> Subtype: Data
> seq nr: 9
> mac 1: 42:42:42:42:42:42
> mac 2: 23:23:23:23:23:23
> mac 3: ff:ff:ff:ff:ff:ff
> instantaneous fer: 0
>
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Sounds good.
> *WiFi Tx:*
> 1. Using wifi_tx.grc to transmit. I have not changed the s-mac, d-mac
> and other parameters (does it matter?).
If the WiFi card is in monitor mode, it doesn't matter. It will just
show all frames.
> Dipole antenna. RF gain values tried are 3dB and 6dB.
> 2. Put my Wifi card (Netgear WNA1100 N150) into monitor mode and
> capturing packets using Wireshark. Directly assigning a channel number
> did not work reliably, so I first configured my Wifi AP and BladeRf Tx
> to use the same channel before putting the device into monitor mode.
You could, for example, check if this is working by using a channel
that's used by another network and see if those frames are picked up.
>
> Using this setup, the bladeRF seems to be in use (the Tx LED blinks).
> Wireshark seems to receive some malformed packets from time to time.
> Like, I've set the PDU length to 200, but I seldom receive a malformed
> packet with a length greater than 61. The packet is not decoded properly.
> *
> *Another scenario:*
> 1. Using wifi_tx.grc to transmit and wifi_rx.grc to receive.
> Here, I've tried even a direct line between the Rx and Tx (Tx of
> the first bladeRF connected to Rx of second with a -20dB attenuator in
> between). No success here either.
>
> Out of curiosity, I've tried to watch the FFT plot at the Rx bladeRF to
> see if I can see power levels rise if some transmissions occur. The FFT
> plot is at 4k FFT with a refresh rate of 20. It is totally silent. For
> comparison, I tried to see the FFT plot of the Wifi band over the air
> also. It does show some spiking activity from time to time (which begs
> the question, what am I supposed to be looking at, but I'll ask that as
> a separate question).
The duty-cycle is quite low (frame time / frame rate). So this makes
sense. If you want to see something send long frames at a high rate (or
use fosphor).
>
> *WiFi Rx:*
> 1. using wifi_rx.grc to receive.
> 2. Put Wifi card into monitor mode and used the packetspammer utility to
> inject packets into it. Wireshark capture at the transmitting machine
> shows packets being put on the interface. I also put my router into
> 802.11g mode to see if that would work, but I am not sure if it is in
> pure g-mode or in 802.11b compatibility mode.
If possible, just use the 5GHz band. This is always OFDM.
>
> No output. What I see at Rx is a fairly continuous value of about 1 unit.
I don't get that part.
Make sure there are no overruns or underruns, i.e., that the device is
able to produce/process the samples fast enough (I'm not sure how the
BladRF driver shows them). Also you could test transceivers that come
with GNU Radio to make sure your general setup is working.
Maybe you can also find something helpful here:
https://www.wime-project.net/installation/
<https://www.wime-project.net/installation/>
Best,
Bastian