- osmocom-sdr - lists.osmocom.org

by Luca Bedogni

Hi I have an Elonics 4000 USB receiver, and I-m trying to do some measurements on the digital television received power in my area. Everything works fine, except that the received power is never lower than -46 dB, even on channel which are not occupied. I was expecting to get values like -120 dB or something similar, instead in my measurements the lowest point in any portion of the spectrum is circa -46 dB. Am I missing something? Thank you Best

11 years, 1 month

3
3
0 0

DAB+ free/open encoder: fdk-aac-dabplus

by Benjamin Hagemann

Hello, I read on twitter: Opendigitalradio.org @opendigiradio "A new DAB+ free/open encoder is born ! https://github.com/piratfm/fdk-aac-dabplus …" https://twitter.com/opendigiradio/status/324231787163303936 -- Regards, Benny gpg 0xFC505AB0 jabber benny(a)benny.de sip benny(a)benny.de

11 years, 1 month

4
3
0 0

Using the R820T above 1.77 GHz?

by Per Baekgaard

One more (but completely different) topic, hence a separate mail: Has anyone experimented with using the R820T above 1.77 GHz?

11 years, 1 month

2
4
0 0

ask help for the format of outcome IQ data

by kainwen

Hello, I use rtl_sdr to collect some data into a bin file(file.bin). As from the wiki, I think it is parsed like this : /fd = open("file.bin","r") ;// // char I[];// // char Q[];// ////loop :// // read(fd, I, 1) ;// // read(fd, Q,1) ;// // endloop// // char *p = Q ;// // loop :// // printf("%f\n", (float*)p);// // p += 4 ;// ////endloop/ But this code can only print 0.00000 I don't know where the error is. Please help me. Thank you.

11 years, 1 month

1
0
0 0

Thank you

by Marco Haakmeester

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 ;-)

11 years, 1 month

1
0
0 0

R820T "spur prevention" code

by Per Baekgaard

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.

11 years, 1 month

1
0
0 0

gr-osmosdr build problem

by Wojciech Kazubski

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

11 years, 1 month

2
3
0 0

RTL offset with kalibrate-rtl

by Nuno Gonçalves

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

11 years, 1 month

1
0
0 0

[PATCH] rtl-sdr: add support for lib64 (e.g. Fedora)

by Jaroslav Skarvada

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

11 years, 1 month

2
1
0 0

Re: osmocom-sdr Digest, Vol 17, Issue 3

by Peter Stuge

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

11 years, 1 month

1
0
0 0

feedback: Terratec ran - T Stick+

by Thomas Osterried

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

11 years, 1 month

1
0
0 0

[PATCH 1/2] doxygen package needs to be detetected before the doxygen is used

by Jaroslav Škarvada

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

11 years, 1 month

1
1
0 0

RTL_TCP Output

by Chris Svendsen

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

11 years, 1 month

2
1
0 0

Re: "ld: warning: could not create compact unwind for rtl_source_c::rtl_source_" while building gr-osmosdr

by Trillium 2024

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

11 years, 1 month

1
0
0 0

"ld: warning: could not create compact unwind for rtl_source_c::rtl_source_" while building gr-osmosdr

by Trillium 2024

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

11 years, 1 month

1
0
0 0

Broadcast FM subcarrier decoding?

by Alan Corey

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

11 years, 1 month

5
6
0 0

RTL_TCP Commands

by Chris Svendsen

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

11 years, 1 month

2
3
0 0

RTL_TCP Commands

by Chris Svendsen

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

11 years, 1 month

3
2
0 0

Simple SDR transmitter

by Mathias Coinchon

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

11 years, 1 month

1
0
0 0

Re: Re: R820T vs. E4000

by Al

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 >

11 years, 2 months

1
0
0 0

SDRSharp, E4000 USB dongle not working

by Lorenz Wiedemann

Hello, I am using two of the "usual" RTL2832-USB dongles, with Ubuntu 12.04. The one with the R820T tuner in it works with both GQRX and SDRSharp (although driving the laptop temperature beyond 60°C - P-Mobile 1,8 GHz, with SDRSharp/Mono only!). The one with E4000 tuner is only accepted by GQRX. SDRSharp says "Array index is out of range", although in the dropdown menu, for both dongles "RTL-SDR / USB" is displayed. Anyone got an idea ...? Lorenz

11 years, 2 months

1
0
0 0

GSOC 2013

by Hemant Singh

Hey all, Osmocom is such a great community with awesome projects. Why doesn't Osmocom apply for GSOC 2013? It's a really nice opportunity. - More students will come to know about osmocom thus greater visibility - Some great minds will work on the projects so it may lead to something more awesome - Osmocom community will get to mentor students which is a very important experience, because that is how one understands the problems of new developers Cheers, *Hemant *

11 years, 2 months

2
1
0 0

ask for help : gr-osmosdr build failed

by kainwen

Dear All, Thanks for reading my mail. when I do the last steps, I failed, I don't know why. git clone git://git.osmocom.org/gr-osmosdr cd gr-osmosdr/ mkdir build cd build/ cmake ../ make sudo make install sudo ldconfig I failed when I " make ". the make error is : /tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc: In constructor 'osmosdr_source_c_impl::osmosdr_source_c_impl(const string&)': /tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc:117:16: error: 'GR_OSMOSDR_VERSION' was not declared in this scope /tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc:117:47: error: 'GR_OSMOSDR_LIBVER' was not declared in this scope make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/osmosdr_source_c_impl.cc.o] Error 1 make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2 make: *** [all] Error 2 the cmake output is : -- Build type not specified: defaulting to release. -- Extracting version information from git describe... -- Configuring Boost C++ Libraries... -- checking for module 'gnuradio-iqbalance' -- package 'gnuradio-iqbalance' not found -- Found gnuradio-uhd: /usr/local/include, /usr/local/lib/libgnuradio-uhd.so -- Found gnuradio-fcd: /usr/local/include, /usr/local/lib/libgnuradio-fcd.so -- Will build with gnuradio iqbalance support. -- -- The build system will automatically enable all components. -- Use -DENABLE_DEFAULT=OFF to disable components by default. -- -- Configuring sysmocom OsmoSDR support... -- Dependency LIBOSMOSDR_FOUND = TRUE -- Enabling sysmocom OsmoSDR support. -- Override with -DENABLE_OSMOSDR=ON/OFF -- -- Configuring FunCube Dongle support... -- Dependency GNURADIO_FCD_FOUND = TRUE -- Enabling FunCube Dongle support. -- Override with -DENABLE_FCD=ON/OFF -- -- Configuring IQ File Source support... -- Dependency GNURADIO_CORE_FOUND = TRUE -- Enabling IQ File Source support. -- Override with -DENABLE_FILE=ON/OFF -- -- Configuring Osmocom RTLSDR support... -- Dependency LIBRTLSDR_FOUND = TRUE -- Enabling Osmocom RTLSDR support. -- Override with -DENABLE_RTL=ON/OFF -- -- Configuring RTLSDR TCP Client support... -- Dependency GNURADIO_CORE_FOUND = TRUE -- Enabling RTLSDR TCP Client support. -- Override with -DENABLE_RTL_TCP=ON/OFF -- -- Configuring Ettus UHD support... -- Dependency UHD_FOUND = TRUE -- Dependency GNURADIO_UHD_FOUND = TRUE -- Enabling Ettus UHD support. -- Override with -DENABLE_UHD=ON/OFF -- -- Configuring Osmocom MiriSDR support... -- Dependency LIBMIRISDR_FOUND = TRUE -- Enabling Osmocom MiriSDR support. -- Override with -DENABLE_MIRI=ON/OFF -- -- ###################################################### -- # gr-osmosdr enabled components -- ###################################################### -- * sysmocom OsmoSDR -- * FunCube Dongle -- * IQ File Source -- * Osmocom RTLSDR -- * RTLSDR TCP Client -- * Ettus UHD -- * Osmocom MiriSDR -- -- ###################################################### -- # gr-osmosdr disabled components -- ###################################################### -- -- Building for version: 1eb3af22 / 0.0.1git -- Using install prefix: /usr/local -- Configuring done -- Generating done -- Build files have been written to: /tmp/gr-osmosdr/build * *

11 years, 2 months

1
0
0 0

Re: ask for help : gr-osmosdr build failed

by Dimitri Stolnikov

Hi, it seems you've triggered an issue recently introduced via gnuradio master: http://gnuradio.org/cgit/gnuradio.git/commit/?id=9297c84dfdae3002677f759ef2… Their config.h basically overrides our build-time generated one which not only effectively disables every single source functionality but also causes the build error you experienced. I've just pushed a small workaround for that, please test it & report. One second issue i've noticed is that in your configuration every single option seems to be enabled, although not all dependencies have been detected. Usually a full configuration should look like in the attached file. Best regards, Dimitri I failed when I " make ". the make error is : /tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc: In constructor ‘osmosdr_source_c_impl::osmosdr_source_c_impl(const string&)’: /tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc:117:16: error: ‘GR_OSMOSDR_VERSION’ was not declared in this scope /tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc:117:47: error: ‘GR_OSMOSDR_LIBVER’ was not declared in this scope make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/osmosdr_source_c_impl.cc.o] Error 1 make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2 make: *** [all] Error 2 the cmake output is : -- Build type not specified: defaulting to release. -- Extracting version information from git describe... -- Configuring Boost C++ Libraries... -- checking for module 'gnuradio-iqbalance' -- package 'gnuradio-iqbalance' not found -- Found gnuradio-uhd: /usr/local/include, /usr/local/lib/libgnuradio-uhd.so -- Found gnuradio-fcd: /usr/local/include, /usr/local/lib/libgnuradio-fcd.so -- Will build with gnuradio iqbalance support. -- -- The build system will automatically enable all components. -- Use -DENABLE_DEFAULT=OFF to disable components by default. -- -- Configuring sysmocom OsmoSDR support... -- Dependency LIBOSMOSDR_FOUND = TRUE -- Enabling sysmocom OsmoSDR support. -- Override with -DENABLE_OSMOSDR=ON/OFF -- -- Configuring FunCube Dongle support... -- Dependency GNURADIO_FCD_FOUND = TRUE -- Enabling FunCube Dongle support. -- Override with -DENABLE_FCD=ON/OFF -- -- Configuring IQ File Source support... -- Dependency GNURADIO_CORE_FOUND = TRUE -- Enabling IQ File Source support. -- Override with -DENABLE_FILE=ON/OFF -- -- Configuring Osmocom RTLSDR support... -- Dependency LIBRTLSDR_FOUND = TRUE -- Enabling Osmocom RTLSDR support. -- Override with -DENABLE_RTL=ON/OFF -- -- Configuring RTLSDR TCP Client support... -- Dependency GNURADIO_CORE_FOUND = TRUE -- Enabling RTLSDR TCP Client support. -- Override with -DENABLE_RTL_TCP=ON/OFF -- -- Configuring Ettus UHD support... -- Dependency UHD_FOUND = TRUE -- Dependency GNURADIO_UHD_FOUND = TRUE -- Enabling Ettus UHD support. -- Override with -DENABLE_UHD=ON/OFF -- -- Configuring Osmocom MiriSDR support... -- Dependency LIBMIRISDR_FOUND = TRUE -- Enabling Osmocom MiriSDR support. -- Override with -DENABLE_MIRI=ON/OFF -- -- ###################################################### -- # gr-osmosdr enabled components -- ###################################################### -- * sysmocom OsmoSDR -- * FunCube Dongle -- * IQ File Source -- * Osmocom RTLSDR -- * RTLSDR TCP Client -- * Ettus UHD -- * Osmocom MiriSDR -- -- ###################################################### -- # gr-osmosdr disabled components -- ###################################################### -- -- Building for version: 1eb3af22 / 0.0.1git -- Using install prefix: /usr/local -- Configuring done -- Generating done -- Build files have been written to: /tmp/gr-osmosdr/build * *

11 years, 2 months

2
1
0 0

ask for help : gr-osmosdr build failed

by kainwen

Dear All, Thanks for reading my mail. when I do the last steps, I failed, I don't know why. git clone git://git.osmocom.org/gr-osmosdr cd gr-osmosdr/ mkdir build cd build/ cmake ../ make sudo make install sudo ldconfig I failed when I " make ". the make error is : /tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc: In constructor 'osmosdr_source_c_impl::osmosdr_source_c_impl(const string&)': /tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc:117:16: error: 'GR_OSMOSDR_VERSION' was not declared in this scope /tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc:117:47: error: 'GR_OSMOSDR_LIBVER' was not declared in this scope make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/osmosdr_source_c_impl.cc.o] Error 1 make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2 make: *** [all] Error 2 the cmake output is : -- Build type not specified: defaulting to release. -- Extracting version information from git describe... -- Configuring Boost C++ Libraries... -- checking for module 'gnuradio-iqbalance' -- package 'gnuradio-iqbalance' not found -- Found gnuradio-uhd: /usr/local/include, /usr/local/lib/libgnuradio-uhd.so -- Found gnuradio-fcd: /usr/local/include, /usr/local/lib/libgnuradio-fcd.so -- Will build with gnuradio iqbalance support. -- -- The build system will automatically enable all components. -- Use -DENABLE_DEFAULT=OFF to disable components by default. -- -- Configuring sysmocom OsmoSDR support... -- Dependency LIBOSMOSDR_FOUND = TRUE -- Enabling sysmocom OsmoSDR support. -- Override with -DENABLE_OSMOSDR=ON/OFF -- -- Configuring FunCube Dongle support... -- Dependency GNURADIO_FCD_FOUND = TRUE -- Enabling FunCube Dongle support. -- Override with -DENABLE_FCD=ON/OFF -- -- Configuring IQ File Source support... -- Dependency GNURADIO_CORE_FOUND = TRUE -- Enabling IQ File Source support. -- Override with -DENABLE_FILE=ON/OFF -- -- Configuring Osmocom RTLSDR support... -- Dependency LIBRTLSDR_FOUND = TRUE -- Enabling Osmocom RTLSDR support. -- Override with -DENABLE_RTL=ON/OFF -- -- Configuring RTLSDR TCP Client support... -- Dependency GNURADIO_CORE_FOUND = TRUE -- Enabling RTLSDR TCP Client support. -- Override with -DENABLE_RTL_TCP=ON/OFF -- -- Configuring Ettus UHD support... -- Dependency UHD_FOUND = TRUE -- Dependency GNURADIO_UHD_FOUND = TRUE -- Enabling Ettus UHD support. -- Override with -DENABLE_UHD=ON/OFF -- -- Configuring Osmocom MiriSDR support... -- Dependency LIBMIRISDR_FOUND = TRUE -- Enabling Osmocom MiriSDR support. -- Override with -DENABLE_MIRI=ON/OFF -- -- ###################################################### -- # gr-osmosdr enabled components -- ###################################################### -- * sysmocom OsmoSDR -- * FunCube Dongle -- * IQ File Source -- * Osmocom RTLSDR -- * RTLSDR TCP Client -- * Ettus UHD -- * Osmocom MiriSDR -- -- ###################################################### -- # gr-osmosdr disabled components -- ###################################################### -- -- Building for version: 1eb3af22 / 0.0.1git -- Using install prefix: /usr/local -- Configuring done -- Generating done -- Build files have been written to: /tmp/gr-osmosdr/build * *

11 years, 2 months

1
0
0 0

rtl-sdr, SDRSharp under Ubuntu/mono, high CPU load - compared with GQRX

by Lorenz Wiedemann

Hello, I am running an RTL2832 USB stick (R820T tuner in it) and SDRSharp via Mono under Ubuntu 12.04 with a Pentium-M 1.5GHz and 1,5 GB RAM. SDRSharp With sample rates of 0.25M and 1.024M, I'm "suffering" from 100% CPU load and temperatures around 70°C - this can't be healthy for the laptop... Switching the waterfall off and speed etc. to minimum doesn't help very much. RDS is displayed fine, all functions seem to be OK. RAM space is not filled up (30%). Any advice for a "smoother" running on such an "old" machine...? http://superkuh.com/rtlsdr.html#sdrsharpappnote said "it can even run on my old 1.8Ghz P4 laptop". GQRX GQRX did run using the QtPro way as described in the wiki, but after recent update of GQRX the DC spike at centre frequency appeared (it wasn't there before), and massive stuttering of audio and the "OOOOOO"s in terminal window at a lot of different sample rates made the usage of GQRX worse. (right, this should be posted in a GQRX forum...) Anyway, did someone notice that GQRX update (ca. first days of march 2013) lead to problems ? thanks, Lorenz

11 years, 2 months

2
1
0 0

dump1090 - forked repo and added mysql support - some artwork

by Oliver Goldenstein

HI All ! Many thanks Salvatore for that very impressive piece of software. I extended dump1090 to make use of a mysql database: http://dl6kbg.blogspot.de/2013/03/dump1090-with-mysql-support.html I will work on the code the next days to improve it for a more easy db setup. Some results and a description you may see here: http://dl6kbg.blogspot.de/2013/03/dump1090-with-mysql-support.html the forked repo is here: https://github.com/dl6kbg/dump1090 You need a mysql database called "dump1090" with a table "tracks". You may easily setup the db using the supplied script "tracks.sql" Username and password ist coded for now as mysql user: root mysql password: root. Run: ./dump1090 --mysql Have fun ! 73 Oliver DL6KBG

11 years, 2 months

4
5
0 0

the next level in Software Definition

by Jay Salsburg

Gird you Grid for the next level in Software Definition. We are now stuck in Software Defined Radio (SDR). Next is Software Defined Instrumentation (SDI) with intriguing choices like the Vector Signal Transceiver (VST) for Device Testing.

11 years, 2 months

1
0
0 0

SDR rx

by Chas

Hi Guys. Any news on the V3 hardware board availability. Best regards. Chas.

11 years, 2 months

2
1
0 0

the next OsmoSDR

by wjquyi＠sina.com

Hello,Christian When will you post the schematics and the firmware of the next OsmoSDR of 4MS/s ? I am intersted in them. How do I get them? best regards Yi Qu

11 years, 2 months

1
0
0 0

Question osmosdr driver R820T

by Szilárd Jakab

Dear developers! I would like to ask the driver for the R820T osdmocom rtlsdr tuner use of this IFGAIN conrtol was, and if his shirt, the GNU Radio source how to use it (I think python command) I'm a hardwer working towards, and it would be important that we have a value ifgain radio) thank you Jakab Szilárd HUNGARY HA1003SWL

11 years, 2 months

2
1
0 0

New item for the "Known Apps" section of OSMOCOM rtl-sdr

by Thomas Frisch

Hello osmocom-sdr-Team, i spent some time to get familiar with GNU-Radio and RTL-SDR stuff and have implemented an decoder for the FS20 wireless home automation protocol. Maybe this is something for the "Known Apps" section in the OSMOCOM rtl-sdr wiki. Since i am a hardware/FPGA/RF guy, my programming skills are not the best, not at all in python, so i hope the code is not too scary. Name: rtl_sdr_FS20_decoder Type: gnuradio app Author: Thomas Frisch URL: https://github.com/eT0M/rtl_sdr_FS20_decoder.git My compliments to the whole OSMOCOM Team, you are doing a great job. regards Thomas

11 years, 2 months

2
1
0 0

Please add LEADTEK VID 0413:6f0f

by Alan Beard

Hi guys, Please add the LEADTEK "WinFast DTV DONGLE MINI D". EAN code 710918 292751 ARC here in Australia is selling these: Add to line 234 of "librtlsdr.c" { 0x0413, 0x6f0f, "Leadtek RTL2832U + FC0012" }, And to "rtl_eeprom.c" line 179 " LEADTEK," And to "rtl_eeprom.c" line 190 case LEADTEK: fprintf(stderr, "Leadtek default (as without EEPROM)\n"); conf->vendor_id = 0x0413; conf->product_id = 0x6f0f; strcpy(conf->manufacturer, "LEADTEK"); strcpy(conf->product, "RTL2832U + FC0012 DVB-T"); strcpy(conf->serial, "0"); conf->have_serial = 1; conf->enable_ir = 0; conf->remote_wakeup = 1; break; Now to try it. Thanks guys. Alan VK2ZIW --------------------------------------------------------------------------- Alan Beard Unix Support Technician from 1984 to today 70 Wedmore Rd. Sun Solaris, AIX, HP/UX, Linux, SCO OpenServer 5.0.X Emu Heights N.S.W. 2750 Routers, terminal servers, printers, terminals etc.. +61 2 47353013 (h) Support Programming, shell scripting, "C", assembler 0414 353013 (mobile) After uni, electronics tech. Man's greatest waste of time: Worshipping the wrong God. I cannot walk past what Jesus of Nazereth has done.

11 years, 2 months

2
1
0 0

RTL uvd mode

by Anton Komarov

Hi, guys. In Russia aviation has similar to ADSB communication protocol - UVD-M at 740 MHz. Is it possible to extend rtl_adsb utility to decode this protocol too? Detailed explanation of protocol can be found here - http://rtl1090.web99.de/homepage/index.php?way=1&site=READOUT&DERNAME=RTL10…

11 years, 2 months

1
0
0 0

[ANNOUNCE] OsmoDevCon 2013-04-04 till 2013-04-07, Berlin

by Harald Welte

Dear fellow Osmcoom developers, it is my pleasure to finally announce the date + venue of OsmoDevCon 2013: Date: April 04 through April 07, 2013 Place: IN-Berlin, Lehrter Str. 53, Berlin Like last year, this is an event for developers of the various Osmocom proejects. Reservation and confirmation of reservation is required. The event is free of charge. The Room is made available by IN-Berlin e.V., an Internet related non-profit organization. Lunch catering will be sponsored (so far by sysmocom GmbH, but if any other sponsors come up, we are happy to share the cost). So all you have to cover is your own travel + accomodation costs, as well as breakfast and dinner. If you are an active developer and cannot afford travel/accomodation, please let me know and I'll see if we can do something about it. If you would like to attend, please send a message to laforge(a)gnumonks.org applying for registration of the event. The registration deadline is March 5, i.e. one week from now. There is no detailed schedule of talks yet. I will start a separate discussion suggesting / collecting topics in the next couple of days. More information is (and will be made) available at http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2013 Further discussion regarding the event should be directed at the osmocom-event-orga(a)lists.osmocom.org mailing list, to avoid cross-posting over the various project-specific lists. Best regards and happy hacking, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

11 years, 2 months

1
0
0 0

an issue with rtl

by Mikhail Popov

Dear RTL developers, I was not able find a way how file the issue with RTL base USB dongle . It behaves in the same way on Linux and Windows The Problem: The constant observation of the spike on the tuned frequency in the ranges after 160MHz or so. Is it known issue or a HW defect? If it is in the software, please let me know any possible fix. The screen snapshot and USB information are attached. $ rtl_eeprom Found 1 device(s): 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Fitipower FC0013 tuner Current configuration: __________________________________________ Vendor ID: 0x0bda Product ID: 0x2838 Manufacturer: Realtek Product: RTL2838UHIDIR Serial number: 00000001 Serial number enabled: no IR endpoint enabled: yes Remote wakeup enabled: no __________________________________________ 73 Mikhail

11 years, 2 months

3
2
0 0

rtl_fm scanning

by Ben Moore

I am having a problem with using multiple frequencies with rtl_fm. Single frequencies work just fine. For example: rtl_fm -f 462.5625M -f 462.5725M -N -s 12k -r 12k -g 48 -l 50 | play -r 12k -e signed-integer -b 16 -t raw -c 1 -V1 - Will get to: Sampling at 1008000 Hz. Output at 12000 Hz. Exact sample rate is: 1008000.009613 Hz Tuner gain set to 48.00 dB. Then freeze. If I set the squelch low enough, it will continuously monitor the first channel. If I have a transmitter on before starting the command, it will monitor that. But when the transmitter turns off, rtl_fm hangs. I looked at the code but couldn't fix it. Maybe it's some reset command that's not being done between frequencies. If I force "data_ready" to unlock, it scans, but there's no data. Although, rtl_tcp works just fine when connecting with SDR# and changing frequencies. This is on a Raspberry Pi btw, latest rtl-sdr source code. Sorry if this has already been discussed somewhere, I could not find it. - Ben

11 years, 2 months

1
0
0 0

rtlsdr-based spectrum analyzer on a Beaglebone

by Alexandru Csete

Greetings, It is my pleasure to share with you a small, fun project I made few weeks ago: an rtlsdr-based spectrum analyzer running on a Beaglebone with an LCD3 touch screen. Video demo: http://www.youtube.com/watch?v=jzmFXreuFR4 Howto guide: http://www.oz9aec.net/index.php/beaglebone/480-rtlizer I also took the opportunity to start collecting bitbake recipes to create sdr oriented linux images for embedded devices. It is available here: https://github.com/csete/nanosdr I don't intend to create full blown PC-like desktops, instead I want to have fast, minimalistic linux images that can run a single GUI app without any display or window management. Think of it as a radio or an instrument that happens to run linux :) Alex

11 years, 2 months

2
1
0 0

rtl sdr with macbook os x v10.8.2

by paim

hello i am loking for some info before ordering the Realtek RTL2832U & Elonics E4000 is this dongle can work with macbook ?/ i am new to this group ,but new to SDR . thank you elan

