Re: [Discuss-gnuradio] WAV sink

[Martin Braun]

On Tue, Mar 27, 2012 at 12:21:50AM -0300, John Coppens wrote:
> 2) The wav sink doesn't seem to close the wav-file correctly. After
> writing an 82MB file, the size of the file (bytes 4-7) were 0. Many
> programs don't seem to mind this. 'snd' doesn't like it and won't open
> the file.
> 
> Also, the size of the 'data' block in the wav-file is not set.
> 
> Though I have seen the 'closing' routine in the wav code, can it be
> that it isn't called?

These bytes can only be set once the writing is finished, and it's
called from the destructor, so that might not be getting called...?
It also gets called when the WAV file changes.
Calling close() manually is also possible (but shouldn't be necessary).

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


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

Re: [Discuss-gnuradio] Building new blocks in Gnu Radio

[Martin Braun]

On Mon, Mar 26, 2012 at 12:27:42PM -0700, Nick Foster wrote:
> After this, I used cmake. I wrote:
> >cmake -i
> >sudo make
> >sudo make install
> >sudo ldconfig

I assume you know what you're doing, but just in case someone reads this
who doesn't, the recommended way is

mkdir build
cd build
cmake ../
make # This is what I mean
sudo make install
sudo ldconfig

So don't run make as root (permissions and so on).

> These were my steps to build a new block to use in GRC. However, I get 
> this
> error:
> 
> ImportError: /usr/local/lib/python2.7/dist-
> packages/mycoolstuff/_mycoolstuff_swig.so: undefined symbol:
> _Z38mycoolstuff_make_decimated_average_vccifi
> 
> Yes. My module and block are called mycoolstuff and
> decimated_average_vcc.cc
> 
> It seems that there is a problem with the swig. Do I have to configure
> anything
> in the .i files before starting to use cmake?
> 
> My guess is you haven't declared your functions as API exports. There should 
> be
> a file in your module called include/mycoolstuff_api.h, which should be #
> included by your block implementations and the public constructor declared 
> like
> this:
> 
> MYCOOLSTUFF_API mycoolstuff_make_decimated_average(.) {}
> 
> This will export the symbol so it gets called out in the library.

If you use gr_modtool.py, it will take care of this.

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


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

[Discuss-gnuradio] Strange problem when using build-gnuradio script

[Wu Ting]

Hi all,

 

I'm using build-gnuradio script to build gnuradio and uhd. It works well
before (both on Ubuntu 10.04 and 11.10). However, on my current computer
(Ubuntu 10.04), it has a strange problem. At first, it kept showing some
libs are not found. After installing these libs and trying for several
times, it finally finished installing. But it finished with such
information:

 


You should probably set your PYTHONPATH to:
 

 
in your .bashrc or equivalent file prior to attempting to run
any Gnu Radio applications or Gnu Radio Companion.
*
Done function pythonpath at: Tue Mar 27 16:34:46 JST 2012
Done all functions at: Tue Mar 27 16:34:46 JST 2012
All Done

 

 

There is EMPTY line below "You should probably set your PYTHONPATH to:".

And I cannot run any gnuradio script. 

I also tried this:

 

>>> from gnuradio import gr
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named gnuradio

 

I also noticed that there is no .py files under /usr/local/bin/.

There are only these files:

uhd_cal_tx_dc_offset   uhd_find_devices  volk_profile
uhd_cal_rx_iq_balance   uhd_cal_tx_iq_balance  uhd_usrp_probe

 

Anyone know what is the problem?

 

Thanks.

 

Wu

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

Re: [Discuss-gnuradio] Strange problem when using build-gnuradio script

[Marcus D. Leech]

On 03/27/2012 03:59 AM, Wu Ting wrote:


Hi all,

I'm using build-gnuradio script to build gnuradio and uhd. It works 
well before (both on Ubuntu 10.04 and 11.10). However, on my current 
computer (Ubuntu 10.04), it has a strange problem. At first, it kept 
showing some libs are not found. After installing these libs and 
trying for several times, it finally finished installing. But it 
finished with such information:



You should probably set your PYTHONPATH to:



in your .bashrc or equivalent file prior to attempting to run
any Gnu Radio applications or Gnu Radio Companion.
*
Done function pythonpath at: Tue Mar 27 16:34:46 JST 2012
Done all functions at: Tue Mar 27 16:34:46 JST 2012
All Done

There is EMPTY line below "You should probably set your PYTHONPATH to:".

And I cannot run any gnuradio script.

I also tried this:

>>> from gnuradio import gr
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named gnuradio

I also noticed that there is no .py files under /usr/local/bin/.

There are only these files:

uhd_cal_tx_dc_offset   uhd_find_devices  volk_profile
uhd_cal_rx_iq_balance   uhd_cal_tx_iq_balance  uhd_usrp_probe

Anyone know what is the problem?

Thanks.

Wu


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re-run it with --verbose to see where it went off the rails.  it clearly 
didn't build/install Gnu Radio, only UHD.  The blank Pythonpath is because
  it couldn't find any Gnu Radio bits in any of the places it looks for 
locally-installed Python bits.




--
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] Python shared libraries installed to /usr/lib/ on x86_64 architecture

[Joschi Brauchle]

Hello everyone,

I am having the following problem on an x86_64 linux machine:

When I use the ZIP-release (currently 3.5.2.1, using configure&make) 
from the GNUradio homepage to build GNUradio, the python shared 
libraries always get installed to %{prefix}/lib/python.../ instead of 
%{prefix}/lib64/python.../ as would be appropriate.


If I use the GIT release (currently 3.5.3git, using CMake), this is NOT 
the case and the shared libraries get correctly installed to 
%{prefix}/lib64/python.../


So I did debug the problem and ended up at this commit:
http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/1c51b4166f80147b179670ae015f445e9ef5103a/diff/config/gr_python.m4

It adds a logic to detect the python pyexecdir path, but does not do 
this correctly. I have to mention, that I personally believe that AM 
does all this correctly in the first place, no need for additional 
logic. Anyways, in line 58 of /config/gr_python.m4 reads:

path = distutils.sysconfig.get_python_lib()
which is used for the pyexecdir variable later on.

This is clearly wrong, as the shared libraries installed are definitely 
arch dependent. Hence, this the line should read (note the parameter "1"):

path = distutils.sysconfig.get_python_lib(1)

Best regards,
--
Dipl.-Ing. Joschi Brauchle, M.Sc.

Institute for Communications Engineering (LNT)
Technische Universitaet Muenchen (TUM)
80290 Munich, Germany

Tel (work): +49 89 289-23474
Fax (work): +49 89 289-23490
E-mail: joschi.brauc...@tum.de
Web: http://www.lnt.ei.tum.de/



smime.p7s
Description: S/MIME Cryptographic Signature
___
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, thanks for the answer.

Everything clear.
Just a further question.
Would a 0V-mean, 3.3V peak-to-peak sinusoid be correct as a reference
signal for the B100?

regards

vince



Il giorno 23 marzo 2012 18:30, Nick Foster  ha scritto:

> 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
>>
>
>


-- 
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] B100 as clock master + B100 as clock slave

[Vincenzo Pellegrini]

Josh,
I agree this would be a great feature.

vince


>
> 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
>



-- 
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] B100 as clock master + B100 as clock slave

[Rafael Diniz]

Hi Vince,

Changing a little the topic, have you managed to run your SoftDVB code to
work on multiple USRPs in order to create a SFN DVB configuration?

Best regards,
Rafael Diniz

> Josh,
> I agree this would be a great feature.
>
> vince
>
>
>>
>> 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] WAV sink

[John Coppens]

On Tue, 27 Mar 2012 09:36:14 +0200
Martin Braun  wrote:

> These bytes can only be set once the writing is finished, and it's
> called from the destructor, so that might not be getting called...?
> It also gets called when the WAV file changes.
> Calling close() manually is also possible (but shouldn't be necessary).

Hallo Martin,

Yes, I know. I'm running GRC, so I don't really know if the destructor
is called or not. I haven't found the time yet to check the code in
top_block.py.

With close() I really meant the destructor and its code in
gri_wav_file.cc. I did see the closing code in gri_wav_file, when I
wrote my mat-file, so I suspect either the destructor isn't called, or
the destructor doesn't call the gri_-code.

Will try to have a look later.

John

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

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

[Noé Beuret]

Hi!

I have not managed to install what I wanted for my school project.
After gnuradio and uhd installation with the build_gnuradio script, 
uhd_find_device found only usrp n200 but not usrp1...

I didn't have much time so I wouldn't touch anything in the first software. So 
I would start writing the second software even if the work environment is not 
perfect. I hope that problems will be resolved later


My professor give me this  : 

1 USRP1
1 USRP N200
1 software that use gnuradio-3.2.2


Now I have to write software that uses UHD and works in parallel with the first 
software. 


The objective of this second software is to use the usrp n200 to emit a cosinus 
signal that have a span of 1MHz. 
Somebody can help me to start with this UHD project? Where can I find a 
tutorial (or examples) for writing uhd application?

Thanks a lot in advance!

Noé




 De : "mle...@ripnet.com" 
À : discuss-gnuradio@gnu.org 
Envoyé le : Vendredi 23 mars 2012 15h55
Objet : Re: [Discuss-gnuradio] Use USRP1 and USRP N200 at the same time
 

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 
>>[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___
Discuss-gnuradio m

Re: [Discuss-gnuradio] Building new blocks in Gnu Radio

[Ben Reynwar]

On Mon, Mar 26, 2012 at 12:54 PM, Ben Reynwar  wrote:
> On Mon, Mar 26, 2012 at 10:42 AM, Francisco
>  wrote:
>> Ben Reynwar  reynwar.net> writes:
>>
>>>
>>> I think that the best way to get started is to use Martins gr-modtool.
>>>  It will help you to make out-of-tree blocks (out-of-tree means
>>> separate but compatible with your main gnuradio installation).
>>>
>>> It can be found at:
>>> https://github.com/mbant/gr-modtool
>>>
>>> On Mon, Mar 26, 2012 at 2:58 AM, Ebtisam Ahmed  
>>> gmail.com>
>> wrote:
>>> > Indeed i have read but i cant understand the building process. I built
>>> > it the i understood but it failed terribly, i have made .h .cc .i and
>>> > makefile.am. Put them in one folder and then done make. i also tried
>>> > ./configure and ./bootstrap but it doesnt work
>>> >
>>> > Anyways thanx for ur time and help me on this
>>> >
>>> > Regards,
>>> > Ebtisam
>>> >
>>> > ___
>>> > Discuss-gnuradio mailing list
>>> > Discuss-gnuradio  gnu.org
>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>> Hi all,
>>
>> I've decided to follow your suggestion and get gr_modtool.py.
>>
>> First I created the module with this script which created some folders, files
>> and the .cc and .h files with skeleton code.
>>
>> Then I put my code in the .cc and .h files. I also changed the .xml file so I
>> can use GRC (I haven't used python yet to create graphs).
>>
>> After this, I used cmake. I wrote:
>>>cmake -i
>>>sudo make
>>>sudo make install
>>>sudo ldconfig
>>
>> These were my steps to build a new block to use in GRC. However, I get this
>> error:
>>
>> ImportError: /usr/local/lib/python2.7/dist-
>> packages/mycoolstuff/_mycoolstuff_swig.so: undefined symbol:
>> _Z38mycoolstuff_make_decimated_average_vccifi
>>
>> Yes. My module and block are called mycoolstuff and decimated_average_vcc.cc
>>
>> It seems that there is a problem with the swig. Do I have to configure 
>> anything
>> in the .i files before starting to use cmake?
>>
>> Regards,
>> Francisco
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> It looks like there is currently a bug in gr-modtool where when you
> generate a new block it gets the module and block name wrong way
> round.

There's no bug.  I'm just incompetent.

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

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

[mleech]

  

Try: 

uhd_usrp_probe --args "type=usrp1" 

Then 

uhd_usrp_probe
--args "addr=192.168.10.2" 

That should (assuming you have networking
setup correctly) give you probe outputs from both your USRP1 and N200.


On Tue, 27 Mar 2012 16:06:05 +0100 (BST), Noé Beuret wrote: 

> Hi! 
>

> I have not managed to install what I wanted for my school project. 
>
After gnuradio and uhd installation with the build_gnuradio script,
uhd_find_device found only usrp n200 but not usrp1... 
> 
> I didn't
have much time so I wouldn't touch anything in the first software. So I
would start writing the second software even if the work environment is
not perfect. I hope that problems will be resolved later 
> 
> My
professor give me this : 
> 1 USRP1 
> 1 USRP N200 
> 1 software that
use gnuradio-3.2.2 
> 
> Now I have to write software that uses UHD and
works in parallel with the first software. 
> 
> The objective of this
second software is to use the usrp n200 to emit a cosinus signal that
have a span of 1MHz. 
> Somebody can help me to start with this UHD
project? Where can I find a tutorial (or examples) for writing uhd
application?
> 
> Thanks a lot in advance!
> 
> Noé 
> 
>
-
> DE : "mle...@ripnet.com" 
> À :
discuss-gnuradio@gnu.org 
> ENVOYÉ LE : Vendredi 23 mars 2012 15h55
>
OBJET : Re: [Discuss-gnuradio] Use USRP1 and USRP N200 at the same
time
> 
> 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 t> ; 
 
 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 [4]
>>> 
>>> KIT -- University of the State of
Baden-Württemberg and National Laboratory of the Helmholtz
Association
>>> 
>>> __

Re: [Discuss-gnuradio] Strange problem when using build-gnuradio script

[mleech]

  

Looks like there may be a bug in the PYTHONPATH finder inside
build-gnuradio. 

This has almost zero downstream consequences, since
it's merely offering a suggestion as to what to set your PYTHONPATH to
in your .bashrc. It doesn't automatically edit your .bashrc--that's up
to you. 

On Ubuntu 10.04, it should be:


PYTHONPATH=/usr/local/lib/python2.6/dist-packages 

On 11.10


PYTHONPATH=/usr/local/lib/python2.7/dist-packages 

Put one of those
in your .bashrc or .profile or whatever, and logout/login. 

You should
be able to start gnuradio-companion after that. 

On Tue, 27 Mar 2012
21:44:52 +0900, Wu Ting wrote: 

> Hi, Thank you for your reply. I ran
./build-gnuradio -v The result is in the attached file. Could you have a
look at it. Thank you! 
> 
> Wu 
> 
> FROM:
discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.org
[mailto:discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.org]
ON BEHALF OF Marcus D. Leech
> SENT: Tuesday, March 27, 2012 9:15 PM
>
TO: discuss-gnuradio@gnu.org
> SUBJECT: Re: [Discuss-gnuradio] Strange
problem when using build-gnuradio script 
> 
> On 03/27/2012 03:59 AM,
Wu Ting wrote: 
> 
> Hi all, 
> 
> I'm using build-gnuradio script to
build gnuradio and uhd. It works well before (both on Ubuntu 10.04 and
11.10). However, on my current computer (Ubuntu 10.04), it has a strange
problem. At first, it kept showing some libs are not found. After
installing these libs and trying for several times, it finally finished
installing. But it finished with such information: 
> 
>

> You
should probably set your PYTHONPATH to:
> 
> in your .bashrc or
equivalent file prior to attempting to run
> any Gnu Radio applications
or Gnu Radio Companion.
>
*
> Done
function pythonpath at: Tue Mar 27 16:34:46 JST 2012
> Done all
functions at: Tue Mar 27 16:34:46 JST 2012
> All Done 
> 
> There is
EMPTY line below "You should probably set your PYTHONPATH to:". 
> 
>
And I cannot run any gnuradio script. 
> 
> I also tried this: 
> 

from gnuradio import gr
> Traceback (most recent call last):
> File "",
line 1, in 
> ImportError: No module named gnuradio 
> 
> I also noticed
that there is no .py files under /usr/local/bin/. 
> 
> There are only
these files: 
> 
> uhd_cal_tx_dc_offset uhd_find_devices volk_profile
>
uhd_cal_rx_iq_balance uhd_cal_tx_iq_balance uhd_usrp_probe 
> 
> Anyone
know what is the problem? 
> 
> Thanks. 
> 
> Wu 
> 
>
___
> 
> Discuss-gnuradio
mailing list
> 
> Discuss-gnuradio@gnu.org [1]
> 
>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]
> 
> Re-run
it with --verbose to see where it went off the rails. it clearly didn't
build/install Gnu Radio, only UHD. The blank Pythonpath is because
> it
couldn't find any Gnu Radio bits in any of the places it looks for
locally-installed Python bits.
> 
> -- 
> 
> Marcus Leech
> 
> Principal
Investigator
> 
> Shirleys Bay Radio Astronomy Consortium
> 
>
http://www.sbrac.org [3]

  

Links:
--
[1]
mailto:Discuss-gnuradio@gnu.org
[2]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[3]
http://www.sbrac.org
___
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 Tue, Mar 27, 2012 at 7:26 AM, Vincenzo Pellegrini wrote:

> Hi Nick, thanks for the answer.
>
> Everything clear.
> Just a further question.
> Would a 0V-mean, 3.3V peak-to-peak sinusoid be correct as a reference
> signal for the B100?
>

Use a 5-10dBm reference with no DC component. This corresponds to 1-2V p-p.

--n


>
> regards
>
> vince
>
>
>
> Il giorno 23 marzo 2012 18:30, Nick Foster  ha scritto:
>
> 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
>>>
>>
>>
>
>
> --
> 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] B100 as clock master + B100 as clock slave

[Vincenzo Pellegrini]

Thanks Nick,
that's perfect.


Il giorno 27 marzo 2012 18:05, Nick Foster  ha scritto:

> On Tue, Mar 27, 2012 at 7:26 AM, Vincenzo Pellegrini wrote:
>
>> Hi Nick, thanks for the answer.
>>
>> Everything clear.
>> Just a further question.
>> Would a 0V-mean, 3.3V peak-to-peak sinusoid be correct as a reference
>> signal for the B100?
>>
>
> Use a 5-10dBm reference with no DC component. This corresponds to 1-2V p-p.
>
> --n
>
>
>>
>> regards
>>
>> vince
>>
>>
>>
>> Il giorno 23 marzo 2012 18:30, Nick Foster  ha scritto:
>>
>> 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

>>>
>>>
>>
>>
>> --
>> Vincenzo Pellegrini
>> http://www.youtube.com/user/wwvince1
>>
>
>


-- 
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] B100 as clock master + B100 as clock slave

[Vincenzo Pellegrini]

Yes, there is a demo video on this from 2010 which you can view at my
youtube channel  http://www.youtube.com/user/wwvince1
It's called Soft-SFN.

regards

vince



Il giorno 27 marzo 2012 16:44, Rafael Diniz  ha scritto:

> Hi Vince,
>
> Changing a little the topic, have you managed to run your SoftDVB code to
> work on multiple USRPs in order to create a SFN DVB configuration?
>
> Best regards,
> Rafael Diniz
>
> > Josh,
> > I agree this would be a great feature.
> >
> > vince
> >
> >
> >>
> >> 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
> >>
>
>
>


-- 
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] Building new blocks in Gnu Radio

[Ben Reynwar]

On Mon, Mar 26, 2012 at 10:42 AM, Francisco
 wrote:
> Ben Reynwar  reynwar.net> writes:
>
>>
>> I think that the best way to get started is to use Martins gr-modtool.
>>  It will help you to make out-of-tree blocks (out-of-tree means
>> separate but compatible with your main gnuradio installation).
>>
>> It can be found at:
>> https://github.com/mbant/gr-modtool
>>
>> On Mon, Mar 26, 2012 at 2:58 AM, Ebtisam Ahmed  
>> gmail.com>
> wrote:
>> > Indeed i have read but i cant understand the building process. I built
>> > it the i understood but it failed terribly, i have made .h .cc .i and
>> > makefile.am. Put them in one folder and then done make. i also tried
>> > ./configure and ./bootstrap but it doesnt work
>> >
>> > Anyways thanx for ur time and help me on this
>> >
>> > Regards,
>> > Ebtisam
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio  gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
> Hi all,
>
> I've decided to follow your suggestion and get gr_modtool.py.
>
> First I created the module with this script which created some folders, files
> and the .cc and .h files with skeleton code.
>
> Then I put my code in the .cc and .h files. I also changed the .xml file so I
> can use GRC (I haven't used python yet to create graphs).
>
> After this, I used cmake. I wrote:
>>cmake -i
>>sudo make
>>sudo make install
>>sudo ldconfig
>
> These were my steps to build a new block to use in GRC. However, I get this
> error:
>
> ImportError: /usr/local/lib/python2.7/dist-
> packages/mycoolstuff/_mycoolstuff_swig.so: undefined symbol:
> _Z38mycoolstuff_make_decimated_average_vccifi
>
> Yes. My module and block are called mycoolstuff and decimated_average_vcc.cc
>
> It seems that there is a problem with the swig. Do I have to configure 
> anything
> in the .i files before starting to use cmake?
>

The only thing that 'must' be edited are the gr_make_io_signature
arguments in the .cc file, although without editing the work function
you won't get much signal processing going on.
All the swig stuff should be taken care of by gr-modtool.

You can test whether it's working in python by doing:
from mycoolstuff import decimated_average_vcc
that way you can get it working without worrying about the grc stuff.

> Regards,
> Francisco
>
>
> ___
> 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] Strange problem when using build-gnuradio script

[Marcus D. Leech]

On 03/27/2012 08:44 AM, Wu Ting wrote:


Hi, Thank you for your reply. I ran ./build-gnuradio --v  The result 
is in the attached file. Could you have a look at it. Thank you!


Wu


Here's some clue, here:

- Performing Test HAVE_PTHREAD_SETSCHEDPARAM - Success
-- Performing Test HAVE_SCHED_SETSCHEDULER
-- Performing Test HAVE_SCHED_SETSCHEDULER - Failed
-- checking for module 'gsl >= 1.10'
--   found gsl , version 1.13
-- checking for module 'fftw3f >= 3.0'
--   package 'fftw3f >= 3.0' not found
-- Could NOT find FFTW3F  (missing:  FFTW3F_LIBRARIES FFTW3F_INCLUDE_DIRS)
--
-- Configuring gnuradio-core support...
--   Dependency ENABLE_GRUEL = ON
--   Dependency ENABLE_VOLK = ON
--   Dependency Boost_FOUND = TRUE
--   Dependency GSL_FOUND = 1
--   Dependency FFTW3F_FOUND = FALSE
--   Dependency PYTHONINTERP_FOUND = TRUE
--   Disabling gnuradio-core support.
--   Override with -DENABLE_GR_CORE=ON/OFF


Despite the package-config checks that build-gnuradio does passing for 
fftw3f earlier in build-gnuradio, the CMAKE check failed to find
  FFTW3F >= 3.0.  Which may mean that your system is missing 
appropriate libraries for FFTW3F.  Which is a *requirement* for gnuradio

  to build properly.

Also, you're missing:

- ##
-- # Gnuradio disabled components
-- ##
--   * python-support
--   * gnuradio-core
--   * gnuradio-companion
--   * gr-atsc
--   * gr-audio
--   * gr-comedi
--   * gr-digital
--   * gr-noaa
--   * gr-pager
--   * gr-qtgui
--   * gr-trellis
--   * gr-uhd
--   * gr-shd
--   * gr-utils
--   * gr-video-sdl
--   * gr-vocoder
--   * gr-fcd
--   * gr-wxgui


Which is pretty-much all of Gnu Radio.  Not sure how to explain this.  
The build-gnuradio script checks for various packages having been
  installed, and calls the "install depends" if any of them are 
missing.  So, according to your apt-cache check, those packages are there,
  but in reality, they aren't--like they've been removed casually from 
the system without the package database having been updated.


However, it seems that the pre-requisites installer for UBuntu 10.X is 
asking for installation of "liborc" (I added that the other day), and
  that causes the pre-requisites install to fail for everything.  I've 
removed that in the pre-requisites.  Please try again.


I've also added the "--ignore-missing" option to the apt-get.


*From:*discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.org 
[mailto:discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.org] 
*On Behalf Of *Marcus D. Leech

*Sent:* Tuesday, March 27, 2012 9:15 PM
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: [Discuss-gnuradio] Strange problem when using 
build-gnuradio script


On 03/27/2012 03:59 AM, Wu Ting wrote:

Hi all,

I'm using build-gnuradio script to build gnuradio and uhd. It works 
well before (both on Ubuntu 10.04 and 11.10). However, on my current 
computer (Ubuntu 10.04), it has a strange problem. At first, it kept 
showing some libs are not found. After installing these libs and 
trying for several times, it finally finished installing. But it 
finished with such information:



You should probably set your PYTHONPATH to:



in your .bashrc or equivalent file prior to attempting to run
any Gnu Radio applications or Gnu Radio Companion.
*
Done function pythonpath at: Tue Mar 27 16:34:46 JST 2012
Done all functions at: Tue Mar 27 16:34:46 JST 2012
All Done

There is EMPTY line below "You should probably set your PYTHONPATH to:".

And I cannot run any gnuradio script.

I also tried this:

>>> from gnuradio import gr
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named gnuradio

I also noticed that there is no .py files under /usr/local/bin/.

There are only these files:

uhd_cal_tx_dc_offset   uhd_find_devices  volk_profile
uhd_cal_rx_iq_balance   uhd_cal_tx_iq_balance  uhd_usrp_probe

Anyone know what is the problem?

Thanks.

Wu

  
  
___

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

Re-run it with --verbose to see where it went off the rails.  it 
clearly didn't build/install Gnu Radio, only UHD.  The blank 
Pythonpath is because
  it couldn't find any Gnu Radio bits in any of the places it looks 
for locally-installed Python bits.





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



--
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] [discuss-gnuradio]ofdm sync using only one preamble in gnuradio example benchmark_tx.py and benchmark_rx.py

[Alex Zhang]

Hi Tom,

Thanks for the reply.
In the ofdm_sync_pn.py, I see that a matched filter is used, after the
timing metric is obtained based on the correlation of the two halves of the
preamble. I understand this matched filter is trying to find the end of the
plateau of the metric and get the smooth peak. But I am a little confused
with the length of this matched filter.
In the code, the length of this matched filter is set as equal to
cp_length. But in T.M.Schmidl's paper(page 1615), the plateau length is
equal to the cp_length minus the channel impulse response length. I am
thinking, without counting the channel response length, can we get the peak
accurately, especially in multipath environment?


On Sun, Mar 25, 2012 at 12:40 PM, Tom Rondeau  wrote:

> On Sat, Mar 24, 2012 at 8:52 PM, Alex Zhang 
> wrote:
> > Hi Gurus,
> >
> > I just want to make sure how the current gnuradio ofdm exampel is
> > doing synchronization.
> > According to T. M. Schmidl and D. C. Cox, "Robust Frequency and
> > Timing  Synchonization for OFDM," IEEE Trans. Communications, vol.
> 45, no.
> > 12, 1997.
> > When, estimating the carrier frequency offset at the receiver, if the
> phase
> > difference between the two halves of the 1st training symbol is
> guaranteed
> > to be less than PI, then the frequency offset estimate can derived by
> > Phi/(Pi*T). In this situation, the even PN sequencies of the second
> training
> > symbol would not be needed. Otherwise, the actual frequency offset would
> be
> >
> > Phi/(Pi*T)  + 2*z/T
> >  and the z can be estimated by some optimization algorithm, using both of
> > the training symbols. Also, the paper mentioned that the odd frequencies
> of
> > the second training symbol can be used to measure the sub-channels.
> >
> > However, I find that only one training symbol is generated to act as
> > preamble at the ofdm transmitter. And on the receiver, it seems that only
> > one preamble is used to estimate the timing peak and the frequency
> offset.
> > Is the current implementation assuming that the frequency is less than
> PI?
> > Or anything I missed?
> >
> > Looking forward to your input!
> > --
> >
> > Alex,
> > Dreams can come true – just believe.
>
>
> Alex,
>
> Take a look at the presentation we put together here:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Wireless
>
> It explains the synchronization process. Basically, the single
> preamble is made up of two identical sections, so the correlation is
> done between those two sections to get the timing and fine frequency
> estimate. Since this preamble is known, we also use it to handle the
> coarse frequency (number of bins) offset.
>
> Tom
>



-- 

Alex,
*Dreams can come true – just believe.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Strange problem when using build-gnuradio script

[Wu Ting]

Hi! Now it works! Thank you so much!

 

Wu

 

From: Marcus D. Leech [mailto:mle...@ripnet.com] 
Sent: Wednesday, March 28, 2012 6:07 AM
To: Wu Ting
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Strange problem when using build-gnuradio
script

 

On 03/27/2012 08:44 AM, Wu Ting wrote: 

Hi, Thank you for your reply. I ran ./build-gnuradio -v  The result is in
the attached file. Could you have a look at it. Thank you!

 

Wu

 

 

Here's some clue, here:

- Performing Test HAVE_PTHREAD_SETSCHEDPARAM - Success
-- Performing Test HAVE_SCHED_SETSCHEDULER
-- Performing Test HAVE_SCHED_SETSCHEDULER - Failed
-- checking for module 'gsl >= 1.10'
--   found gsl , version 1.13
-- checking for module 'fftw3f >= 3.0'
--   package 'fftw3f >= 3.0' not found
-- Could NOT find FFTW3F  (missing:  FFTW3F_LIBRARIES FFTW3F_INCLUDE_DIRS)
-- 
-- Configuring gnuradio-core support...
--   Dependency ENABLE_GRUEL = ON
--   Dependency ENABLE_VOLK = ON
--   Dependency Boost_FOUND = TRUE
--   Dependency GSL_FOUND = 1
--   Dependency FFTW3F_FOUND = FALSE
--   Dependency PYTHONINTERP_FOUND = TRUE
--   Disabling gnuradio-core support.
--   Override with -DENABLE_GR_CORE=ON/OFF


Despite the package-config checks that build-gnuradio does passing for
fftw3f earlier in build-gnuradio, the CMAKE check failed to find
  FFTW3F >= 3.0.  Which may mean that your system is missing appropriate
libraries for FFTW3F.  Which is a *requirement* for gnuradio
  to build properly.

Also, you're missing:

- ##
-- # Gnuradio disabled components
-- ##
--   * python-support
--   * gnuradio-core
--   * gnuradio-companion
--   * gr-atsc
--   * gr-audio
--   * gr-comedi
--   * gr-digital
--   * gr-noaa
--   * gr-pager
--   * gr-qtgui
--   * gr-trellis
--   * gr-uhd
--   * gr-shd
--   * gr-utils
--   * gr-video-sdl
--   * gr-vocoder
--   * gr-fcd
--   * gr-wxgui


Which is pretty-much all of Gnu Radio.  Not sure how to explain this.  The
build-gnuradio script checks for various packages having been
  installed, and calls the "install depends" if any of them are missing.
So, according to your apt-cache check, those packages are there,
  but in reality, they aren't--like they've been removed casually from the
system without the package database having been updated.

However, it seems that the pre-requisites installer for UBuntu 10.X is
asking for installation of "liborc" (I added that the other day), and
  that causes the pre-requisites install to fail for everything.  I've
removed that in the pre-requisites.  Please try again.

I've also added the "--ignore-missing" option to the apt-get.





From: discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.org
[mailto:discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.or
g] On Behalf Of Marcus D. Leech
Sent: Tuesday, March 27, 2012 9:15 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Strange problem when using build-gnuradio
script

 

On 03/27/2012 03:59 AM, Wu Ting wrote: 

Hi all,

 

I'm using build-gnuradio script to build gnuradio and uhd. It works well
before (both on Ubuntu 10.04 and 11.10). However, on my current computer
(Ubuntu 10.04), it has a strange problem. At first, it kept showing some
libs are not found. After installing these libs and trying for several
times, it finally finished installing. But it finished with such
information:

 


You should probably set your PYTHONPATH to:
 

 
in your .bashrc or equivalent file prior to attempting to run
any Gnu Radio applications or Gnu Radio Companion.
*
Done function pythonpath at: Tue Mar 27 16:34:46 JST 2012
Done all functions at: Tue Mar 27 16:34:46 JST 2012
All Done

 

 

There is EMPTY line below "You should probably set your PYTHONPATH to:".

And I cannot run any gnuradio script. 

I also tried this:

 

>>> from gnuradio import gr
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named gnuradio

 

I also noticed that there is no .py files under /usr/local/bin/.

There are only these files:

uhd_cal_tx_dc_offset   uhd_find_devices  volk_profile
uhd_cal_rx_iq_balance   uhd_cal_tx_iq_balance  uhd_usrp_probe

 

Anyone know what is the problem?

 

Thanks.

 

Wu

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

Re-run it with --verbose to see where it went off the rails.  it clearly
didn't build/install Gnu Radio, only UHD.  The blank Pythonpath is because
  it couldn't find any Gnu Radio bits in any of the places it looks for
locally-installed Python bits.







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






-- 
Marcus Leech
Principal Inv

[Discuss-gnuradio] Problem in usrp side selection

[Ebtisam Ahmed]

hi all,

I have made a simple program for sine transmission which is just a
replicca of usrp_siggen. Im successful in transmitting a sine wave
with the help of side A of usrp1, but when i want to transmit it by
side B, it doesnt give any error but it doesnt transmit either...

My code is given as:

from gnuradio import gr, usrp

class my_top_block(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
self.u = usrp.sink_c()

#self.pick_subdev = usrp.pick_tx_subdevice(self.u)
self.pick_subdev = (1, 0)
### here the code works fine if i pick side A in that
case self.pick_subdev=(0,0), but when i select side B as given in the
code, it doesnt work

print self.pick_subdev
self.subdev = usrp.selected_subdev(self.u, self.pick_subdev)
print self.subdev
r = usrp.tune(self.u, 0, self.subdev, 245000)
self.subdev.set_enable(True)
self.siggen1=gr.sig_source_c(100, gr.GR_COS_WAVE, 1, 16000)
self.connect(self.siggen1, self.u)
print "Using RX d'board %s" % (self.subdev.side_and_name(),)
self.run()

def main():
tb = my_top_block()
tb.run()


if __name__ == '__main__':
main()


kindly help me on this

Regards,
Ebtisam

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