From lists at lazygranch.com Thu Nov 6 21:37:26 2014 From: lists at lazygranch.com (lists) Date: Thu, 6 Nov 2014 13:37:26 -0800 Subject: Bandwidth of the dvb-t dongle Message-ID: <20141106133726.2b0fced2@linux-wh01> I saw a post about Nooelect sellings the dvb-t2 dongle and that it is slightly wider bandwidth than the plain dvb-t dongle. > http://www.rtl-sdr.com/nooelec-now-selling-rtl-sdrs-r820t2-tuner/ Looking up DVB-T2 on google, it indicates the bandwidth is 8MHz. There is a plot on the older DVB-T wiki of a DVB-T signal at about 7.5MHz bandwidth. So the question is why do we only see +/- 2MHz? The dump1090 program would benefit with more bandwidth. From 246tnt at gmail.com Sun Nov 9 12:22:31 2014 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 9 Nov 2014 13:22:31 +0100 Subject: Bandwidth of the dvb-t dongle In-Reply-To: <20141106133726.2b0fced2@linux-wh01> References: <20141106133726.2b0fced2@linux-wh01> Message-ID: > So the question is why do we only see +/- 2MHz? The dump1090 program > would benefit with more bandwidth. Because the bandwidth in the spec is the one when you use the integrated hardware DVB-T demodulator that's onboard. When using it as a general purpose SDR you're using it in a completely different mode and the limitation comes from there. Cheers, Sylvain From cooljohnwright at gmail.com Mon Nov 10 21:40:25 2014 From: cooljohnwright at gmail.com (John Wright) Date: Mon, 10 Nov 2014 16:40:25 -0500 Subject: Spectrum Sensing App Message-ID: Has anyone tried the Spectrum Sensing app that is listed as a part of OsmocomSDR? http://sdr.osmocom.org/trac/wiki/GrOsmoSDR It seems that documentation for it is in the works. I need to generate a spectrum survey log file comprising time, frequency and signal strength. My RF front end is a HackRF. Any pointers would be greatly appreciated. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at joshknows.com Wed Nov 12 07:03:48 2014 From: josh at joshknows.com (Josh Blum) Date: Tue, 11 Nov 2014 23:03:48 -0800 Subject: Announcing the SoapySDR project Message-ID: <54630654.3030801@joshknows.com> Hello list, I am pleased to announce the SoapySDR project. SoapySDR is a vendor neutral and platform independent SDR support library. The library provides a generic API for accessing SDR devices, and a plugin architecture for supporting vendor hardware drivers. Currently SoapySDR offers both a C++ and a C API, as well as Python language bindings. SoapySDR already supports most devices through osmosdr and uhd based plugins. The API covers an almost complete superset of available functionality found in these libraries. Therefore, there is an API for things like burst controls, heterogeneous channels, timed streaming, timed command, find tuning adjustments, automatic gain controls... I have seen a lot of applications where the developer has gone through the trouble of wrapping several low level drivers to gain support for each new device. But this can be way easier: you can use SoapySDR right now, write the code once, and have support for most devices. Please read more about SoapySDR on its main project page: https://github.com/pothosware/SoapySDR/wiki -- Community feedback -- Making a generic library has its challenges, and we will probably never get it 100% right. But with feedback from vendors and users, we can make sure the the library has what most people need. Missing a feature? Need another language binding? Don't like the way something works? Lets hear it. https://github.com/pothosware/SoapySDR/wiki/FAQ -- GNU Radio blocks -- We have created out-of-tree GNU Radio source and sink blocks based on SoapySDR that can provide a GNU Radio interface for the vast majority of SDR devices and capabilities: https://github.com/pothosware/gr-sdr/wiki Volunteers? The source and sink blocks have full basic functionality, but there are still additional APIs to wrap and apps to port over. The eventual goal is to mainline this component into GNU Radio: https://github.com/pothosware/gr-sdr/issues There has been some debate over what would be a good name for this GNU Radio component. Please help us with feedback about the name by taking this online poll: https://github.com/pothosware/gr-sdr/wiki#help-us-name-gr-sdr -- Hardware vendors -- If you are a hardware vendor, chances are that your device is already supported through the uhd or osmo libraries. However, you may be interested in directly hosting a SoapySDR support module along with your low-level driver: for simplicity's sake, licensing reasons, or because it exposes additional features. Hosting a module build with along with the driver is fairly simple and has many advantages. I'm happy to work with anyone who is interested: https://github.com/pothosware/SoapySDR/tree/master/ExampleDriver Thanks, -Josh From guilain.achard at gmail.com Wed Nov 12 20:46:55 2014 From: guilain.achard at gmail.com (Gui) Date: Wed, 12 Nov 2014 20:46:55 +0000 (UTC) Subject: Complex FIR and Stereo support for =?utf-8?b?cnRsX2Zt?= References: <523311A0.3030900@email.cz> <5236D10C.5040009@gmail.com> <5236D18A.2090706@email.cz> <5236D479.6090507@email.cz> Message-ID: Hi Miroslav, I encounter some issues compiling your exciting code for Windows x86. I've compiled with Code Blocks under GCC 4.8.1 and have a SEG FAULT when I use SSE, ie -F4 and -J7. Seems to be at pthread_create function. I'd linked memalign to _aligned_malloc, buffers seems to be initialized. I' don't know how to make it works on windows. Have you an idea ? Thanks... Guilain From alexander.tudor at gmail.com Tue Nov 18 04:05:26 2014 From: alexander.tudor at gmail.com (Alexander Tudor) Date: Mon, 17 Nov 2014 20:05:26 -0800 Subject: sdriq on mac Message-ID: Hi, I have tried to use gqrx with an RFSPACE sdriq using the gr-osmosdr. The experiment failed on both 10.7.5 and 10.9.5 despite following the ftdi site instructions for either OS. I have installed all s/w via mac ports. D2XX is installed in /usr/local/lib and, according to the suggestion of a person from Ettus, tried to set DYLD_INSERT_LIBRARIES=/usr/local/lib/libftd2xx.1.2.2.dylib gxrz. All to no avail. When I run gqrx I get: and if I edit the settings, I get: But there is not /dev/ttyUSB0 nor do I know why a device is required if there is direct access (I suppose via libusb?). System profiler clearly show the device: Could anybody tell me what is the prescribed way of achieving what I am trying, or a way of debugging what is wrong? Thank you, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-3.png Type: image/png Size: 57966 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-4.png Type: image/png Size: 75657 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-5.png Type: image/png Size: 41231 bytes Desc: not available URL: From bstaufenb at hs-koblenz.de Wed Nov 19 11:33:41 2014 From: bstaufenb at hs-koblenz.de (staufenbiel) Date: Wed, 19 Nov 2014 12:33:41 +0100 Subject: Segmentation Fault on OsmoSDR-Source Message-ID: <546C8015.5060505@hs-koblenz.de> Hi, I'm running a RTL-SDR over a Raspberry Pi. On my old machine everthing worked fine. But now I had to move to another machine and I'm getting this output everytime I start my programm: linux; GNU C++ version 4.7.2; Boost_104900; UHD_003.007.002-0-unknown Warning: failed to XInitThreads() Gtk-Message: Failed to load module "canberra-gtk-module" Using Volk machine: avx_64_mmx_orc gr-osmosdr 0.1.3 (0.1.3) gnuradio 3.7.5 built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy Segmentation fault I have installed GNU Radio with the build-gnuradio script. So everthing should be installed correctly. Thank you for your help! Bj?rn From allen.welkie at gmail.com Mon Nov 24 02:20:05 2014 From: allen.welkie at gmail.com (Allen Welkie) Date: Sun, 23 Nov 2014 21:20:05 -0500 Subject: Question about rtlsdr read_sync() Message-ID: Just trying to figure out how to use the rtlsdr_read_sync() function, and I'm not understanding just by reading the source. Am I supposed to call this function continuously in a loop in a thread separate from the sample processing, or can I do some processing in between calls to rtlsdr_read_sync()? In other words, are the samples being buffered on the rtlsdr device in between calls? If so, what's the size of that buffer? Also, what functions need to be called before I can use the read_sync or read_async functions? I'm calling rtlsdr_open, rtlsdr_set_center_freq, and rtlsdr_set_sample_rate before calling rtlsdr_read_sync, but I'm not getting any samples (and subsequent calls to rtlsdr_read_sync or read_async fail, e.g. from running the rtlsdr_fm program). Thanks, Allen -------------- next part -------------- An HTML attachment was scrubbed... URL: