Overflow

[DiDomenicoSimone]

Hi Bastian, I am using the following setup:

• Ubuntu 16.04.1 LTS 64 bit
• Intel Core i7-3770 CPU@3.40GHz x 8 and 16 GB of RAM;
• Ettus USRP N201 with CBX daughterboard;
• GnuRadio v3.7.10.1;
• I am trying to use "wifi_rx.grc" to receive data from an 802.11g AP;
• Bandwidth = 20 MHz;
• Central frequency = 2.437 GHz (channel 6);
• Sample rate 20 MHz;
• I have already properly set the UDP buffer size (rmem and wmem) and the max shared memory (shmmax);
• I have also set the right priority for real time scheduling;

Using this setup I experience the overflow condition, i.e. uhd prints a lot of "D"s while the receiver is running. Do you have some hints/suggestions? Do you think that by using this hardware I cannot have a receiver which works in real time?.

Thanks a lot in advance, Simone

[bastibl]

The PC should be fine. Please look into frame detection and assert that it is working as intended (no frames when you stop the transmitter and frame detection at about the TX rate.) I assume there is a DC offset that triggers frame detection all the time, completely overloading the receiver.

[DiDomenicoSimone]

Moreover, for almost all of the received packet while running I got the following message: "Dropping frame which is too large".

Eventually, how can I remove this DC offset?

Thanks a lot

[bastibl]

I got the following message: "Dropping frame which is too large".

You could try sending shorter frames.

Before trying to change anything, you will have to investigate the reason for the drops. Use the log and debug options to understand what goes on. You will have to find out where in the process it behaves unexpected. That requires a detailed understanding, but there is no way around that. There are so many things involved, I cannot come up with a comprehensive list of all things that could possibly go wrong.

Once you find the root of the problem, you can think of ways to deal with the issue.

Also make simple test cases. If you stop the transmitter does the receiver stop synchronizing on frames. When you send 1 frame per second, does the receiver detect about 1 frame per second. If you send very large frames and the receiver drops frames because they are too large, try sending shorter frames.

[DiDomenicoSimone]

Ok, I will try to debug each block at a time. In any case, if the DC offset is the problem, how can I fix it?.

[bastibl]

That depends on what causes the DC offset. Since the transmitter is a normal WiFi card, it's unlikely either way. Again, please check first what's going on, then search for a solution. Also make sure that the AP is using pure-G (not the backwards compatible version). Or better switch to the 5GHz band.

[DiDomenicoSimone]

Ok. As soon as possibile I will debug the receiver step by step as you suggest. Thanks a lot.

[DiDomenicoSimone]

Hi Bastian, It seems that I "partially" solved the problem using a local oscillator frequency offset equal to 12.5e6 MHz. In this way the receiver is able to receive correctly data packets from a standard 802.11g AP. However, until now, the receiver is not able to receive the beacon packet sent by the AP. Any ideas?

Thanks, Simone

[bastibl]

I guess the setup is still unreliable. Maybe your data packets are shorter than the beacons. Therefore, data is received while beacons are not. (Btw. APs don't send beacons in all configurations, I assume your AP sends beacons.)