I haven't modified the flowgraphs from the examples folder at all, except changing the variables/values for the experiment. It is for those original flowgraphs of wifi_tx and wifi_rx that I get the deterministic error.
Besides checking the gnuradio threads, is there anything else I could do to find the cause for such errors? Bests, Nikita On Sun, Jan 15, 2017 at 2:26 PM, Bastian Bloessl <bloe...@ccs-labs.org> wrote: > Hi, > > On 01/15/2017 07:03 AM, Nikita Airee wrote: > >> 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? >> > > The receiver calculates the autocorrelation coefficient to detect frames. > If you pad 0's, it will constantly divide by zero, leading to > nondeterminism. With a bit noise (added by the channel model), this is > avoided. > > I have yet to check for the threads, which I will only be able to do >> tomorrow as I dont have access the hardware today. >> Should I upload more of the project? >> > > Depends. If simulations work as expected that will not help much. > I would recommend to start the hardware experiments with the (unmodified) > flow graphs from the examples folder and test whether they also cause this > deterministic errors. > > Best, > Bastian > > > >> Thanks again for your help Bastian, >> Nikita >> >> >> On Fri, Jan 13, 2017 at 10:39 PM, Bastian Bloessl <bloe...@ccs-labs.org >> <javascript:_e(%7B%7D,'cvml','bloe...@ccs-labs.org');>> 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 < >> bloe...@ccs-labs.org >> <javascript:_e(%7B%7D,'cvml','bloe...@ccs-labs.org');> >> > <mailto:bloe...@ccs-labs.org >> >> <javascript:_e(%7B%7D,'cvml','bloe...@ccs-labs.org');>>> 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/> >> >> >> > -- > Dipl.-Inform. Bastian Bloessl > Distributed Embedded Systems Group > University of Paderborn, Germany > http://www.ccs-labs.org/~bloessl/ >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
