osmocom-sdr

osmocom-sdr@lists.osmocom.org

1 participants
910 discussions

Complex FIR and Stereo support for rtl_fm
by Miroslav Slugeň 13 Nov '14

13 Nov '14

Hi again, I am working on my own SDR project for Stereo FM radio support, but i would like to also improve quality for rtl_fm application, i made unoficial patch to add: Complex FIR - to filter strong signals close to wanted signal Real FIR - to filter pilot from FM Stereo FIR Stereo Deemphasis AGC support - it can give better resolution of IQ data Some other improvments in FM radio code. All FIR filters has 3 possible variants, simple, LUT, SSE2 instricts, of course SSE is the fastest one and it should works on Intel Atoms, but not on ARM. Feel free to use any part of code in any of you programs, I know that this code is little to much to add it into rtl_fm, but maybe it could somebody help to recieve HW stereo FM radio. Speed of SSE code is much better than anything you can get around here, on Core i7 it consume only 5% of one CPU, so i could demodulate at least 80 channels at the same time in stereo quality of course. I tried this code only on AMD64 and GCC Linux, so i am not sure if it can be compiled under windows. -- Miroslav Slugeň +420 724 825 885 Teramos Multimedia s.r.o.

4 8

Announcing the SoapySDR project
by Josh Blum 12 Nov '14

12 Nov '14

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

1 0

Spectrum Sensing App
by John Wright 11 Nov '14

11 Nov '14

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!

1 0

Bandwidth of the dvb-t dongle
by lists 09 Nov '14

09 Nov '14

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.

2 1

getting started
by Richard Bown 05 Mar '14

05 Mar '14

Hi, I've followed the steps in http://sdr.osmocom.org/trac/wiki/rtl-sdr All built OK, I opened up GRC clicked on RTLSDR in sources, but all I get is something flashing up on screen, looks like a block of text on a yellow background, but it seen to be flashing and scrolling and near impossible for me to read. rtl_test -t shows 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. What do I need to do now to get a working srd display, ie spectrum and waterfall display, or point me in the direction of the idiot guide please TIA -- -- Best wishes /73 Richard Bown Email : richard(a)g8jvm.com HTTP : http://www.g8jvm.com nil carborundum a illegitemis ################################################################################## Ham Call G8JVM . OS Linux Mint 16 x86_64 on a Dell Inspiron N5030 laptop Maidenhead QRA: IO82SP38, LAT. 52 39.720' N LONG. 2 28.171 W QRV VHF 6mtrs 200W, 4 mtrs 150W, 2mtrs 400W, 70cms 200W Microwave 23 cms 140W, 13 cms 100W, 6 cms 0W & 3cms 5W ##################################################################################

1 0

Retrieving device type
by Nick Foster 04 Mar '14

04 Mar '14

Hi, gr-osmosdr is great at abstracting the device type, but now I find myself wishing to de-abstract. For instance: HackRF has large DC offset, so I'd like the option to switch in a DC blocking filter when using that source. RTL dongles can't support more than 2.4Msps reliably, so I'd like to be able to cope accordingly at initialization time. Is there a good way to retrieve, say, a string descriptor telling me which particular source I'm using? --n

3 6

SDRIO: A hardware abstraction layer for SDR devices
by Scott Cutler 02 Mar '14

02 Mar '14

Some of you may have seen this already when I was asking licensing questions, but others may still be curious. In the course of other development efforts, I had a need for an abstraction layer that had more features than ExtIO. In particular, I wanted transmit support (for my bladeRF), as well as better control over gain and other settings. What I have come up with is SDRIO: a straightforward C interface for interacting with SDR devices. I currently support rtl-sdr, bladeRF, and the Funcube Dongle. Each driver lives in its own module: SDRIO_bladeRF.dll, etc. Applications can load these modules, query if devices are present, and then interact with them. All data transfer is asynchronous. Currently I only support Windows, though the API is OS-agnostic and the drivers (particularly rtl-sdr) should be able to be ported in a straightforward manner. SDRIO is licensed as LGPL. However, because it uses GPL code, it may not be distributed with non-GPL applications. It may still be used with non-GPL applications as long as the distributions are kept wholly separate (no bundling, auto-downloaders, etc.). Code is currently kept at: https://github.com/spcutler/SDRIO Right now it is in a very alpha state, and subject to change. Documentation is also currently minimal, although I hope the API is clear enough to be obvious. I hope to stabilize things once I get some outside feedback and suggestions. Thanks! -Scott PS: Mirics dongle support should be coming soon due to the generosity of a fellow member of this mailing list.

1 0

sdrangelove, make gives error [Solved]
by Ben Z en de rest 02 Mar '14

02 Mar '14

Hi, the problem with the installation of sdrangelove is solved. I had mistaken the Qt5 version and I installed the 32 bits version but I am running 64 bits Ubuntu. So make succeeded without errors now. TnX, Ben (can anyone help me how to reply to my own message, so the problem and solution make a thread )

1 0

acarsdec 2.0 with built-in rtl_sdr frontend
by Thierry Leconte 02 Mar '14

02 Mar '14

Thanks to Andreas Reinhardt who have port my old acarsdec code to rtl_sdr (http://lists.osmocom.org/pipermail/osmocom-sdr/2013-July/000712.html) I gain interest back to acars decoding and decided to rewrite completely acarsdec and to add it some new features, in particular a rtl front end. So , I am please to announce the acarsdec 2.0 release : https://sourceforge.net/projects/acarsdec Acarsdec is an open source, multi-channels realtime ACARS decoder for Linux. It features : - up to four channels decoded simultaneously - multi-threaded - error detection AND correction (all one error corrected and some two errors) - input from sound file , alsa sound card or software defined radio (SRD) via a rtl dongle The 4 channels decoding is particularly useful with the rtl dongle. It allows to directly listen simultaneously to 4 different frequencies. Ie: acarsdec -r 0 131.525 131.725 131.825 Will decode acars on 3 frequencies with the rtl dongle number 0. try and enjoy Thierry Leconte

1 1

rtl-sdr licensing question
by Scott Cutler 01 Mar '14

01 Mar '14

Greetings, all-- A while back I asked some questions about licensing of the rtl-sdr libraries, especially with regard to use with non-GPL software. At the time, I was told that the ExtIO libraries were considered an acceptable use-case. My code has been in development, and for various reasons--the largest being the desire for transmit support--I have developed my own HW abstraction layer called SDRIO. At the moment, I support rtl-sdr, bladeRF, and Funcube Dongle devices via the abstraction layer. The layer will, of course, be GNU licensed and thus free for anyone to modify or extend. My intent is thus for SDRIO to live in the same niche as ExtIO and thus have the blessings of the developers. I'm aware that you cannot give legal advice; my hope is only that, if someone comes to me saying I violated the rtl-sdr license, that at least I can tell them that I've talked with the lead developers and that they've given me the same permissions as the ExtIO developers. I have placed the code here in case anyone wishes to look at the current state (though please note that the text of the licensing is not yet finished): https://github.com/spcutler/SDRIO/blob/master The SDRIO_RTLSDR module is quite thin and I hope does not give the impression that SDRIO is just supposed to be a wrapper. If you look at the other devices, you can see that they require more code and that the project as a whole is quite a bit more than a wrapper. Thank you for your time! -Scott

3 7

← Newer
1
...
50
51
52
53
54
55
56
...
91
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr