[Discuss-gnuradio] Unable to run transceiver application on N210:XCVR2450

[Dhrubojyoti Roy]

I have developed a transceiver application to run with XCVR2450 on USRP
N210. My transceiver class has been created as follows:

class my_trans(gr.top_block):

def __init__(self, mod_class, demod_class, rx_callback, rx_callback2,
options):

gr.top_block.__init__(self)

# Get the modulation's bits_per_symbol
args = mod_class.extract_kwargs_from_options(options)
symbol_rate = options.bitrate / mod_class(**args).bits_per_symbol()

self.sink = uhd_transmitter(options.args, symbol_rate,
options.samples_per_symbol,
options.tx_freq, options.tx_gain,
options.spec, options.antenna,
options.verbose)

self.txpath = transmit_path(mod_class, options)
self.connect(self.txpath, self.sink)

# Get the demodulation's bits_per_symbol
args = demod_class.extract_kwargs_from_options(options)
symbol_rate = options.bitrate /
demod_class(**args).bits_per_symbol()

self.source = uhd_receiver(options.args, symbol_rate,
   options.samples_per_symbol,
   options.rx_freq, options.rx_gain,
   options.spec, options.rx_antenna,
   options.verbose)

options.samples_per_symbol = self.source._sps

self.rxpath = receive_path(demod_class, rx_callback, rx_callback2,
options)
self.connect(self.source, self.rxpath)

For testing, I set up one transceiver as a pure transmitter and another as
a pure receiver. The invocations were:

./transmitter.py -f 2.4G -A J1 --rx-freq=5G --rx-antenna=J2
./receiver.py -f 5G -A J1 --rx-freq=2.4G --rx-antenna=J2

where f and A refer to the transmit frequency and antenna respectively.
However, even though the transmitter reports transmission of packets (code
pattern similar to benchmark programs), the receiver is unable to receive
any packets. Strangely, if I run a pure transmitter without a receiver
component as in the original benchmark programs, the packets are received
correctly by the receiver program. I find this baffling, since I have used
separate frequencies and antennae for transmission and reception. I had
previously run a similar program on WBX daughterboard successfully. Could
someone please explain what's going on here?

-- 
Dhrubojyoti Roy
1655, North 4th Street, Apt-D
Columbus, OH-43201
Contact no.: +1-740-417-5890
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] B100 as clock master + B100 as clock slave

[Vincenzo Pellegrini]

Hi everybody,

just a very quick question:

is it possible to enslave the clock of a B100 to the clock of another B100
via the "REF IN" input or in some other way?
More precisely, is there a way to extract the clock signal from a B100 and
feed it into another B100 to enslave the latter to the former?

It would be great to be able to keep them in frequency and phase synch that
way.

thank you

vince

-- 
Vincenzo Pellegrini
http://www.youtube.com/user/wwvince1
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] spectrum sensing in gnuradio-companion

[ketlin Pedron]

Hello

I am looking for a way to assemble a spectrum sensing in gnuradio-companion.
Here in gnuradio.blogspot only found information about the file
usrp_spectrum_sense.py, but would like to know how to implement spectrum
sensing (including detection of energy) in gnuradio-companion.

Could anyone help me?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Use USRP1 and USRP N200 at the same time

[Noé Beuret]

Hi everyone,

 

I’m a student in a telecommunication school and I need to use GNURadio for a
project.

 

I have two USRP : 1 USRP1 (USB interface) and 1 USRP N200 (ethernet
interface). 

The USRP1 works with a software that use GNURadio 3.2.2.

 

Now, I need to develop an other software with the USRPN200. This software
need to run on the same computer, at same time that the first software.

 

What GNURadio and UHD version I need? It is possible to keep GNURadio 3.2.2,
install UHD and use both USRPs at the same time without conflict?

 

Thanks in advance for your response.

 

Noé

 

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

Re: [Discuss-gnuradio] spectrum sensing in gnuradio-companion

[Jonathan Fox]

I am actually doing something similar for cognitive radio, the best way to
go about it is to follow the tutorial online for how to write a signal
processing block
http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.html (I do
find a little vague on some parts); you can browse google for a more in
depth guide from University of Notre Dame. Keep in mind the FFT is a vector
output so you need adjust your sensing block to accept such a stream. If
you understand the underlying concepts of spectrum sensing then you should
be able to program it. For example, energy detection is based of the
Chi-squared test at a certain threshold of energy. Plenty of white papers
covering spectrum sensing.

-Jon

On Fri, Mar 23, 2012 at 8:32 AM, ketlin Pedron wrote:

> Hello
>
> I am looking for a way to assemble a spectrum sensing in
> gnuradio-companion.
> Here in gnuradio.blogspot only found information about the file
> usrp_spectrum_sense.py, but would like to know how to implement spectrum
> sensing (including detection of energy) in gnuradio-companion.
>
> Could anyone help me?
>
>
> ___
> 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] Use USRP1 and USRP N200 at the same time

[Martin Braun]

On Fri, Mar 23, 2012 at 01:51:00PM +0100, Noé Beuret wrote:
> Hi everyone,
> 
> I’m a student in a telecommunication school and I need to use GNURadio for a
> project.

Cool, good luck!

> I have two USRP : 1 USRP1 (USB interface) and 1 USRP N200 (ethernet 
> interface).
> 
> The USRP1 works with a software that use GNURadio 3.2.2.

...it also works with a current version (unless you've done something
super funky to it).

> 
> Now, I need to develop an other software with the USRPN200. This software need
> to run on the same computer, at same time that the first software.
> 
> What GNURadio and UHD version I need? It is possible to keep GNURadio 3.2.2,
> install UHD and use both USRPs at the same time without conflict?

3.2.2 is ancient. Unless you have a really, really good reason, don't
use it. Grab the newest version of both UHD and GNU Radio and *then*
start your project.

MB

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


pgpF5VusArd96.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Use USRP1 and USRP N200 at the same time

[Noé Beuret]

Hi!

Thanks a lot for your response.

Last week I tried to install the latest version of GNURadio and UHD with the 
script provided by Marcus Leech, but I read somewhere that GNURadio version 
need to be between 3.3 and 3.5 for working with USRP1 because newer version 
don't use libusrp...  It is right?

And it's not a problem to use both USRPs at the same time without conflict? For 
trying, it is possible to run uhd_fft.py and usrp_fft.py together?

Thanks ;-)

Noé

-Message d'origine-
De : discuss-gnuradio-bounces+noe_beuret=yahoo...@gnu.org 
[mailto:discuss-gnuradio-bounces+noe_beuret=yahoo...@gnu.org] De la part de 
Martin Braun
Envoyé : vendredi 23 mars 2012 14:25
À : discuss-gnuradio@gnu.org
Objet : Re: [Discuss-gnuradio] Use USRP1 and USRP N200 at the same time

On Fri, Mar 23, 2012 at 01:51:00PM +0100, Noé Beuret wrote:
> Hi everyone,
> 
> I’m a student in a telecommunication school and I need to use GNURadio 
> for a project.

Cool, good luck!

> I have two USRP : 1 USRP1 (USB interface) and 1 USRP N200 (ethernet 
> interface).
> 
> The USRP1 works with a software that use GNURadio 3.2.2.

...it also works with a current version (unless you've done something super 
funky to it).

> 
> Now, I need to develop an other software with the USRPN200. This 
> software need to run on the same computer, at same time that the first 
> software.
> 
> What GNURadio and UHD version I need? It is possible to keep GNURadio 
> 3.2.2, install UHD and use both USRPs at the same time without conflict?

3.2.2 is ancient. Unless you have a really, really good reason, don't use it. 
Grab the newest version of both UHD and GNU Radio and *then* start your project.

MB

--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and National Laboratory of 
the Helmholtz Association


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

Re: [Discuss-gnuradio] Use USRP1 and USRP N200 at the same time

[mleech]

  

USRP1 works just fine with the very-latest Gnu Radio and UHD just
fine--I ran one that way just the other night. So you can run
build-gnuradio to download the very latest UHD and Gnu Radio and it'll
work just fine with both your N210 and your USRP1. 

There's absolutely
no reason for a new user such as yourself to use any of the "classic"
API for USRP1. Just use UHD for everything. 

Yes, you should be able to
use two uhd_fft.py -- one setup to talk to your N210 and the other setup
to talk to your USRP1, that should work just fine. 

-Marcus 

On Fri,
23 Mar 2012 14:38:55 +0100, Noé Beuret wrote: 

> Hi!
> 
> Thanks a lot
for your response.
> 
> Last week I tried to install the latest version
of GNURadio and UHD with the script provided by Marcus Leech, but I read
somewhere that GNURadio version need to be between 3.3 and 3.5 for
working with USRP1 because newer version don't use libusrp... It is
right?
> 
> And it's not a problem to use both USRPs at the same time
without conflict? For trying, it is possible to run uhd_fft.py and
usrp_fft.py together?
> 
> Thanks ;-)
> 
> Noé
> 
> -Message
d'origine-
> De :
discuss-gnuradio-bounces+noe_beuret=yahoo...@gnu.org [1]
[mailto:discuss-gnuradio-bounces+noe_beuret=yahoo...@gnu.org [2]] De la
part de Martin Braun
> Envoyé : vendredi 23 mars 2012 14:25
> À :
discuss-gnuradio@gnu.org [3]
> Objet : Re: [Discuss-gnuradio] Use USRP1
and USRP N200 at the same time
> 
> On Fri, Mar 23, 2012 at 01:51:00PM
+0100, Noé Beuret wrote:
>> Hi everyone, I'm a student in a
telecommunication school and I need to use GNURadio for a project.
>
Cool, good luck! 
> 
>> I have two USRP : 1 USRP1 (USB interface) and 1
USRP N200 (ethernet interface). The USRP1 works with a software that use
GNURadio 3.2.2.
> ...it also works with a current version (unless you've
done something super funky to it). Now, I n
> 
>> time that the first
software. What GNURadio and UHD version I need? It is possible to keep
GNURadio 3.2.2, install UHD and use both USRPs at the same time without
conflict? 3.2.2 is ancient. Unless you have a really, really good
reason, don't use it. Grab the newest version of
> GNU Radio and *then*
start your project. MB -- Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research
Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721
608-43790 Fax: +49 721 608-46071 www.cel.kit.edu [4] KIT -- University
of the State of Baden-Württemberg and National Laboratory of the
Helmholtz Association ___
Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org [5]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [6]

 


Links:
--
[1]
mailto:discuss-gnuradio-bounces+noe_beuret=yahoo...@gnu.org
[2]
mailto:discuss-gnuradio-bounces+noe_beuret=yahoo...@gnu.org
[3]
mailto:discuss-gnuradio@gnu.org
[4] http://www.cel.kit.edu
[5]
mailto:Discuss-gnuradio@gnu.org
[6]
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] Problem of reinstalling ucla_zigbee_phy: no libgruel.la

[Zhonghua]

On 03/22/2012 09:02 PM, Josh Blum wrote:


On 03/22/2012 12:47 PM, Zhonghua wrote:

Hi all,

I changed something in the ucla_zigbee library and want to reinstall it.
But when I doing make, the following error occurred.
/bin/grep: /usr/lib/libgruel.la: No such file or directory
/usr/bin/sed: can't read path: No such file or directory
libtool: link: `/usr/lib/libgruel.la' is not a valid libtool archive
make[4]: *** [_ucla.la] Error 1
make[4]: Leaving directory `/home/root/utils/ucla_zigbee_phy/src/lib'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/root/utils/ucla_zigbee_phy/src/lib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/root/utils/ucla_zigbee_phy/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/root/utils/ucla_zigbee_phy'
make: *** [all] Error 2

My gnuradio was installed with the method of Cmake. Before that there is
no problem with installing ucla. I don't know what is the matter. Any
suggestion is fairly appreciated.


Ive seen this before with fcd. There is usually something old installed
that confuses the configure. Or the configure script has old stuff cached.

I recommend cleaning any old gnuradio installs first, instructions here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#The-problem-of-multiple-installs

Reinstall gnuradio

Reconfigure zigbee from a fresh source/build tree.

-josh

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I spent a long time to reinstall GNU Radio and then replaced my zigbee 
directory. But the problem still exits.


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

Re: [Discuss-gnuradio] detecting spectrum holes

[George Nychis]

Finding white space in the spectrum can be done by looking at power across
the bins you are monitoring.  I have done White space research with the
USRP2 and the WBX, and they worked out great for me.  So you're on the
right track!

Take a look at this work, Section 3.1:
http://static.usenix.org/event/nsdi10/tech/full_papers/yang.pdf

They have a basic technique for detecting white space.  Their paper was not
about the TV bands, but the technique should work elsewhere.

Best of luck, and welcome!

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

Re: [Discuss-gnuradio] Use USRP1 and USRP N200 at the same time

[Noé Beuret]

Hi Marcus,

 

Thanks for your response.

 

If I would use an old version of GNURadio it’s because a software that I need 
use it with USRP1. I’m afraid that this software doesn’t work if I use a newest 
gnuradio version or UHD.

 

Noé

 

 

De : discuss-gnuradio-bounces+noe_beuret=yahoo...@gnu.org 
[mailto:discuss-gnuradio-bounces+noe_beuret=yahoo...@gnu.org] De la part de 
mle...@ripnet.com
Envoyé : vendredi 23 mars 2012 15:04
À : discuss-gnuradio@gnu.org
Objet : Re: [Discuss-gnuradio] Use USRP1 and USRP N200 at the same time

 

USRP1 works just fine with the very-latest Gnu Radio and UHD just fine--I ran 
one that way just the other night.  So you can run build-gnuradio to download 
the very latest UHD and Gnu Radio and it'll work just fine with both your N210 
and your USRP1.

There's absolutely no reason for a new user such as yourself to use any of the 
"classic" API for USRP1.  Just use UHD for everything.

Yes, you should be able to use two uhd_fft.py -- one setup to talk to your N210 
and the other setup to talk to your USRP1, that should work just fine.

-Marcus

 

On Fri, 23 Mar 2012 14:38:55 +0100, Noé Beuret wrote:

Hi!
 
Thanks a lot for your response.
 
Last week I tried to install the latest version of GNURadio and UHD with the 
script provided by Marcus Leech, but I read somewhere that GNURadio version 
need to be between 3.3 and 3.5 for working with USRP1 because newer version 
don't use libusrp...  It is right?



And it's not a problem to use both USRPs at the same time without conflict? For 
trying, it is possible to run uhd_fft.py and usrp_fft.py together?
 
Thanks ;-)
 
Noé
 
-Message d'origine-
De : discuss-gnuradio-bounces+noe_beuret=yahoo...@gnu.org 
[mailto:discuss-gnuradio-bounces+noe_beuret=yahoo...@gnu.org] De la part de 
Martin Braun
Envoyé : vendredi 23 mars 2012 14:25
À : discuss-gnuradio@gnu.org
Objet : Re: [Discuss-gnuradio] Use USRP1 and USRP N200 at the same time
 
On Fri, Mar 23, 2012 at 01:51:00PM +0100, Noé Beuret wrote:

Hi everyone,
 
I’m a student in a telecommunication school and I need to use GNURadio 
for a project.

 
Cool, good luck!
 

I have two USRP : 1 USRP1 (USB interface) and 1 USRP N200 (ethernet interface).
 
The USRP1 works with a software that use GNURadio 3.2.2.

 
...it also works with a current version (unless you've done something super 
funky to it).
 

 
Now, I need to develop an other software with the USRPN200. This 
software need to run on the same computer, at same time that the first software.
 
What GNURadio and UHD version I need? It is possible to keep GNURadio 
3.2.2, install UHD and use both USRPs at the same time without conflict?

 
3.2.2 is ancient. Unless you have a really, really good reason, don't use it. 
Grab the newest version of both UHD and GNU Radio and *then* start your project.
 
MB
 
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
 
Dipl.-Ing. Martin Braun
Research Associate
 
Kaiserstraße 12
Building 05.01
76131 Karlsruhe
 
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
 
KIT -- University of the State of Baden-Württemberg and National Laboratory of 
the Helmholtz Association
 
 
___
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] Use USRP1 and USRP N200 at the same time

[mleech]

  

Conversion to UHD should be too hard. You generally don't have to
touch the "guts", just the source/sink blocks. 

-Marcus 

On Fri, 23
Mar 2012 15:29:26 +0100, Noé Beuret wrote: 

> Hi Marcus, 
> 
> Thanks
for your response. 
> 
> If I would use an old version of GNURadio it's
because a software that I need use it with USRP1. I'm afraid that this
software doesn't work if I use a newest gnuradio version or UHD. 
> 
>
Noé 
> 
> DE : discuss-gnuradio-bounces+noe_beuret=yahoo...@gnu.org
[mailto:discuss-gnuradio-bounces+noe_beuret=yahoo...@gnu.org] DE LA PART
DE mle...@ripnet.com
> ENVOYÉ : vendredi 23 mars 2012 15:04
> À :
discuss-gnuradio@gnu.org
> OBJET : Re: [Discuss-gnuradio] Use USRP1 and
USRP N200 at the same time 
> 
> USRP1 works just fine with the
very-latest Gnu Radio and UHD just fine--I ran one that way just the
other night. So you can run build-gnuradio to download the very latest
UHD and Gnu Radio and it'll work just fine with both your N210 and your
USRP1. 
> 
> There's absolutely no reason for a new user such as
yourself to use any of the "classic" API for USRP1. Just use UHD for
everything. 
> 
> Yes, you should be able to use two uhd_fft.py -- one
setup to talk to your N210 and the other setup to talk to your USRP1,
that should work just fine. 
> 
> -Marcus 
> 
> On Fri, 23 Mar 2012
14:38:55 +0100, Noé Beuret wrote: 
> 
>> Hi!
>> 
>> Thanks a lot for
your response.
>> 
>> Last week I tried to install the latest version of
GNURadio and UHD with the script provided by Marcus Leech, but I read
somewhere that GNURadio version need to be between 3.3 and 3.5 for
working with USRP1 because newer version don't use libusrp... It is
right?
>> 
>> And it's not a problem to use both USRPs at the same time
without conflict? For trying, it is possible to run uhd_fft.py and
usrp_fft.py together?
>> 
>> Thanks ;-)
>> 
>> Noé
>> 
>> -Message
d'origine-
>> 
>> De :
discuss-gnuradio-bounces+noe_beuret=yahoo...@gnu.org [1]
[mailto:discuss-gnuradio-bounces+noe_beuret=yahoo...@gnu.org [2]] De la
part de Martin Braun
>> 
>> Envoyé : vendredi 23 mars 2012 14:25
>> 
>>
À : discuss-gnuradio@gnu.org [3]
>> 
>> Objet : Re: [Discuss-gnuradio]
Use USRP1 and USRP N200 at the same time
>> 
>> On Fri, Mar 23, 2012 at
01:51:00PM +0100, Noé Beuret wrote:
>> 
>>> Hi everyone,
>>> 
>>> I'm a
student in a telecommunication school and I need to use GNURadio 
>>>

>>> for a project.
>> 
>> Cool, good luck!
>> 
>>> I have two USRP : 1
USRP1 (USB interface) and 1 USRP N200 (ethernet interface).
>>> 
>>> The
USRP1 works with a software that use GNURadio 3.2.2.
>> 
>> ...it also
works with a current version (unless you've done something super funky
to it).
>> 
>> Now, I need to develop an other software with the
USRPN200. This ; 
>>> 
>>> What GNURadio and UHD version I need? It is
possible to keep GNURadio 
>>> 
>>> 3.2.2, install UHD and use both
USRPs at the same time without conflict?
>>> 
>>> 3.2.2 is ancient.
Unless you have a really, really good reason, don't use it. Grab the
newest version of both UHD and GNU Radio and *then* start your
project.
>> -- o ignored --> 
>> 
>> --
>> 
>> Karlsruhe Institute of
Technology (KIT)
>> 
>> Communications Engineering Lab (CEL)
>> 
>>
Dipl.-Ing. Martin Braun
>> 
>> Research Associate
>> 
>> Kaiserstraße
12
>> 
>> Building 05.01
>> 
>> 76131 Karlsruhe
>> 
>> Phone: +49 721
608-43790
>> 
>> Fax: +49 721 608-46071
>> 
>> www.cel.kit.edu [4]
>>

>> KIT -- University of the State of Baden-Württemberg and National
Laboratory of the Helmholtz Association
>> 
>>
___
>> 
>> Discuss-gnuradio
mailing list
>> 
>> Discuss-gnuradio@gnu.org [5]
>> 
>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [6]

 


Links:
--
[1]
mailto:discuss-gnuradio-bounces+noe_beuret=yahoo...@gnu.org
[2]
mailto:discuss-gnuradio-bounces+noe_beuret=yahoo...@gnu.org
[3]
mailto:discuss-gnuradio@gnu.org
[4] http://www.cel.kit.edu
[5]
mailto:Discuss-gnuradio@gnu.org
[6]
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] Problem of reinstalling ucla_zigbee_phy: no libgruel.la

[Josh Blum]

On 03/23/2012 07:18 AM, Zhonghua wrote:
> On 03/22/2012 09:02 PM, Josh Blum wrote:
>>
>> On 03/22/2012 12:47 PM, Zhonghua wrote:
>>> Hi all,
>>>
>>> I changed something in the ucla_zigbee library and want to reinstall it.
>>> But when I doing make, the following error occurred.
>>> /bin/grep: /usr/lib/libgruel.la: No such file or directory
>>> /usr/bin/sed: can't read path: No such file or directory
>>> libtool: link: `/usr/lib/libgruel.la' is not a valid libtool archive
>>> make[4]: *** [_ucla.la] Error 1
>>> make[4]: Leaving directory `/home/root/utils/ucla_zigbee_phy/src/lib'
>>> make[3]: *** [all] Error 2
>>> make[3]: Leaving directory `/home/root/utils/ucla_zigbee_phy/src/lib'
>>> make[2]: *** [all-recursive] Error 1
>>> make[2]: Leaving directory `/home/root/utils/ucla_zigbee_phy/src'
>>> make[1]: *** [all-recursive] Error 1
>>> make[1]: Leaving directory `/home/root/utils/ucla_zigbee_phy'
>>> make: *** [all] Error 2
>>>
>>> My gnuradio was installed with the method of Cmake. Before that there is
>>> no problem with installing ucla. I don't know what is the matter. Any
>>> suggestion is fairly appreciated.
>>>
>> Ive seen this before with fcd. There is usually something old installed
>> that confuses the configure. Or the configure script has old stuff
>> cached.
>>
>> I recommend cleaning any old gnuradio installs first, instructions here:
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#The-problem-of-multiple-installs
>>
>>
>> Reinstall gnuradio
>>
>> Reconfigure zigbee from a fresh source/build tree.
>>
>> -josh
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> I spent a long time to reinstall GNU Radio and then replaced my zigbee
> directory. But the problem still exits.
> 

I don't know. I have ubuntu 11.10. The configure is good, but there is a
minor bug when make happens. See output: http://pastebin.com/ehMXAg25

-josh

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

Re: [Discuss-gnuradio] B100 as clock master + B100 as clock slave

[Nick Foster]

On Fri, Mar 23, 2012 at 3:41 AM, Vincenzo Pellegrini wrote:

> Hi everybody,
>
> just a very quick question:
>
> is it possible to enslave the clock of a B100 to the clock of another B100
> via the "REF IN" input or in some other way?
> More precisely, is there a way to extract the clock signal from a B100 and
> feed it into another B100 to enslave the latter to the former?
>
> It would be great to be able to keep them in frequency and phase synch
> that way.
>

Vincenzo,

The ref in input on B100 is intended to accept a 10MHz signal. Multiple
B100s can be synchronized by using a common reference, but there is no
facility to lock two B100s to each other without a common external
reference.

--n


>
> thank you
>
> vince
>
> --
> Vincenzo Pellegrini
> http://www.youtube.com/user/wwvince1
>
> ___
> 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] usrp_nbfm_ptt.py Error: __init__() takes exactly 4 arguments (6 given)

[mario behn]

Hi,

I'm trying to make usrp_nbfm_ptt.py to work with a N210 Rev.4. on
Ubuntu 11.10 and with Gnuradio
3.5.2.1

After my normal system info (see below), however, I get following message:

The debugged program raised the exception unhandled TypeError
"__init__() takes exactly 4 arguments (6 given)"
File: /home/usrp1/USRP/gnuradio/gr-uhd/examples/usrp_nbfm_ptt.py, Line: 81

I wonder if anyone has seen this error and let me know what I'm doing wrong.

With kind regards

Mario Behn

--

linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.004.000-325-g7e296167

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

UHD Warning:
   The hardware does not support the requested TX sample rate:
   Target sample rate: 0.32 MSps
   Actual sample rate: 0.320513 MSps
PCM name: pulse
Access types:
   MMAP_INTERLEAVED     NO
   MMAP_NONINTERLEAVED  NO
   MMAP_COMPLEX         NO
   RW_INTERLEAVED       YES
   RW_NONINTERLEAVED    NO
Formats:
   U8                   YES
   S16_LE               YES
   S16_BE               YES
   S32_LE               YES
   S32_BE               YES
   FLOAT_LE             YES
   FLOAT_BE             YES
   MU_LAW               YES
   A_LAW                YES
Number of channels
   min channels: 1
   max channels: 32
   1 channels  YES
   2 channels  YES
   3 channels  YES
   4 channels  YES
   5 channels  YES
   6 channels  YES
   7 channels  YES
   8 channels  YES
   9 channels  YES
   10 channels YES
   11 channels YES
   12 channels YES
   13 channels YES
   14 channels YES
   15 channels YES
   16 channels YES
Sample Rates:
   min rate:       1 (dir = 0)
   max rate:  192000 (dir = 0)
     8000  YES
    16000  YES
    22050  YES
    32000  YES
    44100  YES
    48000  YES
    96000  YES
   192000  YES
audio_alsa_source[pulse]: using S32_LE
Using Volk machine: avx_32
>>> gr_fir_fff: using SSE
>>> gr_fir_ccf: using SSE

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

Re: [Discuss-gnuradio] B100 as clock master + B100 as clock slave

[Vincenzo Pellegrini]

Hi Nick,
I have noticed that "j101" onboard the B100 outputs a 64 MHz reference.

Could it be possilble to feed that signal somehow into a second USRP B100
to be used as a reference?

Could it be possible as an alternative to lock two B100 to an external 10
MHz reference while still working at 8Msps sample rate ?

my best regards

vincenzo




Il giorno 23 marzo 2012 16:54, Nick Foster  ha scritto:

> On Fri, Mar 23, 2012 at 3:41 AM, Vincenzo Pellegrini wrote:
>
>> Hi everybody,
>>
>> just a very quick question:
>>
>> is it possible to enslave the clock of a B100 to the clock of another
>> B100 via the "REF IN" input or in some other way?
>>  More precisely, is there a way to extract the clock signal from a B100
>> and feed it into another B100 to enslave the latter to the former?
>>
>> It would be great to be able to keep them in frequency and phase synch
>> that way.
>>
>
> Vincenzo,
>
> The ref in input on B100 is intended to accept a 10MHz signal. Multiple
> B100s can be synchronized by using a common reference, but there is no
> facility to lock two B100s to each other without a common external
> reference.
>
> --n
>
>
>>
>> thank you
>>
>> vince
>>
>> --
>> Vincenzo Pellegrini
>> http://www.youtube.com/user/wwvince1
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>


-- 
Vincenzo Pellegrini
http://www.youtube.com/user/wwvince1
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segfault

[Stefan Ott]

> Oh, interesting. uhd_find_devices works fine but uhd_usrp_probe also
> segfaults. I thought that used to run, I'll try again with different
> uhd versions and report back.

The same thing happens with all versions of UHD that I tried:
uhd_find_devices works but uhd_usrp_probe causes a segfault.

cheers
-- 
Stefan Ott
Communication and Distributed Systems
Institute of Computer Science and Applied Mathematics
University of Bern

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

Re: [Discuss-gnuradio] B100 as clock master + B100 as clock slave

[Nick Foster]

On Fri, Mar 23, 2012 at 10:18 AM, Vincenzo Pellegrini wrote:

> Hi Nick,
> I have noticed that "j101" onboard the B100 outputs a 64 MHz reference.
>
> Could it be possilble to feed that signal somehow into a second USRP B100
> to be used as a reference?
>

You would have to go through some gymnastics (read: soldering) to get that
reference into the second B100, and some code rework to recalculate clock
rates based on a 64MHz (or divisor of 64MHz) instead of 10MHz.


>
> Could it be possible as an alternative to lock two B100 to an external 10
> MHz reference while still working at 8Msps sample rate ?
>

Yes, this is what the ref in connectors are for. The external reference is
independent of the sample rate. The B100s will continue to operate
normally, except locked to each other.

--n



>
> my best regards
>
> vincenzo
>
>
>
>
> Il giorno 23 marzo 2012 16:54, Nick Foster  ha scritto:
>
> On Fri, Mar 23, 2012 at 3:41 AM, Vincenzo Pellegrini wrote:
>>
>>> Hi everybody,
>>>
>>> just a very quick question:
>>>
>>> is it possible to enslave the clock of a B100 to the clock of another
>>> B100 via the "REF IN" input or in some other way?
>>>  More precisely, is there a way to extract the clock signal from a B100
>>> and feed it into another B100 to enslave the latter to the former?
>>>
>>> It would be great to be able to keep them in frequency and phase synch
>>> that way.
>>>
>>
>> Vincenzo,
>>
>> The ref in input on B100 is intended to accept a 10MHz signal. Multiple
>> B100s can be synchronized by using a common reference, but there is no
>> facility to lock two B100s to each other without a common external
>> reference.
>>
>> --n
>>
>>
>>>
>>> thank you
>>>
>>> vince
>>>
>>> --
>>> Vincenzo Pellegrini
>>> http://www.youtube.com/user/wwvince1
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>
>
> --
> Vincenzo Pellegrini
> http://www.youtube.com/user/wwvince1
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] usrp_nbfm_ptt.py Error: __init__() takes exactly 4 arguments (6 given)

[Ben Reynwar]

That sounds like the example is out-of-date.  It's calling some
function that expects a different number of arguments than it is
giving it.  If you included the entire error output then we could
better see what the problem was (i.e. which function is raising this
error).

Cheers,
Ben

On Fri, Mar 23, 2012 at 9:02 AM, mario behn  wrote:
> Hi,
>
> I'm trying to make usrp_nbfm_ptt.py to work with a N210 Rev.4. on
> Ubuntu 11.10 and with Gnuradio
> 3.5.2.1
>
> After my normal system info (see below), however, I get following message:
>
> The debugged program raised the exception unhandled TypeError
> "__init__() takes exactly 4 arguments (6 given)"
> File: /home/usrp1/USRP/gnuradio/gr-uhd/examples/usrp_nbfm_ptt.py, Line: 81
>
> I wonder if anyone has seen this error and let me know what I'm doing wrong.
>
> With kind regards
>
> Mario Behn
>
> --
>
> linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.004.000-325-g7e296167
>
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> UHD Warning:
>    The hardware does not support the requested TX sample rate:
>    Target sample rate: 0.32 MSps
>    Actual sample rate: 0.320513 MSps
> PCM name: pulse
> Access types:
>    MMAP_INTERLEAVED     NO
>    MMAP_NONINTERLEAVED  NO
>    MMAP_COMPLEX         NO
>    RW_INTERLEAVED       YES
>    RW_NONINTERLEAVED    NO
> Formats:
>    U8                   YES
>    S16_LE               YES
>    S16_BE               YES
>    S32_LE               YES
>    S32_BE               YES
>    FLOAT_LE             YES
>    FLOAT_BE             YES
>    MU_LAW               YES
>    A_LAW                YES
> Number of channels
>    min channels: 1
>    max channels: 32
>    1 channels  YES
>    2 channels  YES
>    3 channels  YES
>    4 channels  YES
>    5 channels  YES
>    6 channels  YES
>    7 channels  YES
>    8 channels  YES
>    9 channels  YES
>    10 channels YES
>    11 channels YES
>    12 channels YES
>    13 channels YES
>    14 channels YES
>    15 channels YES
>    16 channels YES
> Sample Rates:
>    min rate:       1 (dir = 0)
>    max rate:  192000 (dir = 0)
>      8000  YES
>     16000  YES
>     22050  YES
>     32000  YES
>     44100  YES
>     48000  YES
>     96000  YES
>    192000  YES
> audio_alsa_source[pulse]: using S32_LE
> Using Volk machine: avx_32
 gr_fir_fff: using SSE
 gr_fir_ccf: using SSE
>
> ___
> 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] B100 as clock master + B100 as clock slave

[Josh Blum]

On 03/23/2012 03:41 AM, Vincenzo Pellegrini wrote:
> Hi everybody,
> 
> just a very quick question:
> 
> is it possible to enslave the clock of a B100 to the clock of another B100
> via the "REF IN" input or in some other way?
> More precisely, is there a way to extract the clock signal from a B100 and
> feed it into another B100 to enslave the latter to the former?
> 
> It would be great to be able to keep them in frequency and phase synch that
> way.
> 

It just dawned on me, and this may be a good idea in general:

There is a clock sync pin (cgen_sync_b in the fpga top level).
Presumably, a shared PPS could trigger the clock sync signal across
multiple B100. This would synchronously reset the phase across all N
devices. It would require a little FPGA work.

-Josh

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

Re: [Discuss-gnuradio] B100 as clock master + B100 as clock slave

[Marcus D. Leech]

On 03/23/2012 01:56 PM, Josh Blum wrote:

It just dawned on me, and this may be a good idea in general:

There is a clock sync pin (cgen_sync_b in the fpga top level).
Presumably, a shared PPS could trigger the clock sync signal across
multiple B100. This would synchronously reset the phase across all N
devices. It would require a little FPGA work.

-Josh


Would need to be a one-shot, yes?



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



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

Re: [Discuss-gnuradio] usrp_nbfm_ptt.py Error: __init__() takes exactly 4 arguments (6 given)

[mario behn]

On Fri, Mar 23, 2012 at 5:50 PM, Ben Reynwar  wrote:
> That sounds like the example is out-of-date.  It's calling some
> function that expects a different number of arguments than it is
> giving it.  If you included the entire error output then we could
> better see what the problem was (i.e. which function is raising this
> error).
>
> Cheers,
> Ben

Hi Ben,

thank you for your answer. I agree, here is the total text of the
error, eric4 gives me:

The debugged program raised the exception unhandled TypeError
"__init__() takes exactly 4 arguments (6 given)"
File: /home/usrp1/USRP/gnuradio/gr-uhd/examples/usrp_nbfm_ptt.py, Line: 81

and highlights line 81 correspondingly:

76 self.txpath = transmit_path(options.args, options.spec,
77options.antenna, options.tx_gain,
78options.audio_input)
79 self.rxpath = receive_path(options.args, options.spec,
80   options.antenna, options.rx_gain,
81   options.audio_output)
82  self.connect(self.txpath)
83  self.connect(self.rxpath)

and it is actually the file available here:

http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/v3.5.3git/changes/gr-uhd/examples/usrp_nbfm_ptt.py

Is there any quick fix I can apply?

Cheers

Mario Behn

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

Re: [Discuss-gnuradio] detecting spectrum holes

[Abdelrahman Ahmed]

2012/3/23 George Nychis 

> Finding white space in the spectrum can be done by looking at power across
> the bins you are monitoring.  I have done White space research with the
> USRP2 and the WBX, and they worked out great for me.  So you're on the
> right track!
>
> Take a look at this work, Section 3.1:
> http://static.usenix.org/event/nsdi10/tech/full_papers/yang.pdf
>
> They have a basic technique for detecting white space.  Their paper was
> not about the TV bands, but the technique should work elsewhere.
>
> Best of luck, and welcome!
>
> - George
>

ok, now i installed ubuntu from scratch on the two laptops not with windows.

so is there something missing in this installation :

 i used this link in synaptic to install gnuradio packages:

11.10 contains 3.2.2.dfsg-1ubuntu7 (
http://packages.ubuntu.com/oneiric/gnuradio)

 and this guide to install the other packages :

http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Install-Dependencies

After successful installation still there is UHD, i installed it through
this:

git clone git://code.ettus.com/ettus/uhd.git

cd uhd/host

mkdir build

cd build

cmake ../

make

make test

sudo make install

#Check where your path is with "find |grep libuhd"

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib


i did not do anything else ??
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] detecting spectrum holes

[Nick Foster]

On Fri, Mar 23, 2012 at 11:56 AM, Abdelrahman Ahmed wrote:

>
>
> 2012/3/23 George Nychis 
>
>> Finding white space in the spectrum can be done by looking at power
>> across the bins you are monitoring.  I have done White space research with
>> the USRP2 and the WBX, and they worked out great for me.  So you're on the
>> right track!
>>
>> Take a look at this work, Section 3.1:
>> http://static.usenix.org/event/nsdi10/tech/full_papers/yang.pdf
>>
>> They have a basic technique for detecting white space.  Their paper was
>> not about the TV bands, but the technique should work elsewhere.
>>
>> Best of luck, and welcome!
>>
>> - George
>>
>
> ok, now i installed ubuntu from scratch on the two laptops not with
> windows.
>
> so is there something missing in this installation :
>
>
>  i used this link in synaptic to install gnuradio packages:
>
> 11.10 contains 3.2.2.dfsg-1ubuntu7 (
> http://packages.ubuntu.com/oneiric/gnuradio)
>
>  and this guide to install the other packages :
>
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Install-Dependencies
>
> After successful installation still there is UHD, i installed it through
> this:
>
> git clone git://code.ettus.com/ettus/uhd.git
>
> cd uhd/host
>
> mkdir build
>
> cd build
>
> cmake ../
>
> make
>
> make test
>
> sudo make install
>
> #Check where your path is with "find |grep libuhd"
>
> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
>
>
> i did not do anything else ??
>

This is an ancient version of Gnuradio. Please use Marcus Leech's
"build-gnuradio" script, available here:

http://www.sbrac.org/files/build-gnuradio

Uninstall your Gnuradio with Synaptic first.

--n


>
> ___
> 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] detecting spectrum holes

[Marcus D. Leech]

On 03/23/2012 02:56 PM, Abdelrahman Ahmed wrote:



2012/3/23 George Nychis mailto:gnyc...@gmail.com>>

Finding white space in the spectrum can be done by looking at
power across the bins you are monitoring.  I have done White space
research with the USRP2 and the WBX, and they worked out great for
me.  So you're on the right track!

Take a look at this work, Section 3.1:
http://static.usenix.org/event/nsdi10/tech/full_papers/yang.pdf

They have a basic technique for detecting white space.  Their
paper was not about the TV bands, but the technique should work
elsewhere.

Best of luck, and welcome!

- George


ok, now i installed ubuntu from scratch on the two laptops not with 
windows.


so is there something missing in this installation :

i used this link in synaptic to install gnuradio packages:

11.10 contains 3.2.2.dfsg-1ubuntu7 
(http://packages.ubuntu.com/oneiric/gnuradio)


and this guide to install the other packages :

http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Install-Dependencies

After successful installation still there is UHD, i installed it 
through this:


git clone git://code.ettus.com/ettus/uhd.git 



cd uhd/host

mkdir build

cd build

cmake ../

make

make test

sudo make install

#Check where your path is with "find |grep libuhd"

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib


i did not do anything else ??


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Ok, someone else has already suggested this, and now I'm going to 
suggest it more assertively.


http://www.sbrac.org/files/build-gnuradio

If you fetch a packaged-by-the-distrib Gnu Radio, and a UHD from source, 
you're *guaranteed* to have compatibility/ABI problems.


So, again:

http://www.sbrac.org/files/build-gnuradio

It works, so you don't have to.  It does require that you have SUDO 
access, but you should have that anyway.


Download it, chmod it 755 and simply run it.  It will acquire SUDO as it 
needs to and prompt you.


Takes under an hour even on fairly wimpy machines.



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

[Discuss-gnuradio] Confused after upgrade to UHD USRP Source + WBX

[Jasper Kanbier]

Hi,

 

I just upgraded my gnuradio software and noticed there is a different usrp
source block (uhd)

Now I am puzzled how to configure my usrp1.

 

I got a LFRX on TXA and a WBX on TBX and have no clue how to set up the USRP
Source Block in GRC..

 

Is there any doecumentation, release notes on this???

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

Re: [Discuss-gnuradio] Confused after upgrade to UHD USRP Source + WBX

[Josh Blum]

On 03/23/2012 12:00 PM, Jasper Kanbier wrote:
> Hi,
> 
>  
> 
> I just upgraded my gnuradio software and noticed there is a different usrp
> source block (uhd)
> 
> Now I am puzzled how to configure my usrp1.
> 
>  
> 
> I got a LFRX on TXA and a WBX on TBX and have no clue how to set up the USRP
> Source Block in GRC..
> 

For this, set the subdev/frontend specification to the string

"A:AB B:0"

This puts the IQ subdevice of the LFRX on DSP0, and the WBX on DSP1

>  
> 
> Is there any doecumentation, release notes on this???
> 
> 

Here is a folder worth of examples:
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/examples
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/apps

Also, see the documentation in the UHD source/sink blocks in GRC (there
is quite a bit).

-Josh

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

Re: [Discuss-gnuradio] Confused after upgrade to UHD USRP Source + WBX

[Marcus D. Leech]

On 03/23/2012 03:00 PM, Jasper Kanbier wrote:


Hi,

I just upgraded my gnuradio software and noticed there is a different 
usrp source block (uhd)


Now I am puzzled how to configure my usrp1.

I got a LFRX on TXA and a WBX on TBX and have no clue how to set up 
the USRP Source Block in GRC..


Is there any doecumentation, release notes on this???


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

Like this:

http://files.ettus.com/uhd_docs/manual/html/index.html

You mean?

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] No-go on the GSoC

[Nick Foster]

On Fri, Mar 16, 2012 at 11:05 AM, Tom Rondeau  wrote:

> Sorry gang, GNU Radio was not accepted as a mentor organization for the
> GSoC this year. I'm very disappointed, as I'm sure everyone who helped out
> here is, too. I thought we had great project ideas and application, but it
> apparently wasn't enough.
>
> Well, on to the next big thing!
>

Just to follow up w/ the GSoC thing. Google held their "rejection
discussion" meeting today via IRC. Here's what they had to say about the
Gnuradio application:

gsocbot: kblin: Next in line is gnuradio|bistrom with notice 'gnuradio
http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoC'
carols: hi gnuradio folks
gnuradio|bistrom: hi there
carols: so i have similar feedback to the feedback i had for octave.
carols: I'm hoping that you can participate under the gnu project umbrella.
carols: we were making a lot of tough calls on space and this was one i put
into the category of that we'd like you to participate under their umbrella.
carols: i really love your ideas page.
carols: and the application.
carols: we just didn't have enough space for everyone.
gnuradio|bistrom: thanks, glad to hear it! glad to hear we're on the right
track with the app.
carols: yes, definitely.
gnuradio|bistrom: we'll update & reapply next yr then. thanks!
carols: you're welcome. thank you!
carols: hope you have a good summer and get some students through gnu
project.

So good job with the application, everyone (especially Tom!). Students
wishing to make a contribution to Gnuradio are still obviously encouraged,
and we're happy to find a mentor for anyone wishing to tackle a project.

--n


>
> Tom
>
>
> ___
> 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] usrp_nbfm_ptt.py Error: __init__() takes exactly 4 arguments (6 given)

[Ben Reynwar]

On Fri, Mar 23, 2012 at 11:30 AM, mario behn  wrote:
> On Fri, Mar 23, 2012 at 5:50 PM, Ben Reynwar  wrote:
>> That sounds like the example is out-of-date.  It's calling some
>> function that expects a different number of arguments than it is
>> giving it.  If you included the entire error output then we could
>> better see what the problem was (i.e. which function is raising this
>> error).
>>
>> Cheers,
>> Ben
>
> Hi Ben,
>
> thank you for your answer. I agree, here is the total text of the
> error, eric4 gives me:
>
> The debugged program raised the exception unhandled TypeError
> "__init__() takes exactly 4 arguments (6 given)"
> File: /home/usrp1/USRP/gnuradio/gr-uhd/examples/usrp_nbfm_ptt.py, Line: 81
>
> and highlights line 81 correspondingly:
>
> 76     self.txpath = transmit_path(options.args, options.spec,
> 77                                    options.antenna, options.tx_gain,
> 78                                    options.audio_input)
> 79     self.rxpath = receive_path(options.args, options.spec,
> 80                                   options.antenna, options.rx_gain,
> 81                                   options.audio_output)
> 82      self.connect(self.txpath)
> 83      self.connect(self.rxpath)
>
> and it is actually the file available here:
>
> http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/v3.5.3git/changes/gr-uhd/examples/usrp_nbfm_ptt.py
>
> Is there any quick fix I can apply?
>
> Cheers
>
> Mario Behn

Yep, there is an error in that file.  The receive_path defined on line
371 isn't compatible with the call to receive_path on line 79.
Perhaps try removing options.spec and options.antenna from the call,
but I'm just guessing, I haven't used this example before.

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

Re: [Discuss-gnuradio] usrp_nbfm_ptt.py Error: __init__() takes exactly 4 arguments (6 given)

[Ben Reynwar]

I'm pretty sure this will fix it.

replace line 372:

def __init__(self, args, gain, audio_output):

with

def __init__(self, args, spec, antenna, gain, audio_output):

On Fri, Mar 23, 2012 at 1:23 PM, Ben Reynwar  wrote:
> On Fri, Mar 23, 2012 at 11:30 AM, mario behn  wrote:
>> On Fri, Mar 23, 2012 at 5:50 PM, Ben Reynwar  wrote:
>>> That sounds like the example is out-of-date.  It's calling some
>>> function that expects a different number of arguments than it is
>>> giving it.  If you included the entire error output then we could
>>> better see what the problem was (i.e. which function is raising this
>>> error).
>>>
>>> Cheers,
>>> Ben
>>
>> Hi Ben,
>>
>> thank you for your answer. I agree, here is the total text of the
>> error, eric4 gives me:
>>
>> The debugged program raised the exception unhandled TypeError
>> "__init__() takes exactly 4 arguments (6 given)"
>> File: /home/usrp1/USRP/gnuradio/gr-uhd/examples/usrp_nbfm_ptt.py, Line: 81
>>
>> and highlights line 81 correspondingly:
>>
>> 76     self.txpath = transmit_path(options.args, options.spec,
>> 77                                    options.antenna, options.tx_gain,
>> 78                                    options.audio_input)
>> 79     self.rxpath = receive_path(options.args, options.spec,
>> 80                                   options.antenna, options.rx_gain,
>> 81                                   options.audio_output)
>> 82      self.connect(self.txpath)
>> 83      self.connect(self.rxpath)
>>
>> and it is actually the file available here:
>>
>> http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/v3.5.3git/changes/gr-uhd/examples/usrp_nbfm_ptt.py
>>
>> Is there any quick fix I can apply?
>>
>> Cheers
>>
>> Mario Behn
>
> Yep, there is an error in that file.  The receive_path defined on line
> 371 isn't compatible with the call to receive_path on line 79.
> Perhaps try removing options.spec and options.antenna from the call,
> but I'm just guessing, I haven't used this example before.

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

Re: [Discuss-gnuradio] usrp_nbfm_ptt.py Error: __init__() takes exactly 4 arguments (6 given)

[mario behn]

Yes, it does. The application is starting now without any error. Thanks.

On Fri, Mar 23, 2012 at 8:55 PM, Ben Reynwar  wrote:
> I'm pretty sure this will fix it.
>
> replace line 372:
>
>    def __init__(self, args, gain, audio_output):
>
> with
>
>    def __init__(self, args, spec, antenna, gain, audio_output):
>
> On Fri, Mar 23, 2012 at 1:23 PM, Ben Reynwar  wrote:
>> On Fri, Mar 23, 2012 at 11:30 AM, mario behn  wrote:
>>> On Fri, Mar 23, 2012 at 5:50 PM, Ben Reynwar  wrote:
 That sounds like the example is out-of-date.  It's calling some
 function that expects a different number of arguments than it is
 giving it.  If you included the entire error output then we could
 better see what the problem was (i.e. which function is raising this
 error).

 Cheers,
 Ben
>>>
>>> Hi Ben,
>>>
>>> thank you for your answer. I agree, here is the total text of the
>>> error, eric4 gives me:
>>>
>>> The debugged program raised the exception unhandled TypeError
>>> "__init__() takes exactly 4 arguments (6 given)"
>>> File: /home/usrp1/USRP/gnuradio/gr-uhd/examples/usrp_nbfm_ptt.py, Line: 81
>>>
>>> and highlights line 81 correspondingly:
>>>
>>> 76     self.txpath = transmit_path(options.args, options.spec,
>>> 77                                    options.antenna, options.tx_gain,
>>> 78                                    options.audio_input)
>>> 79     self.rxpath = receive_path(options.args, options.spec,
>>> 80                                   options.antenna, options.rx_gain,
>>> 81                                   options.audio_output)
>>> 82      self.connect(self.txpath)
>>> 83      self.connect(self.rxpath)
>>>
>>> and it is actually the file available here:
>>>
>>> http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/v3.5.3git/changes/gr-uhd/examples/usrp_nbfm_ptt.py
>>>
>>> Is there any quick fix I can apply?
>>>
>>> Cheers
>>>
>>> Mario Behn
>>
>> Yep, there is an error in that file.  The receive_path defined on line
>> 371 isn't compatible with the call to receive_path on line 79.
>> Perhaps try removing options.spec and options.antenna from the call,
>> but I'm just guessing, I haven't used this example before.

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

[Discuss-gnuradio] Responsive programmed push to talk in usrp_nbfm_ptt.py

[mario behn]

Hi,

I wonder what is the easiest way to implement an automatic responsive
push to talk?

1. while I'm in receive mode, I would like to sense if there is a signal,
2. If this is the case I would like to transmit a predefined signal
for a set time frame.
3. I would also like to cycle throuht 4 set frequencies in time.

With kind regards

Mario Behn

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

[Discuss-gnuradio] GNU Radio and Google Summer of Code

[Philip Balister]

Although the GNU Radio project was not accepted to GSoC, the GNU project
was. Since we are part of the project people interested in GSoC and GNU
Radio can apply to the GNU Project.

http://www.gnu.org/software/soc-projects/ideas-2012.html

Applications are due on April 6. Double check for the UTC closing time :)

Sorry for the late notice on this, we had a hiccup with the GNU process.

Philip

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

Re: [Discuss-gnuradio] GR 3.5.1 & OSX

[Arturo Rinaldi]

Nella citazione in data Thu Mar 22 23:43:29 2012, Arturo Rinaldi ha 
scritto:

Nella citazione in data Thu Mar 22 15:17:03 2012, Michael Dickens ha
scritto:

On Mar 22, 2012, at 9:55 AM, Arturo Rinaldi wrote:

I think i've sorted out the dependencies for building gnuradio on
Lion 10.7.3

sudo port install boost icu cppunit fftw-3-single gawk \
readline gsl texinfo guile python27 py27-numpy py27-nose
py27-distribute \
libsndfile portaudio py27-opengl py27-opengl-accelerate py27-pil
lcms py27-tkinter \
py27-wxpython wxWidgets mesa makedepend xorg-dri2proto xorg-glproto
xorg-libXmu \
py27-cheetah py27-gtk libglade2 py27-cairo py27-py py27-gobject
py27-lxml doxygen \
libusb-legacy sdcc29 gputils py27-pyqt4 py27-sip py27-pyqwt qt4-mac
dbus libmng qt4-mac qwtplot3d qwt52 libsdl


Yeah; I'd believe that. Nothing like a "few" background dependencies
as added by MacPorts to those top-level ones. I tried creating a
stand-alone .app for GRC, and it turned out to be something like 600
MB when all of these dependencies were included. Many of them are
spurious -- not directly relevant -- but include as options or
whatever. MP folks have had a discussion about this issue recently,
since it's a real problem.


However :

First
py27-wxpython doesn't install on macports. I'll post it on the
macports mailing list then we aren't able to use the wxgui module


There's are a few discussions about py27-wxpython on various MP lists
right now. Seems like maybe you're not alone. Please do search for a
ticket for:< https://trac.macports.org/search>. I have no issue with
this port on 10.6.8, and it works correctly with 64-bit Wx!


Second
by using autotools with

./configure LDFLAGS="-L/opt/local/lib"
CPPFLAGS="-I/opt/local/include" CC=clang --disable-gr-qtgui
--disable-docs

builds the latest tarball (3.5.2.1) and i need some help for the
DYLD_LIBRARY_PATH because gnuradio-companion start with an error
message though PYTHONPATH is correctly set


You should be able to compile GR without LDFLAGS or CPPFLAGS, if
you've set the PKG_CONFIG_PATH to include "/opt/local/lib/pkgconfig".
You'll probably want to set CXX to clang++ (or, whatever that is
called) along with CC; I don't think CC is actually used, but it
can't hurt to set it. Once installed, you should be able to execute
GR scripts and GRC without resorting to the DYLD_LIBRARY_PATH -- the
PATH and PYTHONPATH should be sufficient.


Third
downloaded the git version and after the usual steps with cmake, the
building crashes at the 3% with the error

cc1: error: unrecognized command line option "-mpopcnt"
make[2]: ***
[volk/lib/CMakeFiles/volk.dir/volk_machine_sse4_a_64.c.o] Error 1
make[1]: *** [volk/lib/CMakeFiles/volk.dir/all] Error 2
make: *** [all] Error 2


No idea, but using CMake is the way to go to get Volk working. Could
be an OSX 10.7 issue; I'm still using 10.6 though I do do testing
using an OSX 10.7 boot disk. I haven't tried this in a while, so I'll
give it a whirl later today or tomorrow, as time allows.

Good luck! - MLD


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



ok i'll do other "experiments" and report news.thx very much :D


downloaded the latest git version and made a little progress in the 
third case. I set :


export CXX=clang++
export CC=clang

and the cmake building worked ! ! !. Now i have to set the python path 
correctly. GRC still doesn't run but the python interpreter import the 
gnuradio module correctly.


i removed the documentantion from building because it seems to stuck at 
a certain point, and cpu(s) load is at full ! ! !


The py27-wxpython issue still remains, i'll post a ticket on macports

Regards, Arturo

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

[Discuss-gnuradio] UHD Announcement - March 23rd 2012

[Josh Blum]

Hello list,

---
-- Tagged a 3.4.0 release
---
A 3.4.0 release has been tagged. Its been a long time coming since the
last release. 3.4.0 contains the new features which have appeared on the
master branch over the last few months. To name a few:

* higher sample rates/sc8 wire format
* self-calibration utilities for SBX/WBX
* TX/RX stream API is now official

The relevant downloads page have moved, you can find a link to
installers for this release here:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki/Downloads#Installer-packages

Changelog:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki/ChangeLog

---
-- Linux repository hosting
---
There is now a repository for fedora and ubuntu so you can apt-get or
yum install uhd:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_Linux

We have installers uploaded for Ubuntu (10.04-11.10) and Fedora (15-16).
Let me know if you have an issues adding the repo or installing.

---
-- New feature - alternative stream destination
---
With USRP2/N-Series, you can tell the USRP to stream RX samples to an
arbitrary location on the network. This should be useful to individuals
who desire distributed processing. Of course its not hard to generate
more data than a singe PC can handle :-)

Using this feature will require the master branch, latest images for the
master branch, and that the USRP be programmed with a gateway and subnet
address.

Relevant instructions here:
http://files.ettus.com/uhd_docs/manual/html/usrp2.html#alternative-stream-destination
This feature can also be used in gnuradio by setting the stream args
(mentioned in the link above) in the usrp source constructor.

Link to master branch images here:
http://files.ettus.com/binaries/master_images/

---
-- New feature - timed commands
---
Using this feature, you can schedule precisely, to the clock cycle, when
settings are activated on the device. Example, tuning a receive chain or
setting a gain at a specific time. This should be exiting for frequency
hoping applications and applications that require phase coherence (see
SBX notes below).

To use this feature, simply wrap the set/clear_command_time calls around
existing settings code you wish to control in a timed fashion. There is
a caveat; some API calls, that should be settings-only, involve
readbacks from the device. In these situations, timed commands cannot
work (which is why this is a next branch feature). We will be working to
ensure that any code worth timing isn't internally blocking on a
readback from the device.

I wrote some documentation on how to use this feature to phase-align a
group of SBXs. Since the docs are not uploaded yet, I will leave this
snippet here: http://pastebin.com/NxGtWiML The same mechanism and API
calls are also available through gr-uhd and can be called within python.

The additional benefit to this feature is that commands on
USRP2/N-Series are no longer interpreted by the soft CPU, but directly
by an FPGA state machine. This means that RTT for control packets (aka
settings) has gone way down, on the order of 100us over gigE.

So far the timed commands feature is only implemented on N-series. E100
will be coming soon. To use this feature, you will need to checkout the
uhd's next branch and burn next branch images on your device.

Link to next branch images here:
http://files.ettus.com/binaries/next_images/

---

Feedback and testing are always welcome!
-Josh

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