From leif at sm5bsz.com Mon Feb 2 02:46:57 2015 From: leif at sm5bsz.com (Leif Asbrink) Date: Mon, 2 Feb 2015 03:46:57 +0100 Subject: R820T Message-ID: <20150202034657.7316edeade1cf6106a3769c1@sm5bsz.com> 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=sharing Linrad-04.04 will soon become available here: http://www.sm5bsz.com/linuxdsp/linrad.htm Regards Leif From laforge at gnumonks.org Fri Feb 13 07:10:12 2015 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 13 Feb 2015 08:10:12 +0100 Subject: Announcing OsmoDevCon 2015 Message-ID: <20150213071012.GF20121@nataraja> 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 http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From oliver.jowett at gmail.com Sun Feb 15 13:38:44 2015 From: oliver.jowett at gmail.com (Oliver Jowett) Date: Sun, 15 Feb 2015 13:38:44 +0000 Subject: Calling rtlsdr_* while receiving in async mode Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver.jowett at gmail.com Mon Feb 16 14:11:26 2015 From: oliver.jowett at gmail.com (Oliver Jowett) Date: Mon, 16 Feb 2015 14:11:26 +0000 Subject: librtlsdr maintenance and releases Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver.jowett at gmail.com Mon Feb 16 14:28:20 2015 From: oliver.jowett at gmail.com (Oliver Jowett) Date: Mon, 16 Feb 2015 14:28:20 +0000 Subject: Calling rtlsdr_* while receiving in async mode In-Reply-To: References: Message-ID: On 15 February 2015 at 13:38, Oliver Jowett wrote: > 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. > Some work in this area: https://github.com/mutability/librtlsdr/tree/async-rearrangements - Rearranging rtlsdr_read_async() so that rtlsdr callbacks are not done from within the libusb callback. This allows you to safely call rtlsdr_* from within the async callback. https://github.com/mutability/librtlsdr/tree/thread-safety - makes device access threadsafe (in theory), so you can safely call rtlsdr_* from multiple threads (including while rtlsdr_read_async is running) Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: From sipos.csaba at kvk.uni-obuda.hu Fri Feb 27 10:13:21 2015 From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba) Date: Fri, 27 Feb 2015 11:13:21 +0100 (CET) Subject: gr-fosphor: error: work group size exceeds the maximum default value for the selected device (AMD HD 5450) In-Reply-To: <7146901.12481753.1425031835324.JavaMail.root@kvk.uni-obuda.hu> Message-ID: <29618406.12482232.1425032001476.JavaMail.root@kvk.uni-obuda.hu> 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 at 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 at 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 From tnt at 246tnt.com Fri Feb 27 10:19:06 2015 From: tnt at 246tnt.com (Sylvain Munaut) Date: Fri, 27 Feb 2015 11:19:06 +0100 Subject: gr-fosphor: error: work group size exceeds the maximum default value for the selected device (AMD HD 5450) In-Reply-To: <29618406.12482232.1425032001476.JavaMail.root@kvk.uni-obuda.hu> References: <7146901.12481753.1425031835324.JavaMail.root@kvk.uni-obuda.hu> <29618406.12482232.1425032001476.JavaMail.root@kvk.uni-obuda.hu> Message-ID: Hi, > 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: > [+] 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. Yes, that card only suppot 128 as a maximum work group size and fosphor is written to use 256. I think this particular generation of card is the only one that's new enough to support OpenCL but old enough to not support WG of 256. I did however write a patch to support it a while back and just never bothered to clean it up (to select size dynamically depending on your card). Try the attached patch and see if it works for you. Cheers, Sylvain -------------- next part -------------- commit 5b2d6c6abef2680e367fc315fb32f9b51fe5de8f Author: Sylvain Munaut Date: Sat Oct 19 23:23:57 2013 +0200 [hack] Make display kernel 8x8 diff --git a/fosphor/cl.c b/fosphor/cl.c index 3160dc4..530d3a2 100644 --- a/fosphor/cl.c +++ b/fosphor/cl.c @@ -679,9 +679,9 @@ fosphor_cl_process(struct fosphor *self, /* Execute display kernel */ global[0] = FOSPHOR_FFT_LEN; - global[1] = 16; - local[0] = 16; - local[1] = 16; + global[1] = 8; + local[0] = 8; + local[1] = 8; err = clEnqueueNDRangeKernel(cl->cq, cl->kern_display, 2, NULL, global, local, 0, NULL, NULL); CL_ERR_CHECK(err, "Unable to queue display kernel execution"); diff --git a/fosphor/display.cl b/fosphor/display.cl index dd19bba..82d210f 100644 --- a/fosphor/display.cl +++ b/fosphor/display.cl @@ -42,6 +42,9 @@ //#define MAX_HOLD_NORMAL #define MAX_HOLD_DECAY +#define QS_LOG 3 +#define QS (1< Message-ID: <33518557.12525302.1425041225874.JavaMail.root@kvk.uni-obuda.hu> Thanks mate, with your patch its working all right :-) With Tom, we talked about a feature wich would be nice to have: a 10ms trigger so we can see something like this: http://tsou.cc/lte/openlte-spectro.png What do you think about it? Regards, Csaba ----- Original Message ----- From: "Sylvain Munaut" To: "Sipos Csaba" Cc: osmocom-sdr at lists.osmocom.org, "Sylvain Munaut" Sent: Friday, February 27, 2015 11:19:06 AM Subject: Re: gr-fosphor: error: work group size exceeds the maximum default value for the selected device (AMD HD 5450) Hi, > 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: > [+] 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. Yes, that card only suppot 128 as a maximum work group size and fosphor is written to use 256. I think this particular generation of card is the only one that's new enough to support OpenCL but old enough to not support WG of 256. I did however write a patch to support it a while back and just never bothered to clean it up (to select size dynamically depending on your card). Try the attached patch and see if it works for you. Cheers, Sylvain From tnt at 246tnt.com Fri Feb 27 13:01:45 2015 From: tnt at 246tnt.com (Sylvain Munaut) Date: Fri, 27 Feb 2015 14:01:45 +0100 Subject: gr-fosphor: error: work group size exceeds the maximum default value for the selected device (AMD HD 5450) In-Reply-To: <33518557.12525302.1425041225874.JavaMail.root@kvk.uni-obuda.hu> References: <33518557.12525302.1425041225874.JavaMail.root@kvk.uni-obuda.hu> Message-ID: Hi, > Thanks mate, with your patch its working all right :-) Great. I'll see if I can make it part of the mailine code so you don't have to mess around with patch. > With Tom, we talked about a feature wich would be nice to have: a 10ms trigger so we can see something like this: > > http://tsou.cc/lte/openlte-spectro.png > > What do you think about it? I'm not exactly sure what you mean with the above picture. But something I'm thinking about it to have a return channel from the fosphor block that would basically feedback 'timestamps' of when the real time spectrum went above a given mask. Then I'm also working on another piece of code that's oriented toward "off-line" signal browsing (so it works on a time-limited number of samples rather than a continuous stream). And when a trigger event is hit, it would basically send off that chunk of sample to that other blow for viewing / browsing. I want them to be separate because the architecture of fosphor is oriented toward high rate real time display and so I have to sacrifice some other aspects to meet that. The other signal browsing block would be coded more with flexibility in mind. So in the end you'd have one display that represent the real-time of what's being recorded _right_now_ by your SDR, and then a second display that shows the last trigger event and allows you to browse around it, a bit like a scope does for time signals. Cheers, Sylvain From sipos.csaba at kvk.uni-obuda.hu Fri Feb 27 14:06:08 2015 From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba) Date: Fri, 27 Feb 2015 15:06:08 +0100 (CET) Subject: gr-fosphor: error: work group size exceeds the maximum default value for the selected device (AMD HD 5450) In-Reply-To: Message-ID: <1106208.12532370.1425045968112.JavaMail.root@kvk.uni-obuda.hu> Hi, > Great. I'll see if I can make it part of the mailine code so you don't have to mess around with patch. Great, that would be nice. :-) I tried to compile the benchmark tool to measure what this card can do, but I hit a compilation error: root at TH-SDR1:~/gr-fosphor/gr-fosphor/lib/fosphor# make clean rm -f main *.o resource_data.c root at TH-SDR1:~/gr-fosphor/gr-fosphor/lib/fosphor# make gcc -Wall -Werror -O2 `pkg-config freetype2 glfw3 --cflags` -g -I/opt/AMDAPPSDK-2.9-1/include -c -o main.o main.c gcc -Wall -Werror -O2 `pkg-config freetype2 glfw3 --cflags` -g -I/opt/AMDAPPSDK-2.9-1/include -c -o resource.o resource.c ./mkresources.py fft.cl display.cl cmap_simple.glsl cmap_bicubic.glsl cmap_fallback.glsl DroidSansMonoDotted.ttf > resource_data.c gcc -Wall -Werror -O2 `pkg-config freetype2 glfw3 --cflags` -g -I/opt/AMDAPPSDK-2.9-1/include -c -o resource_data.o resource_data.c gcc -Wall -Werror -O2 `pkg-config freetype2 glfw3 --cflags` -g -I/opt/AMDAPPSDK-2.9-1/include -c -o axis.o axis.c gcc -Wall -Werror -O2 `pkg-config freetype2 glfw3 --cflags` -g -I/opt/AMDAPPSDK-2.9-1/include -c -o cl.o cl.c gcc -Wall -Werror -O2 `pkg-config freetype2 glfw3 --cflags` -g -I/opt/AMDAPPSDK-2.9-1/include -c -o cl_compat.o cl_compat.c gcc -Wall -Werror -O2 `pkg-config freetype2 glfw3 --cflags` -g -I/opt/AMDAPPSDK-2.9-1/include -c -o fosphor.o fosphor.c gcc -Wall -Werror -O2 `pkg-config freetype2 glfw3 --cflags` -g -I/opt/AMDAPPSDK-2.9-1/include -c -o gl.o gl.c gcc -Wall -Werror -O2 `pkg-config freetype2 glfw3 --cflags` -g -I/opt/AMDAPPSDK-2.9-1/include -c -o gl_cmap.o gl_cmap.c gcc -Wall -Werror -O2 `pkg-config freetype2 glfw3 --cflags` -g -I/opt/AMDAPPSDK-2.9-1/include -c -o gl_cmap_gen.o gl_cmap_gen.c gcc -Wall -Werror -O2 `pkg-config freetype2 glfw3 --cflags` -g -I/opt/AMDAPPSDK-2.9-1/include -c -o gl_font.o gl_font.c gcc -g main.o resource.o resource_data.o axis.o cl.o cl_compat.o fosphor.o gl.o gl_cmap.o gl_cmap_gen.o gl_font.o `pkg-config freetype2 glfw3 --libs` -lm -lOpenCL -lGL -ldl -o main cl.o: In function `cl_init_buffers_gl': /root/gr-fosphor/gr-fosphor/lib/fosphor/cl.c:469: undefined reference to `clCreateFromGLBuffer' cl.o: In function `fosphor_cl_process': /root/gr-fosphor/gr-fosphor/lib/fosphor/cl.c:875: undefined reference to `clEnqueueAcquireGLObjects' cl.o: In function `fosphor_cl_finish': /root/gr-fosphor/gr-fosphor/lib/fosphor/cl.c:938: undefined reference to `clEnqueueAcquireGLObjects' /root/gr-fosphor/gr-fosphor/lib/fosphor/cl.c:958: undefined reference to `clEnqueueReleaseGLObjects' cl_compat.o: In function `clCreateFromGLTexture_alt': /root/gr-fosphor/gr-fosphor/lib/fosphor/cl_compat.c:110: undefined reference to `clCreateFromGLTexture2D' collect2: error: ld returned 1 exit status make: *** [main] Error 1 The application (gr-fosphor) compiles and runs just fine. Maybe you know what am I missing. > I'm not exactly sure what you mean with the above picture. I mean that LTE (and many other RF technology) has a 10ms radio frame lenght, so it would be nice to be able to analyze that (like on the picture) on a radio frame level, rather than a continous stream. I think what you described is pretty much what I am asking for anyway :-) Thanks! Csaba ----- Original Message ----- From: "Sylvain Munaut" To: "Sipos Csaba" Cc: "Sylvain Munaut" , osmocom-sdr at lists.osmocom.org Sent: Friday, February 27, 2015 2:01:45 PM Subject: Re: gr-fosphor: error: work group size exceeds the maximum default value for the selected device (AMD HD 5450) Hi, > Thanks mate, with your patch its working all right :-) Great. I'll see if I can make it part of the mailine code so you don't have to mess around with patch. > With Tom, we talked about a feature wich would be nice to have: a 10ms trigger so we can see something like this: > > http://tsou.cc/lte/openlte-spectro.png > > What do you think about it? I'm not exactly sure what you mean with the above picture. But something I'm thinking about it to have a return channel from the fosphor block that would basically feedback 'timestamps' of when the real time spectrum went above a given mask. Then I'm also working on another piece of code that's oriented toward "off-line" signal browsing (so it works on a time-limited number of samples rather than a continuous stream). And when a trigger event is hit, it would basically send off that chunk of sample to that other blow for viewing / browsing. I want them to be separate because the architecture of fosphor is oriented toward high rate real time display and so I have to sacrifice some other aspects to meet that. The other signal browsing block would be coded more with flexibility in mind. So in the end you'd have one display that represent the real-time of what's being recorded _right_now_ by your SDR, and then a second display that shows the last trigger event and allows you to browse around it, a bit like a scope does for time signals. Cheers, Sylvain From rtlsdrfan at airmail.cc Wed Feb 4 22:13:50 2015 From: rtlsdrfan at airmail.cc (rtlsdrfan at airmail.cc) Date: Wed, 04 Feb 2015 22:13:50 -0000 Subject: A rtl-sdr driver fork for #Sdr-Sharp was created with software decimation Message-ID: 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-decimation/ 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.