December 2020 - osmocom-sdr - lists.osmocom.org

gr-osmosdr: add clock_source= parameter
by Michael Loeffler 26 Mar '21

26 Mar '21

Hello, the attached patch allows to set the clock_source on uhd devices in programs like gqrx. Bye

1 1

Idea for 2021: Regular "OsmoDevCall"
by Harald Welte 25 Mar '21

25 Mar '21

Dear Osmocom community, as the pandemic continues and physical meetings are out of the question for the forseeable future, it would be a good idea to have a periodic virtual online meeting of the interested Osmocom community. I was thinking of a format where we would serve two major purposes: 1) technical talks about osmocom relevant topics - ideally current/recent developments * can be pre-recorded to avoid any problems with technical setup, streaming, ... * should ideally have a Q+A session at their initial "airing" during one OsmoDevCall 2) unstructured solicited social event (USSE) * random chat in audio (optionally video) * not recorded, obviously The recording of the technical presentation should then be permanently made available (like the presentations of our prior OsmoCon / OsmoDevCon). Not every OsmoDevCall would neccessarily need the two parts, but I think it would be great if we can make that happen. We could also have e.g. a two-weekly schedule for the USSE and a monthly schedule for the technical presentation. We'd need somebody to volunteer to "manage" the "broadcast" side of this, preferably somebody with at least some prior exposure to online events (like the c3voc). I'm using https://osmocom.org/issues/4928 to collect a tentative list of topics. Feel free to add your ideas there, as well as any comment/ feedback you may have. 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)

1 4

FOSDEM 2021: Free Software Radio Devroom CfP
by Nicolas Cuervo Benavides 21 Dec '20

21 Dec '20

