From laforge at gnumonks.org  Sun Jun  3 18:17:31 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 3 Jun 2018 20:17:31 +0200
Subject: gr-osmosdr / no tagged versions since 2014
Message-ID: <20180603181731.GU3699@nataraja>

Hi!

today I discovered that the gr-osmosdr package in debian unstable contains
a whooping list of 96 patches.  This is due to the fact that since November
2014 there hasn't been any tagged versions in the repository.

I'd like to suggest to tag releases a bit more often.

@horizon: What about jumping to 1.0.0 right away?

Regards,
	Harald
-- 
- 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 laforge at gnumonks.org  Sun Jun  3 18:14:47 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 3 Jun 2018 20:14:47 +0200
Subject: Tagging new versions of rtl-sdr and osmo-fl2k
Message-ID: <20180603181447.GT3699@nataraja>

Hi!

Today I've added rtl-sdr and osmo-fl2k to the automatic nightly package
builds at https://build.opensuse.org/project/monitor/network:osmocom:nightly

I also wanted to add them to the "latest" feeds (which build that latest
tagged version, as opposed to a nightly snapshot).  However, for this to
work we need tagged versions that include the "debian" sub-directory
in the respective projects.

I hence temporarily disabled the "latest" builds until that happens,
see
https://build.opensuse.org/project/monitor/network:osmocom:nightly

Please let me know once new versions are tagged and
the above patch can be reverted. 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 steve at steve-m.de  Sun Jun  3 18:40:37 2018
From: steve at steve-m.de (Steve Markgraf)
Date: Sun, 3 Jun 2018 20:40:37 +0200
Subject: fl2k_* have libusb: error [op_dev_mem_alloc] alloc dev mem failed
 errno 12
In-Reply-To: <743a2e6e-b925-e742-6fa6-5391c1d85a2b@yahoo.com>
References: <3cd3b886-afb0-cf95-65b4-5b8c4fd6494f@steve-m.de>
 <743a2e6e-b925-e742-6fa6-5391c1d85a2b@yahoo.com>
Message-ID: <fde30d53-0372-6274-d8ab-0c0078b73cb5@steve-m.de>

Hi,

On 30.05.2018 17:57, Hannes Wagner wrote:
> I haven't been able to receive a FM signal yet. My output from the fl2k_test shows:

What are the commandline parameters you are using for fl2k_fm? As you
can see below, you need to limit your samplerate to < 114 MS/s.

> sudo fl2k_test -s 162e6
> Allocating 6 zero-copy buffers
> libusb: error [op_dev_mem_alloc] alloc dev mem failed errno 12
> Failed to allocate zero-copy buffer for transfer 4
> Falling back to buffers in userspace
> Reporting PPM error measurement every 10 seconds...
> Press ^C after a few minutes.
> real sample rate: 113962068 current PPM: -296530 cumulative PPM: -296530
> real sample rate: 113975309 current PPM: -296449 cumulative PPM: -296489
> real sample rate: 114139355 current PPM: -295436 cumulative PPM: -296136
> 
> Do I need to change my kernel settings or will the device simply won't work?

What happens according to the output: libfl2k is running on a system
that seems to support zero-copy transfers, but fails during allocation.
Probably there is not enough DMA-able contiguous memory present for the
Kernel. This is no big deal, as libfl2k will then de-allocate the
already allocated zero-copy buffers, and then fall back to buffers
allocated with malloc() (which of course then will require
copy_from_user() in the Kernel).
So it should work just fine, you just won't get the performance
benefit of zero-copy buffers.
And according to the output of fl2k_test, you are getting around 114
MS/s, as you are probably using a Renesas uPD7202xx controller. If you
want to generate any output, you need to set the sample rate to a value
below that.

Regards,
Steve


From bottoms at debian.org  Sun Jun  3 19:54:23 2018
From: bottoms at debian.org (A. Maitland Bottoms)
Date: Sun, 3 Jun 2018 15:54:23 -0400
Subject: gr-osmosdr / no tagged versions since 2014
In-Reply-To: <20180603181731.GU3699@nataraja>
References: <20180603181731.GU3699@nataraja>
Message-ID: <20180603155423.22f85821@216-Moncure.Alexandria.VA.US>

On Sun, 3 Jun 2018 20:17:31 +0200
Harald Welte <laforge at gnumonks.org> wrote:

> Hi!
> 
> today I discovered that the gr-osmosdr package in debian unstable
> contains a whooping list of 96 patches.  This is due to the fact that
> since November 2014 there hasn't been any tagged versions in the
> repository.

98.
But I do not apply 0001-update-version-to-0.1.5git.patch
so that the version stayed at 0.1.4.

I added Alex Csete's patch Add-initial-support-for-Airspy-HF
from his fork of gr-osmosdr for gqrx.

And a trivial doxygen-reproducible patch that should make the
reproducible-build folk happy.

Please consider incorporating those before your next release tag.

> 
> I'd like to suggest to tag releases a bit more often.

Let me second that!
Release Early, Release Often!

Bonus points for cryptographic signing or released source, either by
using gpg with git to sign tags, or creating detached signatures of
release source tarballs.

> 
> @horizon: What about jumping to 1.0.0 right away?
> 
> Regards,
> 	Harald

0.1.5 would still work fine.
Due to steady C++ compiler changes and my aggressive bumping of
gnuradio's soname and soversion for each gnuradio release, I have not
been so worried about checking API and ABI changes with gr-osmosdr.
Package dependencies make upgrades work smoothly.

Some more details about Debian packages that may interest this list:
As described in debian/copyright, in lieu of gr-osmosdr release
tarballs, I use
git archive --format=tar --prefix=gr-osmosdr-0.1.4/  v0.1.4 \
 | xz > ../gr-osmosdr_0.1.4.orig.tar.xz
to create the basis of the Debian source package.

Then, to get more of your recent good work out of your git tree and
into Debian packages, I use
git format-patch v0.1.4
to generate a series that gets applied to the source tarball via Debian
quilt patch format source packaging tools.

But yes, that begins to get annoying with so many commits between tags.

Thanks for all your good work on making gr-osmosdr so useable and
useful!

Your humble Debian package maintainer,
-Maitland

P.S.
If you contribute to osmocom, some of my remarks I made at the last
gnuradio conference, grcon17, apply to you too:
https://www.youtube.com/watch?v=yKKjbT6YXgA

Thanks again for all the good bits.


From andrea.montefusco at gmail.com  Sun Jun  3 21:44:53 2018
From: andrea.montefusco at gmail.com (andrea montefusco)
Date: Sun, 3 Jun 2018 23:44:53 +0200
Subject: gr-osmosdr / no tagged versions since 2014
In-Reply-To: <20180603155423.22f85821@216-Moncure.Alexandria.VA.US>
References: <20180603181731.GU3699@nataraja>
 <20180603155423.22f85821@216-Moncure.Alexandria.VA.US>
Message-ID: <CACFb=ue1fSjBrixq08sszfYm9EjXSsTdZOQKEf191y8vmr1Tyg@mail.gmail.com>

Hi,
Could you even add my patches for Persues receiver as found in

https://github.com/IW0HDV/gr-osmosdr/tree/perseusairspyhf

?

Andrea Montefusco IW0HDV
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180603/e263c074/attachment.htm>

From jjvonblack at riseup.net  Mon Jun  4 09:00:48 2018
From: jjvonblack at riseup.net (JJ)
Date: Mon, 4 Jun 2018 11:00:48 +0200
Subject: fl2k - low samplerate/ no rf-output
In-Reply-To: <CAHL+j0-G39cWD0b48tfMSoqST2RX7qqT66AQ8JvxfFMKCSZQfQ@mail.gmail.com>
References: <9AD843F2-0709-4296-AAB1-60E81BA20E9E@bitmessage.ch>
 <4fc8cd7451959c41654b81f1f38e1dd2@riseup.net>
 <CAHL+j0-G39cWD0b48tfMSoqST2RX7qqT66AQ8JvxfFMKCSZQfQ@mail.gmail.com>
Message-ID: <9d3c9f43eae488421f4c8cacaee54c31@riseup.net>

> There is your problem .... it should say "Super Speed" for a USB3 device.
> 
> There has been several reports that some low quality devices just are
> broken out-of-the-box ...
> 
> Some with the super speed wires badly soldered or at the wrong place.
> 
> 
> Cheers,
> 
>     Sylvain

Well, thanks for the explanation: that was a detail I didn't notice.
Yesterday I disassembled the adapter and found that the PCB looks like the one shown in the "Fixing OSMO-FL2K Dongle that only works in USB 2.0" article[1] (altough wired in a different way).
In my case the SuperSpeed wires were soldered fine but at the wrong place. Two wires, the blue and yellow, didn't even follow the the standard USB coloring (tested it with a cheap digital multimeter).
Here's the way my dongle has been wired:

Front:

- GREEN      | D+
- WHITE      | D-
- PLAIN WIRE | GND_DRAIN
- PURPLE     | SSTX-
- YELLOW     | SSRX-     (should be SSRX+)
- BLUE       | SSRX+     (should be SSRX-)
- ORANGE     | SSTX+

Back:

- RED        | VBUS
- BLACK      | GND

