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

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

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@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@gmail.com <mailto:jdpoirier@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

Ok so I merged two PRs in the repository that contains the Infrared APIs. I tested and works fine, might be usefull.

Since we added features since the original branch, I made a PR to change the version to 0.6 ( https://github.com/librtlsdr/librtlsdr/pull/12 )

What do you think guys?

Lucas

On 06/03/2016 01:30, Lucas Teske wrote:

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@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@gmail.com <mailto:jdpoirier@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

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/25d0e8e6737b93b3564ad04d0fd2cd5...

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

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