Re: [Discuss-gnuradio] Confusion, help please

[Marcus Müller]

Hi Ali,

that's interesting.
Would you mind sharing the flow graph that you use?

Greetings,
Marcus

PS: Although using adblock plus, before I see every other picture on
tinypic, I get stuff like casino advertisment, and similar.
Could you use any image hoster that doesn't block view on the pictures
with advertisement? I found imgur.com to work fairly well.
On 03/03/2015 12:27 AM, Ali Riaz wrote:
> Hello all,
>
> I just had a quick question regarding the polyphase channelizer. As a
> start, I'm trying to divide an input spectrum into 6 channels of equal
> width. My sample rate for now is 5 MHz and the way I'm calculating the
> taps as follows:
>
> firdes.low_pass2(1.0, samp_rate, samp_rate/(nchan*2.15),
> samp_rate/(nchan*13.8),attenuation_dB = 10, window = firdes.WIN_HAMMING)
>
> The channels are being divided equally now, but the first channel
> behaves very different from the rest, it becomes super wide for a
> moment, and then shrinks back to normal just like the rest of the
> channels and this happens repeatedly. I'm honestly stumped as to what
> the reason could be, so would really appreciate if anybody can point
> me in the right direction or at least clarify why this is happening.
>
> You can find the images here: http://tinypic.com/a/3e8so/4
>
> Thank you,
>
> Best,
> Ali
>
>
> ___
> 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] SVD from LAPACK takes too long time

[Marcus Müller]

Hello Hoang,

exciting :)
Actually, if you're already using LAPACK, I doubt there's much potential
for further optimization on the same platform -- if you, however, know
your stuff is going to only be run on Intel Xeons or so, than maybe have
a look at the Intel math kernel library lapack examples. Maybe you'd
want to accelerate by using GPUs, then you'd have a look at OpenCl or
CUDA implementation, or theano (however, I don't know how readily
available things like SVD are for theano).

One more thing: Since you're doing SVD using LAPACK yourself, I trust
you've already chosen the right routine (general, fully equipped
complex-valued matrix). I'm not completely convinced, though:

Have you had a look at [1]? It seems SVD $A=V \Sigma U^H$  is a two step
process: First, the input matrix is decomposed into left and right
unitary matrixes $U_1$ and $V_1^H$ and an bidiagonal matrix $B$ using
CGEBRD, and after that, $B$ is SVD'ed, yielding $B=U_2 \Sigma V_2^H$;
the product $V_1 V_2$ then is $V$. Maybe for your application $V1$ is
sufficient, because you can rearrange your problem mathematically?

Greetings,
Marcus

[1] http://www.netlib.org/lapack/lug/node53.html
On 03/03/2015 08:13 AM, Hoang Ngo Khac wrote:
> Dear all,
>
> I got trouble with Singular Value Decomposition computation in GNU
> Radio using LAPACK. I use SVD to build a precoder for a secondary
> transmitter in a cognitive radio model. It takes too long times to
> handle a 128x144 matrix with complex entries, and therefore, the data
> stream to be transmitted seem to be really slow in rate. 
>
> Is there any other way to compute SVD faster? FYI, I just need the V*
> matrix within the result (U, S, V*).
>
> Thanks,
> Hoang
>
> -- 
> *Hoang Ngo-Khac*
> Research Assistant - Signal and System Lab, FET, UET
> Vietnam National University-Hanoi (VNU-H)
> G2-206, 144 Xuan Thuy, Cau Giay, Hanoi, Vietnam
> Alternative email:  hoangnk...@vnu.edu.vn 
> Mobilephone:  +84.163.682.7874
>
>
> ___
> 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

[Discuss-gnuradio] mimo beam forming on USRP

[Pengyu Zhang]

Hi Guys,

I am planning to build a mimo system which supports beam forming. Is USRP a
good platform for my target? I do not want to use WARP because I need to
operate at frequencies lower than 2.4GHz.

A potential problem of USRP is phase alignment. As the following doc
suggests, phase alignment can be done by MANUALLY tuning the phase. This
process can be labor intensive when the number of antennas increases. I am
also worried about the problem that the manual phase calibration might need
to be done each time you use the mimo system. Is there any approach that
can make this process much easier?

http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf

Would be great if you can give me some suggestions about what devices
should I use for building a mimo system for beam forming. Thanks.

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

Re: [Discuss-gnuradio] mimo beam forming on USRP

[mleech]

 

If you use the phase-resynch feature of the SBX card, and you have
common refclock and 1PPS across all your USRPs in the array,
 then you should be OK. 

In *general*, synthesized downconverters use fractional-N synthesizers
where their starting phase after a re-tune is random with respect to any
other synthesizer using the same reference clock. That's just the way
fractional- N synthesis works. It happens that SBX uses an ADF4351
synthesizer, which has a (rare!) hardware feature to allow phase-resynch
after tuning. In order to make this work, all SBXes in your "array" must
be tuned at exactly the same time, so the timed_commands feature must be
used to do the tuning. 

See: 

http://files.ettus.com/manual/page_sync.html 

On 2015-03-03 11:05, Pengyu Zhang wrote: 

> Hi Guys, 
> 
> I am planning to build a mimo system which supports beam forming. Is USRP a 
> good platform for my target? I do not want to use WARP because I need to 
> operate at frequencies lower than 2.4GHz. 
> 
> A potential problem of USRP is phase alignment. As the following doc 
> suggests, phase alignment can be done by MANUALLY tuning the phase. This 
> process can be labor intensive when the number of antennas increases. I am 
> also worried about the problem that the manual phase calibration might need 
> to be done each time you use the mimo system. Is there any approach that can 
> make this process much easier? 
> 
> http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf [2] 
> 
> Would be great if you can give me some suggestions about what devices should 
> I use for building a mimo system for beam forming. Thanks. 
> 
> Pengyu 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[2]
http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] mimo beam forming on USRP

[mleech]

 

Indeed, I should have emphasized that despite having features like
"phase resynch", in any *practical* phased-array, you'll still need some
mechanism for calibrating the phase centers of all your antenna.
Differential environmental factors can, for example, affect the phasing
of the antenna feed paths, even with your LOs all agreeing quite-well on
phase. 

In Radio Astronomy, they do this all the time--there's always a
phase-calibration process that is undertaken prior to observations,
because despite careful layout of common LOs, carefully-measured
feedlines from the same batch of cable, etc, differentials creep in. 

On 2015-03-03 11:26, Martin Braun wrote: 

> Can you give us some details (frequency, number of antennas) that you want to 
> have?
> 
> A lot of people have done MIMO with USRPs, up to 100x100 antennas, so there 
> is some precedent. For beam forming, you'll need very good phase alignment, 
> depending on what you're planning to set up. This is always difficult, 
> because all sorts of things affect phase. You should, in any case, have a way 
> to test phase alignment.
> 
> Cheers,
> Martin
> 
> On 03.03.2015 08:18, mle...@ripnet.com wrote:
> If you use the phase-resynch feature of the SBX card, and you have common 
> refclock and 1PPS across all your USRPs in the array, then you should be OK. 
> In *general*, synthesized downconverters use fractional-N synthesizers where 
> their starting phase after a re-tune is random with respect to any other 
> synthesizer using the same reference clock. That's just the way fractional- N 
> synthesis works. It happens that SBX uses an ADF4351 synthesizer, which has a 
> (rare!) hardware feature to allow phase-resynch after tuning. In order to 
> make this work, all SBXes in your "array" must be tuned at exactly the same 
> time, so the timed_commands feature must be used to do the tuning. See: 
> http://files.ettus.com/manual/page_sync.html [1] On 2015-03-03 11:05, Pengyu 
> Zhang wrote: Hi Guys, I am planning to build a mimo system which supports 
> beam forming. Is USRP a good platform for my target? I do not want to use 
> WARP because I need to operate at frequencies lower than 2.4GHz. A potential 
> problem of USRP
is phase alignment. As the following doc suggests, phase alignment can be done 
by MANUALLY tuning the phase. This process can be labor intensive when the 
number of antennas increases. I am also worried about the problem that the 
manual phase calibration might need to be done each time you use the mimo 
system. Is there any approach that can make this process much easier? 
http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf [2] 
Would be great if you can give me some suggestions about what devices should I 
use for building a mimo system for beam forming. Thanks. Pengyu 
___ Discuss-gnuradio mailing list 
Discuss-gnuradio@gnu.org  
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3] 
___ Discuss-gnuradio mailing list 
Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]

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

 

Links:
--
[1] http://files.ettus.com/manual/page_sync.html
[2]
http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
[3] 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] mimo beam forming on USRP

[Martin Braun]

Can you give us some details (frequency, number of antennas) that you 
want to have?


A lot of people have done MIMO with USRPs, up to 100x100 antennas, so 
there is some precedent. For beam forming, you'll need very good phase 
alignment, depending on what you're planning to set up. This is always 
difficult, because all sorts of things affect phase. You should, in any 
case, have a way to test phase alignment.


Cheers,
Martin

On 03.03.2015 08:18, mle...@ripnet.com wrote:

If you use the phase-resynch feature of the SBX card, and you have
common refclock and 1PPS across all your USRPs in the array,
  then you should be OK.

In *general*, synthesized downconverters use fractional-N synthesizers
where their starting phase after a re-tune is random with respect to any
other synthesizer using the same reference clock.  That's just the way
fractional- N synthesis works.  It happens that SBX uses an ADF4351
synthesizer, which has a (rare!) hardware feature to allow phase-resynch
after tuning.  In order to make this work, all SBXes in your "array"
must be tuned at exactly the same time, so the timed_commands feature
must be used to do the tuning.

See:

http://files.ettus.com/manual/page_sync.html

On 2015-03-03 11:05, Pengyu Zhang wrote:


Hi Guys,
I am planning to build a mimo system which supports beam forming. Is
USRP a good platform for my target? I do not want to use WARP because
I need to operate at frequencies lower than 2.4GHz.
A potential problem of USRP is phase alignment. As the following doc
suggests, phase alignment can be done by MANUALLY tuning the phase.
This process can be labor intensive when the number of antennas
increases. I am also worried about the problem that the manual phase
calibration might need to be done each time you use the mimo system.
Is there any approach that can make this process much easier?
http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
Would be great if you can give me some suggestions about what devices
should I use for building a mimo system for beam forming. Thanks.
Pengyu

___
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




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

[Discuss-gnuradio] Finish python app after some processing in a C++ work() function

[Jorge Gallo]

Hi,



I would like to find a way of saying to Python top_block that it should
stop processing and the application must finish.



One of the blocks of the application will be a custom block and after
gathering some samples it must tell python to stop.



Is there a direct way of doing that?



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

Re: [Discuss-gnuradio] mimo beam forming on USRP

[Pengyu Zhang]

Marcus - I am thinking about sending a training signal using one TX antenna
and figure out the phases of other antennas by looking at the maximum
correlation. Does this sound like a reasonable solution for a practical
mimo system?

On Tue, Mar 3, 2015 at 11:44 AM,  wrote:

>  Pengyu:
>
> I think people tend to do it differently, depending on the particular
> application.  In radio astronomy, they typically point the array at a
> well-characterized "calibrator source" and make phase measurements, and
> then tweak based on known baseline geometries.
>
> For commercial MIMO, using a distant transmitter of known properties and
> arrival angles might be useful, or a local calibrator source.
>
>
>
>
>
>
> On 2015-03-03 11:41, Pengyu Zhang wrote:
>
> Martin - I am thinking about doing beam forming around 900MHz. The number
> of antennas that I want to use is around 8x8. I am thinking about using
> USRP N210+SBX+OctoClock-G suggested by ettus. But not sure how much phase
> mis-alignment will I observe.
>
> Marcus - Thanks for the tips. Maybe I should look at how other folks do
> phase calibration on USRP. Any recommendation of sample projects? Ideally,
> I hope that this process can be done automatically in software or in
> hardware.
>
> Pengyu
>
> On Tue, Mar 3, 2015 at 11:32 AM,  wrote:
>
>>  Indeed, I should have emphasized that despite having features like
>> "phase resynch", in any *practical* phased-array, you'll still need some
>> mechanism for calibrating the phase centers of all your antenna.
>> Differential environmental factors can, for example, affect the phasing of
>> the antenna feed paths, even with your LOs all agreeing quite-well on phase.
>>
>> In Radio Astronomy, they do this all the time--there's always a
>> phase-calibration process that is undertaken prior to observations, because
>> despite careful layout of common LOs, carefully-measured feedlines from the
>> same batch of cable, etc, differentials creep in.
>>
>>
>>
>>
>>
>>
>> On 2015-03-03 11:26, Martin Braun wrote:
>>
>> Can you give us some details (frequency, number of antennas) that you want 
>> to have?
>>
>> A lot of people have done MIMO with USRPs, up to 100x100 antennas, so there 
>> is some precedent. For beam forming, you'll need very good phase alignment, 
>> depending on what you're planning to set up. This is always difficult, 
>> because all sorts of things affect phase. You should, in any case, have a 
>> way to test phase alignment.
>>
>> Cheers,
>> Martin
>>
>> On 03.03.2015 08:18, mle...@ripnet.com wrote:
>>
>> If you use the phase-resynch feature of the SBX card, and you have common
>> refclock and 1PPS across all your USRPs in the array, then you should be
>> OK. In *general*, synthesized downconverters use fractional-N synthesizers
>> where their starting phase after a re-tune is random with respect to any
>> other synthesizer using the same reference clock. That's just the way
>> fractional- N synthesis works. It happens that SBX uses an ADF4351
>> synthesizer, which has a (rare!) hardware feature to allow phase-resynch
>> after tuning. In order to make this work, all SBXes in your "array" must be
>> tuned at exactly the same time, so the timed_commands feature must be used
>> to do the tuning. See: http://files.ettus.com/manual/page_sync.html On
>> 2015-03-03 11:05, Pengyu Zhang wrote:
>>
>> Hi Guys, I am planning to build a mimo system which supports beam
>> forming. Is USRP a good platform for my target? I do not want to use WARP
>> because I need to operate at frequencies lower than 2.4GHz. A potential
>> problem of USRP is phase alignment. As the following doc suggests, phase
>> alignment can be done by MANUALLY tuning the phase. This process can be
>> labor intensive when the number of antennas increases. I am also worried
>> about the problem that the manual phase calibration might need to be done
>> each time you use the mimo system. Is there any approach that can make this
>> process much easier?
>> http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
>> Would be great if you can give me some suggestions about what devices
>> should I use for building a mimo system for beam forming. Thanks. Pengyu
>> ___ 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
>>
>> ___
>> 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

Re: [Discuss-gnuradio] Finish python app after some processing in a C++ work() function

[Marcus Müller]

Yes, just let the block return the magic WORK_DONE (==-1) value.

Greetings,
Marcus
On 03/03/2015 05:51 PM, Jorge Gallo wrote:
>
> Hi,
>
>  
>
> I would like to find a way of saying to Python top_block that it
> should stop processing and the application must finish.
>
>  
>
> One of the blocks of the application will be a custom block and after
> gathering some samples it must tell python to stop.
>
>  
>
> Is there a direct way of doing that?
>
>  
>
> Regards,
>
> Jorge
>
>
> ___
> 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] mimo beam forming on USRP

[mleech]

 

Pengyu: 

I think people tend to do it differently, depending on the particular
application. In radio astronomy, they typically point the array at a
well-characterized "calibrator source" and make phase measurements, and
then tweak based on known baseline geometries. 

For commercial MIMO, using a distant transmitter of known properties and
arrival angles might be useful, or a local calibrator source. 

On 2015-03-03 11:41, Pengyu Zhang wrote: 

> Martin - I am thinking about doing beam forming around 900MHz. The number of 
> antennas that I want to use is around 8x8. I am thinking about using USRP 
> N210+SBX+OctoClock-G suggested by ettus. But not sure how much phase 
> mis-alignment will I observe. 
> 
> Marcus - Thanks for the tips. Maybe I should look at how other folks do phase 
> calibration on USRP. Any recommendation of sample projects? Ideally, I hope 
> that this process can be done automatically in software or in hardware. 
> 
> Pengyu 
> 
> On Tue, Mar 3, 2015 at 11:32 AM,  wrote:
> 
> Indeed, I should have emphasized that despite having features like "phase 
> resynch", in any *practical* phased-array, you'll still need some mechanism 
> for calibrating the phase centers of all your antenna. Differential 
> environmental factors can, for example, affect the phasing of the antenna 
> feed paths, even with your LOs all agreeing quite-well on phase. 
> 
> In Radio Astronomy, they do this all the time--there's always a 
> phase-calibration process that is undertaken prior to observations, because 
> despite careful layout of common LOs, carefully-measured feedlines from the 
> same batch of cable, etc, differentials creep in. 
> 
> On 2015-03-03 11:26, Martin Braun wrote: 
> 
> Can you give us some details (frequency, number of antennas) that you want to 
> have?
> 
> A lot of people have done MIMO with USRPs, up to 100x100 antennas, so there 
> is some precedent. For beam forming, you'll need very good phase alignment, 
> depending on what you're planning to set up. This is always difficult, 
> because all sorts of things affect phase. You should, in any case, have a way 
> to test phase alignment.
> 
> Cheers,
> Martin
> 
> On 03.03.2015 08:18, mle...@ripnet.com wrote:
> If you use the phase-resynch feature of the SBX card, and you have common 
> refclock and 1PPS across all your USRPs in the array, then you should be OK. 
> In *general*, synthesized downconverters use fractional-N synthesizers where 
> their starting phase after a re-tune is random with respect to any other 
> synthesizer using the same reference clock. That's just the way fractional- N 
> synthesis works. It happens that SBX uses an ADF4351 synthesizer, which has a 
> (rare!) hardware feature to allow phase-resynch after tuning. In order to 
> make this work, all SBXes in your "array" must be tuned at exactly the same 
> time, so the timed_commands feature must be used to do the tuning. See: 
> http://files.ettus.com/manual/page_sync.html [1] On 2015-03-03 11:05, Pengyu 
> Zhang wrote: Hi Guys, I am planning to build a mimo system which supports 
> beam forming. Is USRP a good platform for my target? I do not want to use 
> WARP because I need to operate at frequencies lower than 2.4GHz. A potential 
> problem of USRP
is phase alignment. As the following doc suggests, phase alignment can be done 
by MANUALLY tuning the phase. This process can be labor intensive when the 
number of antennas increases. I am also worried about the problem that the 
manual phase calibration might need to be done each time you use the mimo 
system. Is there any approach that can make this process much easier? 
http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf [2] 
Would be great if you can give me some suggestions about what devices should I 
use for building a mimo system for beam forming. Thanks. Pengyu 
___ Discuss-gnuradio mailing list 
Discuss-gnuradio@gnu.org  
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3] 
___ Discuss-gnuradio mailing list 
Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]

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

 

Links:
--
[1] http://files.ettus.com/manual/page_sync.html
[2]
http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
[3] 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] mimo beam forming on USRP

[Pengyu Zhang]

Martin - I am thinking about doing beam forming around 900MHz. The number
of antennas that I want to use is around 8x8. I am thinking about using
USRP N210+SBX+OctoClock-G suggested by ettus. But not sure how much phase
mis-alignment will I observe.

Marcus - Thanks for the tips. Maybe I should look at how other folks do
phase calibration on USRP. Any recommendation of sample projects? Ideally,
I hope that this process can be done automatically in software or in
hardware.

Pengyu

On Tue, Mar 3, 2015 at 11:32 AM,  wrote:

>  Indeed, I should have emphasized that despite having features like
> "phase resynch", in any *practical* phased-array, you'll still need some
> mechanism for calibrating the phase centers of all your antenna.
> Differential environmental factors can, for example, affect the phasing of
> the antenna feed paths, even with your LOs all agreeing quite-well on phase.
>
> In Radio Astronomy, they do this all the time--there's always a
> phase-calibration process that is undertaken prior to observations, because
> despite careful layout of common LOs, carefully-measured feedlines from the
> same batch of cable, etc, differentials creep in.
>
>
>
>
>
>
> On 2015-03-03 11:26, Martin Braun wrote:
>
> Can you give us some details (frequency, number of antennas) that you want to 
> have?
>
> A lot of people have done MIMO with USRPs, up to 100x100 antennas, so there 
> is some precedent. For beam forming, you'll need very good phase alignment, 
> depending on what you're planning to set up. This is always difficult, 
> because all sorts of things affect phase. You should, in any case, have a way 
> to test phase alignment.
>
> Cheers,
> Martin
>
> On 03.03.2015 08:18, mle...@ripnet.com wrote:
>
> If you use the phase-resynch feature of the SBX card, and you have common
> refclock and 1PPS across all your USRPs in the array, then you should be
> OK. In *general*, synthesized downconverters use fractional-N synthesizers
> where their starting phase after a re-tune is random with respect to any
> other synthesizer using the same reference clock. That's just the way
> fractional- N synthesis works. It happens that SBX uses an ADF4351
> synthesizer, which has a (rare!) hardware feature to allow phase-resynch
> after tuning. In order to make this work, all SBXes in your "array" must be
> tuned at exactly the same time, so the timed_commands feature must be used
> to do the tuning. See: http://files.ettus.com/manual/page_sync.html On
> 2015-03-03 11:05, Pengyu Zhang wrote:
>
> Hi Guys, I am planning to build a mimo system which supports beam forming.
> Is USRP a good platform for my target? I do not want to use WARP because I
> need to operate at frequencies lower than 2.4GHz. A potential problem of
> USRP is phase alignment. As the following doc suggests, phase alignment can
> be done by MANUALLY tuning the phase. This process can be labor intensive
> when the number of antennas increases. I am also worried about the problem
> that the manual phase calibration might need to be done each time you use
> the mimo system. Is there any approach that can make this process much
> easier?
> http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
> Would be great if you can give me some suggestions about what devices
> should I use for building a mimo system for beam forming. Thanks. Pengyu
> ___ 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
>
> ___
> 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

Re: [Discuss-gnuradio] mimo beam forming on USRP

[Martin Braun]

On 03.03.2015 08:41, Pengyu Zhang wrote:

Martin - I am thinking about doing beam forming around 900MHz. The
number of antennas that I want to use is around 8x8. I am thinking about
using USRP N210+SBX+OctoClock-G suggested by ettus. But not sure how
much phase mis-alignment will I observe.


In that case, SBX will work fine. How much phase alignment you'll 
observe depends on your actual setup... there's a lot of factors (which 
is why, as Marcus mentioned, overall systems usually get calibrated 
before usage).


If you have specific questions or concerns, I suggest you contact Neel 
(CC'd).


Cheers,
Martin



Marcus - Thanks for the tips. Maybe I should look at how other folks do
phase calibration on USRP. Any recommendation of sample projects?
Ideally, I hope that this process can be done automatically in software
or in hardware.

Pengyu

On Tue, Mar 3, 2015 at 11:32 AM, mailto:mle...@ripnet.com>> wrote:

__

Indeed, I should have emphasized that despite having features like
"phase resynch", in any *practical* phased-array, you'll still need
some mechanism for calibrating the phase centers of all your
antenna.  Differential environmental factors can, for example,
affect the phasing of the antenna feed paths, even with your LOs all
agreeing quite-well on phase.

In Radio Astronomy, they do this all the time--there's always a
phase-calibration process that is undertaken prior to observations,
because despite careful layout of common LOs, carefully-measured
feedlines from the same batch of cable, etc, differentials creep in.

On 2015-03-03 11:26, Martin Braun wrote:


Can you give us some details (frequency, number of antennas) that you want 
to have?

A lot of people have done MIMO with USRPs, up to 100x100 antennas, so there 
is some precedent. For beam forming, you'll need very good phase alignment, 
depending on what you're planning to set up. This is always difficult, because 
all sorts of things affect phase. You should, in any case, have a way to test 
phase alignment.

Cheers,
Martin

On 03.03.2015 08:18,mle...@ripnet.com    wrote:

If you use the phase-resynch feature of the SBX card, and you
have common refclock and 1PPS across all your USRPs in the array,
then you should be OK. In *general*, synthesized downconverters
use fractional-N synthesizers where their starting phase after a
re-tune is random with respect to any other synthesizer using the
same reference clock. That's just the way fractional- N synthesis
works. It happens that SBX uses an ADF4351 synthesizer, which has
a (rare!) hardware feature to allow phase-resynch after tuning.
In order to make this work, all SBXes in your "array" must be
tuned at exactly the same time, so the timed_commands feature
must be used to do the tuning. See:
http://files.ettus.com/manual/page_sync.html On 2015-03-03 11:05,
Pengyu Zhang wrote:

Hi Guys, I am planning to build a mimo system which supports
beam forming. Is USRP a good platform for my target? I do not
want to use WARP because I need to operate at frequencies lower
than 2.4GHz. A potential problem of USRP is phase alignment. As
the following doc suggests, phase alignment can be done by
MANUALLY tuning the phase. This process can be labor intensive
when the number of antennas increases. I am also worried about
the problem that the manual phase calibration might need to be
done each time you use the mimo system. Is there any approach
that can make this process much easier?
http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
Would be great if you can give me some suggestions about what
devices should I use for building a mimo system for beam
forming. Thanks. Pengyu
___ 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

___
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

[Discuss-gnuradio] test_corr_and_sync example

[Richard Bell]

Hi all,

I'm trying to figure out what the test_corr_and_sync example (located
.../src/gnuradio/gr-digital/examples/demod/test_corr_and_sync.grc) is
showing me. I see the tags added by the correlator, but they seem to jump
around a bit. If I add some timing offset with the slider, I don't see much
relation to that and the time_est tag value. I can't find any correlation
between the four sliders and any of the tag values.

I also see the constellation being smeared out considerably. It looks to me
like the rrc_taps variable might be set incorrectly. The number of taps
portion of the filter does not match the constellation modulator number of
taps (5*sps vs 11*sps). Though changing this to what I believe is correct
does not help the smear all that much. Shrug.

If this is working as intended, what net effect does this have on the
pfb_sync and costas filters? Is it a considerable boost in sync performance?

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

[Discuss-gnuradio] gr-fosphor with pybombs

[ben Gee]

Hey folks,
So i installed the gr-fosphor 'app' using the pybombs recipe and it seems
to install ok, but when i run it I get the output listed below. Any ideas
here?

Thanks,
-B

cnlsdr1@cnlsdr1:~/pybombs$ osmocom_fft -F
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.002-91-g7d97ab60

gr-osmosdr v0.1.4-9-g48045b59 (0.1.5git) gnuradio v3.7.6.1-89-gc990e825
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf
rfspace
-- Operating over USB 3.
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 32.00 MHz...
-- Actually got clock rate 32.00 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- Setting master clock rate selection to 'automatic'.
-- Using subdev spec 'A:A A:B'.
Traceback (most recent call last):
  File "/home/cnlsdr1/pybombs/bin/osmocom_fft", line 842, in 
main ()
  File "/home/cnlsdr1/pybombs/bin/osmocom_fft", line 838, in main
app = stdgui2.stdapp(app_top_block, "osmocom Spectrum Browser",
nstatus=1)
  File
"/home/cnlsdr1/pybombs/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
line 46, in __init__
wx.App.__init__ (self, redirect=False)
  File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line 7981, in __init__
self._BootstrapApp()
  File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line 7555, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File
"/home/cnlsdr1/pybombs/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
line 49, in OnInit
frame = stdframe (self.top_block_maker, self.title, self._nstatus)
  File
"/home/cnlsdr1/pybombs/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
line 76, in __init__
self.panel = stdpanel (self, self, top_block_maker)
  File
"/home/cnlsdr1/pybombs/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
line 98, in __init__
self.top_block = top_block_maker (frame, self, vbox, sys.argv)
  File "/home/cnlsdr1/pybombs/bin/osmocom_fft", line 221, in __init__
from gnuradio import fosphor
ImportError: cannot import name fosphor
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] cmake can't find 'gnuradio-runtime'

[javier]

Greetings
I am also new in the gnuradio and recently I am working with him. I am
flowing the instruction tutorial in gnuradio.org but when I am  going to
bulid my out of tree using cmake ../ He gives me the following error:

jrbosch@CM6AJR:~/Documents/gnuradio/tutorials/work/out_of_tree/gr-tutorial/build$
cmake ../
-- The CXX compiler identification is GNU 4.8.2
-- The C compiler identification is GNU 4.8.2
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.54.0
-- Found the following Boost libraries:
--   filesystem
--   system
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- checking for module 'gnuradio-runtime'
--   package 'gnuradio-runtime' not found
-- Could NOT find GNURADIO_RUNTIME (missing: GNURADIO_RUNTIME_LIBRARIES)
-- checking for module 'cppunit'
--   found cppunit, version 1.13.1
-- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
CMake Error at CMakeLists.txt:98 (message):
  GnuRadio Runtime required to compile tutorial

-- Configuring incomplete, errors occurred!
See also
"/home/jrbosch/Documents/gnuradio/tutorials/work/out_of_tree/gr-tutorial/build/CMakeFiles/CMakeOutput.log".
 


I have installed the gnuradio of Ubuntu's repositories and I have installed
the library libgnuradio-runtime of ubuntu's repositories too. About
gunradio-runtime there is nothing more to install in my synaptic
If somebody would explain me what do I have not enough to install or what is
the cause of the problem I would thank him.
Excuse me my english, It is not good.





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/cmake-can-t-find-gnuradio-runtime-tp52539.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] cmake can't find 'gnuradio-runtime'

[Martin Braun]

Which GNU Radio version do you have installed?

M

On 03.03.2015 16:35, javier wrote:

Greetings
I am also new in the gnuradio and recently I am working with him. I am
flowing the instruction tutorial in gnuradio.org but when I am  going to
bulid my out of tree using cmake ../ He gives me the following error:

jrbosch@CM6AJR:~/Documents/gnuradio/tutorials/work/out_of_tree/gr-tutorial/build$
cmake ../
-- The CXX compiler identification is GNU 4.8.2
-- The C compiler identification is GNU 4.8.2
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.54.0
-- Found the following Boost libraries:
--   filesystem
--   system
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- checking for module 'gnuradio-runtime'
--   package 'gnuradio-runtime' not found
-- Could NOT find GNURADIO_RUNTIME (missing: GNURADIO_RUNTIME_LIBRARIES)
-- checking for module 'cppunit'
--   found cppunit, version 1.13.1
-- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
CMake Error at CMakeLists.txt:98 (message):
   GnuRadio Runtime required to compile tutorial

-- Configuring incomplete, errors occurred!
See also
"/home/jrbosch/Documents/gnuradio/tutorials/work/out_of_tree/gr-tutorial/build/CMakeFiles/CMakeOutput.log".


I have installed the gnuradio of Ubuntu's repositories and I have installed
the library libgnuradio-runtime of ubuntu's repositories too. About
gunradio-runtime there is nothing more to install in my synaptic
If somebody would explain me what do I have not enough to install or what is
the cause of the problem I would thank him.
Excuse me my english, It is not good.





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/cmake-can-t-find-gnuradio-runtime-tp52539.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
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] cmake can't find 'gnuradio-runtime'

[javier]

I have installed the version 3.7.2.1 which is in the ubuntu 14.04 's repos.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/cmake-can-t-find-gnuradio-runtime-tp52539p52541.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] Finish python app after some processing in a C++ work() function

[Jorge Gallo]

Hi,

That is what I call direct way =P

Thank you Marcus!


On 3 March 2015 at 17:53, Marcus Müller  wrote:

>  Yes, just let the block return the magic WORK_DONE (==-1) value.
>
> Greetings,
> Marcus
>
> On 03/03/2015 05:51 PM, Jorge Gallo wrote:
>
>  Hi,
>
>
>
> I would like to find a way of saying to Python top_block that it should
> stop processing and the application must finish.
>
>
>
> One of the blocks of the application will be a custom block and after
> gathering some samples it must tell python to stop.
>
>
>
> Is there a direct way of doing that?
>
>
>
> Regards,
> Jorge
>
>
> ___
> 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] mimo beam forming on USRP

[Ralph A. Schmid, dk5ras]

When I read this, pCell comes in mind:
http://www.rearden.com/artemis/An-Introduction-to-pCell-White-Paper-150224.p
df 

Quite exciting stuff!

Ralph.

> -Original Message-
> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
> Martin Braun
> Sent: Tuesday, March 3, 2015 5:26 PM
> To: Pengyu Zhang
> Cc: Discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] mimo beam forming on USRP
> 
> Can you give us some details (frequency, number of antennas) that you want
> to have?
> 
> A lot of people have done MIMO with USRPs, up to 100x100 antennas, so
> there is some precedent. For beam forming, you'll need very good phase
> alignment, depending on what you're planning to set up. This is always
> difficult, because all sorts of things affect phase. You should, in any
case,
> have a way to test phase alignment.
> 
> Cheers,
> Martin
> 
> On 03.03.2015 08:18, mle...@ripnet.com wrote:
> > If you use the phase-resynch feature of the SBX card, and you have
> > common refclock and 1PPS across all your USRPs in the array,
> >   then you should be OK.
> >
> > In *general*, synthesized downconverters use fractional-N synthesizers
> > where their starting phase after a re-tune is random with respect to
> > any other synthesizer using the same reference clock.  That's just the
> > way
> > fractional- N synthesis works.  It happens that SBX uses an ADF4351
> > synthesizer, which has a (rare!) hardware feature to allow
> > phase-resynch after tuning.  In order to make this work, all SBXes in
your
> "array"
> > must be tuned at exactly the same time, so the timed_commands feature
> > must be used to do the tuning.
> >
> > See:
> >
> > http://files.ettus.com/manual/page_sync.html
> >
> > On 2015-03-03 11:05, Pengyu Zhang wrote:
> >
> >> Hi Guys,
> >> I am planning to build a mimo system which supports beam forming. Is
> >> USRP a good platform for my target? I do not want to use WARP because
> >> I need to operate at frequencies lower than 2.4GHz.
> >> A potential problem of USRP is phase alignment. As the following doc
> >> suggests, phase alignment can be done by MANUALLY tuning the phase.
> >> This process can be labor intensive when the number of antennas
> >> increases. I am also worried about the problem that the manual phase
> >> calibration might need to be done each time you use the mimo system.
> >> Is there any approach that can make this process much easier?
> >>
> http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updat
> ed
> >> .pdf Would be great if you can give me some suggestions about what
> >> devices should I use for building a mimo system for beam forming.
> >> Thanks.
> >> Pengyu
> >>
> >> ___
> >> 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
> >
> 
> 
> ___
> 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] Finish python app after some processing in a C++ work() function

[Jorge Gallo]

Marcus,

I read on the mailing list that the FG may not get killed if the FG uses
message passing. Is this already solved? Do I have to do anything else when
using message passing?

Thanks in advance.

On 4 March 2015 at 08:16, Jorge Gallo  wrote:

> Hi,
>
> That is what I call direct way =P
>
> Thank you Marcus!
>
>
> On 3 March 2015 at 17:53, Marcus Müller  wrote:
>
>>  Yes, just let the block return the magic WORK_DONE (==-1) value.
>>
>> Greetings,
>> Marcus
>>
>> On 03/03/2015 05:51 PM, Jorge Gallo wrote:
>>
>>  Hi,
>>
>>
>>
>> I would like to find a way of saying to Python top_block that it should
>> stop processing and the application must finish.
>>
>>
>>
>> One of the blocks of the application will be a custom block and after
>> gathering some samples it must tell python to stop.
>>
>>
>>
>> Is there a direct way of doing that?
>>
>>
>>
>> Regards,
>> Jorge
>>
>>
>> ___
>> 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] gr-fosphor with pybombs

[Sylvain Munaut]

Hi,


> ImportError: cannot import name fosphor

Does /home/cnlsdr1/pybombs/lib/python2.7/dist-packages/gnuradio/fosphor exist ?


Cheers,

Sylvain

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