From ve7it at shaw.ca Wed Apr 13 00:53:18 2016 From: ve7it at shaw.ca (Lawrence Glaister) Date: Tue, 12 Apr 2016 17:53:18 -0700 Subject: patch for supporting multiple airspy by serial number in gr-osmosdr Message-ID: <570D987E.2040907@shaw.ca> Hello all, I have completed additions to airspy_source_c.cc to support using multiple airspy devices. This is done by specifying the serial number for the device (i.e. airspy=0x644064DC317C1FCD). The current behaviour of opening the first device when no serial number is specified is still maintained. Specifying airspy=0 will also open the first device found. The serial number format is a 64bit hex number with or without a leading "0x". I have attached a patch file based on the current git source, a copy of the whole CC file as patched ( see lines 93 to 112 and 122 to 129), and a screen shot of the grc block for selecting by s/n. This patch has been tested with gnuradio 3.7.9 and 0, 1 and 2 airspy devices connected. I hope this can be placed into the current sources as I know of several requests for this have shown up on various discussion boards. I place no copyright restrictions on the code... please release it however you desire. This is my first attempt at contributing to gnu radio, so please excuse any blunders in protocol I may have made. Thank you for your fine work Lawrence Glaister VE7IT Nanoose Bay BC Canada -------------- next part -------------- A non-text attachment was scrubbed... Name: source_block.png Type: image/png Size: 47770 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: airspy_source_c.cc Type: text/x-c++src Size: 17212 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: airspy_source_c.cc.diff Type: text/x-patch Size: 2086 bytes Desc: not available URL: From gnieboer at corpcomm.net Thu Apr 14 10:45:20 2016 From: gnieboer at corpcomm.net (Geof Nieboer) Date: Thu, 14 Apr 2016 13:45:20 +0300 Subject: fosphor benchmark result In-Reply-To: References: Message-ID: All, >From the wiki, I understand you are looking for some additional benchmarks for fosphor, here's what I received: Intel i7-5930X CPU (6-core w/ HT, 3.5 GHz OC to ~4.4 GHz) 2 x Radeon 270 3GB GDDR5 video cards Intel 750 SSD, 400GB NVMe Windows 10 64-bit Compiled using MSVC + AMD App SDK Average: 325 MSps I've also submitted two pull requests to the Github repo with the patches I needed to use to get it compile in MSVC 2015. Pretty minor stuff. Cheers, Geof -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sat Apr 16 12:58:56 2016 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 16 Apr 2016 14:58:56 +0200 Subject: Mailing list moderation/administration Message-ID: <20160416125856.GM31766@nataraja> Dear Osmocom SDR community, as one of the Osmocom.org admins, it has come to my attention that nobody seems to be handling the moderator queue ofr the osmocom-sdr mailing list. There's currently 267 held postings, most are spam, but there are also quite some legitimate posts held in the queue. Is there anyone involved in related projects interested in checking the mailman moderation queue regularly and approving good postings while rejecting the bad ones? Explanation: All mails from non-members are moderated to keep the list mostly spam free. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From patrick at wirklich.priv.at Sun Apr 17 20:51:20 2016 From: patrick at wirklich.priv.at (Patrick Strasser) Date: Sun, 17 Apr 2016 22:51:20 +0200 Subject: Mailing list moderation/administration In-Reply-To: <20160416125856.GM31766@nataraja> References: <20160416125856.GM31766@nataraja> Message-ID: <5713F748.4060600@wirklich.priv.at> Harald Welte 2016-04-16 14:58: > Is there anyone involved in related projects interested in checking the > mailman moderation queue regularly and approving good postings while > rejecting the bad ones? Hello, I can help moderate the list. I'm user of GNU Radio, GQRX, rtl_433 (hacking around a little bit), and would be happy to see some improvements in rtl_sdr for R820T. I've read the mailinglist rules and would offer kind words to those who do not know or forgot them :-) Having multiple moderators for the list would be a plus, to speed up moderation, preferably in different time zones. I offer CEST/CET ;-) Regards Patrick -- Engineers motto: cheap, good, fast - choose any two One of the lucky 10.000: http://xkcd.com/1053 Use Mail Encryption Today! PGP Key ID: 0xDF8A127E5A120903 Patrick Strasser -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature URL: From gnieboer at corpcomm.net Sat Apr 23 14:57:45 2016 From: gnieboer at corpcomm.net (Geof Nieboer) Date: Sat, 23 Apr 2016 17:57:45 +0300 Subject: MSVC Patch Message-ID: Please find attached patch for osmocom-sdr 1- Allows compilation on MSVC by conditionally adding __attribute(format tags based on the compiler 2- Allows builders to use Glew when required, making a GlewInit call when USING_GLEW is defined. If that is not defined, there are no changes. Geof -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- From 2c555f50786bfa3aa3428f6a6b86bbf7df72c8a8 Mon Sep 17 00:00:00 2001 From: gnieboer Date: Wed, 13 Apr 2016 19:57:46 +0300 Subject: [PATCH] Allows build on MSVC as MSVC doesn't support __attribute((format... and I needed to add glew to get it to build on windows, which then requires a glewInit() call. --- lib/fosphor/gl.c | 8 ++++++++ lib/fosphor/gl_font.h | 8 +++++++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/lib/fosphor/gl.c b/lib/fosphor/gl.c index 8b8fe4b..297de53 100644 --- a/lib/fosphor/gl.c +++ b/lib/fosphor/gl.c @@ -252,6 +252,14 @@ fosphor_gl_init(struct fosphor *self) if (!gl) return -ENOMEM; +#ifdef USING_GLEW + GLenum err = glewInit(); + if (GLEW_OK != err) + { + fprintf(stderr, "Glew initialization error: %s\n", glewGetErrorString(err)); + } +#endif + self->gl = gl; memset(gl, 0, sizeof(struct fosphor_gl_state)); diff --git a/lib/fosphor/gl_font.h b/lib/fosphor/gl_font.h index 4a5c230..107c14b 100644 --- a/lib/fosphor/gl_font.h +++ b/lib/fosphor/gl_font.h @@ -35,6 +35,12 @@ struct gl_font; #define GLF_FLG_LCD (1 << 0) +#ifdef _MSC_VER +#define PRINT_CHECK +#else +#define PRINT CHECK __attribute__((format(printf, 6, 7))) +#endif + enum glf_align { GLF_LEFT, @@ -60,7 +66,7 @@ void glf_draw_str(const struct gl_font *glf, void glf_printf(const struct gl_font *glf, float x, enum glf_align x_align, float y, enum glf_align y_align, - const char *fmt, ...) __attribute__((format(printf, 6, 7))); + const char *fmt, ...) PRINT_CHECK; void glf_begin(const struct gl_font *glf, float fg_color[3]); void glf_end(void); -- 2.7.1.windows.1 From 246tnt at gmail.com Sat Apr 23 18:28:30 2016 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 23 Apr 2016 20:28:30 +0200 Subject: MSVC Patch In-Reply-To: References: Message-ID: Hi, Thanks for the patches. Comments below. > 1- Allows compilation on MSVC by conditionally adding __attribute(format > tags based on the compiler I merged an equivalent patch, it'll be pushed whenever I push my next series of update for fosphor. > 2- Allows builders to use Glew when required, making a GlewInit call when > USING_GLEW is defined. If that is not defined, there are no changes. Any code in lib/ shouldn't have to care about doing this. It expects that all the required GL setup has been done prior to calling it. Any required setup must be done in the GR C++ part Also using a magic 'USING_GLEW' that must somehow be setup manually is not acceptable. Need some CMake logic to detect when this is required and automatically set it up. Cheers, Sylvain From gnieboer at corpcomm.net Sat Apr 23 21:28:02 2016 From: gnieboer at corpcomm.net (Geof Nieboer) Date: Sun, 24 Apr 2016 00:28:02 +0300 Subject: MSVC Patch In-Reply-To: References: Message-ID: > > Any code in lib/ shouldn't have to care about doing this. Any required setup must be done in the GR C++ part Do you mean in xxx_sink_c_impl, or are you thinking that GR would do it in it's initial GUI setup? Also using a magic 'USING_GLEW' that must somehow be setup manually is not acceptable. Need some CMake logic to detect when this is required and > automatically set it up. Sure. I don't disagree, but I'm not sure what other configurations would require Glew, so since I couldn't vouch for anything but Win10-64/MSVC, I left it as a manual option that can then be specified on the CMake command line (which is what my build scripts are doing now). If you can point in to what configurations overall would need this, then happy to submit a new change. Geof On Sat, Apr 23, 2016 at 9:28 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > > Thanks for the patches. Comments below. > > > > 1- Allows compilation on MSVC by conditionally adding __attribute(format > > tags based on the compiler > > I merged an equivalent patch, it'll be pushed whenever I push my next > series of update for fosphor. > > > > 2- Allows builders to use Glew when required, making a GlewInit call when > > USING_GLEW is defined. If that is not defined, there are no changes. > > Any code in lib/ shouldn't have to care about doing this. It expects > that all the required GL setup has been done prior to calling it. Any > required setup must be done in the GR C++ part > > Also using a magic 'USING_GLEW' that must somehow be setup manually is > not acceptable. Need some CMake logic to detect when this is required > and automatically set it up. > > > Cheers, > > Sylvain > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Sat Apr 23 22:52:28 2016 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 24 Apr 2016 00:52:28 +0200 Subject: MSVC Patch In-Reply-To: References: Message-ID: Hi, > Do you mean in xxx_sink_c_impl, or are you thinking that GR would do it in > it's initial GUI setup? In the xxx_sink_c_impl. Although since this is common this should probably be in the base_sink, most likely just after the glctx_init() call >> Also using a magic 'USING_GLEW' that must somehow be setup manually is >> not acceptable. Need some CMake logic to detect when this is required and >> automatically set it up. > > > Sure. I don't disagree, but I'm not sure what other configurations would > require Glew, so since I couldn't vouch for anything but Win10-64/MSVC, I > left it as a manual option that can then be specified on the CMake command > line (which is what my build scripts are doing now). If you can point in to > what configurations overall would need this, then happy to submit a new > change. I don't think this is compiler specific so probably anything on windows would require it. I found out someone else tried to build gr-fosphor with MSVC a while back but he never to upstream : https://github.com/ariovistus/gr-fosphor/search?utf8=%E2%9C%93&q=glew You can see there the GLEW things he had to do ... not sure if they're required. Cheers, Sylvain From gnieboer at corpcomm.net Sun Apr 24 18:19:41 2016 From: gnieboer at corpcomm.net (Geof Nieboer) Date: Sun, 24 Apr 2016 21:19:41 +0300 Subject: MSVC Patch In-Reply-To: References: Message-ID: New patch attached. GLEW detection will be somewhat spotty I suspect, the basic FindGLEW module built into CMake doesn't really cover it so I added some coverage to a custom one and added it to the cmake/modules subdir. It was good enough for mine, and users can manually specify if they need to. I haven't seen that any of the other changes ariovistus made were necessary to get gr-fosphor going, so I didn't include them. Some are needed for earlier compiler versions, but not MSVC 2015. On Sun, Apr 24, 2016 at 1:52 AM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > > > Do you mean in xxx_sink_c_impl, or are you thinking that GR would do it > in > > it's initial GUI setup? > > In the xxx_sink_c_impl. Although since this is common this should > probably be in the base_sink, most likely just after the glctx_init() > call > > > >> Also using a magic 'USING_GLEW' that must somehow be setup manually is > >> not acceptable. Need some CMake logic to detect when this is required > and > >> automatically set it up. > > > > > > Sure. I don't disagree, but I'm not sure what other configurations would > > require Glew, so since I couldn't vouch for anything but Win10-64/MSVC, I > > left it as a manual option that can then be specified on the CMake > command > > line (which is what my build scripts are doing now). If you can point > in to > > what configurations overall would need this, then happy to submit a new > > change. > > I don't think this is compiler specific so probably anything on > windows would require it. > > I found out someone else tried to build gr-fosphor with MSVC a while > back but he never to upstream : > > https://github.com/ariovistus/gr-fosphor/search?utf8=%E2%9C%93&q=glew > > You can see there the GLEW things he had to do ... not sure if they're > required. > > Cheers, > > Sylvain > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- From e65ce4644c9610a6dbfaaba227f1d9255d4b2c7a Mon Sep 17 00:00:00 2001 From: gnieboer Date: Sun, 24 Apr 2016 19:53:45 +0300 Subject: [PATCH] Refactored changes per upstream request. Added custom FindGLEW cmake module as the one included with CMake 3.3/3.5 won't find it in Windows --- CMakeLists.txt | 2 +- cmake/Modules/FindGLEW.cmake | 50 ++++++++++++++++++++++++++++++++++++++++++++ lib/CMakeLists.txt | 10 +++++++++ lib/base_sink_c_impl.cc | 8 +++++++ lib/fosphor/gl.c | 8 ------- 5 files changed, 69 insertions(+), 9 deletions(-) create mode 100644 cmake/Modules/FindGLEW.cmake diff --git a/CMakeLists.txt b/CMakeLists.txt index be911cf..53ad8e4 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -120,7 +120,7 @@ endif (QT_FOUND) ######################################################################## # Find gnuradio build dependencies ######################################################################## -set(GR_REQUIRED_COMPONENTS RUNTIME FFT) +set(GR_REQUIRED_COMPONENTS RUNTIME FFT PMT) find_package(Gnuradio 3.7.3 REQUIRED) find_package(CppUnit) diff --git a/cmake/Modules/FindGLEW.cmake b/cmake/Modules/FindGLEW.cmake new file mode 100644 index 0000000..8e7ea79 --- /dev/null +++ b/cmake/Modules/FindGLEW.cmake @@ -0,0 +1,50 @@ +#.rst: +# FindGLEW +# -------- +# +# Find the OpenGL Extension Wrangler Library (GLEW) +# +# IMPORTED Targets +# ^^^^^^^^^^^^^^^^ +# +# This module defines the :prop_tgt:`IMPORTED` target ``GLEW::GLEW``, +# if GLEW has been found. +# +# Result Variables +# ^^^^^^^^^^^^^^^^ +# +# This module defines the following variables: +# +# :: +# +# GLEW_INCLUDE_DIRS - include directories for GLEW +# GLEW_LIBRARIES - libraries to link against GLEW +# GLEW_FOUND - true if GLEW has been found and can be used + +#============================================================================= +# Copyright 2012 Benjamin Eikel +# +# Distributed under the OSI-approved BSD License (the "License"); +# see accompanying file Copyright.txt for details. +# +# This software is distributed WITHOUT ANY WARRANTY; without even the +# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +# See the License for more information. +#============================================================================= +# (To distribute this file outside of CMake, substitute the full +# License text for the above reference.) + +find_path(GLEW_INCLUDE_DIR GL/glew.h) +find_library(GLEW_LIBRARY NAMES GLEW glew64 glew32 glew glew32s PATH_SUFFIXES lib64 x86_64 x86 ) + +set(GLEW_INCLUDE_DIRS ${GLEW_INCLUDE_DIR}) +set(GLEW_LIBRARIES ${GLEW_LIBRARY}) + +if(GLEW_FOUND AND NOT TARGET GLEW::GLEW) + add_library(GLEW::GLEW UNKNOWN IMPORTED) + set_target_properties(GLEW::GLEW PROPERTIES + IMPORTED_LOCATION "${GLEW_LIBRARY}" + INTERFACE_INCLUDE_DIRECTORIES "${GLEW_INCLUDE_DIRS}") +endif() + +mark_as_advanced(GLEW_INCLUDE_DIR GLEW_LIBRARY) \ No newline at end of file diff --git a/lib/CMakeLists.txt b/lib/CMakeLists.txt index 08f7ff1..0a3321a 100644 --- a/lib/CMakeLists.txt +++ b/lib/CMakeLists.txt @@ -35,6 +35,16 @@ add_custom_command( COMMAND ${PYTHON_EXECUTABLE} -B mkresources.py fft.cl display.cl cmap_simple.glsl cmap_bicubic.glsl cmap_fallback.glsl DroidSansMonoDotted.ttf > ${CMAKE_CURRENT_BINARY_DIR}/fosphor/resource_data.c ) +if (WIN32) + find_package(GLEW REQUIRED) + include_directories( + ${GLEW_INCLUDE_DIRS} + ) + list(APPEND fosphor_libraries + ${GLEW_LIBRARIES} + ) +endif(WIN32) + include_directories( ${OPENGL_INCLUDE_DIRS} ${OpenCL_INCLUDE_DIRS} diff --git a/lib/base_sink_c_impl.cc b/lib/base_sink_c_impl.cc index bfb672c..e117020 100644 --- a/lib/base_sink_c_impl.cc +++ b/lib/base_sink_c_impl.cc @@ -85,6 +85,14 @@ void base_sink_c_impl::worker() /* Init GL context */ this->glctx_init(); +#ifdef _WIN32 + GLenum err = glewInit(); + if (GLEW_OK != err) + { + fprintf(stderr, "Glew initialization error: %s\n", glewGetErrorString(err)); + } +#endif + /* Init fosphor */ { /* (prevent // init of multiple instance to be gentle on the OpenCL diff --git a/lib/fosphor/gl.c b/lib/fosphor/gl.c index 297de53..8b8fe4b 100644 --- a/lib/fosphor/gl.c +++ b/lib/fosphor/gl.c @@ -252,14 +252,6 @@ fosphor_gl_init(struct fosphor *self) if (!gl) return -ENOMEM; -#ifdef USING_GLEW - GLenum err = glewInit(); - if (GLEW_OK != err) - { - fprintf(stderr, "Glew initialization error: %s\n", glewGetErrorString(err)); - } -#endif - self->gl = gl; memset(gl, 0, sizeof(struct fosphor_gl_state)); -- 2.7.1.windows.1 From tom at trondeau.com Fri Apr 29 14:22:19 2016 From: tom at trondeau.com (Tom Rondeau) Date: Fri, 29 Apr 2016 10:22:19 -0400 Subject: Patch to build static library (libgnuradio-osmosdr.a) Message-ID: I have attached a patch for gr-osmosdr to build it as a static library (libgnuradio-osmosdr.a) as well as the normal shared lib. This is the same method we use in GNU Radio. The main difference here, is that the patch means that the static lib will always be built. In GNU Radio, we added a -DENABLE_STATIC_LIBS option to cmake to turn this on/off. Let me know if that's preferably and if you have specific styles for adding these options (if you can just point me to the right line if you have other flags of this nature). The static libs are used in Android and other embedded systems. It's not entirely necessary, but it sure makes some things a heck of a lot simpler. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmosdr_staticlib.patch Type: text/x-patch Size: 934 bytes Desc: not available URL: From ve7it at shaw.ca Sat Apr 9 20:21:11 2016 From: ve7it at shaw.ca (Lawrence Glaister) Date: Sat, 09 Apr 2016 20:21:11 -0000 Subject: patch for supporting multiple airspy by serial number in gr-osmosdr Message-ID: <57096246.3080702@shaw.ca> Hello all, I have completed additions to airspy_source_c.cc to support using multiple airspy devices. This is done by specifying the serial number for the device (ie airspy=0x644064DC317C1FCD). The current behaviour of opening the first device when no serial number is specified is still maintained. Specifying airspy=0 will also open the first device found. The serial number format is a 64bit hex number with or without a leading "0x". I have attached a patch file based on the current git source, a copy of the whole CC file as patched ( see lines 93 to 112 and 122 to 129), and a screen shot of the grc block for selecting by s/n. This patch has been tested with gnuradio 3.7.9 and 0, 1 and 2 airspy devices connected. I hope this can be placed into the current sources as I know of several requests for this have shown up on various discussion boards. I place no copyright restrictions on the code... please release it however you desire. This is my first attempt at contributing to gnu radio, so please excuse any blunders in protocol I may have made. Thankyou for your fine work Lawrence Glaister VE7IT Nanoose Bay BC Canada -------------- next part -------------- A non-text attachment was scrubbed... Name: airspy_source_c.cc.diff Type: text/x-patch Size: 2086 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: airspy_source_c.cc Type: text/x-c++src Size: 17212 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: source_block.png Type: image/png Size: 47770 bytes Desc: not available URL: From gnieboer at corpcomm.net Mon Apr 11 07:44:37 2016 From: gnieboer at corpcomm.net (Geof Nieboer) Date: Mon, 11 Apr 2016 07:44:37 -0000 Subject: fosphor benchmark result Message-ID: All, >From the wiki, I understand you are looking for some additional benchmarks for fosphor, here's what I received: Intel i7-5930X CPU (6-core w/ HT, 3.5 GHz OC to ~4.4 GHz) 2 x Radeon 270 3GB GDDR5 video cards Intel 750 SSD, 400GB NVMe Windows 10 64-bit Compiled using MSVC + AMD App SDK Average: 325 MSps I've also submitted two pull requests to the Github repo with the patches I needed to use to get it compile in MSVC 2015. Pretty minor stuff. Cheers, Geof -------------- next part -------------- An HTML attachment was scrubbed... URL: