- osmocom-sdr - lists.osmocom.org

Licensing issues
by Scott Cutler 26 Sep '12

26 Sep '12

Greetings, all! I've recently been bitten by the rtlsdr bug and have since developed some software around it. It's Windows-based and currently decodes (mono) WFM, NFM, POCSAG, FLEX 1600/6400, and (very limited) AX.25 frames. I would like to make a semi-limited release but have some concerns about the licensing of the rtlsdr library after what SDR# went through (or seemed to go through--I'm not sure what the whole story was). I do plan on open-sourcing the whole thing eventually, but in the short term I'll probably have a limited read-only license. Simply put, am I in the clear if I: - only access rtlsdr.dll through my own reimplementation of rtl-sdr.h and rtl-sdr_export.h - do not distribute the binary rtlsdr.dll, but instead link to the Osmocom binaries Thanks for the help! - Scott

6 13

R820T tuner support in librtlsdr
by Steve Markgraf 09 Sep '12

09 Sep '12

Hi list, yesterday I committed code for the Rafael Micro R820T tuner to librtlsdr. Sticks with this combination (RTL2832 + R820T) are relatively new on the market. The main difference to all the other supported tuners so far is that it uses a Low-IF (3.57 MHz) architecture instead of Zero-IF. That means the tuner is only connected to the In-Phase ADC input, and the internal downconverter of the RTL2832 is generating the complex samples. This has the benefit of having no DC offset spike in the middle of the spectrum. So far the tuner driver comes straight from the kernel driver that Realtek supplies, and setting gain manually is not supported yet, although functions for that seem to exist. There is still is a lot that needs to be done, the best thing most likely would be to completely rewrite the driver, or at least clean it up dramatically. Initializing the tuner takes way too long at the moment, since the driver produces a lot of I2C traffic, most of it being redundant as it seems. The driver originally had a frequency limitation of 40 MHz to 900 MHz, but tests showed that the PLL of my stick can achieve lock up to 1766 MHz, and indeed both ADS-B at 1090 MHz and L-Band DAB at 1463 MHz, as well as GMR at 1556 MHz can be received just fine with the R820T. Also, the PLL could lock again at 1850 MHz to 1860 MHz, and the reception of a GSM 1800 BTS at 1854 MHz worked as well. Some initial comparisons [1] between the E4000 and R820T seem to hint at the R820T being a bit more sensitive, especially visible in the Tetra screenshots. Given that the supply of E4000-based sticks is dwindling, I'm pleased to see a new tuner that has the potential of becoming a good replacement, and staying for a while on the market. Regards, Steve [1] http://steve-m.de/projects/rtl-sdr/tuner_comparison

5 4

Re: ISDB-T USB TV RTL-SDR FM+DAB Radio Tuner Receiver Stick Realtek RTL2832U E4000
by Bharath Bhushan Lohray 07 Sep '12

07 Sep '12

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=271041428220 I am new to SDR and such hardware. The ebay listing states that the hardware does not work in the US. I am wondering if this hardware is going to work for the purpose of playing around as a SDR? Thank you, Bharath

2 1

"Best" sampling rate?
by James Peroulas 06 Sep '12

06 Sep '12

Message: 1 > Date: Thu, 6 Sep 2012 05:22:25 +1000 > From: Ben Ryan <benryanau(a)hotmail.com> > To: <osmocom-sdr(a)lists.osmocom.org> > Subject: "Best" sampling rate? > Message-ID: <SNT139-W176A4A72E42D16D41CA612B6A90(a)phx.gbl> > Content-Type: text/plain; charset="iso-8859-1" > > > > > > Come to think of it, I've also found some samplerates to be better than > others. No further info to share beyond the fact that I've noticed it too. > > Drops at higher samplerates are probably due to your CPU, IO latency, etc > (esp if virtualised). You should be able to run 2.048Msps with AF rate of > 44.1khz with next to no drops and smooth carrier audio. If not, and your > CPU isn't maxed out, likely you have a latency or bandwidth issue. > What's the rig you're running on? > > There appears to be an interaction between AF samplerate and IQ > samplerate.. under HDSDR/Win32 anyways. > It might well reduce skips and cpu load if the two rates were cleanly > divisible but I haven't tried to work the theoreticals out.. > > I just set 3.2Msps for spectrum scoping, then narrow to around 1.2Msps for > FM/AM work. The audio rate is usually 44.1khz although sometimes whendoing > an "audio print" of a signal using DRM mode I'll up it to 48khz. On the > Core2Duo I get quite a few dropped samples at 3.2Msps/48khz though - it's > hitting the limits for this system as-is (it's running VMWare MS plus it's > got layers of drivers on it). > > Another thing to consider if under Win32: differing versions of libusb, > ExtIO_RTL, ExtIO_USRP, rtl2832u++.dll files all behave differently wrt cpu, > samplerates and drops. > I haven't documented my findings yet but there's a complex relationship > between the above elements and tuner range.. some RTL libs will permit > 50mhz-~2000mhz, others puke at various spots on the dial etc. > Thanks for the inspiration. I actually re-wrote my code to use async mode and now I'm getting reliable captures up to 1.92MSPS (my desired sampling rate). I was using sync mode but apparently that's not fast enough to capture all samples! BR, James

1 0

"Best" sampling rate?
by Ben Ryan 05 Sep '12

05 Sep '12

Come to think of it, I've also found some samplerates to be better than others. No further info to share beyond the fact that I've noticed it too. Drops at higher samplerates are probably due to your CPU, IO latency, etc (esp if virtualised). You should be able to run 2.048Msps with AF rate of 44.1khz with next to no drops and smooth carrier audio. If not, and your CPU isn't maxed out, likely you have a latency or bandwidth issue. What's the rig you're running on? There appears to be an interaction between AF samplerate and IQ samplerate.. under HDSDR/Win32 anyways. It might well reduce skips and cpu load if the two rates were cleanly divisible but I haven't tried to work the theoreticals out.. I just set 3.2Msps for spectrum scoping, then narrow to around 1.2Msps for FM/AM work. The audio rate is usually 44.1khz although sometimes whendoing an "audio print" of a signal using DRM mode I'll up it to 48khz. On the Core2Duo I get quite a few dropped samples at 3.2Msps/48khz though - it's hitting the limits for this system as-is (it's running VMWare MS plus it's got layers of drivers on it). Another thing to consider if under Win32: differing versions of libusb, ExtIO_RTL, ExtIO_USRP, rtl2832u++.dll files all behave differently wrt cpu, samplerates and drops. I haven't documented my findings yet but there's a complex relationship between the above elements and tuner range.. some RTL libs will permit 50mhz-~2000mhz, others puke at various spots on the dial etc. > I was wondering if certain sampling rates were better than others for > the RTL2832 dongles? I'm finding that if the sampling rate is below > 1.1MSPS, I get few samples being dropped (but they still get dropped). > Above this rate, randomly, I get a multiple of 94 samples being > dropped. > > Are there certain sampling frequencies that are sweet-spots for the > RTL2832 that produce very stable performance? Perhaps frequencies that > are a fraction of DVB sampling frequencies? > > JP > > -- > Integrity is a binary state - either you have it or you don?t. - John Doerr

1 0

"Best" sampling rate?
by James Peroulas 05 Sep '12

05 Sep '12

I was wondering if certain sampling rates were better than others for the RTL2832 dongles? I'm finding that if the sampling rate is below 1.1MSPS, I get few samples being dropped (but they still get dropped). Above this rate, randomly, I get a multiple of 94 samples being dropped. Are there certain sampling frequencies that are sweet-spots for the RTL2832 that produce very stable performance? Perhaps frequencies that are a fraction of DVB sampling frequencies? JP -- Integrity is a binary state - either you have it or you don’t. - John Doerr

1 0

Fixed a division by zero bug in rtl_fm that appears on OS X
by Christoph Gommel 31 Aug '12

31 Aug '12

