osmocom-sdr

osmocom-sdr@lists.osmocom.org

906 discussions

Thank you
by Marco Haakmeester 16 Apr '13

16 Apr '13

Hi, I believe through this mailaddress I can reach the persons that have written the excellent wiki on the installation of the realtek receiver for it to receive ADS-B signals. I am a vivid Linux 'customer' but not a programmer. Yet, using the instructions I have been able to get a signal on my pc. So thanks for a well written wiki! Best regards, Marco Ps: the most difficult issue to tackle was to find an address for this 'thank you' note ;-)

1 0

R820T "spur prevention" code
by Per Baekgaard 15 Apr '13

15 Apr '13

List, As a new member here, only recently having acquired a few SDR units, I am not sure if this is the right place to post the following. If not, feel free to advice me of a better way (for reference, I've tried to mail a few of the key people here already directly, but I guess that was not the correct way to approach it). R820T tuning problems ============== As far as I can tell, the "correct" way to tune a RTL SDR device is to call rtlsdr_set_center_freq, which in turn invokes the set_freq function of the driver (mapped to r820t_set_freq which further calls r820t_SetRfFreqHz in case of the R820T). This may not always result in the desired frequency being tuned to. In some cases, such as with the current tuner_r820t.c driver, it can lead to rather large "errors" *). For instance, trying to tune to 144.000 MHz works as intended -- but tuning to anything in the range 144.002 to 144.058 will lead to center frequency of 144.030 MHz, or in other words an error as large of 28 kHz. [If you apply a PPM value other than 0, the exact range will be a little different.] I've also seen cases where use of the "kalibrate" program to locate GSM channels has resulted in one actual GSM channel being detected on 3 adjacent channels, 2 of which are incorrect -- and the calculated frequency deviation is also often wrong on some channels. For GSM channels and other frequencies above 885 MHz, the tuning "error" can be as much +/- ~225 kHz. Now, the way for an application to verify the resulting tuning would be to call the rtlsdr_get_center_freq. However, in the current implementation, this will return the requested tuning (adjusted with any calculated offsets set in the librtlsdr.c driver -- which is not applicable for the R820T) and not the actual tuning. Further, I've checked a couple of GUI programs on how they use the rtl library. One (linrad) only calls the rtlsdr_set_center_freq function and newer checks the resulting tuning. Another (gqrx via the osmo library) does a similar thing, but has a note "FIXME: Read back frequency?" comment. Also, the kalibrate suite does not check for the actual tuned frequency either. So all of these applications will report an incorrect frequency of the spectrum, and the error depends on what center frequency you may have requested. So -- unless I have overlooked something, which could be entirely possible -- the current R820T driver sometimes detunes the requested center frequency and the applications using it are not checking for this. And if they had wanted to do so, they have no means to with the current codebase. Proposed "fix" ======== I understand the R820T driver is messy anyway and that its origin has caused it to be what it is. The problem above is caused by a few lines of code in tuner_r820t.c around line 1460, that does "spur prevention". The idea is that if the resulting VCO frequency is too close to a harmonics of the xtal/2 frequency, the VCO is detuned to run exactly on top of the harmonics, to reduce any spurs within a (450/N) kHz bandwith, where N is the MixDiv, i.e. the divisor used to derive the center frequency from the VCO that runs between 1.77 and 3.54 GHz. This probably makes a lot of sense for applications where the exact tuning is not too important. Likely when using the stick for DVB-T as originally intended, the later stages will compensate for the detuning and just benefit from the reduced amount of spurs. But for our use, it might make less sense and I guess most of the other drivers have not implemented something like this anyway? I can think of the following ways to fix this issue: 1) Disable the code that does the detuning (either temporarily (#if 0/#endif) or by some setup parameter so that an application can specifically ask for the "detune" behaviour). This will possibly introduce additional spur on the R820T, in the presence of strong "near-center frequency" signals, but will fix the problem for existing SDR applications. In case of an optional "setup" parameter, proper handling of the detuning and reporting back to the calling application has to be made available, and those applications then eventually need to implement some way of handling it. 2) Merge with the possibly somewhat similar "offset" tuning method implemented for some other devices -- although I'm not sure exactly how that is intended to work and if it truly is compatible with the R820T method. 3) Keep the code as is, but "tweak" the sampling in the 2832 device to compensate for the offset tuning. So in other words, instead of assuming the nominal IF of 3.57 MHz, tune to an offset IF. This will obviously skew the BW and may not work for smaller sampling rates, where the offset could actually be larger than what the sampling rate allows... I would propose to simply disable the code for now (and I'm happy to submit a small patch), as the detuning currently appears to introduce more problems than it solves. A 2nd step would then be to add a proper report-back abstraction/functionality to all drivers and make the librtlsdr.c code fully aware of the detuning and allow it to be reported back to the caller, and then ask the application developers to start using the get_center_freq calls -- at least if they have asked for "enable_spur_prevention" or something similar. Thanks for any comments/advice on the above, -- Per.

1 0

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

← 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