Thanks for your prompt response!
I have tried connecting the wifi_tx and wifi_rx in loopback configuration.
At 10Packets/s, it would give me a lot of "Warning: starting to receive new
frame before old frame was complete" messages. So quite a lot of packets
didn't reach the MAC decoding stage.
To eliminate the above warning completely, I had to increase the interval
to 20s. But then these sequence numbers have correct checksum values.
There is no under/overflow at the tx/rx in this configuration.I believe
this channel to be quite clean, I checked with the IT department of my
institute and also listened to the channel using a spectrum analyzer. Even
if it weren't, you are right that it shouldn't mess up the same sequence
numbers every time.
Is there something else I could look into?
On Fri, Jan 13, 2017 at 8:30 PM, Bastian Bloessl <bloe...@ccs-labs.org>
> On 01/13/2017 11:17 AM, Nikita Airee wrote:
> > Hi everyone!
> > * Ubuntu 14.04
> > * Gnuradio version : 220.127.116.11, UHD_3.11.0.git-28-gc66cb1ba
> > * 2 USRP 2953R(x310 + cbx40) connected to host laptops using pcie
> > cable, antennae=vert2450
> > * center frequency=2.484GHz, samp_rate=10MHz
> > I have been transmitting at the rate of 10 Packets/s over wireless link
> > with distance between the tx and rx 3m and 6m. tx_gain is set to 30dB
> > and rx_gain to 0. (I have varied these gains to find no improvement).
> > I get a constant total frame error rate at the receiver ~10% for a
> > payload of size 50 bytes. The problem is that the frames for which the
> > checksum fails are always the same sequence
> > numbers(10,12,31,39,49,58,89,93,94,95...).
> > I have tried the different channel estimation algorithms and tried
> > sending the same packet(seq number 0) over and over but still the same
> > numbers are are dropped. I have also increased the interval between
> > transmission to no affect.
> really strange that always the same frames are lost. Can you run the
> flow graph in loopback mode without any hardware (i.e., connect RX to TX
> in GRC), just to rule out any software issues.
> Also assert that there are no overruns (in the receiver) and no
> underruns (in the transmitter).
> There could also be interference on 2.4GHz, but very unlikely that it
> always hits the same frames. I assume you are sending frames that don't
> trigger any response from APs (or other nodes that might be in radio
Discuss-gnuradio mailing list