osmocom-sdr

osmocom-sdr@lists.osmocom.org

2 participants
906 discussions

OsmoDevCall on Feb 15, 2023: Long range communications in the HF band
by Harald Welte 14 Feb '23

14 Feb '23

Dear Osmocom community, we're happy to announce the next incarnation of OsmoDevCall. when: February 15, 2023 at 20:00 CET where: https://osmocom.org/OsmoDevCall This time, @rafael2kwill be presenting on Long range communications in the HF band This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation as outlined above 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you soon! Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Re: [patch] Pass additional library arguments to ld
by Paul R. Tagliamonte 10 Jan '23

10 Jan '23

I did send this to the right place! I had to go onto IRC to confirm - and someone was nice enough to start a review. May be good for others waiting for feedback to join the IRC and do the same. I suspect this ML is a bit disused for contributions. From the conversation on IRC which I'm putting into the email thread to keep everything in one place, here's what I learned: MSVC requires this manual path work, so the first patch isn't going to work, since those values need to be hardcoded for that platform. This just leaves patch #2 for review. After a bit of confusion during the review regarding cmake's behavior and how the CMake in rtl-sdr was causing the build failure not cmake itself (confusion here may explain why no one triaged?) the feedback on the review *appears* to be: | <> so something like https://pastebin.com/CxXiGakh | <> the "beauty" is that this does not just add random lib search paths to | the targets that affect the other libs (which we don't have) Pastebin contents at the bottom at [0]. I have not revised the patches to use this approach, and I don't think I plan to - I haven't gotten very positive vibes on contributing (nor any indication anyone seems to mind the build system is broken?), so I'm not driving this anymore. If the core team needs someone to do the work, maybe another contributor will step forward in a few months. There's also a related PR against the mirror as PR 68, which fixes this issue -- turns out it impacts OSX (not just OpenBSD) at https://github.com/steve-m/librtlsdr/pull/68 -- it has another solution I overlooked -- using LIBUSB_LINK_LIBRARIES. I can confirm this patch also works on OpenBSD. If someone wouldn't mind merging one of the three patches or taking none of them with an independent fix, I'd be very grateful to get this off my mental queue. As I I said on IRC I'd leave it here and help review any patches the team comes up with if they want testing before a push. I'm no longer driving these patches or trying to drive them into main. I don't even run OpenBSD; this was a fix I wanted to send in when I hit a build failure targeting a friend's OS choice figuring it'd be a helpful time-saver for the project and its users after I debugged where exactly the librtlsdr CMake was broken and fixed it locally. paultag [0]: | if(PKG_CONFIG_FOUND) | pkg_check_modules(LIBUSB libusb-1.0 IMPORTED_TARGET) | if(LIBUSB_FOUND) | find_library ( | LIBUSB_LIBRARIESX | NAMES ${LIBUSB_LIBRARIES} | PATHS ${LIBUSB_LIBRARY_DIRS} | ) | set(LIBUSB_LIBRARIES ${LIBUSB_LIBRARIESX} CACHE INTERNAL "full libusb path") | #message(WARNING ${LIBUSB_LIBRARIES}) | endif() | else() | set(LIBUSB_LIBRARIES "" CACHE STRING "manual libusb path") | set(LIBUSB_INCLUDE_DIRS "" CACHE STRING "manual libusb includepath") | endif()

1 0

gr-osmosdr bias-tx runtime switching feature request
by Paul Bongaerts 01 Jan '23

01 Jan '23

Hello everyone, I would like to know if it's possible to switch the bias-tee / phantom power to the hackrf one at runtime in the osmocom-sink block. At the moment it's possible to change the gains and switch the 14 db amp at runtime. Only the bias-tee is en/disabled with device arguments "hackrf=0,bias-tx=0|1" which must be set at startup. Would like to be able to switch this when the flowgraph is running. I haven't figured out how to change device arguments after startup. Or would this require a change on the sink block adding something like a bias-tee option? Thanks and best wishes for the new year. Paul

1 0

Request to reactivate Miri support
by MarcHOsmo＠gmx-topmail.de 30 Dec '22

30 Dec '22

Hello everyone, Short story: I would like to ask if it is possible to bring back the Miri support that was removed in October 2020? The market for cheap SDR receivers has changed in recent years and there are now more good boards with Miri chipsets. Long story: I work as an industrial mechanic, but my secret loves since many years are electronics and amateur radio. It was GNU Radio that allowed me to learn a lot about filtering, modulation or signal mixing without the necessary technical training. I started with the RTL-SDR sticks like many others and they got me off to a good start, but the lack of ability to receive signals below 20MHz without modification makes it difficult for beginners to experiment. This is where the cheap Miri Boards come into play today. I ordered boards with Miri chipset from China for 18€ delivered to Germany. They have a good performance for beginners and signals above 10kHz can also be received well. My plan is to develop cheap open source boards for amateur radio beginners that are connected directly to the Miri boards. Based on the NE555 and the Si5351A, basics such as filters, attenuators, mixing and modulating frequencies should be explained and tested. My biggest problem is that I'm not a good programmer, so I can't manage to re-implement Miri support myself and compile gr-osmosdr to get it running on Windows (yes, I'll burn in hell for it one day). Hence my request to resume Miri support in gr-osmosdr or the question of whether someone can help me to create a fork that can be compiled with Miri Support under Windows. Offtopic: After all these years of using gr-osmosdr, I would like to take this opportunity to thank everyone involved for their time and dedication, which enables people like me to learn and develop with simple means and without expensive equipment. Thanks for your time and Merry Christmas to everyone! Marc

3 3

[patch] Pass additional library arguments to ld
by Paul R. Tagliamonte 26 Dec '22

26 Dec '22

Hey osmocom-sdr, I've got a choose your own adventure patch set here for the adventurous reviewer. On OpenBSD (but not specific to OpenBSD) libusb-1.0 lives in /usr/local/lib. The default linker (lld 13.0.0 on 7.2) doesn't include /usr/local/lib in its out of the box search path, which triggers a build failure in rtl-sdr because the -L argument(s) aren't passed through to ld. The root cause here is that we pass ${LIBUSB_LIBRARIES} to target_link_libraries, which is only the -lfoo arguments, but not the -L/foo/bar arguments. This tends to work on most systems, since libusb is usually in a place ld will search anyway. There's two ways I could see to do this. Here comes the choose your own adventure part: 1) The first is to use the PkgConfig::LIBUSB helper, which can be passed directly to `target_link_libraries`, which allows all the arguments to be passed through. This means the existing hooks to pass in a manual path would be dropped and building without pkg-config against libusb won't be supported anymore. This is the attached git format-patch entitled "0001-Use-the-PkgConfig-imported-target-rather-than-_LIBRA.patch". 2) Punch the -L arguments through next to the LIBUSB_LIBRARIES argument to `target_link_libraries`, add a new knob to set the values ("manual libusb librarypath"), and when using pkg-config, generate the arguments with a FOREACH. This is the attached git format-patch "0001-Pass-additional-library-directory-arguments-to-ld.patch". Both patch flavors build on my Debian sid box and an OpenBSD 7.2 box. paultag -- :wq

2 1

[PATCH] Fix signal handler from getting stuck in an endless loop
by Tobias Girstmair 18 Dec '22

18 Dec '22

The signal handler for SIGINT/TERM/QUIT and, importantly, SIGPIPE tries to write an informational message to stderr. When however stderr is redirected to a closed pipe, this will cause (another) SIGPIPE, and in turn the signal handler will get called again, and again and again. Since we intend to exit rtl_fm anyways, we can just ignore this signal from this point on. --- Here is a small test program to verify the bug. from subprocess import Popen, PIPE p = Popen("rtl_test", stderr=PIPE) # sighandler is set up after rtlsdr_open() call, so read past that while p.stderr.readline()[:8] != b"Sampling": pass p.stderr.close() p.terminate() # SIGTERM -> sighandler() -> fprintf(stderr) -> SIGPIPE! Note that the signal handler is not set up immediately, but only after rtlsdr_open() is called. Due to line buffering/flushing on stderr, we must read from the pipe or rtl_* will stall and SIGTERM/PIPE will still be handled by the SIG_DFL, not triggering the write to the broken pipe. And in case someone is wondering: Using signal(2) instead of sigaction(2) is OK, as long as it only sets to SIG_DFL or SIG_IGN. src/rtl_adsb.c | 1 + src/rtl_fm.c | 1 + src/rtl_power.c | 1 + src/rtl_sdr.c | 1 + src/rtl_tcp.c | 1 + src/rtl_test.c | 1 + 6 files changed, 6 insertions(+) diff --git a/src/rtl_adsb.c b/src/rtl_adsb.c index 7aea8dd..8119ac8 100644 --- a/src/rtl_adsb.c +++ b/src/rtl_adsb.c @@ -123,6 +123,7 @@ sighandler(int signum) #else static void sighandler(int signum) { + signal(SIGPIPE, SIG_IGN); fprintf(stderr, "Signal caught, exiting!\n"); do_exit = 1; rtlsdr_cancel_async(dev); diff --git a/src/rtl_fm.c b/src/rtl_fm.c index 7c84332..037793c 100644 --- a/src/rtl_fm.c +++ b/src/rtl_fm.c @@ -246,6 +246,7 @@ sighandler(int signum) #else static void sighandler(int signum) { + signal(SIGPIPE, SIG_IGN); fprintf(stderr, "Signal caught, exiting!\n"); do_exit = 1; rtlsdr_cancel_async(dongle.dev); diff --git a/src/rtl_power.c b/src/rtl_power.c index 6204de2..df3ceb7 100644 --- a/src/rtl_power.c +++ b/src/rtl_power.c @@ -195,6 +195,7 @@ sighandler(int signum) #else static void sighandler(int signum) { + signal(SIGPIPE, SIG_IGN); do_exit++; multi_bail(); } diff --git a/src/rtl_sdr.c b/src/rtl_sdr.c index e6537ca..2c93b57 100644 --- a/src/rtl_sdr.c +++ b/src/rtl_sdr.c @@ -74,6 +74,7 @@ sighandler(int signum) #else static void sighandler(int signum) { + signal(SIGPIPE, SIG_IGN); fprintf(stderr, "Signal caught, exiting!\n"); do_exit = 1; rtlsdr_cancel_async(dev); diff --git a/src/rtl_tcp.c b/src/rtl_tcp.c index 84f5591..8781ba9 100644 --- a/src/rtl_tcp.c +++ b/src/rtl_tcp.c @@ -144,6 +144,7 @@ sighandler(int signum) #else static void sighandler(int signum) { + signal(SIGPIPE, SIG_IGN); fprintf(stderr, "Signal caught, exiting!\n"); rtlsdr_cancel_async(dev); do_exit = 1; diff --git a/src/rtl_test.c b/src/rtl_test.c index 9b44097..b7f46ea 100644 --- a/src/rtl_test.c +++ b/src/rtl_test.c @@ -115,6 +115,7 @@ sighandler(int signum) #else static void sighandler(int signum) { + signal(SIGPIPE, SIG_IGN); fprintf(stderr, "Signal caught, exiting!\n"); do_exit = 1; rtlsdr_cancel_async(dev); -- 2.38.1

