From lin.zhemin at gmail.com  Fri Jan  8 09:18:23 2016
From: lin.zhemin at gmail.com (Lin Zhemin)
Date: Fri, 8 Jan 2016 09:18:23 +0000 (UTC)
Subject: gr-osmosdr broken on OSX due to =?utf-8?b?TVNHX05PU0lHTkFM?=
References: <CAGGi21YxbgP1MHqNhhL4KDw39-iPNJCk2uux6aJsnzm8R-wkxg@mail.gmail.com>
Message-ID: <loom.20160108T101730-586@post.gmane.org>

Elliot Saba <staticfloat <at> gmail.com> writes:

> 
> It looks like the block to redefine MSG_NOSIGNAL as SO_NOSIGPIPE inside of 
redpitaya_common.cc needs to be copied into redpitaya_sinc_c.cc as well.-E
> 


+1.
It caused "brew install gr-osmosdr --HEAD" to fail.




From pavel.demin at uclouvain.be  Fri Jan  8 10:01:41 2016
From: pavel.demin at uclouvain.be (Pavel Demin)
Date: Fri, 8 Jan 2016 11:01:41 +0100
Subject: gr-osmosdr broken on OSX due to MSG_NOSIGNAL
In-Reply-To: <loom.20160108T101730-586@post.gmane.org>
References: <CAGGi21YxbgP1MHqNhhL4KDw39-iPNJCk2uux6aJsnzm8R-wkxg@mail.gmail.com>
 <loom.20160108T101730-586@post.gmane.org>
Message-ID: <568F8905.7030304@uclouvain.be>

Hi,

I've sent to Dimitri a patch that fixes compilation errors on Mac OS X 
and on MS Windows.

Cheers,

Pavel



From horiz0n at gmx.net  Sun Jan 10 21:38:08 2016
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Sun, 10 Jan 2016 22:38:08 +0100
Subject: gr-osmosdr broken on OSX due to MSG_NOSIGNAL
In-Reply-To: <568F8905.7030304@uclouvain.be>
References: <CAGGi21YxbgP1MHqNhhL4KDw39-iPNJCk2uux6aJsnzm8R-wkxg@mail.gmail.com>
 <loom.20160108T101730-586@post.gmane.org> <568F8905.7030304@uclouvain.be>
Message-ID: <op.ya1k1urvvay7ep@wopr.artelis.net>

Hi Pavel, i've applied the patch, thanks!

Best regards,
Dimitri

On Fri, 08 Jan 2016 11:01:41 +0100, Pavel Demin <pavel.demin at uclouvain.be>  
wrote:

> Hi,
>
> I've sent to Dimitri a patch that fixes compilation errors on Mac OS X  
> and on MS Windows.
>
> Cheers,
>
> Pavel


From horiz0n at gmx.net  Sun Jan 10 21:52:05 2016
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Sun, 10 Jan 2016 22:52:05 +0100
Subject: gr-osmosdr setting value in destructor
In-Reply-To: <5611309D.4010503@seznam.cz>
References: <5611309D.4010503@seznam.cz>
Message-ID: <op.ya1lo3qlvay7ep@wopr.artelis.net>

Hi Jiri, i'd be happy to accept such patch.

Best regards,
Dimitri

On Sun, 04 Oct 2015 15:58:53 +0200, P <j-pi at seznam.cz> wrote:

> Hi,
>
> there is in gr-osmosdr a lot of code like:
>
> hackrf_source_c::~hackrf_source_c ()
> {
> ...
>     free(_buf);
>     _buf = NULL;
>   }
> }
>
> Setting value in destructor have sense in two case:
>   - they are used in some way in destructor of parent class
>   - You set then to something like 0xDEADBEEF and when pointer
>     from already destroyed class is used it will cause segfault.
>
> Setting value to NULL is contraproductive because there is a lot of
> checks if value is not NULL, this actually can hide some troubles of
> calling something using already freed pointer.
>
> I'm suggesting to remove this kind of code. I will prepare patch but now
> I'm waiting if those two pending patches I have send before would be
> accepter or not.
>
> Is there any opinion which oppose previous claim?
>
> With best regards,
> 	JP.


From horiz0n at gmx.net  Sun Jan 10 21:52:06 2016
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Sun, 10 Jan 2016 22:52:06 +0100
Subject: [PATCH] clear warnings about compare signed-unsigned values
In-Reply-To: <561124B0.7060809@seznam.cz>
References: <561124B0.7060809@seznam.cz>
Message-ID: <op.ya1lo4kwvay7ep@wopr.artelis.net>

