- osmocom-sdr - lists.osmocom.org

[PATCH] apps/osmocom_fft: fix compatibility with Python 3: print needs parentheses
by Vadim Yanitskiy 12 Nov '19

12 Nov '19

--- apps/osmocom_fft | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/apps/osmocom_fft b/apps/osmocom_fft index da38861..0110d19 100755 --- a/apps/osmocom_fft +++ b/apps/osmocom_fft @@ -117,7 +117,7 @@ class app_top_block(stdgui2.std_top_block, pubsub): try: self.src.get_sample_rates().start() except RuntimeError: - print "Source has no sample rates (wrong device arguments?)." + print("Source has no sample rates (wrong device arguments?).") sys.exit(1) # Set the antenna @@ -150,18 +150,18 @@ class app_top_block(stdgui2.std_top_block, pubsub): gain_names = self.src.get_gain_names() for name in gain_names: range = self.src.get_gain_range(name) - print "%s gain range: start %d stop %d step %d" % (name, range.start(), range.stop(), range.step()) + print("%s gain range: start %d stop %d step %d" % (name, range.start(), range.stop(), range.step())) if options.gains: for tuple in options.gains.split(","): name, gain = tuple.split(":") gain = int(gain) - print "Setting gain %s to %d." % (name, gain) + print("Setting gain %s to %d." % (name, gain)) self.src.set_gain(gain, name) if self._verbose: rates = self.src.get_sample_rates() - print 'Supported sample rates %d-%d step %d.' % (rates.start(), rates.stop(), rates.step()) + print('Supported sample rates %d-%d step %d.' % (rates.start(), rates.stop(), rates.step())) if options.center_freq is None: freq = self.src.get_center_freq() @@ -221,7 +221,7 @@ class app_top_block(stdgui2.std_top_block, pubsub): #force update on pubsub keys #for key in (SAMP_RATE_KEY, BWIDTH_KEY, CENTER_FREQ_KEY, FREQ_CORR_KEY): - #print key, "=", self[key] + #print(key, "=", self[key]) #self[key] = self[key] if options.fosphor: @@ -422,7 +422,7 @@ class app_top_block(stdgui2.std_top_block, pubsub): try: bw_range = self[BWIDTH_RANGE_KEY] - #print bw_range.to_pp_string() + #print(bw_range.to_pp_string()) if bw_range.start() < bw_range.stop(): bwidth_vbox = forms.static_box_sizer(parent=self.panel, label="Bandwidth", @@ -537,14 +537,14 @@ class app_top_block(stdgui2.std_top_block, pubsub): self.rec_file_name = self.record_to_filename() - print "Recording samples to ", self.rec_file_name + print("Recording samples to ", self.rec_file_name) self.file_sink.open(self.rec_file_name); else: self.sample_rate_text.Enable() self.record_text.Enable() self.file_sink.close() - print "Finished recording to", self.rec_file_name + print("Finished recording to", self.rec_file_name) forms.toggle_button( sizer=rec_hbox, @@ -732,9 +732,9 @@ class app_top_block(stdgui2.std_top_block, pubsub): self.src.set_dc_offset( correction ) if self._verbose: - print "Set DC offset to", correction + print("Set DC offset to", correction) except RuntimeError as ex: - print ex + print(ex) def set_iq_balance_mode(self, iq_balance_mode): if iq_balance_mode == 1: @@ -761,16 +761,16 @@ class app_top_block(stdgui2.std_top_block, pubsub): self.src.set_iq_balance( correction ) if self._verbose: - print "Set IQ balance to", correction + print("Set IQ balance to", correction) except RuntimeError as ex: - print ex + print(ex) def set_sample_rate(self, samp_rate): samp_rate = self.src.set_sample_rate(samp_rate) if hasattr(self.scope, 'set_sample_rate'): self.scope.set_sample_rate(samp_rate) if self._verbose: - print "Set sample rate to:", samp_rate + print("Set sample rate to:", samp_rate) try: self[BWIDTH_KEY] = self.set_bandwidth(samp_rate) @@ -787,13 +787,13 @@ class app_top_block(stdgui2.std_top_block, pubsub): g = self[GAIN_RANGE_KEY(name)] gain = float(g.start()+g.stop())/2 if self._verbose: - print "Using auto-calculated mid-point gain" + print("Using auto-calculated mid-point gain") self[GAIN_KEY(name)] = gain return gain = self.src.set_gain(gain, name) if self._verbose: - print "Set " + name + " gain to:", gain + print("Set " + name + " gain to:", gain) def set_bandwidth(self, bw): clipped_bw = self[BWIDTH_RANGE_KEY].clip(bw) @@ -801,7 +801,7 @@ class app_top_block(stdgui2.std_top_block, pubsub): bw = self.src.set_bandwidth(clipped_bw) if self._verbose: - print "Set bandwidth to:", bw + print("Set bandwidth to:", bw) return bw @@ -814,7 +814,7 @@ class app_top_block(stdgui2.std_top_block, pubsub): f = self[FREQ_RANGE_KEY] freq = float(f.start()+f.stop())/2.0 if self._verbose: - print "Using auto-calculated mid-point frequency" + print("Using auto-calculated mid-point frequency") self[CENTER_FREQ_KEY] = freq return @@ -825,22 +825,22 @@ class app_top_block(stdgui2.std_top_block, pubsub): if freq is not None: if self._verbose: - print "Set center frequency to", freq + print("Set center frequency to", freq) elif self._verbose: - print "Failed to set freq." + print("Failed to set freq.") return freq def set_freq_corr(self, ppm): if ppm is None: ppm = 0.0 if self._verbose: - print "Using frequency corrrection of", ppm + print("Using frequency corrrection of", ppm) self[FREQ_CORR_KEY] = ppm return ppm = self.src.set_freq_corr(ppm) if self._verbose: - print "Set frequency correction to:", ppm + print("Set frequency correction to:", ppm) def main (): app = stdgui2.stdapp(app_top_block, "osmocom Spectrum Browser", nstatus=1) -- 2.24.0

1 0

[PATCH] build gr-iqbal w/ clang
by Brian Waters 11 Nov '19

11 Nov '19

Clang doesn't automatically define the "complex" keyword like old versions of GCC apparently used to. Appending this little check enabled compiling gr-iqbal w/ Clang, which is now the default compiler on OpenBSD and I think FreeBSD too. diff --git a/lib/optimize_c.cc b/lib/optimize_c.cc index 2cad998..6c8b706 100644 --- a/lib/optimize_c.cc +++ b/lib/optimize_c.cc @@ -31,7 +31,7 @@ __GNUC_PATCHLEVEL__ \ ) -#if GCC_VERSION >= 40800 +#if GCC_VERSION >= 40800 || defined(__clang__) # define complex _Complex # undef _GLIBCXX_HAVE_COMPLEX_H #endif -- Brian M. Waters brian(a)brianmwaters.net

2 1

Small patch to fix building librtlsdr on OpenBSD
by Brian Waters 11 Nov '19

11 Nov '19

Gets rid of librt, which doesn't exist on OpenBSD. The version of librtlsdr in the OpenBSD ports tree is extremely old (~2013), so this should help some users. Tested against tag 0.6.0, but it should apply just fine to HEAD. Thanks, Brian Waters -- Brian M. Waters brian(a)brianmwaters.net

3 3

Re: Small patch to fix building librtlsdr on OpenBSD
by Brian Waters 09 Nov '19

09 Nov '19

Based on some cursory googling, it's _not_ needed for FreeBSD, but I haven't tested. I'm not sure about the others. A check for librt.so would be good; something like autoconf's AC_SEARCH_LIBS that actually searches libs for clock_get time() would be best. I don't know what CMake has to offer in that regard. BWOn Nov 9, 2019 11:56 AM, Adrian Chadd <adrian(a)freebsd.org> wrote: > > is this applicable to the other BSDs too? > > Ideally the rule would be "only link in rt if it's present", right? > > > -adrian > > On Sat, 9 Nov 2019 at 03:08, Brian Waters <brian(a)brianmwaters.net> wrote: > > > > Looks like I mistakenly included the patch as an attachment, so it may not have gone through. Here it is: > > > > diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt > > index 07d64ab..015fd48 100644 > > --- a/src/CMakeLists.txt > > +++ b/src/CMakeLists.txt > > @@ -125,7 +125,7 @@ if(UNIX) > > target_link_libraries(rtl_fm m) > > target_link_libraries(rtl_adsb m) > > target_link_libraries(rtl_power m) > > -if(APPLE) > > +if(APPLE OR CMAKE_SYSTEM MATCHES "OpenBSD") > > target_link_libraries(rtl_test m) > > else() > > target_link_libraries(rtl_test m rt) > > > > Thanks, > > BW > > > > -- > > Brian M. Waters > > brian(a)brianmwaters.net > > > > On Tue, Nov 5, 2019, at 5:05 PM, Brian Waters wrote: > > > Gets rid of librt, which doesn't exist on OpenBSD. The version of > > > librtlsdr in the OpenBSD ports tree is extremely old (~2013), so this > > > should help some users. > > > > > > Tested against tag 0.6.0, but it should apply just fine to HEAD. > > > > > > Thanks, > > > Brian Waters > > > > > > -- > > > Brian M. Waters > > > brian(a)brianmwaters.net > > > Attachments: > > > * openbsd.patch

1 0

[rtl-sdr patch?] lib: retry i2c on failure
by Fab Stz 26 Oct '19

26 Oct '19

Hello, When doing a setFrequency I usually have this error afterwards and the frequency is actually not changed rtlsdr_demod_write_reg failed with -9 r82xx_write: i2c wr failed=-9 reg=17 len=1 r82xx_set_freq: failed=-9 By searching around I found this commit that makes the trick for me. https://github.com/keenerd/rtl-sdr/commit/ 9ed9ffa37e24f3293fa960cfcd74909ac3e9996c This will actually really set the frequency and remove the last 2 errors related to "r82xx". The only error remaining is then rtlsdr_demod_write_reg failed with -9 If you can include that upstream that would be nice. I created a pull request here : https://github.com/steve-m/librtlsdr/pull/56 Actually the commit is part of a large PR that you may be interested in ? https://github.com/keenerd/rtl-sdr/pull/8 Regards,

2 8

Re: [USRP-users] FOSDEM 2020: Free Software Radio Devroom CfP
by Sylvain Munaut 16 Oct '19

16 Oct '19

CC to osmocom sdr ML > Dear friends and fans of software-defined radio and free/open-source radio topics in general, > > FOSDEM 2020 (the free and open-source developer's meeting in Brussels, Europe) will, once again, feature a track on Software Defined Radio, and any other radio-related topics in the (now known as) Free Software Radio devroom. Therefore, we invite developers and users from the free software radio community to join us for this track and present your talks or demos. > > > Software Radio has become an important tool to allow anyone to access the EM spectrum. Using free software radio libraries and applications and cheap hardware, anyone can now start hacking on wireless communications, remote sensing, radar, fun hacks of all sorts, or other applications. At FOSDEM, we hope to network all these projects and improve collaboration, bring new ideas forward and get more people involved. > > > The track's web site resides at the link below. The final schedule will be available through Pentabarf and the official FOSDEM website. > > https://fosdem.org/2020/schedule/track/free_software_radio/ > > > Additional Information will be also available at: https://wiki.gnuradio.org/index.php/FOSDEM_2020 > > > ** Submit your presentations > > To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM20 and follow the instructions (you need an account, but can use your account from last year if you have one). You need to create an 'Event'; make sure it's in the Free Software Radio track! Lengths aren't fixed, but give a realistic estimate and please don't exceed 30 minutes unless you have something special planned (in that case, contact one of us). Also, don't forget to include time for Q&A. > We will typically go for 30-minute slots -- shorter talks, unless they're really short, usually tend to screw up the schedule too much. > > You aren't limited to slide presentations, of course. Be creative. However, FOSDEM is an open-source conference, therefore we ask you to stay clear of marketing presentations and present something relevant to free/open software. We like nitty-gritty technical stuff. > > Topics discussed in this devroom include: > > * SDR Frameworks + Tools > * Cellular/telecoms software > * Free/Open SDR hardware > * Wireless security > * Random fun wireless hacks > * SDR in education > * Satellite/spacecraft communication > * Ham radio related topics > > > ** Important Dates > > FOSDEM is February 1st and 2nd, 2020. The Free Software Radio devroom is happening on Sunday, the 2nd of February. > > The submission deadline is Friday, December 6th. A complete schedule for the presentations in the devroom will be available on the 15th of December. > > > In the last years we were always full to the brim with presentations, so if you want to present, please make sure to submit your abstracts soon! > > ** Steering Committee > The track committee consists of: > > * Phil Balister - "Crofton" > * Sylvain Munaut -"tnt" > * Derek Kozel - "dkozel" > * Nicolas Cuervo - "primercuervo" > * Martin Braun - "mbr0wn" (Emeritus) Cheers, Sylvain

1 0

gr-osmosdr maintainer needed
by Harald Welte 02 Oct '19

02 Oct '19

Dear Osmocom SDR community, Dear Dimitri, the situation around gr-osmosdr has been deteriorating for years. Among other things, I notice: * there has not been a tagged release since 2014 * patches (e.g. fixing clang support) are not merged * there is no support for gnuradio 3.8 I raised at least some of this both on-list (in June 2018 at http://lists.osmocom.org/pipermail/osmocom-sdr/2018-June/001766.html) and off-list in personal discussions, e.g. at CCCamp2019 It is clear that technically there are alternatives these days (mainly SoapySDR, which didn't exist when gr-osmosdr started in 2012). However, at the same time I'm seeing plenty of users asking about gr3.8 support, as there are [probably] lots of existing applications which are not ported to other input blocks. As the overall Osmocom project leader, this puts me in a difficult position: I've never been involved with gr-osmosdr myself, but I get various related e-mail which show that there are users, and that they are struggling by a lack of maintenance. It appears that original author and maintainer Dimitri has lost time and/or interest in maintaining gr-osmosdr. That's very sad, but it is a fact that people have a limited amount of time, and priorities change. I'd like to thank Dimitri and all other gr-osmosdr developers/contributors for what they have done so far. But what has unfortunately been missed here during the last 1-2 years is passing the project over to a new maintainer or group of maintainers. Just because the original author is not around anymore, it doesn't mean the project has to die. So with this message, I'm publicly calling for some other community member[s] to step up and become maintainer[s] of gr-osmosdr. Who is interested in gr-osmosdr and willing to maintain it, possibly in a team with other interested folks? I would be more than happy to provide the respective accounts/access on the osmocom.org redmine as well as the official osmocom.org upstream repository. There's a list of open issues at http://osmocom.org/projects/gr-osmosdr/issues I know there are also many forks on github, including * https://github.com/igorauad/gr-osmosdr/tree/gr3.8 gr3.8 support * https://github.com/xtrx-sdr/gr-osmosdr/ with xtrx support * https://github.com/zhovner/gr-osmosdr and https://github.com/Sevyls/gr-osmosdr with clang/MacOS related fix * https://github.com/wirstrom/gr-osmosdr with soapy end-of-burst fix * https://github.com/thegildedturtle/gr-osmosdr hackrf raspi signedness fix? * https://github.com/ScanOC/gr-osmosdr print AirSpy serial number on connect * https://github.com/romeojulietthotel/gr-osmosdr cosmetics * https://github.com/racerxdl/gr-osmosdr spyserver support? * https://github.com/rascustoms/gr-osmosdr airspy related patches * https://github.com/newdreamlj/gr-osmosdr bladerf multi stream fix * https://github.com/Lukeekul/gr-osmosdr bladerf pass source/sink args * https://github.com/IW0HDV/gr-osmosdr perseus HF support * https://github.com/dl1ksv/gr-osmosdr rs-hfiq support * https://github.com/carpikes/gr-osmosdr/ hackRF AVX/SSE performance * https://github.com/aports-ugly/gr-osmosdr gr3.8 + xtrx support * https://github.com/amungo/gr-osmosdr ADSDR support * https://github.com/0pq76r/gr-osmosdr/commits/master expose rtl-sdr gain stages So there's no shortage of interesting fixes and features to investigate and/or merge, even beyond the 'make a release and port to gr3.8'. Thanks in advance! Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1

Developing GNU Radio 3.8 support for gr-fosphor
by Terry Ferrett 26 Sep '19

26 Sep '19

Hi everyone, I've created a branch of fosphor with the goal of making it compatible with GNU Radio 3.8 (specifically the maint-3.8 branch). I've branched fosphor from https://github.com/osmocom/gr-fosphor/tree/gr38-qt5. My branch is located at https://github.com/the-aerospace-corporation/gr-fosphor/tree/gr38-qt5-aero The changes are updates to the cmake scripts and modules, most of which are derived directly from the 3.8 module porting guide located at https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide Development was performed in Ubuntu 18.04 with GNU Radio installed using pybombs and Python 3 support as described at https://github.com/gnuradio/gnuradio and using a prefix-based GNU Radio install. The updated fosphor branch has been tested with NVidia and Intel OpenCL. At this point GLFW works but QT does not. To build and install the updated fosphor branch, install GNU Radio 3.8 from the maint-3.8 branch, install all dependencies as described at the fosphor wiki, then execute git clone https://github.com/the-aerospace-corporation/gr-fosphor cd gr-fosphor git checkout gr38-qt5-aero mkdir build cd build cmake .. make make install I'm interested in the process for merging my updates back to the official repository. For instance, additional testing using different platforms might be a good idea. Best, Terry Ferrett, Signal Processing and Estimation Engineer The Aerospace Corporation <https://aerospace.org/>, El Segundo, CA

2 1

gr-fosphor install troubles:" Unable to share spectrum VBO into OpenCL context" openCL/GL sharing
by Paul Bongaerts 18 Sep '19

18 Sep '19

Hello, I'm experiencing trouble installing gr-fosphor on my new laptop using ubuntu 18.04 LTS Fist installed opengl/cl drivers, gnu-radio over the package manager, and gr-fosphor also with package manager, After that tried building gr-fosphor from source like described in the osmocom wiki. Also tried fresh ubuntu install with gnuradio an gr-fosphor using pybombs.this seems to fail the same. Although my old laptop runs fosphor (3.7.13.4) fine under just intel's openclas well as my old workstation with just nvidia fosphor, (3.8.0.0) This new install won't with either combination i try. who can help me out or point me in the right direction solving this? Thanks in advance, Paul Here is a description of what i did on the last try : Installed ubuntu 18.04 Lts Desktop >> Default settings, 3th party drivers enabled. Update: *sudo apt-get updatesudo apt-get upgrade* Installed nvidia driver 4.30 on: "Additional Drivers" tab in "Software & Updates": *software-properties-gtk* (Apply and reboot) Installed gnuradio via package manager: *sudo apt install gnuradio* Installed clinfo / glxinfo: *sudo apt install clinfo mesa-utils* Download and install latest intel opencl runtime: *sudo apt-get install lsb-corewget http://registrationcenter-download.intel.com/*****/****/**/****/**/l_opencl… <http://registrationcenter-download.intel.com/*****/****/**/****/**/l_opencl…>tar xvzf l_opencl_p_18.1.0.015.tgz cd l_opencl_p_18.1.0.015/sudo ./install_GUI.sh* (Follow steps with Defaults) Check clinfo: *clinfo Number of platforms 2 Platform Name NVIDIA CUDA Platform Vendor NVIDIA Corporation Platform Version OpenCL 1.2 CUDA 10.2.120 Platform Profile FULL_PROFILE Platform Extensions cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_fp64 cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_copy_opts cl_nv_create_buffer Platform Extensions function suffix NV Platform Name Intel(R) CPU Runtime for OpenCL(TM) Applications Platform Vendor Intel(R) Corporation Platform Version OpenCL 2.1 LINUX Platform Profile FULL_PROFILE Platform Extensions cl_khr_icd cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_depth_images cl_khr_3d_image_writes cl_intel_exec_by_local_thread cl_khr_spir cl_khr_fp64 cl_khr_image2d_from_buffer cl_intel_vec_len_hint Platform Host timer resolution 1ns Platform Extensions function suffix INTEL* Check glxinfo: *glxinfo* *name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4 server glx extensions: GLX_ARB_context_flush_control, GLX_ARB_create_context, GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, GLX_ARB_multisample, GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_libglvnd, GLX_EXT_stereo_tree, GLX_EXT_swap_control, GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_NV_copy_image, GLX_NV_delay_before_swap, GLX_NV_float_buffer, GLX_NV_robustness_video_memory_purge, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_SGI_video_sync client glx vendor string: NVIDIA Corporation client glx version string: 1.4 client glx extensions: GLX_ARB_context_flush_control, GLX_ARB_create_context, GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_stereo_tree, GLX_EXT_swap_control, GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_NV_copy_buffer, GLX_NV_copy_image, GLX_NV_delay_before_swap, GLX_NV_float_buffer, GLX_NV_multisample_coverage, GLX_NV_present_video, GLX_NV_robustness_video_memory_purge, GLX_NV_swap_group, GLX_NV_video_capture, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_SGI_video_sync GLX version: 1.4 GLX extensions: GLX_ARB_context_flush_control, GLX_ARB_create_context, GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_stereo_tree, GLX_EXT_swap_control, GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_NV_copy_image, GLX_NV_delay_before_swap, GLX_NV_float_buffer, GLX_NV_robustness_video_memory_purge, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_SGI_video_sync Memory info (GL_NVX_gpu_memory_info): Dedicated video memory: 2048 MB Total available memory: 2048 MB Currently available dedicated video memory: 1710 MB OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce MX250/PCIe/SSE2 OpenGL core profile version string: 4.6.0 NVIDIA 430.26 OpenGL core profile shading language version string: 4.60 NVIDIA OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: GL_AMD_multi_draw_indirect, GL_AMD_sea........................* Run volk to create profile: * volk_profile* Execute a gnuradio-companion flowgraph (FastNoiseSource>Throttle>FosphorSink): * GLFW No Gui error: Executing: /usr/bin/python -u /home/paul/top_block.py Press Enter to quit: [+] Selected device: GeForce MX250 [!] CL Error (-5, /build/gr-fosphor-D4UWhK/gr-fosphor-3.7.0.2.7b6b996/lib/fosphor/cl.c:480): Unable to share spectrum VBO into OpenCL context >>> Done* QT Gui error: *Executing: /usr/bin/python -u /home/paul/top_block.py File "/home/paul/top_block.py", line 75 self.fosphor_qt_sink_c_0 = Template error: #set $win = 'self._%s_win'%$id ^ SyntaxError: invalid syntax >>> Done (return code 1*) WX Gui error: *Executing: /usr/bin/python -u /home/paul/top_block.py Warning: failed to XInitThreads() [xcb] Unknown request in queue while dequeuing [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. python: ../../src/xcb_io.c:165: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed. >>> Done* Install from source: Install GnuRadio 3.7.x build dependencies: *sudo apt install cmake git g++ libboost-all-dev python-dev python-mako python-numpy python-wxgtk3.0 python-sphinx python-cheetah swig libzmq3-dev libfftw3-dev libgsl-dev libcppunit-dev doxygen libcomedi-dev libqt4-opengl-dev python-qt4 libqwt-dev libsdl1.2-dev libusb-1.0-0-dev python-gtk2 python-lxml pkg-config python-sip-dev* Install GLFW build dependencies: *sudo apt-get install git cmake xorg-dev libglu1-mesa-dev* Install glfw from source: *git clone https://github.com/glfw/glfw <https://github.com/glfw/glfw>cd glfwmkdir buildcd buildcmake ../ -DBUILD_SHARED_LIBS=truemakesudo make installsudo ldconfig* Install gr-fosphor build dependencies: *sudo apt-get install nvidia-opencl-dev opencl-headerssudo apt-get install nvidia-modprobesudo apt-get install gnuradio-dev opencl-headers libboost-system-dev libboost-thread-dev* Install gr-fosphor from source: *git clone git://git.osmocom.org/gr-fosphor <http://git.osmocom.org/gr-fosphor>cd gr-fosphorcd buildcmake ../makesudo make installsudo ldconfig* After reading https://lists.gnu.org/archive/html/discuss-gnuradio/2018-08/msg00019.html and https://lists.osmocom.org/pipermail/osmocom-sdr/2017-June/001594.html : nano gr-fosphor/lib/fosphor/private.h Change: #define FLG_FOSPHOR_USE_CLGL_SHARING (0<<0) : recompile and install: *cd gr-fosphorcd buildcmake ../makesudo make installsudo ldconfig* Tried (0<<0) (1<<0) (1<<1) (0<<1) All combinations keep giving the same errors as before. l

2 3

GNURADIO AttributeError when instantiating OSMOSDR source in my OOT module (C++)
by Thabet GHARBI 13 Sep '19

13 Sep '19

Hello, I'm creating a GNU Radio OOT module in C++ language, in which I instantiate an osmosdr source. The syntax is : osmosdr::source ::sptr m_source = osmosdr::source::make(); I also implement other blocks in my design. In CMakeLists.txt file, I specify all these components: set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS FFT OSMOSDR) find_package(Gnuradio-osdmosdr REQUIRED) include_directories( ... ${GNURADIO_OSMOSDR_INCLUDE_DIRS} ) link_directories( ... ${GNURADIO_OSMOSDR_LIBRARY_DIRS} ) In cmake/Modules folder, I copied the FindGnuradio-osmosdr.cmake file from gqrx project. The logs of cmake command show that the osmosdr library is found: -- checking for module 'gnuradio-osmosdr' -- Found gnuradio-osmosdr, version v0.1.4-127-g4d83c606 -- Found GNURADIO_OSMOSDR: /usr/local/lib/libgnuradio-osmosdr.so After compiling the module (cmake .. -> make -> make install -> ldconfig), I got the error 'AttributeError: 'module' object has no attribute 'test'. I analysed the undefined symbol, and it was due to osmosdr module. Any suggestion to solve this problem? PS: - I'm working on Ubuntu 16.04 (VM), gnuradio 3.7.9, cmake 3.5.1 - In GRC, the osmosdr source and sink work fine Thanks.

1 0