osmocom-sdr February 2015

osmocom-sdr@lists.osmocom.org

6 participants
7 discussions

HackRF powered antenna support (pleeeeease :)
by Brad Hein 15 May '15

15 May '15

I would like to humbly request support for hackrf antenna power in gr-osmosdr. At runtime preferably, or at least an init string flag to control it (hackrf=0,antenna_power=1 for example). The function call seems to be hackrf_set_antenna_enable() but it's not exposed in gr-osmosdr as far as I can tell. I have some dev experience (but not in C) but I'm falling short trying to understand the code and add the feature myself. If someone wants to provide some "ELI5" guidance I'll be happy to give it another go. Having this feature would open up the powered antenna feature to users of gr-osmosdr such as gnuradio, gqrx, and the list goes on (big win!) Reference: https://www.mail-archive.com/hackrf-dev@greatscottgadgets.com/msg00423.html Thanks! Brad

1 1

gr-fosphor: error: work group size exceeds the maximum default value for the selected device (AMD HD 5450)
by Sipos Csaba 27 Feb '15

27 Feb '15

Dear list, I just compiled gr-fosphor on a PC equipped with a HD 5450 card, and when I try to run osmocom_fft -F I gut the following error: root@TH-SDR1:~/gr-fosphor/gr-fosphor/lib/fosphor# osmocom_fft -F linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.001-42-g8c87a524 gr-osmosdr v0.1.4-8-g46bb1ad1 (0.1.5git) gnuradio 3.7.5.1 built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace -- Operating over USB 3. -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 32.000000 MHz... -- Actually got clock rate 32.000000 MHz. -- Performing timer loopback test... pass -- Setting master clock rate selection to 'automatic'. -- Using subdev spec 'A:A'. [+] Selected device: Cedar Build log for 'display.cl': "/tmp/OCL2287T8.cl", line 67: error: work group size exceeds the maximum default value for the selected device __attribute__((reqd_work_group_size(16, 16, 1))) ^ 1 error detected in the compilation of "/tmp/OCL2287T8.cl". Frontend phase failed compilation. --- [!] CL Error (-11, /root/gr-fosphor/gr-fosphor/lib/fosphor/cl.c:344): Failed to build program I installed the latest stable driver and APP-SDK. oot@TH-SDR1:~/gr-fosphor/gr-fosphor/lib/fosphor# fglrxinfo display: :0.0 screen: 0 OpenGL vendor string: Advanced Micro Devices, Inc. OpenGL renderer string: AMD Radeon HD 5450 OpenGL version string: 4.4.13283 Compatibility Profile Context 14.501.1003 Here is the info about the card: NAME: Cedar VENDOR: Advanced Micro Devices, Inc. PROFILE: FULL_PROFILE VERSION: OpenCL 1.2 AMD-APP (1642.5) EXTENSIONS: 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_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_atomic_counters_32 cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt cl_amd_image2d_from_buffer_read_only cl_khr_spir cl_khr_gl_event DRIVER_VERSION: 1642.5 Type: GPU EXECUTION_CAPABILITIES: Kernel GLOBAL_MEM_CACHE_TYPE: None (0) CL_DEVICE_LOCAL_MEM_TYPE: Local (1) SINGLE_FP_CONFIG: 0x3e QUEUE_PROPERTIES: 0x2 VENDOR_ID: 4098 MAX_COMPUTE_UNITS: 2 MAX_WORK_ITEM_DIMENSIONS: 3 MAX_WORK_GROUP_SIZE: 128 PREFERRED_VECTOR_WIDTH_CHAR: 16 PREFERRED_VECTOR_WIDTH_SHORT: 8 PREFERRED_VECTOR_WIDTH_INT: 4 PREFERRED_VECTOR_WIDTH_LONG: 2 PREFERRED_VECTOR_WIDTH_FLOAT: 4 PREFERRED_VECTOR_WIDTH_DOUBLE: 0 MAX_CLOCK_FREQUENCY: 650 ADDRESS_BITS: 32 MAX_MEM_ALLOC_SIZE: 134217728 IMAGE_SUPPORT: 1 MAX_READ_IMAGE_ARGS: 128 MAX_WRITE_IMAGE_ARGS: 8 IMAGE2D_MAX_WIDTH: 16384 IMAGE2D_MAX_HEIGHT: 16384 IMAGE3D_MAX_WIDTH: 2048 IMAGE3D_MAX_HEIGHT: 2048 IMAGE3D_MAX_DEPTH: 2048 MAX_SAMPLERS: 16 MAX_PARAMETER_SIZE: 1024 MEM_BASE_ADDR_ALIGN: 2048 MIN_DATA_TYPE_ALIGN_SIZE: 128 GLOBAL_MEM_CACHELINE_SIZE: 0 GLOBAL_MEM_CACHE_SIZE: 0 GLOBAL_MEM_SIZE: 268435456 MAX_CONSTANT_BUFFER_SIZE: 65536 MAX_CONSTANT_ARGS: 8 LOCAL_MEM_SIZE: 32768 ERROR_CORRECTION_SUPPORT: 0 PROFILING_TIMER_RESOLUTION: 1 ENDIAN_LITTLE: 1 AVAILABLE: 1 COMPILER_AVAILABLE: 1 MAX_WORK_GROUP_SIZES: 128 128 128 --------------------------------------------------------------------- If someone can suggest what else to try, it will be appreciated. Thanks, Csaba