Hi Jiri, this has been applied a wile ago when i reworked hackrf a bit.  
Thanks!

Best regards,
Dimitri

On Sun, 04 Oct 2015 15:08:00 +0200, P <j-pi at seznam.cz> wrote:

> This just removes few annoying warnings.
>
> About the conversion of string to signed int.
>
> -          dev_index = boost::lexical_cast< unsigned int >(  
> hackrf_serial );
> +          dev_index = boost::lexical_cast< int >( hackrf_serial );
>
>
> hackrf_device_list_open checks if value of dev_index is out
>  of range (eg negative) and returns proper error. In future negative  
> value
> can be used for something so this check is not necessary nor wanted.
>
> P


From horiz0n at gmx.net  Sun Jan 10 21:52:06 2016
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Sun, 10 Jan 2016 22:52:06 +0100
Subject: [PATCH] do not check for NULL before calling free
In-Reply-To: <56112378.6040005@seznam.cz>
References: <56112378.6040005@seznam.cz>
Message-ID: <op.ya1lo4kwvay7ep@wopr.artelis.net>

Hi Jiri, thanks for the patch, i've applied it without the  
"find_package(Gnuradio 3.8 REQUIRED)" line.

Best regards,
Dimitri


On Sun, 04 Oct 2015 15:02:48 +0200, P <j-pi at seznam.cz> wrote:

> Checking if variable is not NULL before calling free() is not effective,
> because free() already does this.
>
>   - waste instruction and/or compiler time
>   - more lines of code than necessary
>
>
> This patch removes those checks.


From martin_z_smith at yahoo.ie  Mon Jan 11 00:29:12 2016
From: martin_z_smith at yahoo.ie (Martin Smith)
Date: Mon, 11 Jan 2016 00:29:12 +0000
Subject: Airspy patch to enable USB bit packing
Message-ID: <5692F758.6080900@yahoo.ie>

Last July there were several changes made to the Airspy firmware and
libairspy that added support for a new bit packing mode where 4 sets of
12 bit samples are packed into 3 sets of 16 bits for the transfer across
the USB bus ( https://i.imgur.com/qXnWoEK.png?1 ). 25% less data is
transferred across the bus and this is good for some computers with
cheap USB chipsets. There is an overhead of extra memory bandwidth
required on the host side to unpack the data into a useful format, so
for optimal performance bit packing is disabled by default.

The data is automatically unpacked within libairspy before being passed
along, so no changes are required anywhere else if packing is enabled
(or not enabled). Airspy firmware older than v1.0.0-rc6 does not have
the function, but that is detected and handled by libairspy. 

I wrote the attached patch to enable packing in gr-osmosdr, which I
tested and it works. It is basically a clone of the bias=0|1 lines as
pack=0|1 and calls the needed libairspy function.

ref:
https://github.com/airspy/firmware/commit/7e1806b
https://github.com/airspy/firmware/commit/5b7dcab
https://github.com/airspy/host/commit/a51eccb


---
Do some Baseline test with Airspy command line tools to have something
to compare USB throughput results
--------------------------------------------------------------------------------------------------------
$ sudo mount -t debugfs none /sys/kernel/debug
$ sudo modprobe usbmon
$ wireshark -i usbmod3 &
$ airspy_info ; sleep 120 ; \
airspy_rx -t 4 -r /dev/null -n 2400000000 ; sleep 120 ; \
airspy_rx -t 4 -r /dev/null -p 1 -n 2400000000 ; sleep 120 ; \
airspy_info
Wireshark->Statistics->IO Graph
The Bytes/Tick are double the actual data rate because of way wireshark
collects the USB packets, I could have added a filter to fix this. But
the relationship is valid 25% less with packing enabled. The data rate
in the IO Grahp drops from 80MB/sec (in+out) [really 40MB/sec] to
60MB/second (in+out) [really 30MB/sec] from unpacked to packed.
10MSPS no packing, packing https://i.imgur.com/pA9LPdE.png?1
2.5MSPS no packing, packing https://i.imgur.com/lA8q5aq.png?1


Verification test with my patched gr-osmosdr
--------------------------------------------
$ sudo mount -t debugfs none /sys/kernel/debug
$ sudo modprobe usbmon
$ wireshark -i usbmod3 &
$ osmocom_fft -a "airspy=0" -s 10000000 --fft-rate=1
$ osmocom_fft -a "airspy=0,pack=1" -s 10000000 --fft-rate=1
$ osmocom_fft -a "airspy=0" -s 2500000 --fft-rate=1
$ osmocom_fft -a "airspy=0,pack=1" -s 2500000 --fft-rate=1
$ osmocom_fft -a "airspy=0" -s 2500000 --fft-rate=1
$ osmocom_fft -a "airspy=0,pack=0" -s 2500000 --fft-rate=1

I ran all of the above tests and the wireshark USB throughput graphs
showed exactly what was expected.
40MB/sec(10MSPS+normal),30MB/sec(10MSPS+packing),10MB/sec(2.5MSPS+normal),7.5MB/sec(2.5MSPS+packing),10MB/sec(2.5MSPS+normal),10MB/sec(2.5MSPS+normal).

25% less when packing was enabled and if you did not specify the
"pack=1", then no bit packing is performed by libairspy. All the
magnitudes within the FFT windows looked exactly the same as they do
without bit packing.
-------------- next part --------------
--- gr-osmosdr.orig/lib/airspy/airspy_source_c.cc	2016-01-10 23:38:03.590425152 +0000
+++ gr-osmosdr/lib/airspy/airspy_source_c.cc	2016-01-10 23:41:04.356672407 +0000
@@ -153,6 +153,16 @@
     AIRSPY_THROW_ON_ERROR(ret, "Failed to enable DC bias")
   }
 
+/* pack 4 sets of 12 bits into 3 sets 16 bits for the data transfer across the
+ * USB bus. The default is is unpacked, to transfer 12 bits across the USB bus
+ * in 16 bit words. libairspy transparently unpacks if packing is enabled */
+  if ( dict.count( "pack" ) )
+  {
+    bool pack = boost::lexical_cast<bool>( dict["pack"] );
+    int ret = airspy_set_packing(_dev, (uint8_t)pack);
+    AIRSPY_THROW_ON_ERROR(ret, "Failed to enable USB bit packing")
+  }
+
   _fifo = new boost::circular_buffer<gr_complex>(5000000);
   if (!_fifo) {
     throw std::runtime_error( std::string(__FUNCTION__) + " " +

From henk.vergonet at gmail.com  Mon Jan 11 16:32:54 2016
From: henk.vergonet at gmail.com (Henk)
Date: Mon, 11 Jan 2016 17:32:54 +0100
Subject: [patch]: rtl_sdr, fix -n parameter
Message-ID: <CAMFK4TMrMhPA-jL-DJ4R+V=qdDm83xC-NT+yPL59xLYKmPLGog@mail.gmail.com>

Fix bytes_to_read adjustment in callback.

For example bug exposes itself with:
  rtl_sdr -f 100e6 -s 2048000 -n 245.76e6 /tmp/100M.iq
and does not terminate after the expected 245.76e6 samples.
Which is an exact multiple of "out_block_size".

Signed-off-by: Henk vergonet <henk.vergonet at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtl_sdr.patch
Type: application/octet-stream
Size: 607 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20160111/b680a5cb/attachment.obj>

From picmaster at mail.bg  Fri Jan 15 21:51:46 2016
From: picmaster at mail.bg (Nikolay Dimitrov)
Date: Fri, 15 Jan 2016 23:51:46 +0200
Subject: [rtl-sdr][PATCH 1/2] rtl_fm: Add scanner progress
In-Reply-To: <55FFD2C7.8090806@mail.bg>
References: <1436013743-32758-1-git-send-email-picmaster@mail.bg>
 <55FFD242.2080308@mail.bg> <55FFD2C7.8090806@mail.bg>
Message-ID: <569969F2.9020703@mail.bg>

Hi Dimitri,

On 09/21/2015 12:49 PM, Nikolay Dimitrov wrote:
> Oops, forgot to CC the mailing list.
>
>
> On 09/21/2015 12:47 PM, Nikolay Dimitrov wrote:
>> Hi Dimitri,
>>
>> On 07/04/2015 03:42 PM, Nikolay Dimitrov wrote:
>>> Add scanner progress, including signal and squelch levels.
>>> Rename demod_state->conseq_squelch to demod_state->squelch_conseq.
>>>
>>> The scanner progress feature can be tested like this:
>>>
>>> ./rtl_fm -f 144.000M:146.000M:25k -M fm -s 48k -l 100 -t 5 | aplay \
>>>     -r 48k -f S16_LE -t raw -c 1
>>>
>>> Signed-off-by: Nikolay Dimitrov <picmaster at mail.bg>
>>> ---
>>>   src/rtl_fm.c |   43 +++++++++++++++++++++++++++++--------------
>>>   1 file changed, 29 insertions(+), 14 deletions(-)
>>
>> Can you please take a look at this patch and decide whether it's worthy
>> of applying to the rtl-sdr tree?
>>
>> Thanks in advance. Regards,
>> Nikolay

What is the preferred way to receive rtlsdr patches - is it via this ML
or via github pull requests?

Thanks and regards,
Nikolay


From mtologlu at hotmail.com  Sun Jan 24 18:49:47 2016
From: mtologlu at hotmail.com (Murat Tologlu)
Date: Sun, 24 Jan 2016 20:49:47 +0200
Subject: Distinction between librtlsdr and rtl-sdr repositories
Message-ID: <DUB123-DS16ED42345FF67E19B39532C4C60@phx.gbl>

Hi,

 

I appreciate very much to receive your comments on the distinctions between
steve-m/libsrtlsdr and keenerd/rtl-sdr (forked from pinkavaj/rtl-sdr 129
commit ago and maintained).

 

Both have very similar structure, flies, purpose but the software is not
exactly same. There are something attractive for me in one of them while the
other one is also good. 

 

?s it possible to create patch from one of them and apply to the other to
merge two repos together?? Why I am asking is, rtl-sdr has a new agc -
aggressive agc option which is useful for me but I prefer to stay on
librtlsdr; is there a solution?

 

Thanks in advance, 

Murat.

 

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

From josh at joshknows.com  Sun Jan 31 01:36:02 2016
From: josh at joshknows.com (Josh Blum)
Date: Sat, 30 Jan 2016 17:36:02 -0800
Subject: Ubuntu+Windows binaries for GNURadio/GrOsmo
Message-ID: <56AD6502.8070905@joshknows.com>

Hey list,

This is an update and an announcement: Alexandru Csete and I have been 
maintaining an Ubuntu PPA for SDR community software for some time. We 
just updated to GNU Radio 3.7.9 and GrOsmoSDR with RedPitaya support.

The goal of the PPA is to have have recent releases of community 
software (SDR drivers, GNU Radio, and related projects) across several 
versions of Ubuntu. Simply follow the apt-get instructions here:
http://wiki.myriadrf.org/Packaging

I figure that a lot of people (both developers and users) can benefit 
from the shared effort. If you find a bug, have a request, or want to 
get involved; please let us know, we would love to hear it: 
https://discourse.myriadrf.org/c/projects/packaging

On the windows side of things, I am pleased to announce the PothosSDR 
installer/development environment; which now includes around 40 open 
source projects. We just updated to the latest GNURadio/GrOsmoSDR, and 
recently additions include GQRX, gr-rds, and zeromq support.

Instructions for GNURadio/GRC and GQRX users:
https://github.com/pothosware/PothosSDR/wiki/GNURadio
https://github.com/pothosware/PothosSDR/wiki/GQRX

Special thanks to Andrew Back and Myriadrf for all of the support and 
hosting the software!

Thanks,
-josh


From magnus.paulsson at lnu.se  Sat Jan 16 11:05:30 2016
From: magnus.paulsson at lnu.se (Magnus Paulsson)
Date: Sat, 16 Jan 2016 11:05:30 -0000
Subject: peekSDR
Message-ID: <7DE514AE-DF91-402A-B9EA-40BAAA975801@lnu.se>

I?ve been playing with a python application to scan, find and record strong signals.
I attached the code with the hope that someone would like to improve it ? maybe
put it on sourceforge or github. I will not have time to do anything about it for a few
weeks.

Works at least with linux ? haven?t tried OSX or win.
Needs: numpy, scipy, matplotlib, npyscreen (https://pypi.python.org/pypi/npyscreen/),
pyrtlsdr (https://github.com/roger-/pyrtlsdr/releases [use the old release, new code python 3 only])

start with:

python peekSDR.py -d (in one window to start database)
python peekSDR.py -vr (in one window to start radio scanning)
python peekSDR.py -g (in one window to start user interface)

[can be run on different computers as long as you have the same filesystem and stand in the same directory]

in the user interface ?f? plots ffts of recorded signals. ?1? starts gqrx with the recorded signal.

Best wishes - Magnus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20160116/1eb5dad0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: peekSDR.tgz
Type: application/octet-stream
Size: 7930 bytes
Desc: peekSDR.tgz
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20160116/1eb5dad0/attachment.obj>