Re: [Discuss-gnuradio] OFDM Constellation Issue

[Martin Braun]

You have windows enabled in the FFTs. Switch to rectangular windows for
OFDM (you can check out the OFDM examples).

M

On 04/16/2016 02:53 PM, Abhinav Jadon wrote:
> Hi,
> I made two flowgraphs.
> 1st flowgraph : Source -> BPSK modulation -> Constellation Sink
> 2nd flowgraph : Source -> BPSK modulation -> IFFT -> FFT ->
> Constellation Sink
> 
> The source is configured such that if only transmits 1s.
> Therefore one would expect the constellation plot to have one dot on the
> x-axis around the point (1,0). This is what happens :)
> But in the second flowgraph one would expect the same result but the
> flowgraph is not what it should look like.
> 
> The link for the screenshots :
> https://drive.google.com/folderview?id=0Bwh_xvBu7PpWaTRZX0VqQzBxNU0=sharing
> p1 and p2 correspond to the second flowgraph
> Regards
> Abhinav Jadon
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


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

Re: [Discuss-gnuradio] matched filter for BPSK produced by phase shifting

[Andy Walls]

On Sat, Apr 16, 2016 at 6:36 PM, Laur Joost  wrote:

> The phase modulation is according to the equation
>
> S(t) = A*cos(2*pi*f*t + s(t)*pi/2),
> s(t) = RRC(2*b(t) - 1)
>
> where
> S - modulated carrier
> A - Amplitude of the modulated carrier
> f - carrier frequency
> s - modulating signal (shaped pulses)
> b - bit value at time t
>

I'm more at home with FSK, but, yeah, putting the RRC filter there doesn't
seem to be the norm for PSK.
(For FSK modulations, the pulse filter is applied to the pulses that make
up the phase term.)



> But I guess that's moot, given the next:
>
> If the transmitter used RRC, the matched filter in the receiver must be the
>> corresponding RRC filter.  If it is not Nyquist, you'll get ISI; if it is
>> Nyquist, you
>> won't get ISI.  You'll have to accept and work with the ISI you get.
>> Also, the receiver should be performing the matched filtering in a
>> demodulation
>> stage that corresponds to where the filter pulses were in the transmitter.
>
>
> I guess the problem becomes one of matching the stages. How do I get a
> continuous (non-mod(2pi)) phase in GnuRadio?
>

Since integral(d(phi)/dt) = phi, maybe something like this:

 -> quad_demod -> iir_filter( b=[1], a=[1 -1], oldstyletaps=False) ->

But you see the problem with that integrator, right.  Just like infinite
phase unwinding, that integrator can blow up.




> I hacked something together, but it has problems when noise causes a
> more-than-pi/2 error, in which case it's suddenly
> amplified to a -3pi/2 error. Though I guess a low-pass filter should limit
> that happening.
>

The RRC filter is a low-pass filter; maybe it will be enough.



> Is there a better way to do this?
>

My comments:
a. I haven't though about the costas loop position and function.
b. The rotator block does a z-plane rotation (aka, discrete freq spectrum
translation with aliases/wrap-around), and not an I/Q plane phase
rotation.  Is a frequency translation by Fs/2 really what you want?  If you
want a phase rotation, just use a multiply const block with a complex
exponential (cmath.exp(1j*phi), IIRC).
c. Your RRC taps would go in the decimating FIR filter.
d. The complex to arg block will be outputting your symbols as +/- pi/2, if
all goes well.  The M block wants peaks nominally at +/- 1.0.  Scale your
RRC filter gain accordingly.
e. Replace the blocks after the M block with a binary_slicer block, to
convert your soft bits to hard bits.  The M block can output a 0, in
which case the divide block will have problems.
f. In the M block, Omega is the nominal samples per symbol and it need
not be integral.  Omega relative limit is the maximum variation in omega
that you allow when recovering timing; in this case 0.005 is 0.5%, which is
pretty tight given an omega of 3.0 samples/symbol.
g. Nothing in this hier block deal with coarse frequency correction or the
phase ambiguity of the initial phase rotation, AFAICT.  Hopefully you're
handling that somewhere else.


