osmocom-sdr March 2013

osmocom-sdr@lists.osmocom.org

31 participants
25 discussions

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

[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: 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

RTL_TCP Output
by Chris Svendsen 31 Mar '13

31 Mar '13

I am attempting to write a program in c++ to transform the output of RTL_TCP to an audio device as nFM 12500 bandwidth. The problem is I have no idea where to even start could someone point me in the right direction to find out what format the out put of RTL_TCP is or where to find some documentation on how to even start converting it to audio. thanks for your time

2 1

Re: "ld: warning: could not create compact unwind for rtl_source_c::rtl_source_" while building gr-osmosdr
by Trillium 2024 28 Mar '13

28 Mar '13

Please disregard my previous posting. Setting the compiler flag "-march=native" eliminated the error messages.

1 0

"ld: warning: could not create compact unwind for rtl_source_c::rtl_source_" while building gr-osmosdr
by Trillium 2024 28 Mar '13

28 Mar '13

Hello, Thank you for your great software! While building gr-osmosdr yesterday and the day before, I have been getting this new error while compiling. The compiler is gcc 4.7 under Os X 10.5.8 I'm also having unexplained crashes.. Applications that use the library are having issues. Here is the complete message. It occurs twice, Linking CXX shared library libgnuradio-osmosdr.dylib cd /Volumes/xyz/builds/osmocom/gr-osmosdr/build/lib && "/Applications/CMake 2.8-7.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/gnuradio-osmosdr.dir/link.txt --verbose=1 /opt/local/bin/i386-apple-darwin9-g++-mp-4.7 -O3 -DNDEBUG -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -dynamiclib -Wl,-headerpad_max_install_names -compatibility_version 0.0.1 -o libgnuradio-osmosdr.0.0.1git.dylib -install_name /Volumes/xyz/builds/osmocom/gr-osmosdr/build/lib/libgnuradio-osmosdr.0.0.1git.dylib CMakeFiles/gnuradio-osmosdr.dir/osmosdr_source_c_impl.cc.o CMakeFiles/gnuradio-osmosdr.dir/osmosdr_sink_c_impl.cc.o CMakeFiles/gnuradio-osmosdr.dir/osmosdr_ranges.cc.o CMakeFiles/gnuradio-osmosdr.dir/osmosdr_device.cc.o CMakeFiles/gnuradio-osmosdr.dir/file/file_source_c.cc.o CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o CMakeFiles/gnuradio-osmosdr.dir/rtl_tcp/rtl_tcp_source_f.cc.o CMakeFiles/gnuradio-osmosdr.dir/rtl_tcp/rtl_tcp_source_c.cc.o -L/opt/local/lib /opt/local/lib/libboost_thread-mt.dylib /opt/local/lib/libboost_system-mt.dylib /opt/local/lib/libgruel.dylib /opt/local/lib/libgnuradio-core.dylib /opt/local/lib/libgnuradio-core.dylib /opt/local/lib/librtlsdr.dylib /opt/local/lib/libgnuradio-core.dylib /opt/local/lib/librtlsdr.dylib ld: warning: could not create compact unwind for rtl_source_c::rtl_source_c(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&): stack subq instruction is too different from dwarf stack size ld: warning: could not create compact unwind for rtl_source_c::rtl_source_c(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&): stack subq instruction is too different from dwarf stack size ..... Then a few lines down, it happens a second time.. Linking CXX shared module _osmosdr_swig.so cd /Volumes/xyz/builds/osmocom/gr-osmosdr/build/swig && "/Applications/CMake 2.8-7.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/_osmosdr_swig.dir/link.txt --verbose=1 /opt/local/bin/i386-apple-darwin9-g++-mp-4.7 -O3 -DNDEBUG -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -bundle -Wl,-headerpad_max_install_names -o _osmosdr_swig.so CMakeFiles/_osmosdr_swig.dir/osmosdr_swigPYTHON_wrap.cxx.o -L/opt/local/lib /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib ../lib/libgnuradio-osmosdr.0.0.1git.dylib /opt/local/lib/libboost_thread-mt.dylib /opt/local/lib/libboost_system-mt.dylib /opt/local/lib/libgruel.dylib /opt/local/lib/libgnuradio-core.dylib /opt/local/lib/librtlsdr.dylib /opt/local/lib/libgnuradio-core.dylib /opt/local/lib/librtlsdr.dylib ld: warning: could not create compact unwind for swig::SwigPySequence_Ref<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >::operator std::basic_string<char, std::char_traits<char>, std::allocator<char> >() const: stack subq instruction is too different from dwarf stack size ld: warning: could not create compact unwind for swig::SwigPySequence_Ref<osmosdr::device_t>::operator osmosdr::device_t() const: stack subq instruction is too different from dwarf stack size ld: warning: could not create compact unwind for swig::SwigPySequence_Ref<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::operator std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >() const: stack subq instruction is too different from dwarf stack size ld: warning: could not create compact unwind for swig::SwigPySequence_Ref<osmosdr::range_t>::operator osmosdr::range_t() const: stack subq instruction is too different from dwarf stack size ???

1 0

Broadcast FM subcarrier decoding?
by Alan Corey 28 Mar '13

28 Mar '13

This might be a better question for the Gnuradio list, but for years I've known that some broadcast FM stations actually transmit a second audio program which is somehow modulating a subcarrier in the main transmission. It probably carries mostly elevator music type junk but is rumored to be commercial-free (a rare thing in the US!). I remember seeing dedicated receivers advertised for this, but never actually bought one because I wasn't sure it was active in my area. These date back to Lafayette Electronics days I think and ever since so 40 years or more. I've noticed (in SdrSharp) that on some FM stations I can see what look like they might be subcarriers on either side of the main signal. Anyone decoded those? Alan ----- Radio Astronomy - the ultimate DX

5 6

RTL_TCP Commands
by Chris Svendsen 26 Mar '13

26 Mar '13

Sending commands to RTL_TCP What format do the commands need to be in order to change the frequency of RTL_TCP. I have tried the following and the frequency will change but no to the frequency that is expected for example: This code : char SET_FREQUENCY[] ={0x01}; string Freq = string(SET_FREQUENCY,1)+"500000000"; answer = send(sConnect,Freq.c_str(),11,0); Changes the freq to this: client accepted! set freq 892350512 ll+, now 1 ll+, now 2 Any help would be greatly appreciated as i have been stuck on this for days. Thanks

2 3

RTL_TCP Commands
by Chris Svendsen 26 Mar '13

26 Mar '13

Thank you all for the quick response. Unfortunately I'm still having some trouble. This is what I have so far ( Its a lil messy but just for testing it should work ) This is based on the Client implementation: http://cgit.osmocom.org/gr-osmosdr/tree/lib/rtl_tcp/rtl_tcp_source_f.cc#n275 #define COMM_SET_FREQ ((unsigned char) 0x01) struct command{ unsigned char cmd; unsigned int param; }; unsigned char cmds; int iFreq = 500000000; cmds = COMM_SET_FREQ; struct command cmd = {cmds, htonl(iFreq)}; answer = send(sConnect, (const char*)&cmd, sizeof(cmd), 0); and the response is : client accepted! set freq -858993635 ll+, now 1 ll+, now 2 ll+, now 3 I'm sure I'm missing something I just don't know what. Thanks

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr March 2013