The packet padding was enabled when I ran the flowgraph earlier with the
pad front/back set to the default values of 1000/100. So I increased the
values of the padding which lead to some improvement. However those
warnings wouldn't go away compeletely for values as high as 10000 zeros.
I compared my flowgraph (PFA: wifi_tx_rx_jan) to the loopback in the
examples folder and couldn't find any difference besides the fact the 3
blocks for channel effects(multiply const, channel model and polyphase
resampler) were not present between the tx and the rx part initially.
With these blocks in between, the frame rate of 10/s doesn't lead to
those warnings. Is that what going wrong or the presence of a channel
shouldn't matter?
Thanks again for your help Bastian,
Nikita
On Fri, Jan 13, 2017 at 10:39 PM, Bastian Bloessl <address@hidden
<javascript:_e(%7B%7D,'cvml','address@hidden');>> wrote:
Hi
On 01/13/2017 05:50 PM, Nikita Airee wrote:
> 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.
You should pad some 0's between frames (as in the example loopback flow
graph). Otherwise, frames are really back to back in simulations.
> 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.
This is very strange. Something seems to go horribly wrong in software,
as these simulations shouldn't depend at all on the frame rate. Maybe
you could check for threads that are in a live-lock (are always at 100%
even if nothing is sent).
I would recommend to try the (unmodified) loopback flow graph in the
examples directory and, then, make your modifications step by step to
see where it goes wrong.
> 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.
Could you maybe upload your project? Or produce a minimal example for
the problem.
Best,
Bastian
> Is there something else I could look into?
>
> Bests,
> Nikita
>
> On Fri, Jan 13, 2017 at 8:30 PM, Bastian Bloessl <address@hidden
<javascript:_e(%7B%7D,'cvml','address@hidden');>
> <mailto:address@hidden
<javascript:_e(%7B%7D,'cvml','address@hidden');>>> wrote:
>
> Hi,
>
> On 01/13/2017 11:17 AM, Nikita Airee wrote:
> > Hi everyone!
> >
> > * Ubuntu 14.04
> > * Gnuradio version : 3.7.10.1, 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
> range).
>
> Best,
> Bastian
>
>
--
Dipl.-Inform. Bastian Bloessl
Distributed Embedded Systems Group
University of Paderborn, Germany
http://www.ccs-labs.org/~bloessl/ <http://www.ccs-labs.org/~bloessl/>