>
> ​
>
> I don't think that follows.  Real pulses being input to real functions,
>> yields real
>> outputs.
>> Complex filters are usually only needed when you need filter that is not
>> symmetrical about DC (your channel center, aka your baseband).  If you
>> really
>> are at baseband (which you should be if performing clock recovery),
>> your pulse filter should not be complex, it will be real.  Thus its
>> conjugate will be
>> real.
>
>
> Thank you! That helped me understand something in another flowgraph.
>
>
You're welcome.

Regards,
Andy


> Laur
>
>
>
>
>
> 2016-04-16 23:18 GMT+03:00 Andy Walls :
>
>> Forgot to add the list
>>
>>
>> -- Forwarded message --
>> From: Andy Walls
>> Date: Sat, Apr 16, 2016 at 4:16 PM
>> Subject: Re: [Discuss-gnuradio] matched filter for BPSK produced by phase
>> shifting
>> To: darem...@gmail.com
>>
>>
>> *From*: Laur Joost *Subject*: [Discuss-gnuradio] matched filter for BPSK
>> produced by phase shifting *Date*: Sat, 16 Apr 2016 19:30:29 +0300
>> --
>> >Hi all!
>>
>> Hi.
>>
>> >I need a clue where to start.
>> >
>> >I have a signal that is BPSK that is modulated not by applying the
>> filtered
>> > baseband to the in-phase component, but instead doing literal analog
>> phase
>> > shifting.
>>
>> Please provide a mathematical expression for the above.  The description
>> is too
>> ambiguous.  Something like:
>>
>> m_filt(t) = RRC_filter(m(t))
>> s(t) = sin(w_c *t + pi*m_filt(t))
>>
>>
>> > The result is that the signal transitions between the -1 and 1 symbols
>> not
>> > through zero, but instead along the unit circle.
>>
>> Constant modulus, continuous phase - that's nice to work with.
>> A PLL or a Costas loop should lock and track well.
>> AGC can be simple.
>>
>> > The transmitted baseband is RRC-filtered.
>>
>> Again, a picture, or sequence of mathematical statements describing the
>> modulation would be helpful.
>>
>>
>> > My questions:
>> > 1. Is 

Re: [Discuss-gnuradio] matched filter for BPSK produced by phase shifting

[Laur Joost]

The phase modulation is according to the equation

S(t) = A*cos(2*pi*f*t + s(t)*pi/2),
s(t) = RRC(2*b(t) - 1)

where
S - modulated carrier
A - Amplitude of the modulated carrier
f - carrier frequency
s - modulating signal (shaped pulses)
b - bit value at time t

But I guess that's moot, given the next:

If the transmitter used RRC, the matched filter in the receiver must be the
> corresponding RRC filter.  If it is not Nyquist, you'll get ISI; if it is
> Nyquist, you
> won't get ISI.  You'll have to accept and work with the ISI you get.
> Also, the receiver should be performing the matched filtering in a
> demodulation
> stage that corresponds to where the filter pulses were in the transmitter.


I guess the problem becomes one of matching the stages. How do I get a
continuous (non-mod(2pi)) phase in GnuRadio?
I hacked something together, but it has problems when noise causes a
more-than-pi/2 error, in which case it's suddenly
amplified to a -3pi/2 error. Though I guess a low-pass filter should limit
that happening.

Is there a better way to do this?

​

I don't think that follows.  Real pulses being input to real functions,
> yields real
> outputs.
> Complex filters are usually only needed when you need filter that is not
> symmetrical about DC (your channel center, aka your baseband).  If you
> really
> are at baseband (which you should be if performing clock recovery),
> your pulse filter should not be complex, it will be real.  Thus its
> conjugate will be
> real.


Thank you! That helped me understand something in another flowgraph.

Laur





2016-04-16 23:18 GMT+03:00 Andy Walls :

> Forgot to add the list
>
>
> -- Forwarded message --
> From: Andy Walls
> Date: Sat, Apr 16, 2016 at 4:16 PM
> Subject: Re: [Discuss-gnuradio] matched filter for BPSK produced by phase
> shifting
> To: darem...@gmail.com
>
>
> *From*: Laur Joost *Subject*: [Discuss-gnuradio] matched filter for BPSK
> produced by phase shifting *Date*: Sat, 16 Apr 2016 19:30:29 +0300
> --
> >Hi all!
>
> Hi.
>
> >I need a clue where to start.
> >
> >I have a signal that is BPSK that is modulated not by applying the
> filtered
> > baseband to the in-phase component, but instead doing literal analog
> phase
> > shifting.
>
> Please provide a mathematical expression for the above.  The description
> is too
> ambiguous.  Something like:
>
> m_filt(t) = RRC_filter(m(t))
> s(t) = sin(w_c *t + pi*m_filt(t))
>
>
> > The result is that the signal transitions between the -1 and 1 symbols
> not
> > through zero, but instead along the unit circle.
>
> Constant modulus, continuous phase - that's nice to work with.
> A PLL or a Costas loop should lock and track well.
> AGC can be simple.
>
> > The transmitted baseband is RRC-filtered.
>
> Again, a picture, or sequence of mathematical statements describing the
> modulation would be helpful.
>
>
> > My questions:
> > 1. Is Raised Cosine even a valid Nyquist filter for such a signal? After
> all, the
> > actual In-phase transition occurs not according to the RRC response, but
> > according to the sine OF the RRC.
>
> Well, the Nyquist filter criteria can't be rigorously evaluated without an
> expression
> to work with.  But it really doesn't matter.
>
> If the transmitter used RRC, the matched filter in the receiver must be the
> corresponding RRC filter.  If it is not Nyquist, you'll get ISI; if it is
> Nyquist, you
> won't get ISI.  You'll have to accept and work with the ISI you get.
>
> Also, the receiver should be performing the matched filtering in a
> demodulation
> stage that corresponds to where the filter pulses were in the transmitter.
>
>
> > 2. The response of such a modulator to a unit impulse is necessarily
> complex.
>
> I don't think that follows.  Real pulses being input to real functions,
> yields real
> outputs.
>
>
> > From what I gather, the matched filter is then, also complex (time
> reversed and
> > conjugated).
>
> Complex filters are usually only needed when you need filter that is not
> symmetrical about DC (your channel center, aka your baseband).  If you
> really
> are at baseband (which you should be if performing clock recovery),
> your pulse filter should not be complex, it will be real.  Thus its
> conjugate will be
> real.
>
> >How should I go about this in GnuRadio, given that the PFB Clock
> > sync only takes real taps?
>
> Do a separate matched filter with an FFT or FIR filter block, and follow
> that with
> an M clock sync block.
>
> With a separate matched filter block, you unfortunately cannot use the
> PFB clock sync block.  It works with a peaked matched pulse filter and
> that filter's derivative, so passing in a trivial filter like
> [1,1,1,1,1,1,...,1] will cause the PFB clock sync block to crash.
>
>
> > 3. Or can I just take the real part of the matched filter and feed that
> to PFB
> > Clock sync? The constellation will have a weird spread (see picture).
> Will
> > that affect either 

[Discuss-gnuradio] OFDM Constellation Issue

[Abhinav Jadon]

Hi,
I made two flowgraphs.
1st flowgraph : Source -> BPSK modulation -> Constellation Sink
2nd flowgraph : Source -> BPSK modulation -> IFFT -> FFT -> Constellation
Sink

The source is configured such that if only transmits 1s.
Therefore one would expect the constellation plot to have one dot on the
x-axis around the point (1,0). This is what happens :)
But in the second flowgraph one would expect the same result but the
flowgraph is not what it should look like.

The link for the screenshots :
https://drive.google.com/folderview?id=0Bwh_xvBu7PpWaTRZX0VqQzBxNU0=sharing
p1 and p2 correspond to the second flowgraph
Regards
Abhinav Jadon
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Fwd: matched filter for BPSK produced by phase shifting

[Andy Walls]

Forgot to add the list

-- Forwarded message --
From: Andy Walls
Date: Sat, Apr 16, 2016 at 4:16 PM
Subject: Re: [Discuss-gnuradio] matched filter for BPSK produced by phase
shifting
To: darem...@gmail.com


*From*: Laur Joost *Subject*: [Discuss-gnuradio] matched filter for BPSK
produced by phase shifting *Date*: Sat, 16 Apr 2016 19:30:29 +0300
--
>Hi all!

Hi.

>I need a clue where to start.
>
>I have a signal that is BPSK that is modulated not by applying the filtered
> baseband to the in-phase component, but instead doing literal analog
phase
> shifting.

Please provide a mathematical expression for the above.  The description is
too
ambiguous.  Something like:

m_filt(t) = RRC_filter(m(t))
s(t) = sin(w_c *t + pi*m_filt(t))


> The result is that the signal transitions between the -1 and 1 symbols
not
> through zero, but instead along the unit circle.

Constant modulus, continuous phase - that's nice to work with.
A PLL or a Costas loop should lock and track well.
AGC can be simple.

> The transmitted baseband is RRC-filtered.

Again, a picture, or sequence of mathematical statements describing the
modulation would be helpful.


> My questions:
> 1. Is Raised Cosine even a valid Nyquist filter for such a signal? After
all, the
> actual In-phase transition occurs not according to the RRC response, but
> according to the sine OF the RRC.

Well, the Nyquist filter criteria can't be rigorously evaluated without an
expression
to work with.  But it really doesn't matter.

If the transmitter used RRC, the matched filter in the receiver must be the
corresponding RRC filter.  If it is not Nyquist, you'll get ISI; if it is
Nyquist, you
won't get ISI.  You'll have to accept and work with the ISI you get.

Also, the receiver should be performing the matched filtering in a
demodulation
stage that corresponds to where the filter pulses were in the transmitter.


> 2. The response of such a modulator to a unit impulse is necessarily
complex.

I don't think that follows.  Real pulses being input to real functions,
yields real
outputs.


> From what I gather, the matched filter is then, also complex (time
reversed and
> conjugated).

Complex filters are usually only needed when you need filter that is not
symmetrical about DC (your channel center, aka your baseband).  If you
really
are at baseband (which you should be if performing clock recovery),
your pulse filter should not be complex, it will be real.  Thus its
conjugate will be
real.

>How should I go about this in GnuRadio, given that the PFB Clock
> sync only takes real taps?

Do a separate matched filter with an FFT or FIR filter block, and follow
that with
an M clock sync block.

With a separate matched filter block, you unfortunately cannot use the
PFB clock sync block.  It works with a peaked matched pulse filter and
that filter's derivative, so passing in a trivial filter like
[1,1,1,1,1,1,...,1] will cause the PFB clock sync block to crash.


> 3. Or can I just take the real part of the matched filter and feed that
to PFB
> Clock sync? The constellation will have a weird spread (see picture).
Will
> that affect either Costas or PFB?

Again, I don't think a complex baseband pulse filter makes sense.

BTW, on a slightly related note, taking only the real part of a _signal_
before
obtaining proper phase offset and bit timing is not a good idea.
You will degrade your SNR.



Depending on the the mathematical expression the modulator is
actually implementing, you may have to do something a little
different than the textbook GNURadio BPSK demodulation steps.

> PS: The positioning of the constellation plots was not planned.
>
> All the best,
> Laur

Regards,
Andy
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] matched filter for BPSK produced by phase shifting

[Laur Joost]

Thanks for the response, Marcus!

Analog phase modulator, is more correct I guess.

The RRC filtered signal goes into a signal generator's external modulation
input, and I'm receiving the signal from the generator with USRP.

So: PRBS source (random devboard) -> RRC and DC offset (some IC) -> Phase
modulation +- pi/2 (R SMHU signal gen) ->
-> USRP N210 -> GnuRadio -> PBKAC

is the current signal chain.

About the envelope:

Isn't "Special Case of QAM, not PM" what is usually understood as BPSK
nowadays, when pulse shaping is applied? I've been looking for a relevant
citation in textbooks, haven't found one...

Laur

2016-04-16 20:00 GMT+03:00 Marcus Müller :

> Hi Laur,
>
> On 16.04.2016 18:30, Laur Joost wrote:
>
> Hi all!
>
> I need a clue where to start.
>
> I have a signal that is BPSK that is modulated not by applying the
> filtered baseband to the in-phase component, but instead doing literal
> analog phase shifting.
>
> The result is that the signal transitions between the -1 and 1 symbols not
> through zero, but instead along the unit circle.
>
> Well, that's a good thing, envelope-wise :)
>
>
> The transmitted baseband is RRC-filtered.
>
> Wait, so you got
>
> BPSK symbols (-1,+1,+1,-1...) --> RRC --> analog phase shifter?
>
> Or how do I have to read that?
> That would sound like you had two pulse shapers!
>
> Cheers,
> Marcus
>
>
> My questions:
> 1. Is Raised Cosine even a valid Nyquist filter for such a signal? After
> all, the actual In-phase transition occurs not according to the RRC
> response, but according to the sine OF the RRC.
>
> 2. The response of such a modulator to a unit impulse is necessarily
> complex. From what I gather, the matched filter is then, also complex (time
> reversed and conjugated). How should I go about this in GnuRadio, given
> that the PFB Clock sync only takes real taps?
>
> 3. Or can I just take the real part of the matched filter and feed that to
> PFB Clock sync? The constellation will have a weird spread (see picture).
> Will that affect either Costas or PFB?
>
> PS: The positioning of the constellation plots was not planned.
>
> All the best,
> Laur
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] matched filter for BPSK produced by phase shifting

[Marcus Müller]

Hi Laur,

On 16.04.2016 18:30, Laur Joost wrote:
> Hi all!
>
> I need a clue where to start.
>
> I have a signal that is BPSK that is modulated not by applying the
> filtered baseband to the in-phase component, but instead doing literal
> analog phase shifting.
>
> The result is that the signal transitions between the -1 and 1 symbols
> not through zero, but instead along the unit circle.
Well, that's a good thing, envelope-wise :)
>
> The transmitted baseband is RRC-filtered.
Wait, so you got

BPSK symbols (-1,+1,+1,-1...) --> RRC --> analog phase shifter?

Or how do I have to read that?
That would sound like you had two pulse shapers!

Cheers,
Marcus
>
> My questions:
> 1. Is Raised Cosine even a valid Nyquist filter for such a signal?
> After all, the actual In-phase transition occurs not according to the
> RRC response, but according to the sine OF the RRC.
>
> 2. The response of such a modulator to a unit impulse is necessarily
> complex. From what I gather, the matched filter is then, also complex
> (time reversed and conjugated). How should I go about this in
> GnuRadio, given that the PFB Clock sync only takes real taps?
>
> 3. Or can I just take the real part of the matched filter and feed
> that to PFB Clock sync? The constellation will have a weird spread
> (see picture). Will that affect either Costas or PFB?
>
> PS: The positioning of the constellation plots was not planned.
>
> All the best,
> Laur
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] Overflow error in benchmark receiver side "DDDD"

[Marcus Müller]

Hm, those are usually good. What's the exact model ("lspci" will tell)?
What's your OS?


On 16.04.2016 18:10, monika bansal wrote:
> Hi Marcus
>
> The network card is PCI Express Gigabit Ethernet Controller with 1Gbps
> capacity.
>
> Thanks,
> Monika
>
> On Fri, Apr 15, 2016 at 6:38 PM, Marcus Müller
> > wrote:
>
> No harm done :) So the point is that  is still pretty bad, and
> usually shouldn't happen, unless your PC is *much* too slow, and
> usually would be preceeded by a couple of "O".
> There's two cases where this doesn't happen:
> * Too small network buffers
> * strangely misbehaving network hardware.
>
> So: what is your network card?
>
> Best regards,
> Marcus
>
>
> On 15.04.2016 14:32, monika bansal wrote:
>> Yes my mistake :). Sorry for that. I just did not think of the
>> python block at that time and then after i realized.
>>
>> Regards,
>> Monika
>>
>> On Fri, Apr 15, 2016 at 5:17 PM, Marcus Müller
>> > wrote:
>>
>> Monika,
>>
>> no offense, but when you report a problem with software, it's
>> pretty crucial you point out whether you've modified the
>> software or not :)
>>
>> Best regards,
>> Marcus
>>
>>
>> On 15.04.2016 06:28, monika bansal wrote:
>>> Hii,
>>>
>>> Thank you for your help. 
>>> That "" issue is not coming with original benchmark files.
>>> I added one python block in between the chain in benchmark
>>> code. I think due to which it was not fast enough to process
>>> the incoming data resulting "" issue.
>>>
>>> Regards,
>>> Monika
>>>
>>> On Tue, Apr 5, 2016 at 11:51 PM, >> > wrote:
>>>
>>> What if you make the file "/dev/null" -- does this still
>>> happen?
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>> On 2016-04-05 14:12, monika bansal wrote:
>>>
 Hii,

 I am running benchmark code and on the receiver side
 after receiving some number of packets(8000 so), it
 starts showing overflow errors ("") on terminal.
 Following is the system configuration

 python benchmark_rx.py -f 1100M --args
 "addr=10.32.38.163"
 --to-file=/home/ashokbandi/GNU/a_rx.txt --bandwidth=50

 Decreasing the bandwidth delays the error.
  
 I tried changing buffer size by setting
 net.core.rmem_max and net.core.wmem_max to 33445532 but
 to no avail.


 Following is the screen shot of terminal

 DDok: True  pktno: 24116  n_rcvd: 9730
  n_right: 9723
 ok: True  pktno: 24182  n_rcvd: 9731
  n_right: 9724
 DDok: True  pktno: 24319  n_rcvd:
 9732  n_right: 9725
 ok: True  pktno: 24442  n_rcvd:
 9733  n_right: 9726
 DDDok: True  pktno: 24477  n_rcvd: 9734
  n_right: 9727
 Dok: True  pktno: 24568  n_rcvd: 9735
  n_right: 9728
 
 Dok:
 False  pktno: 22729  n_rcvd: 9736  n_right:
 9728


 Thanks

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org 
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>>
>
>

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

