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
> 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
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
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
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)
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)
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
I have been hacking into one of those $20 DVB-T TV Tuner Dongles. To get it
to tune to the Freq I want I use the usual method with the ExtIO Drivers.
The real problem with this thing, as far as making good use of the valuable
E4000, is the RTL2832, even though controlling the Tuner through the USB
requires the RTL2832. This clumsy Analog to Digital Converter / USB
interface Chip, does not have the Audio dynamic range needed for my
purposes. The infuriating predilection it has to crash every time you want
to shift frequency is another disadvantage.
Since the Owners of the E4000 have gone into Bankruptcy, I am taking the
initiative to hack the Tuner.
First, I attached a high gain audio amplifier's input directly to the
Tuner's output then to a 96K Sample per Second, 24 Bit Audio card to observe
a high quality spectral image from the tuner.
Next is to hack into and record the I2C sent to the Tuner, so it may be
controlled independent of that infuriating RTL2832. If anyone has done this,
please share your code and understanding.
Thanks
Jay Salsburg
Sent via the HTC V..b.livid™, anbURL: http://maps.google.com/maps?q=40.031769,-105.2;Kn)na?bks3213, 3128 Bell Dr, Boulder, CO 80301, USA AT&T 4G -3$/-)44+$LTE( (::,2mk:
----- Reply message -----
From: "Christian Gagneraud" <chris(a)techworks.ie>
To: "Dimitri Stolnikov" <horiz0n(a)gmx.net>
Cc: <discuss-gnuradio(a)gnu.org>, <osmocom-sdr(a)lists.osmocom.org>
Subject: [Discuss-gnuradio] FCD/Alsa bug (Re: Bug hunting)
Date: Wed, Aug 8, 2012 9:02 am
Cross posting to discuss-gnuradio.
The bug in question is that if you instanciate an alsa source on a busy device (opened by another app), then the program crashed.
On 08/08/12 00:23, Dimitri Stolnikov wrote:
> Hi Christian,
[...]
>
> The other problem (segfault on trow in ctor) still has to be addressed.
Yes, I started to investigate, and it seems to me that this is not a gr-osmosdr bug, but it's a gnuradio one, caused by gr-fcd.
This simple test program have the same problem, yet it only uses gr-fcd.
#include <iostream>
#include <fcd_source_c.h>
int main(int argc, char **argv)
{
fcd_source_c_sptr fsrc;
try {
fsrc = fcd_make_source_c("hw:2"); // KO, from gr-fcd
}
catch (std::runtime_error &e) {
std::cerr << "Error!\n";
}
exit(0);
}
g++ test.cc -o test -I/usr/local/include/gnuradio -lgnuradio-fcd
Here is the log:
audio_alsa_source[hw:2]: Device or resource busy
Error!
*** glibc detected *** /home/cgagneraud/sdr/gr-osmosdr/test: free(): invalid pointer: 0x08052e3c ***
[...]
And here is a cleaned up backtrace:
operator delete
gruel::msg_accepter::~msg_accepter
checked_delete<gr_hier_block2>
boost::detail::sp_counted_impl_p<gr_hier_block2>::dispose
[...]
const, boost::shared_ptr<gr_basic_block> > > >::~map
__cxa_finalize
__do_global_dtors_aux
[...]
main
The problem is related to gnuradio-core/src/lib/runtime/gr_sptr_magic.{h,cc} and the static std::map in there.
gr_hier_block2 ctor insert "this" in this map, but then in fcd_source ctor, audio_alsa_source ctor throws an exception, so "this" (gr_hier_block2/fcd_source) is not a valid pointer anymore.
When the program exits, the map get cleanup up and free is called on this pointer.
It's not possible to cleanup the map in fcd_source, because the dtor is not called when exception occurs in the ctor (which, btw, leads to some memory leaks in alsa_source: namely d_hw_params and d_sw_params).
It's a bad idea to call fetch_initial_sptr(this) before throwing in the ctor, because it seems the object get deleted.
First off, this is my first post to the group and I want to thank everyone
who has worked to get this kit as far as it is; I was deathly worried that
I might be stuck with unusable hardware, and it is still unusuable, but
there seems to be light at the end of the SDR tunnel and I'm hoping this is
the right forum for asking newbie questions :)
Here's where I am so far: I have the Hama Nano DVB-T+DAB+FM with the
Elonics E4000 tuner and my goal is really very modest (I hope) in that I
only want to tune in one ordinary analog FM station, the FM transmitter in
the next room that supplies our house with music from our MP3 collection.
Rather than pay $40 at walmart for a radio for my lab, I thought I'd spend
$20 on the USB device and have some fun in the process.
And it's been fun: I found the recipe for the rtl_fm using the alsa aplay,
and I assume the examples were concerned with some other sort of radio
(shortwave?) because the recommended 48k sampling sounded like a taxi
radio! Not really Easy Listening sort of audio.
with some experimenting I found a formula that is still heavily distorted,
but recognizable as music:
rtl_fm -f 96.3e6 -s 192000 -l 5 -| aplay -t raw -f s16_le -r 192k -c 1
the trouble was that it wouldn't play continuously on my 3300-bogomips
netbook, so I moved the code over to my 64-bit dual-core laptop and that's
where a strange thing happened: when run as a regular user, the code aborts
giving strange (unicode?) gibberish as the device name, but when run as
root, the name is correctly reported although the program aborts.
~/Work/dev$ rtl_fm -f 96.3k -s 192000 - | aplay -t raw -r 192k -f s16_le
Found 1 device(s):
0: , mX��, SN: ��z�
Using device 0: Generic RTL2832U (e.g. hama nano)
usb_open error -3
Failed to open rtlsdr device #0.
~/Work/dev$ sudo rtl_fm -f 96.3k -s 192000 - | aplay -t raw -r 192k -f
s16_le
Found 1 device(s):
0: Generic, RTL2832U, SN: 77771111153705700
Using device 0: Generic RTL2832U (e.g. hama nano)
usb_claim_interface error -6
Failed to open rtlsdr device #0.
on the 32-bit platform, the *Using device* line is followed by
Found Elonics E4000 tuner
Oversampling input by: 6x
Oversampling output by: 1x
is there perhaps some simple config setting that I've overlooked in the
64-bit box? Both are running Ubuntu 12.04
here are the kernel messages on loading the device on 64bit
Aug 9 13:47:58 strata kernel: [200306.632008] usb 3-1: new high-speed USB
device number 3 using xhci_hcd
Aug 9 13:47:58 strata kernel: [200306.663830] usb 3-1: ep 0x81 - rounding
interval to 32768 microframes, ep desc says 0 microframes
Aug 9 13:47:58 strata kernel: [200306.669822] dvb-usb: found a 'RTL2832U
DVB-T USB DEVICE' in warm state.
Aug 9 13:47:58 strata kernel: [200306.669840] dvb-usb: will pass the
complete MPEG2 transport stream to the software demuxer.
Aug 9 13:47:58 strata kernel: [200306.671500] DVB: registering new adapter
(RTL2832U DVB-T USB DEVICE)
Aug 9 13:47:58 strata kernel: [200306.689815] RTL2832U
usb_init_bulk_setting : USB2.0 HIGH SPEED (480Mb/s)
Aug 9 13:47:58 strata mtp-probe: checking bus 3, device 3:
"/sys/devices/pci0000:00/0000:00:1c.3/0000:09:00.0/usb3/3-1"
Aug 9 13:47:59 strata kernel: [200306.972506] RTL2832U check_tuner_type :
E4000 tuner on board...
Aug 9 13:47:59 strata mtp-probe: bus: 3, device: 3 was not an MTP device
Aug 9 13:47:59 strata kernel: [200307.552737] DVB: registering adapter 0
frontend 0 (Realtek DVB-T RTL2832)...
Aug 9 13:47:59 strata kernel: [200307.553116] input: IR-receiver inside an
USB DVB receiver as
/devices/pci0000:00/0000:00:1c.3/0000:09:00.0/usb3/3-1/input/input15
Aug 9 13:47:59 strata kernel: [200307.553243] dvb-usb: schedule remote
query interval to 287 msecs.
Aug 9 13:47:59 strata kernel: [200307.553251] dvb-usb: RTL2832U DVB-T USB
DEVICE successfully initialized and connected.
I notice that it DOESN'T say "*will pass the complete MPEG2 transport
stream to the software demuxer"* as it does on the 32bit side.
Also, what is the syntax for the -g switch? I have tried integers,
decimals and the string -3dB and in all cases I get the message *Warning:
Failed to set tuner gain* -- could the gain control simply be unsupported
by my device?
Lastly, I'd like to ask the hard question: are my goals here feasible? Is
this an appropriate device for listening to FM broadcasts at the computer
or is this more a hobbyist's SDR playground and, like a dancing bear, the
bear doesn't dance amazingling, it is only amazing that the bear dances at
all ;)
--
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*