- osmocom-sdr - lists.osmocom.org

AMR Receiver
by Douglas Hall 14 Feb '14

14 Feb '14

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

2 1

bug report
by Al Smith 13 Feb '14

13 Feb '14

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.

3 4

rtl_fm question
by Keith Conger 11 Feb '14

11 Feb '14

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

3 2

how to build gr-osmosdr for GnuRadio wheezy-raspbian distribution on Raspberry Pi
by Murat Toloğlu 10 Feb '14

10 Feb '14

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

1 0

odd results working at 250ksp/s
by David Jacobowitz 10 Feb '14

10 Feb '14

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

6 14

pfb_decimator_ccf(13): insufficient connected input ports (5 needed, 1 connected)
by JIANG Pin A 09 Feb '14

09 Feb '14

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

1 0

OsmoDevCon 2014: CFP
by Sylvain Munaut 05 Feb '14

05 Feb '14

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

1 0

UNSUBSCRIBE
by Jeff Miller 31 Jan '14

31 Jan '14

Jeff Miller 360.630.5073 _____ No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3684/7048 - Release Date: 01/31/14

1 0

new FM demodulator
by Anders Lynge Esbensen 31 Jan '14

31 Jan '14

Hi and thanks for a great tool set. I've implemented a faster FM demodulator for rlt_fm. Its an instantaneous frequency demodulator, like the already implemented atan method, but it uses some math tricks to get rid of the the actual atan calculation. Feel free to use it if you wish Best regards Anders

10 22

RE: kalibrate-rtl results...
by Jiao Xianjun 31 Jan '14

31 Jan '14

Though GSM spec has frequency hopping option, it can be switched on or off by operator. Yes, most operator switch it on. I think You too are talking different thing. GSM doesn't hops inside each 200khz channel. It hops among multiple 200khz channel. There is an exception: The downlink broadcasting carrier which carries FCCH SCH BCCH etc doesn't hop, and accordingly uplink RACH carrier doesn't hop either. These two uplink and downlink carrier frequency have a fixed 45MHz spacing if I recall correctly. I think most of calibration programs use downlink broadcasting carrier to calibrate the dongle, because it doesn't hop and is easy to be captured. You may also try my matlab calibration tool: https://github.com/JiaoXianjun/multi-rtl-sdr-calibration -----Original Message----- From: "Nikos Balkanas" <nikos.balkanas(a)eyeonix.com> Sent: ‎2014/‎1/‎31 19:13 To: "Ralph A. Schmid, dk5ras" <ralph(a)schmid.xxx> Cc: "osmocom-sdr(a)lists.osmocom.org" <osmocom-sdr(a)lists.osmocom.org>; "Richard Koch" <n1gp(a)hotmail.com> Subject: Re: kalibrate-rtl results... On Fri, Jan 31, 2014 at 12:47 PM, Ralph A. Schmid, dk5ras <ralph(a)schmid.xxx> wrote: GSM does not hop around inside its channel, this is wrong, the frequency is +- some Hz accurate, at least in normal western European commercial GSM networks. Are you sure about that? Check it out: https://svn.berlin.ccc.de/projects/airprobe/wiki/A Legend of first picture. If still in doubt that *most" GSM carriers are hoppers, use rtl_power to scan your region ;-) Nikos Ralph. From: osmocom-sdr-bounces(a)lists.osmocom.org [mailto:osmocom-sdr-bounces@lists.osmocom.org] On Behalf Of Nikos Balkanas Sent: Thursday, January 30, 2014 7:35 PM To: Richard Koch Cc: osmocom-sdr(a)lists.osmocom.org Subject: Re: kalibrate-rtl results... On Thu, Jan 30, 2014 at 8:21 PM, Richard Koch <n1gp(a)hotmail.com> wrote: I'm attempting to calibrate my RTL dongles. I notice they are all about 2-4khz off if I compare against a known broadcast station's frequency. I am trying out kalibrate-rtl and am getting varied results. I am in the US, so I did a 'kal -s EGSM -g 20' and got the following: chan: 991 (928.4MHz + 26.986kHz) power: 448020.99 chan: 1002 (930.6MHz - 5.631kHz) power: 320357.07 chan: 1003 (930.8MHz + 16.192kHz) power: 109489.92 Then 'kal -c CHANNELNUM -g 20' for each channel number. I then get the results below which the average frequency error looks different for each channel. It is consistent though if I run them multiple times. I would have expected less frequency error since I know that it is really only about 4Khz off. Or am I not reading the results correctly? Results seem OK. Do not forget that most BSTs hop around in their allotted 20 Khz channel. So a result of +/- 20 Khz shouldn't surprise you. Best calibrate against "anchor" BSTs that are steady. And yes, recommendation is to calibrate against 3 BSTs and correct for the average or stddev if you wish... Nikos -Rick Using device 0: Generic RTL2832U OEM Found Fitipower FC0013 tuner Exact sample rate is: 270833.002142 Hz Setting gain: 100.0 dB kal: Calculating clock frequency offset. Using E-GSM-900 channel 991 (928.4MHz) average [min, max] (range, stddev) + 21.342kHz [17837, 27433] (9596, 3402.206299) overruns: 0 not found: 199 average absolute error: -22.988 ppm Using device 0: Generic RTL2832U OEM Found Fitipower FC0013 tuner Exact sample rate is: 270833.002142 Hz Setting gain: 100.0 dB kal: Calculating clock frequency offset. Using E-GSM-900 channel 1002 (930.6MHz) average [min, max] (range, stddev) - 11.529kHz [-15293, -5679] (9614, 3640.780273) overruns: 0 not found: 194 average absolute error: 12.389 ppm Using device 0: Generic RTL2832U OEM Found Fitipower FC0013 tuner Exact sample rate is: 270833.002142 Hz Setting gain: 100.0 dB kal: Calculating clock frequency offset. Using E-GSM-900 channel 1003 (930.8MHz) average [min, max] (range, stddev) + 14.283kHz [9462, 19098] (9636, 4777.044922) overruns: 0 not found: 126 average absolute error: -15.345 ppm

1 0