Re: [Discuss-gnuradio] UHD clock rate in the usrp e310 - release 4

[Gabriel Pechiarovich]

Hi I just tried your suggestion and it was ok for the RX side, but in the
Tx side the decimation wont go up to 1024, it only decimates up to 512,

-- Asking for clock rate 16.384 MHz
-- Actually got clock rate 16.384 MHz
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass

UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 0.016000 MSps
Actual sample rate: 0.032000 MSps

so is this locked for security or something, or the hardware simple doesn't
have the capabilities?



2016-04-07 5:33 GMT+00:00 Martin Braun :

> On 04/06/2016 10:26 PM, Martin Braun wrote:
> > On the release 4 image, you can't do that. But you can set the clock to
> > 16 MHz and use a decimation of 1000. Or you can use a clock rate of
> > 16384e3 and a decimation of 1024, for a better decimation filter
> response.
>
> ...they'll probably be about the same, as the same number of halfbands
> will be active. But the point is, you can't go below 10 MHz MCR on
> release 4, and not above decimation 1024.
>
> Cheers,
> M
> >
> > Cheers,
> > Martin
> >
> > On 04/06/2016 06:11 PM, Gabriel Pechiarovich wrote:
> >> Hi, thanks for your answeri wasn't able to answer earlier.
> >>
> >> I was aiming to a 8MHz clock rate in order to use the DDC and get a
> >> 16000 sample rate.
> >> So i think i was misunderstood.
> >>
> >> Thank you very much
> >> Gabriel
> >>
> >>
> >> 2016-03-31 13:25 GMT-05:00 Martin Braun  >> >:
> >>
> >> On the release 4 image, you can't set the clock speed under 10 MHz.
> >> However, you can use a DDC (which is built in and automatically
> used).
> >> Simply set the clock rate to 32 MHz (or 16 MHz if this is MIMO) and
> the
> >> sample rate to 8 MHz.
> >>
> >> Cheers,
> >> Martin
> >>
> >> On 03/30/2016 05:02 PM, Gabriel Pechiarovich wrote:
> >> > Hi all,
> >> > I've developed a flowgraph wich includes  a qpsk modulator and and
> >> audio
> >> > encoder, I used to run it in the E310 using the first release
> >> > (http://files.ettus.com/e3xx_images/e3xx-release-001/) and now
> >> trying to
> >> > use the release 4.
> >> >
> >> > The problem is:
> >> > in the UHD sink and source the clock rate was set to 8e6 Hz, and
> it
> >> > worked fine, in the release 1, but in the relese 4 the Clock rate
> wont
> >> > go lower than 10e6 Hz, so i cant archive the same results.
> >> >
> >> > Any idea how to force the use of 8MHz as the clock rate using the
> >> release4
> >> >
> >> > Thank you very much
> >> > Gabriel Pechiarovich Salas
> >> >
> >> >
> >> >
> >> > ___
> >> > Discuss-gnuradio mailing list
> >> > Discuss-gnuradio@gnu.org 
> >> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >> >
> >>
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org 
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>
> >>
> >>
> >>
> >> --
> >> Gabriel Pechiarovich Salas
> >> Red Dragon Games
> >> Designers and game developers
> >
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Gabriel Pechiarovich Salas
Red Dragon Games
Designers and game developers
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] matched filter for BPSK produced by phase shifting

