Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9
Hi Michael, Issues with boost disappeared with your last push. However, it seems that all the code you link to boost/gnuradio libraries needs "-stdlib=libc++ -std=c++11" to work properly. This is an example of a C++ out-of-tree project linked to GNU Radio installed via macports in Mavericks: http://gnss-sdr.org/documentation/building-guide#MacOSX Best regards, Carles On Sat, Nov 9, 2013 at 9:21 PM, Michael Dickens wrote: > That's great, Carles! Did you have issues with Boost, as per some reports > in MacPorts ticket < https://trac.macports.org/ticket/41162 >? If so, do > you remember what you did to work around them? Thanks for the feedback. - > MLD > > On Nov 9, 2013, at 5:00 AM, Carles Fernandez > wrote: > > I've tried 'sudo port install gnuradio-devel' on OSX 10.9 and it works > fine. The C++ API and runtime are completely usable; when linked from an > out-of-tree project, everything runs smoothly. > -- > Michael Dickens, Mac OS X Programmer > Ettus Research Technical Support > Email: supp...@ettus.com > Web: http://www.ettus.com > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GnuradioConfig.cmake not working properly ?
Hi,
I'm having a couple of issues when trying to switch from
FindGnuradioRuntime to GnuradioConfig
1) GNURADIO_ALL_INCLUDE_DIRS (and possibly GNURADIO_ALL_LIBRARIES)
don't seem to be propagated propely.
I have ${GNURADIO_ALL_INCLUDE_DIRS} in include_directories(...) in the
top level CMakeFile but the path is not added and CMakeCache.txt has
no trace of that variable either.
If you install in /usr/local you might not notice ... but if you use a
prefixed install, the OOT module don't find the includes
2) No GNURADIO_ALL_LIBRARY_DIRS to set in link_directories(...). I
don't really know if it's needed since it doesn't even get to that
point due to the include issue above
3) Doesn't follow all the libraries requested by the .pc
For ex, the .pc for gnuradio-runtime asks for -lgnuradio-runtime
and -lgnuradio-pmt ... so it should automatically put both in
GNURADIO_RUNTIME_LIBRARIES but it doesn't.
This causes issues for OSX for example. When using
FindGnuradioRuntime, I had to ship my own patched version that
followed all the libs. It's either that, or I need to specify 'PMT' as
a required component even though I don't use it ... (which then embeds
some GR interdependency knowledge in my own OOT projects ...)
GnuradioConfig
So am I doing something wrong that I get all theses issues ? Or isn't
anyone using GnuradioConfig ?
(I found myself wanting to use it because I now need the FFT
components linked in and didn't want to write a FindGnuradioFFT.cmake
...)
Cheers,
Sylvain
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GnuradioConfig.cmake not working properly ?
> I'm having a couple of issues when trying to switch from
> FindGnuradioRuntime to GnuradioConfig
Attached a patch that deals with issue 1 & 3. Issue 2 doesn't seem to
be an issue since ALL_LIBRARIES has absolute path in it.
Cheers,
Sylvain
diff --git a/cmake/Modules/GnuradioConfig.cmake b/cmake/Modules/GnuradioConfig.cmake
index eae9a4a..c162d09 100644
--- a/cmake/Modules/GnuradioConfig.cmake
+++ b/cmake/Modules/GnuradioConfig.cmake
@@ -50,6 +50,10 @@ function(GR_MODULE EXTVAR PCNAME INCFILE LIBFILE)
# check for .pc hints
PKG_CHECK_MODULES(PC_GNURADIO_${EXTVAR} ${PCNAME})
+if(NOT PC_GNURADIO_${EXTVAR}_FOUND)
+set(PC_GNURADIO_${EXTVAR}_LIBRARIES ${LIBFILE})
+endif()
+
set(INCVAR_NAME "GNURADIO_${EXTVAR}_INCLUDE_DIRS")
set(LIBVAR_NAME "GNURADIO_${EXTVAR}_LIBRARIES")
set(PC_INCDIR ${PC_GNURADIO_${EXTVAR}_INCLUDEDIR})
@@ -67,26 +71,29 @@ function(GR_MODULE EXTVAR PCNAME INCFILE LIBFILE)
)
# look for libs
-FIND_LIBRARY(
-${LIBVAR_NAME}
-NAMES ${LIBFILE}
-HINTS $ENV{GNURADIO_RUNTIME_DIR}/lib
-${PC_LIBDIR}
-${CMAKE_INSTALL_PREFIX}/lib/
-${CMAKE_INSTALL_PREFIX}/lib64/
-PATHS /usr/local/lib
- /usr/local/lib64
- /usr/lib
- /usr/lib64
-)
+foreach(libname ${PC_GNURADIO_${EXTVAR}_LIBRARIES})
+FIND_LIBRARY(
+${LIBVAR_NAME}_${libname}
+NAMES ${libname}
+HINTS $ENV{GNURADIO_RUNTIME_DIR}/lib
+${PC_LIBDIR}
+${CMAKE_INSTALL_PREFIX}/lib/
+${CMAKE_INSTALL_PREFIX}/lib64/
+PATHS /usr/local/lib
+ /usr/local/lib64
+ /usr/lib
+ /usr/lib64
+)
+ list(APPEND ${LIBVAR_NAME} ${${LIBVAR_NAME}_${libname}})
+endforeach(libname)
# show results
message(" * INCLUDES=${GNURADIO_${EXTVAR}_INCLUDE_DIRS}")
message(" * LIBS=${GNURADIO_${EXTVAR}_LIBRARIES}")
# append to all includes and libs list
-LIST(APPEND GNURADIO_ALL_INCLUDE_DIRS ${GNURADIO_${EXTVAR}_INCLUDE_DIRS})
-LIST(APPEND GNURADIO_ALL_LIBRARIES ${GNURADIO_${EXTVAR}_LIBRARIES})
+set(GNURADIO_ALL_INCLUDE_DIRS ${GNURADIO_ALL_INCLUDE_DIRS} ${GNURADIO_${EXTVAR}_INCLUDE_DIRS} PARENT_SCOPE)
+set(GNURADIO_ALL_LIBRARIES${GNURADIO_ALL_LIBRARIES}${GNURADIO_${EXTVAR}_LIBRARIES}PARENT_SCOPE)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(GNURADIO_${EXTVAR} DEFAULT_MSG GNURADIO_${EXTVAR}_LIBRARIES GNURADIO_${EXTVAR}_INCLUDE_DIRS)
message("GNURADIO_${EXTVAR}_FOUND = ${GNURADIO_${EXTVAR}_FOUND}")
@@ -121,3 +128,6 @@ GR_MODULE(VOCODER gnuradio-vocoder gnuradio/vocoder/api.h gnuradio-vocoder)
GR_MODULE(WAVELET gnuradio-wavelet gnuradio/wavelet/api.h gnuradio-wavelet)
GR_MODULE(WXGUI gnuradio-wxgui gnuradio/wxgui/api.h gnuradio-wxgui)
GR_MODULE(PMT gnuradio-runtime pmt/pmt.h gnuradio-pmt)
+
+list(REMOVE_DUPLICATES GNURADIO_ALL_INCLUDE_DIRS)
+list(REMOVE_DUPLICATES GNURADIO_ALL_LIBRARIES)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] I couldn't observe 2.4G Wi-Fi signal and didn't know why
On Sun, Nov 10, 2013 at 11:53:41AM +0800, Howard He wrote: > I use four antennas for test. Two are official VERT2400, others are 2.4G > antennas. I use the given example "uhd_fft.grc" (a simple FFT block) hoping to > observe frequency spectrum of Wi-Fi signal. No matter what antenna I set up > (even without antenna) and what central frequency I tune, the FFT window only > shows something like noise around -50--60dB on whole spectrum (sample > rate=25M) > which is unlike the 802.11 standard. > > There is low possibility of bad hardware I guess. I doubt that there may be > some problems with my test methods and hope for some advice. Hi Howard, have you made sure the wifi stations are actually transmitting? Do you have a real spectrum analyzer which shows energy transmitted? And are you on the correct centre frequency? 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 pgph7X3dVluBF.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] I couldn't observe 2.4G Wi-Fi signal and didn't know why
On Sun, Nov 10, 2013 at 12:03 PM, Martin Braun (CEL) wrote: > On Sun, Nov 10, 2013 at 11:53:41AM +0800, Howard He wrote: >> I use four antennas for test. Two are official VERT2400, others are 2.4G >> antennas. I use the given example "uhd_fft.grc" (a simple FFT block) hoping >> to >> observe frequency spectrum of Wi-Fi signal. No matter what antenna I set up >> (even without antenna) and what central frequency I tune, the FFT window >> only >> shows something like noise around -50--60dB on whole spectrum (sample >> rate=25M) >> which is unlike the 802.11 standard. >> >> There is low possibility of bad hardware I guess. I doubt that there may be >> some problems with my test methods and hope for some advice. > > Hi Howard, > > have you made sure the wifi stations are actually transmitting? Do you > have a real spectrum analyzer which shows energy transmitted? > And are you on the correct centre frequency? > > MB Also remember that Wifi is bursty and can be fairly low power. You won't see it constantly and will only see bursts of energy. If you do a peak/max hold you'll start seeing something and a spectrogram/waterfall plot will show you the the signal bursts. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to call another blocks in custom out-of-tree module
On Wed, Nov 06, 2013 at 11:55:00AM +, y...@solid.co.kr wrote: > Thank you for your concern. > > I will tell you more detail about my problem. > > > I'm trying to make frequency hopping system. > > [...] You don't need to call other blocks from your blocks to do this. Perhaps this can help you: https://github.com/jmalsbury/pre-cog 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 pgpa6hP5MZaOK.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [install-usrppythonPYTHON] Error 127
Hi, Can anyone help me with this error ? I do: git checkout v3.4.2git ./configure --prefix=/home/robert/gr342 --disable-gr-qtgui --with-fusb-tech=libusb1 --enable-usrp --enable-gr-usrp --enable-gnuradio-core --disable-usrp2 --disable-volk make works just fine when I run make install I get this: test -z "/home/robert/gr342/lib/python2.7/site-packages/usrpm" || /bin/mkdir -p "/home/robert/gr342/lib/python2.7/site-packages/usrpm" /usr/bin/install -c -m 644 usrp_dbid.py '/home/robert/gr342/lib/python2.7/site-packages/usrpm' /bin/bash: line 15: --destdir: command not found make[7]: *** [install-usrppythonPYTHON] Error 127 make[6]: *** [install-am] Error 2 make[5]: *** [install] Error 2 make[4]: *** [install-recursive] Error 1 make[3]: *** [install-recursive] Error 1 make[2]: *** [install] Error 2 make[1]: *** [install-recursive] Error 1 make: *** [install] Error 2 when I run /home/robert/gr342/lib/python2.7/site-packages/usrpm/ i see only one file "usrp_dbid.py" Linux Astro 3.8.0-33-generic #48~precise1-Ubuntu SMP Thu Oct 24 16:28:06 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio releases 3.7.1.1 and 3.7.2 available for download
GNU Radio releases 3.7.1.1 and 3.7.2 are now available for download: http://gnuradio.org/releases/gnuradio/gnuradio-3.7.1.1.tar.gz http://gnuradio.org/releases/gnuradio/gnuradio-3.7.2.tar.gz MD5 Sums: 9e83fda298ceb4855b473c591dd5d397 gnuradio-3.7.1.1.tar.gz 9a9da8458fd0c1b452487524ed29f3fd gnuradio-3.7.2.tar.gz Release 3.7.2 is a significant new feature and bux fix release, while 3.7.1.1 contains only the bug fixes since 3.7.1. These releases are the result of contributions from 22 developers in the GNU Radio community: Alistair Bird Bastian Bloessl Ben Hilburn Douglas Geiger Jaroslav Škarvada Johnathan Corgan Louis Philippe Lessard Marcus Müller Mark Cottrell Martin Braun Mathieu Rene Michael Berman Michael Dickens Moritz Fischer Nathan West Nicholas Corgan Philip Balister Rick Spanbauer Sebastian Koslowski Sylvain Munaut <246...@gmail.com> Tim O'Shea Tom Rondeau GNU Radio Runtime/Framework updates Work continues on fleshing out the new asynchronous messaging capabilities in GNU Radio, with additional functionality available in Python flowgraphs, several blocks getting message ports to accept parameter changes (noted below), better support for messaging only blocks (mblocks) that have no streaming ports, and several bug fixes. Stream tag handling and propagation has been improved in cases where DSP blocks introduce a signal delay. Block authors/users are able to declare an effective delay value to the runtime, and stream tags will have their position adjusted by the runtime when tags are automatically propagated through the block. In addition, for blocks derived from gr::block directly and have no fixed input/output item ratio, the internal relative rate is dynamically adjusted according to actual usage and stream tags are propagated appropriately. The performance monitoring system has a new counter that tracks accumulated work function time, and the high_res_timer functions are now exported to Python. GNU Radio Companion Updates The GRC Working Group that formed at GRCON13 in October established a roadmap for GRC: http://gnuradio.org/redmine/projects/gnuradio/wiki/GRCroadmap Led by Sebastian Koslowski, several new features and some clean up and bug fixes have been merged for release in 3.7.2. Searching for blocks on the right side GRC menu has always been problematic. The search is now implemented with a search box above the category tree that is accessed via menu, Ctrl-F, or '/'. This box is persistent, and typing in it filters the category tree in-place, allowing one to note which category the block is in. This also fixes the long standing bug where GRC would crash if the search box was opened and the category tree was scrolled. Tim O'Shea added the ability to set max_output_buffer on a per-block basis inside GRC parameter blocks. Correlate and Sync block (Tom Rondeau) As a result of work begun at GRHACK13 in June, we have added a new block called gr::digital::correlate_and_sync. This block is designed to search for a preamble by correlation and uses the results of the correlation to get a time and phase offset estimate. These estimates are passed downstream as stream tags for use by follow-on synchronization blocks. The tags are: * time_est: the estimate of the timing offset in fractions of samples. * phase_est: the phase estimate in radians (from 0 to 2pi). * corr_est: the value that triggered the correlation. Could be used downstream to estimate the quality of the time/phase estimates. These tags are located on the sample index where the correlation peak occurred. The correlate_and_sync block is designed to aid in the processing of burst modems where the timing and phase acquisition loops can get out of sync when there is no transmission. Currently, the pfb_clock_sync_ccf looks for and, if found, uses the time_est tag to set its current value of the sample timing. By doing this, we prime the clock synchronizer to be very close to the correct sample time, which allows the loop to quickly converge and track through the rest of the packet. The Costas loop block (costas_loop_cc) looks for and, if found, uses the phase_est tag. The loop uses the phase estimation to set its internal phase value. The frequency estimation of the loop is left as is. This again gets the loop very close to the real phase offset and allows the loop to acquire and track the actual phase offset quickly. There are three GRC programs that were created to test and explore the use of this block. gr-digital/examples/demod/test_corr_and_sync.py is a full simulation that generates burst PSK packets with a known header and uses the correlate_and_sync block along with the pfb_clock_sync_ccf and costas_loop_cc block's to generate and use the correlation-based tags. Noise, timing offset, and frequency offset can all be adjusted to test the limits and behavior of the receiver. If the bottom disabled blocks are enabled, this example will also show the original bits of the packets again
Re: [Discuss-gnuradio] gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration
Hi Nick, I've just pushed all the things that were pending in my tree, which include the sample rate awareness, configurable FFT windows and various fixes / refactor for more things to come. > Great! Glad to hear it. You might still take a look at the changes to gl.c, > as they're orthogonal to your reorganization and it adds a nice autoranging > sample rate text and legend. I looked at it and improved on it to support displaying the center frequency as well and switch automatically between several display modes depending on what's available (span/center) and their relative relation to one another. > That's fine. Really it was just a matter of a poor user experience -- when > the Python OpenGL bindings aren't there, the WX import fails in __init__.py, > and all the user sees is "no block named wx_core_c". Perhaps a better > failure message in __init__.py is all that's needed. I improved the error reporting. If the import failed, it keeps the stack trace and exception but doesn't display them at first. But if you try to actually instanciate the WX version, then, it will display the error and matching stack trace so that you know what went wrong. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio LiveDVD 2013-1110 (based on 3.7.2)
The GNU Radio LiveDVD has been updated:
http://gnuradio.org/releases/gnuradio/iso/ubuntu-12.04.3-desktop-amd64-gnuradio-2013-1110.torrent
Based on the Ubuntu 12.04.3 LTS 64-bit operating system, the GNU Radio
LiveDVD is a bootable SDR environment suitable for demonstration and
experimentation, contained on a read-only medium.
This release now has:
* GNU Radio release 3.7.2
* Ettus Research uhd snapshot 3.5.4-157-g7641b42
* gqrx snapshot v2.2.0-51-g6e30181
* gr-air-modes commit g585ecf1 ('next' branch)
* gr-iqbal snapshot v0.37.1-5-gd4fd4dd
* gr-osmosdr snapshot v0.1.0-44-g0d10f5e
* hackrf snapshot v2013.07.1-59-gbef5835
* libosmo-dsp v0.3
* osmo-sdr snapshot v0.1-7-gcd37e9fa
* rtl-sdr snapshot v0.5.1-14-g360dd36
--
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com
<>
signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