Hallo guys, I tried to isolate the Floating point exception that prevents rtl_fm from running on my OS X Machine. XCode's code analysis mechanism showed pointed out a location of some code that not only might bring up a division by zero but brought this on my machine. After adding some basic handling rtl_fm runs now on my Mac but does not deliver appropiate sound. It's chopped and not understandable. Despite the fact that gnuradio performs great on the same machine there seem to be more bugs present I do not understand at the moment. But first of all this small patch should be added to the main code base. Sorry for not knowing more about git than executing "git diff" ;( I am a daily svn user who does not understand the non-linear anarchistic version management behind git by now... diff --git a/src/rtl_fm.c b/src/rtl_fm.c index 0350d8b..d00ef2d 100644 --- a/src/rtl_fm.c +++ b/src/rtl_fm.c @@ -313,13 +313,17 @@ int mad(int *samples, int len, int step) int i=0, sum=0, ave=0; for (i=0; i<len; i+=step) { sum += samples[i]; - } - ave = sum / (len * step); + } + if (len * step) //Avoid Division by zero errors + ave = sum / (len * step); sum = 0; for (i=0; i<len; i+=step) { sum += abs(samples[i] - ave); - } - return sum / (len * step); + } + if (len * step) //Avoid Division by zero errors + return sum / (len * step); + else + return (0); } int post_squelch(struct fm_state *fm)

1 0

Re: LTE Cell Scanner
by James Peroulas 28 Aug '12

28 Aug '12

> Date: Mon, 27 Aug 2012 12:27:21 +0200 > From: Christian Buchner <christian.buchner(a)gmail.com> > > For some reason, your CellSearch software worked the second time I ran > it. Here's the result for a scan in Munich. The two frequencies found > correspond to the operators O2 and Vodafone. Deutsche Telekom is > either not using the 800 MHz band here, or I happen to be out of the > reception range for this dongle. > > Detected the following cells: > C: CP type ; P: PHICH duration ; PR: PHICH resource type > CID fc foff RXPWR C nRB P PR CrystalCorrectionFactor > 449 796M -13.2k -47.7 N 50 N one 0.99998344473785039099 > 372 806M -13.2k -43.7 N 50 N one 0.99998362964129883235 I see that the received signal power is very low at -44dB, so it kind of makes sense that these cells would not be detected every time you run the program. I suspect that if you moved outdoors or used a tuned LTE antenna, these cells would be detectable more reliably. > This software project is way cool! I am surprised how precise my crystal is. > > Now who's willing to extend the code to combine several dongles to > scan the full 10 MHz band and to analyze the allocated resources > signalled on the PDCCH so we can generate statistics on cell load and > number of UEs served? Wow, I think that would be a major undertaking for these dongles! I think that's a task best suited for the USRP and the OpenLTE project :) JP

1 0

LTE Cell Scanner
by James Peroulas 28 Aug '12

28 Aug '12

I just released an LTE cell scanner based on the rtlsdr library. If you're interested, the code is available on github: https://github.com/Evrytania/LTE-Cell-Scanner This code will search for all the LTE cells in your area and will also report the frequency error of your dongle. BR, James P.S. Many thanks for the rtlsdr library! -- Integrity is a binary state - either you have it or you don’t. - John Doerr

5 9

Re: osmocom-sdr Digest, Vol 9, Issue 16
by James Peroulas 26 Aug '12

26 Aug '12

> Message: 1 > Date: Fri, 24 Aug 2012 18:11:59 +0200 > From: Christian Buchner <christian.buchner(a)gmail.com> > To: osmocom-sdr(a)lists.osmocom.org > Subject: Re: LTE Cell Scanner > Message-ID: > <CALm6U+pZd8Ufmu1UCOQ_+0ebMc_joDOh9_dFW0g=1QW=M2p02A(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > I was able to build it on Ubuntu 9.04 (Jaunty Jackalope) with a little > upgrading of some dependencies. > > CellSearch is now crashing in the static initializer for the > ROM_TABLES object. *sigh* > > Would anyone have an idea what may be is causing it? > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb773b910 (LWP 21087)] > 0x00f743fe in itpp::Vec<std::complex<double> >::set_size () from > /usr/local/lib/libitpp.so.7 > Current language: auto; currently asm > (gdb) where > #0 0x00f743fe in itpp::Vec<std::complex<double> >::set_size () from > /usr/local/lib/libitpp.so.7 > #1 0x00f74ada in itpp::Vec<std::complex<double> >::operator= () from > /usr/local/lib/libitpp.so.7 > #2 0x0808b0cd in PSS_fd::PSS_fd () > #3 0x08094444 in global constructors keyed to ROM_TABLES () > > Christian Are you still having problems with this? Can you try upgrading to the latest github code? I changed the initialization sequence for the ROM_TABLES and it might fix your problem too. BR, James

1 0