[Laur Joost]

Hi all!

I need a clue where to start.

I have a signal that is BPSK that is modulated not by applying the filtered
baseband to the in-phase component, but instead doing literal analog phase
shifting.

The result is that the signal transitions between the -1 and 1 symbols not
through zero, but instead along the unit circle.

The transmitted baseband is RRC-filtered.

My questions:
1. Is Raised Cosine even a valid Nyquist filter for such a signal? After
all, the actual In-phase transition occurs not according to the RRC
response, but according to the sine OF the RRC.

2. The response of such a modulator to a unit impulse is necessarily
complex. From what I gather, the matched filter is then, also complex (time
reversed and conjugated). How should I go about this in GnuRadio, given
that the PFB Clock sync only takes real taps?

3. Or can I just take the real part of the matched filter and feed that to
PFB Clock sync? The constellation will have a weird spread (see picture).
Will that affect either Costas or PFB?

PS: The positioning of the constellation plots was not planned.

All the best,
Laur
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Overflow error in benchmark receiver side "DDDD"

[monika bansal]

Hi Marcus

The network card is PCI Express Gigabit Ethernet Controller with 1Gbps
capacity.

Thanks,
Monika

On Fri, Apr 15, 2016 at 6:38 PM, Marcus Müller 
wrote:

> No harm done :) So the point is that  is still pretty bad, and usually
> shouldn't happen, unless your PC is *much* too slow, and usually would be
> preceeded by a couple of "O".
> There's two cases where this doesn't happen:
> * Too small network buffers
> * strangely misbehaving network hardware.
>
> So: what is your network card?
>
> Best regards,
> Marcus
>
>
> On 15.04.2016 14:32, monika bansal wrote:
>
> Yes my mistake :). Sorry for that. I just did not think of the python
> block at that time and then after i realized.
>
> Regards,
> Monika
>
> On Fri, Apr 15, 2016 at 5:17 PM, Marcus Müller 
> wrote:
>
>> Monika,
>>
>> no offense, but when you report a problem with software, it's pretty
>> crucial you point out whether you've modified the software or not :)
>>
>> Best regards,
>> Marcus
>>
>>
>> On 15.04.2016 06:28, monika bansal wrote:
>>
>> Hii,
>>
>> Thank you for your help.
>> That "" issue is not coming with original benchmark files.
>> I added one python block in between the chain in benchmark code. I think
>> due to which it was not fast enough to process the incoming data resulting
>> "" issue.
>>
>> Regards,
>> Monika
>>
>> On Tue, Apr 5, 2016 at 11:51 PM, < mle...@ripnet.com>
>> wrote:
>>
>>> What if you make the file "/dev/null" -- does this still happen?
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 2016-04-05 14:12, monika bansal wrote:
>>>
>>> Hii,
>>>
>>> I am running benchmark code and on the receiver side after receiving
>>> some number of packets(8000 so), it starts showing overflow errors ("")
>>> on terminal.
>>> Following is the system configuration
>>>
>>> python benchmark_rx.py -f 1100M --args "addr=10.32.38.163"
>>> --to-file=/home/ashokbandi/GNU/a_rx.txt --bandwidth=50
>>>
>>> Decreasing the bandwidth delays the error.
>>>
>>> I tried changing buffer size by setting net.core.rmem_max and
>>> net.core.wmem_max to 33445532 but to no avail.
>>>
>>>
>>> Following is the screen shot of terminal
>>>
>>> DDok: True  pktno: 24116  n_rcvd: 9730  n_right: 9723
>>> ok: True  pktno: 24182  n_rcvd: 9731  n_right: 9724
>>> DDok: True  pktno: 24319  n_rcvd: 9732  n_right:
>>> 9725
>>> ok: True  pktno: 24442  n_rcvd: 9733
>>>  n_right: 9726
>>> DDDok: True  pktno: 24477  n_rcvd: 9734  n_right: 9727
>>> Dok: True  pktno: 24568  n_rcvd: 9735  n_right: 9728
>>> Dok:
>>> False  pktno: 22729  n_rcvd: 9736  n_right: 9728
>>>
>>>
>>> Thanks
>>>
>>> ___
>>> Discuss-gnuradio mailing 
>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio