[Discuss-gnuradio] USRP1 warning "requested RX frequency is outside of the system range, requested RX frequency is outside of the system range, and has been clipped " even though inside hardware speci

[Hoang Nguyen Tran]

Dear,

Sorry if I have too much question, I am getting started with GNU radio, and
I did not find the answer for this on the Internet.

I have USRP1 and inside it has 2 daughter boards: WBX and RFX400.
I run the FM receiving grc file and got this

UHD Warning:
Tune Request: 102.50 MHz
  The ification:
Target Frequency: 102.50 MHz
Clipped Target Frequency: 380.00 MHz
  The RF LO does not support the requested frequency:
Requested LO Frequency: 380.00 MHz
RF LO Result: 400.00 MHz
  Attempted to use the DSP to reach the requested frequency:
Desired DSP Frequency: 20.00 MHz
DSP Result: 20.00 MHz
  Successfully tuned to 380.00 MHz

I changed various frequency and figure out the range that has Successfully
tuned is from 380Mhz to 520Mhz.
I don't know why this happen, the WBX suppose to have range from 50Mhz to
2200Mhz. Does it come from the wrong firmware ?
And moreover, my USRP has 2 daughter board, so how can I choose exact
daughter board to use ? In UHD USRP source of GNU radio. only have options
for antenna port for example RX2 or TX/RX, right ?

Best regards,
Hoang

-- 
 -HoangNT-
PhoneNo :  +841654248782
Skype : hoangastro
FB : https://www.facebook.com/kenshin.rorouni
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.7.8 build problem 'cannot find -lcblas'

[Barry Jackson]

Thanks for your reply.

On 14/08/15 03:46, Chris Kuethe wrote:

$ dpkg -S /usr/lib/libcblas.*
libatlas-base-dev: /usr/lib/libcblas.a
libatlas-base-dev: /usr/lib/libcblas.so
libatlas3-base: /usr/lib/libcblas.so.3
libatlas3-base: /usr/lib/libcblas.so.3gf

$ dpkg -S /usr/lib/pkgconfig/*blas*pc
libatlas-base-dev: /usr/lib/pkgconfig/blas-atlas.pc
libblas-dev: /usr/lib/pkgconfig/blas-netlib.pc
libopenblas-dev: /usr/lib/pkgconfig/blas-openblas.pc
dpkg-query: no path found matching pattern /usr/lib/pkgconfig/blas.pc
libopenblas-dev: /usr/lib/pkgconfig/lapack-openblas.pc

1) is the correct package installed?


[baz@localhost gnuradio]$ urpmf /usr/lib64/atlas/libcblas.so
lib64atlas3-x86_64:/usr/lib64/atlas/libcblas.so.3
lib64atlas3-x86_64:/usr/lib64/atlas/libcblas.so.3.0
libatlas-x86_64-devel:/usr/lib64/atlas/libcblas.so   <<=

[baz@localhost gnuradio]$ urpmq --provides libatlas-x86_64-devel
libatlas-devel[== 3.8.4-6.mga5]<<==provided by libatlas-devel
libatlas-x86_64-devel[== 3.8.4-6.mga5]
libatlas-x86_64-devel(x86-64)[== 3.8.4-6.mga5]
[baz@localhost gnuradio]$


2) is there a libcblas.* in your linker path?

[root@localhost baz]# ldconfig -p | grep cblas
libptcblas.so.3 (libc6,x86-64) => /usr/lib64/atlas/libptcblas.so.3
libptcblas.so (libc6,x86-64) => /usr/lib64/atlas/libptcblas.so
libgslcblas.so.0 (libc6,x86-64) => /lib64/libgslcblas.so.0
libgslcblas.so (libc6,x86-64) => /lib64/libgslcblas.so
libcblas.so.3 (libc6,x86-64) => /usr/lib64/atlas/libcblas.so.3
libcblas.so (libc6,x86-64) => /usr/lib64/atlas/libcblas.so


3) did cmake not find the right pkgconfig file?
I don't see anything to say either way - and I'm not very familiar with 
cmake.

grepping build dir for cblas finds:

[baz@localhost build]$ grep -r cblas
gr-wavelet/swig/CMakeFiles/_wavelet_swig.dir/link.txt:/usr/bin/c++ 
-fPIC -O2 -g -pipe -Wformat -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 
-fPIC  -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -O3 
-DNDEBUG -Wl,--as-needed  -Wl,-z,relro -Wl,-O1 -Wl,--build-id 
-Wl,--enable-new-dtags -shared -Wl,-soname,_wavelet_swig.so -o 
_wavelet_swig.so 
CMakeFiles/_wavelet_swig.dir/wavelet_swigPYTHON_wrap.cxx.o -lm -lpthread 
-lpython2.7 ../lib/libgnuradio-wavelet-3.7.8.so.0.0.0 -L/usr/lib64/atlas 
-lgsl -lcblas -lm ../../gr-blocks/lib/libgnuradio-blocks-3.7.8.so.0.0.0 
../../gnuradio-runtime/lib/libgnuradio-runtime-3.7.8.so.0.0.0 
../../gnuradio-runtime/lib/pmt/libgnuradio-pmt-3.7.8.so.0.0.0 -lrt 
../../volk/lib/libvolk.so.1.0.2 -ldl -lorc-0.4 -lboost_date_time 
-lboost_program_options -lboost_filesystem -lboost_system -lboost_thread 
-lgsl -lcblas -lm -lpthread
gr-wavelet/lib/CMakeFiles/gnuradio-wavelet.dir/link.txt:/usr/bin/c++ 
-fPIC -O2 -g -pipe -Wformat -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 
-fPIC  -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -O3 
-DNDEBUG -Wl,--no-as-needed   -Wl,--as-needed -Wl,--no-undefined 
-Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags -shared 
-Wl,-soname,libgnuradio-wavelet-3.7.8.so.0.0.0 -o 
libgnuradio-wavelet-3.7.8.so.0.0.0 
CMakeFiles/gnuradio-wavelet.dir/squash_ff_impl.cc.o 
CMakeFiles/gnuradio-wavelet.dir/wavelet_ff_impl.cc.o 
CMakeFiles/gnuradio-wavelet.dir/wvps_ff_impl.cc.o -lm -lpthread 
../../gnuradio-runtime/lib/libgnuradio-runtime-3.7.8.so.0.0.0 
../../gr-blocks/lib/libgnuradio-blocks-3.7.8.so.0.0.0 -lboost_date_time 
-lboost_program_options -lboost_filesystem -lboost_system -lboost_thread 
-lgsl -lcblas -lm 
../../gnuradio-runtime/lib/libgnuradio-runtime-3.7.8.so.0.0.0 
../../gnuradio-runtime/lib/pmt/libgnuradio-pmt-3.7.8.so.0.0.0 -lrt 
-lboost_date_time -lboost_program_options -lboost_filesystem 
-lboost_system -lboost_thread ../../volk/lib/libvolk.so.1.0.2 -ldl 
-lorc-0.4 -lm -lpthread

CMakeCache.txt:_wavelet_swig_LIB_DEPENDS:STATIC=general;m;general;pthread;general;/usr/lib64/libpython2.7.so;general;gnuradio-wavelet;general;-L/usr/lib64/atlas;general;-lgsl;general;-lcblas;general;-lm;
CMakeCache.txt:gnuradio-wavelet_LIB_DEPENDS:STATIC=general;m;general;pthread;general;gnuradio-runtime;general;gnuradio-blocks;general;/usr/lib64/libboost_date_time.so;general;/usr/lib64/libboost_program_options.so;general;/usr/lib64/libboost_filesystem.so;general;/usr/lib64/libboost_system.so;general;/usr/lib64/libboost_thread.so;general;gsl;general;cblas;general;m;
CMakeCache.txt:FIND_PACKAGE_MESSAGE_DETAILS_GSL:INTERNAL=[gsl;cblas;m][/usr/include][/usr/lib64][v()]
CMakeCache.txt:GSL_LDFLAGS:INTERNAL=-L/usr/lib64/atlas;-lgsl;-lcblas;-lm
CMakeCache.txt:GSL_LIBRARIES:INTERNAL=gsl;cblas;m
CMakeCache.txt:GSL_STATIC_LDFLAGS:INTERNAL=-L/usr/lib64/atlas;-lgsl;-lcblas;-lm
CMakeCache.txt:GSL_STATIC_LIBRARIES:INTERNAL=gsl;cblas;m


4) you could rerun make with more verbose output (add "V=1") to see
what exactly failed.


With %cmake -DCMAKE_VERBOSE_MAKEFILE=ON I get the following which may be 
of use, but I can't see it, unless it's to do

[Discuss-gnuradio] Failure to build GNU Radio on various Ubuntu builds

[Mark]

  Hello, After trying to install GNU Radio over the past few days I’vebeen 
unsuccessful due to various failures of GNU Radio to build. The latest error is 
as follows:- Segmentation fault (core 
dumped)gr-blocks/swig/CMakeFiles/blocks_swig5_swig_doc.dir/build.make:177:recipe
 for target 'gr-blocks/swig/blocks_swig5_doc.i' failedmake[2]: *** 
[gr-blocks/swig/blocks_swig5_doc.i] Error 139CMakeFiles/Makefile2:3254: recipe 
for target'gr-blocks/swig/CMakeFiles/blocks_swig5_swig_doc.dir/all' 
failedmake[1]: ***[gr-blocks/swig/CMakeFiles/blocks_swig5_swig_doc.dir/all] 
Error 2Makefile:147: recipe for target 'all' failedmake: *** [all] Error 2make 
failedExiting Gnu Radio build/install As mentioned, this is the latest error of 
a  series ofmany other errors occurring during previous install/build attempts 
but whichwould be too numerous to mention here. I’ve tried installing using 
Marcus’s script from the ShirleyBay server but the install fails near the end 
when attempting to build asmentioned above. I modified Marcus’s script at one 
point to get the install torun more successfully although eventually even that 
modification to a line inthe script fails to lead to a successful overall build 
but it does appear tobuild further doing that. On this occasion, I’ve tried 
various distro’s of Ubuntu(12.04 LTS, 14.04 LTS – 32 bit and 15.04 64 bit) but 
none accommodate theinstall of GNU Radio without some error or other. I feel I 
have installed prerequisites and so forth andprerequisites from various 
suggestions in the various threads on other sitesdiscussing the install of GNU 
Radio on Ubuntu. I should say that I’ve installed GNURadio successfully 
manytimes in the past, using 12.04 LTS and installing GNU Radio on Windows 7 
andthis has been great to use with my Ettus USRP B100 (using UHD) at the 
time.However, today, some two years later I want to use GNU Radio a lot more 
andhopefully write modules and develop a SDR UI for my Ettus device but I 
don’tappear to be having any success at the GNU Radio install which is 
frustrating. I’ve used so much time up trying to overcome the variousissues, 
I’m now turning to ask for help as I feel I’ve exhausted every approachI can 
try with my present knowledge level. All help and guidance is very much 
appreciated and manythanks in advance. Mark.  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Failure to build GNU Radio on various Ubuntu builds

[West, Nathan]

On Fri, Aug 14, 2015 at 8:42 AM, Mark  wrote:

>
> Hello,
>
> After trying to install GNU Radio over the past few days I’ve been
> unsuccessful due to various failures of GNU Radio to build.
>
> The latest error is as follows:-
>
> Segmentation fault (core dumped)
> gr-blocks/swig/CMakeFiles/blocks_swig5_swig_doc.dir/build.make:177: recipe
> for target 'gr-blocks/swig/blocks_swig5_doc.i' failed
> make[2]: *** [gr-blocks/swig/blocks_swig5_doc.i] Error 139
> CMakeFiles/Makefile2:3254: recipe for target
> 'gr-blocks/swig/CMakeFiles/blocks_swig5_swig_doc.dir/all' failed
> make[1]: *** [gr-blocks/swig/CMakeFiles/blocks_swig5_swig_doc.dir/all]
> Error 2
> Makefile:147: recipe for target 'all' failed
> make: *** [all] Error 2
> make failed
> Exiting Gnu Radio build/install
>
> As mentioned, this is the latest error of a  series of many other errors
> occurring during previous install/build attempts but which would be too
> numerous to mention here.
>
> I’ve tried installing using Marcus’s script from the Shirley Bay server
> but the install fails near the end when attempting to build as mentioned
> above. I modified Marcus’s script at one point to get the install to run
> more successfully although eventually even that modification to a line in
> the script fails to lead to a successful overall build but it does appear
> to build further doing that.
>
> On this occasion, I’ve tried various distro’s of Ubuntu (12.04 LTS, 14.04
> LTS – 32 bit and 15.04 64 bit) but none accommodate the install of GNU
> Radio without some error or other.
>
> I feel I have installed prerequisites and so forth and prerequisites from
> various suggestions in the various threads on other sites discussing the
> install of GNU Radio on Ubuntu.
>
> I should say that I’ve installed GNURadio successfully many times in the
> past, using 12.04 LTS and installing GNU Radio on Windows 7 and this has
> been great to use with my Ettus USRP B100 (using UHD) at the time. However,
> today, some two years later I want to use GNU Radio a lot more and
> hopefully write modules and develop a SDR UI for my Ettus device but I
> don’t appear to be having any success at the GNU Radio install which is
> frustrating.
>
> I’ve used so much time up trying to overcome the various issues, I’m now
> turning to ask for help as I feel I’ve exhausted every approach I can try
> with my present knowledge level.
>
> All help and guidance is very much appreciated and many thanks in advance.
>
> Mark.
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
Two comments, it's hard to provide any assistance with this since you don't
include any logs so we don't know what the exact problem is.

However, I suggest you just use the gnuradio that comes packaged in the
latest ubuntu. 'apt-get install gnuradio'. If you insist on a source build
then I always like to do at least a apt-get build-dep gnuradio on fresh OS
installs. (but it's worth asking yourself if you really need the source
build, especially since it's causing so much grief)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Failure to build GNU Radio on various Ubuntu builds

[Marcus D. Leech]

On 08/14/2015 09:11 AM, West, Nathan wrote:



Two comments, it's hard to provide any assistance with this since you 
don't include any logs so we don't know what the exact problem is.


However, I suggest you just use the gnuradio that comes packaged in 
the latest ubuntu. 'apt-get install gnuradio'. If you insist on a 
source build then I always like to do at least a apt-get build-dep 
gnuradio on fresh OS installs. (but it's worth asking yourself if you 
really need the source build, especially since it's causing so much grief)



A further comment--that seg fault is probably the compiler running out 
of memory--not very graceful of it, to be sure.


You should add more swap space to make up for lower system memory (how 
much do you have?)



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

[Discuss-gnuradio] SOCIS project update 11

[Johannes Demel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey GNU Radio'ers!

SOCIS project deadline is near. So I'm trying to finish all
outstanding tasks.

Earlier this week I could issue a pull request against VOLK. So my new
kernels are ready for review. Getting them merged into VOLK is a
prerequisite for upstreaming my polar code blocks.
The decoder contains an AVX kernel. Unfortunately some intrinsics
which could have been very useful for its implementation are missing.
e.g. '_mm256_loadu2_m128' and '_mm256_set_m128'. GCC can't find them.
I'm using GCC 4.8.4 and Ubuntu 14.04. I was able to work around those
issues but they could have bought me a speed up.

Besides finishing the kernels, I did a lot of code clean-up. Tried to
smooth variable names to follow FECAPI naming conventions. Removed
duplicate code wherever possible. Moved functionality around different
classes. Methods were renamed to better reflect their purpose.
Essentially, all the things one would do before a merge. I hope that
makes merging polar codes into mainline easier. For now there's one
commit missing. Bumping the VOLK commit pointer to a future version
which includes the polar code kernels. Nevertheless, I hope to get
some feedback for the pull request I just issued. So I can fix
anything which is coming up as soon as possible.

Next week I'll work on my presentation for GRCon. At the moment it
looks like it's going to be on Wednesday 15.30h. I'm happy to see you
all there.

More info and current project progress can be found in [1], [2] and [3].

Cheers
Johannes

[1] https://github.com/jdemel/gnuradio
[2] https://github.com/jdemel/socis-proposal
[3] https://github.com/jdemel/volk
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVzer1AAoJEO7fmkDsqywM0igP/2wclqH2XjXBohGJ+dPzK9cU
bVsrOZLrP4WAPJxNAQii4LV8Xde5Es2AvE5vA5bu0MJlp2v8f3dmkNeVRPR5Cdpm
uaIKWCV4Hg0D7xVlRDtgnBPnV3GFrvmUHSuCHLRQC5jT7r7ZQkgjE8tpYPb2+PUq
ErCMguq4AROkibt/tBp9E8Ubu8eEmEZgRBBEBaFjyKyrY5lP4TstajGpIVWcS+RB
sxb80tmOTf0flPMvwSYUi8vtCHxbRpMOqUnLZfdhsdbO7MlRITgiEzaxxmDn7kIw
NnI/F3Ae4M4eTEVbv/ex6zJBJldch4jzQP44EMQiQjFoDrMYzYli6Mba3yJtefQJ
AKh8ouooUqMu2kwTKkU2ntzM10HdHmkAw+F2q/St1ybfwZEl7sqcfh/HnXQb3k2B
bbkb9e8abj4/NCKyUPwv/tSHl0IGQZEMjpnZSfKm/8ItUAtrSDy8HkjKMiR061hP
J9/jHbEU0yCk7DFfqzdrwGyOHnu/Nwge0uIA3v0tk6LuLBBeK4fC1hLuzFvJfXjG
V5kJSTpaBnqvQ1hyicAOdZFsep5bdBgabZp/hvtyrQtR9G95sTijJ34YK7l2VhGL
Hsht9gKn+iOTmWjA8tf9buhBSHKh30I1Ohbi/DOWSG19P+DZg/YxCcJQJd1dguJO
Z51zRdry8ivo07Bg2aD5
=Zr1V
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] USRP1 warning "requested RX frequency is outside of the system range, requested RX frequency is outside of the system range, and has been clipped " even though inside hardware s

[Marcus D. Leech]

On 08/14/2015 06:21 AM, Hoang Nguyen Tran wrote:

Dear,

Sorry if I have too much question, I am getting started with GNU 
radio, and I did not find the answer for this on the Internet.


I have USRP1 and inside it has 2 daughter boards: WBX and RFX400.
I run the FM receiving grc file and got this

UHD Warning:
Tune Request: 102.50 MHz
The ification:
Target Frequency: 102.50 MHz
Clipped Target Frequency: 380.00 MHz
The RF LO does not support the requested frequency:
Requested LO Frequency: 380.00 MHz
RF LO Result: 400.00 MHz
Attempted to use the DSP to reach the requested frequency:
Desired DSP Frequency: 20.00 MHz
DSP Result: 20.00 MHz
Successfully tuned to 380.00 MHz


I changed various frequency and figure out the range that has 
Successfully tuned is from 380Mhz to 520Mhz.
I don't know why this happen, the WBX suppose to have range from 50Mhz 
to 2200Mhz. Does it come from the wrong firmware ?
And moreover, my USRP has 2 daughter board, so how can I choose exact 
daughter board to use ? In UHD USRP source of GNU radio. only have 
options for antenna port for example RX2 or TX/RX, right ?


Best regards,
Hoang

--
 -HoangNT-
PhoneNo : +841654248782 
Skype : hoangastro
FB : https://www.facebook.com/kenshin.rorouni


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

The UHD source includes a "subdev specification".

If your WBX is in the first slot, you'd use:

A:0

If your WBX is in the 2nd slot, you'd use:

B:0

As the subdevice specification.

You can use:

uhd_usrp_probe --args "type=usrp1"

To get a listing of the device configuration, including which slot your 
WBX and RFX2400 cards are in on the USRP1.



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

Re: [Discuss-gnuradio] USRP1 warning "requested RX frequency is outside of the system range, requested RX frequency is outside of the system range, and has been clipped " even though inside hardware s

[Marcus Müller]

Hi Hoang,

the 380MHz is the lower frequency you can get with a RFX400. That's
correct.

You can chose your daughterboard by using the number of channels
argument (if you want both), or the subdev spec [1], like:
B:0
to select the WBX in your second slot.

Best regards,
Marcus

[1]http://files.ettus.com/manual/page_configuration.html#config_subdev

On 08/14/2015 12:21 PM, Hoang Nguyen Tran wrote:
> Dear,
>
> Sorry if I have too much question, I am getting started with GNU
> radio, and I did not find the answer for this on the Internet.
>
> I have USRP1 and inside it has 2 daughter boards: WBX and RFX400.
> I run the FM receiving grc file and got this
>
> UHD Warning:
> Tune Request: 102.50 MHz
>   The ification:
> Target Frequency: 102.50 MHz
> Clipped Target Frequency: 380.00 MHz
>   The RF LO does not support the requested frequency:
> Requested LO Frequency: 380.00 MHz
> RF LO Result: 400.00 MHz
>   Attempted to use the DSP to reach the requested frequency:
> Desired DSP Frequency: 20.00 MHz
> DSP Result: 20.00 MHz
>   Successfully tuned to 380.00 MHz
>
>
> I changed various frequency and figure out the range that has
> Successfully tuned is from 380Mhz to 520Mhz.
> I don't know why this happen, the WBX suppose to have range from 50Mhz
> to 2200Mhz. Does it come from the wrong firmware ?
> And moreover, my USRP has 2 daughter board, so how can I choose exact
> daughter board to use ? In UHD USRP source of GNU radio. only have
> options for antenna port for example RX2 or TX/RX, right ?
>
> Best regards,
> Hoang
>
> -- 
>  -HoangNT-
> PhoneNo :  +841654248782 
> Skype : hoangastro
> FB : https://www.facebook.com/kenshin.rorouni
>
>
> ___
> 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] bidirectional with Socket PDU

[Jason Matusiak]

> If someone has an alternative, I am all ears (I'm coming up empty).

I got it working now.  If someone wants to do something similar, what I
did was take the python example code from here:
http://www.binarytides.com/code-chat-application-server-client-sockets-python/
(the last section of code near the bottom of the article that shows how
to use the select function).

The example is for TCP (which worked fine), but if you want to use UDP,
just change the line:
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
to
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

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

[Discuss-gnuradio] Building GNU Radio with previous Boost version

[David Halls]

?Hi guys,


For a number of complicated reasons I would like to build GNU Radio with an 
older version of Boost. Specifically 1.49.


Thanks,


David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Energy Detection Sensing Time Calculation?

[Gerome Jan L]

Hello community,

How do I calculate the sensing time of my Energy Detection flow graph in
GRC? Any tips? Thanks.


-- 

Best,

*Gerome Jan M. Llames *
Engineering Research and Development for Technology (ERDT) Scholar
University of San Carlos - Technological Campus
Nasipit Talamban, Cebu City, Philippines, 6000
Mobile: +639271525124
Email: geromejanlla...@gmail.com

"Design is not just what it looks like and feels like. Design is how it
works."  - Steve Jobs
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Building GNU Radio with previous Boost version

[Marcus Müller]

Hi David,

boost > 1.35 should work, but 1.49 is, if I remember correctly, an
especially buggy version, especially in Ubuntu.
I guess you wouldn't ask if there wasn't a problem, so maybe you want to
elaborate?

Best regards,
Marcus

On 08/14/2015 06:00 PM, David Halls wrote:
>
> ​Hi guys,
>
>
> For a number of complicated reasons I would like to build GNU Radio
> with an older version of Boost. Specifically 1.49.
>
>
> Thanks,
>
>
> David
>
>
> 
>
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be read,
> copied and used only by the intended recipient. If you are not the
> intended recipient, please destroy this message, delete any copies
> held on your system and notify the sender immediately.
>
> Toshiba Research Europe Limited, registered in England and Wales
> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
> Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
>
>
>
> 
> This email has been scanned for email related threats and delivered
> safely by Mimecast.
> For more information please visit http://www.mimecast.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] Energy Detection Sensing Time Calculation?

[Marcus Müller]

Hi Gerome,

we neither know your flow graph nor your application's requirements, so
this is impossible to answer.
Can you illustrate your question?

Best regards,
Marcus

On 08/14/2015 06:14 PM, Gerome Jan L wrote:
> Hello community,
>
> How do I calculate the sensing time of my Energy Detection flow
> graph in GRC? Any tips? Thanks.
>
>
> -- 
>
> Best,
>
> *Gerome Jan M. Llames *
> Engineering Research and Development for Technology (ERDT) Scholar
> University of San Carlos - Technological Campus
> Nasipit Talamban, Cebu City, Philippines, 6000
> Mobile: +639271525124 
> Email: geromejanlla...@gmail.com 
>
> "Design is not just what it looks like and feels like. Design is how
> it works."  - Steve Jobs
>
>
>
>
>
> ___
> 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] OMP Data. GNURadio overhead?

[Dennis Glatting]

Sorry for the HTML...

I have been done some work applying OpenMP to GNURadio and collected
some data. This data was collected WITHOUT GNURadio overhead.
Specifically, I interfaced directly with my detector passing 30 seconds
(30 seconds * 10msps) of data in a buffer (i.e., I allocated and filled
gr_vector_const_void_star, etc.) and calculated the performance at
different sensitivities. Herein lies one problem.

When applying OpenMP against a buffer there has to be enough data to
make it worth while but GNURadio buffers are fairly small. I don't see
a reasonable way to increase buffer sizes for a single source->block
without modifying the constant in flat_flowgraph.cc which has the side
effect of the default size for all buffers. Yes?

I am looking for a way to measure GNURadio overhead. There is a certain
amount of overhead depending on the number of blocks, set() functions,
GUI Sinks, etc. and I'd like to know what that overhead is. Ideas? 

One thought is to set a hardware pin low in the source block and set it
high in the detector block then measuring with a scope. The problem is
these pins often incur kernel overhead by opening something in /dev,
writing a string, then closing the device and waiting for the kernel to
get around to actually toggling the pin. Measurements showed this is
wildly unpredictable. Another option is to toggle a ping on an SDR but
the same problem exists with additional USB transaction delays.

Anyway, in the data below a "signal" buffer is defined as ~1200 samples
(i.e., MAXimum message size), or 2x1200=2400 complex number "chunks". I
found 2xMAX a reasonable value because it is within a reasonable buffer
amount from GNURadio with my alteration to flat_flowgraph.cc. The
OpenMP code really looks like this:

#pragma omp parallel for num_threads(ncpu),schedule(dynamic,1)  \
  if( work_list.size() > 1 )
  for( size_t i = 0; i <  work_list.size(); ++i ) {
do work...
  }

Pretty simple.

That said, unless GNURadio can provide a selective and reasonably large
amount of samples to process then the value of applying OpenMP is
probably moot.


Below, the term "sensitivity" is a bit of a misnomer because as
sensitivity increases signal rejection increases; but the text is what
it is. More specifically, there are roughly twelves sets of criteria
that need to be met before signal presence is declared. Some of those
criteria involve std::log10() and std::pow(10.0,x) operations but
interestingly those math operations are a very small amount of the
detection effort (1.02% worst case).

The numbers in the first block below is the rate in samples/second I
can process samples. For example, "Baseline" "45.0" is "1,662,796"
samples per second.

>From an OpenMP perspective, I have eight cores but limited the effort
to five with the idea GNURadio overhead and other blocks have three
cores to do their thing, worst case. OpenMP gave me a >300% performance
gain in "OMP 5core,2xMAX) but the theoretical gain is 400%. Not perfect
but I'll take it. What these numbers tell me is OpenMP can have
significant value in the context of GNURadio.

My code was run on an AMD 9590 at 4.7GHz, 5GHz boost -- my development
platform. For reasons, I also ran it on a CubieBoard4 (ARM
architecture). I should also mention I have seen NO side effects of
running OpenMP within GNURadio other than considerable amusement.



   
Sensativity:45.050.055.060.065.0Baseline (no 
OMP)1,662,769.543,478,927.5012,272,150.9919,503,025.5320,680,179.97Load divided 
by 5cores6,689,934.9013,861,829.9052,729,762.3284,351,801.4289,637,372.72OMP 
1core1,445,098.782,146,371.2212,476,405.0919,413,352.3920,517,069.07OMP 5core, 
2xMAX6,966,915.1014,678,631.5955,022,397.0287,443,925.0792,651,283.37OMP 5core, 
4xMAX6,992,352.2414,907,933.7655,214,642.0287,609,463.6592,778,048.16OMP 5core, 
8xMAX6,956,344.7614,660,481.2455,202,186.9387,681,575.7392,898,798.06CubieBoard 
5core, 
2xMAX1,805,831.743,794,176.1614,182,461.4224,444,325.8526,173,792.25Performance 
difference 
>From BaselineBaseline (no OMP)0.00%0.00%0.00%0.00%0.00%Load divided by 
>5cores302.34%298.45%329.67%332.51%333.45%OMP 
>1core-13.09%-38.30%1.66%-0.46%-0.79%OMP 5core, 
>2xMAX318.99%321.93%348.35%348.36%348.02%OMP 5core, 
>4xMAX320.52%328.52%349.92%349.21%348.63%OMP 5core, 
>8xMAX318.36%321.41%349.82%349.58%349.22%CubieBoard 5core, 
>2xMAX8.60%9.06%15.57%25.34%26.56%
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] SDRplay and gnuradio

[Ton Machielsen]

Hi all!

First message here. Still learning to work efficiently with gnuradio. Issue
is not the software, issue is the background theory of signal processing
that i need to shape up on. Using gnuradio is pretty easy. Knowing when to
use what block is a whole different story.

Anyway, my question: I just purchased an SDRplay and want to use this in
gnuradio using the gr.osmocom block. I hear that some people have this
working, some have not. Are there people here that got this block working
and if so, is this process to get the osmoblock to support SDRplay
documented somewhere?
The SDRplay developers tell us that it’s supposed to work.

Thanks,

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

Re: [Discuss-gnuradio] OMP Data. GNURadio overhead?

[Douglas Geiger]

On Fri, Aug 14, 2015 at 2:03 PM, Dennis Glatting  wrote:

> Sorry for the HTML...
>
> I have been done some work applying OpenMP to GNURadio and collected some
> data. This data was collected WITHOUT GNURadio overhead. Specifically, I
> interfaced directly with my detector passing 30 seconds (30 seconds *
> 10msps) of data in a buffer (i.e., I allocated and filled
> gr_vector_const_void_star, etc.) and calculated the performance at
> different sensitivities. Herein lies one problem.
>
> When applying OpenMP against a buffer there has to be enough data to make
> it worth while but GNURadio buffers are fairly small. I don't see a
> reasonable way to increase buffer sizes for a single source->block without
> modifying the constant in flat_flowgraph.cc which has the side effect of
> the default size for all buffers. Yes?
>

Is this a sink block (i.e. no outputs)? In general, IIRC, you have more
control on output buffer size (since you own them, and input buffers are
owned by upstream blocks). You can call
set_output_multiple()/set_min_output_buffer(...)/set_min_noutput_items(...)
to influence output buffer size (and for a sync_block, and therefore a
sync_decimator/sync_interpolator, that has a corresponding influence on the
input buffer size). Others may correct me on how much influence sink blocks
have in current releases...


> I am looking for a way to measure GNURadio overhead. There is a certain
> amount of overhead depending on the number of blocks, set() functions, GUI
> Sinks, etc. and I'd like to know what that overhead is. Ideas?
>

What exactly are you interested in measuring when you say 'overhead'? Are
you talking about memory usage? CPU usage? Latency (and if you're
interested in latency, do you mean one-way, two-way)?


> One thought is to set a hardware pin low in the source block and set it
> high in the detector block then measuring with a scope. The problem is
> these pins often incur kernel overhead by opening something in /dev,
> writing a string, then closing the device and waiting for the kernel to get
> around to actually toggling the pin. Measurements showed this is wildly
> unpredictable. Another option is to toggle a ping on an SDR but the same
> problem exists with additional USB transaction delays.
>

This sounds like you are interested in one-way latency... maybe?



> Anyway, in the data below a "signal" buffer is defined as ~1200 samples
> (i.e., MAXimum message size), or 2x1200=2400 complex number "chunks". I
> found 2xMAX a reasonable value because it is within a reasonable buffer
> amount from GNURadio with my alteration to flat_flowgraph.cc. The OpenMP
> code really looks like this:
>
> #pragma omp parallel for num_threads(ncpu),schedule(dynamic,1)  \
>   if( work_list.size() > 1 )
>   for( size_t i = 0; i <  work_list.size(); ++i ) {
> do work...
>   }
>
> Pretty simple.
>
> That said, unless GNURadio can provide a selective and reasonably large
> amount of samples to process then the value of applying OpenMP is probably
> moot.
>
>
> Below, the term "sensitivity" is a bit of a misnomer because as
> sensitivity increases signal rejection increases; but the text is what it
> is. More specifically, there are roughly twelves sets of criteria that need
> to be met before signal presence is declared. Some of those criteria
> involve std::log10() and std::pow(10.0,x) operations but interestingly
> those math operations are a very small amount of the detection effort
> (1.02% worst case).
>
> The numbers in the first block below is the rate in samples/second I can
> process samples. For example, "Baseline" "45.0" is "1,662,796" samples per
> second.
>
> From an OpenMP perspective, I have eight cores but limited the effort to
> five with the idea GNURadio overhead and other blocks have three cores to
> do their thing, worst case. OpenMP gave me a >300% performance gain in "OMP
> 5core,2xMAX) but the theoretical gain is 400%. Not perfect but I'll take
> it. What these numbers tell me is OpenMP can have significant value in the
> context of GNURadio.
>
> My code was run on an AMD 9590 at 4.7GHz, 5GHz boost -- my development
> platform. For reasons, I also ran it on a CubieBoard4 (ARM architecture). I
> should also mention I have seen NO side effects of running OpenMP within
> GNURadio other than considerable amusement.
>
>
So using OpenMP inside a work function is a perfectly reasonable way to try
to accelerate (via parallelization) that particular work function -
obviously as some point you are fighting against the thread-per-block
parallelization of GNURadio, so telling OMP to use fewer cores than your
machine has is a reasonable way to deal with this. My experience with OMP
has indicated that the thread-spawning that happens each time you enter the
work() function has a cost, and therefore instantiating a thread-pool in
the block constructor may give better results, but in the end the real
question you have to ask is: what amount of work is required to achieve the
task at 

Re: [Discuss-gnuradio] SDRplay and gnuradio

[Marcus Müller]

Hi Ton,

Welcome!

Well, I don't have an SDRplay device, but gr-osmosdr checks for the
existence of the libairspy library when you build it, and then should
automatically enable support.

Best regards,
Marcus

On 08/14/2015 08:34 PM, Ton Machielsen wrote:
> Hi all!
>
> First message here. Still learning to work efficiently with gnuradio.
> Issue is not the software, issue is the background theory of signal
> processing that i need to shape up on. Using gnuradio is pretty easy.
> Knowing when to use what block is a whole different story.
>
> Anyway, my question: I just purchased an SDRplay and want to use this
> in gnuradio using the gr.osmocom block. I hear that some people have
> this working, some have not. Are there people here that got this block
> working and if so, is this process to get the osmoblock to support
> SDRplay documented somewhere?
> The SDRplay developers tell us that it’s supposed to work.
>
> Thanks,
>
> Ton.
>
>
> ___
> 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] Gradual loss of amplitude as flowgraph runs

[John Ackermann N8UR]

Still working with the polyphase channelizer program.  While everything 
"works", there is something very strange: the output amplitude slowly 
drops the longer the program runs.  As near I can tell, this happens in 
or following the frequency translating FFT block.


To test, I stripped the flowgraph down to the bare minimum and put a 
frequency display at the output of the UHD block, and another at the 
output of the fx fft block.


By using the "max hold" feature of the display, I can easily monitor 
amplitude drop during the program run.  I'm using a signal generator to 
feed the USRP a known signal level (162.475 MHz at -70dBm).


In the attached screenshot, the left display is the UHD output, and the 
right is the fx fft output.  The flowgraph had been running for about 5 
minutes.  The signal out of the fx fft has dropped 20+ dB while the UHD 
signal level remains the same.  The longer the program runs, the further 
the fx fft output drops.


I'm not seeing any error messages on the console to indicate overrun, 
underrun, or other issues.  Due to size limits, I attach only the fft 
screenshot, but here are all the relevant files:


http://www.febo.com/pages/gr-projects/amplitude_loss_test.grc
http://www.febo.com/pages/gr-projects/amplitude_loss_test.py
http://www.febo.com/pages/gr-projects/amplitude_loss_test_fft.png
http://www.febo.com/pages/gr-projects/amplitude_loss_test_flowgraph.png

Any idea what could lead to this kind of problem?  It seems like some 
sort of accumulating error, but I'm lost as to what.


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

[Discuss-gnuradio] Gnu radio install problems CMake Error with UHD_LIBRARIES

[Andrew Neale]

Hi I'm trying to install gnuradio and I have used the following command to
retrieve the source code (after yum install gnuradio resulted in "no
package gnuradio available"): git clone --recursive git://
git.gnuradio.org/gnuradio
After making the build directory, cd to build, and the following command
cmake ../, this is the result:


 # Gnuradio disabled components
-- ##
--   * sphinx
--   * gr-ctrlport
--   * gr-comedi
--   * gr-video-sdl
--   * gr-zeromq
-- 
-- Using install prefix: /usr/local
-- Building for version: 3.7.8 / 3.7.8
CMake Error: The following variables are used in this project, but they are
set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake
files:
UHD_LIBRARIES
linked by target "gnuradio-uhd" in directory
/home/alneale/gnuradio/gr-uhd/lib
linked by target "_uhd_swig" in directory
/home/alneale/gnuradio/gr-uhd/swig

-- Configuring incomplete, errors occurred!
See also "/home/alneale/gnuradio/build/CMakeFiles/CMakeOutput.log".
See also "/home/alneale/gnuradio/build/CMakeFiles/CMakeError.log".


I got the same error from trying to use the build-gnuradio.sh script.
I tried to set the variable in the CMakeLists.txt file but that did not
work, I'm not sure I was modifying the right file or using the right syntax.
I am running CentOS 6.7 on a 32 bit pentium machine.
Thanks
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.7.8 build problem 'cannot find -lcblas'

[Barry Jackson]

I checked without the %cmake macro so the --no-as-needed did not get 
overridden and the error is the same:


Linking CXX shared library libgnuradio-wavelet-3.7.8.so
cd 
/home/baz/BLD_Mga6_5/gnuradio/BUILD/gnuradio-3.7.8/build/gr-wavelet/lib 
&& /usr/bin/cmake -E cmake_link_script 
CMakeFiles/gnuradio-wavelet.dir/link.txt --verbose=1
/usr/bin/c++  -fPIC  -fvisibility=hidden -Wsign-compare -Wall 
-Wno-uninitialized -O3 -DNDEBUG -Wl,--no-as-needed   -shared 
-Wl,-soname,libgnuradio-wavelet-3.7.8.so.0.0.0 -o 
libgnuradio-wavelet-3.7.8.so.0.0.0 
CMakeFiles/gnuradio-wavelet.dir/squash_ff_impl.cc.o 
CMakeFiles/gnuradio-wavelet.dir/wavelet_ff_impl.cc.o 
CMakeFiles/gnuradio-wavelet.dir/wvps_ff_impl.cc.o -lm -lpthread 
../../gnuradio-runtime/lib/libgnuradio-runtime-3.7.8.so.0.0.0 
../../gr-blocks/lib/libgnuradio-blocks-3.7.8.so.0.0.0 -lboost_date_time 
-lboost_program_options -lboost_filesystem -lboost_system -lboost_thread 
-lgsl -lcblas -lm 
../../gnuradio-runtime/lib/libgnuradio-runtime-3.7.8.so.0.0.0 
../../gnuradio-runtime/lib/pmt/libgnuradio-pmt-3.7.8.so.0.0.0 -lrt 
-lboost_date_time -lboost_program_options -lboost_filesystem 
-lboost_system -lboost_thread ../../volk/lib/libvolk.so.1.0.2 -ldl 
-lorc-0.4 -lm -lpthread 
-Wl,-rpath,/home/baz/BLD_Mga6_5/gnuradio/BUILD/gnuradio-3.7.8/build/gnuradio-runtime/lib:/home/baz/BLD_Mga6_5/gnuradio/BUILD/gnuradio-3.7.8/build/gr-blocks/lib:/home/baz/BLD_Mga6_5/gnuradio/BUILD/gnuradio-3.7.8/build/gnuradio-runtime/lib/pmt:/home/baz/BLD_Mga6_5/gnuradio/BUILD/gnuradio-3.7.8/build/volk/lib: 


/usr/bin/ld: cannot find -lcblas

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

Re: [Discuss-gnuradio] Tutorial 2.4.5 The Singing Sine Wave

[Marcus D. Leech]

On 08/14/2015 04:52 PM, Michael Thelen DK4MT wrote:

Hi,

I have two questions to the above mentioned Tutorial chapter, since I
realized two differences, even though I think I set it up the same.

a) To get an acceptable view in the Waterfall graph I had to adjust the
frequency to a fourth of the suggested value in the tutorial picture.
Please compare in my attachment Flowgraph_2-4-5.png, where the value is
marked with a red arrow. Why could that be?

b) How could it be managed to set the X-axis of the Waterfall graph from
-50 to 50 in the picture of the tutorial? In the documentation is stated
that this is related to the bandwidth value of the GUI Waterfall item.
So I could only change this by setting the bandwidth to 100k. But than
the maximum frequency is shown as 40kHz instead of 20kHz and the
triangle pattern stays the same. This does not seem correct, as the
frequency reading would be wrong. Please look at Waterfall_2-4-5.png.
Again marked with red arrows.

Refers to:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GRC
-- Scroll to 2.4.5

Best regards
Mike


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
The "bandwidth" setting on the waterfall is just to allow it compute the 
X-axis legend along the bottom, which in your attached pics shows -24kHz 
to +24kHz,

  although the last actual numeric marker in each direction is +/-20kHz.

Again, if you set the bandwidth to 100kHz in the waterfall, that will 
dutifully calculate the markers to show +/-50kHz.  But setting the 
"bandwidth" in the
  waterfall does *nothing* about the actual delivered sample rate. It's 
just a hint to the plotter about the bandwidth of your signal. Nearly 
the entirety
  of Gnu Radio doesn't really "know" anything about sample rates--they 
are an artifice that only becomes "real" at the edges with actual 
hardware, and

  also as a convenience when calculating filter parameters.


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

Re: [Discuss-gnuradio] OMP Data. GNURadio overhead?

[Dennis Glatting]

On Fri, 2015-08-14 at 15:17 -0400, Douglas Geiger wrote:
> On Fri, Aug 14, 2015 at 2:03 PM, Dennis Glatting 
> wrote:
> > Sorry for the HTML...
> > 
> > I have been done some work applying OpenMP to GNURadio and
> > collected some data. This data was collected WITHOUT GNURadio
> > overhead. Specifically, I interfaced directly with my detector
> > passing 30 seconds (30 seconds * 10msps) of data in a buffer (i.e.,
> > I allocated and filled gr_vector_const_void_star, etc.) and
> > calculated the performance at different sensitivities. Herein lies
> > one problem.
> > 
> > When applying OpenMP against a buffer there has to be enough data
> > to make it worth while but GNURadio buffers are fairly small. I
> > don't see a reasonable way to increase buffer sizes for a single
> > source->block without modifying the constant in flat_flowgraph.cc
> > which has the side effect of the default size for all buffers. Yes?
> > 
> Is this a sink block (i.e. no outputs)? In general, IIRC, you have
> more control on output buffer size (since you own them, and input
> buffers are owned by upstream blocks). You can call
> set_output_multiple()/set_min_output_buffer(...)/set_min_noutput_item
> s(...) to influence output buffer size (and for a sync_block, and
> therefore a sync_decimator/sync_interpolator, that has a
> corresponding influence on the input buffer size). Others may correct
> me on how much influence sink blocks have in current releases...
>  
hackRF/BladeRF Source -> Preamble Detector (the block) -> multiple
blocks.
If the preamble detector detects a signal it forwards that set of
samples to a "framer" and a GUI Sink.
 
> > I am looking for a way to measure GNURadio overhead. There is a certain 
> > amount of overhead depending on the number of blocks, set() functions, GUI 
> > Sinks, etc. and I'd like to know what that overhead is. Ideas? 
> > What exactly are you interested in measuring when you say 'overhead'? Are 
> > you talking about memory usage? CPU usage? Latency (and if you're 
> > interested in latency, do you mean one-way, two-way)?
>  
CPU. Latency. One way.
I have samples coming in at a certain rate into a limited sized buffer.
I need to know the servicing interval (latency) in an attempt to
architect a solution to prevent or reduce SDR overruns. 
There is a scheduler decision process to release the block for
execution and the overhead before calling general_work() (e.g., in
block_executor.cc), such as: update read/write pointers, are tags
present, maybe service performance counters, etc. At high sample rates
that can reduce the processing rate of samples.
> > One thought is to set a hardware pin low in the source block and set it 
> > high in the detector block then measuring with a scope. The problem is 
> > these pins often incur kernel overhead by opening something in /dev, 
> > writing a string, then closing the device and waiting for the kernel to get 
> > around to actually toggling the pin. Measurements showed this is wildly 
> > unpredictable. Another option is to toggle a ping on an SDR but the same 
> > problem exists with additional USB transaction delays.
> > This sounds like you are interested in one-way latency... maybe?
> >  
> > Anyway, in the data below a "signal" buffer is defined as ~1200 samples 
> > (i.e., MAXimum message size), or 2x1200=2400 complex number "chunks". I 
> > found 2xMAX a reasonable value because it is within a reasonable buffer 
> > amount from GNURadio with my alteration to flat_flowgraph.cc. The OpenMP 
> > code really looks like this:
> > > > #pragma omp parallel for num_threads(ncpu),schedule(dynamic,1)  \
> >   if( work_list.size() > 1 )
> >   for( size_t i = 0; i <  work_list.size(); ++i ) {
> > > > do work...
> >   }
> > > > Pretty simple.
> > > > That said, unless GNURadio can provide a selective and reasonably large 
> > > > amount of samples to process then the value of applying OpenMP is 
> > > > probably moot.
> > > > > > Below, the term "sensitivity" is a bit of a misnomer because as 
> > > > > > sensitivity increases signal rejection increases; but the text is 
> > > > > > what it is. More specifically, there are roughly twelves sets of 
> > > > > > criteria that need to be met before signal presence is declared. 
> > > > > > Some of those criteria involve std::log10() and std::pow(10.0,x) 
> > > > > > operations but interestingly those math operations are a very small 
> > > > > > amount of the detection effort (1.02% worst case).
> > > > The numbers in the first block below is the rate in samples/second I 
> > > > can process samples. For example, "Baseline" "45.0" is "1,662,796" 
> > > > samples per second.
> > > > From an OpenMP perspective, I have eight cores but limited the effort 
> > > > to five with the idea GNURadio overhead and other blocks have three 
> > > > cores to do their thing, worst case. OpenMP gave me a >300% performance 
> > > > gain in "OMP 5core,2xMAX) but the theoretical gain is 400%. Not perfect 
> > > > but