osmocom-sdr

osmocom-sdr@lists.osmocom.org

1 participants
912 discussions

[PATCH] lib/xtrx: add missing libraries
by Gwenhael Goavec-Merou 12 Jan '21

12 Jan '21

When using gr-osmosdr with an xtrx board Executing: /usr/bin/python3 -u /home/gwe/sources/nop.py Traceback (most recent call last): File "/usr/lib/python3/dist-packages/osmosdr/osmosdr_swig.py", line 14, in swig_import_helper return importlib.import_module(mname) File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1006, in _gcd_import File "<frozen importlib._bootstrap>", line 983, in _find_and_load File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 670, in _load_unlocked File "<frozen importlib._bootstrap>", line 583, in module_from_spec File "<frozen importlib._bootstrap_external>", line 1043, in create_module File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed ImportError: /usr/lib/libgnuradio-osmosdr.so.0.2.0: undefined symbol: xtrx_tune_rx_bandwidth libgnuradio-osmosdr has no references to libxtrx*.so*: $ ldd /usr/lib/libgnuradio-osmosdr.so.0.2.0.0 | grep xtrx $ After adding the mandatory library in CMakeLists.txt, flowgraph start correctly: Executing: /usr/bin/python3 -u /home/gwe/sources/nop.py CPU Features: SSE2+ SSE4.1+ AVX- FMA- Using sse2 for xtrxdsp_iq16_sc32 Using sse2 for xtrxdsp_iq8_ic16 Using sse2 for xtrxdsp_iq16_ic16i Using sse2 for xtrxdsp_iq8_ic8i Using sse2 for xtrxdsp_sc32i_iq16 Using sse2 for xtrxdsp_iq8_sc32 Using sse2 for xtrxdsp_iq8_sc32i Using sse2 for xtrxdsp_iq16_sc32i Using sse2 for xtrxdsp_sc32_iq16 Using sse2 for xtrxdsp_iq8_ic16i Using sse2 for xtrxdsp_ic16i_iq16 gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.2.0 built-in source types: file xtrx xtrx xtrx_obj::xtrx_obj = 4 And the libgnuradio-osmosdr is correctly linked to libxtrx*.so* $ ldd /usr/lib/libgnuradio-osmosdr.so.0.2.0.0 | grep xtrx libxtrx.so.0 => /usr/local/lib/libxtrx.so.0 (0x00007f0cf7188000) libxtrxll.so.0 => /usr/local/lib/libxtrxll.so.0 (0x00007f0cf6535000) libxtrxdsp.so.0 => /usr/local/lib/libxtrxdsp.so.0 (0x00007f0cf6526000) $ Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou(a)trabucayre.com> --- lib/xtrx/CMakeLists.txt | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/lib/xtrx/CMakeLists.txt b/lib/xtrx/CMakeLists.txt index 9297bf0..7f31829 100644 --- a/lib/xtrx/CMakeLists.txt +++ b/lib/xtrx/CMakeLists.txt @@ -26,6 +26,10 @@ target_include_directories(gnuradio-osmosdr PRIVATE ${LIBXTRX_INCLUDE_DIRS} ) +APPEND_LIB_LIST( + ${LIBXTRX_LIBRARIES} +) + list(APPEND gr_osmosdr_srcs ${CMAKE_CURRENT_SOURCE_DIR}/xtrx_obj.cc ${CMAKE_CURRENT_SOURCE_DIR}/xtrx_source_c.cc -- 2.26.2

1 0

[PATCH] xtrx: remove BOOST_FOREACH and obsolete API call
by argilo＠gmail.com 11 Jan '21

11 Jan '21

From: Clayton Smith <argilo(a)gmail.com> All instances of BOOST_FOREACH were removed in an earlier commit, but it was reintroduced when xtrx support was merged. I removed BOOST_FOREACH again here. Also, xtrx support fails to build because it relies on the xtrx_open_list function, which was removed from the xtrx API in 2019. It was replaced with xtrx_open_string. I don't have xtrx hardware, so I've only tested that gr-osmosdr compiles with these changes. --- lib/sink_impl.cc | 3 ++- lib/source_impl.cc | 2 +- lib/xtrx/xtrx_obj.cc | 2 +- lib/xtrx/xtrx_sink_c.cc | 4 ++-- 4 files changed, 6 insertions(+), 5 deletions(-) diff --git a/lib/sink_impl.cc b/lib/sink_impl.cc index 24938838ae..317855a4ff 100644 --- a/lib/sink_impl.cc +++ b/lib/sink_impl.cc @@ -154,7 +154,8 @@ sink_impl::sink_impl( const std::string &args ) dev_list.push_back( dev ); #endif #ifdef ENABLE_XTRX - BOOST_FOREACH( std::string dev, xtrx_sink_c::get_devices() ) + for (std::string dev : xtrx_sink_c::get_devices()) + dev_list.push_back( dev ); #endif #ifdef ENABLE_FILE for (std::string dev : file_sink_c::get_devices()) diff --git a/lib/source_impl.cc b/lib/source_impl.cc index 84f5024bb6..8f2028bb3e 100644 --- a/lib/source_impl.cc +++ b/lib/source_impl.cc @@ -242,7 +242,7 @@ source_impl::source_impl( const std::string &args ) dev_list.push_back( dev ); #endif #ifdef ENABLE_XTRX - BOOST_FOREACH( std::string dev, xtrx_source_c::get_devices() ) + for (std::string dev : xtrx_source_c::get_devices()) dev_list.push_back( dev ); #endif diff --git a/lib/xtrx/xtrx_obj.cc b/lib/xtrx/xtrx_obj.cc index a971df4647..016b420980 100644 --- a/lib/xtrx/xtrx_obj.cc +++ b/lib/xtrx/xtrx_obj.cc @@ -68,7 +68,7 @@ xtrx_obj::xtrx_obj(const std::string &path, unsigned loglevel, bool lmsreset) unsigned xtrxflag = (loglevel & XTRX_O_LOGLVL_MASK) | ((lmsreset) ? XTRX_O_RESET : 0); std::cerr << "xtrx_obj::xtrx_obj = " << xtrxflag << std::endl; - int res = xtrx_open_list(path.c_str(), NULL, &_obj); + int res = xtrx_open_string(path.c_str(), &_obj); if (res < 0) { std::stringstream message; message << "Couldn't open " ": Error: " << -res; diff --git a/lib/xtrx/xtrx_sink_c.cc b/lib/xtrx/xtrx_sink_c.cc index 46ce1b035c..5253311af9 100644 --- a/lib/xtrx/xtrx_sink_c.cc +++ b/lib/xtrx/xtrx_sink_c.cc @@ -394,7 +394,7 @@ void xtrx_sink_c::tag_process(int ninput_items) uint64_t max_count = samp0_count + ninput_items; bool found_time_tag = false; - BOOST_FOREACH(const gr::tag_t &my_tag, _tags) { + for (const gr::tag_t &my_tag : _tags) { const uint64_t my_tag_count = my_tag.offset; const pmt::pmt_t &key = my_tag.key; const pmt::pmt_t &value = my_tag.value; @@ -416,7 +416,7 @@ void xtrx_sink_c::tag_process(int ninput_items) std::cerr << "TX_TIME: " << seconds << ":" << fractional << std::endl; } - } // end foreach + } // end for if (found_time_tag) { //_metadata.has_time_spec = true; -- 2.25.1

2 1

[PATCH] hackrf: fix bandwidth setting
by argilo＠gmail.com 01 Jan '21

01 Jan '21

From: Clayton Smith <argilo(a)gmail.com> The T/R switching code added in ae2253c516bfdc9ae4575ecd61fe0e6cd8608a0d fails to set custom filter bandwidths because it sets bandwidth and sample rate in the wrong order. As noted in the documentation for hackrf_set_sample_rate: "If you want to override the baseband filter selection, you must do so after setting the sample rate." To solve this problem I moved the set_bandwidth call after set_sample_rate. It was also necessary to skip the call if a custom bandwidth was not requested. --- lib/hackrf/hackrf_common.cc | 5 ++++- lib/hackrf/hackrf_common.h | 1 + 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/lib/hackrf/hackrf_common.cc b/lib/hackrf/hackrf_common.cc index a6de22aab6..666dc60f84 100644 --- a/lib/hackrf/hackrf_common.cc +++ b/lib/hackrf/hackrf_common.cc @@ -37,6 +37,7 @@ hackrf_common::hackrf_common(const std::string &args) : _center_freq(0), _freq_corr(0), _auto_gain(false), + _requested_bandwidth(0), _bandwidth(0), _bias(false), _started(false) @@ -339,6 +340,7 @@ double hackrf_common::set_bandwidth( double bandwidth, size_t chan ) int ret; // osmosdr::freq_range_t bandwidths = get_bandwidth_range( chan ); + _requested_bandwidth = bandwidth; if ( bandwidth == 0.0 ) /* bandwidth of 0 means automatic filter selection */ bandwidth = _sample_rate * 0.75; /* select narrower filters to prevent aliasing */ @@ -411,9 +413,10 @@ bool hackrf_common::get_bias() void hackrf_common::start() { _started = true; - set_bandwidth(get_bandwidth()); set_center_freq(get_center_freq()); set_sample_rate(get_sample_rate()); + if (_requested_bandwidth != 0) + set_bandwidth(get_bandwidth()); set_gain(get_gain()); set_bias(get_bias()); } diff --git a/lib/hackrf/hackrf_common.h b/lib/hackrf/hackrf_common.h index bb553c3bc6..d1ab47b6fb 100644 --- a/lib/hackrf/hackrf_common.h +++ b/lib/hackrf/hackrf_common.h @@ -104,6 +104,7 @@ private: double _freq_corr; bool _auto_gain; double _amp_gain; + double _requested_bandwidth; double _bandwidth; bool _bias; bool _started; -- 2.25.1

1 0

FOSDEM 2021: Free Software Radio Devroom CfP
by Nicolas Cuervo Benavides 21 Dec '20

21 Dec '20

Dear friends and fans of software-defined radio and free/open-source radio topics in general, FOSDEM 2021 (the free and open-source developer's meeting usually in Brussels, Europe but **this time virtually**) will again feature a track on Software Defined Radio and any other radio-related topics in the 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. Given the current circumstances and the virtual nature of this event in 2021, we are asking the presenters to pre-record the talks, which will then be gathered by us and streamed during the event. Presenters are also asked to be present online during their timeslot for live Q&A. 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 website resides at the link below. The final schedule will be available through Pentabarf and the official FOSDEM website. Notice that the reference time will be Brussels local time (CET). https://fosdem.org/2021/schedule/track/free_software_radio/ Additional Information will be also available at: https://wiki.gnuradio.org/index.php/FOSDEM_2021 ** Submit your presentations To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM21 and follow the instructions (you need an account, but can use your account from last year if you have one. Please do NOT create a new account if you already have one). You need to create an 'Event'; make sure it's in the Free Software Radio track! Your submission should have the following information: * Your contact Email * A descriptive title and subtitle of your talk * A short abstract * Links related to the project * [Optional] A longer description of the content of your talk. 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). 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 * Submission deadline: 26 December 2020 * Announcement of selected talks: 31 December 2020 * Conference dates 6 & 7 February 2021 online * Free software radio devroom date: Sunday 7 February 2021 online 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! ** Following steps for accepted talks When your talk is accepted, you will be contacted by a deputy who will help you with the pre-recording of your talk. Together you will make sure that the content has the required quality and is stream-ready. When complete, the recording will be located into the streaming system, and Bob's your uncle. Don't forget that you **must** be available during the allocated timeslot of your talk for live Q&A. ** Steering Committee The track committee consists of: * Phil Balister - "Crofton" * Derek Kozel - "dkozel" * Nicolas Cuervo - "primercuervo" * Martin Braun - "mbr0wn" Hope to hear from you soon! And please forward this announcement. - Nicolas

1 1

[PATCH] [hackrf] Fix hackrf receive hangs by checking before each lock wait
by Adrian Chadd 17 Dec '20

17 Dec '20

Fix receive path hangs if another thread closes down the hackrf receive whilst this buffer receive function is waiting to be woken up. Now: * Sleep for up to 100ms each time waiting for the cond to be kicked; * Check whether streaming is still enabled each time rather than only when the function is entered. This fixes hangs where consumers like gqrx via gnuradio will do a stop_rx/start_rx very quickly to change something, and the buffer receive path is waiting for a buffer. --- lib/hackrf/hackrf_source_c.cc | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/lib/hackrf/hackrf_source_c.cc b/lib/hackrf/hackrf_source_c.cc index 662d04a..03ea3bd 100644 --- a/lib/hackrf/hackrf_source_c.cc +++ b/lib/hackrf/hackrf_source_c.cc @@ -30,6 +30,7 @@ #include <stdexcept> #include <iostream> +#include <chrono> #include <gnuradio/io_signature.h> @@ -203,8 +204,15 @@ int hackrf_source_c::work( int noutput_items, { std::unique_lock<std::mutex> lock(_buf_mutex); - while (_buf_used < 3 && running) // collect at least 3 buffers - _buf_cond.wait( lock ); + while (_buf_used < 3 && running) { // collect at least 3 buffers + _buf_cond.wait_for( lock , std::chrono::milliseconds(100)); + + // Re-check whether the device has closed or stopped streaming + if ( _dev.get() ) + running = (hackrf_is_streaming( _dev.get() ) == HACKRF_TRUE); + else + running = false; + } } if ( ! running ) -- 2.28.0

1 0

hackrf: gr-osmocom sink tx buffering
by Sebastian Böhm 17 Dec '20

17 Dec '20

Hi, i try to transmit 2.48 ghz radio packets (beacons) at a fixed time interval (e.g. every 1 s) via hackrf using the osmocom sink in gnuradio. Without exception, the beacons are all received by my sniffer "golden device" hardware, but burst. It seems that the packets are only transferred via USB to the hackrf device hardware when the buffer with the fixed BUF_LEN 262144 (32*16*512) is completely filled. For my setup this are e.g. 18 beacon frames, which are transmitted as burst. When I look at the USB interface, I can see this burst of data every 18 seconds in a full USB request block (URB) of size 262144 byte. All other URBs (also of size 262144 - every approx. 200us) transferred via USB are filled with zeros only. So this burst behavior should be caused by gnuradio. How can I achieve that the complex data of the osmocom sink's input is immediately (with the next URB) transferred to the hackrf hardware? Am I missing any options of the GRC module? Thank You in advance! Regards, Sebastian -- __________________________________________________________ Sebastian Boehm Brandenburg University of Technology Cottbus - Senftenberg Computer Networks Communication Systems Group E-Mail: sebastian.boehm(a)b-tu.de <mailto:Sebastian.Boehm@b-tu.de> P.O. Box: 10 13 44 D-03013 Cottbus GERMANY

3 5

gr-fosphor didn't work with AMD(R) Radeon graphics
by 雪碧 0xroot 13 Dec '20

13 Dec '20

Hi osmocom community, I am using nuc8i7hvk which devices with AMD® Radeon graphics. And build gnuradio 3.7.14 gr-fosphor gr3.7 when I run osmocom_fft -F > linux; GNU C++ version 7.5.0; Boost_106501; > UHD_003.010.000.heads-release_003_010_000_000-0-g6e1ac3fc > gr-osmosdr 0.1.5 (0.1.5) gnuradio 3.7.14.0 > built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace > airspy soapy redpitaya > Using AirSpy MINI v1.0.0-rc10-0-g946184a 2016-09-19, samplerates: 3M 6M > Airspy decim:1 kernel size:47 > -1 -1 > [w] CL Error (-1, /home/init3/SDR/gr-fosphor/lib/fosphor/cl.c:309): Unable > to fetch device IDs for platform 0. Skipping. > [!] No suitable OpenCL device found > > OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO^C I try run lib fosphor : /gr-fosphor/lib/fosphor$ ./main > -1 -1 > [w] CL Error (-1, cl.c:309): Unable to fetch device IDs for platform 0. > Skipping. > [!] No suitable OpenCL device found > [!] Failed to initialize fosphor What should I do to make it work fine? There is some infomation maybe helpful Kernel 5.4.1-050401-lowlatency lspci | grep VGA > 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] > Polaris 22 [Radeon RX Vega M GH] (rev c0) inxi -G > Graphics: Card: Advanced Micro Devices [AMD/ATI] Polaris 22 [Radeon RX > Vega M GH] > Display Server: x11 (X.Org 1.19.6 ) > drivers: fbdev,ati (unloaded: modesetting,vesa,radeon) > Resolution: 3840x2160(a)60.00hz > OpenGL: renderer: AMD Radeon Graphics version: 4.6.14736 20.20 > lshw -c video > WARNING: you should run this program as super-user. > *-display > description: VGA compatible controller > product: Polaris 22 [Radeon RX Vega M GH] > vendor: Advanced Micro Devices, Inc. [AMD/ATI] > physical id: 0 > bus info: pci@0000:01:00.0 > version: c0 > width: 64 bits > clock: 33MHz > capabilities: vga_controller bus_master cap_list rom > configuration: driver=amdgpu latency=0 > resources: iomemory:200-1ff iomemory:210-20f irq:172 > memory:2000000000-20ffffffff memory:2100000000-21001fffff > ioport:e000(size=256) memory:dba00000-dba3ffff memory:c0000-dffff > WARNING: output may be incomplete or inaccurate, you should run this > program as super-user. Thanks ---------------------------------------------------------------- 0xroot

