osmocom-sdr

osmocom-sdr@lists.osmocom.org

904 discussions

gr-osmosdr build problem
by Wojciech Kazubski 15 Apr '13

15 Apr '13

Hello! Fo some time I am unable to build gr-osmosdr with enabled documentation. ... cmake -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_DOXYGEN=1 ../ make -j2 ... The build fails with the following error: ... [ 151s] [ 26%] Built target doxygen_target [ 151s] Scanning dependencies of target osmosdr_swig_swig_doc [ 151s] [ 30%] Generating doxygen xml for osmosdr_swig_doc docs [ 151s] /bin/sh: osmosdr_swig_doc_swig_docs/Doxyfile: Permission denied [ 151s] make[2]: *** [swig/osmosdr_swig_doc_swig_docs/xml/index.xml] Error 126 [ 151s] make[1]: *** [swig/CMakeFiles/osmosdr_swig_swig_doc.dir/all] Error 2 [ 151s] make[1]: *** Waiting for unfinished jobs.... ... This happen after this commit: http://cgit.osmocom.org/gr-osmosdr/commit/?id=dc28f6c4c874e182557c8cb9fe8a0… (the last one from Feb 16 2013) For me, it looks like an attempt to run Doxyfile directly and not process it by doxygen. Wojciech Kazubski

2 3

RTL offset with kalibrate-rtl
by Nuno Gonçalves 15 Apr '13

15 Apr '13

I have a stick with the R820T Tunner. Using SDR# and SDR-Radio V2, and tunning to FRS and Airband transmitters I determined that my offset is consistent to 54-63 PPM. On the other hand kalibrate-rtl reports my offset to be about -30PPM, also consistently accross several tests. Is there possibly any difference from 100 (Airband), 400 (FRS) and 900ish (GSM) Mhz? I am at Portugal, so the network is probably a GSM900 and also I don't get something as NOAA narrow channels to figure this out. GSM-900: chan: 10 (937.0MHz + 27.986kHz) power: 29372.03 chan: 30 (941.0MHz + 26.850kHz) power: 197782.82 chan: 50 (945.0MHz + 26.645kHz) power: 86521.18 chan: 62 (947.4MHz + 27.109kHz) power: 29501.15 chan: 74 (949.8MHz + 26.605kHz) power: 56078.03 chan: 107 (956.4MHz + 26.442kHz) power: 57536.25 chan: 112 (957.4MHz + 25.319kHz) power: 31011.95 chan: 121 (959.2MHz + 25.145kHz) power: 87002.34 E-GSM-900: chan: 10 (937.0MHz + 27.514kHz) power: 27631.40 chan: 30 (941.0MHz + 26.395kHz) power: 211497.68 chan: 50 (945.0MHz + 26.209kHz) power: 88871.46 chan: 62 (947.4MHz + 26.629kHz) power: 27770.99 chan: 74 (949.8MHz + 26.181kHz) power: 56274.60 chan: 107 (956.4MHz + 25.984kHz) power: 47437.43 chan: 112 (957.4MHz + 24.878kHz) power: 25791.29 chan: 121 (959.2MHz + 24.765kHz) power: 98473.19 What can be going on here? Also, what is the reason for the dropped samples when sampling over 2.8MS/s? Is it a RTL2832 issue or something related to the USB driver? Regards, Nuno

1 0

[PATCH] rtl-sdr: add support for lib64 (e.g. Fedora)
by Jaroslav Skarvada 14 Apr '13

14 Apr '13

From: "Jaroslav Škarvada" <jskarvad(a)redhat.com> To: laforge(a)gnumonks.org Cc: "Jaroslav Škarvada" <jskarvad(a)redhat.com> Sent: Thursday, April 4, 2013 3:36:18 PM Subject: [PATCH] rtl-sdr: add support for lib64 (e.g. Fedora) Another possibility is to use the GrPlatform.cmake module. Signed-off-by: Jaroslav Škarvada <jskarvad(a)redhat.com> --- CMakeLists.txt | 8 ++++++-- src/CMakeLists.txt | 4 ++-- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index f3ef31e..b113311 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -33,6 +33,10 @@ set(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING "") list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/Modules) +if(NOT LIB_INSTALL_DIR) + set(LIB_INSTALL_DIR lib) +endif() + ######################################################################## # Compiler specific setup ######################################################################## @@ -130,7 +134,7 @@ ENDIF(CMAKE_CROSSCOMPILING) set(prefix ${CMAKE_INSTALL_PREFIX}) set(exec_prefix \${prefix}) -set(libdir \${exec_prefix}/lib) +set(libdir \${exec_prefix}/${LIB_INSTALL_DIR}) set(includedir \${prefix}/include) CONFIGURE_FILE( @@ -140,5 +144,5 @@ CONFIGURE_FILE( INSTALL( FILES ${CMAKE_CURRENT_BINARY_DIR}/librtlsdr.pc - DESTINATION lib/pkgconfig + DESTINATION ${LIB_INSTALL_DIR}/pkgconfig ) diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt index 6b23395..4b91a4b 100644 --- a/src/CMakeLists.txt +++ b/src/CMakeLists.txt @@ -126,7 +126,7 @@ endif() # Install built library files & utilities ######################################################################## install(TARGETS ${INSTALL_TARGETS} - LIBRARY DESTINATION lib${LIB_SUFFIX} # .so/.dylib file - ARCHIVE DESTINATION lib${LIB_SUFFIX} # .lib file + LIBRARY DESTINATION ${LIB_INSTALL_DIR} # .so/.dylib file + ARCHIVE DESTINATION ${LIB_INSTALL_DIR} # .lib file RUNTIME DESTINATION bin # .dll file ) -- 1.8.1.4

2 1

Re: osmocom-sdr Digest, Vol 17, Issue 3
by Peter Stuge 14 Apr '13

14 Apr '13

Thomas Stowe wrote: > Great, admin failure on the list. I'm unsubscribing, fuck this shit. A shame to see such a strong contributor leave. //Peter

1 0

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

13 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 09 Apr '13

09 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 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

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr