osmocom-sdr

osmocom-sdr@lists.osmocom.org

1 participants
910 discussions

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

07 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 17 Oct '22

17 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

RFC: Reviving OsmoDevCall
by Harald Welte 26 Jun '22

26 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 01 Apr '22

01 Apr '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 25 Mar '22

25 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 11 Mar '22

11 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

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr