thanks for the explanation ;) On 17 December 2015 at 15:10, Marcus Müller <[email protected]> wrote:
> ha! "O"s in your output mean that the USRP source had to drop samples, > because your computer was slower at processing them than the USRP was at > producing them, filling up the buffers, until they were full to the brim > and nothing more would fit. > Of course, reducing the CPU load in this scenario, e.g. by usage of more > CPU-efficient filters, will reduce the number of dropped samples, and > hence, will reduce the FER! > > > On 17.12.2015 15:14, Saulo Queiroz wrote: > > Yes. > > I forgot to mention that I used QPSK 1/2 in the experiments. > > > On 17 December 2015 at 14:01, Marcus Müller-3 [via GnuRadio] > <[email protected]> wrote: > > > Hm, do you see "O"s on the output? > > On 17.12.2015 15:39, Saulo Queiroz wrote: > > > well, I tried again and, again, FFT behaved better. > In case someone else wanna give a try, flowgraphs are attached. > > > On 17 December 2015 at 12:34, Marcus Müller <[hidden email] > > <http:///user/SendEmail.jtp?type=node&node=57342&i=0> > <http:///user/SendEmail.jtp?type=node&node=57342&i=0>> > > wrote: > > > Hm, that is an interesting result. > > The point is that the polyphase "magic" that allows decimation before > pushing samples through a FIR is mathematically 100% equivalent to > > doing > > the decimation after the FIR. > Nearly the same goes for (non-decimating) FIR vs FFT filter: whereas > > the > > FIR really just "pushes" the samples through convolution with the taps > > in > > time domain, the FFT filter just multiplies the frequency domain > representation of blocks of samples with the frequency domain > > equivalent to > > the taps, before transforming the result back to time domain. Should be > absolutely identical. > > Now, the question is: if the filters were functionally actually 100% > identical, what would explain the different FER? Or are we comparing > > the > > Flowgraph pre-rectructuring with the flowgraph-post-restructuring, > > where > > other things have changed, too? > > Best regards, > Marcus > On 17.12.2015 12:55, Saulo Queiroz wrote: > > Hi > > In my "through-the-air" tests with a couple of B210s the FFT filters > presented much lower > FER in comparison to the FIR filters at the Rx side. According to [1], > > the > > "FFT filters" > downsamples after filtering while FIR downsamples before filtering. > > cheers > > [1] > > http://www.trondeau.com/blog/2014/2/27/to-use-or-not-to-use-fft-filters.html > > On 15 December 2015 at 19:06, Saulo Queiroz <[hidden email] > > <http:///user/SendEmail.jtp?type=node&node=57342&i=1> > <http:///user/SendEmail.jtp?type=node&node=57342&i=1>> <[hidden > email]<http:///user/SendEmail.jtp?type=node&node=57342&i=2> > <http:///user/SendEmail.jtp?type=node&node=57342&i=2>> wrote: > > > Many thanks Bastian! > > I checked the loopback version and it seems to work very well. > > I'll check over-the-air and report here! > > On 15 December 2015 at 19:04, Bastian Bloessl <[hidden email] > > <http:///user/SendEmail.jtp?type=node&node=57342&i=3> > <http:///user/SendEmail.jtp?type=node&node=57342&i=3>> <[hidden > email]<http:///user/SendEmail.jtp?type=node&node=57342&i=4> > <http:///user/SendEmail.jtp?type=node&node=57342&i=4>> > > wrote: > > > Hi, > > I replaced the Frequency Xlating FFT filters with FIR filters, used the > Low-Pass Filter Taps block to generate taps (since I can’t get my head > around this notation), and removed the filter from the first > > conversion. > > Now, it seems to work. At least it receives frames. If you still have > problems I can send you the flow graph. > > Best, > Bastian > > > > On 15 Dec 2015, at 10:05, Saulo Queiroz <[hidden email] > > <http:///user/SendEmail.jtp?type=node&node=57342&i=5> > <http:///user/SendEmail.jtp?type=node&node=57342&i=5>> <[hidden > email]<http:///user/SendEmail.jtp?type=node&node=57342&i=6> > <http:///user/SendEmail.jtp?type=node&node=57342&i=6>> wrote: > > Each stream has been shiffted with the xlating block. > The intention is to "split" a 20 MHz wide analog channel into two of 10 > > MHz. > > Each 10 MHz channel transmit its own ofdm frame. > I attached the flowgraph for more details. > > thanks in advance. > > On 15 December 2015 at 17:42, Martin Braun-2 [via GnuRadio] <[hidden > > email]> wrote: > > tP indicates you're using corrupt tagged streams, maybe your add block > is overlaying them? I'm also not entirely sure what you mean by > 'simultaneous parallel transmissions'. Are they on different > frequencies? Are you mixing them together in baseband? > > Cheers, > Martin > > > On 15.12.2015 04:10, Saulo Queiroz wrote: > > > Hi all, > > I'm trying to Tx a same tagged stream simultaneously through two > > analog > > orthogonal channels. > > The flow path of each stream copy is: resampling, adjust tag lenght > > and > > xlating FFT filter (with shifting). After this I take the output of > > each > > filter and put into and add block then to the USRP sink. I also do the > reverse process at the Rx side. > With some packets are successfuly receive but with so many losses. At > the Tx side I get many "tP". Any tip on how to set simultaneous > > parallel > > transmissions without this? > > I'm using gr-ieee80211 (thanks Bastian and team :) that has worked > nicely with the single channel scenario. > > thanks in advance > > BR > > -- > Saulo Jorge bq > - "Beware of bugs in the above code; I have only proved it correct, > > not > > tried it." > Donald Knuth. > > > _______________________________________________ > Discuss-gnuradio mailing list > [hidden email]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > _______________________________________________ > Discuss-gnuradio mailing list > [hidden email]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > If you reply to this email, your message will be added to the > > discussion below: > > > > http://gnuradio.4.n7.nabble.com/Tag-preemption-USRP-sink-tp57286p57297.html > > To start a new topic under GnuRadio, email [hidden email] > To unsubscribe from GnuRadio, click here. > NAML > > > > -- > Saulo Jorge bq > - "Beware of bugs in the above code; I have only proved it correct, not > > tried it." > > Donald Knuth. > > wifi_tx_rx_loopback.grc (134K) Download Attachment > > View this message in context: Re: Tag preemption USRP sink > Sent from the GnuRadio mailing list archive at Nabble.com. > _______________________________________________ > Discuss-gnuradio mailing [hidden email] > > <http:///user/SendEmail.jtp?type=node&node=57342&i=7> > <http:///user/SendEmail.jtp?type=node&node=57342&i=7>://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- > Dipl.-Inform. Bastian Bloessl > Distributed Embedded Systems Group > University of Paderborn, Germanyhttp://www.ccs-labs.org/~bloessl/ > > -- > Saulo Jorge bq > - "Beware of bugs in the above code; I have only proved it correct, not > tried it." > Donald Knuth. > > > > > _______________________________________________ > Discuss-gnuradio mailing [hidden email] > > <http:///user/SendEmail.jtp?type=node&node=57342&i=8> > <http:///user/SendEmail.jtp?type=node&node=57342&i=8>://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > [hidden email] <http:///user/SendEmail.jtp?type=node&node=57342&i=9> > <http:///user/SendEmail.jtp?type=node&node=57342&i=9>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > _______________________________________________ > Discuss-gnuradio mailing list > [hidden email] <http:///user/SendEmail.jtp?type=node&node=57342&i=10> > <http:///user/SendEmail.jtp?type=node&node=57342&i=10>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below:http://gnuradio.4.n7.nabble.com/Tag-preemption-USRP-sink-tp57286p57342.html > To start a new topic under GnuRadio, email [email protected] > To unsubscribe from GnuRadio, click > here<http://gnuradio.4.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=2&code=c3NhdWxvam9yZ2VAZ21haWwuY29tfDJ8MTQyNzUwNTA3OQ==> > > <http://gnuradio.4.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=2&code=c3NhdWxvam9yZ2VAZ21haWwuY29tfDJ8MTQyNzUwNTA3OQ==> > . > NAML<http://gnuradio.4.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > > <http://gnuradio.4.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > > > > > _______________________________________________ > Discuss-gnuradio mailing > [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Saulo Jorge bq - "Beware of bugs in the above code; I have only proved it correct, not tried it." Donald Knuth.
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
