osmocom-sdr

osmocom-sdr@lists.osmocom.org

917 discussions

Start a nNew thread

Patches: rtl_tcp memory fix, samplerate measure, args info
by Alexander Schultze 01 Apr '15

01 Apr '15

--- Alexander Schultze alexschultze(a)gmail.com +49 (0) 176 98109096

1 0

librtlsdr feature patch: Added a CMake option to specify the udev rules destination directory (handy for maintainers)
by Marcus Müller 21 Mar '15

21 Mar '15

2 1

R820T upper frequency ?
by friedtj 17 Mar '15

17 Mar '15

I am struggling with using some of the R820T-based dongles I bought (http://www.dx.com/p/170541). I am wondering where the specs from http://sdr.osmocom.org/trac/wiki/rtl-sdr comes from: although I am told that the operating frequency range is 24 - 1766 MHz, I am struggling to lock at 1574.2 MHz. From the datasheet (http://superkuh.com/gnuradio/R820T_datasheet-Non_R-20111130_unlocked.pdf) we are already well above the "official" operating frequency of this receiver frontend, but I nevertheless attempted to reproduce with this dongle the GPS decoding scheme I successfully implemented with E4k based dongles (for teaching purposes, I'd need a reliable supply of dongles but I only have a couple of E4k based dongles left, one of them probably damaged since the frontend is overheating). I did try to replace L9 (RF input), L2 + L6 (RF filters) and most significantly the pump charge RC circuit R8/C16 from the datasheet with high quality RF-grade components, but only managed to extend by ~60 MHz the locking range of the PLL, from 1.500 to 1.560 GHz. I am unable to to gain the last 20 MHz of reliable locking to receive GPS ! The way I measure is trivial: a frequency synthesizer generates a single tone (-35 dBm) and I look at the gnuradio FFT output. After a couple of seconds, the PLL unlocks and the visible single tone vanishes from the FFT. At 1.5 GHz the measurement is unreliable, lasts for about 1-10 seconds at 1.55 GHz, and a second at most at 1.56 GHz. The dongles never lock at 1.57 GHz, let alone 1.5742 GHz. I attempted the experiment with 3 dongles (of the 12 I have) so something is definitely wrong with either the layout of the PCB, or the information on the web page. Thanks for any info or which component to upgrade to extend the operating range (by only another 30 MHz !), JM -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 32 av. observatoire, 25044 Besancon, France

1 0

anyone have make fail on build.make:54: recipe for target 'src/CMakeFiles/rtl_tcp.dir/rtl_tcp.c.o'??
by loren butler 16 Mar '15

16 Mar '15

make produces the following...i have tried the main and mirror to see if there was a difference.... running raspian, the same instructions worked before...however im stuck in my tracks with this one Scanning dependencies of target convenience_static [ 5%] Building C object src/CMakeFiles/convenience_static.dir/convenience/convenience.c.o Linking C static library libconvenience_static.a [ 5%] Built target convenience_static Scanning dependencies of target rtlsdr_shared [ 10%] Building C object src/CMakeFiles/rtlsdr_shared.dir/librtlsdr.c.o [ 15%] Building C object src/CMakeFiles/rtlsdr_shared.dir/tuner_e4k.c.o [ 20%] Building C object src/CMakeFiles/rtlsdr_shared.dir/tuner_fc0012.c.o [ 25%] Building C object src/CMakeFiles/rtlsdr_shared.dir/tuner_fc0013.c.o [ 30%] Building C object src/CMakeFiles/rtlsdr_shared.dir/tuner_fc2580.c.o [ 35%] Building C object src/CMakeFiles/rtlsdr_shared.dir/tuner_r82xx.c.o Linking C shared library librtlsdr.so [ 35%] Built target rtlsdr_shared Scanning dependencies of target rtl_adsb [ 40%] Building C object src/CMakeFiles/rtl_adsb.dir/rtl_adsb.c.o Linking C executable rtl_adsb [ 40%] Built target rtl_adsb Scanning dependencies of target rtl_eeprom [ 45%] Building C object src/CMakeFiles/rtl_eeprom.dir/rtl_eeprom.c.o Linking C executable rtl_eeprom [ 45%] Built target rtl_eeprom Scanning dependencies of target rtl_fm [ 50%] Building C object src/CMakeFiles/rtl_fm.dir/rtl_fm.c.o Linking C executable rtl_fm [ 50%] Built target rtl_fm Scanning dependencies of target rtl_power [ 55%] Building C object src/CMakeFiles/rtl_power.dir/rtl_power.c.o Linking C executable rtl_power [ 55%] Built target rtl_power Scanning dependencies of target rtl_sdr [ 60%] Building C object src/CMakeFiles/rtl_sdr.dir/rtl_sdr.c.o Linking C executable rtl_sdr [ 60%] Built target rtl_sdr Scanning dependencies of target rtl_tcp [ 65%] Building C object src/CMakeFiles/rtl_tcp.dir/rtl_tcp.c.o /home/davinci/librtlsdr/src/rtl_tcp.c:28:23: fatal error: arpa/inet.h: No such file or directory compilation terminated. src/CMakeFiles/rtl_tcp.dir/build.make:54: recipe for target 'src/CMakeFiles/rtl_tcp.dir/rtl_tcp.c.o' failed make[2]: *** [src/CMakeFiles/rtl_tcp.dir/rtl_tcp.c.o] Error 1 CMakeFiles/Makefile2:355: recipe for target 'src/CMakeFiles/rtl_tcp.dir/all' failed make[1]: *** [src/CMakeFiles/rtl_tcp.dir/all] Error 2 Makefile:113: recipe for target 'all' failed make: *** [all] Error 2

1 0

rtl_test.exe failed to open rtlsdr device #0 with RTL2832U+R820T(tuner)
by Longxiang Wang 13 Mar '15

13 Mar '15

Hi, I am a rookie playing with SDR, and I have installed the driver with zadig properly I think, then I try to use rtl_test.exe, the error is like *Found 2 devices:* *0: ezcap usb2.0 DVB-T/DAB/FM dongle* *1:ezcap usb2.0 DVB-T/DAB/FM dongle* *failed to open rtlsdr device #0* Can anyone help? I would really appreciate that Thanks, Benjamin

1 0

SDR Osmocom
by Radiarisainana Sitraka 11 Mar '15

11 Mar '15

I would have a principal electornic schematic of SDR?thank's for helping.

1 0

Integration of Murata DNT 900
by Al Woodcock 10 Mar '15

10 Mar '15

Has any one used the Murata DNT 900 with a raspberry pi To receive data from the iron ert? It seems to have a little more range than the others I've been looking into. Just curious Al

1 0

Integration of Murata
by Al Woodcock 10 Mar '15

10 Mar '15

Sent from my iPad

1 0

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

← Newer
1
...
48
49
50
51
52
53
54
...
92
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr