From jskarvad at redhat.com  Mon Apr  8 08:24:28 2013
From: jskarvad at redhat.com (Jaroslav Skarvada)
Date: Mon, 8 Apr 2013 04:24:28 -0400 (EDT)
Subject: [PATCH] rtl-sdr: add support for lib64 (e.g. Fedora)
In-Reply-To: <1365082578-3714-1-git-send-email-jskarvad@redhat.com>
References: <1365082578-3714-1-git-send-email-jskarvad@redhat.com>
Message-ID: <987467806.782284.1365409468479.JavaMail.root@redhat.com>

From: "Jaroslav ?karvada" <jskarvad at redhat.com>
To: laforge at gnumonks.org
Cc: "Jaroslav ?karvada" <jskarvad at 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 at 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




From jskarvad at redhat.com  Tue Apr  9 16:33:11 2013
From: jskarvad at redhat.com (=?UTF-8?q?Jaroslav=20=C5=A0karvada?=)
Date: Tue,  9 Apr 2013 18:33:11 +0200
Subject: [PATCH 2/2] allow docdir location override
In-Reply-To: <1365525191-29181-1-git-send-email-jskarvad@redhat.com>
References: <1365525191-29181-1-git-send-email-jskarvad@redhat.com>
Message-ID: <1365525191-29181-2-git-send-email-jskarvad@redhat.com>

Signed-off-by: Jaroslav ?karvada <jskarvad at redhat.com>
---
 CMakeLists.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index a1af563..9ff0b37 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -97,7 +97,9 @@ set(GR_INCLUDE_DIR      include)
 set(GR_DATA_DIR         share)
 set(GR_PKG_DATA_DIR     ${GR_DATA_DIR}/${CMAKE_PROJECT_NAME})
 set(GR_DOC_DIR          ${GR_DATA_DIR}/doc)
-set(GR_PKG_DOC_DIR      ${GR_DOC_DIR}/${CMAKE_PROJECT_NAME})
+if (NOT GR_PKG_DOC_DIR)
+    set(GR_PKG_DOC_DIR      ${GR_DOC_DIR}/${CMAKE_PROJECT_NAME})
+endif()
 set(GR_CONF_DIR         etc)
 set(GR_PKG_CONF_DIR     ${GR_CONF_DIR}/${CMAKE_PROJECT_NAME}/conf.d)
 set(GR_LIBEXEC_DIR      libexec)
-- 
1.8.1.4




From jskarvad at redhat.com  Tue Apr  9 16:33:10 2013
From: jskarvad at redhat.com (=?UTF-8?q?Jaroslav=20=C5=A0karvada?=)
Date: Tue,  9 Apr 2013 18:33:10 +0200
Subject: [PATCH 1/2] doxygen package needs to be detetected before the doxygen
	is used
Message-ID: <1365525191-29181-1-git-send-email-jskarvad@redhat.com>

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




From wk at ire.pw.edu.pl  Fri Apr 12 15:54:13 2013
From: wk at ire.pw.edu.pl (Wojciech Kazubski)
Date: Fri, 12 Apr 2013 17:54:13 +0200
Subject: gr-osmosdr build problem
Message-ID: <sig.58145223cb.11878630.qO5P271hei@jawor.ire.pw.edu.pl>

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=dc28f6c4c874e182557c8cb9fe8a04f757f3569e

(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









From horiz0n at gmx.net  Fri Apr 12 18:57:53 2013
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Fri, 12 Apr 2013 20:57:53 +0200
Subject: gr-osmosdr build problem
In-Reply-To: <sig.58145223cb.11878630.qO5P271hei@jawor.ire.pw.edu.pl>
References: <sig.58145223cb.11878630.qO5P271hei@jawor.ire.pw.edu.pl>
Message-ID: <op.wvfyyrg6vay7ep@wopr.artelis.net>

Hi Wojciech,

which version of Doxygen are you using? On which OS? Does it work with  
gnuradio's documentation?

Best regards,
Dimitri

On Fri, 12 Apr 2013 17:54:13 +0200, Wojciech Kazubski <wk at ire.pw.edu.pl>  
wrote:

> 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=dc28f6c4c874e182557c8cb9fe8a04f757f3569e
>
> (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
>
>
>
>
>
>



From peter at stuge.se  Sun Apr 14 11:16:03 2013
From: peter at stuge.se (Peter Stuge)
Date: Sun, 14 Apr 2013 13:16:03 +0200
Subject: osmocom-sdr Digest, Vol 17, Issue 3
In-Reply-To: <CAAuyBcA_N_phPwjWjzkSUC-Tb8Qv4xt7SpjjUBON8qPR6mcVqA@mail.gmail.com>
References: <mailman.5315.1365666767.1441.osmocom-sdr@lists.osmocom.org>
	<CAAuyBcA_N_phPwjWjzkSUC-Tb8Qv4xt7SpjjUBON8qPR6mcVqA@mail.gmail.com>
Message-ID: <20130414111603.5137.qmail@stuge.se>

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



From steve at steve-m.de  Sun Apr 14 15:43:42 2013
From: steve at steve-m.de (Steve Markgraf)
Date: Sun, 14 Apr 2013 17:43:42 +0200
Subject: [PATCH] rtl-sdr: add support for lib64 (e.g. Fedora)
In-Reply-To: <987467806.782284.1365409468479.JavaMail.root@redhat.com>
References: <1365082578-3714-1-git-send-email-jskarvad@redhat.com>
	<987467806.782284.1365409468479.JavaMail.root@redhat.com>
Message-ID: <516ACEAE.7000709@steve-m.de>

Hi,

Merged your series of three patches, thanks.

Regards,
Steve



From horiz0n at gmx.net  Sun Apr 14 16:27:23 2013
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Sun, 14 Apr 2013 18:27:23 +0200
Subject: gr-osmosdr build problem
In-Reply-To: <op.wvfyyrg6vay7ep@wopr.artelis.net>
References: <sig.58145223cb.11878630.qO5P271hei@jawor.ire.pw.edu.pl>
	<op.wvfyyrg6vay7ep@wopr.artelis.net>
Message-ID: <op.wvjhbxd8vay7ep@wopr.artelis.net>

Hi Wojciech,

as we have merged patches from Jaroslav and they seem to fix Doxygen  
invocation, could you please give it a try with the current master and  
report how it goes?

Best regards,
Dimitri



From nunojpg at gmail.com  Mon Apr 15 09:48:36 2013
From: nunojpg at gmail.com (=?UTF-8?Q?Nuno_Gon=C3=A7alves?=)
Date: Mon, 15 Apr 2013 10:48:36 +0100
Subject: RTL offset with kalibrate-rtl
Message-ID: <CAEXMXLSiih7VC=c3w7xbNG5JZNYSRK7usXik0YN2_YvSEgDvdQ@mail.gmail.com>

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



From wk at ire.pw.edu.pl  Mon Apr 15 10:41:25 2013
From: wk at ire.pw.edu.pl (Wojciech Kazubski)
Date: Mon, 15 Apr 2013 12:41:25 +0200
Subject: gr-osmosdr build problem
In-Reply-To: <op.wvjhbxd8vay7ep@wopr.artelis.net>
References: <11878630.qO5P271hei@jawor.ire.pw.edu.pl>
	<op.wvfyyrg6vay7ep@wopr.artelis.net>
	<op.wvjhbxd8vay7ep@wopr.artelis.net>
Message-ID: <sig.681712fe1e.2219332.oAlVaCWLzd@jawor.ire.pw.edu.pl>

> Hi Wojciech,
> 
> as we have merged patches from Jaroslav and they seem to fix Doxygen
> invocation, could you please give it a try with the current master and
> report how it goes?
> 
> Best regards,
> Dimitri

Now gr-osmosdr builds fine, at least on openSUSE releases 12.1 to 12.3, both 
32 and 64 bit. There was some tweaking needed, as Jaroslav's patch changed 
library name a bit.

Thanks!
Wojciech





From baekgaard at b4net.dk  Mon Apr 15 10:45:45 2013
From: baekgaard at b4net.dk (Per Baekgaard)
Date: Mon, 15 Apr 2013 12:45:45 +0200
Subject: R820T "spur prevention" code
Message-ID: <516BDA59.6040904@b4net.dk>

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.




From baekgaard at b4net.dk  Mon Apr 15 10:52:12 2013
From: baekgaard at b4net.dk (Per Baekgaard)
Date: Mon, 15 Apr 2013 12:52:12 +0200
Subject: Using the R820T above 1.77 GHz?
Message-ID: <516BDBDC.90109@b4net.dk>

One more (but completely different) topic, hence a separate mail:

Has anyone experimented with using the R820T above 1.77 GHz?


From st at metafly.info  Mon Apr 15 12:23:37 2013
From: st at metafly.info (Stefan Sydow)
Date: Mon, 15 Apr 2013 14:23:37 +0200
Subject: Using the R820T above 1.77 GHz?
In-Reply-To: <516BDBDC.90109@b4net.dk>
References: <516BDBDC.90109@b4net.dk>
Message-ID: <516BF149.1020606@metafly.info>

Hi Per,

mine goes up till almost 1.9GHz with no harm.
I don't know if you already had a look on
https://github.com/stsydow/rtl-sdr.

I've changed the PLL code a lot. From your last mail I get that we had
similar ideas. If you find bugs in it I would be glad to hear about.

Stefan



From baekgaard at b4net.dk  Mon Apr 15 14:31:32 2013
From: baekgaard at b4net.dk (Per Baekgaard)
Date: Mon, 15 Apr 2013 16:31:32 +0200
Subject: Using the R820T above 1.77 GHz?
In-Reply-To: <516BF149.1020606@metafly.info>
References: <516BDBDC.90109@b4net.dk> <516BF149.1020606@metafly.info>
Message-ID: <516C0F44.40109@b4net.dk>

Thanks for your reply, Stefan.

You wrote:
> mine goes up till almost 1.9GHz with no harm.

Mine does go up there around too, if I'm using your repository.

I've also had a look at your code, and I can see you have removed the
same lines of code too. However, when I build it here and install it on
my machine, there is a big difference in the performance -- for
instance, tuning to some of the lower bands (just try 24 MHz) shows a
lot of spikes/spurs that are not present when using the "official"
repository, even though the settings are the same in the testing
application (in this case gqrx).

Not sure why, though -- did you change the gain parameters somehow? If
not, then there might possible be some bugs introduced that are causing
the spurs? They seem to be somewhat stable in the spectrum, despite the
tuned-to frequency.


-- Per.




From bedogni.luca at gmail.com  Tue Apr 16 05:35:03 2013
From: bedogni.luca at gmail.com (Luca Bedogni)
Date: Tue, 16 Apr 2013 07:35:03 +0200
Subject: Can't get below -46 dB
Message-ID: <CAJkDHktuUwbrn1TRqbPxdAVbM6vZ2RoYmYZHrMCa3+Uio_LZyA@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130416/a7648623/attachment.htm>

From st at metafly.info  Tue Apr 16 10:20:19 2013
From: st at metafly.info (Stefan Sydow)
Date: Tue, 16 Apr 2013 12:20:19 +0200
Subject: Can't get below -46 dB
In-Reply-To: <CAJkDHktuUwbrn1TRqbPxdAVbM6vZ2RoYmYZHrMCa3+Uio_LZyA@mail.gmail.com>
References: <CAJkDHktuUwbrn1TRqbPxdAVbM6vZ2RoYmYZHrMCa3+Uio_LZyA@mail.gmail.com>
Message-ID: <516D25E3.4020902@metafly.info>

Hi,

-48bB is the theoretical limit for a 8bit ADC.
There are two channels and a bit of filtering but it will not help that
much.

Stefan

Am 16.04.2013 07:35, schrieb 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
> 




From st at metafly.info  Tue Apr 16 10:32:26 2013
From: st at metafly.info (Stefan Sydow)
Date: Tue, 16 Apr 2013 12:32:26 +0200
Subject: Using the R820T above 1.77 GHz?
In-Reply-To: <516C0F44.40109@b4net.dk>
References: <516BDBDC.90109@b4net.dk> <516BF149.1020606@metafly.info>
	<516C0F44.40109@b4net.dk>
Message-ID: <516D28BA.6010307@metafly.info>

Hi Per,

I guess I changed to much to find the bug by looking at the diff.
My motivation was to rewrite the driver, understand what's going on inside.

I've seen that spurs at 24MHz and there are also mirror images form
FM-radio, but it did not raise my suspicion until now. I'm wordering if
I disabled a filter or something.

To get to 1.9 GHz, you need to adjust the PLL charge pump register if
the PLL doesn't lock.


Stefan



From 246tnt at gmail.com  Tue Apr 16 10:34:35 2013
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Tue, 16 Apr 2013 12:34:35 +0200
Subject: Can't get below -46 dB
In-Reply-To: <CAJkDHktuUwbrn1TRqbPxdAVbM6vZ2RoYmYZHrMCa3+Uio_LZyA@mail.gmail.com>
References: <CAJkDHktuUwbrn1TRqbPxdAVbM6vZ2RoYmYZHrMCa3+Uio_LZyA@mail.gmail.com>
Message-ID: <CAHL+j0-H8iq9vpmMDy6nYXTvVYGTznD01b=M07K9BWa0=JTr-Q@mail.gmail.com>

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

Yes ... those are not absolute dBm values ... There is no calibration
whatsoever so the '0dB' level doesn't mean 0 dBm at all ...

Cheers,

    Sylvain



From kainwen at gmail.com  Tue Apr 16 13:03:38 2013
From: kainwen at gmail.com (kainwen)
Date: Tue, 16 Apr 2013 21:03:38 +0800
Subject: ask help for the format of outcome IQ data
Message-ID: <516D4C2A.6000701@gmail.com>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130416/7e778837/attachment.htm>

From baekgaard at b4net.dk  Tue Apr 16 13:06:37 2013
From: baekgaard at b4net.dk (Per Baekgaard)
Date: Tue, 16 Apr 2013 15:06:37 +0200
Subject: Using the R820T above 1.77 GHz?
In-Reply-To: <516D28BA.6010307@metafly.info>
References: <516BDBDC.90109@b4net.dk> <516BF149.1020606@metafly.info>
	<516C0F44.40109@b4net.dk> <516D28BA.6010307@metafly.info>
Message-ID: <516D4CDD.2000202@b4net.dk>

On 04/16/2013 12:32 PM, Stefan Sydow wrote:
> My motivation was to rewrite the driver, understand what's going on inside.

Yep, the code in your repo looks much cleaner -- and some of the really
weird and non-intuitive parts have been streamlined, making it easier to
read!

> I've seen that spurs at 24MHz and there are also mirror images form
> FM-radio, but it did not raise my suspicion until now. I'm wordering if
> I disabled a filter or something.

Might be the case, yes. Or some some other setup is missing -- I guess
we're still missing a more complete description on how the device functions.


-- Per.



From benny at benny.de  Tue Apr 16 19:02:14 2013
From: benny at benny.de (Benjamin Hagemann)
Date: Tue, 16 Apr 2013 21:02:14 +0200
Subject: DAB+ free/open encoder: fdk-aac-dabplus
Message-ID: <20130416190214.GY22071@quelle.benny.de>

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 at benny.de
sip     benny at benny.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130416/64c049e3/attachment.bin>

From steve at steve-m.de  Tue Apr 16 20:14:07 2013
From: steve at steve-m.de (Steve Markgraf)
Date: Tue, 16 Apr 2013 22:14:07 +0200
Subject: DAB+ free/open encoder: fdk-aac-dabplus
In-Reply-To: <20130416190214.GY22071@quelle.benny.de>
References: <20130416190214.GY22071@quelle.benny.de>
Message-ID: <516DB10F.8090707@steve-m.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 16.04.2013 21:02, Benjamin Hagemann wrote:
> "A new DAB+ free/open encoder is born !

Well, that's just the audio codec, but there's the well established
FAAC already... So nothing too exciting.

Regards,
Steve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRbbEDAAoJEDTskicYOO0G/uoH+gIG9iTGahAcI73zZomDsV7r
UX5UShMiWg6qfxB6uA+uTVO3XtHdKoBmqpg6eHeWuAOL/zAHzgAoCk5RW1bLVaD8
sec5yr0TLz962Pr3nE9uSH9jcxtloajA9dW0DYVeLOO+UB+jNiOdqxC8wFywr6xW
LQnc80DWi/fN0LcZ+8oGof9YQcDVpyB4vIzOoCNpEfmfbNo8PjRPotYDjTd0v/BW
2j8gIbiy+3bTeDax5ZcUF9HBQg+T9kufQwe/X63jW6yShD+ZLYoqH05fMpFqogtu
ulwnu+PR91GjmgLMVPNyqsTJvQLaJhl4Cd8zVtAiFD5BL/CsqejOQVbEhJzX8DM=
=IIXs
-----END PGP SIGNATURE-----



From horiz0n at gmx.net  Tue Apr 16 20:21:29 2013
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Tue, 16 Apr 2013 22:21:29 +0200
Subject: DAB+ free/open encoder: fdk-aac-dabplus
In-Reply-To: <20130416190214.GY22071@quelle.benny.de>
References: <20130416190214.GY22071@quelle.benny.de>
Message-ID: <op.wvnhh3tfvay7ep@wopr.artelis.net>

> I read on twitter:

Sure you did.



From coinchon at yahoo.com  Tue Apr 16 21:14:25 2013
From: coinchon at yahoo.com (Mathias Coinchon)
Date: Tue, 16 Apr 2013 14:14:25 -0700 (PDT)
Subject: DAB+ free/open encoder: fdk-aac-dabplus
In-Reply-To: <516DB10F.8090707@steve-m.de>
References: <20130416190214.GY22071@quelle.benny.de>
	<516DB10F.8090707@steve-m.de>
Message-ID: <1366146865.10756.YahooMailNeo@web162101.mail.bf1.yahoo.com>



DAB+ (and DRM) uses AAC 960 transform (FAAC implements only 1024 transform which is effectively the most commonly used)


DAB+ uses a special framing (gathering AAC AUs in a 120ms superframe), adding a RS code and Firecode.


So yes, it's only the encoder but it's the first time someone has implemented these special features in open source. Free open tools for multiplexing and modulation already exist with CRC mmbtools.

However, nobody has implemented a full and open DAB+ SDR receiver yet. There's a partial receiver https://github.com/andrmuel/gr-dab?source=cr but it doesn't implement audio decoding yet.

Regards

Mathias



________________________________
 De?: Steve Markgraf <steve at steve-m.de>
??: Benjamin Hagemann <benny at benny.de> 
Cc?: osmocom-sdr at lists.osmocom.org 
Envoy? le : Mardi 16 avril 2013 22h14
Objet?: Re: DAB+ free/open encoder: fdk-aac-dabplus
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 16.04.2013 21:02, Benjamin Hagemann wrote:
> "A new DAB+ free/open encoder is born !

Well, that's just the audio codec, but there's the well established
FAAC already... So nothing too exciting.

Regards,
Steve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRbbEDAAoJEDTskicYOO0G/uoH+gIG9iTGahAcI73zZomDsV7r
UX5UShMiWg6qfxB6uA+uTVO3XtHdKoBmqpg6eHeWuAOL/zAHzgAoCk5RW1bLVaD8
sec5yr0TLz962Pr3nE9uSH9jcxtloajA9dW0DYVeLOO+UB+jNiOdqxC8wFywr6xW
LQnc80DWi/fN0LcZ+8oGof9YQcDVpyB4vIzOoCNpEfmfbNo8PjRPotYDjTd0v/BW
2j8gIbiy+3bTeDax5ZcUF9HBQg+T9kufQwe/X63jW6yShD+ZLYoqH05fMpFqogtu
ulwnu+PR91GjmgLMVPNyqsTJvQLaJhl4Cd8zVtAiFD5BL/CsqejOQVbEhJzX8DM=
=IIXs
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130416/a8e2d3b1/attachment.htm>

From alancorey at yahoo.com  Wed Apr 17 04:14:48 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Tue, 16 Apr 2013 21:14:48 -0700 (PDT)
Subject: OpenBSD: crashing
Message-ID: <1366172088.84920.YahooMailNeo@web161502.mail.bf1.yahoo.com>

This is with a version of rtl-sdr I got by git last night and OpenBSD 5.2 (current release).? 5.2 has some pthreads fixing so I waited until I bought another computer and loaded it.? Are the crashes related to threads?? I don't know, but possibly.? It didn't work with OpenBSD 5.0 either.

rtl_fm crashes and uses threads????????????????????? 
rtl_adsb crashes and uses threads??????????????????? 
rtl_tcp doesn't crash, uses threads, actually stops on ctrl-c
rtl_test doesn't crash, doesn't use threads, won't stop
rtl_eeprom doesn't crash, doesn't use threads, ends normally


I'm not real practiced using gdb but I tried looking at a couple of core files, here's a run of? rtl_fm:

rtl_fm -f 162550000 -N - | play -t raw -r 24k -e signed-integer -b 16 -c 1
-V1 -

-: (raw)

? Encoding: Signed PCM
? Channels: 1 @ 16-bit
Samplerate: 24000Hz
Replaygain: off
? Duration: unknown

In:0.00% 00:00:00.00 [00:00:00.00] Out:0???? [????? |????? ]??????? Clip:0
Found 1 device(s):
? 0:? Realtek, RTL2838UHIDIR, SN: 00000013

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Rafael Micro R820T tuner
Oversampling input by: 42x.
Oversampling output by: 1x.
Buffer size: 8.13ms
Tuned to 162802000 Hz.
Sampling at 1008000 Hz.
Output at 24000 Hz.
Exact sample rate is: 1008000.009613 Hz
Tuner gain set to automatic.
In:0.00% 00:00:00.00 [00:00:00.00] Out:0???? [????? |????? ]??????? Clip:0
Done.
Abort (core dumped)


d530# gdb -c rtl_fm.core /usr/local/bin/rtl_fm
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.? Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd5.2"...
Core was generated by `rtl_fm'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/lib/libpthread.so.16.0...done.
Loaded symbols for /usr/lib/libpthread.so.16.0
Reading symbols from /usr/lib/libm.so.7.0...done.
Loaded symbols for /usr/lib/libm.so.7.0
Reading symbols from /usr/local/lib/librtlsdr.so.0.0...done.
Loaded symbols for /usr/local/lib/librtlsdr.so.0.0
Reading symbols from /usr/local/lib/libusb-1.0.so.1.0...done.
Loaded symbols for /usr/local/lib/libusb-1.0.so.1.0
Symbols already loaded for /usr/lib/libpthread.so.16.0
Reading symbols from /usr/lib/libc.so.65.0...done.
Loaded symbols for /usr/lib/libc.so.65.0
Loaded symbols for /usr/libexec/ld.so
#0? 0x0abbd98d in kill () from /usr/lib/libc.so.65.0
(gdb) bt
#0? 0x0abbd98d in kill () from /usr/lib/libc.so.65.0
#1? 0x0ac29545 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
#2? 0x005e9298 in pthread_mutex_unlock (mutexp=0x3c003d8c)
??? at /usr/src/lib/librthread/rthread_sync.c:218
#3? 0x1c00266e in full_demod (fm=0xcfa2de5c)
??? at /usr/src/misc/osmocom/2013-04-15/rtl-sdr/src/rtl_fm.c:583
#4? 0x1c0028ff in demod_thread_fn (arg=0xcfa2de5c)
??? at /usr/src/misc/osmocom/2013-04-15/rtl-sdr/src/rtl_fm.c:641
#5? 0x005ebc2e in _rthread_start (v=0x84da4c00)
??? at /usr/src/lib/librthread/rthread.c:111
#6? 0x0aba62e9 in __tfork_thread () from /usr/lib/libc.so.65.0


The backtrace (bt) shows that it dies trying to do a mutex_unlock (I think).? rtl_tcp also does a mutex_unlock and it doesn't crash.? I'm probably reading it wrong for all I know.? I don't know what's causing the signal 6 either.

I'd also like to get the -lrt of of the cmake files.? OpenBSD doesn't use or have lrt, it works without.? I can edit it out and compile, but every time I run cmake again, I have to edit the files again.

? Alan

?
-----
Radio Astronomy - the ultimate DX
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130416/ad36dbd9/attachment.htm>

From bedogni.luca at gmail.com  Wed Apr 17 05:13:17 2013
From: bedogni.luca at gmail.com (Luca Bedogni)
Date: Wed, 17 Apr 2013 07:13:17 +0200
Subject: Can't get below -46 dB
In-Reply-To: <516D25E3.4020902@metafly.info>
References: <CAJkDHktuUwbrn1TRqbPxdAVbM6vZ2RoYmYZHrMCa3+Uio_LZyA@mail.gmail.com>
	<516D25E3.4020902@metafly.info>
Message-ID: <CAJkDHksU0dnckFw_S=XPqiF_tEcMVkPKqthEfPi77S+3+-UNiQ@mail.gmail.com>

Thank you

So, If I want to get the real power on the channel, what should I do?
Basically when I get like -46/-47 dB I'm getting only noise, right?

Thank you very much

--
Luca Bedogni
Academic: http://lbedogni.web.cs.unibo.it
Photo: http://www.lucabedogni.it


On Tue, Apr 16, 2013 at 12:20 PM, Stefan Sydow <st at metafly.info> wrote:

> Hi,
>
> -48bB is the theoretical limit for a 8bit ADC.
> There are two channels and a bit of filtering but it will not help that
> much.
>
> Stefan
>
> Am 16.04.2013 07:35, schrieb 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
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130417/485a3290/attachment.htm>

From thomas at osterried.de  Sat Apr 13 21:45:36 2013
From: thomas at osterried.de (Thomas Osterried)
Date: Sat, 13 Apr 2013 23:45:36 +0200
Subject: feedback: Terratec ran - T Stick+
Message-ID: <87F3E595-210C-4201-8C01-F83767F748A5@osterried.de>

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_Stick.2B

Thank you for your good work..

	- Thomas


From marcohaakmeester at gmail.com  Tue Apr 16 10:07:13 2013
From: marcohaakmeester at gmail.com (Marco Haakmeester)
Date: Tue, 16 Apr 2013 12:07:13 +0200
Subject: Thank you
Message-ID: <516D22D1.7010401@gmail.com>

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




From wk at ire.pw.edu.pl  Fri Apr 19 10:56:19 2013
From: wk at ire.pw.edu.pl (Wojciech Kazubski)
Date: Fri, 19 Apr 2013 12:56:19 +0200
Subject: gr-iqbal or gr-iqbalance?
Message-ID: <sig.982124110c.16665049.SeNOXA4bCZ@jawor.ire.pw.edu.pl>

Hello!

This is a minor issue, but may lead to some misunderstanding  (and seach 
failures) in future.
The package to correct IQ imbalance is registered at http://cgit.osmocom.org 
as gr-iqbal but project name set in line 24 of toplevel CMakeList.txt is gr-
iqbalance.
Which name should be used while building packages, etc.?

BTW: Is there any homepage for gr-iqbal/gr-iqbalance?

Wojciech Kazubski





From stu at spacehopper.org  Fri Apr 19 12:37:18 2013
From: stu at spacehopper.org (Stuart Henderson)
Date: Fri, 19 Apr 2013 12:37:18 +0000 (UTC)
Subject: OpenBSD: crashing
References: <1366172088.84920.YahooMailNeo@web161502.mail.bf1.yahoo.com>
Message-ID: <slrnkn2ek2.9sa.stu@naiad.spacehopper.org>

On 2013-04-17, Alan Corey <alancorey at yahoo.com> wrote:
> This is with a version of rtl-sdr I got by git last night and OpenBSD
> 5.2 (current release). 5.2 has some pthreads fixing so I waited until
> I bought another computer and loaded it. Are the crashes related to
> threads? I don't know, but possibly. It didn't work with OpenBSD 5.0
> either.
> 
> rtl_fm crashes and uses threads                      
> rtl_adsb crashes and uses threads                    
> rtl_tcp doesn't crash, uses threads, actually stops on ctrl-c
> rtl_test doesn't crash, doesn't use threads, won't stop
> rtl_eeprom doesn't crash, doesn't use threads, ends normally

[snip]

I've just got hold of a card and looking into this.

> (gdb) bt
> #0  0x0abbd98d in kill () from /usr/lib/libc.so.65.0
> #1  0x0ac29545 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
> #2  0x005e9298 in pthread_mutex_unlock (mutexp=0x3c003d8c)
>     at /usr/src/lib/librthread/rthread_sync.c:218
> #3  0x1c00266e in full_demod (fm=0xcfa2de5c)
>     at /usr/src/misc/osmocom/2013-04-15/rtl-sdr/src/rtl_fm.c:583
> #4  0x1c0028ff in demod_thread_fn (arg=0xcfa2de5c)
>     at /usr/src/misc/osmocom/2013-04-15/rtl-sdr/src/rtl_fm.c:641
> #5  0x005ebc2e in _rthread_start (v=0x84da4c00)
>     at /usr/src/lib/librthread/rthread.c:111
> #6  0x0aba62e9 in __tfork_thread () from /usr/lib/libc.so.65.0

By specification, pthread_mutex_unlock() has undefined behaviour when
unlocking a mutex which is already unlocked.

Currently OpenBSD's "undefined behaviour" in this case is to immediately
abort(), which has helped debug problems with some threaded programs.

You can change this behaviour by hacking librthread/rthread_sync.c:218
and building/installing new librthread, this gets rid of the crash but
does not make things work properly; like rtl_test, rtl_fm doesn't stop
when you ^C. I don't get any output from rtl_fm instead I get high
system cpu usage. I suspect this is some issue (quite possibly kernel
driver) with bulk transfers.

rtl_test doesn't work well for me. It starts up but

$ 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 Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6 

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode...
lost at least 1228 bytes
lost at least 1924 bytes
lost at least 1892 bytes
lost at least 2588 bytes
lost at least 1648 bytes
[...]

Notably the two programs which do seem to work correctly are rtl_eeprom
and rtl_tcp (at least I get some data from rtl_tcp but don't have
anything setup to use it yet) - notably these two do *not* use
rtlsdr_read_sync i.e. bulk transfers.


> I'd also like to get the -lrt of of the cmake files. OpenBSD doesn't
> use or have lrt, it works without. I can edit it out and compile, but
> every time I run cmake again, I have to edit the files again.

OpenBSD isn't the only system which has the realtime functions
in libc; this might be more generally applicable but note I have
not tested it on a system which *does* have librt.

diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 6b23395..2afb494 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -101,12 +101,21 @@ target_link_libraries(rtl_adsb rtlsdr_shared
 if(UNIX)
 target_link_libraries(rtl_fm m)
 target_link_libraries(rtl_adsb m)
-if(APPLE)
-    target_link_libraries(rtl_test m)
-else()
-    target_link_libraries(rtl_test m rt)
-endif()
-endif()
+
+include(CheckFunctionExists)
+check_function_exists(clock_gettime LIBRT_LIBC_HAS_CLOCK_GETTIME)
+if(LIBRT_LIBC_HAS_CLOCK_GETTIME)
+    set(LIBRT_LIBRARIES)
+    set(LIBRT_LIB_FOUND TRUE)
+else(LIBRT_LIBC_HAS_CLOCK_GETTIME)
+    find_library(LIBRT_LIBRARIES NAMES rt )
+    if(LIBRT_LIBRARIES)
+        set(LIBRT_LIBRARIES TRUE)
+    endif(LIBRT_LIBRARIES)
+endif(LIBRT_LIBC_HAS_CLOCK_GETTIME)
+
+target_link_libraries(rtl_test m ${LIBRT_LIBRARIES})
+endif(UNIX)
 
 if(WIN32)
 target_link_libraries(rtl_sdr libgetopt_static)
diff --git a/src/rtl_test.c b/src/rtl_test.c
index f5a56b8..f84d453 100644
--- a/src/rtl_test.c
+++ b/src/rtl_test.c
@@ -131,7 +131,7 @@ static void rtlsdr_callback(unsigned char *buf, uint32_t len, void *ctx)
 	}
 	ppm_count += (int64_t)len;
 #ifndef _WIN32
-	#ifndef __APPLE__
+	#ifdef CLOCK_REALTIME
 	clock_gettime(CLOCK_REALTIME, &ppm_now);
 	#else
 	gettimeofday(&tv, NULL);
@@ -143,7 +143,7 @@ static void rtlsdr_callback(unsigned char *buf, uint32_t len, void *ctx)
 		ns += (int64_t)(ppm_now.tv_nsec - ppm_recent.tv_nsec);
 		printf("real sample rate: %i\n",
 		(int)((1000000000L * ppm_count / 2L) / ns));
-		#ifndef __APPLE__
+		#ifdef CLOCK_REALTIME
 		clock_gettime(CLOCK_REALTIME, &ppm_recent);
 		#else
 		gettimeofday(&tv, NULL);





From alancorey at yahoo.com  Sat Apr 20 03:59:34 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Fri, 19 Apr 2013 20:59:34 -0700 (PDT)
Subject: OpenBSD: crashing
In-Reply-To: <slrnkn2ek2.9sa.stu@naiad.spacehopper.org>
References: <1366172088.84920.YahooMailNeo@web161502.mail.bf1.yahoo.com>
	<slrnkn2ek2.9sa.stu@naiad.spacehopper.org>
Message-ID: <1366430374.52532.YahooMailNeo@web161504.mail.bf1.yahoo.com>

> I've just got hold of a card and looking into this.


Do you mean a dongle?? I got one of the $20 ones, which works pretty well in Windows with SDR# and RTL1090, so I bought a second one.

> 
> By specification, pthread_mutex_unlock() has undefined behaviour when
> unlocking a mutex which is already unlocked.

I wondered about that.? If it wasn't either locking something already locked our unlocking something already unlocked.? I stuck a bunch of extra printfs in the code and was trying to keep track of what it was doing.? It works under Linux, but that's like saying a web page works fine in IE.? Too sloppy to do otherwise.

> 
> Currently OpenBSD's "undefined behaviour" in this case is to 
> immediately
> abort(), which has helped debug problems with some threaded programs.
> 
> You can change this behaviour by hacking librthread/rthread_sync.c:218
> and building/installing new librthread, this gets rid of the crash but
> does not make things work properly; like rtl_test, rtl_fm doesn't stop
> when you ^C. I don't get any output from rtl_fm instead I get high
> system cpu usage. I suspect this is some issue (quite possibly kernel
> driver) with bulk transfers.

I wonder if the not stopping is because the low level acquisition, possibly a different thread, isn't getting stopped.

> Info: This tool will continuously read from the device, and report if
> samples get lost. If you observe no further output, everything is fine.

I seem to always have samples getting lost, no matter what I do? I think it's also supposed to give you a ppm adjustment figure, but I worked out mine from tuning in a few stations and seeing how far off frequency they were (with SDR#).? One dongle is off 102 ppm, the other 62 ppm.

I forgot to mention it, but rtl_sdr (the simplest one) also doesn't work.? I was looking at trying to adapt them to use the Gnu pth threads.

> Notably the two programs which do seem to work correctly are rtl_eeprom
> and rtl_tcp (at least I get some data from rtl_tcp but don't have
> anything setup to use it yet) - notably these two do *not* use
> rtlsdr_read_sync i.e. bulk transfers.

There's a scanning client for rtl_tcp somebody wrote, but they did it in Python.? It has one dependency that seems badly packaged.? I don't have it working yet.? I was thinking of writing a command line scanner in C that has hopefully no dependencies.

Are you sure your rtl_tcp is actually working?? Mine stops after a while.? You could test it by running SDR# on a Windows machine and having the source of that be the rtl_tcp on an OpenBSD box, just enter the IP address and port.? I think it's a lot of network load for even 100baseTX though.? There are also Gnuradio sources that can work from rtl_tcp.

> 
> OpenBSD isn't the only system which has the realtime functions
> in libc; this might be more generally applicable but note I have
> not tested it on a system which *does* have librt.

I could in principle do that.? I can boot this box into an old Debian and try that.

? Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130419/f1011fd7/attachment.htm>

From stu at spacehopper.org  Sat Apr 20 09:51:33 2013
From: stu at spacehopper.org (Stuart Henderson)
Date: Sat, 20 Apr 2013 10:51:33 +0100
Subject: OpenBSD: crashing
In-Reply-To: <1366430374.52532.YahooMailNeo@web161504.mail.bf1.yahoo.com>
References: <1366172088.84920.YahooMailNeo@web161502.mail.bf1.yahoo.com>
	<slrnkn2ek2.9sa.stu@naiad.spacehopper.org>
	<1366430374.52532.YahooMailNeo@web161504.mail.bf1.yahoo.com>
Message-ID: <20130420095133.GX1588@symphytum.spacehopper.org>

On 2013/04/19 20:59, Alan Corey wrote:
> > I've just got hold of a card and looking into this.
> 
> Do you mean a dongle?  I got one of the $20 ones, which works pretty
> well in Windows with SDR# and RTL1090, so I bought a second one.

Yes..

> > By specification, pthread_mutex_unlock() has undefined behaviour when
> > unlocking a mutex which is already unlocked.
> 
> I wondered about that.  If it wasn't either locking something already
> locked our unlocking something already unlocked.  I stuck a bunch of
> extra printfs in the code and was trying to keep track of what it was
> doing.  It works under Linux, but that's like saying a web page works
> fine in IE.  Too sloppy to do otherwise.

Linux doesn't have this strict checking, it was specifically added to
try to flush out bugs in programs using mutexes.

> I wonder if the not stopping is because the low level acquisition,
> possibly a different thread, isn't getting stopped.

I've talked to another developer and we don't have good support for
usb transfer with asynchronous events yet, somebody is already looking
at this though. So for this side of things, it probably makes sense
to wait until that's available as this is likely to be the main
problem. (this is separate to the strict mutex checks mentioned above).

However I've just tried a few things in synchronous mode (rtl_test -S,
rtl_sdr -S, and RTLSDR-Scanner which uses sync mode anyway) and those
*do* seem to work.

> > Info: This tool will continuously read from the device, and report if
> > samples get lost. If you observe no further output, everything is
> fine.
> 
> I seem to always have samples getting lost, no matter what I do  I
> think it's also supposed to give you a ppm adjustment figure, but I
> worked out mine from tuning in a few stations and seeing how far off
> frequency they were (with SDR#).  One dongle is off 102 ppm, the other
> 62 ppm.
> 
> I forgot to mention it, but rtl_sdr (the simplest one) also doesn't
> work.  I was looking at trying to adapt them to use the Gnu pth
> threads.

I think Pth won't help things on OpenBSD versions which already use
kernel threads (5.2+), and unlikely to have helped earlier versions
with userland threads either, the problem with userland thread
implementations is how file descriptor blocking is handled.

> > Notably the two programs which do seem to work correctly are
> rtl_eeprom
> > and rtl_tcp (at least I get some data from rtl_tcp but don't have
> > anything setup to use it yet) - notably these two do *not* use
> > rtlsdr_read_sync i.e. bulk transfers.
> 
> There's a scanning client for rtl_tcp somebody wrote, but they did it
> in Python.  It has one dependency that seems badly packaged.  I don't
> have it working yet.  I was thinking of writing a command line scanner
> in C that has hopefully no dependencies.
> 
> Are you sure your rtl_tcp is actually working?  Mine stops after a
> while.  You could test it by running SDR# on a Windows machine and
> having the source of that be the rtl_tcp on an OpenBSD box, just enter
> the IP address and port.  I think it's a lot of network load for even
> 100baseTX though.

Can't test these; I can only run Windows in VM (SDR# is broken if you
have no audio device) or by dual booting my laptop (in which case
I can't use rtl_tcp on OpenBSD as a source).

> There are also Gnuradio sources that can work from rtl_tcp.

working on this ;)




From alancorey at yahoo.com  Sun Apr 21 02:45:57 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Sat, 20 Apr 2013 19:45:57 -0700 (PDT)
Subject: OpenBSD: crashing
In-Reply-To: <20130420095133.GX1588@symphytum.spacehopper.org>
References: <1366172088.84920.YahooMailNeo@web161502.mail.bf1.yahoo.com>
	<slrnkn2ek2.9sa.stu@naiad.spacehopper.org>
	<1366430374.52532.YahooMailNeo@web161504.mail.bf1.yahoo.com>
	<20130420095133.GX1588@symphytum.spacehopper.org>
Message-ID: <1366512357.86783.YahooMailNeo@web161505.mail.bf1.yahoo.com>

>>  I forgot to mention it, but rtl_sdr (the simplest one) also doesn't

>>  work.? I was looking at trying to adapt them to use the Gnu pth
>>  threads.
> 
> I think Pth won't help things on OpenBSD versions which already use
> kernel threads (5.2+), and unlikely to have helped earlier versions
> with userland threads either, the problem with userland thread
> implementations is how file descriptor blocking is handled.

I was trying to figure out whether pth was abandoned or just mature enough that it doesn't need any more updates.? Looks like it's just mature.? I was suspicious that it was somebody's thesis project.

This machine I'm trying to run on lately under 5.2 is dual core, and various things indicate that threads are less effective with multiple CPUs.? It's my first dual core.? Cost me $37.

> 
>>  There are also Gnuradio sources that can work from rtl_tcp.
> 
> working on this ;)

Me too, I failed a bunch of QA self-tests with segfaults but I'm not hearing from my post to the gnuradio-discuss list.

Your patch/diff for the cmake stuff works fine under OpenBSD, but not under Linux:

Linking C executable rtl_test
/usr/bin/ld: cannot find -lTRUE
collect2: ld returned 1 exit status
make[2]: *** [src/rtl_test] Error 1
make[1]: *** [src/CMakeFiles/rtl_test.dir/all] Error 2
make: *** [all] Error 2

Gotta dereference that test result, sort of, somehow.? I did the patching by hand with an editor but I'm fairly sure it's right.? I did it in the OpenBSD partition, then copied to the Linux partition.

The sync/async stuff is interesting.? I was assuming it was somehow more radio-related, like sync detection or sync related to the A/D process than USB sync.

? Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130420/5e0dcbf5/attachment.htm>

From stu at spacehopper.org  Sun Apr 21 11:31:30 2013
From: stu at spacehopper.org (Stuart Henderson)
Date: Sun, 21 Apr 2013 12:31:30 +0100
Subject: OpenBSD: crashing
In-Reply-To: <1366512357.86783.YahooMailNeo@web161505.mail.bf1.yahoo.com>
References: <1366172088.84920.YahooMailNeo@web161502.mail.bf1.yahoo.com>
	<slrnkn2ek2.9sa.stu@naiad.spacehopper.org>
	<1366430374.52532.YahooMailNeo@web161504.mail.bf1.yahoo.com>
	<20130420095133.GX1588@symphytum.spacehopper.org>
	<1366512357.86783.YahooMailNeo@web161505.mail.bf1.yahoo.com>
Message-ID: <20130421113130.GT1588@symphytum.spacehopper.org>

On 2013/04/20 19:45, Alan Corey wrote:
> >> I forgot to mention it, but rtl_sdr (the simplest one) also doesn't
> >> work.  I was looking at trying to adapt them to use the Gnu pth
> >> threads.
> >
> > I think Pth won't help things on OpenBSD versions which already use
> > kernel threads (5.2+), and unlikely to have helped earlier versions
> > with userland threads either, the problem with userland thread
> > implementations is how file descriptor blocking is handled.
> 
> I was trying to figure out whether pth was abandoned or just mature
> enough that it doesn't need any more updates.  Looks like it's just
> mature.  I was suspicious that it was somebody's thesis project.

It's not all that much needed now that most unix-like OS have posix
threads support..

> Your patch/diff for the cmake stuff works fine under OpenBSD, but not
> under Linux:

bleh, silly mistake ;)

OK - just setup an fc18 box to test it; here's a fixed version.

diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 4b91a4b..4cc77fc 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -101,12 +101,17 @@ target_link_libraries(rtl_adsb rtlsdr_shared
 if(UNIX)
 target_link_libraries(rtl_fm m)
 target_link_libraries(rtl_adsb m)
-if(APPLE)
-    target_link_libraries(rtl_test m)
-else()
-    target_link_libraries(rtl_test m rt)
-endif()
-endif()
+
+include(CheckFunctionExists)
+check_function_exists(clock_gettime LIBRT_LIBC_HAS_CLOCK_GETTIME)
+if(LIBRT_LIBC_HAS_CLOCK_GETTIME)
+    set(LIBRT_LIBRARIES)
+else(LIBRT_LIBC_HAS_CLOCK_GETTIME)
+    find_library(LIBRT_LIBRARIES NAMES rt)
+endif(LIBRT_LIBC_HAS_CLOCK_GETTIME)
+
+target_link_libraries(rtl_test m ${LIBRT_LIBRARIES})
+endif(UNIX)
 
 if(WIN32)
 target_link_libraries(rtl_sdr libgetopt_static)



From nunojpg at gmail.com  Sun Apr 21 11:59:56 2013
From: nunojpg at gmail.com (=?UTF-8?Q?Nuno_Gon=C3=A7alves?=)
Date: Sun, 21 Apr 2013 12:59:56 +0100
Subject: rtlsdr not reseting buffers
Message-ID: <CAEXMXLSm5=o_uY6CQaKRjH3mi02Yp-iU0+cAiHS7NrjWj1ouVA@mail.gmail.com>

rtlsdr in async mode is returning buffers full with data from previous calls.

I noticed that sometimes the first async callbacks would return TOO
QUICKLY so that it would be impossible to have sampled that data. This
might be because lib-usb have previous transfers submitted and not
cleared?

I compiled rtl_test with a small modification that will print the
sampling time if it is much lower than expected.
BUF_LENGTH is (16 * 16384)=256K, and SAMPLE_RATE is 2048000, so a full
buffer should take about 64ms.

You can see that in this example the async callback is returned after
7.79ms (and the following one 1.47ms later). So the data must be old.

The ns printf

nuno at ubuntu:~/Desktop/rtl-sdr/build/src$ ./rtl_test -p
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 Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7
16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1
43.4 43.9 44.5 48.0 49.6
Reporting PPM error measurement every 10 seconds...
Press ^C after a few minutes.
Reading samples in async mode...
ERROR ns:   7791886
ERROR ns:   9259301
lost at least 185 bytes
real sample rate: 2073369
real sample rate: 2048190
^CSignal caught, exiting!

User cancel, exiting...
Cumulative PPM error: -289


The modifications to demonstrate the issue:

nuno at ubuntu:~/Desktop/rtl-sdr/src$ git diff
diff --git a/src/rtl_test.c b/src/rtl_test.c
index f5a56b8..1935bfb 100644
--- a/src/rtl_test.c
+++ b/src/rtl_test.c
@@ -138,9 +138,11 @@ static void rtlsdr_callback(unsigned char *buf, uint32_t le
        ppm_now.tv_sec = tv.tv_sec;
        ppm_now.tv_nsec = tv.tv_usec*1000;
        #endif
-       if (ppm_now.tv_sec - ppm_recent.tv_sec > PPM_DURATION) {
-               ns = 1000000000L * (int64_t)(ppm_now.tv_sec - ppm_recent.tv_sec)
-               ns += (int64_t)(ppm_now.tv_nsec - ppm_recent.tv_nsec);
+       ns = 1000000000L * (int64_t)(ppm_now.tv_sec - ppm_recent.tv_sec);
+       ns += (int64_t)(ppm_now.tv_nsec - ppm_recent.tv_nsec);
+       if(ns<60000000)
+               printf("ERROR ns: %9lld\n",ns);
+       if (ppm_now.tv_sec - ppm_recent.tv_sec > PPM_DURATION) {
                printf("real sample rate: %i\n",
                (int)((1000000000L * ppm_count / 2L) / ns));
                #ifndef __APPLE__


Nuno



From mrzfrn at gmail.com  Sun Apr 21 12:47:57 2013
From: mrzfrn at gmail.com (mrzfrn)
Date: Sun, 21 Apr 2013 14:47:57 +0200
Subject: OpenSourceDABplusSDRreceiver
Message-ID: <5173DFFD.1040304@gmail.com>

"However, nobody has implemented a full and open DAB+ SDR receiver yet"
Not true, look at
http://www.sdr-j.tk/index.html

Francesco




From nunojpg at gmail.com  Sun Apr 21 17:59:57 2013
From: nunojpg at gmail.com (=?UTF-8?Q?Nuno_Gon=C3=A7alves?=)
Date: Sun, 21 Apr 2013 18:59:57 +0100
Subject: rtl_test patch
Message-ID: <CAEXMXLQvWTrPH2SPecAg2s=T5Bv9LdGCPCZ1QhX0cGiYZkE7Zg@mail.gmail.com>

Corrects bugs where:
Cumulative PPM error is always "342" if execution stopped before first
PPM_DURATION.
PPM error alias to wrong values if over +-1045 (this happens quite a
lot actually due to bug reported at [1]).

Behavior changes:
Cumulative PPM error value is now printed every PPM_DURATION so the
user can check when it is settled.

[1] http://lists.osmocom.org/pipermail/osmocom-sdr/2013-April/000584.html

Thanks,
Nuno

Signed-off-by: Nuno Goncalves <nunojpg at gmail.com>

diff --git a/src/rtl_test.c b/src/rtl_test.c
index f5a56b8..c705e04 100644
--- a/src/rtl_test.c
+++ b/src/rtl_test.c
@@ -55,6 +55,8 @@ static int ppm_benchmark = 0;
 static int64_t ppm_count = 0L;
 static int64_t ppm_total = 0L;

+static uint32_t samp_rate = DEFAULT_SAMPLE_RATE;
+
 #ifndef _WIN32
 static struct timespec ppm_start;
 static struct timespec ppm_recent;
@@ -108,6 +110,7 @@ static void rtlsdr_callback(unsigned char *buf,
uint32_t len, void *ctx)
 {
  uint32_t i, lost = 0;
  int64_t ns;
+ int real_rate;

  if (uninit) {
  bcnt = buf[0];
@@ -141,17 +144,23 @@ static void rtlsdr_callback(unsigned char *buf,
uint32_t len, void *ctx)
  if (ppm_now.tv_sec - ppm_recent.tv_sec > PPM_DURATION) {
  ns = 1000000000L * (int64_t)(ppm_now.tv_sec - ppm_recent.tv_sec);
  ns += (int64_t)(ppm_now.tv_nsec - ppm_recent.tv_nsec);
- printf("real sample rate: %i\n",
+ printf("real sample rate: %i",
  (int)((1000000000L * ppm_count / 2L) / ns));
- #ifndef __APPLE__
- clock_gettime(CLOCK_REALTIME, &ppm_recent);
- #else
- gettimeofday(&tv, NULL);
- ppm_recent.tv_sec = tv.tv_sec;
- ppm_recent.tv_nsec = tv.tv_usec*1000;
- #endif
+
  ppm_total += ppm_count / 2L;
  ppm_count = 0L;
+
+ #ifndef _WIN32
+ ns = 1000000000L * (int64_t)(ppm_now.tv_sec - ppm_start.tv_sec);
+ ns += (int64_t)(ppm_now.tv_nsec - ppm_start.tv_nsec);
+ real_rate = (int)(ppm_total * 1000000000L / ns);
+ printf(" cumulative PPM error: %.1f\n",
+ (1000000.0 * (real_rate - (int)samp_rate)) / samp_rate);
+ #else
+ printf("\n");
+ #endif
+
+ ppm_recent = ppm_now;
  }
 #endif
 }
@@ -213,13 +222,10 @@ int main(int argc, char **argv)
  int sync_mode = 0;
  uint8_t *buffer;
  uint32_t dev_index = 0;
- uint32_t samp_rate = DEFAULT_SAMPLE_RATE;
  uint32_t out_block_size = DEFAULT_BUF_LENGTH;
  int device_count;
  int count;
  int gains[100];
- int real_rate;
- int64_t ns;

  while ((opt = getopt(argc, argv, "d:s:b:tpS::")) != -1) {
  switch (opt) {
@@ -365,15 +371,6 @@ int main(int argc, char **argv)

  if (do_exit) {
  fprintf(stderr, "\nUser cancel, exiting...\n");
- if (ppm_benchmark) {
-#ifndef _WIN32
- ns = 1000000000L * (int64_t)(ppm_recent.tv_sec - ppm_start.tv_sec);
- ns += (int64_t)(ppm_recent.tv_nsec - ppm_start.tv_nsec);
- real_rate = (int)(ppm_total * 1000000000L / ns);
- printf("Cumulative PPM error: %i\n",
- (int)round((double)(1000000 * (real_rate - (int)samp_rate)) /
(double)samp_rate));
-#endif
- }
  }
  else
  fprintf(stderr, "\nLibrary error %d, exiting...\n", r);
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_ppm.diff
Type: application/octet-stream
Size: 2512 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130421/0647505f/attachment.obj>

From coinchon at yahoo.com  Sun Apr 21 22:43:26 2013
From: coinchon at yahoo.com (Mathias Coinchon)
Date: Sun, 21 Apr 2013 15:43:26 -0700 (PDT)
Subject: OpenSourceDABplusSDRreceiver
In-Reply-To: <5173DFFD.1040304@gmail.com>
References: <5173DFFD.1040304@gmail.com>
Message-ID: <1366584206.91866.YahooMailNeo@web162103.mail.bf1.yahoo.com>

Hey, thank you !
It looks very interesting and didn't know about it ! I will add it now to opendigitalradio wiki and will test it later.
Another achievement. Lots of great things in the digital radio domain on these days with Serguei devs (encoder, low cost SDR peripheral) and now this one.

Looks like we have now all the open source bricks for digital radio: what is missing is still an open DRM+ transmitter, an open DRM HE-AAC encoder and an open DRM+ receiver but again I may be wrong..not knowing them.


Do you know the guy who developped this ? Do you know if he used Andreas Mueller code (the gnuradio DAB partial receiver)


Regards

Mathias



________________________________
 De?: mrzfrn <mrzfrn at gmail.com>
??: osmocom-sdr at lists.osmocom.org 
Cc?: mrzfrn at gmail.com 
Envoy? le : Dimanche 21 avril 2013 14h47
Objet?: OpenSourceDABplusSDRreceiver
 

"However, nobody has implemented a full and open DAB+ SDR receiver yet"
Not true, look at
http://www.sdr-j.tk/index.html

Francesco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130421/d6a221ac/attachment.htm>

From stu at spacehopper.org  Tue Apr 23 14:47:33 2013
From: stu at spacehopper.org (Stuart Henderson)
Date: Tue, 23 Apr 2013 15:47:33 +0100
Subject: [PATCH 1/1] add -S (synchronous) mode to rtl_fm
Message-ID: <20130423144733.GS9461@symphytum.spacehopper.org>

The enclosed diff adds a synchronous mode to rtl_fm. This helps
OpenBSD (where libusb async isn't yet working).

Signed-off-by: Stuart Henderson <stu at spacehopper.org>
---
 src/rtl_fm.c | 29 +++++++++++++++++++++++++----
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/src/rtl_fm.c b/src/rtl_fm.c
index e8ebb77..a71e287 100644
--- a/src/rtl_fm.c
+++ b/src/rtl_fm.c
@@ -128,6 +128,7 @@ void usage(void)
 		"\t[-E sets lower edge tuning (default: center)]\n"
 		"\t[-N enables NBFM mode (default: on)]\n"
 		"\t[-W enables WBFM mode (default: off)]\n"
+		"\t[-S force sync output (default: async)]\n"
 		"\t (-N -s 170k -o 4 -A fast -r 32k -l 0 -D)\n"
 		"\tfilename (a '-' dumps samples to stdout)\n"
 		"\t (omitting the filename also uses stdout)\n\n"
@@ -723,12 +724,14 @@ int main(int argc, char **argv)
 	uint32_t dev_index = 0;
 	int device_count;
 	int ppm_error = 0;
+	int sync_mode = 0;
 	char vendor[256], product[256], serial[256];
+
 	fm_init(&fm);
 	pthread_mutex_init(&data_ready, NULL);
 	pthread_mutex_init(&data_write, NULL);
 
-	while ((opt = getopt(argc, argv, "d:f:g:s:b:l:o:t:r:p:EFA:NWMULRDC")) != -1) {
+	while ((opt = getopt(argc, argv, "d:f:g:s:b:l:o:t:r:p:EFA:NWMULRDSC")) != -1) {
 		switch (opt) {
 		case 'd':
 			dev_index = atoi(optarg);
@@ -815,6 +818,9 @@ int main(int argc, char **argv)
 		case 'R':
 			fm.mode_demod = &raw_demod;
 			break;
+		case 'S':
+			sync_mode = 1;
+			break;
 		default:
 			usage();
 			break;
@@ -921,9 +927,24 @@ int main(int argc, char **argv)
 		fprintf(stderr, "WARNING: Failed to reset buffers.\n");}
 
 	pthread_create(&demod_thread, NULL, demod_thread_fn, (void *)(&fm));
-	rtlsdr_read_async(dev, rtlsdr_callback, (void *)(&fm),
-			      DEFAULT_ASYNC_BUF_NUMBER,
-			      lcm_post[fm.post_downsample] * DEFAULT_BUF_LENGTH);
+	if (sync_mode) {
+		fprintf(stderr, "Reading samples in sync mode...\n");
+		while (!do_exit) {
+			r = rtlsdr_read_sync(dev, &fm.buf,
+					     lcm_post[fm.post_downsample] * DEFAULT_BUF_LENGTH,
+					     &fm.buf_len);
+			if (r < 0) {
+				fprintf(stderr, "WARNING: sync read failed.\n");
+				break;
+			}
+			full_demod(&fm);
+		}
+	} else {
+		fprintf(stderr, "Reading samples in async mode...\n");
+		rtlsdr_read_async(dev, rtlsdr_callback, (void *)(&fm),
+				  DEFAULT_ASYNC_BUF_NUMBER,
+				  lcm_post[fm.post_downsample] * DEFAULT_BUF_LENGTH);
+	}
 
 	if (do_exit) {
 		fprintf(stderr, "\nUser cancel, exiting...\n");}
-- 
1.8.1.3





From alancorey at yahoo.com  Tue Apr 23 19:46:47 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Tue, 23 Apr 2013 12:46:47 -0700 (PDT)
Subject: [PATCH 1/1] add -S (synchronous) mode to rtl_fm
In-Reply-To: <20130423144733.GS9461@symphytum.spacehopper.org>
Message-ID: <1366746407.92712.YahooMailClassic@web161506.mail.bf1.yahoo.com>

Did you also fix the pthread_mutex_unlock when it was already unlocked?? The cmake patch should get included too.

For me this dumps core with an abort, so it sounds like the thread thing:

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Rafael Micro R820T tuner
Oversampling input by: 2x.
Oversampling output by: 4x.
Buffer size: 6.02ms
Tuned to 88856000 Hz.
Sampling at 1360000 Hz.
Output at 32000 Hz.
Exact sample rate is: 1360000.050439 Hz
Tuner gain set to automatic.
Reading samples in sync mode...
In:0.00% 00:00:00.00 [00:00:00.00] Out:0???? [????? |????? ]??????? Clip:0
Done.
Abort (core dumped)

This is OpenBSD 5.2 with the libusbs from ports:

d530# pkg_info | grep libusb
libusb-compat-0.1.4 libusb-0.1 compatibility layer for libusb1
libusb1-1.0.9p3???? library for USB device access from userspace

? Alan

-----

Radio Astronomy - the ultimate DX

--- On Tue, 4/23/13, Stuart Henderson <stu at spacehopper.org> wrote:

From: Stuart Henderson <stu at spacehopper.org>
Subject: [PATCH 1/1] add -S (synchronous) mode to rtl_fm
To: osmocom-sdr at lists.osmocom.org
Date: Tuesday, April 23, 2013, 10:47 AM

The enclosed diff adds a synchronous mode to rtl_fm. This helps
OpenBSD (where libusb async isn't yet working).

Signed-off-by: Stuart Henderson <stu at spacehopper.org>
---
 src/rtl_fm.c | 29 +++++++++++++++++++++++++----
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/src/rtl_fm.c b/src/rtl_fm.c
index e8ebb77..a71e287 100644
--- a/src/rtl_fm.c
+++ b/src/rtl_fm.c
@@ -128,6 +128,7 @@ void usage(void)
 ??? ??? "\t[-E sets lower edge tuning (default: center)]\n"
 ??? ??? "\t[-N enables NBFM mode (default: on)]\n"
 ??? ??? "\t[-W enables WBFM mode (default: off)]\n"
+??? ??? "\t[-S force sync output (default: async)]\n"
 ??? ??? "\t (-N -s 170k -o 4 -A fast -r 32k -l 0 -D)\n"
 ??? ??? "\tfilename (a '-' dumps samples to stdout)\n"
 ??? ??? "\t (omitting the filename also uses stdout)\n\n"
@@ -723,12 +724,14 @@ int main(int argc, char **argv)
 ??? uint32_t dev_index = 0;
 ??? int device_count;
 ??? int ppm_error = 0;
+??? int sync_mode = 0;
 ??? char vendor[256], product[256], serial[256];
+
 ??? fm_init(&fm);
 ??? pthread_mutex_init(&data_ready, NULL);
 ??? pthread_mutex_init(&data_write, NULL);
 
-??? while ((opt = getopt(argc, argv, "d:f:g:s:b:l:o:t:r:p:EFA:NWMULRDC")) != -1) {
+??? while ((opt = getopt(argc, argv, "d:f:g:s:b:l:o:t:r:p:EFA:NWMULRDSC")) != -1) {
 ??? ??? switch (opt) {
 ??? ??? case 'd':
 ??? ??? ??? dev_index = atoi(optarg);
@@ -815,6 +818,9 @@ int main(int argc, char **argv)
 ??? ??? case 'R':
 ??? ??? ??? fm.mode_demod = &raw_demod;
 ??? ??? ??? break;
+??? ??? case 'S':
+??? ??? ??? sync_mode = 1;
+??? ??? ??? break;
 ??? ??? default:
 ??? ??? ??? usage();
 ??? ??? ??? break;
@@ -921,9 +927,24 @@ int main(int argc, char **argv)
 ??? ??? fprintf(stderr, "WARNING: Failed to reset buffers.\n");}
 
 ??? pthread_create(&demod_thread, NULL, demod_thread_fn, (void *)(&fm));
-??? rtlsdr_read_async(dev, rtlsdr_callback, (void *)(&fm),
-??? ??? ??? ? ? ? DEFAULT_ASYNC_BUF_NUMBER,
-??? ??? ??? ? ? ? lcm_post[fm.post_downsample] * DEFAULT_BUF_LENGTH);
+??? if (sync_mode) {
+??? ??? fprintf(stderr, "Reading samples in sync mode...\n");
+??? ??? while (!do_exit) {
+??? ??? ??? r = rtlsdr_read_sync(dev, &fm.buf,
+??? ??? ??? ??? ??? ? ???lcm_post[fm.post_downsample] * DEFAULT_BUF_LENGTH,
+??? ??? ??? ??? ??? ? ???&fm.buf_len);
+??? ??? ??? if (r < 0) {
+??? ??? ??? ??? fprintf(stderr, "WARNING: sync read failed.\n");
+??? ??? ??? ??? break;
+??? ??? ??? }
+??? ??? ??? full_demod(&fm);
+??? ??? }
+??? } else {
+??? ??? fprintf(stderr, "Reading samples in async mode...\n");
+??? ??? rtlsdr_read_async(dev, rtlsdr_callback, (void *)(&fm),
+??? ??? ??? ??? ? DEFAULT_ASYNC_BUF_NUMBER,
+??? ??? ??? ??? ? lcm_post[fm.post_downsample] * DEFAULT_BUF_LENGTH);
+??? }
 
 ??? if (do_exit) {
 ??? ??? fprintf(stderr, "\nUser cancel, exiting...\n");}
-- 
1.8.1.3



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130423/d9638e6a/attachment.htm>

From stu at spacehopper.org  Tue Apr 23 19:57:17 2013
From: stu at spacehopper.org (Stuart Henderson)
Date: Tue, 23 Apr 2013 20:57:17 +0100
Subject: [PATCH 1/1] add -S (synchronous) mode to rtl_fm
In-Reply-To: <1366746407.92712.YahooMailClassic@web161506.mail.bf1.yahoo.com>
References: <20130423144733.GS9461@symphytum.spacehopper.org>
	<1366746407.92712.YahooMailClassic@web161506.mail.bf1.yahoo.com>
Message-ID: <20130423195717.GC9461@symphytum.spacehopper.org>

On 2013/04/23 12:46, Alan Corey wrote:
> Did you also fix the pthread_mutex_unlock when it was already unlocked?

No - I have hacked around it in what I've committed to OpenBSD ports
but it's not a fix ;)

>   The cmake patch should get included too.

yes (or something similar to it).

> For me this dumps core with an abort, so it sounds like the thread
> thing:

That's exactly what it looks like (if you take a backtrace you'll see
it's in rthread_sync.c:127)




From peter at stuge.se  Tue Apr 23 20:35:02 2013
From: peter at stuge.se (Peter Stuge)
Date: Tue, 23 Apr 2013 22:35:02 +0200
Subject: [PATCH 1/1] add -S (synchronous) mode to rtl_fm
In-Reply-To: <20130423144733.GS9461@symphytum.spacehopper.org>
References: <20130423144733.GS9461@symphytum.spacehopper.org>
Message-ID: <20130423203503.19551.qmail@stuge.se>

Stuart Henderson wrote:
> The enclosed diff adds a synchronous mode to rtl_fm. This helps
> OpenBSD (where libusb async isn't yet working).

The kernel so far only provides a synchronous API to libusb,
so yes, submit blocks until the transfer is complete. :\

I'm sure the kernel guys would appreciate some helping hands and minds.


//Peter



From Shinji.Ikari_de at gmx.de  Fri Apr 26 15:51:23 2013
From: Shinji.Ikari_de at gmx.de (Ronny Kunze)
Date: Fri, 26 Apr 2013 17:51:23 +0200
Subject: OpenSourceDABplusSDRreceiver
In-Reply-To: <5173DFFD.1040304@gmail.com>
References: <5173DFFD.1040304@gmail.com>
Message-ID: <517AA27B.7000408@gmx.de>

On 21.04.2013 14:47, mrzfrn wrote:
> "However, nobody has implemented a full and open DAB+ SDR receiver yet"
> Not true, look at
> http://www.sdr-j.tk/index.html
>
> Francesco
>
>
Hello ,

Thank you for the very good tip. It works after some small modifications.
The tuning is a little bit tricky because the drift of the oscillator 
and the individual displacement of the ensembles.
But in all i can receive all three DAB-Ensembles in my region.
Hopefully more people like to work on improving DAB reception whit Linux.

Ronny



From Shinji.Ikari_de at gmx.de  Fri Apr 26 15:55:56 2013
From: Shinji.Ikari_de at gmx.de (Ronny Kunze)
Date: Fri, 26 Apr 2013 17:55:56 +0200
Subject: OsmoSDR modification
In-Reply-To: <5173DFFD.1040304@gmail.com>
References: <5173DFFD.1040304@gmail.com>
Message-ID: <517AA38C.9090705@gmx.de>

Hello ,

are there some news about the piggyback PCB for the impedance matching 
of the OsmoSDR ?
Is the there an PCB available , with or without populated components?

Ronny



From mrzfrn at gmail.com  Fri Apr 26 17:47:58 2013
From: mrzfrn at gmail.com (mrzfrn)
Date: Fri, 26 Apr 2013 19:47:58 +0200
Subject: OpenSourceDABplusSDRreceiver
In-Reply-To: <517AA27B.7000408@gmx.de>
References: <5173DFFD.1040304@gmail.com> <517AA27B.7000408@gmx.de>
Message-ID: <517ABDCE.3040601@gmail.com>

On 04/26/2013 05:51 PM, Ronny Kunze wrote:
It works after some small modifications.
> The tuning is a little bit tricky because the drift of the oscillator
   Read the manual, paragraph 3.2.3
Install fmreceiver-dab (IMHO best wfm software receiver ,
...MPX display and even RDS pi-code ...)
  Tune a strong fm station and find best correction, after
  write it on .jsdr-dab.ini
> and the individual displacement of the ensemble
after correction displacement minimal
> But in all i can receive all three DAB-Ensembles in my region.
> Hopefully more people like to work on improving DAB reception whit Linux.
It is  work in progress, I'm sure improvements will come

Francesco




From 246tnt at gmail.com  Sun Apr 28 09:00:44 2013
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sun, 28 Apr 2013 11:00:44 +0200
Subject: gr-iqbal or gr-iqbalance?
In-Reply-To: <sig.982124110c.16665049.SeNOXA4bCZ@jawor.ire.pw.edu.pl>
References: <sig.982124110c.16665049.SeNOXA4bCZ@jawor.ire.pw.edu.pl>
Message-ID: <CAHL+j08Mgn3EhR31jBafAiZDuidpgB8qYd7xqRtfg8XCRF5m6Q@mail.gmail.com>

Hi,

> Which name should be used while building packages, etc.?

gr-iqbalance

The name of the git repo was probably a misunderstanding but I'm not
sure if we should change it now (and breaking links) or change it ...


> BTW: Is there any homepage for gr-iqbal/gr-iqbalance?

No. This is just a utility block. You can create a page about it on
the osmosdr wiki if you have anything to say about it.

Cheers,

    Sylvain



From alancorey at yahoo.com  Sun Apr 28 15:43:44 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Sun, 28 Apr 2013 08:43:44 -0700 (PDT)
Subject: Scanning with rtl_fm
Message-ID: <1367163824.92255.YahooMailClassic@web161501.mail.bf1.yahoo.com>

I'm using rtl_fm in a scanning (nbfm) situation, and even with the antenna input disconnected and terminated, I get a burst of noise that sounds like a squelch tail maybe once each scan cycle.? They're a little over 1 second apart.? I've tried setting the squelch up to 10000 where I don't get signals anymore, but I still get the noise.

I discovered that if you scan and have the output be a raw audio file, nothing gets recorded when nothing breaks squelch.? This makes time-lapse recordings where all the pauses are taken out.? Very nice, except for the noise bursts.

I'm using:
#!/bin/sh
rtl_fm -N -S -l 132 -p 102 -f 854040000 -f 854240000 -f 854315000 -f 854415000 -f \
854490000 -f 854540000 -f 855165000 -f 855240000 -f 858790000 -f 867350000 \
-f 867715000 /tmp/`date +"%Y-%m-%d_%H%M.raw"`

and recorded overnight, but I mostly got noise bursts.

? Alan
-----

Radio Astronomy - the ultimate DX
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130428/06fe87dd/attachment.htm>

From ka2rrz at yahoo.com  Sun Apr 28 19:01:36 2013
From: ka2rrz at yahoo.com (Ron Hayes)
Date: Sun, 28 Apr 2013 12:01:36 -0700 (PDT)
Subject: Scanning with rtl_fm
In-Reply-To: <1367163824.92255.YahooMailClassic@web161501.mail.bf1.yahoo.com>
References: <1367163824.92255.YahooMailClassic@web161501.mail.bf1.yahoo.com>
Message-ID: <1367175696.74306.YahooMailNeo@web120805.mail.ne1.yahoo.com>

Last year our power company changed the meter so they can read it from there office and it seems to be in the VHF area, I havent pin pointed if its a fact yet But I am now getting a large burst I didnt have before.

 

________________________________
 From: Alan Corey <alancorey at yahoo.com>
To: osmocom-sdr at lists.osmocom.org 
Sent: Sunday, April 28, 2013 10:43 AM
Subject: Scanning with rtl_fm
  
I'm using rtl_fm in a scanning (nbfm) situation, and even with the antenna input disconnected and terminated, I get a burst of noise that sounds like a squelch tail maybe once each scan cycle.? They're a little over 1 second apart.? I've tried setting the squelch up to 10000 where I don't get signals anymore, but I still get the noise.

I discovered that if you scan and have the output be a raw audio file, nothing gets recorded when nothing breaks squelch.? This makes time-lapse recordings where all the pauses are taken out.? Very nice, except for the noise bursts.

I'm using:
#!/bin/sh
rtl_fm -N -S -l 132 -p 102 -f 854040000 -f 854240000 -f 854315000 -f 854415000 -f \
854490000 -f 854540000 -f 855165000 -f 855240000 -f 858790000 -f 867350000 \
-f 867715000 /tmp/`date +"%Y-%m-%d_%H%M.raw"`

and recorded
 overnight, but I mostly got noise bursts.

? Alan
-----
Radio Astronomy - the ultimate DX    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130428/6568d642/attachment.htm>

From alancorey at yahoo.com  Sun Apr 28 20:48:46 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Sun, 28 Apr 2013 13:48:46 -0700 (PDT)
Subject: Scanning with rtl_fm
In-Reply-To: <1367175696.74306.YahooMailNeo@web120805.mail.ne1.yahoo.com>
Message-ID: <1367182126.84086.YahooMailClassic@web161505.mail.bf1.yahoo.com>

Thank you.? QST has talked a good deal about the fact that power companies in some areas were trying to put broadband wireless internet out over power lines.? It didn't work very well and radiated enough to be a major nuisance.? Either they quit on their own or the FCC made them stop, I forget which.? This sounds similar.? I'm ab1jx by the way.? You should be able to see that with sdr sharp.

I don't know whether it depends on frequency or not, but I can scan the AM aircraft frequencies around 120 MHz and I don't have the same problem.

#!/bin/sh
rtl_fm -M -S -l 132 -p 102 -f 123000000 -f 135675000 -f 123750000 -f 122700000 \
-f 125350000 -f 133600000 -f 118350000 -f 134850000 -f 119600000 -f 122950000 \
-f 121500000 -f 126450000 -f 121600000 -f 127800000 -f 126450000 -f 122800000 \
-f 135675000 -f 135875000 -f 119025000 /tmp/`date +"air_%Y-%m-%d_%H%M.raw"`

That doesn't pick up anything odd, just pilots talking.? The other is Massachusetts state police around 850 MHz nbfm.? I tried taking each frequency out of the pool one at a time, raising the squelch level (it's an int by the way).? 

I have a couple of pigtails that fit my dongles, so I put a 50 ohm terminator in place of the antenna and I still hear it, even here in a basement.? It could be something from a computer, but it isn't on any one particular frequency.

I was thinking it was some artifact of the demodulation method used.? If that were the case other people would hear it too when they scan.? It isn't a local noise I don't think.

? Alan
-----

Radio Astronomy - the ultimate DX

--- On Sun, 4/28/13, Ron Hayes <ka2rrz at yahoo.com> wrote:

From: Ron Hayes <ka2rrz at yahoo.com>
Subject: Re: Scanning with rtl_fm
To: "Alan Corey" <alancorey at yahoo.com>, "osmocom-sdr at lists.osmocom.org" <osmocom-sdr at lists.osmocom.org>
Date: Sunday, April 28, 2013, 3:01 PM

Last year our power company changed the meter so they can read it from there office and it seems to be in the VHF area, I havent pin pointed if its a fact yet But I am now getting a large burst I didnt have before.
        From: Alan Corey <alancorey at yahoo.com>
 To: osmocom-sdr at lists.osmocom.org 

 Sent: Sunday, April 28, 2013 10:43 AM
 Subject: Scanning with rtl_fm
   I'm using rtl_fm in a scanning (nbfm) situation, and even with the antenna input disconnected and terminated, I get a burst of noise that sounds like a squelch tail maybe once each scan cycle.? They're a little over 1 second apart.? I've tried setting the squelch up to 10000 where I don't get signals anymore, but I still get the noise.

I discovered that if you scan and have the output be a raw audio file, nothing gets recorded when nothing breaks squelch.? This makes time-lapse recordings where all the pauses are taken out.? Very nice,
 except for the noise bursts.

I'm using:
#!/bin/sh
rtl_fm -N -S -l 132 -p 102 -f 854040000 -f 854240000 -f 854315000 -f 854415000 -f \
854490000 -f 854540000 -f 855165000 -f 855240000 -f 858790000 -f 867350000 \
-f 867715000 /tmp/`date +"%Y-%m-%d_%H%M.raw"`

and recorded
 overnight, but I mostly got noise bursts.

? Alan
-----

Radio Astronomy - the ultimate DX    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130428/ad64cbd1/attachment.htm>

From lists at the-reapers.com  Tue Apr 30 11:53:22 2013
From: lists at the-reapers.com (Chourico)
Date: Tue, 30 Apr 2013 11:53:22 +0000 (UTC)
Subject: =?utf-8?b?cnRsX2Zt?= scanning
References: <51462B42.50301@gmail.com>
Message-ID: <loom.20130430T134351-50@post.gmane.org>

Colin Stagner <cbs228 <at> gmail.com> writes:

> 
> I am also having the rtl_fm scanning bug which was first reported in
> http://lists.gnumonks.org/pipermail/osmocom-sdr/2013-February/000485.html
> 

> 
> Can anyone else reproduce this bug?
> 
> 

I am having the same problem.

EzTV666, Ubuntu 12.04, kernel 3.2.0-23,
latest rtl_sdr from git, 2013-04-30

rtl_fm works fine when only one frequency is specified, hangs after first
frequency is skipped.






From alancorey at yahoo.com  Tue Apr 30 18:07:21 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Tue, 30 Apr 2013 11:07:21 -0700 (PDT)
Subject: rtl_fm scanning
In-Reply-To: <loom.20130430T134351-50@post.gmane.org>
Message-ID: <1367345241.95864.YahooMailClassic@web161505.mail.bf1.yahoo.com>

Mine doesn't hang, it just makes a noise.? If I change just the demodulator to AM instead of FM, it doesn't do it. If I set the squelch level up around 1000 it takes out the signals, but not the noise.

OpenBSD 5.2, ftl_fm from git about 4/23/2013

? Alan

-----

Radio Astronomy - the ultimate DX

--- On Tue, 4/30/13, Chourico <lists at the-reapers.com> wrote:

From: Chourico <lists at the-reapers.com>
Subject: Re: rtl_fm scanning
To: osmocom-sdr at lists.osmocom.org
Date: Tuesday, April 30, 2013, 7:53 AM

Colin Stagner <cbs228 <at> gmail.com> writes:

> 
> I am also having the rtl_fm scanning bug which was first reported in
> http://lists.gnumonks.org/pipermail/osmocom-sdr/2013-February/000485.html
> 

> 
> Can anyone else reproduce this bug?
> 
> 

I am having the same problem.

EzTV666, Ubuntu 12.04, kernel 3.2.0-23,
latest rtl_sdr from git, 2013-04-30

rtl_fm works fine when only one frequency is specified, hangs after first
frequency is skipped.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130430/ab005556/attachment.htm>

From benjamin.n.moore at gmail.com  Tue Apr 30 19:16:58 2013
From: benjamin.n.moore at gmail.com (Ben Moore)
Date: Tue, 30 Apr 2013 12:16:58 -0700
Subject: rtl_fm scanning
In-Reply-To: <1367345241.95864.YahooMailClassic@web161505.mail.bf1.yahoo.com>
References: <1367345241.95864.YahooMailClassic@web161505.mail.bf1.yahoo.com>
Message-ID: <29247AB4-B695-4C87-BF70-6C201F0FA15E@gmail.com>

I haven't had a chance to check on the Raspberry Pi to see if this issue is fixed by forcing synchronous mode, but I suspect it is.

http://lists.gnumonks.org/pipermail/osmocom-sdr/2013-April/000588.html

- Ben


On Apr 30, 2013, at 11:07 AM, Alan Corey wrote:

> Mine doesn't hang, it just makes a noise.  If I change just the demodulator to AM instead of FM, it doesn't do it. If I set the squelch level up around 1000 it takes out the signals, but not the noise.
> 
> OpenBSD 5.2, ftl_fm from git about 4/23/2013
> 
>   Alan
> 
> -----
> Radio Astronomy - the ultimate DX
> 
> --- On Tue, 4/30/13, Chourico <lists at the-reapers.com> wrote:
> 
> From: Chourico <lists at the-reapers.com>
> Subject: Re: rtl_fm scanning
> To: osmocom-sdr at lists.osmocom.org
> Date: Tuesday, April 30, 2013, 7:53 AM
> 
> Colin Stagner <cbs228 <at> gmail.com> writes:
> 
> > 
> > I am also having the rtl_fm scanning bug which was first reported in
> > http://lists.gnumonks.org/pipermail/osmocom-sdr/2013-February/000485.html
> > 
> 
> > 
> > Can anyone else reproduce this bug?
> > 
> > 
> 
> I am having the same problem.
> 
> EzTV666, Ubuntu 12.04, kernel 3.2.0-23,
> latest rtl_sdr from git, 2013-04-30
> 
> rtl_fm works fine when only one frequency is specified, hangs after first
> frequency is skipped.
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130430/f8563534/attachment.htm>

From mjmdavis at gmail.com  Tue Apr 30 19:25:20 2013
From: mjmdavis at gmail.com (Michael Davis)
Date: Tue, 30 Apr 2013 21:25:20 +0200
Subject: submitting patches
Message-ID: <0DD7EDBF-0DCE-43EF-8F57-086035025E3B@gmail.com>

Hi All,

Can anyone point me in the direction of a place I can go to submit patches?

I fixed a bug in CMake for gnuradio-osmosdr that stopped the build on my system.

Best,
Mike


From horiz0n at gmx.net  Tue Apr 30 19:41:18 2013
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Tue, 30 Apr 2013 21:41:18 +0200
Subject: submitting patches
In-Reply-To: <0DD7EDBF-0DCE-43EF-8F57-086035025E3B@gmail.com>
References: <0DD7EDBF-0DCE-43EF-8F57-086035025E3B@gmail.com>
Message-ID: <op.wwdcy4mpvay7ep@wopr.artelis.net>

Hi Michael,

just send them to this list or the particular maintainer.

Best regards,
Dimitri

On Tue, 30 Apr 2013 21:25:20 +0200, Michael Davis <mjmdavis at gmail.com>  
wrote:

> Hi All,
>
> Can anyone point me in the direction of a place I can go to submit  
> patches?
>
> I fixed a bug in CMake for gnuradio-osmosdr that stopped the build on my  
> system.
>
> Best,
> Mike



From electronixtar at gmail.com  Thu Apr 25 01:51:27 2013
From: electronixtar at gmail.com (est)
Date: Thu, 25 Apr 2013 09:51:27 +0800
Subject: [Discuss-gnuradio] nVidia's Tegra 4 has SDR - the i500 LTE soft
	modem from Icera
In-Reply-To: <CA+=kK2KE2+FHzG12qvogyDjnaMpQjorzh2VxXJSALxqrruEc_Q@mail.gmail.com>
References: <CA+=kK2JmM3dCLbimRH1WrD5BVjD7=kbN_+w6Bq=DduDYNcD8OA@mail.gmail.com>
	<CA+SzT6gHCe-AcWi-eXk-AD5xs1xd78A93OB7MJMwCjWMu5yyhQ@mail.gmail.com>
	<CAKo12-nSZVkP_DjUHkq_Bf=tpLUvz4DoxUrdwmUzCqvUprCb2A@mail.gmail.com>
	<50EB0609.9090202@ripnet.com>
	<CA+FEAncFvHRdDtMdKLJFbgeNzG73fF=TmV5y=vtE96DEt_rReQ@mail.gmail.com>
	<lz4nirk218.fsf@gmail.com>
	<CAP2dER2y0_mkZ71XyRy1dH+=vqK4bZgazykQ=Hxej+4RcYFRkA@mail.gmail.com>
	<lzd2x76d86.fsf@gmail.com>
	<CAP2dER33nLsDbbaMadNWLYoohNXxjC4kQeOtpahj+sHM7JgQQw@mail.gmail.com>
	<CA+=kK2LuvTBMkZ4=bNXYZNqvtUfMosd_=_5SBciNpZyiaTzZNw@mail.gmail.com>
	<CAP2dER2pwPRuW8n4WFjF0gMMnBKTuHfyDGo3SNrmWG=9LCrktA@mail.gmail.com>
	<CA+=kK2KE2+FHzG12qvogyDjnaMpQjorzh2VxXJSALxqrruEc_Q@mail.gmail.com>
Message-ID: <CA+=kK2+8Mb00yExjZe=V++TsrT5unV593xreK4uDbr3xtOs-1w@mail.gmail.com>

Hello group,

What do you guys think of the nVidia Tegra 4's i500 SDR?

http://www.engadget.com/2013/01/07/nvidia-i500-soft-modem/

http://www.nvidia.com/docs/IO/116757/NVIDIA_i500_whitepaper_FINALv3.pdf

Is it hackable?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130425/d447e798/attachment.htm>

From alalbiol at iteam.upv.es  Fri Apr 26 18:40:09 2013
From: alalbiol at iteam.upv.es (Alberto Albiol)
Date: Fri, 26 Apr 2013 20:40:09 +0200
Subject: Compiling on osx - solved...
Message-ID: <CAKQd66W+zN96v4GH3_gQdw+qSFsyJfUAgwoe=6es3mz_kQF5iw@mail.gmail.com>

Hello
I have been fighting to compile the gr-osmosdr package in my osx

These are the minor fixes I had to do:
1- Change in Cmakelists.txt:  find_package(Boost COMPONENTS thread system),
If thread and system is not included then there are linking problems.
Although I see that this was removed recently...

 2- cmake -DCMAKE_INSTALL_PREFIX=/opt/local (so it is installed together
wit my ports intallation, this is really optional)
3- Before compiling I manually edit CmakeCache.txt, and change all the
references of /usr/lib/python to /opt/local/lib/python. If not it links
agains the system python instead of the ports's python!
4- Add this line in my .bashrc so python can find the package
          export PYTHONPATH="/opt/local/lib/python2.7/site-packages/"

I am aware that this is not the most elegant way to solve the problem but
is the only one that I was able to come up. Hope it helps


Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130426/24ea06b0/attachment.htm>