2 3

OsmoBTS with separate Tx and Rx SDRs?
by Robert Bates (Octobang) 08 Dec '20

08 Dec '20

Hello list! I've been digging a bit into the osmo-bts project to explore the GSM stack, and only ever see config information assuming you have a full-duplex TRX radio. I have a HackRF One I'd like to use for TX and an RTL-SDR I'd like to use for RX (both operating on the 900MHz GSM band), but cannot seem to find any configuration information for setting this up - even though I've seen some mentions in passing to osmo-bts-trx supporing RTL-SDR devices. I really don't have the budget to drop a few hundred more on a USRP device just to tinker with GSM and was hoping I could get away with two dedicated radios. Can anyone tell me 1. if this kind of setup is even supported and 2. if so, point me to reference material that might help me make the connection? Thanks in advance! -Rob -- ========== Robert Bates Octobang rob(a)octobang.com https://keybase.io/arpieb

3 4

Re: [patch]: add xtrx support
by Sipos Csaba 19 Nov '20

19 Nov '20

Dear Eric, About two weeks ago I sent in a patch that adds XTRX support to gr-osmosdr. I wanted to ask if there is any problem with it, or maybe there are some other reasons it did not get merged? Please let me know if any further work is needed. Regards, Csaba

2 3

[PATCH] [hackrf] Fix hackrf receive hangs by checking before each lock wait
by Adrian Chadd 19 Nov '20

19 Nov '20

1 1

← Newer
1
...
8
9
10
11
12
13
14
...
92
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr