osmocom-sdr August 2012

osmocom-sdr@lists.osmocom.org

17 participants
20 discussions

Mis-detected E4000 instead of FC0013 tuner when using NOXON DAB Stick on Raspberry Pi
by Christoph Gommel 18 Oct '12

18 Oct '12

Hello Guys, First of all: I am amazed by your project - many ideas come up in my head what can be done with this tiny cheap SDR. I have tested rtl_sdr with a linux-vm on my Mac successfully but wanted to run it on my raspberry pi. Unfortunately and thithout an explainable reason to me the tools detect an E4000 instead of the soldered FC0013 on my stick - but only on the PI. To fix this issue I have changed the detection order in librtlsdr.c: diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 3a67b53..cb34f1d 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -1073,13 +1073,6 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) /* Probe tuners */ rtlsdr_set_i2c_repeater(dev, 1); - reg = rtlsdr_i2c_read_reg(dev, E4K_I2C_ADDR, E4K_CHECK_ADDR); - if (reg == E4K_CHECK_VAL) { - fprintf(stderr, "Found Elonics E4000 tuner\n"); - dev->tuner_type = RTLSDR_TUNER_E4000; - goto found; - } - reg = rtlsdr_i2c_read_reg(dev, FC0013_I2C_ADDR, FC0013_CHECK_ADDR); if (reg == FC0013_CHECK_VAL) { fprintf(stderr, "Found Fitipower FC0013 tuner\n"); @@ -1088,6 +1081,13 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) goto found; } + reg = rtlsdr_i2c_read_reg(dev, E4K_I2C_ADDR, E4K_CHECK_ADDR); + if (reg == E4K_CHECK_VAL) { + fprintf(stderr, "Found Elonics E4000 tuner\n"); + dev->tuner_type = RTLSDR_TUNER_E4000; + goto found; + } + /* initialise GPIOs */ rtlsdr_set_gpio_output(dev, 5); After compiling the lib the FC0013 is detected and the sticks works great on my Pi. Of course this is not a perfect solution and I will figure out later in depth WHY the E4K_CHECK_VAL comes out of the FC0013. Anybody else who has or had the same problems? the Hardware used is: Bus 001 Device 004: ID 0ccd:00b3 TerraTec Electronic GmbH NOXON DAB/DAB+ Stick regards Christoph

5 4

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

RTL_FM fails on OS X
by Christoph Gommel 25 Aug '12

25 Aug '12

Hello, I was completely happy that rtl-sdr builds without any problems in my iMac (with OSX 10.8.1 and latest Macports). Using a RLT2832-Dongle that is plugged into my mac on other machines via rtl_tcp works well, also recording data is working. What fails is running rtl_fm: iGommel:build chg$ rtl_fm -f 97300000 -s 44100 test.raw Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000291 Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Elonics E4000 tuner Oversampling input by: 23x. Oversampling output by: 1x. Buffer size: 8.08ms Tuned to 97553575 Hz. Sampling at 1014300 Hz. Exact sample rate is: 1014300.020041 Hz Tuner gain set to -1.00 dB. Floating point exception: 8 Unfortunately i don't have the debugging skills to find the position of the Floating point exception without a high-level GUI ;) Any idea what can be done by me to help chasing the bug? Christoph

1 0

BONANZA - The e4000 *complete* reference document :)
by Ben Ryan 22 Aug '12

22 Aug '12

Hey all, Got some gold for ya's. Registers, the works. Even a reference design schematic. Grab it while it's hot, before the lawyers catch on.. and thanks guys for all your hard work with RTLSDR! https://skydrive.live.com/redir?resid=E55F3F5F75B5A7BB!1160

1 0

[benzandstra@caiway.nl: Small comment about the rtl-sdr wiki]
by Harald Welte 21 Aug '12

21 Aug '12

FYI, -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

[jarribas@cttc.es: GNSS-SDR now supports the RTLSDR signal source]
by Harald Welte 17 Aug '12

17 Aug '12

Hi all! I'm forwarding this announcement from the GNSS-SDR developers. I will also put it on the sdr.osmocom.org site. Congratulations to steve-m, horizon, hoernchen and the team! Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Say Enter "RTL readlen=524288" in the 'ExtIO : Device hint' edit field, when that is what you mean
by Jay Salsburg 17 Aug '12

17 Aug '12

OK I get it. I wish those who write this stuff were not so Cryptic and Acronymous. On this page ... http://wiki.spench.net/wiki/USRP_Interfaces the author has an entry that looks like this "RTL readlen=524288" yet nowhere in the immediate text is there any language stating to enter this text in the 'ExtIO : Device hint' edit field, you have to sort of guess the author thoughts. No one is ever thinking like the one who is doing the original thinking so to reproduce original thinking adequate references to what the author is thinking is required to reproduce the original thoughts in the reader's mind. Literate illustration makes everything so much easier (and a liberal sprinkling screen shots). Thanks Jay Salsburg

4 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr August 2012