osmocom-sdr

osmocom-sdr@lists.osmocom.org

1 participants
910 discussions

feedback: Terratec ran - T Stick+
by Thomas Osterried 14 Apr '13

14 Apr '13

Hello, my feedback to http://sdr.osmocom.org/trac/wiki/rtl-sdr and the list of working devices: I buyed a "Terratec ran - T Stick+". It's working. lsusb shows the following IDs: Bus 005 Device 033: ID 0ccd:00d7 TerraTec Electronic GmbH It's a DVB / DAB/DAB+ stick (what ever this means - it's all about SDR ;). Buyed it at conrad for < 20 Eur. I found the device reading http://lehwalder.wordpress.com/2012/12/31/sdr-software-defined-radio/ It's already mentioned in http://www.randomprojects.org/wiki/Software_defined_radio#Terratec_ran_T_St… Thank you for your good work.. - Thomas

1 0

[PATCH 1/2] doxygen package needs to be detetected before the doxygen is used
by Jaroslav Škarvada 10 Apr '13

10 Apr '13

Without this patch the DOXYGEN_EXECUTABLE is set too late which results in build failure when processing swig directory (with ENABLE_DOXYGEN). Signed-off-by: Jaroslav Škarvada <jskarvad(a)redhat.com> --- CMakeLists.txt | 1 + docs/CMakeLists.txt | 5 ----- 2 files changed, 1 insertion(+), 5 deletions(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index a9334c8..a1af563 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -116,6 +116,7 @@ find_package(GnuradioFCD) find_package(LibOsmoSDR) find_package(LibRTLSDR) find_package(LibMiriSDR) +find_package(Doxygen) if(NOT GRUEL_FOUND) message(FATAL_ERROR "Gruel required to compile osmosdr") diff --git a/docs/CMakeLists.txt b/docs/CMakeLists.txt index f16fbf6..446b86a 100644 --- a/docs/CMakeLists.txt +++ b/docs/CMakeLists.txt @@ -18,11 +18,6 @@ # Boston, MA 02110-1301, USA. ######################################################################## -# Setup dependencies -######################################################################## -find_package(Doxygen) - -######################################################################## # Begin conditional configuration ######################################################################## if(ENABLE_DOXYGEN) -- 1.8.1.4

1 1

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 29 Mar '13

29 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 29 Mar '13

29 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 27 Mar '13

27 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 27 Mar '13

27 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

Simple SDR transmitter
by Mathias Coinchon 21 Mar '13

21 Mar '13

Hello, You may be interest by this project from Tipok: http://tipok.org.ua/node/41 It's a simplified and low cost SDR transmission interface using an FX2 USB controller and an AD9957 modulator/DAC. Here he's using it to create a DAB digital radio transmission using CRC mmbtools DAB multiplexer/modulator. Mathias opendigitalradio.org

1 0

Re: Re: R820T vs. E4000
by Al 18 Mar '13

18 Mar '13

Hi Hunz, I've just pushed some updated code up to GitHub, you can now set the gain in the preferences and tweak the scan settings. There's some info at http://eartoearoak.com/software/rtlsdr-scanner#tweaking A 250kHz offset seems to work well with my E4000, 140k with a FC0012 and 100k with a R820T. The FC0012 is the noisiest and the R820T is quietest. Hope it helps, Al On 17/03/2013 11:00, Benedikt Heinz <zn000h(a)gmail.com> wrote: >> For me the most interesting plots were the "no antenna" ones, showing the LO >> leakage ;-) If I understood clearly your plots, you have at some places high >> power ghosts. Maybe you are close to powerful transmitters, but this is more >> probably a LO to RF isolation problem: the receiver receives himself... > I did two new measurements with the gain set to 20 in RTLSDR-Scanner. > The files with the -gain20 in the filename [1] show the new results. > There are more spikes from the R820T LOs now, but it's still less than > with the E4000 I'd say. > The good thing is that the DVB-T stations as well as some other > signals can be found as expected now. > > 2013/3/16 Al <al(a)eartoearoak.com>: >> I think you've run into a couple of issues, firstly it appears that the AGC >> isn't fully disabled on the R820T (if you remove the aerial the noise floor >> increases). > It looks like gain=0 just was too little for the R820T. gain=20 seems > to be a good start. > Maybe exposing the gain-value in the regular UI would make sense? > >> Secondly RTLSDR-Scanner averages 2 chunks of bandwidth either side of the DC >> point, these seem relatively quiet with an E4000 and FC0012 but I haven't >> had chance to check the R820T yet. This tuner may have a very different >> noise floor. I was wondering about adding a feature to allow the user to >> pick their own segments (by terminating the aerial and looking at the noise >> distribution). > Ah, that's interesting. I was indeed wondering how you avoid the DC > spike and my pathon skills are close to zero ;-) > According to [2], the R820T doesn't use a Zero-IF, so there should be > no DC-spike at all. > >> Has anyone had a chance to test 2 different dongles with the same tuner? >> I'd be interested to know if it makes a difference to the noise floor, if >> there is little change, I could vary the scan based on the tuner. > I do have two E4000 and two R820T dongles, but I haven't yet compared > the noise floor. > I'm thinking about a per-dongle baseline file w/o an antenna for > compensation. This approach should be more robust. Otherwise you need > to shift the baseline spectrum according to the frequency error. > > Best regards, > > Hunz > > [1] https://docs.google.com/folder/d/0ByDAKwyEiyx_XzZ5ZnpRV1VZWDQ/edit?usp=shar… > [2] http://lists.osmocom.org/pipermail/osmocom-sdr/2012-September/000253.html >

1 0

← Newer
1
...
70
71
72
73
74
75
76
...
91
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr