From lucas at teske.net.br  Wed Mar  2 01:35:27 2016
From: lucas at teske.net.br (Lucas Teske)
Date: Tue, 1 Mar 2016 22:35:27 -0300
Subject: post a new release
In-Reply-To: <CAMFK4TPL=RT_ecP60prBaDZMT_YCc27CNBeJ5ZdzNoOpfjR8VA@mail.gmail.com>
References: <CAOonV0rDm9z1Vd5ZVBjF==qV3XCC3Ven_TPPPLLhac1cTdnn3g@mail.gmail.com>
 <CAMFK4TMEziWDo=XO6uU0CEMy+E62iPSGh+pTiAaJZm1WDByxhg@mail.gmail.com>
 <CAMFK4TPL=RT_ecP60prBaDZMT_YCc27CNBeJ5ZdzNoOpfjR8VA@mail.gmail.com>
Message-ID: <56D6435F.5090406@teske.net.br>

Btw, I made some changes (I merged some changes from a fork of rtlsdr 
that allows manual control of the VGA, LNA, Mixer Gains) and added a 
Debian Package Generator.

https://github.com/racerxdl/librtlsdr

I just don't know how relevante is Debian Package Generator (also it is 
sort of incomplete).

Should I make a PR to the oficial github with the changes of the VLM 
Gains? Here is the commit:

https://github.com/racerxdl/librtlsdr/commit/25d0e8e6737b93b3564ad04d0fd2cd5e91cefa8b

It is very helpfull for me to get NOAA APT Signals adjusting manually 
each gain.

Regards,

Lucas

PS: Sorry Henk, I sent only to you.

Em 29/02/2016 14:34, Henk escreveu:
> Oeps, sorry forgot to quote the original post of joseph.
>
> +1
> Hmm in my opinion rtl_sdr is the next best thing since the invention
> of canned beer :) since it liberated the airwaves for allot of users.
>
> Regards,
> henk
>
> On Sun, Feb 28, 2016 at 7:11 PM, Joseph Poirier <jdpoirier at gmail.com> wrote:
>> If would be nice to have a newer official release available; installation
>> using the package manager on many Linux distros gets a two year old
>> librtlsdr that's missing the rtlsdr_set_tuner_bandwidth function (added
>> about nine months ago), as well as, other nice updates and fixes.
>>
>> cheers,
>> joe



From a.kurpiers at gmail.com  Wed Mar  2 17:13:12 2016
From: a.kurpiers at gmail.com (Alexander Kurpiers)
Date: Wed, 2 Mar 2016 18:13:12 +0100
Subject: post a new release
In-Reply-To: <56D6435F.5090406@teske.net.br>
References: <CAOonV0rDm9z1Vd5ZVBjF==qV3XCC3Ven_TPPPLLhac1cTdnn3g@mail.gmail.com>
 <CAMFK4TMEziWDo=XO6uU0CEMy+E62iPSGh+pTiAaJZm1WDByxhg@mail.gmail.com>
 <CAMFK4TPL=RT_ecP60prBaDZMT_YCc27CNBeJ5ZdzNoOpfjR8VA@mail.gmail.com>
 <56D6435F.5090406@teske.net.br>
Message-ID: <56D71F28.1020500@gmail.com>

I agree that the official code lacks proper manual gain control - but I
would still prefer some nice presets. Being able to adjust the internal
gain controls of the tuner chips to me is a bonus (as you really need to
know what you are doing).

As many others, I've started my fork (current version
https://github.com/dl8aau/librtlsdr/tree/devel1), which among other
things includes manual gain settings optimized for E4000 and R820T
(optimization done by Leif Asbrink for Linrad). Something like this is
badly needed for applications that cannot use the automatic gain control.

There are many other forks with interesting features and there seems
lots of duplicate work... I would love to see these merged back into the
official release, but I actually do not believe this is going to happen
any time soon.

Regards,

Alexander


On 03/02/2016 02:35 AM, Lucas Teske wrote:
> Btw, I made some changes (I merged some changes from a fork of rtlsdr
> that allows manual control of the VGA, LNA, Mixer Gains) and added a
> Debian Package Generator.
>
> https://github.com/racerxdl/librtlsdr
>
> I just don't know how relevante is Debian Package Generator (also it
> is sort of incomplete).
>
> Should I make a PR to the oficial github with the changes of the VLM
> Gains? Here is the commit:
>
> https://github.com/racerxdl/librtlsdr/commit/25d0e8e6737b93b3564ad04d0fd2cd5e91cefa8b
>
>
> It is very helpfull for me to get NOAA APT Signals adjusting manually
> each gain.
>
> Regards,
>
> Lucas
>
> PS: Sorry Henk, I sent only to you.
>
> Em 29/02/2016 14:34, Henk escreveu:
>> Oeps, sorry forgot to quote the original post of joseph.
>>
>> +1
>> Hmm in my opinion rtl_sdr is the next best thing since the invention
>> of canned beer :) since it liberated the airwaves for allot of users.
>>
>> Regards,
>> henk
>>
>> On Sun, Feb 28, 2016 at 7:11 PM, Joseph Poirier <jdpoirier at gmail.com>
>> wrote:
>>> If would be nice to have a newer official release available;
>>> installation
>>> using the package manager on many Linux distros gets a two year old
>>> librtlsdr that's missing the rtlsdr_set_tuner_bandwidth function (added
>>> about nine months ago), as well as, other nice updates and fixes.
>>>
>>> cheers,
>>> joe
>



From lucas at teske.net.br  Wed Mar  2 23:40:46 2016
From: lucas at teske.net.br (Lucas Teske)
Date: Wed, 2 Mar 2016 20:40:46 -0300
Subject: post a new release
In-Reply-To: <56D71F28.1020500@gmail.com>
References: <CAOonV0rDm9z1Vd5ZVBjF==qV3XCC3Ven_TPPPLLhac1cTdnn3g@mail.gmail.com>
 <CAMFK4TMEziWDo=XO6uU0CEMy+E62iPSGh+pTiAaJZm1WDByxhg@mail.gmail.com>
 <CAMFK4TPL=RT_ecP60prBaDZMT_YCc27CNBeJ5ZdzNoOpfjR8VA@mail.gmail.com>
 <56D6435F.5090406@teske.net.br> <56D71F28.1020500@gmail.com>
Message-ID: <56D779FE.8050703@teske.net.br>

Why do you think that it will not happen soon?

I would love to check all of these ports and make some tests testing the 
implementations of each one for the cases I can test.

Also I will take a look on your fork as well. I was going to modify gqrx 
to support this new library, and then I notice that it does not use it. 
It uses the old osmocom plugin. I'm thinking how to proceed with that. I 
would love to have a Graphical Interface like SDR# but OSS and fully 
cross-platform.

Lucas

Em 02/03/2016 14:13, Alexander Kurpiers escreveu:
> I agree that the official code lacks proper manual gain control - but I
> would still prefer some nice presets. Being able to adjust the internal
> gain controls of the tuner chips to me is a bonus (as you really need to
> know what you are doing).
>
> As many others, I've started my fork (current version
> https://github.com/dl8aau/librtlsdr/tree/devel1), which among other
> things includes manual gain settings optimized for E4000 and R820T
> (optimization done by Leif Asbrink for Linrad). Something like this is
> badly needed for applications that cannot use the automatic gain control.
>
> There are many other forks with interesting features and there seems
> lots of duplicate work... I would love to see these merged back into the
> official release, but I actually do not believe this is going to happen
> any time soon.
>
> Regards,
>
> Alexander
>
>
> On 03/02/2016 02:35 AM, Lucas Teske wrote:
>> Btw, I made some changes (I merged some changes from a fork of rtlsdr
>> that allows manual control of the VGA, LNA, Mixer Gains) and added a
>> Debian Package Generator.
>>
>> https://github.com/racerxdl/librtlsdr
>>
>> I just don't know how relevante is Debian Package Generator (also it
>> is sort of incomplete).
>>
>> Should I make a PR to the oficial github with the changes of the VLM
>> Gains? Here is the commit:
>>
>> https://github.com/racerxdl/librtlsdr/commit/25d0e8e6737b93b3564ad04d0fd2cd5e91cefa8b
>>
>>
>> It is very helpfull for me to get NOAA APT Signals adjusting manually
>> each gain.
>>
>> Regards,
>>
>> Lucas
>>
>> PS: Sorry Henk, I sent only to you.
>>
>> Em 29/02/2016 14:34, Henk escreveu:
>>> Oeps, sorry forgot to quote the original post of joseph.
>>>
>>> +1
>>> Hmm in my opinion rtl_sdr is the next best thing since the invention
>>> of canned beer :) since it liberated the airwaves for allot of users.
>>>
>>> Regards,
>>> henk
>>>
>>> On Sun, Feb 28, 2016 at 7:11 PM, Joseph Poirier <jdpoirier at gmail.com>
>>> wrote:
>>>> If would be nice to have a newer official release available;
>>>> installation
>>>> using the package manager on many Linux distros gets a two year old
>>>> librtlsdr that's missing the rtlsdr_set_tuner_bandwidth function (added
>>>> about nine months ago), as well as, other nice updates and fixes.
>>>>
>>>> cheers,
>>>> joe



From jean-paul.lefevre at cea.fr  Thu Mar  3 12:17:21 2016
From: jean-paul.lefevre at cea.fr (=?UTF-8?Q?Jean-Paul_Le_F=c3=a8vre?=)
Date: Thu, 3 Mar 2016 13:17:21 +0100
Subject: AirSpy & sdr tools ?
Message-ID: <56D82B51.9020502@cea.fr>


Hi,

After having played with a DX-Patrol device for a while using the sdr 
tools (sdr_tcp, sdr_fm, etc.) I've purchased an AirSpy and I would like 
to experiment with it.

However reading the GrOsmoSDR page I see that AirSpy is supposed to be 
supported by the gr-osmosdr library but on the other hand the wiki page 
rtl-sdr does not mention it.

I've recompiled the file librtlsdr.c after having added the id product 
and vendor of the AirSpy in the code.

But I figure out that it is not sufficient and even maybe that it does 
not make sense.

Is there a way to make the sdr tool set (sdr_*) compatible with the AirSpy ?


-- 
Jean-Paul Le F?vre - CEA Saclay Irfu
Svom Scientific Ground Segment project manager


From martin_z_smith at yahoo.ie  Fri Mar  4 18:07:02 2016
From: martin_z_smith at yahoo.ie (Martin Smith)
Date: Fri, 4 Mar 2016 18:07:02 +0000
Subject: AirSpy & sdr tools ?
In-Reply-To: <56D82B51.9020502@cea.fr>
References: <56D82B51.9020502@cea.fr>
Message-ID: <56D9CEC6.3070503@yahoo.ie>

Wrong mailing list ?
https://uk.groups.yahoo.com/neo/groups/airspy/info

On 03/03/2016 12:17, Jean-Paul Le F?vre wrote:
>
> Hi,
>
> After having played with a DX-Patrol device for a while using the sdr
> tools (sdr_tcp, sdr_fm, etc.) I've purchased an AirSpy and I would
> like to experiment with it.
>
> However reading the GrOsmoSDR page I see that AirSpy is supposed to be
> supported by the gr-osmosdr library but on the other hand the wiki
> page rtl-sdr does not mention it.
>
> I've recompiled the file librtlsdr.c after having added the id product
> and vendor of the AirSpy in the code.
>
> But I figure out that it is not sufficient and even maybe that it does
> not make sense.
>
> Is there a way to make the sdr tool set (sdr_*) compatible with the
> AirSpy ?
>
>




From patrick at wirklich.priv.at  Fri Mar  4 18:58:23 2016
From: patrick at wirklich.priv.at (Patrick Strasser)
Date: Fri, 4 Mar 2016 19:58:23 +0100
Subject: post a new release
In-Reply-To: <56D71F28.1020500@gmail.com>
References: <CAOonV0rDm9z1Vd5ZVBjF==qV3XCC3Ven_TPPPLLhac1cTdnn3g@mail.gmail.com>
 <CAMFK4TMEziWDo=XO6uU0CEMy+E62iPSGh+pTiAaJZm1WDByxhg@mail.gmail.com>
 <CAMFK4TPL=RT_ecP60prBaDZMT_YCc27CNBeJ5ZdzNoOpfjR8VA@mail.gmail.com>
 <56D6435F.5090406@teske.net.br> <56D71F28.1020500@gmail.com>
Message-ID: <nbclsf$gkd$1@ger.gmane.org>

Hello!

To introduce myself, I'm using librtlsdr with rtl_433, a stick with
RT820T tuner, and want to have enhanced control of gain settings in the
official librtlsdr branch. I found gazillion of forks, but nothing that
comes with my favourite distribution.

Alexander Kurpiers 2016-03-02 18:13:
> I agree that the official code lacks proper manual gain control - but I would still prefer some nice presets. Being able to adjust the internal gain controls of the tuner chips to me is a bonus (as you really need to know what you are doing).
> 
> As many others, I've started my fork (current version
> https://github.com/dl8aau/librtlsdr/tree/devel1),


There are hundreds of forks! This is growing wildly. It's bad that all
this efforts are not bundled to improve librtlsdr.

> which among other
> things includes manual gain settings optimized for E4000 and R820T
> (optimization done by Leif Asbrink for Linrad). Something like this is
> badly needed for applications that cannot use the automatic gain control.

Would'nt it be possible to read the settings from various sources like
environment, $HOME/.config/librtlsdr.rc or /etc/librtlsdr.rc? Then noone
needs to fork and fiddle any more only to get special settings.

I reccommend Semantic Versioning [1]:

> Given a version number MAJOR.MINOR.PATCH, increment the:
> MAJOR version when you make incompatible API changes,
> MINOR version when you add functionality in a backwards-compatible manner, and
> PATCH version when you make backwards-compatible bug fixes.
> 
> Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.


librtlsdr is stable and in use, it could be released as 1.0.0. With
compatible changes, the existing apps could be using 1.x along with new
features like extended device support, extended settings with sane
(maybe improved) defaults, a out-of-api configuration, maybe autoranging
of settings, extended tuning, etc.

Regards

Patrick


[1] semver.org
-- 
Engineers motto: cheap, good, fast - choose any two
One of the lucky 10.000: http://xkcd.com/1053
Use Mail Encryption Today! PGP Key ID: 0xDF8A127E5A120903
Patrick Strasser <patrick at wirklich.priv.at>



From jdpoirier at gmail.com  Sat Mar  5 17:47:37 2016
From: jdpoirier at gmail.com (Joseph Poirier)
Date: Sat, 5 Mar 2016 11:47:37 -0600
Subject: post a new release
In-Reply-To: <22229.11656.562788.73052@airborne.nrl.navy.mil>
References: <CAOonV0rDm9z1Vd5ZVBjF==qV3XCC3Ven_TPPPLLhac1cTdnn3g@mail.gmail.com>
 <CAMFK4TMEziWDo=XO6uU0CEMy+E62iPSGh+pTiAaJZm1WDByxhg@mail.gmail.com>
 <CAMFK4TPL=RT_ecP60prBaDZMT_YCc27CNBeJ5ZdzNoOpfjR8VA@mail.gmail.com>
 <22229.11656.562788.73052@airborne.nrl.navy.mil>
Message-ID: <CAOonV0p9APQgG6vHG--MMNe99os8iVEoUj+ykzO9LswAN7jmpA@mail.gmail.com>

fyi - I just created a librtlsdr organization on github (
github.com/librtlsdr) and cloned https://github.com/steve-m/librtlsdr to
it.

It would be nice to aggregate a list of the most interesting forks and
attempt to merge some of the features and/or fixes in, and possibly get
this fork tagged as the canonical fork for packages, users, etc. If we can
get some sort of a majority approval that is.

I'll be more than happy to add permissions for people and/or pass it off to
someone that might have more time than myself to manage.

cheers,
joe

On Mon, Feb 29, 2016 at 11:50 PM, A. Maitland Bottoms <bottoms at debian.org>
wrote:

