osmocom-sdr

osmocom-sdr@lists.osmocom.org

1 participants
910 discussions

[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) 09 Dec '20

09 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

[PATCH] Add back pkg-config
by argilo＠gmail.com 19 Nov '20

19 Nov '20

From: Clayton Smith <argilo(a)gmail.com> When gr-osmosdr was updated to GNU Radio 3.8, generation of gnuradio-osmosdr.pc was removed. Other software uses pkg-config to find gr-osmosdr, so I think we should add it back. This fixes http://osmocom.org/issues/4423 --- CMakeLists.txt | 37 +++++++++++++++++++++++++++++++++++++ gnuradio-osmosdr.pc.in | 15 +++++++++++++++ 2 files changed, 52 insertions(+) create mode 100644 gnuradio-osmosdr.pc.in diff --git a/CMakeLists.txt b/CMakeLists.txt index c23cb49530..868057dcc8 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -275,6 +275,43 @@ if(ENABLE_PYTHON) endif(ENABLE_PYTHON) add_subdirectory(docs) +######################################################################## +# Create Pkg Config File +######################################################################## +FOREACH(inc ${Boost_INCLUDE_DIRS}) + LIST(APPEND GR_OSMOSDR_PC_CFLAGS "-I${inc}") +ENDFOREACH(inc) + +FOREACH(lib ${Boost_LIBRARY_DIRS}) + LIST(APPEND GR_OSMOSDR_PC_LIBS "-L${lib}") +ENDFOREACH(lib) + +# use space-separation format for the pc file +STRING(REPLACE ";" " " GR_OSMOSDR_PC_REQUIRES "${GR_OSMOSDR_PC_REQUIRES}") +STRING(REPLACE ";" " " GR_OSMOSDR_PC_CFLAGS "${GR_OSMOSDR_PC_CFLAGS}") +STRING(REPLACE ";" " " GR_OSMOSDR_PC_LIBS "${GR_OSMOSDR_PC_LIBS}") + +# unset these vars to avoid hard-coded paths to cross environment +IF(CMAKE_CROSSCOMPILING) + UNSET(GR_OSMOSDR_PC_CFLAGS) + UNSET(GR_OSMOSDR_PC_LIBS) +ENDIF(CMAKE_CROSSCOMPILING) + +# fake gnuradio cpack behavior as long as we don't use it directly +set(CPACK_PACKAGE_NAME "gnuradio-osmosdr") +set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "GNU Radio block for various radio hardware") +set(CPACK_PACKAGE_VERSION ${VERSION}) + +CONFIGURE_FILE( + ${CMAKE_CURRENT_SOURCE_DIR}/gnuradio-osmosdr.pc.in + ${CMAKE_CURRENT_BINARY_DIR}/gnuradio-osmosdr.pc +@ONLY) + +INSTALL( + FILES ${CMAKE_CURRENT_BINARY_DIR}/gnuradio-osmosdr.pc + DESTINATION ${GR_LIBRARY_DIR}/pkgconfig +) + ######################################################################## # Print Summary ######################################################################## diff --git a/gnuradio-osmosdr.pc.in b/gnuradio-osmosdr.pc.in new file mode 100644 index 0000000000..5f1ae694e3 --- /dev/null +++ b/gnuradio-osmosdr.pc.in @@ -0,0 +1,15 @@ +prefix=@CMAKE_INSTALL_PREFIX@ +exec_prefix=${prefix} +libdir=${exec_prefix}/@GR_LIBRARY_DIR@ +includedir=${prefix}/@GR_INCLUDE_DIR@ + +Name: @CPACK_PACKAGE_NAME@ +Description: @CPACK_PACKAGE_DESCRIPTION_SUMMARY@ +URL: http://sdr.osmocom.org/trac/wiki/GrOsmoSDR +Version: @CPACK_PACKAGE_VERSION@ +Requires: gnuradio-runtime gnuradio-blocks +Requires.private: @GR_OSMOSDR_PC_REQUIRES@ +Conflicts: +Cflags: -I${includedir} @GR_OSMOSDR_PC_CFLAGS@ +Libs: -L${libdir} -lgnuradio-osmosdr +Libs.private: @GR_OSMOSDR_PC_LIBS@ -- 2.25.1

3 4

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

10 Nov '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 | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/lib/hackrf/hackrf_source_c.cc b/lib/hackrf/hackrf_source_c.cc index 662d04a..21656f9 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,22 @@ 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 ); + // XXX adrian - tomorrow, turn this loop into a wait_for (1 second) + // and re-check dev.get / running ! + // Otherwise this will hang reasonably reliably if we race where + // receive is stopped in one thread, and we've already passed + // the hackrf_is_streaming() check; we'll never finish this loop + // and consumers (eg gqrx) will fail. + + 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 1

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr