osmocom-sdr

osmocom-sdr@lists.osmocom.org

903 discussions

RFC: migrating git.osmocom.org to gitea?

by Harald Welte

Hi all! [please follow-up-to the openbsc(a)lists.osmocom.org mailing list, if there is any discussion, we don't want to drag it over tons of mailing lists in parallel] Some weeks ago, I created https://osmocom.org/issues/5397 but it seems nobody noticed the ticket or had any comments to it. So let me post this as RFC here on the mailing list: In the past, we had a gitolite/gitosis setup, which was fine in the early days of git, but it means that people cannot easily create new repositories, see who has permissions, and we cannot delegate ownership. Even updating SSH keys requires manual interaction of a sysadmin like me. I would therefore suggest to migrate git.osmocom.org to gitea[1] This would allow the following features: * users can self-create any number of personal repositories (like gitlab/github) * we can create 'organizations' along the line of reasonably independent osmocom member projects like op25, who can then manage their own repos/permissions/... * gitea can link to redmine wiki and redmine issue trackers (rather than using its own built-in) For those repositories hosted in gerrit (mainly CNI), we would still keep git.osmocom.org a read-only mirror, like we do it right now. For those repositories not hosted in gerrit, users/projects could then accept merge requests in gitea. Coupling this with 3rd party authentication via github/gitlab/etc should make it easier for the occasional contributor to submit changes. There is a downside, of course; A lot of repo URLs have to change. Most of our current repositories are at git.osmocom.org/project.git while gitea follows a git.osmocom.org/organization/project.git scheme. I'm not sure there is any way to help to mitigate this... Any thoughts, comments? [1] https://gitea.io/ -- - 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)

3 years, 2 months

OsmoDevCall on Mar 25, 2022: "Iridium reverse engineering update"

by Harald Welte

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall on March 25, 2022 at 20:00 CET at https://meeting5.franken.de/b/har-xbc-bsx-wvs In this edition, Sec and schneider will present an "Iridium reverse engineering update". 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. NOTE: There will be no recording of this talk, so if interested, please make sure you don't miss it! 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 on Friday. 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)

3 years, 2 months

OsmoDevCon 2022 ?

by Harald Welte

Dear fellow Osmocom developers, as you all know, we've sadly had to skip OsmoDevCon 2020 and 2021, trying to compensate it at least to some extent with our OsmoDevCall every two weeks. The COVID-19 pandemic is far from over, and we don't know what the upcoming winter season will bring. Nevertheless, I think it would be a good idea to start a discussion of whether we should plan for an OsmoDevCon in 2022. I personally would say let's plan for the usual late April 2022 time frame, and if the pandemic situation deteriorates, we can still cancel it with something like one month lead time. I would also personally suggest to limit attendance to people who are fully vaccinated, and in addition do a self-test for all participants every morning. In terms of venue, we might also consider to move to a venue that allows better ventilation. Irrespective of the above we can also bring the air filters from the sysmocom office. So with that as an input statement, I would like to hear your opinion on the above proposals. Who would want to attend? Any complaints against the "vaccinated only plus daily self-tests in the morning" approach? Regards, Harald -- - 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)

3 years, 3 months

Snap package for RTL-SDR tools

by Alberto Donato

Hi, I made a snap [1] package for the RTL-SDR tools. The package has "strict" confinement, which allows installing it on any supported distro. I tested it on Ubuntu 21.10 (on amd64) and Ubuntu Core on a Raspberry Pi (my main use case for the packaging is to be able to run rtl_tcp on the latter). Would you consider merging this to the repo and possibly publishing snap packages on the Snap Store as part of the regular release process? Cheers, -Alberto [1] https://snapcraft.io/docs

3 years, 3 months

Using rtl-sdr libraries from scratch

by madoak92＠gmail.com

Hi everyone! I'm so interested about using the rtl-sdr libraries for creating some own applications, but am a bit lost concerning the code structure and the interaction between cmake and the libraries. I have some background in C programming, but I haven't write any code as complicated, and nor of course have I had to use tools like cmake to distribute code, only I've used some Makefiles in order to compile locally a basic code. With this background, I'm trying to manage antenna switches within an array, but I need some new functionalities in the rtl_biast.c code. For this purpose, I have to use the following functions: rtlsdr_set_bias_tee rtlsdr_set_i2c_repeater rtlsdr_i2c_write_reg rtlsdr_close_bt I have modified the code but when I execute cmake and make again, I obtain errors regarding the file dependencies, saying that these functions are undeclared. How should I change the file dependencies/include and recompile it in order to make it works? Could you help me to understand the compilation process in order to arrange my own applications using rtl-sdr libraries locally? I assume I have to study thoroughly the cmake and make advanced topics, but it's a bit overwhelming and I would like to learn about it constructing the code from the basic pieces. Thank you very much in advance.

3 years, 3 months

FOSDEM 2022 - Free Software Radio Devroom

by Andrej Rode

Hi all, I’d like to invite you all to join the Free Software Radio Devroom at the FOSDEM 2022 online event tomorrow February 6th 2022 at 1300 (CET). We have a range of very interesting presentations ranging from project updates, implementation of hardware accelerators for Software Radio up to receiving communication from the most distant artificial object from Earth. You can find the full schedule here: https://fosdem.org/2022/schedule/track/free_software_radio/ You can either join just the livestream of the event, but I really encourage you to join the Matrix chat to ask questions you might have and continue discussion about the presentation after it is finished, you can even join the video call for a more direct way of communication. You can find information about the chat system here: https://fosdem.org/2022/practical/online/. If you are already a member of the GNU Radio Matrix server, you don’t have to create a new account or anything. You can simply visit: https://matrix.to/#/#space-radio-devroom:fosdem.org to join the dedicated "Free Software Radio Devroom space". This space contains the main chatroom during the devroom but also you will find all dedicated presentation chatrooms in there after the presentation has finished to continue in-depth discussion. During the presentation you can ask questions in the chat and upvote questions of others, at the end of the presentation there will be a short live Q&A where a presentation host will address said questions directly to the presenter. If your question is not answered during this time you are welcome to join the presentation chatroom to ask yourself. I hope to “see” many of you tomorrow. And a big thanks for everyone presenting or helping to make this Devroom possible this year! Cheers Andrej

3 years, 4 months

Help on patch submission process for a fix in rtlsdr

by Gonzalo José Carracedo Carballal

Hi, Long story short: I have a fix for a crash in Windows in librtlsdr when closing the device, and I'd love to submit a patch. I went through this page: https://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards and saw that I have to follow certain steps (design, review, etc) but I am not quite sure who to contact. For some projects, this is somehow automatized by means of Gerrit, but it looks that this is not the case for librtlsdr (yet) I'd like to do it the right way, how should I proceed? Should I post the patch here directly? Do I have to document the design of my fix and have it reviewed first somewhere else? Bit of backstory: some days ago I came across a crash in librtlsdr for Windows when closing the device (initially reported as a potential libusb bug, see https://github.com/libusb/libusb/issues/1043). Although workarounds existed (https://github.com/TALUAtGitHub/librtlsdr/commit/27d79d258c0fffb73afd3fffd3…) they relied on a somewhat arbitrary (1 ms) delay to give some time for libusb event callbacks to be triggered before resource cleanup. This was not working anymore, so I decided to look into it and ended up working on a solution. This solution involved refactoring the transfer / buffer array into an array of transfer objects that enabled synchronous cancellation of pending transfers (see https://github.com/BatchDrake/rtl-sdr-blog/blob/feature/xfer-completion/src…). Since it seems to work rather well, I though it could be interesting to submit a patch to have this fixed upstream. Thanks in advance, -- >> Gonzalo José Carracedo Carballal

3 years, 4 months

[PATCH] call libsub_intertrupt_event_handler in rtlsdr_cancel_async

by Jasper

Please find below a patch as per suggestion of Martin Ling: call libusb_interrupt_event_handler in rtlsdr_cancel_async to trigger the event loop handler to look at the async_cancel variable. (https://lists.osmocom.org/hyperkitty/list/osmocom-sdr@lists.osmocom.org/thr…) I have tested timings on a windows 11 machine with and without the patch when running a async transfer at two different sampling rates: sample rate with without theory 1536K 0 - 2 ms 0 - 84 ms 85 ms 288K 0 - 4 ms 0 - 457 ms 455 ms The table shows the range of timings to cancel the async transfer as measured over a couple of runs. The "theory" column shows the theoretical time to complete one transfer at the particular sampling rate (i.e. driven by the size of a transfer buffer). And indeed, on some machines it appears that cancelling the async transfer, if unlucky, can take as much time as waiting for a full transfer to complete. The call to libsub_intertrupt_event_handler fixes that. For large transfer buffers and/or low sample rates this can make a difference. Thanks to Martin for sharing the insight. Jasper Author: jvde.github <jvde.github(a)gmail.com> Date: Wed Jan 26 19:00:55 2022 +0100 call interrupt_event_handler in cancel_async diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 67e30c4..b949692 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -1948,6 +1948,9 @@ int rtlsdr_cancel_async(rtlsdr_dev_t *dev) if (RTLSDR_RUNNING == dev->async_status) { dev->async_status = RTLSDR_CANCELING; dev->async_cancel = 1; + + libusb_interrupt_event_handler(dev->ctx); + return 0; }

3 years, 4 months

[PATCH] count number of open transfers and ensure zero open transfers before freeing memory

by Jasper

Hi all, As per discussion with Martin Ling on this mailing list, please find below a proposed patch that simplifies the async_read, keeps track of open tranfers and checks for zero open transfers before closing to avoid unidentified behaviour at close. Thanks, Jasper commit 4b06ae321e91296f13355a0715e9a961b4f57e45 Author: jvde.github <jvde.github(a)gmail.com> Date: Mon Jan 24 20:15:34 2022 +0100 count live transfers before close diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 096abae..67e30c4 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -119,6 +119,7 @@ struct rtlsdr_dev { int dev_lost; int driver_active; unsigned int xfer_errors; + int live_transfers; }; void rtlsdr_set_gpio_bit(rtlsdr_dev_t *dev, uint8_t gpio, int val); @@ -1695,11 +1696,15 @@ static void LIBUSB_CALL _libusb_callback(struct libusb_transfer *xfer) { rtlsdr_dev_t *dev = (rtlsdr_dev_t *)xfer->user_data; + dev->live_transfers --; + if (LIBUSB_TRANSFER_COMPLETED == xfer->status) { if (dev->cb) dev->cb(xfer->buffer, xfer->actual_length, dev->cb_ctx); - libusb_submit_transfer(xfer); /* resubmit transfer */ + if(!dev->async_cancel) + if( libusb_submit_transfer(xfer) == 0) /* resubmit transfer */ + dev->live_transfers++; dev->xfer_errors = 0; } else if (LIBUSB_TRANSFER_CANCELLED != xfer->status) { #ifndef _WIN32 @@ -1847,9 +1852,9 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, { unsigned int i; int r = 0; + int ret = 0; struct timeval tv = { 1, 0 }; - struct timeval zerotv = { 0, 0 }; - enum rtlsdr_async_status next_status = RTLSDR_INACTIVE; + struct timeval canceltv = { 0, 50 }; if (!dev) return -1; @@ -1863,6 +1868,7 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, dev->cb = cb; dev->cb_ctx = ctx; + if (buf_num > 0) dev->xfer_buf_num = buf_num; else @@ -1875,6 +1881,8 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, _rtlsdr_alloc_async_buffers(dev); + dev->live_transfers = 0; + for(i = 0; i < dev->xfer_buf_num; ++i) { libusb_fill_bulk_transfer(dev->xfer[i], dev->devh, @@ -1894,64 +1902,41 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, "echo 0 > /sys/module/usbcore" "/parameters/usbfs_memory_mb\n", i); dev->async_status = RTLSDR_CANCELING; + ret = -3; break; } + else + dev->live_transfers++; } - while (RTLSDR_INACTIVE != dev->async_status) { + while (RTLSDR_RUNNING == dev->async_status) { r = libusb_handle_events_timeout_completed(dev->ctx, &tv, - &dev->async_cancel); + &dev->async_cancel); if (r < 0) { /*fprintf(stderr, "handle_events returned: %d\n", r);*/ if (r == LIBUSB_ERROR_INTERRUPTED) /* stray signal */ continue; - break; + rtlsdr_cancel_async(dev); + ret = -4; } + } - if (RTLSDR_CANCELING == dev->async_status) { - next_status = RTLSDR_INACTIVE; + if (!dev->xfer) return -5; - if (!dev->xfer) - break; + for(i = 0; i < dev->xfer_buf_num; ++i) + if (dev->xfer[i]) + libusb_cancel_transfer(dev->xfer[i]); - for(i = 0; i < dev->xfer_buf_num; ++i) { - if (!dev->xfer[i]) - continue; + for (i = 0; i < dev->xfer_buf_num && dev->live_transfers > 0; ++i) + libusb_handle_events_timeout_completed(dev->ctx, &canceltv, NULL); - if (LIBUSB_TRANSFER_CANCELLED != - dev->xfer[i]->status) { - r = libusb_cancel_transfer(dev->xfer[i]); - /* handle events after canceling - * to allow transfer status to - * propagate */ -#ifdef _WIN32 - Sleep(1); -#endif - libusb_handle_events_timeout_completed(dev->ctx, - &zerotv, NULL); - if (r < 0) - continue; - - next_status = RTLSDR_CANCELING; - } - } - - if (dev->dev_lost || RTLSDR_INACTIVE == next_status) { - /* handle any events that still need to - * be handled before exiting after we - * just cancelled all transfers */ - libusb_handle_events_timeout_completed(dev->ctx, - &zerotv, NULL); - break; - } - } - } + if(dev->live_transfers > 0) return -6; _rtlsdr_free_async_buffers(dev); - dev->async_status = next_status; + dev->async_status = RTLSDR_INACTIVE; - return r; + return ret; } int rtlsdr_cancel_async(rtlsdr_dev_t *dev)

3 years, 4 months

[PATCH] librtlsdr: force wait state after lib_cancel_transfer to avoid crash on close in windows

by Jasper van den Eshof

Good day! I was struggling with an occasional crash of the rtl-sdr tools on windows when closing the device after pressing CTRL-C. Both with the versions as provided with VCPKG and when directly compiling the latest version in MSVC (with latest of libusb). It is a bit difficult to spot a crash at close as usually it is silent but you can see it running it from MSVC or in a debugger. It does not happen always but frequent enough. Also, consider this example for the binary versions from Jan 2 (https://ftp.osmocom.org/binaries/windows/rtl-sdr/): C:\>rtl_adsb.exe Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000001 Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner .... Signal caught, exiting! User cancel, exiting... C:\>echo %ERRORLEVEL% -1073741819 After investigation of the libusb logs and experimentation I think this crash can be avoided by 1) defining zerotv in rtlsdr_read_async as 1 ms instead of zero (see libusb/libusb#1043) or 2) include a short call to Sleep to allow async operations to finish. Please find below a patch for the latter fix for your consideration. More information, here: https://github.com/osmocom/rtl-sdr/pull/18 and here: https://github.com/libusb/libusb/issues/1043 Thanks for your great work on the rtlsdr library and kind regards. Author: jvde.github <jvde.github(a)gmail.com> Date: Sat Jan 8 13:30:34 2022 +0100 force wait state after cancel of usb transfer and before handling usb events diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 0146298..2682d77 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -1930,6 +1930,9 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, /* handle events after canceling * to allow transfer status to * propagate */ +#ifdef _WIN32 + Sleep(1); +#endif libusb_handle_events_timeout_completed(dev->ctx, &zerotv, NULL); if (r < 0)

3 years, 4 months

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr