April 2013 - osmocom-sdr - lists.osmocom.org

R820T vs. E4000
by Benedikt Heinz 09 Sep '13

09 Sep '13

Hi everyone, although there are some comparisons between the R820T and the E4000 already [1, 2], I also did some tests with another use-case in mind. I'm working on a thing similar to RTLSDR-Scanner [3]. I want to monitor a large part of the spectrum continuously. So I compared the R820T with the E4000 using RTLSDR-Scanner w/ and w/o an antenna. My results are here: https://docs.google.com/folder/d/0ByDAKwyEiyx_XzZ5ZnpRV1VZWDQ/edit?usp=shar… There's much more spurs with the E4000 than w/ the R820T. According to [1, 2] one also would expect a better overall sensivity compared to the E4000. However, the GSM900 signals for example seem to be way better with the E4000 according to the RTLSDR-Scanner. Tuning to a certain channel w/ OsmoSDR Source in GNUradio gives about the same SNR - contrary to the RTLSDR-Scanner output. Can anyone explain this? Also, the DVB-T channel at 502MHz is quite weak in the R820T RTLSDR-Scanner output when compared to the E4000. I had a closer look at the lower limit of the channel in gnuradio. This can be seen in the 502MHz_*.png pictures. The E4000 produces a nice +20dB step while one can hardly see the channel in the R820T spectrum. I don't understand this as well. Is this AGC-related? Manually setting a fixed gain didn't really help though... Any explanations? Thank you! Best regards, Hunz [1] http://steve-m.de/projects/rtl-sdr/tuner_comparison/ [2] http://www.hamradioscience.com/rtl2832u-r820t-vs-rtl2832u-e4000/#more-1852 [3] https://github.com/EarToEarOak/RTLSDR-Scanner

5 5

OpenBSD: crashing
by Alan Corey 18 Aug '13

18 Aug '13

This is with a version of rtl-sdr I got by git last night and OpenBSD 5.2 (current release). 5.2 has some pthreads fixing so I waited until I bought another computer and loaded it. Are the crashes related to threads? I don't know, but possibly. It didn't work with OpenBSD 5.0 either. rtl_fm crashes and uses threads rtl_adsb crashes and uses threads rtl_tcp doesn't crash, uses threads, actually stops on ctrl-c rtl_test doesn't crash, doesn't use threads, won't stop rtl_eeprom doesn't crash, doesn't use threads, ends normally I'm not real practiced using gdb but I tried looking at a couple of core files, here's a run of rtl_fm: rtl_fm -f 162550000 -N - | play -t raw -r 24k -e signed-integer -b 16 -c 1 -V1 - -: (raw) Encoding: Signed PCM Channels: 1 @ 16-bit Samplerate: 24000Hz Replaygain: off Duration: unknown In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [ | ] Clip:0 Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000013 Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Rafael Micro R820T tuner Oversampling input by: 42x. Oversampling output by: 1x. Buffer size: 8.13ms Tuned to 162802000 Hz. Sampling at 1008000 Hz. Output at 24000 Hz. Exact sample rate is: 1008000.009613 Hz Tuner gain set to automatic. In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [ | ] Clip:0 Done. Abort (core dumped) d530# gdb -c rtl_fm.core /usr/local/bin/rtl_fm GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-openbsd5.2"... Core was generated by `rtl_fm'. Program terminated with signal 6, Aborted. Reading symbols from /usr/lib/libpthread.so.16.0...done. Loaded symbols for /usr/lib/libpthread.so.16.0 Reading symbols from /usr/lib/libm.so.7.0...done. Loaded symbols for /usr/lib/libm.so.7.0 Reading symbols from /usr/local/lib/librtlsdr.so.0.0...done. Loaded symbols for /usr/local/lib/librtlsdr.so.0.0 Reading symbols from /usr/local/lib/libusb-1.0.so.1.0...done. Loaded symbols for /usr/local/lib/libusb-1.0.so.1.0 Symbols already loaded for /usr/lib/libpthread.so.16.0 Reading symbols from /usr/lib/libc.so.65.0...done. Loaded symbols for /usr/lib/libc.so.65.0 Loaded symbols for /usr/libexec/ld.so #0 0x0abbd98d in kill () from /usr/lib/libc.so.65.0 (gdb) bt #0 0x0abbd98d in kill () from /usr/lib/libc.so.65.0 #1 0x0ac29545 in abort () at /usr/src/lib/libc/stdlib/abort.c:68 #2 0x005e9298 in pthread_mutex_unlock (mutexp=0x3c003d8c) at /usr/src/lib/librthread/rthread_sync.c:218 #3 0x1c00266e in full_demod (fm=0xcfa2de5c) at /usr/src/misc/osmocom/2013-04-15/rtl-sdr/src/rtl_fm.c:583 #4 0x1c0028ff in demod_thread_fn (arg=0xcfa2de5c) at /usr/src/misc/osmocom/2013-04-15/rtl-sdr/src/rtl_fm.c:641 #5 0x005ebc2e in _rthread_start (v=0x84da4c00) at /usr/src/lib/librthread/rthread.c:111 #6 0x0aba62e9 in __tfork_thread () from /usr/lib/libc.so.65.0 The backtrace (bt) shows that it dies trying to do a mutex_unlock (I think). rtl_tcp also does a mutex_unlock and it doesn't crash. I'm probably reading it wrong for all I know. I don't know what's causing the signal 6 either. I'd also like to get the -lrt of of the cmake files. OpenBSD doesn't use or have lrt, it works without. I can edit it out and compile, but every time I run cmake again, I have to edit the files again. Alan ----- Radio Astronomy - the ultimate DX

