osmocom-sdr October 2018

osmocom-sdr@lists.osmocom.org

14 participants
15 discussions

by Michael Auß

CC to mailing list ------- Weitergeleitete Nachricht ------ Von: Michael Auß <michael.auss(a)gmail.com> Datum: Fr. 19. Okt. 2018 um 22:26 Betreff: Re: [PATCH] Related: OS#3663 Fix failed compilation on macOS Mojave with clang in CMakeLists.txt An: Greg Troxel <gdt(a)lexort.com> I did encounter problems with syntax errors when compiling with clang, see OS#3663 for details. (Relating to rtl_tcp) I did not add something to the README. KR Michael Greg Troxel <gdt(a)lexort.com> schrieb am Fr. 19. Okt. 2018 um 21:44: > Michael Auß <michael.auss(a)gmail.com> writes: > > > Fix regarding the issue https://osmocom.org/issues/3663macOS Mojave > > comes with clang but the binary matches by the name c++ instead of > > clang.Additionally the compiler flag std=c++14 had to be added. > > I am surprised about c++14. Is it new that c++14 is required? Is it > in the README? > > gr-osmosdr is at 0.1.4 in pkgsrc, which appears to be the latest > official release on github. It's marked as needing "c++" which means > 03, not 11, and not 14. >

6 years, 4 months

by Michael Auß

Fix regarding the issue https://osmocom.org/issues/3663 <https://osmocom.org/issues/3663> macOS Mojave comes with clang but the binary matches by the name c++ instead of clang. Additionally the compiler flag std=c++14 had to be added.

6 years, 4 months

Save the Date: OsmoCon 2018 on October 18-19, 2018

by Harald Welte

== OsmoCon 2018 == OsmoCon (Osmocom Conference) 2018 is the technical conference for Osmocom users, operators and developers! We are happy to announce the date of OsmoCon 2018. It has been scheduled on October 18 + 19, 2018 and will happen in Berlin, Germany. For the second time, the Osmocom Conference brings together users, operators and developers of the Osmocom Open Source cellular infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN and others. Join us for two days of presentations and discussions with the main developers behind Open Source Mobile Communications, as well as commercial and non-profit users of the Osmocom cellular infrastructure software. You can find some initial information in our wiki at http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018 which will be updated as more information becomes available. == Call for Participation == We're also at the same time announcing the Call for Participation and call on everyone with experiences to share around the Osmocom member projects to submit talks, workshops, discussions or other proposals. You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp We are particularly looking for contributions about: * updates on features/functionality/status of individual Osmocom projects * success stories on how Osmocom projects are deployed in practice * migration from OsmoNITB to the post-NITB architecture * tutorials / workshops on how to setup / analyze Osmocom projects * statistics, reporting, operations aspects of Osmocom projects * third-party open source utilities to be used with Osmocom projects Looking forward to meeting many existing and new Osmocom users at OsmCon this October! Regards, Harald Welte -- - 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)

6 years, 5 months

fl2k_test sample rate speeds up on Windows

by Francesco Gugliuzza

Hi, I encountered this strange behavior when running fl2k_test on Windows 7: basically after a while the sample rate drifts and speeds up considerably. Sometimes it even starts up directly like that. In the command prompt I get: C:\Users\Francesco Gugliuzza\Downloads\Sviluppo\FL2000fl2k_win_2018-08-09>fl2k_test.exe -s 138e6 Reporting PPM error measurement every 10 seconds... Press ^C after a few minutes. real sample rate: 146656386 current PPM: 62727 cumulative PPM: 62727 real sample rate: 150803676 current PPM: 92780 cumulative PPM: 77858 real sample rate: 149716182 current PPM: 84900 cumulative PPM: 80218 real sample rate: 150107883 current PPM: 87738 cumulative PPM: 82104 real sample rate: 150526750 current PPM: 90774 cumulative PPM: 83843 The same thing happens if I compile the latest osmo-fl2k myself using Cygwin. I'm running everything on a laptop with an i7 4710HQ CPU and 8 GB of ram, and I'm using a RayCue HDMI+VGA box. Do you have an idea why the real sample rate drifts so much? Thanks! Francesco -- Francesco Gugliuzza M.Sc. in Computer Engineering Ph.D. Student at DIID, Università degli Studi di Palermo Qualified to practice as a Professional Engineer E-mail: fgugliuzza.mail(a)gmail.com PEC: francesco.gugliuzza(a)pec.it

6 years, 5 months

librtlsdr segfault from race

by Karl Semich

Reproducible segfault apparently from race condition on my system in librtlsdr. --- $ uname -r 4.14.67-1.pvops.qubes.x86_64 rtl-sdr and libusb are both current git master. --- 1. run librtlsdr under gdb $ gdb --args rtl_sdr -f 43M -n 1000 /dev/null 2. place a breakpoint when the cancellation condition is hit, currently line 1915 1914 if (RTLSDR_CANCELING == dev->async_status) { 1915 next_status = RTLSDR_INACTIVE; 1916 (gdb) break ./src/librtlsdr.c:1915 3. run and continue; segfault after second breakpoint (gdb) run (gdb) cont (gdb) cont Thread 1 "rtl_sdr" received signal SIGSEGV, Segmentation fault. 0x00007ffff7d76a15 in add_to_flying_list (transfer=0x426590) at ../../libusb/io.c:1396 1396 if (!timerisset(cur_tv) || (cur_tv->tv_sec > timeout->tv_sec) || -- The crash appears to be because the transfers are deallocated while they are still in flight, and then later referenced by libusb. I think this happens because the pause gives the transfer time to complete before it is canceled. The cancel then fails because the transfer was completed, and the current code assumes this means it is not in flight, when it actually hasn't been handled yet and will be resubmitted. The documentation for libusb_transfer::status at http://libusb.sourceforge.net/api-1.0/structlibusb__transfer.html#a64b2e70e… states that it is only correct to read the field from within the callback handler, and the documentation for libusb_cancel_transfer at http://libusb.sourceforge.net/api-1.0/group__asyncio.html#ga685eb7731f9a059… states that the transfer cancellation is only complete when the callback handler is called with such status. Although I imagine there are simpler solutions, I think the correct solution would be to move cancellation of the transfers into the callback handler entirely, to eliminate race conditions like this and respect the libusb documentation. I would enjoy crafting a patch to make such a change, if that would be helpful. Karl Semich

6 years, 5 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr October 2018