Re: [Discuss-gnuradio] GNURADIO.org down???

[M Dammer]

gnuradio.org still down here (Oct. 4th, 8:39 UTC). I can see that a
whois update has happened last night, so maybe DNS has to sync.
Mark



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

Re: [Discuss-gnuradio] GNURADIO.org down???

[Ralph A. Schmid, dk5ras]

Here in Germany it is available again; two hours ago it still was
unreachable.

Ralph


> -Original Message-
> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
> M Dammer
> Sent: Friday, October 04, 2013 10:42 AM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] GNURADIO.org down???
> 
> gnuradio.org still down here (Oct. 4th, 8:39 UTC). I can see that a whois
> update has happened last night, so maybe DNS has to sync.
> Mark
> 
> 
> 
> ___
> 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] Changing Bandwidth USRP

[Antmrt]

How can we increase the bandwidth of the FFT plot. The bandwidth is only
0.1MHz, how can I increase that to at least 10MHz. Thanks.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Changing-Bandwidth-USRP-tp43949.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] GNURADIO.org down???

[M Dammer]

yepp, up here (Scotland) as well - 9:54 UTC.
Mark

On 04/10/13 10:35, Ralph A. Schmid, dk5ras wrote:
> Here in Germany it is available again; two hours ago it still was
> unreachable.
>
> Ralph
>
>
>> -Original Message-
>> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
>> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
>> M Dammer
>> Sent: Friday, October 04, 2013 10:42 AM
>> To: discuss-gnuradio@gnu.org
>> Subject: Re: [Discuss-gnuradio] GNURADIO.org down???
>>
>> gnuradio.org still down here (Oct. 4th, 8:39 UTC). I can see that a whois
>> update has happened last night, so maybe DNS has to sync.
>> Mark
>>
>>
>>
>> ___
>> 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] Changing Bandwidth USRP

[Marcus Mueller]

Hi Antmrt,

The FFT plots (there are several available in GR) don't have a bandwidth
of their own, they just display the FFT magnitude of the input sample.
Frequencies are only for display and are usually calculated by the
sampling rate parameter you set. That has no effect on the plot itself,
but only on the axes' labels. 
If you want more bandwidth in your plot, you have got to have a higher
sampling rate. If this relationship is new to you, I may recommend the
recommended reading page on the GNU radio wiki, which, ironically, is
not reachable for everyone right now, but that should be sorted out in a
few hours (I hope).
So: The Bandwidth you see is the bandwidth you put in; there's no way
around that. If you're having something that smaples a complex signal at
100kHz sampling rate, you cannot expect your FFT to show higher
frequencies than that. 

Greetings,
Marcus

> How can we increase the bandwidth of the FFT plot. The bandwidth is only
> 0.1MHz, how can I increase that to at least 10MHz. Thanks.
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Changing-Bandwidth-USRP-tp43949.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



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

Re: [Discuss-gnuradio] Changing Bandwidth USRP

[Antmrt]

Thanks Marcus, my problem is how to calibrate the scale on the FFT plot. e.g:
I'm feeding a signal of -30 dBm to the usrp and on the plot the value
becomes about -10 dBm



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Changing-Bandwidth-USRP-tp43949p43952.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] Changing Bandwidth USRP

[Marcus Müller]

This is a completely different problem, is it? Bandwidth is orthogonal to the 
concept of dynamic range and amplitude values.

Anyway, your FFT plot knows about complex samples; therefore, it displays dB relative to 
the numeric value of "1.0"; this has nothing to do with your input signal 
power. But since USRP/daughterboards tend to work linearly over most of their available 
power range, you can just add a multiply_const to your signal processing flowgraph and 
get your value.
The factor, however, depends on your ADC/daughterboard combination, on the gain you set 
for the RF frontend, a little bit on temperature, the tuner, the impedance matching of 
your RF input to the Daughterboard etc.  So if you already know what you're putting in, 
just use this as a reference and "calibrate" yourself.

Hope that helped clear things up,

Marcus

On 10/04/2013 01:05 PM, Antmrt wrote:

Thanks Marcus, my problem is how to calibrate the scale on the FFT plot. e.g:
I'm feeding a signal of -30 dBm to the usrp and on the plot the value
becomes about -10 dBm



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Changing-Bandwidth-USRP-tp43949p43952.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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



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

[Discuss-gnuradio] DNS issues

[Johnathan Corgan]

Just a quick update to say that the DNS issues have been identified and
fixed, and we are just waiting for everything to propagate.  I'll send
another update with more detail after we get things started today at the
conference.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to integrate a specific number of vectors element-wise in gnuradio?

[Eskil Varenius]

Hi everyone,
After a long break since June I am now back learning about Gnuradio. I
asked in June for a way to average vectors elementwise and Martin Braun
suggested the moving_average_Vff block in the gr-specest. He also said it
would be available PyBOMBS. Now update:

Since I had installed Gnuradio using the build-script I wanted to
re-install it using pybombs. I uninstalled the old gnuradio by doing a
"sudo make uninstall" in each build directory for the old release. Seems to
work. Now I installed gnuradio 3.6 (since gr-specest is still only verified
for 3.6, although I'm happy to see people working towards a 3.7 release). I
did the install using the instructions on the pybombs quickstart page:

git clone git://github.com/pybombs/pybombs
cd pybombs
git checkout gr-3.6
./pybombs install gnuradio

Gnuradio seemed to install without problems but: I realised I had
path-problems since I could not start anything (gnuradio companion, import
gnuradio etc. fails). Perhaps this was related to me using a custom target
directory (/opt/gnuradio_pybombs). I looked around and found path
instructions for custom directory installs at "
http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Installing-in-a-custom-directory";,
i.e. put the following in my .bashrc:

# GNU Radio installation
export PATH=$PATH:/opt/gnuradio_pybombs/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/gnuradio_pybombs/lib
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/gnuradio_pybombs/lib/pkgconfig
export
PYTHONPATH=$PYTHONPATH:/opt/gnuradio_pybombs/lib/python2.6/site-packages

However, that didn't work completely - I still could not find the gnuradio
python module. I realised two things: the 2.6 should probably be 2.7 for
me, and also the pythonpath should end in dist-packages, not site-packages,
since the site-packages folder was empty. After modifying the pythonpath
with 2.7 and dist-packages everything runs, I can import gnuradio and also
use gnuradio companion. So far so good!

Now for gr-specest. I tried to install it using app store (cool stuff, you
guys are amazing!) and also just command line which is equivalent, i.e. I
run using "sudo ./pybombs install gr-specest" I get a lot of output, but
the perhaps most interesting one before it ends abruptly is:
-- checking for module 'gruel'
--   package 'gruel' not found
-- Could NOT find GRUEL (missing:  GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS)
-- checking for module 'gnuradio-core'
--   package 'gnuradio-core' not found
-- Could NOT find GNURADIO_CORE (missing:  GNURADIO_CORE_LIBRARIES
GNURADIO_CORE_INCLUDE_DIRS)
CMake Error at CMakeLists.txt:100 (message):
  Gruel required to compile specest

I am lost here. Any ideas? I can give the rest of the output as well, but
this is the showstopper as far as I can see. I have tried googling this,
but it seems to me that the solution used is to use the build-gnuradio
script instead of PyBOMBS. I could do that, but then I would not be able to
enjoy installing gr-specest through the app-store ;). Grateful for any
advice.

Cheers,
Eskil


2013/6/24 Martin Braun (CEL) 

> On Mon, Jun 24, 2013 at 02:09:51PM +0200, Eskil Varenius wrote:
> > The grand plan is as follows:
> > 1) Use an USRP to recieve a signal, I know how.
> > 2) Divide the stream of samples into vectors, I know how.
> > 3) Take the FFT of the vectors one by one, I know how.
> > 4) Average the vectors coming from the FFT together element-wise. I
> don't know
> > how.
> > 5) Save the averaged vector to a file, I know how.
> >
> > What I cannot solve is step 4: I need to take the N vectors (each of
> size M)
> > coming from the FFT-block and sum them together element-wise to produce
> one
> > vector of size M.
>
> The spectral estimation toolbox (gr-specest) has a block to do this
> (moving_average_vff). You can get it through PyBOMBS, it is not yet
> 3.7-compatible, though.
>
> https://github.com/kit-cel/gr-specest
>
> 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] How to integrate a specific number of vectors element-wise in gnuradio?

[Jared Clements]

I updated gr-specest so it would compile with 3.7, see my repo on
www.github.com/dfxx if you want to try that route.  The changes were almost
all namespace stuff and cmake stuff, i.e. I don't think I broke anything.

Jared
On Oct 4, 2013 7:33 AM, "Eskil Varenius"  wrote:

> Hi everyone,
> After a long break since June I am now back learning about Gnuradio. I
> asked in June for a way to average vectors elementwise and Martin Braun
> suggested the moving_average_Vff block in the gr-specest. He also said it
> would be available PyBOMBS. Now update:
>
> Since I had installed Gnuradio using the build-script I wanted to
> re-install it using pybombs. I uninstalled the old gnuradio by doing a
> "sudo make uninstall" in each build directory for the old release. Seems to
> work. Now I installed gnuradio 3.6 (since gr-specest is still only verified
> for 3.6, although I'm happy to see people working towards a 3.7 release). I
> did the install using the instructions on the pybombs quickstart page:
>
> git clone git://github.com/pybombs/pybombs
> cd pybombs
> git checkout gr-3.6
> ./pybombs install gnuradio
>
> Gnuradio seemed to install without problems but: I realised I had
> path-problems since I could not start anything (gnuradio companion, import
> gnuradio etc. fails). Perhaps this was related to me using a custom target
> directory (/opt/gnuradio_pybombs). I looked around and found path
> instructions for custom directory installs at "
> http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Installing-in-a-custom-directory";,
> i.e. put the following in my .bashrc:
>
> # GNU Radio installation
> export PATH=$PATH:/opt/gnuradio_pybombs/bin
> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/gnuradio_pybombs/lib
> export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/gnuradio_pybombs/lib/pkgconfig
> export
> PYTHONPATH=$PYTHONPATH:/opt/gnuradio_pybombs/lib/python2.6/site-packages
>
> However, that didn't work completely - I still could not find the gnuradio
> python module. I realised two things: the 2.6 should probably be 2.7 for
> me, and also the pythonpath should end in dist-packages, not site-packages,
> since the site-packages folder was empty. After modifying the pythonpath
> with 2.7 and dist-packages everything runs, I can import gnuradio and also
> use gnuradio companion. So far so good!
>
> Now for gr-specest. I tried to install it using app store (cool stuff, you
> guys are amazing!) and also just command line which is equivalent, i.e. I
> run using "sudo ./pybombs install gr-specest" I get a lot of output, but
> the perhaps most interesting one before it ends abruptly is:
> -- checking for module 'gruel'
> --   package 'gruel' not found
> -- Could NOT find GRUEL (missing:  GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS)
> -- checking for module 'gnuradio-core'
> --   package 'gnuradio-core' not found
> -- Could NOT find GNURADIO_CORE (missing:  GNURADIO_CORE_LIBRARIES
> GNURADIO_CORE_INCLUDE_DIRS)
> CMake Error at CMakeLists.txt:100 (message):
>   Gruel required to compile specest
>
> I am lost here. Any ideas? I can give the rest of the output as well, but
> this is the showstopper as far as I can see. I have tried googling this,
> but it seems to me that the solution used is to use the build-gnuradio
> script instead of PyBOMBS. I could do that, but then I would not be able to
> enjoy installing gr-specest through the app-store ;). Grateful for any
> advice.
>
> Cheers,
> Eskil
>
>
> 2013/6/24 Martin Braun (CEL) 
>
>> On Mon, Jun 24, 2013 at 02:09:51PM +0200, Eskil Varenius wrote:
>> > The grand plan is as follows:
>> > 1) Use an USRP to recieve a signal, I know how.
>> > 2) Divide the stream of samples into vectors, I know how.
>> > 3) Take the FFT of the vectors one by one, I know how.
>> > 4) Average the vectors coming from the FFT together element-wise. I
>> don't know
>> > how.
>> > 5) Save the averaged vector to a file, I know how.
>> >
>> > What I cannot solve is step 4: I need to take the N vectors (each of
>> size M)
>> > coming from the FFT-block and sum them together element-wise to produce
>> one
>> > vector of size M.
>>
>> The spectral estimation toolbox (gr-specest) has a block to do this
>> (moving_average_vff). You can get it through PyBOMBS, it is not yet
>> 3.7-compatible, though.
>>
>> https://github.com/kit-cel/gr-specest
>>
>> 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-gnurad

[Discuss-gnuradio] Cross Compiling ORC-0.4.18

[Brandon Ess]

All,

I'm trying to cross compile ORC so I may use it during compilation of the
UHD driver and GNURADIO.

When cross compiling on Ubuntu 12.04 x86-64 for ARM I get the following
errors:

*./configure --host=arm-linux-gnueabihf  --build=arm-linux-gnueabihf
cxxflags="-mcpu=cortex-a8 -mfpu=neon -funsafe-math-optimizations
-mfloat-abi=hard " cflags="-mcpu=cortex-a8 -mfpu=neon
-funsafe-math-optimizations -mfloat-abi=hard "
 --prefix=/opt/orc-arm-cross/orc-0.4.18/test-build*


*libtool: link: gcc -Wall -I.. -g -O2 -o .libs/generate-bytecode
generate_bytecode-generate-bytecode.o  ../orc/.libs/liborc-0.4.so -lm -lrt
-Wl,-rpath -Wl,/opt/orc-arm-cross/orc-0.4.18/test-build/lib*
*../orc/.libs/liborc-0.4.so: undefined reference to `orc_arm_get_cpu_flags'*
*collect2: ld returned 1 exit status*
*make[2]: *** [generate-emulation] Error 1*
*make[2]: *** Waiting for unfinished jobs*
*../orc/.libs/liborc-0.4.so: undefined reference to `orc_arm_get_cpu_flags'*


orc_arm_get_cpu_flags is defined in orcarm.h and all the headers are or
$ORC_ROOT/orc but when it needs this one header is cannot find it. I've
made sure #include orcarm.h is in orcarm.c but it cannot find it during
compilation.

So I then manually define it with: -Iorc/orcarm.h during the ./configure
process and it still doesn't find it.

ORC 0.4.18 compiles just fine natively on both x86-64 and ARM so my current
workaround is to just compile natively on the ARM platform and copy over
the necessary ARM files to the x86 cross compile environment so UHD and
GNURADIO can use them.

Any ideas why ORC won't cross compile?

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

[Discuss-gnuradio] Bug? grc xml file throws error when elements out of order

[Jared Clements]

I'm getting the following error when opening gnuradio-companion on my
hand-coded blocks:

ERROR:VALID:DTD_NOT_PCDATA: Element block was declared #PCDATA but
contains non text nodes

I'm seeing it when I do the following in the xml file:

  
vlen
vlen
int
128
  

When I correct the block to look like this:

  
vlen
vlen
128
int
  

The error goes away.  Is this expected behavior?  The only difference
is how I order the tags inside the param blocks.

Jared

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

[Discuss-gnuradio] Linking Error // Missing Library // openLTE Cmake

[Dincer Beken]

Hi all,

while adding the a resampler to the openLTE project, i got a linking error.

I added in the header file :
LTE_fdd_dl_scan_flowgraph the library rational resampler:

Into the header file:
gr::filter::rational_resampler_base_ccf::sptr resapler_filter;

Into the source code:
Top_block-->connect(samp_src,0,resampler_filer(1536,1000,std::vector(1,1)),0);

And got no compile error.

I included:

#include 

Into the header file.


As output I am getting:


Linking CXX executable LTE_fdd_dl_scan 
CMakeFiles/LTE_fdd_dl_scan.dir/src/LTE_fdd_dl_scan_flowgraph.cc.o:
 In function `LTE_fdd_dl_scan_flowgraph::start(unsigned short)': 
LTE_fdd_dl_scan_flowgraph.cc:(.text+0x94b): undefined reference to 
`gr::filter::rational_resampler_base_ccf::make(unsigned int, unsigned int, 
std::vector > const&)' collect2: ld returned 1 
exit status make[2]: *** [LTE_fdd_dl_scan/LTE_fdd_dl_scan] Error 1 make[1]: *** 
[LTE_fdd_dl_scan/CMakeFiles/LTE_fdd_dl_scan.dir/all]
 Error 2 make: *** [all] Error 2


I think the problem lies in that I need to add the filters libraries, somehow 
into the projects CMAKEList.txt files.

Could you please help me, in which CMAKEList.txt files (for the the overall 
project or for the app spefic (LTE_fdd_dl_scan) file), I need to make some 
manipulations?

I am going to look more detailed in cmake myself, but if you give hints, as 
always, I will highly appreciate.

Regards,
Dincer


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

Re: [Discuss-gnuradio] Bug? grc xml file throws error when elements out of order

[Martin Braun (CEL)]

Hi Jared,

this is how the XML validation works, yes. It's probably just an
artifact of whatever XML parser we're using, but we've all gotten used
to it.

MB


On Fri, Oct 04, 2013 at 12:46:54PM -0600, Jared Clements wrote:
> I'm getting the following error when opening gnuradio-companion on my
> hand-coded blocks:
> 
> ERROR:VALID:DTD_NOT_PCDATA: Element block was declared #PCDATA but
> contains non text nodes
> 
> I'm seeing it when I do the following in the xml file:
> 
>   
> vlen
> vlen
> int
> 128
>   
> 
> When I correct the block to look like this:
> 
>   
> vlen
> vlen
> 128
> int
>   
> 
> The error goes away.  Is this expected behavior?  The only difference
> is how I order the tags inside the param blocks.
> 
> Jared
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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


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

Re: [Discuss-gnuradio] Linking Error // Missing Library // openLTE Cmake

[Jared Clements]

Just ran into this one a while back, see the discussion I initiated on
Sept 17th with the subject line: Updating gr-specest to 3.7

Most of the CMakeList.txt files needed updating... in one way or another.

Jared

On Fri, Oct 4, 2013 at 1:20 PM, Dincer Beken  wrote:
> Hi all,
>
>
>
> while adding the a resampler to the openLTE project, i got a linking error.
>
>
>
> I added in the header file :
>
> LTE_fdd_dl_scan_flowgraph the library rational resampler:
>
>
>
> Into the header file:
>
> gr::filter::rational_resampler_base_ccf::sptr resapler_filter;
>
>
>
> Into the source code:
>
> Top_blockàconnect(samp_src,0,resampler_filer(1536,1000,std::vector(1,1)),0);
>
>
>
> And got no compile error.
>
>
>
> I included:
>
>
>
> #include 
>
>
>
> Into the header file.
>
>
>
>
>
> As output I am getting:
>
>
>
>
>
> Linking CXX executable LTE_fdd_dl_scan
> CMakeFiles/LTE_fdd_dl_scan.dir/src/LTE_fdd_dl_scan_flowgraph.cc.o: In
> function `LTE_fdd_dl_scan_flowgraph::start(unsigned short)':
> LTE_fdd_dl_scan_flowgraph.cc:(.text+0x94b): undefined reference to
> `gr::filter::rational_resampler_base_ccf::make(unsigned int, unsigned int,
> std::vector > const&)' collect2: ld returned 1
> exit status make[2]: *** [LTE_fdd_dl_scan/LTE_fdd_dl_scan] Error 1 make[1]:
> *** [LTE_fdd_dl_scan/CMakeFiles/LTE_fdd_dl_scan.dir/all] Error 2 make: ***
> [all] Error 2
>
>
>
>
>
> I think the problem lies in that I need to add the filters libraries,
> somehow into the projects CMAKEList.txt files.
>
>
>
> Could you please help me, in which CMAKEList.txt files (for the the overall
> project or for the app spefic (LTE_fdd_dl_scan) file), I need to make some
> manipulations?
>
>
>
> I am going to look more detailed in cmake myself, but if you give hints, as
> always, I will highly appreciate.
>
>
>
> Regards,
>
> Dincer
>
>
>
>
>
>
> ___
> 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] How to work with a limited sample

[Gui Ritter]

Hi everyone.
I just started using GRC for a college assignment, but I'm having a hard time 
to find what I need to know in order to do what I want.
I want to make a flowgraph that works with a limited sample, like a WAV file. 
So I'd like to know how to stop the flowgraph after the processing is done, or 
something similar.
Thanks in advance.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] swig madness

[Miklos Maroti]

Hi Guys,

I am trying to create a rational_sync_block class in an out of tree
module, which is both an interpolator and decimator with a rational
data rate. So I just wrote the class, almost exactly like how
sync_interpolator is written. Then when I want to use this new base
class in a derived real block named xxx_block in my out of tree
module, then everything compiles, but the swig generation fails with
an error message that xxx_block cannot be allocated because it is
abstract type has an virtual work function. When I change the base
type back to sync_interpolator, then swig is happy. I do not
understand what is so special about gr::sync_interpolator, and why I
cannot reproduce the sync_interpolator in a way that makes swig happy.
Any ideas?

Miklos

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

[Discuss-gnuradio] Lock/Unlock segfaulting

[Achilleas Anastasopoulos]

I have a pyhton program (see
http://web.eecs.umich.edu/~anastas/docs/onoff_flat_test.py)
that based on a button chooser (on/off) rearranges itself.
I use lock/unlock to do the disconnection/reconnection.
However, I always get segfaults after a couple of changes.

The graph is pretty simple:

A complex sinusodial source + noise (throttled) goes to either:

ON) multiplication by 2 and complex to mag squared
or
OFF) multiplication by 0 and complex to mag squared

and then to a null sink.

I would really appreciate some input because I am kind of lost as to what
is going wrong.

thanks in advance,
Achilleas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to work with a limited sample

[Marcus Müller]

Hi Gui,

that's how most sample sources work anyway. 
So just find the source that suits your needs best (in your case: Wav
file source), connect it to your signal processing blocks and run the
flowgraph. It will stop when the source signals that it's done, which
will happen when the file end is reached.

Happy Hacking!
Marcus

On Fri, 2013-10-04 at 17:37 -0300, Gui Ritter wrote:
> Hi everyone.
> 
> 
> I just started using GRC for a college assignment, but I'm having a
> hard time to find what I need to know in order to do what I want.
> 
> 
> I want to make a flowgraph that works with a limited sample, like a
> WAV file. So I'd like to know how to stop the flowgraph after the
> processing is done, or something similar.
> 
> 
> Thanks in advance.
> ___
> 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] Lock/Unlock segfaulting

[Marcus Müller]

Hi Achilleas,

after skimming through your code, I found no obvious mistakes so far.
My guess was that under some circumstances, you connect or disconnect a
connection twice or something similarly wicked happens, but I can't see
why that should happen.
Can you supply us with a backtrace, generated by GDB?
(gdb --args python onoff_flat_test.py; then type "run" as soon
as gdb is ready, then type "backtrace" after the program
segfaulted)

