Re: [Discuss-gnuradio] Tag preemption USRP sink

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] < ml-node+s4n57342...@n7.nabble.com> 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,

Re: [Discuss-gnuradio] Tag preemption USRP sink

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 > wrote: > >> Hm, that

Re: [Discuss-gnuradio] Tag preemption USRP sink

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

Re: [Discuss-gnuradio] Tag preemption USRP sink

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,

Re: [Discuss-gnuradio] Tag preemption USRP sink

If you're still seeing O's, but they are getting rare, this might be a good time to play the buffer increase tricks again. Cheers, Marcus On 17.12.2015 18:21, Saulo Queiroz wrote: > thanks for the explanation ;) > > On 17 December 2015 at 15:10, Marcus Müller > wrote:

Re: [Discuss-gnuradio] Tag preemption USRP sink

Yes, that is what i'm doing now. On 17 December 2015 at 16:43, Marcus Müller-3 [via GnuRadio] < ml-node+s4n57347...@n7.nabble.com> wrote: > If you're still seeing O's, but they are getting rare, this might be a > good time to play the buffer increase tricks again. > > > Cheers, > Marcus > > On

Re: [Discuss-gnuradio] Tag preemption USRP sink

thanks for the explanation ;) On 17 December 2015 at 15:10, Marcus Müller 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

Re: [Discuss-gnuradio] Tag preemption USRP sink

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]

Re: [Discuss-gnuradio] Tag preemption USRP sink

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

Re: [Discuss-gnuradio] Tag preemption USRP sink

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

Re: [Discuss-gnuradio] Tag preemption USRP sink

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

[Discuss-gnuradio] Tag preemption USRP sink

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