I've then attempted to rewire it but due to both my nearly inexistent soldering skills and the use of a very cheap welder ($10) I've managed to render it completely broken (the massive presence of hot glue didn't help).
Probably it would have been easier just to cut the wires and bind them together in the correct way without any resoldering (only using some insulating tape).

Does somebody knows any reputable source which sells the same device but not broken out-of-the-box?


[1]: http://tinyhack.com/2018/05/05/fixing-osmo-fl2k-dongle-that-only-works-in-usb-2-0/


Thanks again,
JJ


From bjorn.forsman at gmail.com  Mon Jun  4 14:23:48 2018
From: bjorn.forsman at gmail.com (=?UTF-8?Q?Bj=C3=B8rn_Forsman?=)
Date: Mon, 4 Jun 2018 16:23:48 +0200
Subject: gr-osmosdr / no tagged versions since 2014
In-Reply-To: <20180603155423.22f85821@216-Moncure.Alexandria.VA.US>
References: <20180603181731.GU3699@nataraja>
 <20180603155423.22f85821@216-Moncure.Alexandria.VA.US>
Message-ID: <CAEYzJUHN3cdF82wNxTrJwhix=egA+G9kwLQxZRSX0tiYjS5Pjw@mail.gmail.com>

On 3 June 2018 at 21:54, A. Maitland Bottoms <bottoms at debian.org> wrote:
> [...]
> Then, to get more of your recent good work out of your git tree and
> into Debian packages, I use
> git format-patch v0.1.4
> to generate a series that gets applied to the source tarball via Debian
> quilt patch format source packaging tools.

In Nixpkgs we ship plain v0.1.4, because that is the latest release. If you
(gr-osmosdr developers) want users to get newer software, please make a tag
/ release.

- Bj?rn Forsman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180604/1e95ec25/attachment.htm>

From patrick at wirklich.priv.at  Mon Jun  4 22:07:25 2018
From: patrick at wirklich.priv.at (Patrick Strasser-Mikhail)
Date: Tue, 5 Jun 2018 00:07:25 +0200
Subject: gr-osmosdr / no tagged versions since 2014
In-Reply-To: <20180603155423.22f85821@216-Moncure.Alexandria.VA.US>
References: <20180603181731.GU3699@nataraja>
 <20180603155423.22f85821@216-Moncure.Alexandria.VA.US>
Message-ID: <aad35c4d-2fe7-f449-b2b6-fee481bcfbac@wirklich.priv.at>

A. Maitland Bottoms 2018-06-03 21:54:
> On Sun, 3 Jun 2018 20:17:31 +0200
> Harald Welte <laforge at gnumonks.org> wrote:
> 
>> today I discovered that the gr-osmosdr package in debian unstable
>> contains a whooping list of 96 patches.  This is due to the fact that
>> since November 2014 there hasn't been any tagged versions in the
>> repository.
> 
> 98.
> But I do not apply 0001-update-version-to-0.1.5git.patch
> so that the version stayed at 0.1.4.
> 
> I added Alex Csete's patch Add-initial-support-for-Airspy-HF
> from his fork of gr-osmosdr for gqrx.
> 
> And a trivial doxygen-reproducible patch that should make the
> reproducible-build folk happy.
> 
> Please consider incorporating those before your next release tag.
> 
>>
>> I'd like to suggest to tag releases a bit more often.
>>
>> @horizon: What about jumping to 1.0.0 right away?
> 
> 0.1.5 would still work fine.
What do you think of Semantic Versioning (https://semver.org/)?

> Summary
> -------
> 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.

> FAQ
> ---
> [...]
> How do I know when to release 1.0.0?
> ------------------------------------
> If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you?re worrying a lot about backwards compatibility, you should probably already be 1.0.0.
> [...]

gr-osmosdr being actively used for years now and already including
dozens of patches and forked-tree features, it seems to me that 1.0.0 is
completely warranted.
If bugfixes and new features keep on coming, bumps in minor number and
patch number seem to help make versions better comparable.

BR

Patrick
-- 
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-Mikhail <patrick at wirklich priv at>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180605/d851a7c7/attachment.bin>

From fred.neich at yandex.com  Fri Jun  8 23:47:51 2018
From: fred.neich at yandex.com (Fred Neich)
Date: Sat, 09 Jun 2018 00:47:51 +0100
Subject: Osmo-fl2k
Message-ID: <716751528501671@web37g.yandex.ru>

Hello,

I have a question about osmo-fl2k,
the generated binary file using the fl2k grc transmission flow graphs, contains the carrier frequency,
the fl2k_file stream the file to the device, so how the device can transmit these data in that frequency.
I mean how it recognize the frequency to transmit on.


Thank you.





From marcus.mueller at ettus.com  Sat Jun  9 11:05:46 2018
From: marcus.mueller at ettus.com (Marcus =?ISO-8859-1?Q?M=FCller?=)
Date: Sat, 09 Jun 2018 13:05:46 +0200
Subject: Osmo-fl2k
In-Reply-To: <716751528501671@web37g.yandex.ru>
References: <716751528501671@web37g.yandex.ru>
Message-ID: <1528542346.3372.430.camel@ettus.com>

These files just contain raw samples.

The fact that the signal then isn't around 0 Hz is simply because it 

1. (optionally/depends on example you're referring to) was mixed, in
the generating GNU Radio script, onto a carrier frequency within the
first Nyquist zone and
2. on the fact that DACs introduce *images* in spectrum at multiples of
the sampling rate, and you exploit these to have a copy of your signal,
shifted by a multiple of the sampling rate. You should filter out all
the other copies.

Terms to google for: reconstruction filter, band-pass undersampling

Best regards,
Marcus

On Sat, 2018-06-09 at 00:47 +0100, Fred Neich wrote:
> Hello,
> 
> I have a question about osmo-fl2k,
> the generated binary file using the fl2k grc transmission flow
> graphs, contains the carrier frequency,
> the fl2k_file stream the file to the device, so how the device can
> transmit these data in that frequency.
> I mean how it recognize the frequency to transmit on.
> 
> 
> Thank you.
> 
> 
> 


From cattalina.nicolescu at gmail.com  Wed Jun  6 09:11:31 2018
From: cattalina.nicolescu at gmail.com (Cattalina Maria)
Date: Wed, 6 Jun 2018 05:11:31 -0400
Subject: question!
Message-ID: <CAOT51P=64TOUKAdp3VtE0YtVT288VPouoA8ck40Wc+EXYHUbhg@mail.gmail.com>

Hello. I have some problems.I want to create a GSM network for my final
diploma project for University.I'm using USRP2 and I haven't find any
specific configuration files for this type of USRP.Do you have any
configuration files for USRP2? I'm running Kali Linux (amd64). I've
attached the config files that I've used from osmocom.org and some
printscreens.Sorry for my English.I'm looking forward for your
response.Thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180606/3715bdbe/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openbsc44.conf
Type: application/octet-stream
Size: 4250 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180606/3715bdbe/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmobsc3.cfg
Type: application/octet-stream
Size: 1807 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180606/3715bdbe/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-bts44.cfg
Type: application/octet-stream
Size: 568 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180606/3715bdbe/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-pcu44.cfg
Type: application/octet-stream
Size: 1060 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180606/3715bdbe/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: snapbsc.png
Type: image/png
Size: 897224 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180606/3715bdbe/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: snapbsc2.png
Type: image/png
Size: 596849 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180606/3715bdbe/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: snapbts.png
Type: image/png
Size: 647904 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180606/3715bdbe/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: snappcu.png
Type: image/png
Size: 567156 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180606/3715bdbe/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: snaptrx.png
Type: image/png
Size: 640124 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180606/3715bdbe/attachment-0004.png>

From maxime.vince at gmail.com  Sun Jun 10 10:22:30 2018
From: maxime.vince at gmail.com (Maxime Vincent)
Date: Sun, 10 Jun 2018 12:22:30 +0200
Subject: [patch] fix compilation with boost 1.67
Message-ID: <CACBz148UwKxM=0wV06cX7nonN2VgDx3C+eYJhuZJBiBkELgJ2g@mail.gmail.com>

Hi everyone @ gr-osmosdr,

I have created a small pull request to fix compilation with boost-1.67.
I filed it on your github mirror, but am not sure that's the way to
make a contribution.
It's available here:
https://github.com/osmocom/gr-osmosdr/pull/13

I'll also include the patch here for completeness:

diff -ura gr-osmosdr.orig/lib/CMakeLists.txt gr-osmosdr/lib/CMakeLists.txt
--- gr-osmosdr.orig/lib/CMakeLists.txt 2018-06-10 12:06:35.662484236 +0200
+++ gr-osmosdr/lib/CMakeLists.txt 2018-06-10 12:06:51.886207437 +0200
@@ -43,6 +43,8 @@
     time_spec.cc
 )

+list(APPEND Boost_LIBRARIES pthread)
+
 GR_OSMOSDR_APPEND_LIBS(
     ${Boost_LIBRARIES}
     ${GNURADIO_ALL_LIBRARIES}



Cheers,
Maxime


From keil at keil-tech.de  Mon Jun 11 20:15:07 2018
From: keil at keil-tech.de (Torben Keil)
Date: Mon, 11 Jun 2018 22:15:07 +0200
Subject: Usability of i2c of fl2k?
Message-ID: <eb256ac4e6259bf1d7dfc653ef190ad8@keil-tech.de>

Hello List,
I tried to get a signal over the i2c interface but it wasn't sucsessful.
Do you have an idea how to enable the i2c interface on the fl2k chip? 

Best whishes,
Torben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180611/fef2feb4/attachment.htm>

From steve at steve-m.de  Mon Jun 11 20:57:32 2018
From: steve at steve-m.de (Steve Markgraf)
Date: Mon, 11 Jun 2018 22:57:32 +0200
Subject: Usability of i2c of fl2k?
In-Reply-To: <eb256ac4e6259bf1d7dfc653ef190ad8@keil-tech.de>
References: <eb256ac4e6259bf1d7dfc653ef190ad8@keil-tech.de>
Message-ID: <0980fc9e-697a-77a3-cdeb-b5b36216cdd0@steve-m.de>

Hi Torben,

On 11.06.2018 22:15, Torben Keil wrote:
> I tried to get a signal over the i2c interface but it wasn't sucsessful.
> Do you have an idea how to enable the i2c interface on the fl2k chip?

I have some code sitting here, but when I wanted to clean it up
recently, it didn't work anymore as expected. I'll need to debug it with
a logic analyzer. Note that the FL2000 can only do I2C transfers of a
fixed length of 4 bytes, it was probably really only meant to read EDID
EEPROMs.
In the original driver, single register writes to the ITE HDMI interface
chip that some devices have are first reading 4 registers, then
modifying the desired byte, and then writing them back.

Regards,
Steve


From sajjsamm at yahoo.com  Wed Jun 13 18:38:19 2018
From: sajjsamm at yahoo.com (Sajjad Golchin poor)
Date: Wed, 13 Jun 2018 18:38:19 +0000 (UTC)
Subject: Osmo-FL2K stops transmitting randomly
References: <610977808.8451983.1528915099224.ref@mail.yahoo.com>
Message-ID: <610977808.8451983.1528915099224@mail.yahoo.com>

Hi all,

as some of you know Osmo-fl2k has a bothersome software issue that sometimes just stop transmitting without any good reason.?in my case when I was transmitting WBFM sometimes it may stop transmitting. I mean the RF output will be interrupted completely without any error or warnings on screen and I should re-execute the commands to transmit again and this goes on and on. sometimes it may work without any issues for like 10 min and sometimes it may fail after just a few seconds. the problem also appeared in executing <fl2k_file> when I was transmitting DVB-T.

you can watch this video to gain a better understanding: https://www.youtube.com/watch?v=G0tjzPHFFA8

I have no idea if this issue been discussed earlier in the mailing list or not, anyway I didn't find anything useful by Googling.your comments and suggestions are greatly appreciated.
Regards,Sajjad

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

From mueller at kit.edu  Wed Jun 13 19:06:32 2018
From: mueller at kit.edu (=?utf-8?B?TcO8bGxlciwgTWFyY3VzIChDRUwp?=)
Date: Wed, 13 Jun 2018 19:06:32 +0000
Subject: Osmo-FL2K stops transmitting randomly
In-Reply-To: <610977808.8451983.1528915099224@mail.yahoo.com>
References: <610977808.8451983.1528915099224.ref@mail.yahoo.com>
 <610977808.8451983.1528915099224@mail.yahoo.com>
Message-ID: <1528916791.3372.503.camel@kit.edu>

Hi Sajjad,

no, this issue doesn't seem related to any other topic that I can
remember lately ? I've seen wonder why a non-transmitting test didn't
transmit, but no reports of sudden breakdowns.

Your video is about 13 minutes longer than I'd like ? can you pinpoint
at which time in that video your transmission stops?

As usual, debugging on the side of the observing party might very well
be helpful here. Figure out whether the program halts (a software
debugger, e.g. gdb, would be the appropriate tool), the USB transfers
stop (wireshark might be helpful here), or whether just something
happens inside the device while the computer and software happily
continue to work. Observing the spectrum might help. Describe whether
the signal just disappears, or changes in a manner that makes reception
of DVB-T impossible. Isolate the sources of error ? start with a much
less complex signal, typically a single sine wave that you can easily
observe.

All in all, what we'd need to help you is a complete error description.

Best regards,
Marcus

On Wed, 2018-06-13 at 18:38 +0000, Sajjad Golchin poor wrote:
> Hi all,
> 
> as some of you know Osmo-fl2k has a bothersome software issue that
> sometimes just stop transmitting without any good reason. in my case
> when I was transmitting WBFM sometimes it may stop transmitting. I
> mean the RF output will be interrupted completely without any error
> or warnings on screen and I should re-execute the commands to
> transmit again and this goes on and on. sometimes it may work without
> any issues for like 10 min and sometimes it may fail after just a few
> seconds. the problem also appeared in executing <fl2k_file> when I
> was transmitting DVB-T.
> 
> you can watch this video to gain a better understanding: https://www.
> youtube.com/watch?v=G0tjzPHFFA8
> 
> I have no idea if this issue been discussed earlier in the mailing
> list or not, anyway I didn't find anything useful by Googling.
> your comments and suggestions are greatly appreciated.
> 
> Regards,
> Sajjad
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6582 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180613/fc5fb1d4/attachment.bin>

From steve at steve-m.de  Wed Jun 13 19:13:00 2018
From: steve at steve-m.de (Steve Markgraf)
Date: Wed, 13 Jun 2018 21:13:00 +0200
Subject: Osmo-FL2K stops transmitting randomly
In-Reply-To: <610977808.8451983.1528915099224@mail.yahoo.com>
References: <610977808.8451983.1528915099224.ref@mail.yahoo.com>
 <610977808.8451983.1528915099224@mail.yahoo.com>
Message-ID: <da41122f-fa83-8280-ddfa-e85bca9ad63b@steve-m.de>

Hi Sajjad,

On 13.06.2018 20:38, Sajjad Golchin poor wrote:
> as some of you know Osmo-fl2k has a bothersome software issue that
> sometimes just stop transmitting without any good reason.?in my case
> when I was transmitting WBFM sometimes it may stop transmitting. I mean
> the RF output will be interrupted completely without any error or
> warnings on screen and I should re-execute the commands to transmit
> again and this goes on and on. sometimes it may work without any issues
> for like 10 min and sometimes it may fail after just a few seconds. the
> problem also appeared in executing <fl2k_file> when I was transmitting
> DVB-T.
> 
> you can watch this video to gain a better understanding:
> https://www.youtube.com/watch?v=G0tjzPHFFA8

This will happen if the host cannot supply enough data to the device,
you need to use a lower sample rate in this case, or get rid of
a hypervisor like VMware, as is the case in this video.

When operating as a normal graphics adapter, the frame would be skipped
when an underflow happens and the screen flickers, however, when
HSYNC/VSYNC is disabled the device completely stops and needs to be
re-initialized.
There seems to be a 'frame loss' mechanism to detect this in  through an
interupt transfer, but I haven't implemented this yet and have no idea
if this works with disabled synchronization.

Anyway, there seems to be something wrong with your setup. Either host
controller, or host controller driver etc. What setup are you using (OS,
host controller, any virtualization present like in the video?)

Regards,
Steve



From osmocom at lains.me  Thu Jun 14 13:16:31 2018
From: osmocom at lains.me (Filipe =?iso-8859-1?b?TGHtbnM=?=)
Date: Thu, 14 Jun 2018 14:16:31 +0100
Subject: question!
In-Reply-To: <CAOT51P=64TOUKAdp3VtE0YtVT288VPouoA8ck40Wc+EXYHUbhg@mail.gmail.com>
References: <CAOT51P=64TOUKAdp3VtE0YtVT288VPouoA8ck40Wc+EXYHUbhg@mail.gmail.com>
Message-ID: <1528982191.1052.0@smtp.migadu.com>

Hey Cattalina,

As stated in the logs, the openbsc44.conf config has some problem. You 
should re-write it. If you want, you can use this one as a base.
Let me know if you more help :)

Thanks,
Filipe La?ns (FFY00)
https://github.com/FFY00
3DCE 51D6 0930 EBA4 7858  BA41 46F6 33CB B0EB 4BF2

On Wed, Jun 6, 2018 at 10:11 AM, Cattalina Maria 
<cattalina.nicolescu at gmail.com> wrote:
> Hello. I have some problems.I want to create a GSM network for my 
> final diploma project for University.I'm using USRP2 and I haven't 
> find any specific configuration files for this type of USRP.Do you 
> have any configuration files for USRP2? I'm running Kali Linux 
> (amd64). I've attached the config files that I've used from 
> osmocom.org and some printscreens.Sorry for my English.I'm looking 
> forward for your response.Thank you!


Sent via Migadu.com, world's easiest email hosting
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180614/8dc49151/attachment.htm>

From sajjsamm at yahoo.com  Sat Jun 16 07:16:04 2018
From: sajjsamm at yahoo.com (Sajjad Golchin poor)
Date: Sat, 16 Jun 2018 11:46:04 +0430
Subject: Osmo-FL2K stops transmitting randomly
Message-ID: <mailman.16.1641746905.43026.osmocom-sdr@lists.osmocom.org>

Hi Marcus and thanks for your reply.

>Your video is about 13 minutes longer than I'd like ? can you pinpoint
>at which time in that video your transmission stops?

You can watch this video between 7:00 & 8:00 to observe the breakdowns.

>As usual, debugging on the side of the observing party might very well
>be helpful here. Figure out whether the program halts (a software
>debugger, e.g. gdb, would be the appropriate tool), the USB transfers
>stop (wireshark might be helpful here), or whether just something
>happens inside the device while the computer and software happily
>continue to work. Observing the spectrum might help.

You just gave me a good point to start debugging this issue! Actually I don?t have a RTL-SDR or anything else in hand right now to observe the spectrum but I will do the tests soon.
--------------------------------------------

Hi Steve, did a great job!

>This will happen if the host cannot supply enough data to the device,
>you need to use a lower sample rate in this case, or get rid of
>a hypervisor like VMware, as is the case in this video.

I tried fl2k_fm both in VMWare and in GNU radio live image booted from a flash drive and in both I had the problem. and why should I use a lower sample rate when my system can handle the samples well? (take a look at attachments)

I?m using VMWare Workstation Pro (Version: 14.1.2 build-8497320) on a brand new ACER laptop (Model: Aspire A715-71G-71Y3) running Windows 10 Pro 1803 (Build: 17134.112) with 16 gigabyte RAM and an Intel Core i7 7700HQ CPU. The USB host controller is Intel(R) USB 3.0 eXtensible Host Controller - 1.0 (Microsoft) witch I believe it can handle up to 157 MS/s. all drivers are updated. 
However, I didn?t see anything wrong with virtualization except that the maximum achievable sample rate was a little lower than the GNU radio live booted from flash drive. Except for this, I didn't encounter by anything.

>There seems to be a 'frame loss' mechanism to detect this in ?through an
>interrupt transfer, but I haven't implemented this yet and have no idea
>if this works with disabled synchronization.

Looking forward to the results!
And don?t mind asking me for a helping hand. I?ll do my best to help this project.

I was reading the comments below this post in rtl-sdr.com blog and I saw a user who had the same issue mentioned something that might be useful:
Of futher note (hopefully someone from osmocom will see this) the bug where the broadcast intermittently ceases in fl2k_fm under both an ubuntu virtual machine and directly ran as a windows exe seems to have something to do with cpu affinity and / or process priority ? generally it starts spitting out the underflow message on stdout then the signal drops out and the process requires a restart.
Regards,
Sajjad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180616/73d71d4e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20180517_233048-min.jpg
Type: image/jpeg
Size: 96370 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180616/73d71d4e/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnu-2018-05-29-14-26-46-min.png
Type: image/png
Size: 88628 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180616/73d71d4e/attachment.png>

From keil at keil-tech.de  Sat Jun 16 07:40:58 2018
From: keil at keil-tech.de (Torben Keil)
Date: Sat, 16 Jun 2018 09:40:58 +0200
Subject: Usability of i2c of fl2k?
In-Reply-To: <0980fc9e-697a-77a3-cdeb-b5b36216cdd0@steve-m.de>
References: <eb256ac4e6259bf1d7dfc653ef190ad8@keil-tech.de>
 <0980fc9e-697a-77a3-cdeb-b5b36216cdd0@steve-m.de>
Message-ID: <fa822a3d2222a939ae493bee5e381886@keil-tech.de>

Hi Steve,

do you have a git repository for the code so that I could have a try?


Regards,
Torben



Am 11.06.2018 22:57, schrieb Steve Markgraf:
> Hi Torben,
> 
> On 11.06.2018 22:15, Torben Keil wrote:
>> I tried to get a signal over the i2c interface but it wasn't 
>> sucsessful.
>> Do you have an idea how to enable the i2c interface on the fl2k chip?
> 
> I have some code sitting here, but when I wanted to clean it up
> recently, it didn't work anymore as expected. I'll need to debug it 
> with
> a logic analyzer. Note that the FL2000 can only do I2C transfers of a
> fixed length of 4 bytes, it was probably really only meant to read EDID
> EEPROMs.
> In the original driver, single register writes to the ITE HDMI 
> interface
> chip that some devices have are first reading 4 registers, then
> modifying the desired byte, and then writing them back.
> 
> Regards,
> Steve


From steve at steve-m.de  Sun Jun 17 01:18:57 2018
From: steve at steve-m.de (Steve Markgraf)
Date: Sun, 17 Jun 2018 03:18:57 +0200
Subject: Usability of i2c of fl2k?
In-Reply-To: <fa822a3d2222a939ae493bee5e381886@keil-tech.de>
References: <eb256ac4e6259bf1d7dfc653ef190ad8@keil-tech.de>
 <0980fc9e-697a-77a3-cdeb-b5b36216cdd0@steve-m.de>
 <fa822a3d2222a939ae493bee5e381886@keil-tech.de>
Message-ID: <ee87d960-d405-ec7d-e185-7738058f16e7@steve-m.de>

Hi Torben,

On 16.06.2018 09:40, Torben Keil wrote:
> do you have a git repository for the code so that I could have a try?

I've debugged and cleaned up the I2C code and just pushed it.
I2C transfers with the FL2000 seem to fail from time to time, so make
sure to check the return code of fl2k_i2c_read()/fl2k_i2c_write().

Regards,
Steve


From tom at tswartz.net  Thu Jun 14 21:27:17 2018
From: tom at tswartz.net (tom at tswartz.net)
Date: Thu, 14 Jun 2018 17:27:17 -0400
Subject: Lists page cert expired
Message-ID: <20180614212717.GA1269@gmail.com>

Hey all:

Just a heads up, the certificate on the mailing list site has expired.
It expired two days ago, 12 June 2018.

Since it's signed by Lets Encrypt, shouldn't be too hard to update,
but you might want to do that ;)

Cheers,

-- 
Tom Swartz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180614/518f9b9d/attachment.bin>

From steve at steve-m.de  Sun Jun 17 16:02:04 2018
From: steve at steve-m.de (Steve Markgraf)
Date: Sun, 17 Jun 2018 18:02:04 +0200
Subject: [patch] fix compilation with boost 1.67
In-Reply-To: <CACBz148UwKxM=0wV06cX7nonN2VgDx3C+eYJhuZJBiBkELgJ2g@mail.gmail.com>
References: <CACBz148UwKxM=0wV06cX7nonN2VgDx3C+eYJhuZJBiBkELgJ2g@mail.gmail.com>
Message-ID: <a494df14-971c-166a-1bec-c3beb62622c1@steve-m.de>

Hi Maxime,

On 10.06.2018 12:22, Maxime Vincent wrote:
> I have created a small pull request to fix compilation with boost-1.67.

Thanks for the patch, I've merged it. I've successfully built with
boost-1.65, so older version still seem to work.

Regards,
Steve



From steve at steve-m.de  Sun Jun 17 20:02:03 2018
From: steve at steve-m.de (Steve Markgraf)
Date: Sun, 17 Jun 2018 22:02:03 +0200
Subject: Usability of i2c of fl2k?
In-Reply-To: <865a032f565e564d19c53a7121a62ab5@keil-tech.de>
References: <eb256ac4e6259bf1d7dfc653ef190ad8@keil-tech.de>
 <0980fc9e-697a-77a3-cdeb-b5b36216cdd0@steve-m.de>
 <fa822a3d2222a939ae493bee5e381886@keil-tech.de>
 <ee87d960-d405-ec7d-e185-7738058f16e7@steve-m.de>
 <865a032f565e564d19c53a7121a62ab5@keil-tech.de>
Message-ID: <a2401b22-9b87-44f1-9c24-72c6c016ee70@steve-m.de>

Hi Torben,

I'm replying with the mailing-list in Cc, as this might also be
interesting for others.

As mentioned earlier, the issue is that the FL2000 has a very inflexible
I2C implementation that was only intended (I guess?) for I2C EEPROMs.
The PCF8574 you want to use is much simpler, as it expects only one data
byte after being addressed.

If you can live with only 6 of the 8 outputs on your port expander, you
might still be able to get it working.

What the FL2000 does for an I2C write is the following:

START, I2C_ADDR(W), REG_ADDR,   DATA[0], STOP
START, I2C_ADDR(W), REG_ADDR+1, DATA[1], STOP
START, I2C_ADDR(W), REG_ADDR+2, DATA[2], STOP
START, I2C_ADDR(W), REG_ADDR+3, DATA[3], STOP

As you can see, REG_ADDR is the first byte of data that is being sent to
the device after the address. This is where you need to put the data
you want to set on the IO expander outputs. As the FL2000
auto-increments the register address, you need to set the lowest 2 bits
to 0, so that the increment is not carried to the higher bits. But that
also means that output 0 and 1 of your port-expander will toggle with
each write and are not controllable by you.

>From the datasheet of the PCF8574:
"If other data bytes are sent from the master, following the
acknowledge, they are ignored by this device."

That means that DATA[0-3] are completely ignored, which probably means
that the device will send a NAK for that byte.
So the transfer always will fail from the view of the FL2000, so you
must ignore the return value of fl2k_i2c_write(), which means you also
have no feedback if the slave is actually present or not.

The first thing I would suggest trying is writing a non-zero reg_addr to
all possible slave addresses and observe the output of the port
expander. If you have a logic analyzer, I suggest to use that and have a
look at the I2C bus.

If all that doesn't work, using a small MCU and dealing with the FL2000
I2C oddities there is probably the easiest solution.

Regards,
Steve

On 17.06.2018 21:11, Torben Keil wrote:
> Hi Steve,
> 
> I tried my luck with i2c... but I wasn't successful.
> There's a PCF8574 (Portextender) connected directly on the I2C interface
> of fl2k.
> ?
> Here's my code:
> 
> torben at Mworkstation: <mailto:torben at Mworkstation:>~/Amateurfunk/C++$ cat
> fl2k_i2c.cpp
> // g++ fl2k_i2c.cpp -L/home/torben/Amateurfunk/osmo-fl2k/build/src
> -I/home/torben/Amateurfunk/osmo-fl2k/include -losmo-fl2k -o fl2k-i2c_test
> #include "osmo-fl2k.h"
> #include <iostream>
> #include <bitset>
> 
> int main (int argc, char *argv[] ) {
> ????int status;
> ????fl2k_dev_t *dev = NULL;
> ????uint8_t i2c_addr = 0b01000001; ?// Letztes Bit: Read / #Write
> ????uint8_t reg_addr = 0;
> ????uint8_t *data = new uint8_t[10];
> ????uint32_t dev_index = 0;
> ????
> ????fl2k_open(&dev, (uint32_t)dev_index);
> ????????if (NULL == dev) {
> ????????????????std::cerr << "Failed to open fl2k device " << dev_index
> << std::endl;
> ????????????????return -1;
> ????????}
> 
> ????????for (i2c_addr=0; i2c_addr<128; i2c_addr++) {
> ????????status = fl2k_i2c_read(dev, i2c_addr, reg_addr, data);
> ????????if( status >= 0 ) {
> ????????????std::cout << "Adress: " << i2c_addr;
> ????????????std::cout << "; I2C-Status: " << status << "; Data: ";
> ????????????for( int i=0; i<static_cast<int>(status); i++) {
> ????????????????std::cout << " " << std::bitset<8>(data[i]);
> ????????????}
> ????????????std::cout << std::endl;
> ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
> ????????}
> ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
> ?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
> ????????data[0]=127;
> ????????for (i2c_addr=0; i2c_addr<128; i2c_addr++) {
> ????????????//fl2k_i2c_write(fl2k_dev_t *dev, uint8_t i2c_addr, uint8_t
> reg_addr, uint8_t *data);
> ????????????status = fl2k_i2c_write(dev, i2c_addr, 0, data);
> ????????????if( status >= 0 ) {
> ????????????????std::cout << "Write Adress: " << i2c_addr;
> ????????????????std::cout << "; I2C-Status: " << status << ?std::endl;
> ????????????} else {
> ????????????????std::cout << static_cast<int>(i2c_addr) << "\t";
> ????????????}
> ????????}
> ????}
> ????
> ????fl2k_close(dev);
> ????
> ????free(data);
> ????
> ????????return 0;
> ????
> }
> 
> Output of that program after a fresh reboot of the system:
> torben at Mworkstation:~/Amateurfunk/C++$ ./fl2k-i2c_test
> Kernel mass storage driver is attached, detaching driver. This may take
> more than 10 seconds!
> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
> 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
> 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74
> 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98
> 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116
> 117 118 119 120 121 122 123 124 125 126 127
> ?
> So there's nothing reachable via I2C.
> ?
> What am I doing wrong here?
> ?
> ?
> Greetings,
> Torben
> 
> 
> 
> Am 17.06.2018 03:18, schrieb Steve Markgraf:
>> Hi Torben,
>>
>> On 16.06.2018 09:40, Torben Keil wrote:
>>> do you have a git repository for the code so that I could have a try?
>>
>> I've debugged and cleaned up the I2C code and just pushed it.
>> I2C transfers with the FL2000 seem to fail from time to time, so make
>> sure to check the return code of fl2k_i2c_read()/fl2k_i2c_write().
>>
>> Regards,
>> Steve



From lucas at teske.com.br  Tue Jun 19 02:07:05 2018
From: lucas at teske.com.br (Lucas Teske)
Date: Mon, 18 Jun 2018 23:07:05 -0300
Subject: SpyServer support on gr-osmosdr
Message-ID: <f51a759d-cf62-4ce0-eb35-a69dc6ce8109@teske.com.br>

Hi all,

So I decided to add support for SpyServer in gr-osmosdr. It is currently
at a fork of mirrored in github: https://github.com/racerxdl/gr-osmosdr

What should be my next steps to get this to the official branch?


-- 
Lucas Teske
Teske Virtual System

GPG: BD29 7EF3 4CCB EB61 B790 06C3 351A 8000 DEAD CE11
GPG: 4A90 974B ACE0 A9A6 AF09 B3B1 6C39 C1C1 6A9D A7BE
GPG: BD09 9175 6DE8 37F4 08D3 B296 DE7A 51C3 87C9 27EE


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180618/e15bbb97/attachment.bin>

From dwmw2 at infradead.org  Thu Jun 28 15:43:24 2018
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 28 Jun 2018 16:43:24 +0100
Subject: [PATCH] Fix inline functions to use 'static inline'
Message-ID: <20180628154324.2582068-1-dwmw2@infradead.org>

With just 'inline', if the compiler decides not to inline them, it isn't
required to emit them at all. For some targets with -Os that is causing
build failures.

Perhaps we might consider using '__attribute__((always_inline))' for
GCC builds, but 'static inline' is a good start.
---
 src/rtl_adsb.c  | 8 ++++----
 src/rtl_power.c | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/rtl_adsb.c b/src/rtl_adsb.c
index 9087de4..7aea8dd 100644
--- a/src/rtl_adsb.c
+++ b/src/rtl_adsb.c
@@ -183,7 +183,7 @@ int magnitute(uint8_t *buf, int len)
 	return len/2;
 }
 
-inline uint16_t single_manchester(uint16_t a, uint16_t b, uint16_t c, uint16_t d)
+static inline uint16_t single_manchester(uint16_t a, uint16_t b, uint16_t c, uint16_t d)
 /* takes 4 consecutive real samples, return 0 or 1, BADSAMPLE on error */
 {
 	int bit, bit_p;
@@ -224,17 +224,17 @@ inline uint16_t single_manchester(uint16_t a, uint16_t b, uint16_t c, uint16_t d
 	return BADSAMPLE;
 }
 
-inline uint16_t min16(uint16_t a, uint16_t b)
+static inline uint16_t min16(uint16_t a, uint16_t b)
 {
 	return a<b ? a : b;
 }
 
-inline uint16_t max16(uint16_t a, uint16_t b)
+static inline uint16_t max16(uint16_t a, uint16_t b)
 {
 	return a>b ? a : b;
 }
 
-inline int preamble(uint16_t *buf, int i)
+static inline int preamble(uint16_t *buf, int i)
 /* returns 0/1 for preamble at index i */
 {
 	int i2;
diff --git a/src/rtl_power.c b/src/rtl_power.c
index 00f4d9f..625d818 100644
--- a/src/rtl_power.c
+++ b/src/rtl_power.c
@@ -250,7 +250,7 @@ void sine_table(int size)
 	}
 }
 
-inline int16_t FIX_MPY(int16_t a, int16_t b)
+static inline int16_t FIX_MPY(int16_t a, int16_t b)
 /* fixed point multiply and scale */
 {
 	int c = ((int)a * (int)b) >> 14;
-- 
2.17.1



From steve at steve-m.de  Thu Jun 28 18:29:34 2018
From: steve at steve-m.de (Steve Markgraf)
Date: Thu, 28 Jun 2018 20:29:34 +0200
Subject: [PATCH] Fix inline functions to use 'static inline'
In-Reply-To: <20180628154324.2582068-1-dwmw2@infradead.org>
References: <20180628154324.2582068-1-dwmw2@infradead.org>
Message-ID: <98b581eb-8ab9-7438-a085-472b0d7b35a1@steve-m.de>

Hi David,

On 28.06.2018 17:43, David Woodhouse wrote:
> With just 'inline', if the compiler decides not to inline them, it isn't
> required to emit them at all. For some targets with -Os that is causing
> build failures.

"It isn't required to emit them at all" - What the heck, which compiler
on earth does such horrible things?

I've taken at look at the C99 standard for the function specifier
'inline' and there is nothing that would justify such behaviour.

Of course, if that's a bug with a specific compiler version we can merge
that, but the explanation in the commit doesn't make any sense to me.

Regards,
Steve


From j-pi at seznam.cz  Thu Jun 28 18:50:43 2018
From: j-pi at seznam.cz (Pinky)
Date: Thu, 28 Jun 2018 20:50:43 +0200
Subject: [PATCH] Fix inline functions to use 'static inline'
In-Reply-To: <98b581eb-8ab9-7438-a085-472b0d7b35a1@steve-m.de>
References: <20180628154324.2582068-1-dwmw2@infradead.org>
 <98b581eb-8ab9-7438-a085-472b0d7b35a1@steve-m.de>
Message-ID: <20180628185042.i6mhzjgm7givzopa@zizala>

Hi all,

althought the argument about compiller is a bit strange the change is in
my opinion in right course. If the goal is to use those functions only in this
one particular .c file and not elsewhere, the good practice is to
limit scope by using static.

Can You please let us know how to reproduce behaviour You have
described?

with best regards,
    Pinky.


* Steve Markgraf <steve at steve-m.de> [2018-06-28 20:29:34 +0200]:

>Hi David,
>
>On 28.06.2018 17:43, David Woodhouse wrote:
>> With just 'inline', if the compiler decides not to inline them, it isn't
>> required to emit them at all. For some targets with -Os that is causing
>> build failures.
>
>"It isn't required to emit them at all" - What the heck, which compiler
>on earth does such horrible things?
>
>I've taken at look at the C99 standard for the function specifier
>'inline' and there is nothing that would justify such behaviour.
>
>Of course, if that's a bug with a specific compiler version we can merge
>that, but the explanation in the commit doesn't make any sense to me.
>
>Regards,
>Steve


From mardnh at gmx.de  Thu Jun 28 21:08:56 2018
From: mardnh at gmx.de (Martin Hauke)
Date: Thu, 28 Jun 2018 23:08:56 +0200
Subject: [PATCH] CMake: Replace deprecated qt5_use_modules macro
Message-ID: <20180628210856.17408-1-mardnh@gmx.de>

qt5_use_modules has been marked as deprecated since a while and is
finally removed in Qt 5.11

Change-Id: I5ac81b654d248028bccf48ba0cfd0c11ff9409e1
---
 CMakeLists.txt                               | 14 ++++++++------
 plugins/channel/nfm/CMakeLists.txt           |  6 ++++--
 plugins/channel/tcpsrc/CMakeLists.txt        |  6 ++++--
 plugins/channel/tetra/CMakeLists.txt         |  6 ++++--
 plugins/samplesource/gnuradio/CMakeLists.txt |  6 ++++--
 plugins/samplesource/osmosdr/CMakeLists.txt  |  6 ++++--
 plugins/samplesource/rtlsdr/CMakeLists.txt   |  6 ++++--
 7 files changed, 32 insertions(+), 18 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 72ce30e..b5a264b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,4 +1,4 @@
-cmake_minimum_required(VERSION 2.8.9)
+cmake_minimum_required(VERSION 2.8.11)
 list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/Modules)
 
 project(sdrangelove)
@@ -14,7 +14,7 @@ set(CMAKE_AUTOMOC ON)
 find_package(Qt5Core 5.0 REQUIRED)
 find_package(Qt5Widgets 5.0 REQUIRED)
 find_package(Qt5Multimedia 5.0 REQUIRED)
-#find_package(QT5OpenGL 5.0 REQUIRED)
+find_package(Qt5OpenGL 5.0 REQUIRED)
 find_package(OpenGL REQUIRED)
 find_package(PkgConfig)
 
@@ -245,6 +245,10 @@ add_library(sdrbase SHARED
 )
 
 target_link_libraries(sdrbase
+	Qt5::Core
+	Qt5::Widgets
+	Qt5::OpenGL
+	Qt5::Multimedia
 	${QT_LIBRARIES}
 	${OPENGL_LIBRARIES}
 	${LIBUSB_LIBRARIES}
@@ -260,8 +264,6 @@ endif(LIBFFTS_FOUND)
 
 set_target_properties(sdrbase PROPERTIES DEFINE_SYMBOL "sdrangelove_EXPORTS")
 
-qt5_use_modules(sdrbase Core Widgets OpenGL Multimedia)
-
 include_directories(
 	${CMAKE_CURRENT_BINARY_DIR}
 	${CMAKE_SOURCE_DIR}/include
@@ -304,6 +306,8 @@ add_executable(sdrangelove
 
 target_link_libraries(sdrangelove
 	sdrbase
+	Qt5::Widgets
+	Qt5::Multimedia
 	${QT_LIBRARIES}
 	${OPENGL_LIBRARIES}
 )
@@ -317,8 +321,6 @@ if(WIN32)
 	set_target_properties(sdrangelove PROPERTIES LINK_FLAGS_MINSIZEREL "/SUBSYSTEM:windows /ENTRY:mainCRTStartup")
 endif(WIN32)
 
-qt5_use_modules(sdrangelove Widgets Multimedia)
-
 ##############################################################################
 
 add_subdirectory(plugins)
diff --git a/plugins/channel/nfm/CMakeLists.txt b/plugins/channel/nfm/CMakeLists.txt
index feeb891..a39931e 100644
--- a/plugins/channel/nfm/CMakeLists.txt
+++ b/plugins/channel/nfm/CMakeLists.txt
@@ -39,9 +39,11 @@ add_library(demodnfm SHARED
 )
 
 target_link_libraries(demodnfm
+	Qt5::Core
+	Qt5::Widgets
+	Qt5::OpenGL
+	Qt5::Network
 	${QT_LIBRARIES}
 	${OPENGL_LIBRARIES}
 	sdrbase
 )
-
-qt5_use_modules(demodnfm Core Widgets OpenGL Multimedia)
\ No newline at end of file
diff --git a/plugins/channel/tcpsrc/CMakeLists.txt b/plugins/channel/tcpsrc/CMakeLists.txt
index df7c4d4..86d8426 100644
--- a/plugins/channel/tcpsrc/CMakeLists.txt
+++ b/plugins/channel/tcpsrc/CMakeLists.txt
@@ -39,9 +39,11 @@ add_library(demodtcpsrc SHARED
 )
 
 target_link_libraries(demodtcpsrc
+	Qt5::Core
+	Qt5::Widgets
+	Qt5::OpenGL
+	Qt5::Network
 	${QT_LIBRARIES}
 	${OPENGL_LIBRARIES}
 	sdrbase
 )
-
-qt5_use_modules(demodtcpsrc Core Widgets OpenGL Network)
diff --git a/plugins/channel/tetra/CMakeLists.txt b/plugins/channel/tetra/CMakeLists.txt
index f46c2bb..9da7aa4 100644
--- a/plugins/channel/tetra/CMakeLists.txt
+++ b/plugins/channel/tetra/CMakeLists.txt
@@ -39,9 +39,11 @@ add_library(demodtetra SHARED
 )
 
 target_link_libraries(demodtetra
+	Qt5::Core
+	Qt5::Widgets
+	Qt5::OpenGL
+	Qt5::Network
 	${QT_LIBRARIES}
 	${OPENGL_LIBRARIES}
 	sdrbase
 )
-
-qt5_use_modules(demodtetra Core Widgets OpenGL Multimedia)
diff --git a/plugins/samplesource/gnuradio/CMakeLists.txt b/plugins/samplesource/gnuradio/CMakeLists.txt
index 0e08608..c5c3300 100644
--- a/plugins/samplesource/gnuradio/CMakeLists.txt
+++ b/plugins/samplesource/gnuradio/CMakeLists.txt
@@ -75,6 +75,10 @@ add_library(inputgnuradio SHARED
 )
 
 target_link_libraries(inputgnuradio
+	Qt5::Core
+	Qt5::Widgets
+	Qt5::OpenGL
+	Qt5::Network
 	${QT_LIBRARIES}
 	${Boost_LIBRARIES}
 	${GNURADIO_RUNTIME_LIBRARIES}
@@ -82,6 +86,4 @@ target_link_libraries(inputgnuradio
 	sdrbase
 )
 
-qt5_use_modules(inputgnuradio Core Widgets OpenGL Multimedia)
-
 endif(Boost_FOUND AND GNURADIO_RUNTIME_FOUND AND GNURADIO_OSMOSDR_FOUND)
diff --git a/plugins/samplesource/osmosdr/CMakeLists.txt b/plugins/samplesource/osmosdr/CMakeLists.txt
index 9dc9705..10f3cc9 100644
--- a/plugins/samplesource/osmosdr/CMakeLists.txt
+++ b/plugins/samplesource/osmosdr/CMakeLists.txt
@@ -45,10 +45,12 @@ add_library(inputosmosdr SHARED
 )
 
 target_link_libraries(inputosmosdr
+	Qt5::Core
+	Qt5::Widgets
+	Qt5::OpenGL
+	Qt5::Network
 	${QT_LIBRARIES}
 	${LIBOSMOSDR_LIBRARIES}
 	${LIBUSB_LIBRARIES}
 	sdrbase
 )
-
-qt5_use_modules(inputosmosdr Core Widgets OpenGL Multimedia)
diff --git a/plugins/samplesource/rtlsdr/CMakeLists.txt b/plugins/samplesource/rtlsdr/CMakeLists.txt
index 35c4081..fa9a53a 100644
--- a/plugins/samplesource/rtlsdr/CMakeLists.txt
+++ b/plugins/samplesource/rtlsdr/CMakeLists.txt
@@ -41,10 +41,12 @@ add_library(inputrtlsdr SHARED
 )
 
 target_link_libraries(inputrtlsdr
+	Qt5::Core
+	Qt5::Widgets
+	Qt5::OpenGL
+	Qt5::Network
 	${QT_LIBRARIES}
 	${LIBRTLSDR_LIBRARIES}
 	${LIBUSB_LIBRARIES}
 	sdrbase
 )
-
-qt5_use_modules(inputrtlsdr Core Widgets OpenGL Multimedia)
-- 
2.13.7



From mueller at kit.edu  Fri Jun 29 08:25:01 2018
From: mueller at kit.edu (=?utf-8?B?TcO8bGxlciwgTWFyY3VzIChDRUwp?=)
Date: Fri, 29 Jun 2018 08:25:01 +0000
Subject: [PATCH] Fix inline functions to use 'static inline'
In-Reply-To: <20180628185042.i6mhzjgm7givzopa@zizala>
References: <20180628154324.2582068-1-dwmw2@infradead.org>
 <98b581eb-8ab9-7438-a085-472b0d7b35a1@steve-m.de>
 <20180628185042.i6mhzjgm7givzopa@zizala>
Message-ID: <1530260699.3372.652.camel@kit.edu>

Hi David, Pinky, Steve and all,

I'd agree with "uh, I need to know where this goes wrong please, I'm
scared". I'd also agree, an inlined function should probably have
compilation unit scope, anyway, so `static` would be appropriate.

I've taken a look at the patched function declarations and would
recommend to just remove `min16` and `max16` alltogether (only used in
a comment, and frankly, not that great a function `(a<>b?a:b)`). 

I'd really like to know the compile error! Maybe there's actually
something we can do ? simply because this really *shouldn't* fail,
imho.

Best regards,
Marcus

On Thu, 2018-06-28 at 20:50 +0200, Pinky wrote:
> Hi all,
> 
> althought the argument about compiller is a bit strange the change is
> in
> my opinion in right course. If the goal is to use those functions
> only in this
> one particular .c file and not elsewhere, the good practice is to
> limit scope by using static.
> 
> Can You please let us know how to reproduce behaviour You have
> described?
> 
> with best regards,
>     Pinky.
> 
> 
> * Steve Markgraf <steve at steve-m.de> [2018-06-28 20:29:34 +0200]:
> 
> > Hi David,
> > 
> > On 28.06.2018 17:43, David Woodhouse wrote:
> > > With just 'inline', if the compiler decides not to inline them,
> > > it isn't
> > > required to emit them at all. For some targets with -Os that is
> > > causing
> > > build failures.
> > 
> > "It isn't required to emit them at all" - What the heck, which
> > compiler
> > on earth does such horrible things?
> > 
> > I've taken at look at the C99 standard for the function specifier
> > 'inline' and there is nothing that would justify such behaviour.
> > 
> > Of course, if that's a bug with a specific compiler version we can
> > merge
> > that, but the explanation in the commit doesn't make any sense to
> > me.
> > 
> > Regards,
> > Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6582 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180629/864b74fb/attachment.bin>

From dwmw2 at infradead.org  Fri Jun 29 08:34:38 2018
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 29 Jun 2018 09:34:38 +0100
Subject: [PATCH] Fix inline functions to use 'static inline'
In-Reply-To: <98b581eb-8ab9-7438-a085-472b0d7b35a1@steve-m.de>
References: <20180628154324.2582068-1-dwmw2@infradead.org>
 <98b581eb-8ab9-7438-a085-472b0d7b35a1@steve-m.de>
Message-ID: <1530261278.8792.171.camel@infradead.org>



On Thu, 2018-06-28 at 20:29 +0200, Steve Markgraf wrote:
> Hi David,
> 
> On 28.06.2018 17:43, David Woodhouse wrote:
> > 
> > With just 'inline', if the compiler decides not to inline them, it isn't
> > required to emit them at all. For some targets with -Os that is causing
> > build failures.
>
> "It isn't required to emit them at all" - What the heck, which compiler
> on earth does such horrible things?
> 
> I've taken at look at the C99 standard for the function specifier
> 'inline' and there is nothing that would justify such behaviour.

Yeah, you're probably right. My initial reading of the docs was a
little hasty and mostly based on the assumption (haha) that GCC would
be doing the right thing for something like this, given all the churn
that went on some years ago with static/extern inline handling.

This was seen in the OpenWRT build.
https://github.com/openwrt/packages/pull/6377

Of course, I question whether we should be building rtl-sdr with -O0 or
-Os and eschewing inlining... that does seem a bit daft for this
*particular* piece of software even if the general policy of the
OpenWRT is to reduce size. But that's a separate discussion, really.
?
> Of course, if that's a bug with a specific compiler version we can merge
> that, but the explanation in the commit doesn't make any sense to me.

Agreed.

Here's another example FWIW:

 $ cat foo.c

inline int foo(int a)
{
	return a+1;
}

int bar(int a)
{
	return foo(a);
}
 $ gcc -O0 -o- -S foo.c
	.file	"foo.c"
	.text
	.globl	bar
	.type	bar, @function
bar:
.LFB1:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register 6
	subq	$16, %rsp
	movl	%edi, -4(%rbp)
	movl	-4(%rbp), %eax
	movl	%eax, %edi
	call	foo
	leave
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc
.LFE1:
	.size	bar, .-bar
	.ident	"GCC: (GNU) 8.1.1 20180502 (Red Hat 8.1.1-1)"
	.section	.note.GNU-stack,"", at progbits
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180629/b5285105/attachment.bin>

From dwmw2 at infradead.org  Fri Jun 29 09:11:52 2018
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 29 Jun 2018 10:11:52 +0100
Subject: [PATCH] Fix inline functions to use 'static inline'
In-Reply-To: <1530260699.3372.652.camel@kit.edu>
References: <20180628154324.2582068-1-dwmw2@infradead.org>
 <98b581eb-8ab9-7438-a085-472b0d7b35a1@steve-m.de>
 <20180628185042.i6mhzjgm7givzopa@zizala>
 <1530260699.3372.652.camel@kit.edu>
Message-ID: <1530263512.8792.181.camel@infradead.org>

On Fri, 2018-06-29 at 08:25 +0000, M?ller, Marcus (CEL) wrote:
> Hi David, Pinky, Steve and all,
> 
> I'd agree with "uh, I need to know where this goes wrong please, I'm
> scared".

GCC just fails to emit the offending functions and then the link fails:
?
[ 36%] Linking C executable rtl_power
CMakeFiles/rtl_power.dir/rtl_power.c.o: In function `fix_fft':
rtl_power.c:(.text+0x41a): undefined reference to `FIX_MPY'
rtl_power.c:(.text+0x445): undefined reference to `FIX_MPY'
rtl_power.c:(.text+0x476): undefined reference to `FIX_MPY'
rtl_power.c:(.text+0x49d): undefined reference to `FIX_MPY'
collect2: error: ld returned 1 exit status

You should be able to reproduce this really easily by building with
-O0.

Admittedly it's fairly bloody stupid to use -O0 for rtl-sdr but for the
MIPS target this was even happening with -Os, which is slightly saner.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180629/feec169d/attachment.bin>

From dwmw2 at infradead.org  Fri Jun 29 09:40:20 2018
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 29 Jun 2018 10:40:20 +0100
Subject: [PATCH] Fix inline functions to use 'static inline'
In-Reply-To: <98b581eb-8ab9-7438-a085-472b0d7b35a1@steve-m.de>
References: <20180628154324.2582068-1-dwmw2@infradead.org>
 <98b581eb-8ab9-7438-a085-472b0d7b35a1@steve-m.de>
Message-ID: <1530265220.8792.183.camel@infradead.org>



On Thu, 2018-06-28 at 20:29 +0200, Steve Markgraf wrote:
> Hi David,
> 
> On 28.06.2018 17:43, David Woodhouse wrote:
> > 
> > With just 'inline', if the compiler decides not to inline them, it isn't
> > required to emit them at all. For some targets with -Os that is causing
> > build failures.
>
> "It isn't required to emit them at all" - What the heck, which compiler
> on earth does such horrible things?
> 
> I've taken at look at the C99 standard for the function specifier
> 'inline' and there is nothing that would justify such behaviour.
> 
> Of course, if that's a bug with a specific compiler version we can merge
> that, but the explanation in the commit doesn't make any sense to me.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86360
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180629/9e91a411/attachment.bin>

From mueller at kit.edu  Fri Jun 29 14:56:50 2018
From: mueller at kit.edu (=?utf-8?B?TcO8bGxlciwgTWFyY3VzIChDRUwp?=)
Date: Fri, 29 Jun 2018 14:56:50 +0000
Subject: [PATCH] Fix inline functions to use 'static inline'
In-Reply-To: <1530263512.8792.181.camel@infradead.org>
References: <20180628154324.2582068-1-dwmw2@infradead.org>
 <98b581eb-8ab9-7438-a085-472b0d7b35a1@steve-m.de>
 <20180628185042.i6mhzjgm7givzopa@zizala>
 <1530260699.3372.652.camel@kit.edu>
 <1530263512.8792.181.camel@infradead.org>
Message-ID: <1530284210.17663.151.camel@kit.edu>

True, can reproduce. Reading the issue and the linked "differences in
C99" page, this all makes sense.

Thanks for enlightening me!

Best regards,
Marcus

On Fri, 2018-06-29 at 10:11 +0100, David Woodhouse wrote:
> On Fri, 2018-06-29 at 08:25 +0000, M?ller, Marcus (CEL) wrote:
> > Hi David, Pinky, Steve and all,
> > 
> > I'd agree with "uh, I need to know where this goes wrong please, I'm
> > scared".
> 
> GCC just fails to emit the offending functions and then the link fails:
>  
> [ 36%] Linking C executable rtl_power
> CMakeFiles/rtl_power.dir/rtl_power.c.o: In function `fix_fft':
> rtl_power.c:(.text+0x41a): undefined reference to `FIX_MPY'
> rtl_power.c:(.text+0x445): undefined reference to `FIX_MPY'
> rtl_power.c:(.text+0x476): undefined reference to `FIX_MPY'
> rtl_power.c:(.text+0x49d): undefined reference to `FIX_MPY'
> collect2: error: ld returned 1 exit status
> 
> You should be able to reproduce this really easily by building with
> -O0.
> 
> Admittedly it's fairly bloody stupid to use -O0 for rtl-sdr but for the
> MIPS target this was even happening with -Os, which is slightly saner.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6582 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180629/21b9e6f4/attachment.bin>

From maxime.vince at gmail.com  Mon Jun 18 06:33:59 2018
From: maxime.vince at gmail.com (Maxime Vincent)
Date: Mon, 18 Jun 2018 08:33:59 +0200
Subject: [patch] fix compilation with boost 1.67
In-Reply-To: <a494df14-971c-166a-1bec-c3beb62622c1@steve-m.de>
References: <CACBz148UwKxM=0wV06cX7nonN2VgDx3C+eYJhuZJBiBkELgJ2g@mail.gmail.com>
 <a494df14-971c-166a-1bec-c3beb62622c1@steve-m.de>
Message-ID: <CACBz149A8gqFnD5U-6_RokwWpQrVbXMwZor2ZX55nQfhSAGtbg@mail.gmail.com>

That's great. Thanks!


Op zo 17 jun. 2018 om 18:02 schreef Steve Markgraf <steve at steve-m.de>:

> Hi Maxime,
>
> On 10.06.2018 12:22, Maxime Vincent wrote:
> > I have created a small pull request to fix compilation with boost-1.67.
>
> Thanks for the patch, I've merged it. I've successfully built with
> boost-1.65, so older version still seem to work.
>
> Regards,
> Steve
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20180618/a977a45d/attachment.htm>

From frank_lists at superlogical.ch  Sat Jun 30 15:30:20 2018
From: frank_lists at superlogical.ch (Frank Werner-Krippendorf)
Date: Sat, 30 Jun 2018 17:30:20 +0200
Subject: [PATCH] SDRPlay API breaking changes & support recent hardware / API
 v2.13+
Message-ID: <5c233c96-5640-c745-8a7c-939f1ebb282e@superlogical.ch>

The current NONFREE SDRplay class is unusable with recent APIs, too many 
breaking API changes.
This patch is tested with the current up-to-date API V2.13

diff --git a/lib/sdrplay/sdrplay_source_c.cc 
b/lib/sdrplay/sdrplay_source_c.cc
index 9a9ee40..6f20d5f 100644
--- a/lib/sdrplay/sdrplay_source_c.cc
+++ b/lib/sdrplay/sdrplay_source_c.cc
@@ -1,9 +1,12 @@
 ?/* -*- c++ -*- */
 ?/*
+ * Copyright 2018 Frank Werner-Krippendorf <mail at hb9fxq.ch>
+ * Copyright 2018 Jeff Long <willcode4 at gmail.com>
 ? * Copyright 2015 SDRplay Ltd <support at sdrplay.com>
 ? * Copyright 2012 Dimitri Stolnikov <horiz0n at gmx.net>
 ? * Copyright 2012 Steve Markgraf <steve at steve-m.de>
 ? *
+ *
 ? * GNU Radio is free software; you can redistribute it and/or modify
 ? * it under the terms of the GNU General Public License as published by
 ? * the Free Software Foundation; either version 3, or (at your option)
@@ -32,179 +35,159 @@
 ?#include "sdrplay_source_c.h"
 ?#include <gnuradio/io_signature.h>
 ?#include "osmosdr/source.h"
+#include "arg_helpers.h"

 ?#include <boost/assign.hpp>
 ?#include <boost/format.hpp>
+#include <boost/thread/mutex.hpp>
+#include <boost/thread/condition_variable.hpp>
+#include <boost/chrono.hpp>

-#include <stdexcept>
 ?#include <iostream>
-#include <stdio.h>
-#include <math.h>
-
-#include <mirsdrapi-rsp.h>
-
-#include "arg_helpers.h"
+#include <mutex>

 ?#define MAX_SUPPORTED_DEVICES?? 4

-struct sdrplay_dev
-{
-?? int gRdB;
-?? double gain_dB;
-?? double fsHz;
-?? double rfHz;
-?? mir_sdr_Bw_MHzT bwType;
-?? mir_sdr_If_kHzT ifType;
-?? int samplesPerPacket;
-?? int maxGain;
-?? int minGain;
-?? int dcMode;
-};
-
 ?using namespace boost::assign;

-#define BYTES_PER_SAMPLE? 4 // sdrplay device delivers 16 bit signed IQ 
data
-??????????????????????????? // containing 12 bits of information
+// Index by mir_sdr_Bw_MHzT
+static std::vector<double> bandwidths = {
+? 0,???? // Dummy
+? 200e3,
+? 300e3,
+? 600e3,
+? 1536e3,
+? 5000e3,
+? 6000e3,
+? 7000e3,
+? 8000e3
+};

-#define SDRPLAY_AM_MIN???? 150e3
-#define SDRPLAY_AM_MAX????? 30e6
-#define SDRPLAY_FM_MIN????? 64e6
-#define SDRPLAY_FM_MAX???? 108e6
-#define SDRPLAY_B3_MIN???? 162e6
-#define SDRPLAY_B3_MAX???? 240e6
-#define SDRPLAY_B45_MIN??? 470e6
-#define SDRPLAY_B45_MAX??? 960e6
-#define SDRPLAY_L_MIN???? 1450e6
-#define SDRPLAY_L_MAX???? 1675e6
+// TODO - RSP1 lower freq is 10e3.
+#define SDRPLAY_FREQ_MIN 1e3
+#define SDRPLAY_FREQ_MAX 2000e6

-#define SDRPLAY_MAX_BUF_SIZE 504
+static std::string hwName(int hwVer)
+{
+? if (hwVer == 1)
+??? return "RSP1";
+? if (hwVer == 2)
+??? return "RSP2";
+? if (hwVer == 255)
+??? return "RSP1A";
+? if (hwVer == 3)
+??? return "RSPduo";
+? return "UNK";
+}

-/*
- * Create a new instance of sdrplay_source_c and return
- * a boost shared_ptr.? This is effectively the public constructor.
- */
 ?sdrplay_source_c_sptr
 ?make_sdrplay_source_c (const std::string &args)
 ?{
 ?? return gnuradio::get_initial_sptr(new sdrplay_source_c (args));
 ?}

-/*
- * Specify constraints on number of input and output streams.
- * This info is used to construct the input and output signatures
- * (2nd & 3rd args to gr::block's constructor).? The input and
- * output signatures are used by the runtime system to
- * check that a valid number and type of inputs and outputs
- * are connected to this block.? In this case, we accept
- * only 0 input and 1 output.
- */
-static const int MIN_IN = 0;??? // mininum number of input streams
-static const int MAX_IN = 0;??? // maximum number of input streams
-static const int MIN_OUT = 1;??? // minimum number of output streams
-static const int MAX_OUT = 1;??? // maximum number of output streams
+// 0 inputs, 1 output
+static const int MIN_IN = 0;
+static const int MAX_IN = 0;
+static const int MIN_OUT = 1;
+static const int MAX_OUT = 1;

-/*
- * The private constructor
- */
 ?sdrplay_source_c::sdrplay_source_c (const std::string &args)
 ?? : gr::sync_block ("sdrplay_source_c",
 ???????? gr::io_signature::make(MIN_IN, MAX_IN, sizeof (gr_complex)),
 ???????? gr::io_signature::make(MIN_OUT, MAX_OUT, sizeof (gr_complex))),
-??? _running(false),
-??? _uninit(false),
-??? _auto_gain(false)
-{
-?? _dev = (sdrplay_dev_t *)malloc(sizeof(sdrplay_dev_t));
-?? if (_dev == NULL)
-?? {
-????? return;
-}
-?? _dev->fsHz = 2048e3;
-?? _dev->rfHz = 200e6;
-?? _dev->bwType = mir_sdr_BW_1_536;
-?? _dev->ifType = mir_sdr_IF_Zero;
-?? _dev->samplesPerPacket = 0;
-?? _dev->dcMode = 0;
-?? _dev->gRdB = 60;
-?? set_gain_limits(_dev->rfHz);
-?? _dev->gain_dB = _dev->maxGain - _dev->gRdB;
+? _auto_gain(true),
+? _gRdB(40),
+? _lna(0),
+? _bcastNotch(0),
+? _dabNotch(0),
+? _fsHz(2e6),
+? _decim(1),
+? _rfHz(100e6),
+? _bwType(mir_sdr_BW_1_536),
+? _ifType(mir_sdr_IF_Zero),
+? _loMode(mir_sdr_LO_Auto),
+? _dcMode(true),
+? _iqMode(true),
+? _buffer(NULL),
+? _streaming(false),
+? _flowgraphRunning(false),
+? _reinit(false)
+{
+? dict_t dict = params_to_dict(args);
+? if (dict.count("sdrplay")) {
+??? _devIndex = boost::lexical_cast<unsigned int>(dict["sdrplay"]);
+? }
+? else {
+??? _devIndex = 0;
+? }
+
+? unsigned int numDevices;
+? mir_sdr_DeviceT mirDevices[MAX_SUPPORTED_DEVICES];
+? mir_sdr_GetDevices(mirDevices, &numDevices, MAX_SUPPORTED_DEVICES);
+? if (((_devIndex+1 > numDevices) || !mirDevices[_devIndex].devAvail)) {
+??? std::cerr << "Failed to open SDRplay device " + 
std::to_string(_devIndex) << std::endl;
+??? throw std::runtime_error("Failed to open SDRplay device " + 
std::to_string(_devIndex));
+? }
+
+? for (int i; i < numDevices; i++) {
+??? std::cerr << "RSP devIndex: [" << i << "] hwVer: " << 
hwName(mirDevices[i].hwVer) << " SerNo: " << mirDevices[i].SerNo
+?????????????? << std::endl;;
+? }
+
+? _hwVer = mirDevices[_devIndex].hwVer;
+
+? int debug = 0;
+? if (dict.count("debug") && (boost::lexical_cast<int>(dict["debug"]) 
!= 0))
+??? debug = 1;
+? mir_sdr_DebugEnable(debug);
+
+? if (_hwVer == 2) {
+??? _antenna = "A";
+}
+? else {
+??? _antenna = "RX";
+? }

-?? _bufi.reserve(SDRPLAY_MAX_BUF_SIZE);
-?? _bufq.reserve(SDRPLAY_MAX_BUF_SIZE);
-
-?? _buf_mutex.lock();
-?? _buf_offset = 0;
-?? _buf_mutex.unlock();
+? // bias=[0|1] to turn [off|on] bias tee. Default is off.
+? _biasT = 0;
+? if (dict.count("bias")) {
+??? _biasT = boost::lexical_cast<int>(dict["bias"]);
+? }
+
+? // lo=[120|144|168] to set first LO to 120/144/168 MHz. Default is Auto.
+? if (dict.count("lo")) {
+??? int loMode = boost::lexical_cast<int>(dict["lo"]);
+??? if (loMode == 120)
+????? _loMode = mir_sdr_LO_120MHz;
+??? else if (loMode == 144)
+????? _loMode = mir_sdr_LO_144MHz;
+??? else if (loMode == 168)
+????? _loMode = mir_sdr_LO_168MHz;
+? }
 ?}

-/*
- * Our virtual destructor.
- */
 ?sdrplay_source_c::~sdrplay_source_c ()
 ?{
-?? free(_dev);
-?? _dev = NULL;
-?? _buf_mutex.lock();
-?? if (_running)
-?? {
-????? _running = false;
+? if (_streaming) {
+??? stopStreaming();
 ??? }
-?? _uninit = true;
-?? _buf_mutex.unlock();
 ?}

-void sdrplay_source_c::reinit_device()
-{
-?? std::cerr << "reinit_device started" << std::endl;
-?? _buf_mutex.lock();
-?? std::cerr << "after mutex.lock" << std::endl;
-?? if (_running)
-?? {
-????? std::cerr << "mir_sdr_Uninit started" << std::endl;
-????? mir_sdr_Uninit();
-?? }
-
-?? std::cerr << "mir_sdr_Init started" << std::endl;
-?? mir_sdr_Init(_dev->gRdB, _dev->fsHz / 1e6, _dev->rfHz / 1e6, 
_dev->bwType, _dev->ifType, &_dev->samplesPerPacket);
-
-?? if (_dev->dcMode)
+bool sdrplay_source_c::start(void)
 ??? {
-????? std::cerr << "mir_sdr_SetDcMode started" << std::endl;
-????? mir_sdr_SetDcMode(4, 1);
-?? }
-
-?? _buf_offset = 0;
-?? _buf_mutex.unlock();
-?? std::cerr << "reinit_device end" << std::endl;
+? boost::mutex::scoped_lock lock(_bufferMutex);
+? _flowgraphRunning = true;
+? return true;
 ?}

-void sdrplay_source_c::set_gain_limits(double freq)
+bool sdrplay_source_c::stop(void)
 ?{
-?? if (freq <= SDRPLAY_AM_MAX)
-?? {
-????? _dev->minGain = -4;
-????? _dev->maxGain = 98;
-?? }
-?? else if (freq <= SDRPLAY_FM_MAX)
-?? {
-????? _dev->minGain = 1;
-????? _dev->maxGain = 103;
-?? }
-?? else if (freq <= SDRPLAY_B3_MAX)
-?? {
-????? _dev->minGain = 5;
-????? _dev->maxGain = 107;
-?? }
-?? else if (freq <= SDRPLAY_B45_MAX)
-?? {
-????? _dev->minGain = 9;
-????? _dev->maxGain = 94;
-?? }
-?? else if (freq <= SDRPLAY_L_MAX)
-?? {
-????? _dev->minGain = 24;
-????? _dev->maxGain = 105;
-?? }
+? boost::mutex::scoped_lock lock(_bufferMutex);
+? _flowgraphRunning = false;
+? // FG may be modified, so assume copied pointer is invalid
+? _buffer = NULL;
+? return true;
 ?}

 ?int sdrplay_source_c::work( int noutput_items,
@@ -212,186 +195,311 @@ int sdrplay_source_c::work( int noutput_items,
 ???????????????????????????? gr_vector_void_star &output_items )
 ?{
 ??? gr_complex *out = (gr_complex *)output_items[0];
-?? int cnt = noutput_items;
-?? unsigned int sampNum;
-?? int grChanged;
-?? int rfChanged;
-?? int fsChanged;

-?? if (_uninit)
-?? {
-????? return WORK_DONE;
-?? }
+? if (!_streaming)
+??? startStreaming();

-?? if (!_running)
 ??? {
-????? reinit_device();
-????? _running = true;
+??? boost::mutex::scoped_lock lock(_bufferMutex);
+??? _buffer = out;
+??? _bufferSpaceRemaining = noutput_items;
+??? _bufferOffset = 0;
+??? _bufferReady.notify_one();
+
+??? while (_buffer && _streaming) {
+????? _bufferReady.wait(lock);
+??? }
+? }
+
+? if (!_streaming) {
+??? return 0;
 ??? }

-?? _buf_mutex.lock();
+? return noutput_items - _bufferSpaceRemaining;
+}

-?? if (_buf_offset)
+// Called by sdrplay streamer thread when data is available
+void sdrplay_source_c::streamCallback(short *xi, short *xq,
+????????????????????????????????????? unsigned int firstSampleNum,
+????????????????????????????????????? int grChanged, int rfChanged, int 
fsChanged,
+????????????????????????????????????? unsigned int numSamples, unsigned 
int reset)
 ??? {
-????? for (int i = _buf_offset; i < _dev->samplesPerPacket; i++)
-????? {
-???????? *out++ = gr_complex( float(_bufi[i]) * (1.0f/2048.0f), 
float(_bufq[i]) * (1.0f/2048.0f) );
-????? }
-????? cnt -= (_dev->samplesPerPacket - _buf_offset);
-?? }
+? unsigned int i = 0;
+? _reinit = false;

-?? while ((cnt - _dev->samplesPerPacket) >= 0)
-?? {
-????? mir_sdr_ReadPacket(_bufi.data(), _bufq.data(), &sampNum, 
&grChanged, &rfChanged, &fsChanged);
-????? for (int i = 0; i < _dev->samplesPerPacket; i++)
-????? {
-???????? *out++ = gr_complex( float(_bufi[i]) * (1.0f/2048.0f), 
float(_bufq[i]) * (1.0f/2048.0f) );
-????? }
-????? cnt -= _dev->samplesPerPacket;
-?? }
+? boost::mutex::scoped_lock lock(_bufferMutex);

-?? _buf_offset = 0;
-?? if (cnt)
-?? {
-????? mir_sdr_ReadPacket(_bufi.data(), _bufq.data(), &sampNum, 
&grChanged, &rfChanged, &fsChanged);
-????? for (int i = 0; i < cnt; i++)
-????? {
-???????? *out++ = gr_complex( float(_bufi[i]) * (1.0f/2048.0f), 
float(_bufq[i]) * (1.0f/2048.0f) );
-????? }
-????? _buf_offset = cnt;
+? while (i < numSamples) {
+
+??? // Discard samples if not streaming, if flowgraph not running, or 
reinit needed.
+??? if (!_streaming || _reinit || !_flowgraphRunning)
+????? return;
+
+??? // While buffer is not ready for write, wait a short time.
+??? while (!_buffer) {
+????? if (boost::cv_status::timeout ==
+????????? _bufferReady.wait_for(lock, boost::chrono::milliseconds(250)))
+??????? return;
+??? }
+
+??? // Copy until out of samples or buffer is full
+??? while ((i < numSamples) && (_bufferSpaceRemaining > 0)) {
+????? _buffer[_bufferOffset] =
+??????? gr_complex(float(xi[i]) / 32768.0, float(xq[i]) / 32768.0);
+
+????? i++;
+????? _bufferOffset++;
+????? _bufferSpaceRemaining--;
 ??? }
-?? _buf_mutex.unlock();

-?? return noutput_items;
+??? if (_bufferSpaceRemaining == 0) {
+????? _buffer = NULL;
+????? _bufferReady.notify_one();
+??? }
+? }
+}
+
+// Callback wrapper
+void sdrplay_source_c::streamCallbackWrap(short *xi, short *xq,
+????????????????????????????????????????? unsigned int firstSampleNum,
+????????????????????????????????????????? int grChanged, int rfChanged, 
int fsChanged,
+????????????????????????????????????????? unsigned int numSamples, 
unsigned int reset, unsigned int hwRemoved,
+????????????????????????????????????????? void *cbContext)
+{
+? sdrplay_source_c *obj = (sdrplay_source_c *)cbContext;
+? obj->streamCallback(xi, xq,
+????????????????????? firstSampleNum,
+????????????????????? grChanged, rfChanged, fsChanged,
+????????????????????? numSamples, reset);
+}
+
+// Called by strplay streamer thread when gain reduction is changed.
+void sdrplay_source_c::gainChangeCallback(unsigned int gRdB,
+????????????????????????????????????????? unsigned int lnaGRdB)
+{
+? mir_sdr_GainValuesT gainVals;
+
+? mir_sdr_GetCurrentGain(&gainVals);
+
+? if (gRdB < 200)
+? {
+??? std::cerr << "GR change, BB+MIX -" << gRdB << "dB, LNA -" << 
lnaGRdB << std::endl;
+? }
+
+? if (gRdB < mir_sdr_GAIN_MESSAGE_START_ID)
+? {
+??? // gainVals.curr is a calibrated gain value
+? }
+? else if (gRdB == mir_sdr_ADC_OVERLOAD_DETECTED)
+? {
+??? mir_sdr_GainChangeCallbackMessageReceived();
+??? // OVERLOAD DETECTED
+? }
+? else
+? {
+??? mir_sdr_GainChangeCallbackMessageReceived();
+??? // OVERLOAD CORRECTED
+? }
+}
+
+// Callback wrapper
+void sdrplay_source_c::gainChangeCallbackWrap(unsigned int gRdB,
+????????????????????????????????????????????? unsigned int lnaGRdB,
+????????????????????????????????????????????? void *cbContext)
+{
+? sdrplay_source_c *obj = (sdrplay_source_c *)cbContext;
+? obj->gainChangeCallback(gRdB, lnaGRdB);
+}
+
+void sdrplay_source_c::startStreaming(void)
+{
+? if (_streaming)
+??? return;
+
+? unsigned int numDevices;
+? mir_sdr_DeviceT mirDevices[MAX_SUPPORTED_DEVICES];
+? mir_sdr_ReleaseDeviceIdx();
+? mir_sdr_GetDevices(mirDevices, &numDevices, MAX_SUPPORTED_DEVICES);
+? mir_sdr_SetDeviceIdx(_devIndex);
+
+? std::cerr << "Using SDRplay " << hwName(_hwVer) << " "
+??????????? << mirDevices[_devIndex].SerNo << std::endl;
+
+? // Set bias voltage on/off (RSP1A/RSP2).
+? std::cerr << "Bias voltage: " << _biasT << std::endl;
+? if (_hwVer == 2)
+??? mir_sdr_RSPII_BiasTControl(_biasT);
+? else if (_hwVer == 255)
+??? mir_sdr_rsp1a_BiasT(_biasT);
+
+? // Set first LO frequency
+? mir_sdr_SetLoMode(_loMode);
+
+? _streaming = true;
+
+? set_gain_mode(get_gain_mode(/*channel*/ 0), /*channel*/ 0);
+
+? int gRdB = _gRdB;
+? int gRdBsystem = 0;
+
+? mir_sdr_StreamInit(&gRdB,
+???????????????????? _fsHz / 1e6,
+???????????????????? _rfHz / 1e6,
+???????????????????? _bwType,
+???????????????????? _ifType,
+???????????????????? checkLNA(_lna),
+???????????????????? &gRdBsystem,
+???????????????????? mir_sdr_USE_RSP_SET_GR,
+???????????????????? &_samplesPerPacket,
+???????????????????? &streamCallbackWrap,
+???????????????????? &gainChangeCallbackWrap,
+???????????????????? this);
+
+? // Set decimation with halfband filter
+? mir_sdr_DecimateControl(_decim != 1, _decim, 1);
+
+? mir_sdr_DCoffsetIQimbalanceControl(_dcMode, _iqMode);
+
+? // Model-specific initialization
+? if (_hwVer == 2) {
+??? set_antenna(get_antenna(), 0);
+??? mir_sdr_RSPII_RfNotchEnable(_bcastNotch);
+? }
+
+? else if (_hwVer == 255) {
+??? mir_sdr_rsp1a_BroadcastNotch(_bcastNotch);
+??? mir_sdr_rsp1a_DabNotch(_dabNotch);
+? }
+}
+
+void sdrplay_source_c::stopStreaming(void)
+{
+? if (!_streaming)
+??? return;
+
+? _streaming = false;
+
+? mir_sdr_StreamUninit();
+? mir_sdr_ReleaseDeviceIdx();
+}
+
+void sdrplay_source_c::reinitDevice(int reason)
+{
+? // If no reason given, reinit everything
+? if (reason == (int)mir_sdr_CHANGE_NONE)
+??? reason = (mir_sdr_CHANGE_GR |
+????????????? mir_sdr_CHANGE_FS_FREQ |
+????????????? mir_sdr_CHANGE_RF_FREQ |
+????????????? mir_sdr_CHANGE_BW_TYPE |
+????????????? mir_sdr_CHANGE_IF_TYPE |
+????????????? mir_sdr_CHANGE_LO_MODE |
+????????????? mir_sdr_CHANGE_AM_PORT);
+
+? int gRdB;
+? int gRdBsystem; // Returned overall system gain reduction
+
+? gRdB = _gRdB;
+
+? // Tell stream CB to return
+? _reinit = true;
+
+? mir_sdr_Reinit(&gRdB,
+???????????????? _fsHz / 1e6,
+???????????????? _rfHz / 1e6,
+???????????????? _bwType,
+???????????????? _ifType,
+???????????????? _loMode,
+???????????????? checkLNA(_lna),
+???????????????? &gRdBsystem,
+???????????????? mir_sdr_USE_RSP_SET_GR,
+???????????????? &_samplesPerPacket,
+???????????????? (mir_sdr_ReasonForReinitT)reason
+???????????????? );
+
+? // Set decimation with halfband filter
+? if (reason & (int)mir_sdr_CHANGE_FS_FREQ)
+??? mir_sdr_DecimateControl(_decim != 1, _decim, 1);
+
+? _bufferReady.notify_one();
 ?}

 ?std::vector<std::string> sdrplay_source_c::get_devices()
 ?{
+? unsigned int numDevices;
+? mir_sdr_DeviceT mirDevices[MAX_SUPPORTED_DEVICES];
 ??? std::vector<std::string> devices;
-?? std::cerr << "get_devices started" << std::endl;
-
-?? unsigned int dev_cnt = 0;
-?? int samplesPerPacket;
-?? while(mir_sdr_Init(60, 2.048, 200.0, mir_sdr_BW_1_536, 
mir_sdr_IF_Zero, &samplesPerPacket) == mir_sdr_Success)
-?? {
-????? dev_cnt++;
-?? }

-?? std::cerr << "Device count: " << dev_cnt << std::endl;
+? mir_sdr_GetDevices(mirDevices, &numDevices, MAX_SUPPORTED_DEVICES);

-?? for (unsigned int i = 0; i < dev_cnt; i++)
-?? {
-????? mir_sdr_Uninit();
-????? std::string args = "sdrplay=" + boost::lexical_cast< std::string 
 >( i );
-????? args += ",label='" + std::string("SDRplay RSP") + "'";
+? for (unsigned int i=0; i<numDevices; i++) {
+??? mir_sdr_DeviceT *dev = &mirDevices[i];
+??? if (!dev->devAvail)
+????? continue;
+??? std::string args = 
boost::str(boost::format("sdrplay=%d,label='SDRplay %s %s'")
+????????????????????????????????? % i % hwName((int)dev->hwVer) % 
dev->SerNo );
 ?????? std::cerr << args << std::endl;
 ?????? devices.push_back( args );
 ??? }

-?? std::cerr << "get_devices end" << std::endl;
 ??? return devices;
 ?}

 ?size_t sdrplay_source_c::get_num_channels()
 ?{
-?? std::cerr << "get_num_channels: 1" << std::endl;
 ??? return 1;
 ?}

 ?osmosdr::meta_range_t sdrplay_source_c::get_sample_rates()
 ?{
 ??? osmosdr::meta_range_t range;
-
-?? range += osmosdr::range_t( 2000e3, 12000e3 );
-
+? range += osmosdr::range_t( 62.5e3, 10e6 );
 ??? return range;
 ?}

 ?double sdrplay_source_c::set_sample_rate(double rate)
 ?{
-?? std::cerr << "set_sample_rate start" << std::endl;
-?? double diff = rate - _dev->fsHz;
-?? _dev->fsHz = rate;
+? rate = std::min( std::max(rate,62.5e3), 10e6 );
+? _fsHz = rate;

-?? std::cerr << "rate = " << rate << std::endl;
-?? std::cerr << "diff = " << diff << std::endl;
-?? if (_running)
-?? {
-????? if (fabs(diff) < 10000.0)
-????? {
-???????? std::cerr << "mir_sdr_SetFs started" << std::endl;
-???????? mir_sdr_SetFs(diff, 0, 0, 0);
-????? }
-????? else
-????? {
-???????? std::cerr << "reinit_device started" << std::endl;
-???????? reinit_device();
+? // Decimation is required for rates below 2MS/s
+? _decim = 1;
+? while (_fsHz < 2e6) {
+??? _decim *= 2;
+??? _fsHz *= 2;
 ?????? }
-?? }
-?? std::cerr << "set_sample_rate end" << std::endl;
+
+? if (_streaming)
+??? reinitDevice((int)mir_sdr_CHANGE_FS_FREQ);

 ??? return get_sample_rate();
 ?}

 ?double sdrplay_source_c::get_sample_rate()
 ?{
-?? if (_running)
-?? {
-????? return _dev->fsHz;
-?? }
-
-//?? return 0;
-?? return _dev->fsHz;
+? return _fsHz/_decim;
 ?}

 ?osmosdr::freq_range_t sdrplay_source_c::get_freq_range( size_t chan )
 ?{
 ??? osmosdr::freq_range_t range;
-
-?? range += osmosdr::range_t( SDRPLAY_AM_MIN,? SDRPLAY_AM_MAX ); /* 
LW/MW/SW (150 kHz - 30 MHz) */
-?? range += osmosdr::range_t( SDRPLAY_FM_MIN,? SDRPLAY_FM_MAX ); /* VHF 
Band II (64 - 108 MHz) */
-?? range += osmosdr::range_t( SDRPLAY_B3_MIN,? SDRPLAY_B3_MAX ); /* 
Band III (162 - 240 MHz) */
-?? range += osmosdr::range_t( SDRPLAY_B45_MIN, SDRPLAY_B45_MAX ); /* 
Band IV/V (470 - 960 MHz) */
-?? range += osmosdr::range_t( SDRPLAY_L_MIN,?? SDRPLAY_L_MAX ); /* 
L-Band (1450 - 1675 MHz) */
-
+? range += osmosdr::range_t(SDRPLAY_FREQ_MIN,? SDRPLAY_FREQ_MAX);
 ??? return range;
 ?}

 ?double sdrplay_source_c::set_center_freq( double freq, size_t chan )
 ?{
-?? std::cerr << "set_center_freq start" << std::endl;
-?? std::cerr << "freq = " << freq << std::endl;
-?? double diff = freq - _dev->rfHz;
-?? std::cerr << "diff = " << diff << std::endl;
-?? _dev->rfHz = freq;
-?? set_gain_limits(freq);
-?? if (_running)
-?? {
-????? if (fabs(diff) < 10000.0)
-????? {
-???????? std::cerr << "mir_sdr_SetRf started" << std::endl;
-???????? mir_sdr_SetRf(diff, 0, 0);
-????? }
-????? else
-????? {
-???????? std::cerr << "reinit_device started" << std::endl;
-???????? reinit_device();
-????? }
+? _rfHz = freq;
+
+? if (_streaming) {
+??? reinitDevice((int)mir_sdr_CHANGE_RF_FREQ);
 ??? }

-?? std::cerr << "set_center_freq end" << std::endl;
 ??? return get_center_freq( chan );
 ?}

 ?double sdrplay_source_c::get_center_freq( size_t chan )
 ?{
-?? if (_running)
-?? {
-????? return _dev->rfHz;
-?? }
-
-//?? return 0;
-?? return _dev->rfHz;
+? return _rfHz;
 ?}

 ?double sdrplay_source_c::set_freq_corr( double ppm, size_t chan )
@@ -408,7 +516,15 @@ std::vector<std::string> 
sdrplay_source_c::get_gain_names( size_t chan )
 ?{
 ??? std::vector< std::string > gains;

-?? gains += "LNA_MIX_BB";
+? gains += "LNA_ATTEN_STEP";
+? gains += "IF_ATTEN_DB";
+
+? // RSP1A and RSP2 have broadcast notch filters, and RSP1A has a DAB
+? // notch filter. Show all controls for all models, mainly because
+? // gqrx gets confused when switching between sources with different
+? // sets of gains.
+? gains += "BCAST_NOTCH";
+? gains += "DAB_NOTCH";

 ??? return gains;
 ?}
@@ -417,32 +533,60 @@ osmosdr::gain_range_t 
sdrplay_source_c::get_gain_range( size_t chan )
 ?{
 ??? osmosdr::gain_range_t range;

-?? for (int i = _dev->minGain; i < _dev->maxGain; i++)
-?? {
+? for (int i = 20; i <= 59; i++)
 ?????? range += osmosdr::range_t( (float)i );
-?? }

 ??? return range;
 ?}

 ?osmosdr::gain_range_t sdrplay_source_c::get_gain_range( const 
std::string & name, size_t chan )
 ?{
-?? return get_gain_range( chan );
+? osmosdr::gain_range_t range;
+? int maxLnaState;
+
+? if (name == "LNA_ATTEN_STEP") {
+??? if (_hwVer == 2)
+????? maxLnaState = 8;
+??? else if (_hwVer == 255)
+????? maxLnaState = 9;
+??? else
+????? maxLnaState = 3;
+??? for (int i = 0; i <= maxLnaState; i++)
+????? range += osmosdr::range_t((float)i);
+? }
+? // RSP1A, RSP2
+? else if (name == "BCAST_NOTCH") {
+??? range += osmosdr::range_t((float)0);
+??? if (_hwVer == 2 || _hwVer == 255)
+????? range += osmosdr::range_t((float)1);
+? }
+? // RSP1A
+? else if (name == "DAB_NOTCH") {
+??? range += osmosdr::range_t((float)0);
+??? if (_hwVer == 255)
+????? range += osmosdr::range_t((float)1);
+? }
+? else {
+??? for (int i = 20; i <= 59; i++)
+????? range += osmosdr::range_t((float)i);
+? }
+
+? return range;
 ?}

 ?bool sdrplay_source_c::set_gain_mode( bool automatic, size_t chan )
 ?{
-?? std::cerr << "set_gain_mode started" << std::endl;
 ??? _auto_gain = automatic;
-?? std::cerr << "automatic = " << automatic << std::endl;
-?? if (automatic)
-?? {
-????? /* Start AGC */
-????? std::cerr << "AGC not yet implemented" << std::endl;
+? if (_streaming) {
+??? if (automatic) {
+????? mir_sdr_AgcControl(mir_sdr_AGC_5HZ, -30, 0, 0, 0, 0, 
checkLNA(_lna));
+??? }
+??? else {
+????? mir_sdr_AgcControl(mir_sdr_AGC_DISABLE, -30, 0, 0, 0, 0, 
checkLNA(_lna));
+??? }
 ??? }

-?? std::cerr << "set_gain_mode end" << std::endl;
-?? return get_gain_mode(chan);
+? return _auto_gain;
 ?}

 ?bool sdrplay_source_c::get_gain_mode( size_t chan )
@@ -450,151 +594,216 @@ bool sdrplay_source_c::get_gain_mode( size_t chan )
 ??? return _auto_gain;
 ?}

+int sdrplay_source_c::checkLNA(int lna)
+{
+? // Clip LNA reduction step. See table in API section 5.3.
+? if (_hwVer == 1) {
+??? lna = std::min(3, lna);
+? }
+? else if (_hwVer == 255) {
+??? if (_rfHz < 60000000)
+????? lna = std::min(6, lna);
+??? else if (_rfHz >= 1000000000)
+????? lna = std::min(8, lna);
+??? else
+????? lna = std::min(9, lna);
+? }
+? else if (_hwVer == 2) {
+??? if (_rfHz >= 420000000)
+????? lna = std::min(5, lna);
+??? else if (_rfHz < 60000000 && _antenna == "HIGHZ")
+????? lna = std::min(4, lna);
+??? else
+????? lna = std::min(8, lna);
+? }
+
+? return lna;
+}
+
 ?double sdrplay_source_c::set_gain( double gain, size_t chan )
 ?{
-?? std::cerr << "set_gain started" << std::endl;
-?? _dev->gain_dB = gain;
-?? std::cerr << "gain = " << gain << std::endl;
-?? if (gain < _dev->minGain)
+? set_gain(gain, "IF_ATTEN_DB");
+? return get_gain("IF_ATTEN_DB");
+}
+
+double sdrplay_source_c::set_gain(double gain, const std::string & 
name, size_t chan)
 ??? {
-????? _dev->gain_dB = _dev->minGain;
+? bool bcastNotchChanged = false;
+? bool dabNotchChanged = false;
+? bool gainChanged = false;
+
+? if (name == "LNA_ATTEN_STEP") {
+??? if (gain != _lna)
+????? gainChanged = true;
+??? _lna = int(gain);
+? }
+? else if (name == "IF_ATTEN_DB") {
+??? // Ignore out-of-bounds values, since caller knows limits. (GQRX 
spurious calls).
+??? if (gain >= 20.0 && gain <= 59.0 && gain != _gRdB) {
+????? gainChanged = true;
+????? _gRdB = int(gain);
+??? }
+? }
+? // RSP1A, RSP2
+? else if (name == "BCAST_NOTCH" && (_hwVer == 2 || _hwVer == 255)) {
+??? if (int(gain) != _bcastNotch)
+????? bcastNotchChanged = true;
+??? _bcastNotch = int(gain);
+? }
+? // RSP1A
+? else if (name == "DAB_NOTCH" && _hwVer == 255) {
+??? if (int(gain) != _dabNotch)
+????? dabNotchChanged = true;
+??? _dabNotch = int(gain);
 ??? }
-?? if (gain > _dev->maxGain)
-?? {
-????? _dev->gain_dB = _dev->maxGain;
+
+? if (_streaming) {
+??? if (gainChanged)
+????? mir_sdr_RSP_SetGr(_gRdB, checkLNA(_lna), 1 /*absolute*/, 0 
/*immediate*/);
+
+??? if (bcastNotchChanged) {
+????? if (_hwVer == 255 ) {
+??????? mir_sdr_rsp1a_BroadcastNotch(_bcastNotch);
 ??? }
-?? _dev->gRdB = (int)(_dev->maxGain - gain);
+????? else if (_hwVer == 2) {
+??????? mir_sdr_RSPII_RfNotchEnable(_bcastNotch);
+????? }
+??? }

-?? if (_running)
-?? {
-????? std::cerr << "mir_sdr_SetGr started" << std::endl;
-????? mir_sdr_SetGr(_dev->gRdB, 1, 0);
+??? if (dabNotchChanged) {
+????? mir_sdr_rsp1a_DabNotch(_dabNotch);
+??? }
 ??? }

-std::cerr << "set_gain end" << std::endl;
 ?return get_gain( chan );
 ?}

-double sdrplay_source_c::set_gain( double gain, const std::string & 
name, size_t chan)
-{
-?? return set_gain( gain, chan );
-}
-
 ?double sdrplay_source_c::get_gain( size_t chan )
 ?{
-?? if ( _running )
-?? {
-????? return _dev->gain_dB;
-?? }
-
-//?? return 0;
-?? return _dev->gain_dB;
+? return get_gain("IF_ATTEN_DB");
 ?}

 ?double sdrplay_source_c::get_gain( const std::string & name, size_t 
chan )
 ?{
-?? return get_gain( chan );
+? if (name == "LNA_ATTEN_STEP")
+??? return _lna;
+? else if (name == "BCAST_NOTCH")
+??? return _bcastNotch;
+? else if (name == "DAB_NOTCH")
+??? return _dabNotch;
+? else if (name == "IF_ATTEN_DB")
+??? return _gRdB;
+? else
+??? return 0;
 ?}

 ?std::vector< std::string > sdrplay_source_c::get_antennas( size_t chan )
 ?{
 ??? std::vector< std::string > antennas;

-?? antennas += get_antenna( chan );
+? if (_hwVer == 2) {
+??? antennas += "A";
+??? antennas += "B";
+??? antennas += "HIGHZ";
+? }
+? else {
+??? antennas += "RX";
+? }

 ??? return antennas;
 ?}

 ?std::string sdrplay_source_c::set_antenna( const std::string & 
antenna, size_t chan )
 ?{
-?? return get_antenna( chan );
+? _antenna = antenna;
+
+? if (_streaming) {
+??? if (_hwVer == 2) {
+????? // HIGHZ is ANTENNA_B with AmPortSelect
+????? if (antenna == "HIGHZ") {
+??????? mir_sdr_RSPII_AntennaControl(mir_sdr_RSPII_ANTENNA_B);
+??????? mir_sdr_AmPortSelect(1);
+????? }
+????? else {
+??????? if (antenna == "A")
+????????? mir_sdr_RSPII_AntennaControl(mir_sdr_RSPII_ANTENNA_A);
+??????? else
+????????? mir_sdr_RSPII_AntennaControl(mir_sdr_RSPII_ANTENNA_B);
+??????? mir_sdr_AmPortSelect(0);
+????? }
+
+????? reinitDevice((int)mir_sdr_CHANGE_AM_PORT);
+??? }
+? }
+
+? return antenna;
 ?}

 ?std::string sdrplay_source_c::get_antenna( size_t chan )
 ?{
-?? return "RX";
+? return _antenna.c_str();
 ?}

 ?void sdrplay_source_c::set_dc_offset_mode( int mode, size_t chan )
 ?{
-?? if ( osmosdr::source::DCOffsetOff == mode )
-?? {
-????? _dev->dcMode = 0;
-????? if (_running)
-????? {
-???????? mir_sdr_SetDcMode(4, 1);
-????? }
-?? }
-?? else if ( osmosdr::source::DCOffsetManual == mode )
-?? {
-????? std::cerr << "Manual DC correction mode is not implemented." << 
std::endl;
-????? _dev->dcMode = 0;
-????? if (_running)
-????? {
-???????? mir_sdr_SetDcMode(4, 1);
-????? }
-?? }
-?? else if ( osmosdr::source::DCOffsetAutomatic == mode )
-?? {
-????? _dev->dcMode = 1;
-????? if (_running)
-????? {
+? _dcMode = (osmosdr::source::DCOffsetAutomatic == mode);
+
+? if (_dcMode) {
 ????????? mir_sdr_SetDcMode(4, 1);
+??? mir_sdr_SetDcTrackTime(63);
 ?????? }
-?? }
+? mir_sdr_DCoffsetIQimbalanceControl(_dcMode, _iqMode);
 ?}

 ?void sdrplay_source_c::set_dc_offset( const std::complex<double> 
&offset, size_t chan )
 ?{
-?? std::cerr << "Manual DC correction mode is not implemented." << 
std::endl;
+? std::cerr << "set_dc_offset(): not implemented" << std::endl;
+}
+
+void sdrplay_source_c::set_iq_balance_mode(int mode, size_t chan)
+{
+? _iqMode = (osmosdr::source::IQBalanceAutomatic == mode);
+
+? mir_sdr_DCoffsetIQimbalanceControl(_dcMode, _iqMode);
 ?}

 ?double sdrplay_source_c::set_bandwidth( double bandwidth, size_t chan )
 ?{
-?? if????? (bandwidth <= 200e3)? _dev->bwType = mir_sdr_BW_0_200;
-?? else if (bandwidth <= 300e3)? _dev->bwType = mir_sdr_BW_0_300;
-?? else if (bandwidth <= 600e3)? _dev->bwType = mir_sdr_BW_0_600;
-?? else if (bandwidth <= 1536e3) _dev->bwType = mir_sdr_BW_1_536;
-?? else if (bandwidth <= 5000e3) _dev->bwType = mir_sdr_BW_5_000;
-?? else if (bandwidth <= 6000e3) _dev->bwType = mir_sdr_BW_6_000;
-?? else if (bandwidth <= 7000e3) _dev->bwType = mir_sdr_BW_7_000;
-?? else????????????????????????? _dev->bwType = mir_sdr_BW_8_000;
+? _bwType = mir_sdr_BW_8_000;

-?? if (_running)
-?? {
-????? reinit_device();
+? for (double bw : bandwidths) {
+??? // Skip dummy value at index 0
+??? if (bw == 0)
+????? continue;
+??? if (bandwidth <= bw) {
+????? _bwType = (mir_sdr_Bw_MHzT)(bw/1e3);
+????? break;
+??? }
+? }
+
+? int actual = get_bandwidth(chan);
+? std::cerr << "SDRplay bandwidth requested=" << bandwidth
+??????????? << " actual=" << actual << std::endl;
+
+? if (_streaming) {
+??? reinitDevice((int)mir_sdr_CHANGE_BW_TYPE);
 ??? }

-?? return get_bandwidth( chan );
+? return actual;
 ?}

 ?double sdrplay_source_c::get_bandwidth( size_t chan )
 ?{
-?? double tmpbw=0.0f;
-?? if????? (_dev->bwType == mir_sdr_BW_0_200) tmpbw =? 200e3;
-?? else if (_dev->bwType == mir_sdr_BW_0_300) tmpbw =? 300e3;
-?? else if (_dev->bwType == mir_sdr_BW_0_600) tmpbw =? 600e3;
-?? else if (_dev->bwType == mir_sdr_BW_1_536) tmpbw = 1536e3;
-?? else if (_dev->bwType == mir_sdr_BW_5_000) tmpbw = 5000e3;
-?? else if (_dev->bwType == mir_sdr_BW_6_000) tmpbw = 6000e3;
-?? else if (_dev->bwType == mir_sdr_BW_7_000) tmpbw = 7000e3;
-?? else?????????????????????????????????????? tmpbw = 8000e3;
-
-?? return (double)tmpbw;
+? return (double)_bwType * 1e3;
 ?}

 ?osmosdr::freq_range_t sdrplay_source_c::get_bandwidth_range( size_t 
chan )
 ?{
 ??? osmosdr::freq_range_t range;

-?? range += osmosdr::range_t( 200e3 );
-?? range += osmosdr::range_t( 300e3 );
-?? range += osmosdr::range_t( 600e3 );
-?? range += osmosdr::range_t( 1536e3 );
-?? range += osmosdr::range_t( 5000e3 );
-?? range += osmosdr::range_t( 6000e3 );
-?? range += osmosdr::range_t( 7000e3 );
-?? range += osmosdr::range_t( 8000e3 );
+? // bandwidths[0] is a dummy
+? for (unsigned int i=1; i<bandwidths.size(); i++)
+??? range += osmosdr::range_t(bandwidths[i]);

 ??? return range;
-}
+}
\ No newline at end of file
diff --git a/lib/sdrplay/sdrplay_source_c.h 
b/lib/sdrplay/sdrplay_source_c.h
index 2e4631e..35de63b 100644
--- a/lib/sdrplay/sdrplay_source_c.h
+++ b/lib/sdrplay/sdrplay_source_c.h
@@ -1,5 +1,7 @@
 ?/* -*- c++ -*- */
 ?/*
+ * Copyright 2018 Frank Werner-Krippendorf <mail at hb9fxq.ch>
+ * Copyright 2018 Jeff Long <willcode4 at gmail.com>
 ? * Copyright 2015 SDRplay Ltd <support at sdrplay.com>
 ? * Copyright 2012 Dimitri Stolnikov <horiz0n at gmx.net>
 ? *
@@ -22,17 +24,21 @@
 ?#define INCLUDED_SDRPLAY_SOURCE_C_H

 ?#include <gnuradio/sync_block.h>
-
 ?#include <gnuradio/thread/thread.h>
-#include <boost/thread/mutex.hpp>
-#include <boost/thread/condition_variable.hpp>

 ?#include "osmosdr/ranges.h"

 ?#include "source_iface.h"

+#include <mirsdrapi-rsp.h>
+
 ?class sdrplay_source_c;
-typedef struct sdrplay_dev sdrplay_dev_t;
+
+template <typename T>
+struct Range {
+? T min;
+? T max;
+};

 ?/*
 ? * We use boost::shared_ptr's instead of raw pointers for all access
@@ -82,6 +88,9 @@ public:
 ???????????? gr_vector_const_void_star &input_items,
 ???????????? gr_vector_void_star &output_items );

+?? bool start( void );
+?? bool stop( void );
+
 ??? static std::vector< std::string > get_devices();

 ??? size_t get_num_channels( void );
@@ -112,25 +121,58 @@ public:

 ??? void set_dc_offset_mode( int mode, size_t chan = 0 );
 ??? void set_dc_offset( const std::complex<double> &offset, size_t chan 
= 0 );
+?? void set_iq_balance_mode( int mode, size_t chan = 0 );

 ??? double set_bandwidth( double bandwidth, size_t chan = 0 );
 ??? double get_bandwidth( size_t chan = 0 );
 ??? osmosdr::freq_range_t get_bandwidth_range( size_t chan = 0 );

 ?private:
-?? void reinit_device(void);
-?? void set_gain_limits(double freq);
-
-?? sdrplay_dev_t *_dev;
-
-?? std::vector< short > _bufi;
-?? std::vector< short > _bufq;
-?? int _buf_offset;
-?? boost::mutex _buf_mutex;
+? void startStreaming(void);
+? void stopStreaming(void);
+? void reallocateBuffers(int size, int num);
+? void reinitDevice(int reason);
+? int checkLNA(int lna);
+? void streamCallback(short *xi, short *xq, unsigned int firstSampleNum,
+????????????????????? int grChanged, int rfChanged, int fsChanged,
+????????????????????? unsigned int numSamples, unsigned int reset);
+? void gainChangeCallback(unsigned int gRdB, unsigned int lnaGRdB);
+
+? static void streamCallbackWrap(short *xi, short *xq, unsigned int 
firstSampleNum,
+???????????????????????????????? int grChanged, int rfChanged, int 
fsChanged,
+???????????????????????????????? unsigned int numSamples, unsigned int 
reset,
+???????????????????????????????? unsigned int hwRemoved, void *cbContext);
+? static void gainChangeCallbackWrap(unsigned int gRdB, unsigned int 
lnaGRdB, void *cbContext);

-?? bool _running;
-?? bool _uninit;
 ??? bool _auto_gain;
+?? int _gain;
+?? int _gRdB;
+?? int _lna;
+?? int _bcastNotch;
+?? int _dabNotch;
+?? double _fsHz;
+?? int _decim;
+?? double _rfHz;
+?? mir_sdr_Bw_MHzT _bwType;
+?? mir_sdr_If_kHzT _ifType;
+?? mir_sdr_LoModeT _loMode;
+?? int _samplesPerPacket;
+?? bool _dcMode;
+?? bool _iqMode;
+?? unsigned char _hwVer;
+?? unsigned int _devIndex;
+?? std::string _antenna;
+?? int _biasT;
+
+?? gr_complex *_buffer;
+?? int _bufferOffset;
+?? int _bufferSpaceRemaining;
+?? boost::mutex _bufferMutex;
+?? boost::condition_variable _bufferReady;? // buffer is ready to move 
to other thread
+
+?? bool _streaming;
+?? bool _flowgraphRunning;
+?? bool _reinit;? // signal streamer to return after a reinit
 ?};

 ?#endif /* INCLUDED_SDRPLAY_SOURCE_C_H */