Hi.
I just use the the RTL2832U and Rt820t dongle to scan the wireless and draw the specturm of what i get.
But i find the data i calculate is never bigger than -46dbm also never smaller than -63dbm.Is that the dongle's
receiving ability is just like that?
By the way, here is how i test the dongle:
1、i turn on a basestaion
2、i used the gsm module to detect the power of basestaion nearby,i get about -20dbm as the biggest
3、i used the dongle which i set its working frequency to the frequency that basestaion used
4、i calculate the spectrum using the data return by dongle(honestly, i used the rtl_power to calculate)
the result i calculate is never big than -46dbm,what a difference from the result from gsm module.
So i wonder whether the dongle's receiving abllity is just ordinary or the way i calculate is wrong?
Hi All:
I have gnuradio 3.6 running under FreeBSD 9.2. This is the latest port of gnuradio on that platform.
I would like to build gr-osmosdr so that I can use my Realtek USB dongle under gnuradio-companion.
I followed the procedure at http://sdr.osmocom.org/trac/wiki/GrOsmoSDR:
1) Got the source:
git clone git://git.osmocom.org/gr-osmosdr
cd gr-osmosdr/
2) Followed the direction for use with gnuradio 3.6:
git checkout gr3.6
3) Created the build environment:
mkdir build
cd build/
cmake ../
4) However, "make" fails with the following error:
make
[ 24%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o
/home/kevin/gr-osmosdr/lib/rtl/rtl_source_c.cc: In member function 'virtual osmosdr::freq_range_t rtl_source_c::get_freq_range(size_t)':
/home/kevin/gr-osmosdr/lib/rtl/rtl_source_c.cc:468: error: 'RTLSDR_TUNER_R828D' was not declared in this scope
/usr/local/include/boost/system/error_code.hpp: At global scope:
/usr/local/include/boost/system/error_code.hpp:222: warning: 'boost::system::posix_category' defined but not used
/usr/local/include/boost/system/error_code.hpp:223: warning: 'boost::system::errno_ecat' defined but not used
/usr/local/include/boost/system/error_code.hpp:224: warning: 'boost::system::native_ecat' defined but not used
*** [lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o] Error code 1
Stop in /usr/home/kevin/gr-osmosdr/build.
*** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error code 1
Stop in /usr/home/kevin/gr-osmosdr/build.
*** [all] Error code 1
Stop in /usr/home/kevin/gr-osmosdr/build.
I did some research on the error and the missing declaration.
While there is a previous post from another person who experienced this error, I can't follow the proven solution of "upgrade to gnuradio 3.7" as I expect that this would not be trivial, and in fact very complex, under FreeBSD. I have no porting/port conversion experience.
Just thought I'd ask if anyone else has experienced this, and whether there is a known solution.
Thanks,
Kevin
I just recently finished an rtl-sdr based automatic meter reading receiver
for smart commodity meters, thought it might be useful to add to the list
of known applications table on the wiki. I don't currently have a trac
account so I cannot add it myself.
Name: rtlamr
Source: https://github.com/bemasher/rtlamr
Blog Post: http://bemasher.github.io/rtlamr/2014/02/08/innards.html
-BeMasher
I'm getting some errors when using gnuradio-companion with the osmocom
source that I think might be a bug related to this patch:
cgit.osmocom.org/gr-osmosdr/commit/?id=e5f7b28093c10f05d272bcf12c6c4b6583af…
This is the output I get:
Using Volk machine: avx_32_mmx_orc
gr-osmosdr v0.1.0-66-g154c4ddd (0.1.1git) gnuradio 3.7.1
built-in source types: file fcd rtl_tcp bladerf rfspace
[bladeRF source] Using nuand LLC bladeRF #0 SN 909d...c10c FW v1.6.1 FPGA
v0.0.2
Failed to set out of bound frequency: 1.37912e+08
aUaUaUaUaUaUaU
When I look at the patch in the commit I linked above that error relates to
setting the input frequency. There are 2 expected parameters
get_freq_range( chan ).start() get_freq_range( chan ).stop() but in the GUI
osmocom source there is only Ch0 Frequency (center) and Ch0 Bandwidth, both
of which I have set. I don't see a way to define the start and stop
frequency which seems to be generating this error.
Hi,
I would love to see rtl_fm get support to connect to a rtl_tcp server. Are
there any plans to add this?
Thanks
--
Keith Conger
keith DOT conger AT gmail DOT com
http://thecongers.org
Hi All,
I have easily and smoothly installed GnuRadio 3.7.2.1 on Raspberry Pi with
this procedure:
1. Add the following entry to the /etc/apt/sources.list file:
deb http://mirrordirector.raspbian.org/raspbian/ jessie main contrib
non-free rpi
(reboot after modification)
2. sudo apt-get update
3. sudo apt-get install gnuradio
Installation completed in about 1 hour and GnuRadio together with GnuRadio
Companion Works on my RPi.
However, when it comes to build Gr-Osmosdr trouble starts. I couldn't pass
the CMAKE stage of Gr-Osmosdr build process.
I remembered and applied the classical "export PATH, PYTHOPATH,
LD_LIBRARY_PATH, PKG_CONFIG_PATH correction" and added necessary lines at
the end of ./.bashrc . My install directory was /usr (without /local) !??
anyway I've added /usr/bin, /usr/lib ..etc. to appropriate places but this
couldn't be a solution.
Cmake couldn't find GnuradioConfig.cmake file, I found this file of the
same version on my other computer running without problem and copied the
missed file into correct directory on Rpi. This couldn't be the solution
either.
Then, Cmake couldn't locate gnuradio-runtime.pc file, similarly I copied
gnuradio-runtime.pc of same version from another computer to RPi but this
couldn't be a solution either.
Now I get the same error message of this :
http://gnuradio.org/redmine/issues/591 (Unable to compile out of tree
projects due to wrong FindGnuradio.cmake)
I am really tired. I have enough experience on installing - uninstalling
Gnuradio building from the source, I have made this install uninstall
building process several times but I am first time trying installation of a
built gnuradio.
Is there a way of recovering the existing install and continue building out
of tree projects ?
I appreciate your help,
Kind regards 73
Murat TA1DB
Hi,
I've been working on a project the involves tuning VOR signals. They are
narrow band signals. > 25 kHz. For that, the wide bandwidth of the RTL
dongles isn't that helpful to me. (and actually a hindrance when two
signals are inside the sample range but widely different strengths)
Anyway, the lowest I can get my dongles (R820T) to go is 250ksps, which is
fine. I've been working at that frequency for awhile, but getting some
strange results. For example, if I tune in to 116.8 MHz, which should be
the OAK VOR, it works fine. But if I tune to 115.8 MHz, which should be the
SFO VOR I get ... the OAK VOR. That is, there is a perfect copy of the OAK
signal 1 MHz shifted down.
If I switch the sample rate to 1.024Msps or 900ksps, I don't get this
problem.
I don't understand what is happening here. 1 MHz is an even multiple of
250kHz, so maybe I'm getting an image of OAK overpowering the relatively
weaker SFO signal. But should there not be filters that manage this?
I guess I was expecting that if the device is set to 250ksps, then it would
"close down" filters appropriately to reject signals out of that band. But
maybe the filters don't work properly below a certain sample rate? Like the
rtl2832 can sample down to 250ksps, but the 820T tuner was not designed for
it?
Or perhaps I'm doing something wrong? Can I control the filters directly?
I'm glad I find this issue because I was going nuts thinking my software
had some mysterious bug. But I can reproduce this issue just with SDR# or
whatever. :-)
Regards.
Dave J
Hi, all
I try to re-structure the osmo-tetra to work with GNU Radio 3.7. The osmo-tetra is based on GNU Radio 3.6.
The original code has tuner, resampler, demodulater three modules which connected sequentially.
The resampler is based on function pfb_decimator_ccf which changes from 3.6 to 3.7. The pfb_decimator_ccf only take single parameter decimation, which changes in 3.7,
After reading the manual of 3.7, I made following changes to the python script :
Add a low-pass filter " taps = filter.firdes.low_pass_2(1, fs, options.low_pass, options.low_pass * 0.2, attenuation_dB=ATT, window=filter.firdes.WIN_BLACKMAN_hARRIS) "
Change "self.resamp = blks2.pfb_decimator_ccf(int(rerate)) " to " self.resamp = filter.pfb_decimator.ccf(int(rerate), taps, 0) "
But error still occurs when connecting modules " self.connect(self.src, self.tuner, self.resamp, self.demod, self.output) " :
Traceback (most recent call last):
File "./osmosdr-tetra_demod_fft.py", line 264, in <module>
tb.Run(True)
File "/usr/local/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py", line 82, in Run
self.Start(start, max_nouts)
File "/usr/local/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py", line 73, in Start
self.start()
File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 103, in start
top_block_start_unlocked(self._tb, max_noutput_items)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line 4612, in top_block_start_unlocked
return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
RuntimeError: pfb_decimator_ccf(13): insufficient connected input ports (5 needed, 1 connected)
Does it indicate pfb_decimator_ccf take 5 inputs ? It puzzled me.
Best Regards, Jiang Pin
Dear all,
Time has come to fill out the "Talks/Discussions/Workshop / Hacking"
section of the wiki page.
If you have something you'd like to present, talk about or hack on,
add it there. A simple descriptive title along with an estimated
duration is enough.
I guess we'll collect those for 2/3 weeks and then start making the schedule.
Cheers,
Sylvain