5 10

[rtl-sdr] store frequency correction in eeprom?
by Benedikt Heinz 30 May '13

30 May '13

Some of you are probably using multiple dongles with alternating applications as well. Regarding the frequency correction, I put a sticker on each dongle and wrote the ppm value on it. However manually setting the value in each application is still annoying. So I used rtl_eeprom to write the value into the product-ID with the following format: "RTL%+dppm" resulting in sth. like this: RTL+87ppm I'm not sure if this is the best way to do it, but this approach works without changing librtlsdr. Another option might be storing the value in a non-used eeprom location and adding get/set functions to librtlsdr. Is it possible to write arbitrary values to unused eeprom locations without fucking up the realtek eeprom handling? Do you think this would be a better way? I'd like to hear your comments on this. It would be awesome if we could find a solution that many existing applications could incorporate. (Of course the ppm value still changes with temperature, but having a base value is still closer to the truth than 0ppm I'd say. I measured the offset directly after grabbing samples for 20 minutes at room-temperature and jitter is <1ppm.) Best regards, Hunz

4 3

R820T register map available
by Adam Nielsen 02 May '13

02 May '13

Hi all, One of the designers of the R820T tuner has recently been posting on the ultra-cheap-sdr group, and has kindly supplied a map of the R820T registers for private use only within the SDR community. He has asked that it not be posted on any website, but only be forwarded around privately. To that end, if anyone would like a copy of this spreadsheet and would be willing to likewise not publish it on the web, let me know off-list and I'll send it to you. There's not a huge amount in the way of explanations, but it lists all the registers and a very brief description of what they do. Cheers, Adam.

3 2

Re: [Discuss-gnuradio] nVidia's Tegra 4 has SDR - the i500 LTE soft modem from Icera
by est 02 May '13

02 May '13

Hello group, What do you guys think of the nVidia Tegra 4's i500 SDR? http://www.engadget.com/2013/01/07/nvidia-i500-soft-modem/ http://www.nvidia.com/docs/IO/116757/NVIDIA_i500_whitepaper_FINALv3.pdf Is it hackable?

3 3

Compiling on osx - solved...
by Alberto Albiol 01 May '13

01 May '13

Hello I have been fighting to compile the gr-osmosdr package in my osx These are the minor fixes I had to do: 1- Change in Cmakelists.txt: find_package(Boost COMPONENTS thread system), If thread and system is not included then there are linking problems. Although I see that this was removed recently... 2- cmake -DCMAKE_INSTALL_PREFIX=/opt/local (so it is installed together wit my ports intallation, this is really optional) 3- Before compiling I manually edit CmakeCache.txt, and change all the references of /usr/lib/python to /opt/local/lib/python. If not it links agains the system python instead of the ports's python! 4- Add this line in my .bashrc so python can find the package export PYTHONPATH="/opt/local/lib/python2.7/site-packages/" I am aware that this is not the most elegant way to solve the problem but is the only one that I was able to come up. Hope it helps Regards

3 3

Re: rtl_fm scanning
by Colin Stagner 01 May '13

01 May '13

I am also having the rtl_fm scanning bug which was first reported in http://lists.gnumonks.org/pipermail/osmocom-sdr/2013-February/000485.html The scanning mode in rtl_fm hangs during the re-tuning process. This makes it impossible to use rtl_fm in scanning mode. I am using Ubuntu 12.10 with libusb 2:1.0.12-2, the latest git master version of rtl-sdr, and an Elonics E4000 (Realtek, RTL2838UHIDIR). Here are the steps to reproduce: 1. Find some frequency FREQ_NOISE that is not in use, and some frequency FREQ_SIGNAL which is in use constantly (i.e., like a commercial FM station). Find an appropriate squelch value SQUELCH which will stop FREQ_NOISE but pass FREQ_SIGNAL. 2. rtl_fm -f ${FREQ_NOISE} -l ${SQUELCH}. The program should not pass any audio, but it will exit cleanly with ^C. 3. rtl_fm -f ${FREQ_SIGNAL} -l ${SQUELCH}. The program should pass audio and exit cleanly with ^C 4. rtl_fm -f ${FREQ_SIGNAL} -f ${FREQ_NOISE} -l 0. The scan will pause on the first channel and pass audio. 5. rtl_fm -f ${FREQ_NOISE} -f ${FREQ_SIGNAL} -l ${SQUELCH}. The program will not output any audio, even though the first frequency is squelched out and the scanning function should skip immediately to the second frequency. Additionally, it will not exit if sent a SIGINT with ^C, and it must be killed with a SIGKILL. I've made a stack trace of this behavior. The program hangs very consistently at the same location each time: http://pastebin.com/wzE09MCi Thread 1 (the USB buffer reading thread) hangs while waiting for the data_write mutex lock in rtl_fm.c:642. I presume the thread has exhausted its supply of data and isn't getting any more. Thread 2 is slightly more interesting, because it hangs during the libusb system calls within the tuning function rtlsdr_set_center_freq() in librtlsdr.c:796. My guess is that it's making a blocking call that never returns. Can anyone else reproduce this bug?

4 4

submitting patches
by Michael Davis 30 Apr '13

30 Apr '13

Hi All, Can anyone point me in the direction of a place I can go to submit patches? I fixed a bug in CMake for gnuradio-osmosdr that stopped the build on my system. Best, Mike

2 1

Scanning with rtl_fm
by Alan Corey 28 Apr '13

28 Apr '13

I'm using rtl_fm in a scanning (nbfm) situation, and even with the antenna input disconnected and terminated, I get a burst of noise that sounds like a squelch tail maybe once each scan cycle. They're a little over 1 second apart. I've tried setting the squelch up to 10000 where I don't get signals anymore, but I still get the noise. I discovered that if you scan and have the output be a raw audio file, nothing gets recorded when nothing breaks squelch. This makes time-lapse recordings where all the pauses are taken out. Very nice, except for the noise bursts. I'm using: #!/bin/sh rtl_fm -N -S -l 132 -p 102 -f 854040000 -f 854240000 -f 854315000 -f 854415000 -f \ 854490000 -f 854540000 -f 855165000 -f 855240000 -f 858790000 -f 867350000 \ -f 867715000 /tmp/`date +"%Y-%m-%d_%H%M.raw"` and recorded overnight, but I mostly got noise bursts. Alan ----- Radio Astronomy - the ultimate DX

2 2

gr-iqbal or gr-iqbalance?
by Wojciech Kazubski 28 Apr '13

28 Apr '13

Hello! This is a minor issue, but may lead to some misunderstanding (and seach failures) in future. The package to correct IQ imbalance is registered at http://cgit.osmocom.org as gr-iqbal but project name set in line 24 of toplevel CMakeList.txt is gr- iqbalance. Which name should be used while building packages, etc.? BTW: Is there any homepage for gr-iqbal/gr-iqbalance? Wojciech Kazubski

2 1