From admin at rtl-sdr.com Mon Oct 1 03:42:11 2018 From: admin at rtl-sdr.com (Carl Laufer) Date: Mon, 1 Oct 2018 16:42:11 +1300 Subject: Librtlsdr zerocopy buffers not working on Tinkerboard Armbian Message-ID: I've been trying to get some RTL-SDRs to function properly on my Tinkerboard, running Armbian Bionic, Kernel 4.14y. I noticed that with the Osmocom drivers rtl_test would result in huge sample drops (millions of samples dropped each time). However, Keenerds branch did not drop any samples, nor did the presumably older Osmocom drivers from apt-get. I did a diff against Keenerds and discovered the new zerocopy buffer code in the Osmocom drivers. After commenting that out, the Osmocom drivers work fine on the Tinkerboard with Armbian and there is no sample loss. Strangely, on TinkerOS and Ubuntu OS for Tinkerboard, all of which run Kernel 4.4, I do not get sample loss with the Osmocom drivers and the zerocopy code enabled. I'm also running the Osmocom drivers on an Odroid XU4 with Ubuntu which is also running Kernel 4.14, and on Raspbian, and on those there is no sample loss. So it seems to be something specific to the Tinkerboard and Armbian with Kernel 4.14y. Not sure if the zerocopy code is just not getting activated on those other OSes or what. How do I check if the installed libusb API version is >= 0x01000105? Any ideas what could cause the zero copy code to result in the lost samples? Regards, Carl Laufer -------------- next part -------------- An HTML attachment was scrubbed... URL: From 0xloem at gmail.com Mon Oct 1 20:22:36 2018 From: 0xloem at gmail.com (Karl Semich) Date: Mon, 1 Oct 2018 16:22:36 -0400 Subject: Librtlsdr zerocopy buffers not working on Tinkerboard Armbian In-Reply-To: References: Message-ID: Hey, You can find the libusb version with e.g. `dpkg-query -W libusb-*`. The api version you're asking about is LIBUSB_API_VERSION in libusb.h, which is usually in /usr/include/libusb-1.0/libusb.h, or you can find it with `pkg-config --cflags libusb-1.0`. Karl Semich On 9/30/18, Carl Laufer wrote: > I've been trying to get some RTL-SDRs to function properly on my > Tinkerboard, running Armbian Bionic, Kernel 4.14y. I noticed that with the > Osmocom drivers rtl_test would result in huge sample drops (millions of > samples dropped each time). However, Keenerds branch did not drop any > samples, nor did the presumably older Osmocom drivers from apt-get. > > I did a diff against Keenerds and discovered the new zerocopy buffer code > in the Osmocom drivers. After commenting that out, the Osmocom drivers work > fine on the Tinkerboard with Armbian and there is no sample loss. > > Strangely, on TinkerOS and Ubuntu OS for Tinkerboard, all of which run > Kernel 4.4, I do not get sample loss with the Osmocom drivers and the > zerocopy code enabled. > > I'm also running the Osmocom drivers on an Odroid XU4 with Ubuntu which is > also running Kernel 4.14, and on Raspbian, and on those there is no sample > loss. So it seems to be something specific to the Tinkerboard and Armbian > with Kernel 4.14y. > > Not sure if the zerocopy code is just not getting activated on those other > OSes or what. How do I check if the installed libusb API version is >= > 0x01000105? > > Any ideas what could cause the zero copy code to result in the lost > samples? > > Regards, > Carl Laufer > From steve at steve-m.de Mon Oct 1 21:28:56 2018 From: steve at steve-m.de (Steve Markgraf) Date: Mon, 1 Oct 2018 23:28:56 +0200 Subject: Librtlsdr zerocopy buffers not working on Tinkerboard Armbian In-Reply-To: References: Message-ID: Hi Carl, On 01.10.2018 05:42, Carl Laufer wrote: > I did a diff against Keenerds and discovered the new zerocopy buffer > code in the Osmocom drivers. After commenting that out, the Osmocom > drivers work fine on the Tinkerboard with Armbian and there is no sample > loss. That's very strange, because from an rtl-sdr point of view it is just regular memory that was allocated by the Kernel (and happens to be DMA-able) and mapped into userspace. So my first guess is that something must be going wrong either inside the Kernel or libusb. > Strangely, on TinkerOS and Ubuntu OS for Tinkerboard, all of which run > Kernel 4.4, I do not get sample loss with the Osmocom drivers and the > zerocopy code enabled. Yes, as 4.4 doesn't support usbfs zerocopy. > I'm also running the Osmocom drivers on an Odroid XU4 with Ubuntu which > is also running Kernel 4.14, and on Raspbian, and on those there is no > sample loss. So it seems to be something specific to the Tinkerboard and > Armbian with Kernel 4.14y. > > Not sure if the zerocopy code is just not getting activated on those > other OSes or what. How do I check if the installed libusb API version > is >= 0x01000105? I've put that information into the commit message: > Requires Linux >= 4.6 and libusb >= 1.0.21. (https://cgit.osmocom.org/rtl-sdr/commit/?id=a854ae8b48d42e8dad514c75d3a4c6cfb62707da) So it's enabled if both versions are there. > Any ideas what could cause the zero copy code to result in the lost samples? Do you get any error messages when the library is loaded? What is the value of /sys/module/usbcore/parameters/usbfs_memory_mb, and can you try to increase it or set it to 0 to disable the limit? Was the Kernel built with CONFIG_CMA=y, and what is the value of CONFIG_CMA_SIZE_MBYTES? If any of this isn't right, there normally should appear a warning and "falling back to buffers in userspace" when starting the application, but maybe there is something going wrong... Regards, Steve From admin at rtl-sdr.com Tue Oct 2 04:22:14 2018 From: admin at rtl-sdr.com (Carl Laufer) Date: Tue, 2 Oct 2018 17:22:14 +1300 Subject: Librtlsdr zerocopy buffers not working on Tinkerboard Armbian In-Reply-To: References:

Message-ID: I did some more tests. I upgraded the OS on my Odroid XU4 to Ubuntu 18.04, and this has libusb 1.0.21 in the repo's (the previous one I was using had libusb 1.0.20). Now I get the same continuous lost sample bytes problem on the XU4 as on the Tinkerboard - a huge amount of dropped samples with zerocopy enabled. However, on the latest Raspbian on the Rpi3, I don't see the problem. On the Pi3 rtl_test returns only one line of dropped samples, then no more. Allocating 15 zero-copy buffers lost at least 156 bytes On the Odroid and Tinkerboard it's more like: Allocating 15 zero-copy buffers lost at least 13617588 bytes lost at least 12326518 bytes lost at least 13208366 bytes lost at least 13301044 bytes ...and so on forever No other error messages are seen, and disabling the usbfs_memory_mb limit by setting it to zero doesn't get rid of the problem. I'm not too sure about the CMA stuff, i'm just using the default OS images provided for the Tinkerboard and XU4, and standard Ubuntu 18.04 on my laptop. Regards, Carl Laufer On Tue, Oct 2, 2018 at 10:28 AM Steve Markgraf wrote: > Hi Carl, > > On 01.10.2018 05:42, Carl Laufer wrote: > > I did a diff against Keenerds and discovered the new zerocopy buffer > > code in the Osmocom drivers. After commenting that out, the Osmocom > > drivers work fine on the Tinkerboard with Armbian and there is no sample > > loss. > > That's very strange, because from an rtl-sdr point of view it is just > regular memory that was allocated by the Kernel (and happens to be > DMA-able) and mapped into userspace. So my first guess is that something > must be going wrong either inside the Kernel or libusb. > > > Strangely, on TinkerOS and Ubuntu OS for Tinkerboard, all of which run > > Kernel 4.4, I do not get sample loss with the Osmocom drivers and the > > zerocopy code enabled. > > Yes, as 4.4 doesn't support usbfs zerocopy. > > > I'm also running the Osmocom drivers on an Odroid XU4 with Ubuntu which > > is also running Kernel 4.14, and on Raspbian, and on those there is no > > sample loss. So it seems to be something specific to the Tinkerboard and > > Armbian with Kernel 4.14y. > > > > Not sure if the zerocopy code is just not getting activated on those > > other OSes or what. How do I check if the installed libusb API version > > is >= 0x01000105? > > I've put that information into the commit message: > > > Requires Linux >= 4.6 and libusb >= 1.0.21. > > ( > https://cgit.osmocom.org/rtl-sdr/commit/?id=a854ae8b48d42e8dad514c75d3a4c6cfb62707da > ) > > So it's enabled if both versions are there. > > > Any ideas what could cause the zero copy code to result in the lost > samples? > > Do you get any error messages when the library is loaded? What is the > value of /sys/module/usbcore/parameters/usbfs_memory_mb, and can you try > to increase it or set it to 0 to disable the limit? > > Was the Kernel built with CONFIG_CMA=y, and what is the value of > CONFIG_CMA_SIZE_MBYTES? > > If any of this isn't right, there normally should appear a warning and > "falling back to buffers in userspace" when starting the application, > but maybe there is something going wrong... > > Regards, > Steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 0xloem at gmail.com Fri Oct 5 12:30:29 2018 From: 0xloem at gmail.com (Karl Semich) Date: Fri, 5 Oct 2018 08:30:29 -0400 Subject: Librtlsdr zerocopy buffers not working on Tinkerboard Armbian In-Reply-To: References:

Message-ID: Hey, I just wanted to offer, if time and energy is short, I'd be willing to spend some time narrowing down this issue, given shell access to one of the failing systems. Sounds like a bug in either the kernel or libusb. Karl On 10/2/18, Carl Laufer wrote: > I did some more tests. I upgraded the OS on my Odroid XU4 to Ubuntu 18.04, > and this has libusb 1.0.21 in the repo's (the previous one I was using had > libusb 1.0.20). Now I get the same continuous lost sample bytes problem on > the XU4 as on the Tinkerboard - a huge amount of dropped samples with > zerocopy enabled. > > However, on the latest Raspbian on the Rpi3, I don't see the problem. On > the Pi3 rtl_test returns only one line of dropped samples, then no more. > > Allocating 15 zero-copy buffers > lost at least 156 bytes > > On the Odroid and Tinkerboard it's more like: > > Allocating 15 zero-copy buffers > lost at least 13617588 bytes > lost at least 12326518 bytes > lost at least 13208366 bytes > lost at least 13301044 bytes > ...and so on forever > > No other error messages are seen, and disabling the usbfs_memory_mb limit > by setting it to zero doesn't get rid of the problem. > > I'm not too sure about the CMA stuff, i'm just using the default OS images > provided for the Tinkerboard and XU4, and standard Ubuntu 18.04 on my > laptop. > > Regards, > Carl Laufer > > On Tue, Oct 2, 2018 at 10:28 AM Steve Markgraf wrote: > >> Hi Carl, >> >> On 01.10.2018 05:42, Carl Laufer wrote: >> > I did a diff against Keenerds and discovered the new zerocopy buffer >> > code in the Osmocom drivers. After commenting that out, the Osmocom >> > drivers work fine on the Tinkerboard with Armbian and there is no >> > sample >> > loss. >> >> That's very strange, because from an rtl-sdr point of view it is just >> regular memory that was allocated by the Kernel (and happens to be >> DMA-able) and mapped into userspace. So my first guess is that something >> must be going wrong either inside the Kernel or libusb. >> >> > Strangely, on TinkerOS and Ubuntu OS for Tinkerboard, all of which run >> > Kernel 4.4, I do not get sample loss with the Osmocom drivers and the >> > zerocopy code enabled. >> >> Yes, as 4.4 doesn't support usbfs zerocopy. >> >> > I'm also running the Osmocom drivers on an Odroid XU4 with Ubuntu which >> > is also running Kernel 4.14, and on Raspbian, and on those there is no >> > sample loss. So it seems to be something specific to the Tinkerboard >> > and >> > Armbian with Kernel 4.14y. >> > >> > Not sure if the zerocopy code is just not getting activated on those >> > other OSes or what. How do I check if the installed libusb API version >> > is >= 0x01000105? >> >> I've put that information into the commit message: >> >> > Requires Linux >= 4.6 and libusb >= 1.0.21. >> >> ( >> https://cgit.osmocom.org/rtl-sdr/commit/?id=a854ae8b48d42e8dad514c75d3a4c6cfb62707da >> ) >> >> So it's enabled if both versions are there. >> >> > Any ideas what could cause the zero copy code to result in the lost >> samples? >> >> Do you get any error messages when the library is loaded? What is the >> value of /sys/module/usbcore/parameters/usbfs_memory_mb, and can you try >> to increase it or set it to 0 to disable the limit? >> >> Was the Kernel built with CONFIG_CMA=y, and what is the value of >> CONFIG_CMA_SIZE_MBYTES? >> >> If any of this isn't right, there normally should appear a warning and >> "falling back to buffers in userspace" when starting the application, >> but maybe there is something going wrong... >> >> Regards, >> Steve >> > From steve at steve-m.de Tue Oct 9 19:21:13 2018 From: steve at steve-m.de (Steve Markgraf) Date: Tue, 9 Oct 2018 21:21:13 +0200 Subject: Librtlsdr zerocopy buffers not working on Tinkerboard Armbian In-Reply-To: References:

Message-ID: <1fdf87ad-c7e9-7eb5-66a1-4d54fcffbb80@steve-m.de> Hi, so it turned out that this is indeed a Kernel issue. I have implemented a crude workaround for both rtl-sdr and osmo-fl2k to detect the bug, and fall back to buffers in userspace if it is present. I've sent the mail below to the linux-usb list, but didn't get any reply so far. Let's see. -- When I debugged the issue, I found out that the Kernel maps seemingly random memory to my transfer buffers, containing memory of other processes or even the Kernel itself. The code that does the mapping in drivers/usb/core/devio.c: (line 243 in v4.19-rc7) > if (remap_pfn_range(vma, vma->vm_start, > virt_to_phys(usbm->mem) >> PAGE_SHIFT, > size, vma->vm_page_prot) < 0) { With the following change the issue is fixed for ARM systems, but it breaks x86 systems: - virt_to_phys(usbm->mem) >> PAGE_SHIFT, + page_to_pfn(virt_to_page(dma_addr)), Both usbm->mem and dma_addr are returned by the previous call to usb_alloc_coherent(). Here's an example of the pointers generated by the two macros on an ARM64 system for the same buffer: virt_to_phys(usbm->mem) >> PAGE_SHIFT: 00000000808693ce page_to_pfn(virt_to_page(dma_addr)): 000000009775a856 >From what I read so far I got the impression that the 'proper' way would be to use dma_mmap_coherent() with dma_addr instead of remap_pfn_range(), however, I did not get it to work. Can anyone help out? Best Regards, Steve Markgraf From 0xloem at gmail.com Tue Oct 9 22:33:37 2018 From: 0xloem at gmail.com (Karl Semich) Date: Tue, 9 Oct 2018 18:33:37 -0400 Subject: librtlsdr segfault from race Message-ID: 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#a64b2e70e76d52a7cd23daa3cd4fb397e 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#ga685eb7731f9a0593f75beb99727bbe54 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 From michael.auss at gmail.com Fri Oct 19 19:14:17 2018 From: michael.auss at gmail.com (=?utf-8?Q?Michael_Au=C3=9F?=) Date: Fri, 19 Oct 2018 21:14:17 +0200 Subject: [PATCH] Related: OS#3663 Fix failed compilation on macOS Mojave with clang in CMakeLists.txt Message-ID: <49F14F0F-8DA3-43DD-966D-50AEE7A0E146@gmail.com> Fix regarding the issue 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-support-for-the-macOS-Mojave-clang-based-compile.patch Type: application/octet-stream Size: 1141 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Fri Oct 19 19:44:10 2018 From: gdt at lexort.com (Greg Troxel) Date: Fri, 19 Oct 2018 15:44:10 -0400 Subject: [PATCH] Related: OS#3663 Fix failed compilation on macOS Mojave with clang in CMakeLists.txt In-Reply-To: <49F14F0F-8DA3-43DD-966D-50AEE7A0E146@gmail.com> ("Michael =?utf-8?Q?Au=C3=9F=22's?= message of "Fri, 19 Oct 2018 21:14:17 +0200") References: <49F14F0F-8DA3-43DD-966D-50AEE7A0E146@gmail.com> Message-ID: Michael Au? 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. From michael.auss at gmail.com Fri Oct 19 20:27:35 2018 From: michael.auss at gmail.com (=?UTF-8?B?TWljaGFlbCBBdcOf?=) Date: Fri, 19 Oct 2018 22:27:35 +0200 Subject: Fwd: [PATCH] Related: OS#3663 Fix failed compilation on macOS Mojave with clang in CMakeLists.txt In-Reply-To: References: <49F14F0F-8DA3-43DD-966D-50AEE7A0E146@gmail.com>

Message-ID: CC to mailing list ------- Weitergeleitete Nachricht ------ Von: Michael Au? 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 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 schrieb am Fr. 19. Okt. 2018 um 21:44: > Michael Au? 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Fri Oct 19 23:45:42 2018 From: gdt at lexort.com (Greg Troxel) Date: Fri, 19 Oct 2018 19:45:42 -0400 Subject: [PATCH] Related: OS#3663 Fix failed compilation on macOS Mojave with clang in CMakeLists.txt In-Reply-To: ("Michael =?utf-8?Q?Au=C3=9F=22's?= message of "Fri, 19 Oct 2018 22:26:48 +0200") References: <49F14F0F-8DA3-43DD-966D-50AEE7A0E146@gmail.com>

Message-ID: Michael Au? writes: > 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. I can certainly believe you had errors. But, changing the compiler requirement is significant -- particularly on platforms that don't have last week's compiler -- and if it isn't the plan to require C++14, then it seems like a workaround to enable that. My point really is that there should be a decision about the language, that should be in the README, and the build system should set --std for that chosen language, and then whatever needs to be fixed should be fixed. From gdt at lexort.com Sat Oct 20 00:18:18 2018 From: gdt at lexort.com (Greg Troxel) Date: Fri, 19 Oct 2018 20:18:18 -0400 Subject: branches, releases Message-ID: (I am one of several who look after ham/gnuradio stuff in pkgsrc.) In gr-osmosdr, it seems 0.1.4 is the most recently release, long ago. The v0.1.4 tarball seems to build aginst gnuradio 3.7. There is a gr3.6 branch that has both many commits more than and less than the v3.6 tag. master has 127 commits beyond v0.1.4 but is not missing any. This seems odd, as I would expect gr3.6 to be based on some intermediate commit along the path from 0.1.4 to master. So I am not following what is going on and why. Now that gnuradio 3.7 seems normal, it seems there should be a release based on master, and there is no real reason for anyone to use the 3.6 branch (unless they are on a system that is intentionally using old gnuradio). Can somebody explain? With any luck I'm confused. Greg From fgugliuzza.mail at gmail.com Sat Oct 20 00:20:44 2018 From: fgugliuzza.mail at gmail.com (Francesco Gugliuzza) Date: Sat, 20 Oct 2018 02:20:44 +0200 Subject: fl2k_test sample rate speeds up on Windows Message-ID: 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 Gugliuzza -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.auss at gmail.com Sat Oct 20 08:36:07 2018 From: michael.auss at gmail.com (=?utf-8?Q?Michael_Au=C3=9F?=) Date: Sat, 20 Oct 2018 10:36:07 +0200 Subject: [PATCH] Related: OS#3663 Fix failed compilation on macOS Mojave with clang in CMakeLists.txt In-Reply-To: References: <49F14F0F-8DA3-43DD-966D-50AEE7A0E146@gmail.com>

Message-ID: <747003D1-90EB-4849-9D1C-D14E2D36F692@gmail.com> > Am 20.10.2018 um 01:45 schrieb Greg Troxel : > My point really is that there should be a decision about the language, that should be in the > README, and the build system should set --std for that chosen language, > and then whatever needs to be fixed should be fixed. I only added the flag for compilers based on the existing pattern *.clang and my new pattern matching "c++?. So the Build system is setting the language only for clang at this point. I tested the output for c++98 which resulted in the bugs original errors: [ 61%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/rtl_tcp/rtl_tcp_source_c.cc.o /Users/aussmich/Projekte/gr-osmosdr/lib/rtl_tcp/rtl_tcp_source_c.cc:301:9: error: expected expression cmd = { 0x09, htonl(direct_samp) }; ^ /Users/aussmich/Projekte/gr-osmosdr/lib/rtl_tcp/rtl_tcp_source_c.cc:307:9: error: expected expression cmd = { 0x0a, htonl(offset_tune) }; ^ /Users/aussmich/Projekte/gr-osmosdr/lib/rtl_tcp/rtl_tcp_source_c.cc:311:9: error: expected expression cmd = { 0x0e, htonl(bias_tee) }; ^ /Users/aussmich/Projekte/gr-osmosdr/lib/rtl_tcp/rtl_tcp_source_c.cc:570:9: error: expected expression cmd = { 0x08, htonl(automatic) }; ^ In file included from /Users/aussmich/Projekte/gr-osmosdr/lib/rtl_tcp/rtl_tcp_source_c.cc:30: In file included from /Users/aussmich/Projekte/gr-osmosdr/lib/rtl_tcp/rtl_tcp_source_c.h:23: In file included from /usr/local/Cellar/gnuradio/3.7.13.4/include/gnuradio/sync_block.h:27: In file included from /usr/local/Cellar/gnuradio/3.7.13.4/include/gnuradio/block.h:29: /usr/local/Cellar/gnuradio/3.7.13.4/include/gnuradio/logger.h:766:16: warning: private field 'd_logger' is not used [-Wunused-private-field] logger_ptr d_logger; ^ 1 warning and 4 errors generated. make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/rtl_tcp/rtl_tcp_source_c.cc.o] Error 1 make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2 make: *** [all] Error 2 I then tried c++11 which compiles just fine, so the minimum language required for this file is c++11 and not c++14 as stated in my patch. From michael.auss at gmail.com Sat Oct 20 08:46:52 2018 From: michael.auss at gmail.com (=?utf-8?Q?Michael_Au=C3=9F?=) Date: Sat, 20 Oct 2018 10:46:52 +0200 Subject: [PATCH] Related: OS#3663 Fix failed compilation on macOS Mojave with clang in CMakeLists.txt In-Reply-To: <747003D1-90EB-4849-9D1C-D14E2D36F692@gmail.com> References: <49F14F0F-8DA3-43DD-966D-50AEE7A0E146@gmail.com>

<747003D1-90EB-4849-9D1C-D14E2D36F692@gmail.com> Message-ID: PS: C++11 defined list initialization: https://en.cppreference.com/w/cpp/language/list_initialization > Am 20.10.2018 um 10:36 schrieb Michael Au? : > >> Am 20.10.2018 um 01:45 schrieb Greg Troxel : >> My point really is that there should be a decision about the language, that should be in the >> README, and the build system should set --std for that chosen language, >> and then whatever needs to be fixed should be fixed. > > > > I only added the flag for compilers based on the existing pattern *.clang and my new pattern matching "c++?. > So the Build system is setting the language only for clang at this point. > > I tested the output for c++98 which resulted in the bugs original errors: > > [ 61%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/rtl_tcp/rtl_tcp_source_c.cc.o > /Users/aussmich/Projekte/gr-osmosdr/lib/rtl_tcp/rtl_tcp_source_c.cc:301:9: error: expected expression > cmd = { 0x09, htonl(direct_samp) }; > ^ > /Users/aussmich/Projekte/gr-osmosdr/lib/rtl_tcp/rtl_tcp_source_c.cc:307:9: error: expected expression > cmd = { 0x0a, htonl(offset_tune) }; > ^ > /Users/aussmich/Projekte/gr-osmosdr/lib/rtl_tcp/rtl_tcp_source_c.cc:311:9: error: expected expression > cmd = { 0x0e, htonl(bias_tee) }; > ^ > /Users/aussmich/Projekte/gr-osmosdr/lib/rtl_tcp/rtl_tcp_source_c.cc:570:9: error: expected expression > cmd = { 0x08, htonl(automatic) }; > ^ > In file included from /Users/aussmich/Projekte/gr-osmosdr/lib/rtl_tcp/rtl_tcp_source_c.cc:30: > In file included from /Users/aussmich/Projekte/gr-osmosdr/lib/rtl_tcp/rtl_tcp_source_c.h:23: > In file included from /usr/local/Cellar/gnuradio/3.7.13.4/include/gnuradio/sync_block.h:27: > In file included from /usr/local/Cellar/gnuradio/3.7.13.4/include/gnuradio/block.h:29: > /usr/local/Cellar/gnuradio/3.7.13.4/include/gnuradio/logger.h:766:16: warning: private field 'd_logger' is not used [-Wunused-private-field] > logger_ptr d_logger; > ^ > 1 warning and 4 errors generated. > make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/rtl_tcp/rtl_tcp_source_c.cc.o] Error 1 > make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2 > make: *** [all] Error 2 > > > > I then tried c++11 which compiles just fine, so the minimum language required for this file is c++11 and not c++14 as stated in my patch. > > > > From gdt at lexort.com Mon Oct 22 23:49:38 2018 From: gdt at lexort.com (Greg Troxel) Date: Mon, 22 Oct 2018 19:49:38 -0400 Subject: [PATCH] Related: OS#3663 Fix failed compilation on macOS Mojave with clang in CMakeLists.txt In-Reply-To: <747003D1-90EB-4849-9D1C-D14E2D36F692@gmail.com> ("Michael =?utf-8?Q?Au=C3=9F=22's?= message of "Sat, 20 Oct 2018 10:36:07 +0200") References: <49F14F0F-8DA3-43DD-966D-50AEE7A0E146@gmail.com>

<747003D1-90EB-4849-9D1C-D14E2D36F692@gmail.com> Message-ID: Michael Au? writes: > I only added the flag for compilers based on the existing pattern *.clang and my new pattern matching "c++?. > So the Build system is setting the language only for clang at this point. So this is not really about your change, but it seems that the modern C++ world is complicated enough and various compilers have various defaults (which itself seems buggy), so my point is that we should be setting --std always (to a value that matches what the README says is needed), rather than special casing which is building up a record of defaults that don't work. > I tested the output for c++98 which resulted in the bugs original > errors: And there is c++03. But if it really needs C++11, that's how it is. The last release does not, but it seems master and the last release are very far apart. From steve at steve-m.de Tue Oct 23 17:00:31 2018 From: steve at steve-m.de (Steve Markgraf) Date: Tue, 23 Oct 2018 19:00:31 +0200 Subject: fl2k_test sample rate speeds up on Windows In-Reply-To: References: Message-ID: Hi, On 20.10.2018 02:20, Francesco Gugliuzza wrote: > 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. Hm, I haven't seen this on Linux so far. Would be interesting to see if only the time measurement goes wrong (could be caused by CPU frequency scaling etc.), or if something is actually going wrong with the device or transfers. fl2k_test outputs a rectangle signal, do you have an oscilloscope or an SDR you could use to check if the signal disappears when the measured sample rate starts to get strange? Regards, Steve From fgugliuzza.mail at gmail.com Wed Oct 24 22:27:56 2018 From: fgugliuzza.mail at gmail.com (Francesco Gugliuzza) Date: Thu, 25 Oct 2018 00:27:56 +0200 Subject: fl2k_test sample rate speeds up on Windows In-Reply-To: References:

Message-ID: Hi, Il giorno mar 23 ott 2018 alle ore 19:00 Steve Markgraf ha scritto: > Hi, > > On 20.10.2018 02:20, Francesco Gugliuzza wrote: > > 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. > > Hm, I haven't seen this on Linux so far. Would be interesting to see if > only the time measurement goes wrong (could be caused by CPU frequency > scaling etc.), or if something is actually going wrong with the device > or transfers. > My two cents is that something is up with the actual data transmission, because I'm quite sure that the output signal gets corrupted or shifted out of frequency. The CPU is set to maximum performance, but turbo boost could effectively bring the frequency up by 200-300 MHz. I'm on a laptop with an i7 4710HQ. > > fl2k_test outputs a rectangle signal, do you have an oscilloscope or an > SDR you could use to check if the signal disappears when the measured > sample rate starts to get strange? > Yes, I have a RTL-SDR, but I can't get my hands on it until next week. I will update you when I will manage to perform some tests. I can try on a live Linux distro if fl2k_test works correctly there, though. > > Regards, > Steve > Thank you! Regards, Francesco -- Francesco Gugliuzza -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbsalty at yahoo.com Sun Oct 28 15:26:24 2018 From: mbsalty at yahoo.com (MB) Date: Sun, 28 Oct 2018 15:26:24 +0000 (UTC) Subject: RTL_SDR dongle not being working with gnuradio References: <1868336601.17712153.1540740384658.ref@mail.yahoo.com> Message-ID: <1868336601.17712153.1540740384658@mail.yahoo.com> I have a rtl_sdr.com RTL2832U R820T2 dongle. It works with HDSDR and SDRSHARP programs. Using win10 64 BIT 10.0.17134.345 and GNURadio 3.7.13.4/V1.5Windows reports VID_0BDA, PID_2838 When I run GNUradio, I get [R82XX] PLL not locked! When I open the GNUradio command prompt and run rtl_test -t, I get this: setting gnuradio environmentMicrosoft Windows [Version 10.0.17134.345] (c) 2018 Microsoft Corporation. All rights reserved. C:\Program Files\GNURadio-3.7\bin>rtl_test -t Found 1 device(s): ? 0:? Realtek, RTL2838UHIDIR, SN: 00000001 Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6 Sampling at 2048000 S/s. No E4000 tuner found, aborting. C:\Program Files\GNURadio-3.7\bin> At this page, https://osmocom.org/projects/rtl-sdr/wiki/Rtl-sdr shows this table : VID ? ? ? PID???????????tuner ? ? ? ? ? device name 0x0bda 0x2832???? all of them ? ? ? Generic RTL2832U (e.g. hama nano) 0x0bda 0x2838 ? ? ?? E4000???????? ezcap USB 2.0 DVB-T/DAB/FM dongle Is it possible RTL_TEST is looking for a E4000 because of it's dongle's screwy PID, even though it sees a R820T.? If not, why is it not working?thanks. | | Virus-free. www.avast.com | -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmkarl at gmail.com Mon Oct 1 20:21:36 2018 From: gmkarl at gmail.com (Karl) Date: Mon, 01 Oct 2018 20:21:36 -0000 Subject: Librtlsdr zerocopy buffers not working on Tinkerboard Armbian In-Reply-To: References: Message-ID: Hey, You can find the libusb version with e.g. `dpkg-query -W libusb-*`. The api version you're asking about is LIBUSB_API_VERSION in libusb.h, which is usually in /usr/include/libusb-1.0/libusb.h, or you can find it with `pkg-config --cflags libusb-1.0`. Karl Semich On 9/30/18, Carl Laufer wrote: > I've been trying to get some RTL-SDRs to function properly on my > Tinkerboard, running Armbian Bionic, Kernel 4.14y. I noticed that with the > Osmocom drivers rtl_test would result in huge sample drops (millions of > samples dropped each time). However, Keenerds branch did not drop any > samples, nor did the presumably older Osmocom drivers from apt-get. > > I did a diff against Keenerds and discovered the new zerocopy buffer code > in the Osmocom drivers. After commenting that out, the Osmocom drivers work > fine on the Tinkerboard with Armbian and there is no sample loss. > > Strangely, on TinkerOS and Ubuntu OS for Tinkerboard, all of which run > Kernel 4.4, I do not get sample loss with the Osmocom drivers and the > zerocopy code enabled. > > I'm also running the Osmocom drivers on an Odroid XU4 with Ubuntu which is > also running Kernel 4.14, and on Raspbian, and on those there is no sample > loss. So it seems to be something specific to the Tinkerboard and Armbian > with Kernel 4.14y. > > Not sure if the zerocopy code is just not getting activated on those other > OSes or what. How do I check if the installed libusb API version is >= > 0x01000105? > > Any ideas what could cause the zero copy code to result in the lost > samples? > > Regards, > Carl Laufer > From fgugliuzza.mail at gmail.com Sun Oct 14 12:34:10 2018 From: fgugliuzza.mail at gmail.com (Francesco Gugliuzza) Date: Sun, 14 Oct 2018 14:34:10 +0200 Subject: fl2k_test sample rate speeds up on Windows Message-ID: 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 at gmail.com PEC: francesco.gugliuzza at pec.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From b.mafakheri at fbk.eu Tue Oct 16 15:45:27 2018 From: b.mafakheri at fbk.eu (Babak Mafakheri) Date: Tue, 16 Oct 2018 17:45:27 +0200 Subject: OSMOCOM-fft Message-ID: <5bc60798.1c69fb81.17e7f.3eb3@mx.google.com> Dear all, I am confused about some parameters of osmocom fft spectrum analyzer. I am wonder what exactly the vertical axis shows? It is written Power(dB); if so, what is the reference power? Is it 1dBW? Moreover, by changing the PGA Gain, I will have different values of power (dB). What is the relation between PGA gain and the received power in dBm? In general, does anyone know how should I find the received power in dBm, having the PGA gain(dB) and the value on vertical axis. (Picture in attach) Looking forward to your reply. Bests, -- -- Le informazioni contenute nella presente comunicazione sono di natura? privata e come tali sono da considerarsi riservate ed indirizzate? esclusivamente ai destinatari indicati e per le finalit? strettamente? legate al relativo contenuto. Se avete ricevuto questo messaggio per? errore, vi preghiamo di eliminarlo e di inviare una comunicazione? all?indirizzo e-mail del mittente. -- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 7A62FC0691E84F3DBB915498AF022C2C.png Type: image/png Size: 93321 bytes Desc: not available URL: From felix.ontanon at podgroup.com Tue Oct 16 17:45:42 2018 From: felix.ontanon at podgroup.com (=?UTF-8?Q?J=2E_F=C3=A9lix_Onta=C3=B1on_Podsystem?=) Date: Tue, 16 Oct 2018 19:45:42 +0200 Subject: Save the Date: OsmoCon 2018 on October 18-19, 2018 In-Reply-To: <20180411202208.GD28162@nataraja> References: <20180411202208.GD28162@nataraja> Message-ID: Hi Osmocom community. Pretty happy to attend this year and looking forward to see you in a few days. Considering there's a talk about sysmoUSIM (Philipp Maier), and regarding the contributions with "third-party open source utilities to be used with Osmocom projects" as Harald said, I'd like to introduce you something: We've been for some time developing some open source (gplv3) applets for the sysmoUSIM units. Still simple experiments, yet promising: https://github.com/PodgroupConnectivity/sim-applet-apn-autoconf https://github.com/PodgroupConnectivity/sim-applet-data-heartbeat https://github.com/PodgroupConnectivity/sim-applet-sms-im-alive I wanted to let you know as I'd really appreciate finding people with the same interests during the conference. See ya in a few days. On Wed, 11 Apr 2018 at 22:23, Harald Welte wrote: > == 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 > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -- *J. F?lix Onta??n* Director of Research and Innovation Pod Group felix.ontanon at podgroup.com www.podgroup.com www.podm2m.com www.pod.solutions UK: +44 (0)1223 850 900 <+44%201223%20850900> USA: +1 415 7070 500 Spain: +34 954 050 200 <+34%20954%2005%2002%2000> [image: Facebook] [image: Twitter] [image: LinkedIn] [image: Instagram] *Sign up for a demo of our hierarchical billing engine, Pod Billing * *Sales*: sales at podgroup.com *Support*: support at podgroup.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmkarl at gmail.com Sun Oct 28 10:38:14 2018 From: gmkarl at gmail.com (Karl) Date: Sun, 28 Oct 2018 06:38:14 -0400 Subject: Librtlsdr zerocopy buffers not working on Tinkerboard Armbian In-Reply-To: <1fdf87ad-c7e9-7eb5-66a1-4d54fcffbb80@steve-m.de> References:

<1fdf87ad-c7e9-7eb5-66a1-4d54fcffbb80@steve-m.de> Message-ID: Hey, to follow this up ... I saw there was a reply on the linux-usb list at https://www.spinics.net/lists/linux-usb/msg173393.html: "You should ask on the linux-arch at xxxxxxxxxxxxxxx, linux-arm-kernel at xxxxxxxxxxxxxxxxxxx, and linux-kernel at xxxxxxxxxxxxxxx mailing lists." I was using the zerocopy buffer feature, and just wondering if anybody ended up following this up on those kernel lists. I didn't find it mentioned with a brief google. Dumping kernel ram to userspace is obviously a serious security issue, so maybe it's not being discussed via public channels. But it would be tragic if it were not being discussed at all. On 10/9/18, Steve Markgraf wrote: > Hi, > > so it turned out that this is indeed a Kernel issue. I have implemented > a crude workaround for both rtl-sdr and osmo-fl2k to detect the bug, and > fall back to buffers in userspace if it is present. > > I've sent the mail below to the linux-usb list, but didn't get any reply > so far. Let's see. > > -- > When I debugged the issue, I found out that the Kernel maps seemingly > random memory to my transfer buffers, containing memory of other > processes or even the Kernel itself. > > The code that does the mapping in drivers/usb/core/devio.c: > (line 243 in v4.19-rc7) > >> if (remap_pfn_range(vma, vma->vm_start, >> virt_to_phys(usbm->mem) >> PAGE_SHIFT, >> size, vma->vm_page_prot) < 0) { > > With the following change the issue is fixed for ARM systems, but it > breaks x86 systems: > > - virt_to_phys(usbm->mem) >> PAGE_SHIFT, > + page_to_pfn(virt_to_page(dma_addr)), > > Both usbm->mem and dma_addr are returned by the previous call to > usb_alloc_coherent(). > Here's an example of the pointers generated by the two macros on an > ARM64 system for the same buffer: > > virt_to_phys(usbm->mem) >> PAGE_SHIFT: 00000000808693ce > page_to_pfn(virt_to_page(dma_addr)): 000000009775a856 > > From what I read so far I got the impression that the 'proper' way would > be to use dma_mmap_coherent() with dma_addr instead of > remap_pfn_range(), however, I did not get it to work. Can anyone help > out? > > Best Regards, > Steve Markgraf > From 246tnt at gmail.com Mon Oct 29 09:13:06 2018 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 29 Oct 2018 10:13:06 +0100 Subject: OSMOCOM-fft In-Reply-To: <5bc60798.1c69fb81.17e7f.3eb3@mx.google.com> References: <5bc60798.1c69fb81.17e7f.3eb3@mx.google.com> Message-ID: Hi, > I am wonder what exactly the vertical axis shows? It is written Power(dB); if so, what is the reference power? Is it 1dBW? Generally it's dBFS ... i.e. relative to the full scale value you get from the SDR. Whatever that is is hardware dependent. > Moreover, by changing the PGA Gain, I will have different values of power (dB). What is the relation between PGA gain and the received power in dBm? If the SDR gain are correct, increasing the gain by 1 dB should raise the value by 1 dB. But most SDR gains are not calibrated and really not that precise on only bear a vague correlation between their nominal value and their actual values. > In general, does anyone know how should I find the received power in dBm, having the PGA gain(dB) and the value on vertical axis. (Picture in attach) You can't. The only way to do that would be for you to do a bunch of calibration measurement with your SDR at every gain level and across the temperature range and frequency range with known power sources. This is the exact reason why your Keysight/Tek/R&S/... spectrum analyzer costs a few order of magnitude more than your SDR ... they can do theses absolute measurement and the entire signal chain is done for that. Cheers, Sylvain From steve at steve-m.de Mon Oct 29 21:29:51 2018 From: steve at steve-m.de (Steve Markgraf) Date: Mon, 29 Oct 2018 22:29:51 +0100 Subject: RTL_SDR dongle not being working with gnuradio In-Reply-To: <1868336601.17712153.1540740384658@mail.yahoo.com> References: <1868336601.17712153.1540740384658.ref@mail.yahoo.com> <1868336601.17712153.1540740384658@mail.yahoo.com> Message-ID: <89628879-285b-d28c-8a0d-1d40032d4b7c@steve-m.de> Hi, On 28.10.2018 16:26, MB wrote: > Is it possible RTL_TEST is looking for a E4000 because of it's dongle's > screwy PID, even though it sees a R820T.? If not, why is it not working? > thanks. ? rtl_test -h rtl_test, a benchmark tool for RTL2832 based DVB-T receivers Usage: [-s samplerate (default: 2048000 Hz)] [-d device_index (default: 0)] [-t enable Elonics E4000 tuner benchmark] As you can see, -t only works with E4000 tuners, and is meant to determine the size of the L-Band gap this tuner has. The R820T2 you have doesn't have an L-Band gap, thus there is nothing to benchmark. Regards, Steve From richard.hedlund at gmail.com Tue Oct 30 10:16:13 2018 From: richard.hedlund at gmail.com (Richard Hedlund) Date: Tue, 30 Oct 2018 11:16:13 +0100 Subject: Disable internal AGC in AirSpy HF+ Message-ID: Hello, For my purposes in GNU Radio using the osmocom source block i would like to disable the internal AGC in my AirSpy HF+. I see that i can choose the "Gain Mode" setting, however i am not sure that will disable (when set to manual) the AGC on the AirSpy HF+. Do you know of any good way to achieve this? I have installed the following library for the AirSpy HF+, where there is an API which enables you to disable the AGC, however i am not sure how to achieve this in GNU Radio: https://github.com/airspy/airspyhf *$airspyhf_info* AirSpy HF library version: 1.4.2 S/N: "removed" Part ID: 0x00000001 Firmware Version: R1.7.2 Available sample rate: 768 kS/s *$uname -a* Linux hedric-dev 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Hopefully this is enough information for you, otherwise let me know. Kind regards, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnieboer at corpcomm.net Wed Oct 31 01:05:17 2018 From: gnieboer at corpcomm.net (Geof Nieboer) Date: Tue, 30 Oct 2018 21:05:17 -0400 Subject: RTL_SDR dongle not being working with gnuradio In-Reply-To: <89628879-285b-d28c-8a0d-1d40032d4b7c@steve-m.de> References: <1868336601.17712153.1540740384658.ref@mail.yahoo.com> <1868336601.17712153.1540740384658@mail.yahoo.com> <89628879-285b-d28c-8a0d-1d40032d4b7c@steve-m.de> Message-ID: Yes, can confirm Steve's comment, with -t that's the expected result. I also get the "PLL not locked!" error message on my RTL-SDR (different PID), but flowgraphs still work fine in GNURadio / Win10. On Mon, Oct 29, 2018 at 5:29 PM Steve Markgraf wrote: > Hi, > > On 28.10.2018 16:26, MB wrote: > > Is it possible RTL_TEST is looking for a E4000 because of it's dongle's > > screwy PID, even though it sees a R820T. If not, why is it not working? > > thanks. > > ? rtl_test -h > rtl_test, a benchmark tool for RTL2832 based DVB-T receivers > > Usage: > [-s samplerate (default: 2048000 Hz)] > [-d device_index (default: 0)] > [-t enable Elonics E4000 tuner benchmark] > > As you can see, -t only works with E4000 tuners, and is meant to > determine the size of the L-Band gap this tuner has. The R820T2 > you have doesn't have an L-Band gap, thus there is nothing to benchmark. > > Regards, > Steve > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhouta at gmail.com Wed Oct 31 09:28:03 2018 From: lhouta at gmail.com (Tom Nash) Date: Wed, 31 Oct 2018 09:28:03 +0000 Subject: No subject Message-ID: Request sibscription -------------- next part -------------- An HTML attachment was scrubbed... URL: