osmocom-sdr

osmocom-sdr@lists.osmocom.org

2 participants
906 discussions

RFC: Reviving OsmoDevCall
by Harald Welte 25 Jun '22

25 Jun '22

[please follow-up-to openbsc(a)lists.osmocom.org so we don't cross-post all related mails] Dear Osmocom community, OsmoDevCall used to be rather successful for quite some time in recent years, but recently has been suffering quite a bit due to insufficient people volunteering to present. Big thanks to all who did! Interestingly, there's no shortage of ideas of topics at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall - but then many of the potential speakers did not have the interest or time to follow-up. Most recently, the last few instances have not been taking place due to a lack of volunteers during my holidays. Last, but not least, while during COVID lockdown winter "friday night 8pm" was a good idea, this of course is more difficult during the summer, when people are more likely want to go out the weekend. So, to summarize, let me ask some questions: * would you be interested in OsmoDevCall continuing? * which day/time/timezone would you prefer ? * would you be able and willing to volunteer to give at talk within the next 3 or so months? Any other suggestions for or around OsmoDevCall are of course also welcome. Thanks in advance, 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 0

Re: gr-osmosdr build issue (patch included)
by Stefan Oltmanns 20 Jun '22

20 Jun '22

That compiles as well, I removed const as well for a simple reason: The AVX version above doesn't use const and doesn't modify mulme either Am 20.06.22 um 11:18 schrieb Patrick Welche: > (I would just get rid of "register" and not "const" as well) > > P > > On Mon, Jun 20, 2022 at 04:41:20AM +0200, Stefan Oltmanns wrote: >> Hello, >> >> gr-osmosdr currently doesn't build on macOS (probably not with clang in >> general), because C++17 does not allow the "register storage class >> specifier". >> >> The fix is quite trivial: >> >> --- a/lib/hackrf/hackrf_sink_c.cc >> +++ b/lib/hackrf/hackrf_sink_c.cc >> @@ -299,7 +299,7 @@ void convert_avx(const float* inbuf, int8_t* >> outbuf,const unsigned int count) >> #elif USE_SSE2 >> void convert_sse2(const float* inbuf, int8_t* outbuf,const unsigned >> int count) >> { >> - const register __m128 mulme = _mm_set_ps( 127.0f, 127.0f, 127.0f, >> 127.0f ); >> + __m128 mulme = _mm_set_ps( 127.0f, 127.0f, 127.0f, 127.0f ); >> __m128 itmp1,itmp2,itmp3,itmp4; >> __m128i otmp1,otmp2,otmp3,otmp4; >> >> Could you please apply that patch and also create a new release? >> Unfortunately gr-osmosdr was thrown out of the homebrew package earlier >> this year, because it didn't build. >> I would like to get it back in, because that would make things on mac a >> lot easier (and GNURadio tutorials for mac would be correct again and >> not cause frustration). >> >> I assume the easiest way to get it back in is to have a new official >> release that builds again correctly. >> >> Best regards >> Stefan

1 0

gr-osmosdr build issue (patch included)
by Stefan Oltmanns 20 Jun '22

20 Jun '22

Hello, gr-osmosdr currently doesn't build on macOS (probably not with clang in general), because C++17 does not allow the "register storage class specifier". The fix is quite trivial: --- a/lib/hackrf/hackrf_sink_c.cc +++ b/lib/hackrf/hackrf_sink_c.cc @@ -299,7 +299,7 @@ void convert_avx(const float* inbuf, int8_t* outbuf,const unsigned int count) #elif USE_SSE2 void convert_sse2(const float* inbuf, int8_t* outbuf,const unsigned int count) { - const register __m128 mulme = _mm_set_ps( 127.0f, 127.0f, 127.0f, 127.0f ); + __m128 mulme = _mm_set_ps( 127.0f, 127.0f, 127.0f, 127.0f ); __m128 itmp1,itmp2,itmp3,itmp4; __m128i otmp1,otmp2,otmp3,otmp4; Could you please apply that patch and also create a new release? Unfortunately gr-osmosdr was thrown out of the homebrew package earlier this year, because it didn't build. I would like to get it back in, because that would make things on mac a lot easier (and GNURadio tutorials for mac would be correct again and not cause frustration). I assume the easiest way to get it back in is to have a new official release that builds again correctly. Best regards Stefan

1 0

RFC: migrating git.osmocom.org to gitea?
by Harald Welte 31 Mar '22

31 Mar '22

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)

1 1

OsmoDevCall on Mar 25, 2022: "Iridium reverse engineering update"
by Harald Welte 24 Mar '22

24 Mar '22

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)

1 0

OsmoDevCon 2022 ?
by Harald Welte 10 Mar '22

10 Mar '22

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)

2 4

Snap package for RTL-SDR tools
by Alberto Donato 03 Mar '22

03 Mar '22

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

1 1

Using rtl-sdr libraries from scratch
by madoak92＠gmail.com 25 Feb '22

25 Feb '22

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.

1 0

FOSDEM 2022 - Free Software Radio Devroom
by Andrej Rode 05 Feb '22

05 Feb '22

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

1 0

Help on patch submission process for a fix in rtlsdr
by Gonzalo José Carracedo Carballal 04 Feb '22

04 Feb '22

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

2 1

← 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