2 4

Calling rtlsdr_* while receiving in async mode
by Oliver Jowett 16 Feb '15

16 Feb '15

What's the "right way" to call rtlsdr_* functions while receiving samples via rtlsdr_read_async()? e.g. to change frequency or gain mid-run. You can't call them directly from the async callback as you're within a libusb callback at that point and libusb will self-deadlock if you do anything that needs a synchronous transfer. Plus even without the self-deadlock you really don't want a recursive callback happening if another bulk transfer turns up.. You can't call them from a separate thread because librtlsdr isn't threadsafe. The only way I've found that's reliable is to call rtlsdr_cancel_async() from within the async callback, wait for rtlsdr_read_async() to return, do your work, then call rtlsdr_read_async() again. This is ugly and can drop samples. rtlsdr_read_async() is also a bit buggy in that sometimes it will take up to a second after cancellation has completed before it returns (it calls into libusb to handle more events even if all xfers have completed cancellation, and then you've got to wait for that to time out..) What's the right way to do this? Oliver

1 1

librtlsdr maintenance and releases
by Oliver Jowett 16 Feb '15

16 Feb '15

Is Osmocom still maintaining librtlsdr? Last change to the code was over a year ago now. Any plans for future releases of the library? Oliver

1 0

Announcing OsmoDevCon 2015
by Harald Welte 13 Feb '15

13 Feb '15

Dear Osmocom.org project members, I'm happy to be able to announce the annual incarnation of OsmoDevCon. The Date is set for March 27 through 30. Venue: As usual, IN-Berlin e.V. in Berlin, Germany. Further details can be obtained from http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2015 Attendance, as usual, is restricted to people with an active history in the Project by contributions in terms of code, patches, discussions, documentation or in other form. = Registration = If you have wiki access, please add yourself to the #Requested section. Alternatively, you can send me private e-mail about it. After review, your (nick)name will be listed in the #Confirmed section. Looking forward to meeting all of you again soon! -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

A rtl-sdr driver fork for #Sdr-Sharp was created with software decimation
by rtlsdrfan＠airmail.cc 04 Feb '15

04 Feb '15

It seems a Russian developer created a fork of rtl-sdr that has software decimation. "The decimation feature allows you to sacrifice some bandwidth for increased ADC bit resolution." This may be a reimplementation of the sdr-sharp version of decimation according to this story: http://www.rtl-sdr.com/new-sdr-rtl-sdr-driver-lnamixervga-gain-settings-dec… The driver also features manual settings for the LNA/Mixer and VGA gain stages and is based on Oliver Jowet’s modified driver. The source code is here: http://sourceforge.net/projects/sdrr820tmanualgainsettings/files/ if anybody wants to see if there are any notable changes worthy of making a patch or pull for as it may contain other fixes or features.

1 0

R820T
by Leif Asbrink 02 Feb '15

02 Feb '15

Hi All, The rtl-sdr library from Osmocom uses R820T with an IF filter bandwidth of 5 MHz. This means that the peak amplitude of all the signals within this bandwidth has to be below the point of saturation for tha ADC. To accomplish that on a crowded FM band it is necessary to turn down the gain which means that weak stations can not be heard because of the degraded NF. It is possible to do much better. The IF filter which actually is a low pass filter and a high pass filter can be set for a bandwidth of 300 kHz. Dynamic range increases by something like 30 dB for the second next channel 400 kHz away. It is also possible to get some more improvement by changing the gain distribution. Sampling should remain at 2.4 MHz because the stop band attenuation is not very high and if sampling at 300 kHz one would get aliases from signals outside the filter if they are strong. Here is a video showing the difference between the Osmocom library and a modified library: https://www.youtube.com/watch?v=btDiWHuI730 Amusing that the cheap dongle has lower phase noise than the low noise synthetized generator from Hewlet Packard. An oldfashioned vacuumtube generator is needed to find the performance of the dongle... The modified library can be obtained like this: git clone https://github.com/dl8aau/librtlsdr A dll for Windows is available here: https://drive.google.com/file/d/0B9m6SAaGpewQeWtyS0lzdW1xVmM/view?usp=shari… Linrad-04.04 will soon become available here: http://www.sm5bsz.com/linuxdsp/linrad.htm Regards Leif

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr February 2015