Greetings
Marcus
On Fri, 2013-10-04 at 17:46 -0400, Achilleas Anastasopoulos wrote:
> 
> 
> I have a pyhton program (see
> http://web.eecs.umich.edu/~anastas/docs/onoff_flat_test.py) 
> that based on a button chooser (on/off) rearranges itself.
> I use lock/unlock to do the disconnection/reconnection.
> However, I always get segfaults after a couple of changes.
> 
> 
> The graph is pretty simple:
> 
> 
> A complex sinusodial source + noise (throttled) goes to either:
> 
> 
> ON) multiplication by 2 and complex to mag squared
> 
> or
> 
> OFF) multiplication by 0 and complex to mag squared 
> 
> 
> and then to a null sink.
> 
> 
> 
> I would really appreciate some input because I am kind of lost as to
> what 
> 
> is going wrong.
> 
> thanks in advance,
> Achilleas
> 
> 
> ___
> 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] swig madness

[Michael Berman]

Miklos,

Have you imported all of the gnuradio files into the swig .i file that you
are using within your OOT module?  I recently went through this, and I had
to include a gnuradio header into my swig .i file as shown below; I'm not
entirely sure what the two include declarations are for, but I needed both
to work.

%{
#include "gnuradio/digital/constellation.h"
#include ""
%}
%include "gnuradio/digital/constellation.h"
%include ""

Also, make sure you include the appropriate .so file of any gnuradio object
you are using into the CMakeList.txt file, otherwise you may get a runtime
error as it cannot find the object you are referencing within gnuradio.

Michael Berman




On Fri, Oct 4, 2013 at 2:36 PM, Miklos Maroti wrote:

> Hi Guys,
>
> I am trying to create a rational_sync_block class in an out of tree
> module, which is both an interpolator and decimator with a rational
> data rate. So I just wrote the class, almost exactly like how
> sync_interpolator is written. Then when I want to use this new base
> class in a derived real block named xxx_block in my out of tree
> module, then everything compiles, but the swig generation fails with
> an error message that xxx_block cannot be allocated because it is
> abstract type has an virtual work function. When I change the base
> type back to sync_interpolator, then swig is happy. I do not
> understand what is so special about gr::sync_interpolator, and why I
> cannot reproduce the sync_interpolator in a way that makes swig happy.
> Any ideas?
>
> Miklos
>
> ___
> 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] Lock/Unlock segfaulting

[Achilleas Anastasopoulos]

Marcus,

thanks for the quick reply.

Here is the backtrace:

Sleep...
Unlocking...
[Thread 0x7fffbe7fc700 (LWP 29591) exited]
[Thread 0x7fffbf7fe700 (LWP 29593) exited]
[Thread 0x7fffdbfff700 (LWP 29595) exited]
[Thread 0x7fffe0aa7700 (LWP 29594) exited]
[Thread 0x7fffbeffd700 (LWP 29592) exited]
[Thread 0x7fffdb7fe700 (LWP 29596) exited]
[Thread 0x7fffbdffb700 (LWP 29590) exited]
[New Thread 0x7fffd8ff9700 (LWP 29603)]
[New Thread 0x7fffd97fa700 (LWP 29604)]
[New Thread 0x7fffd9ffb700 (LWP 29605)]
[New Thread 0x7fffda7fc700 (LWP 29606)]
[New Thread 0x7fffe0aa7700 (LWP 29607)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe0aa7700 (LWP 29607)]
0x700b80a0 in volk_32fc_s32fc_multiply_32fc_a_sse3 ()
   from /usr/local/lib64/libvolk.so.0.0.0

==

(gdb) backtrace
#0  0x700b80a0 in volk_32fc_s32fc_multiply_32fc_a_sse3 ()
   from /usr/local/lib64/libvolk.so.0.0.0
#1  0x7083910a in gr::blocks::multiply_const_cc_impl::work(int,
std::vector >&, std::vector >&) ()
   from /usr/local/lib64/libgnuradio-blocks-3.7.2git.so.0.0.0
#2  0x70401fc7 in gr::sync_block::general_work(int,
std::vector >&, std::vector >&, std::vector
>&) () from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#3  0x703caca8 in gr::block_executor::run_one_iteration() ()
   from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#4  0x70410ee6 in
gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int) ()
from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#5  0x703ff38e in gr::tpb_container::operator()() ()
   from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#6  0x703ff58e in
gr::thread::thread_body_wrapper::operator()()
() from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#7  0x703b320f in boost::detail::thread_data
>::run() ()
   from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#8  0x003349a11629 in thread_proxy () from
/lib64/libboost_thread-mt.so.1.50.0
#9  0x003340a07d15 in start_thread () from /lib64/libpthread.so.0
#10 0x00333fef253d in clone () from /lib64/libc.so.6






On Fri, Oct 4, 2013 at 6:00 PM, Marcus Müller  wrote:

> Hi Achilleas,
>
> after skimming through your code, I found no obvious mistakes so far.
> My guess was that under some circumstances, you connect or disconnect a
> connection twice or something similarly wicked happens, but I can't see
> why that should happen.
> Can you supply us with a backtrace, generated by GDB?
> (gdb --args python onoff_flat_test.py; then type "run" as soon
> as gdb is ready, then type "backtrace" after the program
> segfaulted)
>
> Greetings
> Marcus
> On Fri, 2013-10-04 at 17:46 -0400, Achilleas Anastasopoulos wrote:
> >
> >
> > I have a pyhton program (see
> > http://web.eecs.umich.edu/~anastas/docs/onoff_flat_test.py)
> > that based on a button chooser (on/off) rearranges itself.
> > I use lock/unlock to do the disconnection/reconnection.
> > However, I always get segfaults after a couple of changes.
> >
> >
> > The graph is pretty simple:
> >
> >
> > A complex sinusodial source + noise (throttled) goes to either:
> >
> >
> > ON) multiplication by 2 and complex to mag squared
> >
> > or
> >
> > OFF) multiplication by 0 and complex to mag squared
> >
> >
> > and then to a null sink.
> >
> >
> >
> > I would really appreciate some input because I am kind of lost as to
> > what
> >
> > is going wrong.
> >
> > thanks in advance,
> > Achilleas
> >
> >
> > ___
> > 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] swig madness

[Miklos Maroti]

Hi Michael,

Unfortunately, the problem is not always reproducible with a simple
"cmake ../ && make clean && make", I have to remove the build
directory completely. I have tried all combinations, and now I seem to
have something that seem to work. The problem is that I need a

rational_sync_block(void) {} // allows pure virtual interface sub-classes

constructor in order to declare interface classes in my include
directory. These interface classes are inheriting from
rational_sync_block with virtual inheritance. So when SWIG is scanning
the header files, then it decides that it is going to create a wrapper
around the empty constructor (and I do not know why it does this). But
you cannot instantiate this interface class, you have to use make
which will create the proper implementation. Anyhow, the solution was
to conditionally create a different class definition for swig like
below. If I do not do this special case, then the error is there.
Also, it is not clear what and how to set up my swig .i file, but some
combination seems to work now.

#ifdef SWIG_VERSION

class rational_sync_block : public gr::sync_block
{
protected:
  rational_sync_block(const std::string &name,
gr::io_signature::sptr input_signature, gr::io_signature::sptr
output_signature,
unsigned int interpolation, unsigned int decimation);
};

#else

class rational_sync_block: public gr::sync_block
{
private:
  unsigned int d_interpolation;
  unsigned int d_decimation;

protected:
  rational_sync_block(void) {} // allows pure virtual interface sub-classes
  rational_sync_block(const std::string &name,
gr::io_signature::sptr input_signature, gr::io_signature::sptr
output_signature,
unsigned int interpolation, unsigned int decimation);

public:
  unsigned int interpolation() const { return d_interpolation; }
  unsigned int decimation() const { return d_interpolation; }

  void set_interpolation(unsigned int interpolation, unsigned int decimation);

  int fixed_rate_ninput_to_noutput(int ninput);
  int fixed_rate_noutput_to_ninput(int noutput);

  void forecast(int noutput_items, gr_vector_int &ninput_items_required);

  // derived classes should override work
  int general_work(int noutput_items, gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items, gr_vector_void_star
&output_items);
};

#endif

Miklos

On Sat, Oct 5, 2013 at 12:11 AM, Michael Berman  wrote:
> Miklos,
>
> Have you imported all of the gnuradio files into the swig .i file that you
> are using within your OOT module?  I recently went through this, and I had
> to include a gnuradio header into my swig .i file as shown below; I'm not
> entirely sure what the two include declarations are for, but I needed both
> to work.
>
> %{
> #include "gnuradio/digital/constellation.h"
> #include ""
> %}
> %include "gnuradio/digital/constellation.h"
> %include ""
>
> Also, make sure you include the appropriate .so file of any gnuradio object
> you are using into the CMakeList.txt file, otherwise you may get a runtime
> error as it cannot find the object you are referencing within gnuradio.
>
> Michael Berman
>
>
>
>
> On Fri, Oct 4, 2013 at 2:36 PM, Miklos Maroti 
> wrote:
>>
>> Hi Guys,
>>
>> I am trying to create a rational_sync_block class in an out of tree
>> module, which is both an interpolator and decimator with a rational
>> data rate. So I just wrote the class, almost exactly like how
>> sync_interpolator is written. Then when I want to use this new base
>> class in a derived real block named xxx_block in my out of tree
>> module, then everything compiles, but the swig generation fails with
>> an error message that xxx_block cannot be allocated because it is
>> abstract type has an virtual work function. When I change the base
>> type back to sync_interpolator, then swig is happy. I do not
>> understand what is so special about gr::sync_interpolator, and why I
>> cannot reproduce the sync_interpolator in a way that makes swig happy.
>> Any ideas?
>>
>> Miklos
>>
>> ___
>> 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] Lock/Unlock segfaulting

[Achilleas Anastasopoulos]

I have uploaded a bare minimum example that still has this problem:

sinusoid--> throtle --> (ON or OFF block) --> null sink

http://web.eecs.umich.edu/~anastas/docs/onoff_flat_test1.py

And here is all the output of gdb (it segfaults in unlock() ):


(gdb) backtrace
#0  0x700b80a0 in volk_32fc_s32fc_multiply_32fc_a_sse3 ()
   from /usr/local/lib64/libvolk.so.0.0.0
#1  0x7083910a in gr::blocks::multiply_const_cc_impl::work(int,
std::vector >&, std::vector >&) ()
   from /usr/local/lib64/libgnuradio-blocks-3.7.2git.so.0.0.0
#2  0x70401fc7 in gr::sync_block::general_work(int,
std::vector >&, std::vector >&, std::vector
>&) () from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#3  0x703caca8 in gr::block_executor::run_one_iteration() ()
   from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#4  0x70410ee6 in
gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int) ()
from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#5  0x703ff38e in gr::tpb_container::operator()() ()
   from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#6  0x703ff58e in
gr::thread::thread_body_wrapper::operator()()
() from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#7  0x703b320f in boost::detail::thread_data
>::run() ()
   from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0
#8  0x003349a11629 in thread_proxy () from
/lib64/libboost_thread-mt.so.1.50.0
#9  0x003340a07d15 in start_thread () from /lib64/libpthread.so.0
#10 0x00333fef253d in clone () from /lib64/libc.so.6








On Fri, Oct 4, 2013 at 6:00 PM, Marcus Müller  wrote:

> Hi Achilleas,
>
> after skimming through your code, I found no obvious mistakes so far.
> My guess was that under some circumstances, you connect or disconnect a
> connection twice or something similarly wicked happens, but I can't see
> why that should happen.
> Can you supply us with a backtrace, generated by GDB?
> (gdb --args python onoff_flat_test.py; then type "run" as soon
> as gdb is ready, then type "backtrace" after the program
> segfaulted)
>
> Greetings
> Marcus
> On Fri, 2013-10-04 at 17:46 -0400, Achilleas Anastasopoulos wrote:
> >
> >
> > I have a pyhton program (see
> > http://web.eecs.umich.edu/~anastas/docs/onoff_flat_test.py)
> > that based on a button chooser (on/off) rearranges itself.
> > I use lock/unlock to do the disconnection/reconnection.
> > However, I always get segfaults after a couple of changes.
> >
> >
> > The graph is pretty simple:
> >
> >
> > A complex sinusodial source + noise (throttled) goes to either:
> >
> >
> > ON) multiplication by 2 and complex to mag squared
> >
> > or
> >
> > OFF) multiplication by 0 and complex to mag squared
> >
> >
> > and then to a null sink.
> >
> >
> >
> > I would really appreciate some input because I am kind of lost as to
> > what
> >
> > is going wrong.
> >
> > thanks in advance,
> > Achilleas
> >
> >
> > ___
> > 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] How to work with a limited sample

[West, Nathan]

On Friday, October 4, 2013, Marcus Müller wrote:

> Hi Gui,
>
> that's how most sample sources work anyway.
> So just find the source that suits your needs best (in your case: Wav
> file source), connect it to your signal processing blocks and run the
> flowgraph. It will stop when the source signals that it's done, which
> will happen when the file end is reached.
>
> Happy Hacking!
> Marcus
>
> On Fri, 2013-10-04 at 17:37 -0300, Gui Ritter wrote:
> > Hi everyone.
> >
> >
> > I just started using GRC for a college assignment, but I'm having a
> > hard time to find what I need to know in order to do what I want.
> >
> >
> > I want to make a flowgraph that works with a limited sample, like a
> > WAV file. So I'd like to know how to stop the flowgraph after the
> > processing is done, or something similar.
> >
> >
> > Thanks in advance.
> > ___
> > 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
>

That's correct that file playback type sinks will end the flowgraph after
reading every item. As a more general alternative if you have a live source
and just want to use X samples you can use the head block.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] ofdm_rx

[lingeswar kandregula]

hi,
in the rx_ofdm.grc in examples contains the STREAMCRC32 block. in which the
mode must be check CRC. but the default in the example is generate crc. it
is only working for generate crc and for checkCRC it doesnot give output.

i tried using the data before the streamCRC32 and tried to use with
streamcrc32 block in another flowgraph. but it gave me an error missing
length tag. how to resolve this.

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