Dear friends and fans of software-defined radio and free/open-source radio topics in general, FOSDEM 2021 (the free and open-source developer's meeting usually in Brussels, Europe but **this time virtually**) will again feature a track on Software Defined Radio and any other radio-related topics in the Free Software Radio devroom. Therefore, we invite developers and users from the free software radio community to join us for this track and present your talks or demos. Given the current circumstances and the virtual nature of this event in 2021, we are asking the presenters to pre-record the talks, which will then be gathered by us and streamed during the event. Presenters are also asked to be present online during their timeslot for live Q&A. Software Radio has become an important tool to allow anyone to access the EM spectrum. Using free software radio libraries and applications and cheap hardware, anyone can now start hacking on wireless communications, remote sensing, radar, fun hacks of all sorts, or other applications. At FOSDEM, we hope to network all these projects, and improve collaboration, bring new ideas forward and get more people involved. The track's website resides at the link below. The final schedule will be available through Pentabarf and the official FOSDEM website. Notice that the reference time will be Brussels local time (CET). https://fosdem.org/2021/schedule/track/free_software_radio/ Additional Information will be also available at: https://wiki.gnuradio.org/index.php/FOSDEM_2021 ** Submit your presentations To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM21 and follow the instructions (you need an account, but can use your account from last year if you have one. Please do NOT create a new account if you already have one). You need to create an 'Event'; make sure it's in the Free Software Radio track! Your submission should have the following information: * Your contact Email * A descriptive title and subtitle of your talk * A short abstract * Links related to the project * [Optional] A longer description of the content of your talk. Lengths aren't fixed, but give a realistic estimate, and please don't exceed 30 minutes unless you have something special planned (in that case, contact one of us). We will typically go for 30-minute slots -- shorter talks, unless they're really short, usually tend to screw up the schedule too much. You aren't limited to slide presentations, of course. Be creative. However, FOSDEM is an open-source conference, therefore we ask you to stay clear of marketing presentations and present something relevant to free/open software. We like nitty-gritty technical stuff. Topics discussed in this devroom include: * SDR Frameworks + Tools * Cellular/telecoms software * Free/Open SDR hardware * Wireless security * Random fun wireless hacks * SDR in education * Satellite/spacecraft communication * Ham radio related topics ** Important Dates * Submission deadline: 26 December 2020 * Announcement of selected talks: 31 December 2020 * Conference dates 6 & 7 February 2021 online * Free software radio devroom date: Sunday 7 February 2021 online In the last years we were always full to the brim with presentations, so if you want to present, please make sure to submit your abstracts soon! ** Following steps for accepted talks When your talk is accepted, you will be contacted by a deputy who will help you with the pre-recording of your talk. Together you will make sure that the content has the required quality and is stream-ready. When complete, the recording will be located into the streaming system, and Bob's your uncle. Don't forget that you **must** be available during the allocated timeslot of your talk for live Q&A. ** Steering Committee The track committee consists of: * Phil Balister - "Crofton" * Derek Kozel - "dkozel" * Nicolas Cuervo - "primercuervo" * Martin Braun - "mbr0wn" Hope to hear from you soon! And please forward this announcement. - Nicolas

1 1

[PATCH] [hackrf] Fix hackrf receive hangs by checking before each lock wait
by Adrian Chadd 16 Dec '20

16 Dec '20

Fix receive path hangs if another thread closes down the hackrf receive whilst this buffer receive function is waiting to be woken up. Now: * Sleep for up to 100ms each time waiting for the cond to be kicked; * Check whether streaming is still enabled each time rather than only when the function is entered. This fixes hangs where consumers like gqrx via gnuradio will do a stop_rx/start_rx very quickly to change something, and the buffer receive path is waiting for a buffer. --- lib/hackrf/hackrf_source_c.cc | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/lib/hackrf/hackrf_source_c.cc b/lib/hackrf/hackrf_source_c.cc index 662d04a..03ea3bd 100644 --- a/lib/hackrf/hackrf_source_c.cc +++ b/lib/hackrf/hackrf_source_c.cc @@ -30,6 +30,7 @@ #include <stdexcept> #include <iostream> +#include <chrono> #include <gnuradio/io_signature.h> @@ -203,8 +204,15 @@ int hackrf_source_c::work( int noutput_items, { std::unique_lock<std::mutex> lock(_buf_mutex); - while (_buf_used < 3 && running) // collect at least 3 buffers - _buf_cond.wait( lock ); + while (_buf_used < 3 && running) { // collect at least 3 buffers + _buf_cond.wait_for( lock , std::chrono::milliseconds(100)); + + // Re-check whether the device has closed or stopped streaming + if ( _dev.get() ) + running = (hackrf_is_streaming( _dev.get() ) == HACKRF_TRUE); + else + running = false; + } } if ( ! running ) -- 2.28.0

1 0

hackrf: gr-osmocom sink tx buffering
by Sebastian Böhm 16 Dec '20

16 Dec '20

Hi, i try to transmit 2.48 ghz radio packets (beacons) at a fixed time interval (e.g. every 1 s) via hackrf using the osmocom sink in gnuradio. Without exception, the beacons are all received by my sniffer "golden device" hardware, but burst. It seems that the packets are only transferred via USB to the hackrf device hardware when the buffer with the fixed BUF_LEN 262144 (32*16*512) is completely filled. For my setup this are e.g. 18 beacon frames, which are transmitted as burst. When I look at the USB interface, I can see this burst of data every 18 seconds in a full USB request block (URB) of size 262144 byte. All other URBs (also of size 262144 - every approx. 200us) transferred via USB are filled with zeros only. So this burst behavior should be caused by gnuradio. How can I achieve that the complex data of the osmocom sink's input is immediately (with the next URB) transferred to the hackrf hardware? Am I missing any options of the GRC module? Thank You in advance! Regards, Sebastian -- __________________________________________________________ Sebastian Boehm Brandenburg University of Technology Cottbus - Senftenberg Computer Networks Communication Systems Group E-Mail: sebastian.boehm(a)b-tu.de <mailto:Sebastian.Boehm@b-tu.de> P.O. Box: 10 13 44 D-03013 Cottbus GERMANY

3 5

gr-fosphor didn't work with AMD(R) Radeon graphics
by 雪碧 0xroot 13 Dec '20

13 Dec '20

Hi osmocom community, I am using nuc8i7hvk which devices with AMD® Radeon graphics. And build gnuradio 3.7.14 gr-fosphor gr3.7 when I run osmocom_fft -F > linux; GNU C++ version 7.5.0; Boost_106501; > UHD_003.010.000.heads-release_003_010_000_000-0-g6e1ac3fc > gr-osmosdr 0.1.5 (0.1.5) gnuradio 3.7.14.0 > built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace > airspy soapy redpitaya > Using AirSpy MINI v1.0.0-rc10-0-g946184a 2016-09-19, samplerates: 3M 6M > Airspy decim:1 kernel size:47 > -1 -1 > [w] CL Error (-1, /home/init3/SDR/gr-fosphor/lib/fosphor/cl.c:309): Unable > to fetch device IDs for platform 0. Skipping. > [!] No suitable OpenCL device found > > OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO^C I try run lib fosphor : /gr-fosphor/lib/fosphor$ ./main > -1 -1 > [w] CL Error (-1, cl.c:309): Unable to fetch device IDs for platform 0. > Skipping. > [!] No suitable OpenCL device found > [!] Failed to initialize fosphor What should I do to make it work fine? There is some infomation maybe helpful Kernel 5.4.1-050401-lowlatency lspci | grep VGA > 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] > Polaris 22 [Radeon RX Vega M GH] (rev c0) inxi -G > Graphics: Card: Advanced Micro Devices [AMD/ATI] Polaris 22 [Radeon RX > Vega M GH] > Display Server: x11 (X.Org 1.19.6 ) > drivers: fbdev,ati (unloaded: modesetting,vesa,radeon) > Resolution: 3840x2160(a)60.00hz > OpenGL: renderer: AMD Radeon Graphics version: 4.6.14736 20.20 > lshw -c video > WARNING: you should run this program as super-user. > *-display > description: VGA compatible controller > product: Polaris 22 [Radeon RX Vega M GH] > vendor: Advanced Micro Devices, Inc. [AMD/ATI] > physical id: 0 > bus info: pci@0000:01:00.0 > version: c0 > width: 64 bits > clock: 33MHz > capabilities: vga_controller bus_master cap_list rom > configuration: driver=amdgpu latency=0 > resources: iomemory:200-1ff iomemory:210-20f irq:172 > memory:2000000000-20ffffffff memory:2100000000-21001fffff > ioport:e000(size=256) memory:dba00000-dba3ffff memory:c0000-dffff > WARNING: output may be incomplete or inaccurate, you should run this > program as super-user. Thanks ---------------------------------------------------------------- 0xroot

2 3

OsmoBTS with separate Tx and Rx SDRs?
by Robert Bates (Octobang) 08 Dec '20

08 Dec '20

Hello list! I've been digging a bit into the osmo-bts project to explore the GSM stack, and only ever see config information assuming you have a full-duplex TRX radio. I have a HackRF One I'd like to use for TX and an RTL-SDR I'd like to use for RX (both operating on the 900MHz GSM band), but cannot seem to find any configuration information for setting this up - even though I've seen some mentions in passing to osmo-bts-trx supporing RTL-SDR devices. I really don't have the budget to drop a few hundred more on a USRP device just to tinker with GSM and was hoping I could get away with two dedicated radios. Can anyone tell me 1. if this kind of setup is even supported and 2. if so, point me to reference material that might help me make the connection? Thanks in advance! -Rob -- ========== Robert Bates Octobang rob(a)octobang.com https://keybase.io/arpieb

3 4