Questions about bbn_80211b_rx.py

GNU Radio
1

Hi all,

I am implementing the BBN80211 projects now. I have the following
questions:

I run my receiver (with transmitter off): ./bbn_80211b_rx.py -d 4 -f
2.437G
-b -g 100 -v
The result is:

shine@ubuntu:~/Projects/bbn_80211/branches/usrp2_version/gr-bbn/src/examples$
sudo ./bbn_80211b_rx.py -d 4 -f 2.437G -b -g 100 -v
adc frequency = 100000000
decimation frequency = 4
input_rate = 25000000
gain = 100.0
desired freq = 2437000000.0
baseband frequency 0.0
dxc frequency -37000000.0

gr_fir_ccf: using SSE
Recieved (short) header!
signal: 0x37
service: 0xD9
length: 0xB5D6
crc: 0xAA78
Calculated crc: 0x1DD1
*** BAD CRC ***
Recieved header!
signal: 0xF0
service: 0xAF
length: 0x7367
crc: 0x9C3D
Calculated crc: 0xA7A4
*** BAD CRC ***
Recieved header!
signal: 0xB4
service: 0x4F
length: 0xE127
crc: 0x42E5
Calculated crc: 0x3BA3
*** BAD CRC ***
Recieved (short) header!
signal: 0x0A
service: 0x88
length: 0xBF87
crc: 0xB627
Calculated crc: 0x66E6
*** BAD CRC ***

As you can see, I always fail the CRC check and cannot decode the 80211
packets successfully.

I saw some people encountered the same problems as mine but no solutions
were posted. Can anyone help?

Many thanks!
Curtis

2

Actually, I am going to use the code to receive the 802.11b beacons
transmitted by the commercial APs. However, I always get a bad CRC.
I was told that this code can only work with a BBN code running as the
transmitter. Not a commercial AP.
Did anyone use the USRPs to successfully decode the beacons from APs?

Thanks!

3

You mentioned the transmitter is off.
What happen if you start the corresponding tx?

Another thing is, you may wanna try lower sampling rate by using bigger
decim rate.

Best,
Guanbo

4

I was told that this code can only work with a BBN code running as the
transmitter. Not a commercial AP.
Did anyone use the USRPs to successfully decode the beacons from APs?

I worked on the BBN code before, and I was able to decode Probe
Requests from mobile phones as well as the BBN transmitter.

Actually, I am going to use the code to receive the 802.11b beacons transmitted
by the commercial APs. However, I always get a bad CRC.

I think I found a bug in bbn_slicer_cc.cc that degrades its
performance but I am not too sure how to report the bug.

Anyway, there is a buffer that collects the sum of the magnitude of
each sample in a symbol, in order to determine the offset error for
symbol synchronization. However, the slicer only resets it to zero
during initialization, but it should also be reset every block size.
My fix is as follows:

Index: bbn_slicer_cc.cc

— bbn_slicer_cc.cc (revision 1066)
+++ bbn_slicer_cc.cc (working copy)
@@ -126,6 +126,10 @@
max_idx = i;
}
}
+

  •  for(i=0; i<d_samples_per_symbol; ++i) {

  •    d_sums[i] = 0;

  •  }

 delta = (float)max_idx - d_f_offset;

#if BBN_SLICER_DEBUG

After i applied this fix, the packet error rates seem to be reduced
significantly.

Regards,
Alex

5

I am not sure if you can see the picture attached, so I print out the
result.

shine@ubuntu:~/Projects/bbn_80211/branches/usrp2_version/gr-bbn/src/examples$
sudo ./bbn_80211b_rx.py -d 4 -f 2.412G -b -v
adc frequency = 100000000
decimation frequency = 4
input_rate = 25000000
gain = 0.0
desired freq = 2412000000.0
baseband frequency 0.0
dxc frequency -12000000.0

gr_fir_ccf: using SSE
Recieved header!
signal: 0x0A
service: 0x04
length: 0x0338
crc: 0x09E8
Calculated crc: 0x09E8
Packet Length: 103 bytes.
128 0 0 0 255 255 255 255 255 255 192 193 192 78 119 29 192 193 192 78
119
29 64 142 131 137 23 63 13 0 0 0 10 0 1 0 0 9 100 117 114 104 97 109 51
54
53 1 4 130 132 139 150 3 1 1 5 4 0 1 0 0 221 9 0 16 24 2 0 240 4 0 0 221
24
0 80 242 2 1 1 128 0 3 164 0 0 39 164 0 0 66 67 188 0 98 50 102 0 171
186
167 118
PKT: len=99, rssi=-96, src=c0:c1:c0:4e:77:1D, time=5392, rate=1 Mbps
Payload: ����������Nw���Nw@�?
durham365����� ��P���’�BC�b2f
Recieved header!
signal: 0x0A
service: 0x04
length: 0x0338
crc: 0x09E8
Calculated crc: 0x09E8
Packet Length: 103 bytes.
128 0 0 0 255 255 255 255 255 255 192 193 192 78 119 29 192 193 192 78
119
29 96 142 131 217 23 63 13 0 0 0 10 0 1 0 0 9 100 117 114 104 97 109 51
54
53 1 4 130 132 139 150 3 1 1 5 4 0 1 0 0 221 9 0 16 24 2 0 240 4 0 0 221
24
0 80 242 2 1 1 128 0 3 164 0 0 39 164 0 0 66 67 188 0 98 50 102 0 167
157
54 131
PKT: len=99, rssi=-96, src=c0:c1:c0:4e:77:1D, time=25864, rate=1 Mbps
Payload: ����������Nw���Nw`�?
durham365����� ��P���’�BC�b2f

6

I solved this problem by using WBX daughterboard instead of SBX. Now,
the
USRP2 can decode some packets transmitted by the APs. The result
snapshot
is attached.
I think the problem is caused by low SNR.

However, I still have a few questions:

  1. I think the what I got is 802.11b beacon frame, because the SSID is
    corresponding to my AP. Is it right?
  2. The daughterboard information is :
    WBX 50-2200 MHz Rx/Tx
    https://www.ettus.com/product/details/WBX
    SBX 400-4400 MHz Rx/Tx https://www.ettus.com/product/details/SBX It’s
    weird that I can catch the packet on 2.412G Hz by WBX rather than SBX.
    The
    highest frequency bound of WBX is just 2.2G.
  3. What’s the unit of the RSSI in bbn_80211b_rx.py? The RSSI I got is
    -96,
    if it means -96dbm, that would be too weak for a 802.11b signal.

Curtis

7

I solved this problem by using WBX daughterboard instead of SBX. Now,
the
USRP2 can decode some packets transmitted by the APs. I have posted the
result in last email.
I think the problem is caused by low SNR.

However, I still have a few questions:

  1. I think the what I got is 802.11b beacon frame, because the SSID is
    corresponding to my AP. Is it right?
  2. The daughterboard information is :
    WBX 50-2200 MHz Rx/Tx
    https://www.ettus.com/product/details/WBX
    SBX 400-4400 MHz Rx/Tx https://www.ettus.com/product/details/SBX It’s
    weird that I can catch the packet on 2.412G Hz by WBX rather than SBX.
    The
    highest frequency bound of WBX is just 2.2G.
  3. What’s the unit of the RSSI in bbn_80211b_rx.py? The RSSI I got is
    -96,
    if it means -96dbm, that would be too weak for a 802.11b signal.