2 3

[PATCH] Add support for RFSpace CloudSDR to gr-osmosdr
by Mike McCarrick 06 Dec '22

06 Dec '22

The new-ish RFSpace CloudSDR is mostly the same as the Cloud-IQ, but has a few differences. I’ve tested it thoroughly and it works well. One side note, the CloudSDR (and probably others) require the UDP host port to be set equal to the SDR’s port. This allows multiple CloudSDRs to work simultaneously. That is, a second CloudSDR needs a different IP address, obviously, but also needs a different port, e.g. 50001 rather than the default 50000. Regards, Mike McCarrick

1 0

A Bit Of a Mess
by Kevin Utzy 17 Nov '22

17 Nov '22

I am trying to go back and simply install gqrx on Liux Mint v21 Vanessa (Ubuntu Jammy) using an RTL-SDR V3. It all started I believe when I tried to install SDR++ building it from source. I install osmo_sdr and gr-osmosdr. I have worked my way through and deleted some of the issues, the last one being getting rid of the osmo_sdr binary. Deleting that removed the error I was getting with the libgnuradio-osmosdr.0.2.0 (it was showing libgnuradio-osmosdr.0.2.0 (build 0.3build53 or something). I am now getting an error running gqrx is "gqrx: error while loading shared libraries: libgnuradio-blocks.so.3.10.1: cannot open shared object file: No such file or directory". Some fragment of something I uninstalled incorrectly is causing gqrx distribution to think that this is already installed. If I could figure out what that is, it would be helpful. The reason I am posting this here is because it started I believe when I installed either osmo_sdr or gr-osmosdr. Thank you. Kevin

1 0

Osmocom binary package repository URLs have changed
by Oliver Smith 25 Oct '22

25 Oct '22

Hello various Osmocom mailing lists, as previously announced (https://osmocom.org/news/191): * The binary packages are being built on Osmocom's own OBS server now. * We will stop pushing packages to the openSUSE OBS server at the end of October (in one week). If you are using Osmocom binary packages, please make sure that you have configured the new repository URLs. See the wiki for details: https://osmocom.org/projects/cellular-infrastructure/wiki/Binary_Packages Best, Oliver -- - Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

1 0

RFC: OsmoDevCall restart: Your input required
by Harald Welte 16 Oct '22

16 Oct '22

Dear Osmocom community, your input is required in order to tune the re-launch of the OsmoDevCall talk series. One of the complaints before the suspension in Summer this year was that the "Friday night 8pm CEST" timeslot was not exactly ideal for several people. Finding a common denominator might be difficult, given that Osmocom is a dayjob for some, a hobby for most, and we're of course not all in the same time zone or even continent. So let's try to run a couple of polls to figure out: * What is the best day of the week for OsmoDevCall? https://bitpoll.de/poll/CEQnaQKEvO/ * What is the best time of day for OsmoDevCall? https://bitpoll.de/poll/59dgmzOocT/ * What is the best frequency of OsmoDevCall https://bitpoll.de/poll/8jyuRJB6Hb/ The polls are open until October 21st, 2021. I would appreciate a high turn-out so we have a good representation across our community to make an educated decision about the schedule of futur events. Can't wait to re-start OsmoDevCall! 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)

1 1

← Newer
1
2
3
4
5
6
7
...
91
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr