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
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
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
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
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
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
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
