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 <[email protected]> > 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 <[email protected]> >> <[email protected]> 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 <[email protected]> >> <[email protected]> >> 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 <[email protected]> >> <[email protected]> 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 >> [email protected]https://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 >> [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