> Henk writes:
>  > Oeps, sorry forgot to quote the original post of joseph.
>  >
>  > +1
>  > Hmm in my opinion rtl_sdr is the next best thing since the invention
>  > of canned beer :) since it liberated the airwaves for allot of users.
>  >
>  > Regards,
>  > henk
>  >
>  > On Sun, Feb 28, 2016 at 7:11 PM, Joseph Poirier <jdpoirier at gmail.com>
> wrote:
>  > > If would be nice to have a newer official release available;
> installation
>  > > using the package manager on many Linux distros gets a two year old
>  > > librtlsdr that's missing the rtlsdr_set_tuner_bandwidth function
> (added
>  > > about nine months ago), as well as, other nice updates and fixes.
>  > >
>  > > cheers,
>  > > joe
>
> Oh yes, Debian Jessie did not release with rtlsdr bandwidth setting code.
> But, the rtl-sdr currently available in Debian unstable, testing and
> jessie-backports include current git HEAD code - v0.5.3-12-ge3c03f7.
> (based upon git://git.osmocom.org/rtl-sdr.git)
>
> So, while the Debian source package starts from the v0.5.3 tag, I use
> the 3.0 (quilt) source format to also include more recent git commits.
> https://sources.debian.net/src/rtl-sdr/0.5.3-5/debian/patches/
>
> Ubuntu Wily Werewolf and Xenial Xerus also contain rtl-sdr based on
> v0.5.3-12-ge3c03f7.
>
> A release would be good. I'd be happy to reduce the amount of stuff
> in the debian/ packaging directory - the various man pages could
> be adopted upstream, as well as the improve-librtlsdr-pc-file and
> improve-scanning-range-parsing patches.
>
> And a gpg signed tarball release, or even just a gpg signed tag
> would be a help in establishing source code integrity. A new release
> for osmocom might indeed help synchronize the various distributions.
>
> Thanks for keeping me informed,
> -Maitland
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20160305/71636827/attachment.htm>

From lucas at teske.net.br  Sat Mar  5 18:59:03 2016
From: lucas at teske.net.br (Lucas Teske)
Date: Sat, 5 Mar 2016 15:59:03 -0300
Subject: post a new release
In-Reply-To: <CAOonV0p9APQgG6vHG--MMNe99os8iVEoUj+ykzO9LswAN7jmpA@mail.gmail.com>
References: <CAOonV0rDm9z1Vd5ZVBjF==qV3XCC3Ven_TPPPLLhac1cTdnn3g@mail.gmail.com>
 <CAMFK4TMEziWDo=XO6uU0CEMy+E62iPSGh+pTiAaJZm1WDByxhg@mail.gmail.com>
 <CAMFK4TPL=RT_ecP60prBaDZMT_YCc27CNBeJ5ZdzNoOpfjR8VA@mail.gmail.com>
 <22229.11656.562788.73052@airborne.nrl.navy.mil>
 <CAOonV0p9APQgG6vHG--MMNe99os8iVEoUj+ykzO9LswAN7jmpA@mail.gmail.com>
Message-ID: <56DB2C77.6030005@teske.net.br>

Sure! That is good! :D

If you can add me, I will in a few hours have some free time to merge my 
fork changes into it.

Also anyone that have a working fork please send the link to the repos 
so I can check it.

On 05/03/2016 14:47, Joseph Poirier wrote:
> fyi - I just created a librtlsdr organization on github 
> (github.com/librtlsdr <http://github.com/librtlsdr>) and cloned 
> https://github.com/steve-m/librtlsdr to it.
>
> It would be nice to aggregate a list of the most interesting forks and 
> attempt to merge some of the features and/or fixes in, and possibly 
> get this fork tagged as the canonical fork for packages, users, etc. 
> If we can get some sort of a majority approval that is.
>
> I'll be more than happy to add permissions for people and/or pass it 
> off to someone that might have more time than myself to manage.
>
> cheers,
> joe
>
> On Mon, Feb 29, 2016 at 11:50 PM, A. Maitland Bottoms 
> <bottoms at debian.org <mailto:bottoms at debian.org>> wrote:
>
>     Henk writes:
>      > Oeps, sorry forgot to quote the original post of joseph.
>      >
>      > +1
>      > Hmm in my opinion rtl_sdr is the next best thing since the
>     invention
>      > of canned beer :) since it liberated the airwaves for allot of
>     users.
>      >
>      > Regards,
>      > henk
>      >
>      > On Sun, Feb 28, 2016 at 7:11 PM, Joseph Poirier
>     <jdpoirier at gmail.com <mailto:jdpoirier at gmail.com>> wrote:
>      > > If would be nice to have a newer official release available;
>     installation
>      > > using the package manager on many Linux distros gets a two
>     year old
>      > > librtlsdr that's missing the rtlsdr_set_tuner_bandwidth
>     function (added
>      > > about nine months ago), as well as, other nice updates and fixes.
>      > >
>      > > cheers,
>      > > joe
>
>     Oh yes, Debian Jessie did not release with rtlsdr bandwidth
>     setting code.
>     But, the rtl-sdr currently available in Debian unstable, testing and
>     jessie-backports include current git HEAD code - v0.5.3-12-ge3c03f7.
>     (based upon git://git.osmocom.org/rtl-sdr.git
>     <http://git.osmocom.org/rtl-sdr.git>)
>
>     So, while the Debian source package starts from the v0.5.3 tag, I use
>     the 3.0 (quilt) source format to also include more recent git commits.
>     https://sources.debian.net/src/rtl-sdr/0.5.3-5/debian/patches/
>
>     Ubuntu Wily Werewolf and Xenial Xerus also contain rtl-sdr based on
>     v0.5.3-12-ge3c03f7.
>
>     A release would be good. I'd be happy to reduce the amount of stuff
>     in the debian/ packaging directory - the various man pages could
>     be adopted upstream, as well as the improve-librtlsdr-pc-file and
>     improve-scanning-range-parsing patches.
>
>     And a gpg signed tarball release, or even just a gpg signed tag
>     would be a help in establishing source code integrity. A new release
>     for osmocom might indeed help synchronize the various distributions.
>
>     Thanks for keeping me informed,
>     -Maitland
>
>

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

From lucas at teske.net.br  Sun Mar  6 02:25:28 2016
From: lucas at teske.net.br (Lucas Teske)
Date: Sat, 5 Mar 2016 23:25:28 -0300
Subject: post a new release
In-Reply-To: <56DB2C77.6030005@teske.net.br>
References: <CAOonV0rDm9z1Vd5ZVBjF==qV3XCC3Ven_TPPPLLhac1cTdnn3g@mail.gmail.com>
 <CAMFK4TMEziWDo=XO6uU0CEMy+E62iPSGh+pTiAaJZm1WDByxhg@mail.gmail.com>
 <CAMFK4TPL=RT_ecP60prBaDZMT_YCc27CNBeJ5ZdzNoOpfjR8VA@mail.gmail.com>
 <22229.11656.562788.73052@airborne.nrl.navy.mil>
 <CAOonV0p9APQgG6vHG--MMNe99os8iVEoUj+ykzO9LswAN7jmpA@mail.gmail.com>
 <56DB2C77.6030005@teske.net.br>
Message-ID: <56DB9518.6010200@teske.net.br>

Ok so I merged some forks into mine. I'll wait for Joseph to add me as a 
librtlsdr organization member to merge it with the organization repo.

https://github.com/racerxdl/librtlsdr

So basically I added the SDR# manual gains change to the librtlsdr ( 
from https://sourceforge.net/projects/sdrr820tmanualgainsettings/ )
Then I merged Hayati changes to the DC Filter from 
https://github.com/hayguen/librtlsdr

I am taking a look into Alexander Kurpiers changes ( 
https://github.com/dl8aau/librtlsdr/tree/devel1 ) before merging because 
he did a lot more commits and also he also added the Manual Gains to the 
code. So I will take a look and test both codes.

Lucas

Em 05/03/2016 15:59, Lucas Teske escreveu:
> Sure! That is good! :D
>
> If you can add me, I will in a few hours have some free time to merge 
> my fork changes into it.
>
> Also anyone that have a working fork please send the link to the repos 
> so I can check it.
>
> On 05/03/2016 14:47, Joseph Poirier wrote:
>> fyi - I just created a librtlsdr organization on github 
>> (github.com/librtlsdr <http://github.com/librtlsdr>) and cloned 
>> https://github.com/steve-m/librtlsdr to it.
>>
>> It would be nice to aggregate a list of the most interesting forks 
>> and attempt to merge some of the features and/or fixes in, and 
>> possibly get this fork tagged as the canonical fork for packages, 
>> users, etc. If we can get some sort of a majority approval that is.
>>
>> I'll be more than happy to add permissions for people and/or pass it 
>> off to someone that might have more time than myself to manage.
>>
>> cheers,
>> joe
>>
>> On Mon, Feb 29, 2016 at 11:50 PM, A. Maitland Bottoms 
>> <bottoms at debian.org> wrote:
>>
>>     Henk writes:
>>      > Oeps, sorry forgot to quote the original post of joseph.
>>      >
>>      > +1
>>      > Hmm in my opinion rtl_sdr is the next best thing since the
>>     invention
>>      > of canned beer :) since it liberated the airwaves for allot of
>>     users.
>>      >
>>      > Regards,
>>      > henk
>>      >
>>      > On Sun, Feb 28, 2016 at 7:11 PM, Joseph Poirier
>>     <jdpoirier at gmail.com <mailto:jdpoirier at gmail.com>> wrote:
>>      > > If would be nice to have a newer official release available;
>>     installation
>>      > > using the package manager on many Linux distros gets a two
>>     year old
>>      > > librtlsdr that's missing the rtlsdr_set_tuner_bandwidth
>>     function (added
>>      > > about nine months ago), as well as, other nice updates and
>>     fixes.
>>      > >
>>      > > cheers,
>>      > > joe
>>
>>     Oh yes, Debian Jessie did not release with rtlsdr bandwidth
>>     setting code.
>>     But, the rtl-sdr currently available in Debian unstable, testing and
>>     jessie-backports include current git HEAD code - v0.5.3-12-ge3c03f7.
>>     (based upon git://git.osmocom.org/rtl-sdr.git
>>     <http://git.osmocom.org/rtl-sdr.git>)
>>
>>     So, while the Debian source package starts from the v0.5.3 tag, I use
>>     the 3.0 (quilt) source format to also include more recent git
>>     commits.
>>     https://sources.debian.net/src/rtl-sdr/0.5.3-5/debian/patches/
>>
>>     Ubuntu Wily Werewolf and Xenial Xerus also contain rtl-sdr based on
>>     v0.5.3-12-ge3c03f7.
>>
>>     A release would be good. I'd be happy to reduce the amount of stuff
>>     in the debian/ packaging directory - the various man pages could
>>     be adopted upstream, as well as the improve-librtlsdr-pc-file and
>>     improve-scanning-range-parsing patches.
>>
>>     And a gpg signed tarball release, or even just a gpg signed tag
>>     would be a help in establishing source code integrity. A new release
>>     for osmocom might indeed help synchronize the various distributions.
>>
>>     Thanks for keeping me informed,
>>     -Maitland
>>
>>
>

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

From lucas at teske.net.br  Sun Mar  6 04:30:27 2016
From: lucas at teske.net.br (Lucas Teske)
Date: Sun, 6 Mar 2016 01:30:27 -0300
Subject: post a new release
In-Reply-To: <56DB9518.6010200@teske.net.br>
References: <CAOonV0rDm9z1Vd5ZVBjF==qV3XCC3Ven_TPPPLLhac1cTdnn3g@mail.gmail.com>
 <CAMFK4TMEziWDo=XO6uU0CEMy+E62iPSGh+pTiAaJZm1WDByxhg@mail.gmail.com>
 <CAMFK4TPL=RT_ecP60prBaDZMT_YCc27CNBeJ5ZdzNoOpfjR8VA@mail.gmail.com>
 <22229.11656.562788.73052@airborne.nrl.navy.mil>
 <CAOonV0p9APQgG6vHG--MMNe99os8iVEoUj+ykzO9LswAN7jmpA@mail.gmail.com>
 <56DB2C77.6030005@teske.net.br> <56DB9518.6010200@teske.net.br>
Message-ID: <56DBB263.3020301@teske.net.br>

Ok so I had some spare time now and I decided to add the Bandwidth 
parameters to rtl_tcp and rtl_fm, since they are very usefull to reduce 
out-of-band noises. I made a Pull Request from my BWChanges Branch to 
the Development Branch. If anyone is available to review my Pull 
Request, it is here:

https://github.com/librtlsdr/librtlsdr/pull/1

I hope it helps :D

Lucas

Em 05/03/2016 23:25, Lucas Teske escreveu:
> Ok so I merged some forks into mine. I'll wait for Joseph to add me as 
> a librtlsdr organization member to merge it with the organization repo.
>
> https://github.com/racerxdl/librtlsdr
>
> So basically I added the SDR# manual gains change to the librtlsdr ( 
> from https://sourceforge.net/projects/sdrr820tmanualgainsettings/ )
> Then I merged Hayati changes to the DC Filter from 
> https://github.com/hayguen/librtlsdr
>
> I am taking a look into Alexander Kurpiers changes ( 
> https://github.com/dl8aau/librtlsdr/tree/devel1 ) before merging 
> because he did a lot more commits and also he also added the Manual 
> Gains to the code. So I will take a look and test both codes.
>
> Lucas
>
> Em 05/03/2016 15:59, Lucas Teske escreveu:
>> Sure! That is good! :D
>>
>> If you can add me, I will in a few hours have some free time to merge 
>> my fork changes into it.
>>
>> Also anyone that have a working fork please send the link to the 
>> repos so I can check it.
>>
>> On 05/03/2016 14:47, Joseph Poirier wrote:
>>> fyi - I just created a librtlsdr organization on github 
>>> (github.com/librtlsdr <http://github.com/librtlsdr>) and cloned 
>>> https://github.com/steve-m/librtlsdr to it.
>>>
>>> It would be nice to aggregate a list of the most interesting forks 
>>> and attempt to merge some of the features and/or fixes in, and 
>>> possibly get this fork tagged as the canonical fork for packages, 
>>> users, etc. If we can get some sort of a majority approval that is.
>>>
>>> I'll be more than happy to add permissions for people and/or pass it 
>>> off to someone that might have more time than myself to manage.
>>>
>>> cheers,
>>> joe
>>>
>>> On Mon, Feb 29, 2016 at 11:50 PM, A. Maitland Bottoms 
>>> <bottoms at debian.org> wrote:
>>>
>>>     Henk writes:
>>>      > Oeps, sorry forgot to quote the original post of joseph.
>>>      >
>>>      > +1
>>>      > Hmm in my opinion rtl_sdr is the next best thing since the
>>>     invention
>>>      > of canned beer :) since it liberated the airwaves for allot
>>>     of users.
>>>      >
>>>      > Regards,
>>>      > henk
>>>      >
>>>      > On Sun, Feb 28, 2016 at 7:11 PM, Joseph Poirier
>>>     <jdpoirier at gmail.com <mailto:jdpoirier at gmail.com>> wrote:
>>>      > > If would be nice to have a newer official release
>>>     available; installation
>>>      > > using the package manager on many Linux distros gets a two
>>>     year old
>>>      > > librtlsdr that's missing the rtlsdr_set_tuner_bandwidth
>>>     function (added
>>>      > > about nine months ago), as well as, other nice updates and
>>>     fixes.
>>>      > >
>>>      > > cheers,
>>>      > > joe
>>>
>>>     Oh yes, Debian Jessie did not release with rtlsdr bandwidth
>>>     setting code.
>>>     But, the rtl-sdr currently available in Debian unstable, testing and
>>>     jessie-backports include current git HEAD code - v0.5.3-12-ge3c03f7.
>>>     (based upon git://git.osmocom.org/rtl-sdr.git
>>>     <http://git.osmocom.org/rtl-sdr.git>)
>>>
>>>     So, while the Debian source package starts from the v0.5.3 tag,
>>>     I use
>>>     the 3.0 (quilt) source format to also include more recent git
>>>     commits.
>>>     https://sources.debian.net/src/rtl-sdr/0.5.3-5/debian/patches/
>>>
>>>     Ubuntu Wily Werewolf and Xenial Xerus also contain rtl-sdr based on
>>>     v0.5.3-12-ge3c03f7.
>>>
>>>     A release would be good. I'd be happy to reduce the amount of stuff
>>>     in the debian/ packaging directory - the various man pages could
>>>     be adopted upstream, as well as the improve-librtlsdr-pc-file and
>>>     improve-scanning-range-parsing patches.
>>>
>>>     And a gpg signed tarball release, or even just a gpg signed tag
>>>     would be a help in establishing source code integrity. A new release
>>>     for osmocom might indeed help synchronize the various distributions.
>>>
>>>     Thanks for keeping me informed,
>>>     -Maitland
>>>
>>>
>>
>

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

From holger at freyther.de  Fri Mar 18 19:59:26 2016
From: holger at freyther.de (Holger Freyther)
Date: Fri, 18 Mar 2016 20:59:26 +0100
Subject: Time to rename projects.osmocom.org to osmocom.org
Message-ID: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>

Hi,

I think we all liked tnt's proposal to just call it osmocom.org. Are we ready to make the redmine available as osmocom.org (and redirect www.osmocom.org, projects.osmocom.org to it)?

As first step of redirects I propose:

http://bb.osmocom.org/		-> http://osmocom.org/projects/baseband
http://openbsc.osmocom.org/	-> http://osmocom.org/projects/openbsc
http://tetra.osmocom.org/	-> http://osmocom.org/projects/tetra
http://simtrace.osmocom.org/	-> http://osmocom.org/projects/simtrace
http://security.osmocom.org/	-> http://osmocom.org/projects/security
http://gmr.osmocom.org/		-> http://osmocom.org/projects/gmr
http://sdr.osmocom.org/		-> http://osmocom.org/projects/sdr

any objections or corrections to that?


kind regards
	holger

From suraev at alumni.ntnu.no  Fri Mar 18 21:51:10 2016
From: suraev at alumni.ntnu.no (=?UTF-8?B?TWF4ICjimK0p?=)
Date: Fri, 18 Mar 2016 22:51:10 +0100
Subject: Time to rename projects.osmocom.org to osmocom.org
In-Reply-To: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>
References: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>
Message-ID: <56EC784E.8010803@alumni.ntnu.no>

Why not just omit the word "projects" -> http://osmocom.org/baseband - lesser to type :)

18.03.2016 20:59, Holger Freyther ?????:
> Hi,
> 
> I think we all liked tnt's proposal to just call it osmocom.org. Are we ready to make the redmine available as osmocom.org (and redirect www.osmocom.org, projects.osmocom.org to it)?
> 
> As first step of redirects I propose:
> 
> http://bb.osmocom.org/		-> http://osmocom.org/projects/baseband
> http://openbsc.osmocom.org/	-> http://osmocom.org/projects/openbsc
> http://tetra.osmocom.org/	-> http://osmocom.org/projects/tetra
> http://simtrace.osmocom.org/	-> http://osmocom.org/projects/simtrace
> http://security.osmocom.org/	-> http://osmocom.org/projects/security
> http://gmr.osmocom.org/		-> http://osmocom.org/projects/gmr
> http://sdr.osmocom.org/		-> http://osmocom.org/projects/sdr
> 
> any objections or corrections to that?
> 
> 
> kind regards
> 	holger
> 



From laforge at gnumonks.org  Mon Mar 21 06:53:08 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 21 Mar 2016 07:53:08 +0100
Subject: Time to rename projects.osmocom.org to osmocom.org
In-Reply-To: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>
References: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>
Message-ID: <20160321065308.GD10371@nataraja>

Hi Holger,

On Fri, Mar 18, 2016 at 08:59:26PM +0100, Holger Freyther wrote:
> I think we all liked tnt's proposal to just call it osmocom.org. Are
> we ready to make the redmine available as osmocom.org (and redirect
> www.osmocom.org, projects.osmocom.org to it)?

yes, and also yes for the redirects.

> any objections or corrections to that?

none, please go ahead.  Thanks a lot!

I wonder if it is worth to make the old wiki/issue trac databases
(without the user password hashes!) publicly available, in case somebody
has a need for old content.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From holger at freyther.de  Sun Mar 27 13:35:25 2016
From: holger at freyther.de (Holger Freyther)
Date: Sun, 27 Mar 2016 15:35:25 +0200
Subject: Time to rename projects.osmocom.org to osmocom.org
In-Reply-To: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>
References: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>
Message-ID: <79493EC9-B340-4207-8CF3-1AA4EBFE4373@freyther.de>


> On 18 Mar 2016, at 20:59, Holger Freyther <holger at freyther.de> wrote:
> 
> Hi,
> 

> any objections or corrections to that?

this is now in place and the old domains are now using X509 certs of letsencrypt.

holger

From 246tnt at gmail.com  Sun Mar 27 14:30:31 2016
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sun, 27 Mar 2016 16:30:31 +0200
Subject: Time to rename projects.osmocom.org to osmocom.org
In-Reply-To: <79493EC9-B340-4207-8CF3-1AA4EBFE4373@freyther.de>
References: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>
 <79493EC9-B340-4207-8CF3-1AA4EBFE4373@freyther.de>
Message-ID: <CAHL+j0_rP_OL=dEMmkVdcUQNQjhhV6GL9Ycxj0LWhQaS7jv-Nw@mail.gmail.com>

> this is now in place and the old domains are now using X509 certs of letsencrypt.

Do you know if redmine supports going to HTTPS only (i.e. redir http
to https). I changed the "protocol" to HTTPS in the admin panel but
that had no effect afaict.

I would prefer to be HTTPS only and also have the session cookie have
the "Secure" flag (so they're never sent over plain HTTP)

Cheers,

   Sylvain


From holger at freyther.de  Sun Mar 27 16:40:33 2016
From: holger at freyther.de (Holger Freyther)
Date: Sun, 27 Mar 2016 18:40:33 +0200
Subject: Time to rename projects.osmocom.org to osmocom.org
In-Reply-To: <CAHL+j0_rP_OL=dEMmkVdcUQNQjhhV6GL9Ycxj0LWhQaS7jv-Nw@mail.gmail.com>
References: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>
 <79493EC9-B340-4207-8CF3-1AA4EBFE4373@freyther.de>
 <CAHL+j0_rP_OL=dEMmkVdcUQNQjhhV6GL9Ycxj0LWhQaS7jv-Nw@mail.gmail.com>
Message-ID: <7F92EBB5-3188-4E81-854C-B9DF70DBD64D@freyther.de>


> On 27 Mar 2016, at 16:30, Sylvain Munaut <246tnt at gmail.com> wrote:
> 
>> this is now in place and the old domains are now using X509 certs of letsencrypt.
> 
> Do you know if redmine supports going to HTTPS only (i.e. redir http
> to https). I changed the "protocol" to HTTPS in the admin panel but
> that had no effect afaict.

I don't know.


> I would prefer to be HTTPS only and also have the session cookie have
> the "Secure" flag (so they're never sent over plain HTTP)

I added:
	proxy_set_header X-Forwarded-Ssl on;


to the nginx config in the hope that redmine makes use of that instead of the X-Forwarded-Proto. If it matters to you deeply we can make a general http -> https redirect.


holger

From holger at freyther.de  Sun Mar 27 16:46:40 2016
From: holger at freyther.de (Holger Freyther)
Date: Sun, 27 Mar 2016 18:46:40 +0200
Subject: Time to rename projects.osmocom.org to osmocom.org
In-Reply-To: <7F92EBB5-3188-4E81-854C-B9DF70DBD64D@freyther.de>
References: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>
 <79493EC9-B340-4207-8CF3-1AA4EBFE4373@freyther.de>
 <CAHL+j0_rP_OL=dEMmkVdcUQNQjhhV6GL9Ycxj0LWhQaS7jv-Nw@mail.gmail.com>
 <7F92EBB5-3188-4E81-854C-B9DF70DBD64D@freyther.de>
Message-ID: <24432F59-2C05-4B90-8EF1-72048E9CEEB0@freyther.de>


> On 27 Mar 2016, at 18:40, Holger Freyther <holger at freyther.de> wrote:
> 
> 
> 
> to the nginx config in the hope that redmine makes use of that instead of the X-Forwarded-Proto. If it matters to you deeply we can make a general http -> https redirect.
> 

ah lol... http://www.redmine.org/projects/redmine/wiki/RedmineSettings#Protocol says it is for http vs. https in email notifications. :}

From laforge at gnumonks.org  Mon Mar 28 08:03:57 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 28 Mar 2016 10:03:57 +0200
Subject: [notifications@github.com: [rtl-sdr] drop option -a and be
 independent from interface ip-address (#2)]
Message-ID: <20160328080357.GA27418@nataraja>

somebody sending pull requests to a mirror of the official repository...
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
An embedded message was scrubbed...
From: Hannes Schmelzer <notifications at github.com>
Subject: [rtl-sdr] drop option -a and be independent from interface ip-address (#2)
Date: Sun, 27 Mar 2016 14:43:26 -0700
Size: 5863
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20160328/3369da63/attachment.eml>

From laforge at gnumonks.org  Mon Mar 28 09:40:49 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 28 Mar 2016 11:40:49 +0200
Subject: [notifications@github.com: [rtl-sdr] drop option -a and be
 independent from interface ip-address (#2)]
In-Reply-To: <56F8EBFD.1070806@schmelzer.or.at>
References: <20160328080357.GA27418@nataraja>
 <56F8EBFD.1070806@schmelzer.or.at>
Message-ID: <20160328094049.GB27418@nataraja>

On Mon, Mar 28, 2016 at 10:31:57AM +0200, Hannes Schmelzer wrote:
> should i send some patch to this mailing list instead?

that would be the usual process, yes. Thanks.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From oe5hpm at oevsv.at  Mon Mar 28 20:00:44 2016
From: oe5hpm at oevsv.at (Hannes Petermaier)
Date: Mon, 28 Mar 2016 22:00:44 +0200
Subject: [PATCH] drop option -a and be independent from interface ip-address
Message-ID: <1459195244-22500-1-git-send-email-oe5hpm@oevsv.at>

From: Hannes Schmelzer <oe5hpm at oevsv.at>

It is very inconvenient to have some RTL-stick on a machine with
multiple network interfaces if it is bound to a specific one.

So we break up this and make this dynamically.

The -a option therefore is not needed any longer.

Signed-off-by: Hannes Schmelzer <oe5hpm at oevsv.at>
---
 src/rtl_tcp.c | 34 ++++++++++++++++++----------------
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/src/rtl_tcp.c b/src/rtl_tcp.c
index 317e0f3..39d7c3e 100644
--- a/src/rtl_tcp.c
+++ b/src/rtl_tcp.c
@@ -31,6 +31,7 @@
 #include <sys/socket.h>
 #include <sys/time.h>
 #include <netinet/in.h>
+#include <netdb.h>
 #include <fcntl.h>
 #else
 #include <winsock2.h>
@@ -365,10 +366,10 @@ static void *command_worker(void *arg)
 int main(int argc, char **argv)
 {
 	int r, opt, i;
-	char* addr = "127.0.0.1";
-	int port = 1234;
+	char* port = "1234";
 	uint32_t frequency = 100000000, samp_rate = 2048000;
-	struct sockaddr_in local, remote;
+	struct addrinfo hints, *res;
+	struct sockaddr_in remote;
 	uint32_t buf_num = 0;
 	int dev_index = 0;
 	int dev_given = 0;
@@ -391,7 +392,7 @@ int main(int argc, char **argv)
 	struct sigaction sigact, sigign;
 #endif
 
-	while ((opt = getopt(argc, argv, "a:p:f:g:s:b:n:d:P:")) != -1) {
+	while ((opt = getopt(argc, argv, "p:f:g:s:b:n:d:P:")) != -1) {
 		switch (opt) {
 		case 'd':
 			dev_index = verbose_device_search(optarg);
@@ -406,11 +407,8 @@ int main(int argc, char **argv)
 		case 's':
 			samp_rate = (uint32_t)atofs(optarg);
 			break;
-		case 'a':
-			addr = optarg;
-			break;
 		case 'p':
-			port = atoi(optarg);
+			port = optarg;
 			break;
 		case 'b':
 			buf_num = atoi(optarg);
@@ -502,16 +500,20 @@ int main(int argc, char **argv)
 	pthread_cond_init(&cond, NULL);
 	pthread_cond_init(&exit_cond, NULL);
 
-	memset(&local,0,sizeof(local));
-	local.sin_family = AF_INET;
-	local.sin_port = htons(port);
-	local.sin_addr.s_addr = inet_addr(addr);
+	memset(&hints, 0, sizeof(hints));
+	hints.ai_family = AF_INET;
+	hints.ai_socktype = SOCK_STREAM;
+	hints.ai_flags = AI_PASSIVE;    /* fill in my IP for me */
+	hints.ai_protocol = IPPROTO_TCP;
+	getaddrinfo(NULL, port, &hints, &res);
+
+	listensocket = socket(res->ai_family,
+			      res->ai_socktype, res->ai_protocol);
 
-	listensocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
 	r = 1;
 	setsockopt(listensocket, SOL_SOCKET, SO_REUSEADDR, (char *)&r, sizeof(int));
 	setsockopt(listensocket, SOL_SOCKET, SO_LINGER, (char *)&ling, sizeof(ling));
-	bind(listensocket,(struct sockaddr *)&local,sizeof(local));
+	bind(listensocket, res->ai_addr, res->ai_addrlen);
 
 #ifdef _WIN32
 	ioctlsocket(listensocket, FIONBIO, &blockmode);
@@ -522,11 +524,11 @@ int main(int argc, char **argv)
 
 	while(1) {
 		printf("listening...\n");
-		printf("Use the device argument 'rtl_tcp=%s:%d' in OsmoSDR "
+		printf("Use the device argument 'rtl_tcp=%s:%s' in OsmoSDR "
 		       "(gr-osmosdr) source\n"
 		       "to receive samples in GRC and control "
 		       "rtl_tcp parameters (frequency, gain, ...).\n",
-		       addr, port);
+		       "yourip", port);
 		listen(listensocket,1);
 
 		while(1) {
-- 
1.9.1



From 246tnt at gmail.com  Mon Mar 28 20:34:41 2016
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Mon, 28 Mar 2016 22:34:41 +0200
Subject: [PATCH] drop option -a and be independent from interface
 ip-address
In-Reply-To: <1459195244-22500-1-git-send-email-oe5hpm@oevsv.at>
References: <1459195244-22500-1-git-send-email-oe5hpm@oevsv.at>
Message-ID: <CAHL+j0_L9bAFc1N3WVv6F2K67F-OyDpDD568Us1vrQnOeq0K+w@mail.gmail.com>

On Mon, Mar 28, 2016 at 10:00 PM, Hannes Petermaier <oe5hpm at oevsv.at> wrote:
> From: Hannes Schmelzer <oe5hpm at oevsv.at>
>
> It is very inconvenient to have some RTL-stick on a machine with
> multiple network interfaces if it is bound to a specific one.
>
> So we break up this and make this dynamically.
>
> The -a option therefore is not needed any longer.

?!?

And what if you _want_ to bind it to a specific IP ?

If you have several interface and just listen to all, just use -a 0.0.0.0 ...

Cheers,

  Sylvain


From bottoms at debian.org  Tue Mar  1 05:50:07 2016
From: bottoms at debian.org (A. Maitland Bottoms)
Date: Tue, 01 Mar 2016 05:50:07 -0000
Subject: post a new release
In-Reply-To: <CAMFK4TPL=RT_ecP60prBaDZMT_YCc27CNBeJ5ZdzNoOpfjR8VA@mail.gmail.com>
References: <CAOonV0rDm9z1Vd5ZVBjF==qV3XCC3Ven_TPPPLLhac1cTdnn3g@mail.gmail.com>
 <CAMFK4TMEziWDo=XO6uU0CEMy+E62iPSGh+pTiAaJZm1WDByxhg@mail.gmail.com>
 <CAMFK4TPL=RT_ecP60prBaDZMT_YCc27CNBeJ5ZdzNoOpfjR8VA@mail.gmail.com>
Message-ID: <22229.11656.562788.73052@airborne.nrl.navy.mil>

Henk writes:
 > Oeps, sorry forgot to quote the original post of joseph.
 > 
 > +1
 > Hmm in my opinion rtl_sdr is the next best thing since the invention
 > of canned beer :) since it liberated the airwaves for allot of users.
 > 
 > Regards,
 > henk
 > 
 > On Sun, Feb 28, 2016 at 7:11 PM, Joseph Poirier <jdpoirier at gmail.com> wrote:
 > > If would be nice to have a newer official release available; installation
 > > using the package manager on many Linux distros gets a two year old
 > > librtlsdr that's missing the rtlsdr_set_tuner_bandwidth function (added
 > > about nine months ago), as well as, other nice updates and fixes.
 > >
 > > cheers,
 > > joe

Oh yes, Debian Jessie did not release with rtlsdr bandwidth setting code.
But, the rtl-sdr currently available in Debian unstable, testing and
jessie-backports include current git HEAD code - v0.5.3-12-ge3c03f7.
(based upon git://git.osmocom.org/rtl-sdr.git)

So, while the Debian source package starts from the v0.5.3 tag, I use
the 3.0 (quilt) source format to also include more recent git commits.
https://sources.debian.net/src/rtl-sdr/0.5.3-5/debian/patches/

Ubuntu Wily Werewolf and Xenial Xerus also contain rtl-sdr based on
v0.5.3-12-ge3c03f7.

A release would be good. I'd be happy to reduce the amount of stuff
in the debian/ packaging directory - the various man pages could
be adopted upstream, as well as the improve-librtlsdr-pc-file and
improve-scanning-range-parsing patches.

And a gpg signed tarball release, or even just a gpg signed tag
would be a help in establishing source code integrity. A new release
for osmocom might indeed help synchronize the various distributions.

Thanks for keeping me informed,
-Maitland


From domi at tomcsanyi.net  Mon Mar 21 08:31:19 2016
From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=)
Date: Mon, 21 Mar 2016 08:31:19 -0000
Subject: Time to rename projects.osmocom.org to osmocom.org
In-Reply-To: <20160321065308.GD10371@nataraja>
References: <F895AC1A-ADFE-4263-9591-159E7D4F2008@freyther.de>
 <20160321065308.GD10371@nataraja>
Message-ID: <C02D901B-73A0-41CB-9C07-A9FFF3F64E0D@tomcsanyi.net>

Hi Harald,

> I wonder if it is worth to make the old wiki/issue trac databases
> (without the user password hashes!) publicly available, in case somebody
> has a need for old content.

I think this would be great.

Thanks!

Domi Tomcsanyi


From f6gnj78 at gmail.com  Tue Mar 22 15:05:11 2016
From: f6gnj78 at gmail.com (a c)
Date: Tue, 22 Mar 2016 15:05:11 -0000
Subject: DC spike remove ???
Message-ID: <CANTNY2frYy-ckjnymPCCxkqeRPsCxyNuiyvRk8gp5S=KTjSwSQ@mail.gmail.com>

Hi,

 I just started experimenting with rtl-fm with a DVB-T stick and a
raspberry pi 2. It's really very simple to use but I currently have a
problem by setting a frequency in NBFM mode. When I slightly shifts
the frequency of the true frequency , it appears intermodulation with
DC spike even with the dc -E parameters and offset -E ???  The problem
does not exist with automatic gain. IQ balance dont work with a fixed
gain (ex -g 30) or i made mistake in my command line ??? Have you ever
encountered this problem?


Thanks,

Arnaud
F6GNJ


From hannes at schmelzer.or.at  Mon Mar 28 08:56:35 2016
From: hannes at schmelzer.or.at (Hannes Schmelzer)
Date: Mon, 28 Mar 2016 08:56:35 -0000
Subject: [notifications@github.com: [rtl-sdr] drop option -a and be
 independent from interface ip-address (#2)]
In-Reply-To: <20160328080357.GA27418@nataraja>
References: <20160328080357.GA27418@nataraja>
Message-ID: <56F8EBFD.1070806@schmelzer.or.at>

Hi,
should i send some patch to this mailing list instead?

best regards,
Hannes

On 03/28/2016 10:03 AM, Harald Welte wrote:
> somebody sending pull requests to a mirror of the official repository...



From hannes at schmelzer.or.at  Tue Mar 29 05:43:39 2016
From: hannes at schmelzer.or.at (Hannes Schmelzer)
Date: Tue, 29 Mar 2016 05:43:39 -0000
Subject: [PATCH] drop option -a and be independent from interface
 ip-address
In-Reply-To: <CAHL+j0_L9bAFc1N3WVv6F2K67F-OyDpDD568Us1vrQnOeq0K+w@mail.gmail.com>
References: <1459195244-22500-1-git-send-email-oe5hpm@oevsv.at>
 <CAHL+j0_L9bAFc1N3WVv6F2K67F-OyDpDD568Us1vrQnOeq0K+w@mail.gmail.com>
Message-ID: <56FA1602.3000104@schmelzer.or.at>



On 28.03.2016 22:34, Sylvain Munaut wrote:
> On Mon, Mar 28, 2016 at 10:00 PM, Hannes Petermaier <oe5hpm at oevsv.at> wrote:
>> From: Hannes Schmelzer <oe5hpm at oevsv.at>
>>
>> It is very inconvenient to have some RTL-stick on a machine with
>> multiple network interfaces if it is bound to a specific one.
>>
>> So we break up this and make this dynamically.
>>
>> The -a option therefore is not needed any longer.
> ?!?
>
> And what if you _want_ to bind it to a specific IP ?
okay, i dissapeared this point of view.
Of course we cannot drop this.
> If you have several interface and just listen to all, just use -a 0.0.0.0 ...
I remember having trouble in the past with this during another project, 
i think it was if there where two subnets on same physical interface 
(agree, that isn't a normal situation, but existing).
Problem was that ip-stack used as source address always the first e.g. 
the lower one defined on the interface, this doesn't happen with the 
passive flag.

I will double check this again and resend some V2.
> Cheers,
>
>    Sylvain
best regards,
Hannes


From f6gnj78 at gmail.com  Tue Mar 29 09:24:15 2016
From: f6gnj78 at gmail.com (a c)
Date: Tue, 29 Mar 2016 09:24:15 -0000
Subject: DC spike remove ???
In-Reply-To: <CANTNY2frYy-ckjnymPCCxkqeRPsCxyNuiyvRk8gp5S=KTjSwSQ@mail.gmail.com>
References: <CANTNY2frYy-ckjnymPCCxkqeRPsCxyNuiyvRk8gp5S=KTjSwSQ@mail.gmail.com>
Message-ID: <CANTNY2c4gP6av0UrTuLocYGp465GyQQEfoFr+caGisSYmA0xPg@mail.gmail.com>

Hi,

 I just started experimenting with rtl-fm with a DVB-T stick and a
raspberry pi 2. It's really very simple to use but I currently have a
problem by setting a frequency in NBFM mode. When I slightly shifts
the frequency of the true frequency , it appears intermodulation with
DC spike even with the dc -E parameters and offset -E ???  The problem
does not exist with automatic gain. IQ balance dont work with a fixed
gain (ex -g 30) or i made mistake in my command line ??? Have you ever
encountered this problem?


Thanks,

Arnaud
F6GNJ


From ejesse at nd.edu  Tue Mar 29 16:23:04 2016
From: ejesse at nd.edu (Eric Jesse)
Date: Tue, 29 Mar 2016 16:23:04 -0000
Subject: Segfault bug and solution
Message-ID: <CAH7Wt+-S330OZz87CAHYQqrt7+251EzJAjy2kjHLFFpEchuHdg@mail.gmail.com>

Hey all,

I've been looking into a seg fault bug appearing after asynchronous reads,
and I wanted to put forward my thoughts, and a potential solution, perhaps
for the official release.

I looked into the C source code and have ultimately determined that problem
lies in the rtlsdr_read_async function in librtlsdr.c, which usually (if
not always) returns a -5. I've traced this error back to the
libusb_cancel_transfer function.

My proposed solution is to change the following condition, "if (r < 0)" to
"if (r < 0 && r != LIBUSB_ERROR_NOT_FOUND)".

Why? It's been noted that the new transfer status from the
libusb_cancel_transfer function does not propagate immediately (and to be
honest, I'm not sure when exactly it propagates). As it is now, if the
function returns successfully (r=0), the function runs through the while
loop again, and checks all the functions to see if they are cancelled. If
not, (i.e. the status hasn't propagated) the libusb_cancel_transfer
function is called again, but this time it returns LIBUSB_ERROR_NOT_FOUND,
which according to the function description in the libusb documentation
means "the transfer is not in progress, already complete, or already
cancelled" and is treated as an error. This does not sound to me like an
error, but something that can be ignored to give time for the already
"cancelled" signal to obtain the "CANCELED" status.

I've implemented the change personally, and everything seems to work fine.
I don't know if others have seen the same seg fault problem I have, but
this seems to be a working, minimal solution. Let me know if I'm
interpreting the "transfer is not in progress, already complete, or already
cancelled" wrong, since I don't want to ignore any actual problems.

Thanks,
Eric Jesse
AMDG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20160329/4769bbff/attachment.htm>