Re: [Discuss-gnuradio] Tag preemption USRP sink

On 17 December 2015 at 15:10, Marcus Müller <address@hidden> 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] <
address@hidden> 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>>

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>> <[hidden email]
<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>> <[hidden email]
<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>> <[hidden email]
<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>://
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>://
lists.gnu.org/mailman/listinfo/discuss-gnuradio


_______________________________________________
Discuss-gnuradio mailing list
[hidden email] <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>
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 address@hidden
To unsubscribe from GnuRadio, click here
<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>

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
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.

From:	Saulo Queiroz
Subject:	Re: [Discuss-gnuradio] Tag preemption USRP sink
Date:	Thu, 17 Dec 2015 17:21:42 +0000