11 years, 2 months

1
0
0 0

Still problem with "cb transfer status 1, cancelling" -> segmentation fault, libusb

by Markus Gonser

Hello, I am new to this mailing list, but that does not mean that I have been following SDR activities here at osmocom and especially gnuradio actively. I am not a linux professional, but "intermediate beginner". I currently have a problem running my Hama Nano DVB-T Dongle which I cannot solve and therefore need to turn to you with the following problem: I hava an Intel Pentium 977 machine running Ubuntu 12.04LTS in the 64bit version. I compiled and installed gnuradio using the script from Marcus Leech (http://www.sbrac.org/files/build-gnuradio) I have an Hama Nano DVB-T Dongle which contains an RTL2832U Chip combined with the E4000 frontend. When I try to access the Dongle via rtlsdr (either via sample programs in GRC or simply via rtl_test -s) I get cb transfer status: 1, canceling... Library error 0, exiting... Speicherzugriffsfehler (Speicherabzug geschrieben) (engl.: "segmentation fault") I found two threads regarding this problem in this mailinglist: 1) http://lists.osmocom.org/pipermail/osmocom-sdr/2013-January/000443.html 2) http://lists.gnumonks.org/pipermail/osmocom-sdr/2012-August/000201.html With respect to the former (1) I checked my version of libusb-1.0-0-dev which is 2:1.0.9~rc3-2ubuntu1 With respect to the latter (2) (and older post) I checked in my source of the rtlsdr library if the proposed change is included and it is. So I do not have any clue how and where to proceed further. I'd be happy to give you any more information you need and try out patches. If you have any ideas or could point me to the right direction, I'd be very happy about Thanks upfront for your consideration and best regards, Markus P.S.: The dongle worked on this machine before, but I do not remember if I had the 32bit Ubuntu version running and which versions of gnuradio, etc. were installed.

11 years, 2 months

3
3
0 0

rtl-entropy, atmospheric radio noise entropy source

by Paul Warren

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, I just finished my first go at an entropy gathering tool for rtl-sdr, it's licensed under GPL (will add LICENSE file next!) and available at: https://github.com/pwarren/rtl-entropy My aim was to have a utility that ran with a minimum of dependencies, so it could be done easily on a raspberry pi, and without trying to get a whole gnuradio stack working! I'm not a crypto expert, but I've read enough to know that you really should pass the output through rng-test or similar before using. As I mention in the Readme, I plan on doing these tests and eventually getting it to the stage where the entropy can be plumbed in to /dev/random. So, thanks for making the rtl-sdr libraries and making them easy to work with! Cheers - -- Paul Warren -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEeKZQACgkQkwz3ZmaDjV4e+QCeMG6rOr+PZ+yHnIeXGFJRnpsr e9oAn3vQBEW7L2mcJLJE0tyNUnZpGori =dlzx -----END PGP SIGNATURE-----

11 years, 3 months

3
2
0 0

info

by Massimo Borlis

Hi, message to the developer, you can also add this device, id: (15a4-9016-00) device: AF15BDA (v7.3.20.1) thanks waiting response. The drive is USB dikom

11 years, 3 months

2
1
0 0

Trouble using E4000 on new Dell Vostro

by Ethan Trewhitt

I have been unable to get basic tuning functionality out of my E4000 on my new laptop, in Ubuntu Precise. I'm running 64-bit Precise with the Osmocom drivers installed via the GNU Radio setup script. When I attempt to use the RTL device in Linux, the following occurs: " $ rtl_test Found 1 device(s): 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Elonics E4000 tuner Supported gain values (14): -1.0 1.5 4.0 6.5 9.0 11.5 14.0 16.5 19.0 21.5 24.0 29.0 34.0 42.0 Reading samples in async mode... cb transfer status: 1, canceling... Library error 0, exiting... Segmentation fault (core dumped) " When I run the system in GDB and request a backtrace, this is all I get: " Program received signal SIGSEGV, Segmentation fault. 0x00007ffff6ed42e5 in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0 (gdb) bt #0 0x00007ffff6ed42e5 in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0 #1 0x00007ffff6ed447f in libusb_close () from /lib/x86_64-linux-gnu/libusb-1.0.so.0 #2 0x00007ffff7bc51a9 in rtlsdr_close () from /usr/local/lib/librtlsdr.so.0 #3 0x0000000000401322 in main () " So there is apparently some issue with libusb. This machine has four USB 3.0 ports, and I've tried using all four of them. There's no hub, but nor are there any USB 2.0 ports to try. Here's the relevant output of usb-devices: " T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0bda ProdID=2838 Rev=01.00 S: Manufacturer=Realtek S: Product=RTL2838UHIDIR S: SerialNumber=00000947 C: #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) " Note that I have had easy success using the dongle in 64-bit Windows 7 (through the Zadig-installed drivers and SDRSharp), as well as in the same version of Ubuntu installed on another laptop (an older HP Envy). So I know the dongle works, and I know it theoretically can work with the Osmocom drivers, albeit in a different machine. Any ideas? Thanks in advance. Ethan

11 years, 3 months

1
0
0 0

Multiple dongles 1 rtl-server

by Mathison Ott

Im hopping to spark up a diolog to help to rewrite the RTL-server that the group has produced... I currently use the RTL-server with the ghpsdr-alex DSP-server. I have some code that alows the RTL-server to see multible dongles... the Problem is that unlike the Softrock-server a qtradio user cant select between the different receivers when connecting. The DSP-server needs mods to accept a tcp packet from a RTL-server with multiple RTL-dongles attached to its hardware. Keep in mind could the user select between dongles using a qt_radio check box, like the gain control. This could help to mange multiple qtradio client connections to a server. Say one receiver is indicated to be In Use, then a client can select the next one that isn't in use. I just found most of the rtl dongles to be usfull because of the vhf uhf spectrum they can receive. I have a few of the DVb units and I realized that i cant run more that one thou a DSP server at a time. Its could become useful to write DSP-server that hosts mixed devices. 73 Mathison KJ6DZB

11 years, 3 months

2
1
0 0

Re: osmocom-sdr Digest, Vol 15, Issue 3

by Jeff Murri

> -Message: 1 > Date: Sat, 2 Feb 2013 22:49:14 +0100 > From: Benedikt Heinz <zn000h(a)gmail.com> > To: osmocom-sdr(a)lists.osmocom.org > Subject: new SDR project (bladeRF) on kickstarter > Message-ID: > <CAFXU+zENpDgdfCTZu-U17GbMw-xg4BifyyPu4BwzTjK9p_mn5Q(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi everyone, > > just stumbled across this SDR on kickstarter: > http://www.kickstarter.com/projects/1085541682/bladerf-usb-30-software-defi… > (found via hackaday) > Maybe this is interesting for some of you. > > Cheers, > > hunz > I saw this too. It looks like a great piece of kit. Doesn't the dollars he's asking seem a bit steep though? Maybe not, and I'm hoping this comes off as a serious question. If it were opened up so that the dollars asked was lower then there'd be a lot of backers, which in turn drives build costs down further? If HackRF is half as good as I think it's going to be, then the $$ is definitely way to high. Just my (possibly uninformed) opinion. --Jeff

11 years, 3 months

3
2
0 0

new SDR project (bladeRF) on kickstarter

by Benedikt Heinz

Hi everyone, just stumbled across this SDR on kickstarter: http://www.kickstarter.com/projects/1085541682/bladerf-usb-30-software-defi… (found via hackaday) Maybe this is interesting for some of you. Cheers, hunz

11 years, 3 months

1
0
0 0

Re: any one brave enough to help a newbie with getting started with SDR

by Alan Corey

Yes, there are a confusing number of Linuxes, that's partly why I avoid them and use OpenBSD. I think Red Hat is only commercial now, try Fedora for the closest. Ubuntu will probably work, I didn't like it because I found it too "dumbed down", meant to appeal to Windows users. Ubuntu is supposedly based on Debian, which I've had installed for a few years and like it much better. Debian is "Deb" and "Ian", Ian is a ham. >The default compiler gcc is probably what you want. You don't mention what software you're trying to build. I had no problem building the Osmocom suite under my old Debian version, no extra libraries needed. But: my understanding from somewhere is that this suite of programs (rtl_*) exists because some ARM machines like the Raspberry Pi couldn't handle Gnuradio. Gnuradio may be what you really want. > >Gnuradio (http://www.gnuradio.org) is very versatile, bordering on confusing. Part of it is the RTLSDR or Osmocom source from Osmocom which connects to the dongle. Then you use the gunradio-companion to drag and drop different signal processing blocks onto a flow graph, the output of that is a Python program which hopefully does what you want. Start at the gnuradio web site and follow the build guide. Most of the work is getting the dependancies you need installed. You don't need the parts for hardware you don't have. > >Makefiles come with various programs, but most of this uses cmake to build the actual makefiles. Typically, you cd into the source directory, mkdir build, cd build, then "cmake ../". Track down things missing/wrong, modify your cmake cache file to fix it up, then when you have no errors, do make and make install. It works pretty well because you can set options in your cache file and they migrate down the line into makefiles. Both the Osmocom stuff and Gnuradio use cmake, but you can avoid it if you want to. > >If you need sensitivity and freedom from spurious noises you might find the NooElec dongle isn't the best way to go. Take a look at >http://wavelab.homestead.com/HF_VHF_multi_index.html >I bought a dozen of the MC13535 chips from http://www.futurlec.com for $1.20 each, plus the ceramic filters, crystals, etc. If you don't need frequency agility they might work out well. Futurlec isn't fast, but they have some good deals. > > Alan > > > >----- >Radio Astronomy - the ultimate DX > > > >>________________________________ >> From: Wayne Sanders <wsanders(a)xplornet.com> >>To: osmocom-sdr(a)lists.osmocom.org >>Sent: Thursday, January 31, 2013 11:40 PM >>Subject: any one brave enough to help a newbie with getting started with SDR >> >>Good day all >> I know that this may nor be the proper or correct place to request some basic assistance but I will tempt the wrath of the few. >> First off has the packaging for Linux changed there are many more versions now compared to 24 years ago when I dabbled with it running a packet radio bbs. It was Red Hat country then. Now ? >> Any way My questions are of the where to start kind. >> >> Step 1 Have selected Ubuntu as the o/s got it installed >> >> step 2 need to know what form of compiler is needed. >> Worked 28 years ago with Borland's C++ >> >> Step 3 what are the liberaies that I require and where may they >> be found. >> >> Step 4 And of course a suitable Make File. >> >> As all can see I am jut renewing a friend ship with a very powerfull o/s and of course are having the steep learning curve all over again. But expect that I will enjoy it. >> Project at this time is using the NooElec R820T SDR & DVB-T >> Dongle to monitor an number of frequencys in the >> analoge area 54mhz up for Pasive radar detection of >> meteors. >>Thanking all in advance. >> If the above questions are deemed off topic again I apoligize and would request that a direct e-mail answer to wsanders(a)xplornet.com be used if it should not be posted >>I remain wayne sanders ve7duc and RDL-OBS observatory >> >> >> >>Wayne Sanders >> >> >> >> > >

11 years, 3 months

1
0
0 0

any one brave enough to help a newbie with getting started with SDR

by Wayne Sanders

Good day all I know that this may nor be the proper or correct place to request some basic assistance but I will tempt the wrath of the few. First off has the packaging for Linux changed there are many more versions now compared to 24 years ago when I dabbled with it running a packet radio bbs. It was Red Hat country then. Now ? Any way My questions are of the where to start kind. Step 1 Have selected Ubuntu as the o/s got it installed step 2 need to know what form of compiler is needed. Worked 28 years ago with Borland's C++ Step 3 what are the liberaies that I require and where may they be found. Step 4 And of course a suitable Make File. As all can see I am jut renewing a friend ship with a very powerfull o/s and of course are having the steep learning curve all over again. But expect that I will enjoy it. Project at this time is using the NooElec R820T SDR & DVB-T Dongle to monitor an number of frequencys in the analoge area 54mhz up for Pasive radar detection of meteors. Thanking all in advance. If the above questions are deemed off topic again I apoligize and would request that a direct e-mail answer to wsanders(a)xplornet.com be used if it should not be posted I remain wayne sanders ve7duc and RDL-OBS observatory Wayne Sanders

11 years, 3 months

1
0
0 0

how about: rtl_drm?

by Alan Corey

Just an idea, really, I don't know how complex the decoding is. Or rtl_fm for Android? Just got an upconverter for my dongle, sitting here listening to music from faraway exotic places on HF. Using rtlsdr.dll with SDR#. Alan ----- Radio Astronomy - the ultimate DX

11 years, 3 months

2
1
0 0

rtl_tcp port for Android

by Мартин Маринов

I am pleased to announce I have released an RTL2832U driver for android for the benefit of all of the developers working on SDR. The app could be found here https://play.google.com/store/apps/details?id=marto.rtl_tcp_andro And the sources are released under GPL2+ here https://github.com/martinmarinov/rtl_tcp_andro- So how do you use it in case you want to develop your own Android application that uses rtl_tcp_andro? It's quite simple, you need to add just one line of code to your existing Android app (assuming the user has the driver installed). *startActivityForResult(new Intent(Intent.ACTION_VIEW).setData(Uri.parse("iqsrc://-a 127.0.0.1 -p 123", START_REQ_CODE);* Where START_REQ_CODE is a random number you assign. This will start rtl_tcp_andro on the localhost at port 123. As you see the thing after iqsrc:// is just the command line arguments you pass to a regular rtl_tcp. If you want to be more fancy and do error capture, you should override this method in your Android activity and perform error detection as so: *@Override* * protected void onActivityResult(final int requestCode, final int resultCode, final Intent data) {* * * * runOnUiThread(new Runnable() {* * * * @Override* * public void run() {* * if (requestCode == START_REQ_CODE) {* * if (resultCode == RESULT_OK) { // rtl_tcp_andro has been started successfully!}* * else {* * * * try {* * switch (data.getIntExtra("marto.rtl_tcp_andro.RtlTcpExceptionId", -1)) {* * case 0:* * // exception - permission denied* * break;* * case 1:* * // exception - root required* * break;* * case 2:* * // exception - no devices found* * break;* * case 4:* * // exception - the user needs to reconnect the device* * break;* * default:* * // unknown exception* * break;* * }* * } catch (Exception e) {}* * }* * }* * }* * });* * }* It is that simple! rtl_tcp_andro will take care of showing different dialogs to the user for device selection. It will also take care of non-rooted devices by communicating with rtl_tcp_androi and sending the appropriate file descriptors, etc. You don't need to worry about all of the magic that is happening in the background - you only need to monitor the result of your intent request. If you get *RESULT_OK* then you are ready to go. Now what remains is to implement your own TCP client that connects to the appropriate host/port number and communicates using the *rtl_tcp* protocol. Make sure you send the additional "exit" command that rtl_tcp_andro has in order not to leave zombie services behind. That's all if you have any questions, feel free to contact me! Sorry for the bad state of the source code of rtl_tcp_andro, I will add comments as time passes by. Hope to see great new projects on the Android platform :) Thanks, Martin

11 years, 3 months

3
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr