From Sebastian.Boehm at b-tu.de Tue Dec 1 15:28:46 2020 From: Sebastian.Boehm at b-tu.de (=?UTF-8?Q?Sebastian_B=c3=b6hm?=) Date: Tue, 1 Dec 2020 16:28:46 +0100 Subject: hackrf: gr-osmocom sink tx buffering Message-ID: 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 at b-tu.de P.O. Box: 10 13 44 D-03013 Cottbus GERMANY -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5485 bytes Desc: S/MIME Cryptographic Signature URL: From cuervonicolas at gmail.com Sat Dec 5 10:36:41 2020 From: cuervonicolas at gmail.com (Nicolas Cuervo Benavides) Date: Sat, 5 Dec 2020 11:36:41 +0100 Subject: FOSDEM 2021: Free Software Radio Devroom CfP Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at octobang.com Mon Dec 7 21:48:39 2020 From: rob at octobang.com (Robert Bates (Octobang)) Date: Mon, 7 Dec 2020 16:48:39 -0500 Subject: OsmoBTS with separate Tx and Rx SDRs? Message-ID: 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 at octobang.com https://keybase.io/arpieb From 246tnt at gmail.com Mon Dec 7 23:13:14 2020 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 8 Dec 2020 00:13:14 +0100 Subject: OsmoBTS with separate Tx and Rx SDRs? In-Reply-To: References: Message-ID: > 1. if this kind of setup is even supported It's not. Cheers, Sylvain From phip at devtal.de Tue Dec 8 10:31:43 2020 From: phip at devtal.de (Philipp Psurek) Date: Tue, 08 Dec 2020 11:31:43 +0100 Subject: OsmoBTS with separate Tx and Rx SDRs? In-Reply-To: References: Message-ID: > 1. if this kind of setup is even supported > > It's not. Hi Sylvain, This answer made me curious. Is it because it is not implemented yet or because you need an exact (same) clock for the Rx and Tx part. Or is it because of something else. Thanks in advance for the answer. Kind regards Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From 246tnt at gmail.com Tue Dec 8 10:58:20 2020 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 8 Dec 2020 11:58:20 +0100 Subject: OsmoBTS with separate Tx and Rx SDRs? In-Reply-To: References: Message-ID: Hi, > This answer made me curious. Is it because it is not implemented yet or > because you need an exact (same) clock for the Rx and Tx part. Or is it > because of something else. You need the exact same clock (or at the very least phase locked ones, you could have different sample rates if they are locked you can always resample in software). Then you also need to know absolute time sync (i.e. which sample of TX matches exactly which sample on the RX side). Theses requirements, while not impossible to achieve would impose some hardware modifications to whatever cheap SDR you try to use (like hackrf for TX and RTL-SDR for RX), making it hard to reproduce. It would also required _a_lot_ of work on the software side to deal with all the peculiarities of such a system. And finally there are cheap-ish full duplex SDR. So simply put, there is too high a cost and too low a reward to bother. I mean, if someone has a spare 100kEUR in their couch cushion to finance the dev, I'm sure I can get that implemented. Cheers, Sylvain From rob at octobang.com Tue Dec 8 14:17:37 2020 From: rob at octobang.com (Robert Bates (Octobang)) Date: Tue, 8 Dec 2020 09:17:37 -0500 Subject: OsmoBTS with separate Tx and Rx SDRs? In-Reply-To: References: Message-ID: <264b5bd6-4864-8e92-69e9-7e70a33cc7ea@octobang.com> Thanks for the quick reply.? If you don't mind me asking, what would you recommend as the least expensive option that you know is fully supported by the Osmocomm stack? -Rob On 12/7/2020 6:13 PM, Sylvain Munaut wrote: >> 1. if this kind of setup is even supported > It's not. > > Cheers, > > Sylvain > -- ========== Robert Bates Octobang rob at octobang.com https://keybase.io/arpieb From Sebastian.Boehm at b-tu.de Wed Dec 9 12:23:06 2020 From: Sebastian.Boehm at b-tu.de (=?UTF-8?Q?Sebastian_B=c3=b6hm?=) Date: Wed, 9 Dec 2020 13:23:06 +0100 Subject: hackrf: gr-osmocom sink tx buffering In-Reply-To: References: Message-ID: <0b9d4c0e-eefd-cf5f-c23c-6eb94791a2fc@b-tu.de> Does anyone have any idea what could be the reason for this behavior? Am 01.12.2020 um 16:28 schrieb Sebastian B?hm: > 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 at b-tu.de > > P.O. Box: 10 13 44 > D-03013 Cottbus > GERMANY -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5485 bytes Desc: S/MIME Cryptographic Signature URL: From ewild at sysmocom.de Wed Dec 9 15:39:55 2020 From: ewild at sysmocom.de (Eric Wild) Date: Wed, 9 Dec 2020 16:39:55 +0100 Subject: hackrf: gr-osmocom sink tx buffering In-Reply-To: <0b9d4c0e-eefd-cf5f-c23c-6eb94791a2fc@b-tu.de> References: <0b9d4c0e-eefd-cf5f-c23c-6eb94791a2fc@b-tu.de> Message-ID: <6097eaf0-0f92-599e-7017-b3d3aaeb10e5@sysmocom.de> Hi Sebastian, since the hackrf is half-duplex and has no timestamp support (only continuous streaming) the buffer size was chosen at the time to provide a reasonable tradeoff between latency and performance for higher sample rates - I suppose you could just decrease it if that is the problem, but there is still no way to just send something immediately, there will always be a considerable latency between the host and the rf output. -Eric Am 09.12.2020 um 13:23 schrieb Sebastian B?hm: > > Does anyone have any idea what could be the reason for this behavior? > > Am 01.12.2020 um 16:28 schrieb Sebastian B?hm: >> 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 at b-tu.de >> >> P.O. Box: 10 13 44 >> D-03013 Cottbus >> GERMANY -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sebastian.Boehm at b-tu.de Thu Dec 10 08:06:53 2020 From: Sebastian.Boehm at b-tu.de (=?UTF-8?Q?Sebastian_B=c3=b6hm?=) Date: Thu, 10 Dec 2020 09:06:53 +0100 Subject: hackrf: gr-osmocom sink tx buffering In-Reply-To: <6097eaf0-0f92-599e-7017-b3d3aaeb10e5@sysmocom.de> References: <0b9d4c0e-eefd-cf5f-c23c-6eb94791a2fc@b-tu.de> <6097eaf0-0f92-599e-7017-b3d3aaeb10e5@sysmocom.de> Message-ID: Hi Eric, thanks for your reply! I understand what you mean by the performance aspect, but 'immediately' in my case did not mean that no latency should occur. And I think my problem does not necessarily belong to the size of the buffer. However, I'm surprised that this buffer is only flushed to the Hackrf hardware when it is completely filled, whereas it is actually streamed continuously with 4M samples per second via USB.? This is a major limitation. Here is an example of what I mean: If I create a simple communication protocol in grc where only a response is made by sending a small acknowledgement packet for a request, but otherwise waiting, the osmocom sink will never send this packet because the buffer is not yet full. This inevitably leads to misbehavior in the communication flow. I could adjust the size of the buffer so that it is already completely filled with the smallest of my packets, but his is not a very elegant solution. However, I'll try it! Sebastian Am 09.12.2020 um 16:39 schrieb Eric Wild: > Hi Sebastian, > since the hackrf is half-duplex and has no timestamp support (only > continuous streaming) the buffer size was chosen at the time to > provide a reasonable tradeoff between latency and performance for > higher sample rates - I suppose you could just decrease it if that is > the problem, but there is still no way to just send something > immediately, there will always be a considerable latency between the > host and the rf output. > > -Eric > > Am 09.12.2020 um 13:23 schrieb Sebastian B?hm: >> >> Does anyone have any idea what could be the reason for this behavior? >> >> Am 01.12.2020 um 16:28 schrieb Sebastian B?hm: >>> 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 at b-tu.de >>> >>> P.O. Box: 10 13 44 >>> D-03013 Cottbus >>> GERMANY > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5485 bytes Desc: S/MIME Cryptographic Signature URL: From 246tnt at gmail.com Thu Dec 10 09:15:04 2020 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 10 Dec 2020 10:15:04 +0100 Subject: hackrf: gr-osmocom sink tx buffering In-Reply-To: References: <0b9d4c0e-eefd-cf5f-c23c-6eb94791a2fc@b-tu.de> <6097eaf0-0f92-599e-7017-b3d3aaeb10e5@sysmocom.de> Message-ID: GNuradio is a streaming system by design, you need to insert as many zeros as you need between your bursts (depending on the idle time you want between your bursts). That's inherent to the way GR buffers data between blocks and won't call the work() method until it has "sufficient" data. Cheers, Sylvain From renxianyuanqi at gmail.com Sat Dec 12 07:09:49 2020 From: renxianyuanqi at gmail.com (=?UTF-8?B?6Zuq56KnIDB4cm9vdA==?=) Date: Sat, 12 Dec 2020 15:09:49 +0800 Subject: gr-fosphor didn't work with AMD(R) Radeon graphics Message-ID: 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 at 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 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Sat Dec 12 11:23:51 2020 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sat, 12 Dec 2020 12:23:51 +0100 Subject: gr-fosphor didn't work with AMD(R) Radeon graphics In-Reply-To: References: Message-ID: Hey, > I am using nuc8i7hvk which devices with AMD? Radeon graphics. is it Radeon RX Vega M GH? > [w] CL Error (-1, cl.c:309): Unable to fetch device IDs for platform 0. Skipping. > [!] No suitable OpenCL device found Are you sure you have an OpenCL run-time installed? What does 'clinfo' show? With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From renxianyuanqi at gmail.com Sun Dec 13 03:34:22 2020 From: renxianyuanqi at gmail.com (=?UTF-8?B?6Zuq56KnIDB4cm9vdA==?=) Date: Sun, 13 Dec 2020 11:34:22 +0800 Subject: gr-fosphor didn't work with AMD(R) Radeon graphics In-Reply-To: References: Message-ID: Thanks for your quickly reply > is it Radeon RX Vega M GH? Yes Radeon? RX Vega M graphics > Are you sure you have an OpenCL run-time installed? dpkg -l |grep opencl > ii libopencl1-amdgpu-pro:amd64 20.20-1089974 > amd64 AMD OpenCL ICD Loader library > ii ocl-icd-libopencl1:amd64 2.2.11-1ubuntu1 > amd64 Generic OpenCL ICD Loader > ii ocl-icd-opencl-dev:amd64 2.2.11-1ubuntu1 > amd64 OpenCL development files > ii opencl-amdgpu-pro-comgr 20.20-1089974 > amd64 non-free AMD OpenCL ICD Loaders > ii opencl-amdgpu-pro-icd 20.20-1089974 > amd64 non-free AMD OpenCL ICD Loaders > ii opencl-c-headers > 2.2~2018.02.21-gb5c3680-1 all OpenCL (Open > Computing Language) C header files > ii opencl-clhpp-headers 2.0.10+git12-g5dd8bb9-1 > all C++ headers for OpenCL development > ii opencl-headers > 2.2~2018.02.21-gb5c3680-1 all OpenCL (Open > Computing Language) header files > ii opencl-orca-amdgpu-pro-icd:amd64 20.20-1089974 > amd64 non-free AMD OpenCL ICD Loaders >What does 'clinfo' show? clinfo > Number of platforms: 1 > Platform Profile: FULL_PROFILE > Platform Version: OpenCL 2.1 AMD-APP (3110.6) > Platform Name: AMD Accelerated Parallel Processing > Platform Vendor: Advanced Micro Devices, Inc. > Platform Extensions: cl_khr_icd cl_amd_event_callback > cl_amd_offline_devices > > > Platform Name: AMD Accelerated Parallel Processing > ERROR: clGetDeviceIDs(-1) > Vadim Yanitskiy ?2020?12?12??? ??7:24??? > Hey, > > > I am using nuc8i7hvk which devices with AMD? Radeon graphics. > > is it Radeon RX Vega M GH? > > > [w] CL Error (-1, cl.c:309): Unable to fetch device IDs for platform 0. > Skipping. > > [!] No suitable OpenCL device found > > Are you sure you have an OpenCL run-time installed? > What does 'clinfo' show? > > With best regards, > Vadim Yanitskiy. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From renxianyuanqi at gmail.com Sun Dec 13 03:48:41 2020 From: renxianyuanqi at gmail.com (=?UTF-8?B?6Zuq56KnIDB4cm9vdA==?=) Date: Sun, 13 Dec 2020 11:48:41 +0800 Subject: gr-fosphor didn't work with AMD(R) Radeon graphics In-Reply-To: References: Message-ID: Maybe I know why it doesn't work https://community.amd.com/t5/opencl/fixes-for-amd-installer-ubuntu-16-04-x86-64-dec-30-2017/td-p/135646 export LD_LIBRARY_PATH=/opt/AMDAPPSDK-3.0/lib/x86_64/:/opt/AMDAPPSDK-3.0/lib/x86_64/sdk clinfo works now. clinfo > Number of platforms: 1 > Platform Profile: FULL_PROFILE > Platform Version: OpenCL 2.0 AMD-APP (1800.8) > Platform Name: AMD Accelerated Parallel Processing > Platform Vendor: Advanced Micro Devices, Inc. > Platform Extensions: cl_khr_icd cl_amd_event_callback > cl_amd_offline_devices > > > Platform Name: AMD Accelerated Parallel Processing > Number of devices: 1 > Device Type: CL_DEVICE_TYPE_CPU > Vendor ID: 1002h > Board name: > Max compute units: 8 > Max work items dimensions: 3 > Max work items[0]: 1024 > Max work items[1]: 1024 > Max work items[2]: 1024 > Max work group size: 1024 > Preferred vector width char: 16 > Preferred vector width short: 8 > Preferred vector width int: 4 > Preferred vector width long: 2 > Preferred vector width float: 8 > Preferred vector width double: 4 > Native vector width char: 16 > Native vector width short: 8 > Native vector width int: 4 > Native vector width long: 2 > Native vector width float: 8 > Native vector width double: 4 > Max clock frequency: 3974Mhz > Address bits: 64 > Max memory allocation: 4176266240 > Image support: Yes > Max number of images read arguments: 128 > Max number of images write arguments: 64 > Max image 2D width: 8192 > Max image 2D height: 8192 > Max image 3D width: 2048 > Max image 3D height: 2048 > Max image 3D depth: 2048 > Max samplers within kernel: 16 > Max size of kernel argument: 4096 > Alignment (bits) of base address: 1024 > Minimum alignment (bytes) for any datatype: 128 > Single precision floating point capability > Denorms: Yes > Quiet NaNs: Yes > Round to nearest even: Yes > Round to zero: Yes > Round to +ve and infinity: Yes > IEEE754-2008 fused multiply-add: Yes > Cache type: Read/Write > Cache line size: 64 > Cache size: 32768 > Global memory size: 16705064960 > Constant buffer size: 65536 > Max number of constant args: 8 > Local memory type: Global > Local memory size: 32768 > Max pipe arguments: 16 > Max pipe active reservations: 16 > Max pipe packet size: 4176266240 > Max global variable size: 1879048192 > Max global variable preferred total size: 1879048192 > Max read/write image args: 64 > Max on device events: 0 > Queue on device max size: 0 > Max on device queues: 0 > Queue on device preferred size: 0 > SVM capabilities: > Coarse grain buffer: No > Fine grain buffer: No > Fine grain system: No > Atomics: No > Preferred platform atomic alignment: 0 > Preferred global atomic alignment: 0 > Preferred local atomic alignment: 0 > Kernel Preferred work group size multiple: 1 > Error correction support: 0 > Unified memory for Host and Device: 1 > Profiling timer resolution: 1 > Device endianess: Little > Available: Yes > Compiler available: Yes > Execution capabilities: > Execute OpenCL kernels: Yes > Execute native function: Yes > Queue on Host properties: > Out-of-Order: No > Profiling : Yes > Queue on Device properties: > Out-of-Order: No > Profiling : No > Platform ID: 0x7f39310c5430 > Name: Intel(R) Core(TM) i7-8809G CPU @ 3.10GHz > Vendor: GenuineIntel > Device OpenCL C version: OpenCL C 1.2 > Driver version: 1800.8 (sse2,avx) > Profile: FULL_PROFILE > Version: OpenCL 1.2 AMD-APP (1800.8) > Extensions: cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics > cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics > cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics > cl_khr_int64_extended_atomics cl_khr_3d_image_writes > cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_device_fission > cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops > cl_amd_media_ops2 cl_amd_popcnt cl_khr_spir cl_khr_gl_event > Vadim , Thank you very much. ?? 0xroot ?2020?12?13??? ??11:34??? > Thanks for your quickly reply > > > is it Radeon RX Vega M GH? > Yes Radeon? RX Vega M graphics > > > Are you sure you have an OpenCL run-time installed? > > dpkg -l |grep opencl >> ii libopencl1-amdgpu-pro:amd64 20.20-1089974 >> amd64 AMD OpenCL ICD Loader library >> ii ocl-icd-libopencl1:amd64 2.2.11-1ubuntu1 >> amd64 Generic OpenCL ICD Loader >> ii ocl-icd-opencl-dev:amd64 2.2.11-1ubuntu1 >> amd64 OpenCL development files >> ii opencl-amdgpu-pro-comgr 20.20-1089974 >> amd64 non-free AMD OpenCL ICD Loaders >> ii opencl-amdgpu-pro-icd 20.20-1089974 >> amd64 non-free AMD OpenCL ICD Loaders >> ii opencl-c-headers >> 2.2~2018.02.21-gb5c3680-1 all OpenCL (Open >> Computing Language) C header files >> ii opencl-clhpp-headers 2.0.10+git12-g5dd8bb9-1 >> all C++ headers for OpenCL development >> ii opencl-headers >> 2.2~2018.02.21-gb5c3680-1 all OpenCL (Open >> Computing Language) header files >> ii opencl-orca-amdgpu-pro-icd:amd64 20.20-1089974 >> amd64 non-free AMD OpenCL ICD Loaders > > > >What does 'clinfo' show? > > clinfo >> Number of platforms: 1 >> Platform Profile: FULL_PROFILE >> Platform Version: OpenCL 2.1 AMD-APP (3110.6) >> Platform Name: AMD Accelerated Parallel Processing >> Platform Vendor: Advanced Micro Devices, Inc. >> Platform Extensions: cl_khr_icd cl_amd_event_callback >> cl_amd_offline_devices >> >> >> Platform Name: AMD Accelerated Parallel Processing >> ERROR: clGetDeviceIDs(-1) >> > > > > > > Vadim Yanitskiy ?2020?12?12??? ??7:24??? > >> Hey, >> >> > I am using nuc8i7hvk which devices with AMD? Radeon graphics. >> >> is it Radeon RX Vega M GH? >> >> > [w] CL Error (-1, cl.c:309): Unable to fetch device IDs for platform 0. >> Skipping. >> > [!] No suitable OpenCL device found >> >> Are you sure you have an OpenCL run-time installed? >> What does 'clinfo' show? >> >> With best regards, >> Vadim Yanitskiy. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sebastian.Boehm at b-tu.de Wed Dec 16 15:22:39 2020 From: Sebastian.Boehm at b-tu.de (=?UTF-8?Q?Sebastian_B=c3=b6hm?=) Date: Wed, 16 Dec 2020 16:22:39 +0100 Subject: hackrf: gr-osmocom sink tx buffering In-Reply-To: References: <0b9d4c0e-eefd-cf5f-c23c-6eb94791a2fc@b-tu.de> <6097eaf0-0f92-599e-7017-b3d3aaeb10e5@sysmocom.de> Message-ID: Thanks for your advise! Now i pad my message with zeroes so that the hackrf buffer is completely filled. This works perfectly! Am 10.12.2020 um 10:15 schrieb Sylvain Munaut: > GNuradio is a streaming system by design, you need to insert as many > zeros as you need between your bursts (depending on the idle time you > want between your bursts). > That's inherent to the way GR buffers data between blocks and won't > call the work() method until it has "sufficient" data. > > Cheers, > > Sylvain -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5485 bytes Desc: S/MIME Cryptographic Signature URL: From adrian at freebsd.org Wed Dec 16 19:07:49 2020 From: adrian at freebsd.org (Adrian Chadd) Date: Wed, 16 Dec 2020 11:07:49 -0800 Subject: [PATCH] [hackrf] Fix hackrf receive hangs by checking before each lock wait Message-ID: <20201216190749.6605-1-adrian@freebsd.org> 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 #include +#include #include @@ -203,8 +204,15 @@ int hackrf_source_c::work( int noutput_items, { std::unique_lock 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 From cuervonicolas at gmail.com Mon Dec 21 04:44:07 2020 From: cuervonicolas at gmail.com (Nicolas Cuervo Benavides) Date: Mon, 21 Dec 2020 05:44:07 +0100 Subject: FOSDEM 2021: Free Software Radio Devroom CfP In-Reply-To: References: Message-ID: Dear friends and fans of software-defined radio, the Free Software Radio DevRoom track at next year's FOSDEM still has some slots left! We already have some submissions and we are in the process of ranking those, but we will gladly add YOUR presentation to the list! If you have anything related to the field of free software radio, please head to: https://penta.fosdem.org/submission/FOSDEM21 and submit your short abstract! We're looking very much forward to your submission. For the committee, Nicolas On Sat, Dec 5, 2020 at 11:36 AM Nicolas Cuervo Benavides < cuervonicolas at gmail.com> wrote: > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at osmocom.org Thu Dec 31 11:04:45 2020 From: laforge at osmocom.org (Harald Welte) Date: Thu, 31 Dec 2020 12:04:45 +0100 Subject: Idea for 2021: Regular "OsmoDevCall" Message-ID: 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)