From None Mon Jan  3 10:57:16 2022
From: None
To: osmocom-sdr@lists.osmocom.org
Subject: None
Date: Mon, 03 Jan 2022 10:57:16 +0000
Message-ID: <164120743694.16541.16265955471697615390.generated@lists>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1908695325770536120=="

--===============1908695325770536120==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

from DVB-T (I am a complete neophyte at all of this) and so that particular
feature of the device won't be of much use to me, but as for the FM, I'm on
the Ubuntu/Linux GNU platform, so I'm awaiting on the kindness of strangers
to perfect the kernel drivers enough to match the Windows kit performance.
But that's okay, because I'm learning a lot in the process :)

On Mon, Aug 13, 2012 at 11:44 PM, Adam Nielsen <a.nielsen(a)shikadi.net>wrote:

> so it is /designed/ for FM?  That's encouraging because mostly that is all
>> I
>>
>> really need from it, only all my experiments so far have yielded only
>> AM-quality sound, but it's good to hear because it means there's /hope/
>> and so
>>
>> I'll just keep hanging in there until an FM recipe surfaces :)
>>
>
> Yes, because the dongles provide digital TV (via hardware) and as an extra
> selling point, analogue FM radio (provided via the SDR.)
>
> I don't know what platform you're on or what your goals are, but I hear
> the SDR# program for Windows offers excellent stereo FM support, as it's
> one of the few programs that can deal with the ~120kHz bandwidth needed for
> a WBFM signal.
>
> Cheers,
> Adam.
>
>
>


-- 
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*

--f46d042fd93a1d197104c738bd48
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

--===============1908695325770536120==--


From None Mon Jan  3 10:57:16 2022
From: None
To: osmocom-sdr@lists.osmocom.org
Subject: None
Date: Mon, 03 Jan 2022 10:57:16 +0000
Message-ID: <164120743695.16541.3075843062139573392.generated@lists>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2695374873155295418=="

--===============2695374873155295418==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

r feature of the device won&#39;t be of much use to me, but as for the FM, =
I&#39;m on the Ubuntu/Linux GNU platform, so I&#39;m awaiting on the kindne=
ss of strangers to perfect the kernel drivers enough to match the Windows k=
it performance. But that&#39;s okay, because I&#39;m learning a lot in the =
process :)<br>
<br><div class=3D"gmail_quote">On Mon, Aug 13, 2012 at 11:44 PM, Adam Niels=
en <span dir=3D"ltr">&lt;<a href=3D"mailto:a.nielsen(a)shikadi.net" target=3D=
"_blank">a.nielsen(a)shikadi.net</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
so it is /designed/ for FM? =A0That&#39;s encouraging because mostly that i=
s all I<div class=3D"im"><br>
really need from it, only all my experiments so far have yielded only<br></=
div>
AM-quality sound, but it&#39;s good to hear because it means there&#39;s /h=
ope/ and so<div class=3D"im"><br>
I&#39;ll just keep hanging in there until an FM recipe surfaces :)<br>
</div></blockquote>
<br>
Yes, because the dongles provide digital TV (via hardware) and as an extra =
selling point, analogue FM radio (provided via the SDR.)<br>
<br>
I don&#39;t know what platform you&#39;re on or what your goals are, but I =
hear the SDR# program for Windows offers excellent stereo FM support, as it=
&#39;s one of the few programs that can deal with the ~120kHz bandwidth nee=
ded for a WBFM signal.<br>

<br>
Cheers,<br>
Adam.<br>
<br>
<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div style=
=3D"text-align:right"><i><span style=3D"font-size:x-small">Have Blog, Will =
Travel: </span><span style=3D"font-size:x-small"><a href=3D"http://blog.tel=
edyn.com" target=3D"_blank">blog.teledyn.com</a></span></i></div>
<div style=3D"text-align:right"><i><span style=3D"font-size:x-small">A Serv=
iceable Substitute: <a href=3D"http://post.teledyn.com" target=3D"_blank">p=
ost.teledyn.com</a></span></i></div><br>

--f46d042fd93a1d197104c738bd48--


--===============2695374873155295418==--


From None Mon Jan  3 10:57:21 2022
From: None
To: osmocom-sdr@lists.osmocom.org
Subject: None
Date: Mon, 03 Jan 2022 10:57:21 +0000
Message-ID: <164120744180.16541.13739372598256146158.generated@lists>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3658010038299116395=="

--===============3658010038299116395==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

3.54 GHz. The actual mixer frequency sent to the IF stage is the VCO
frequency divided by a number between 2 and 63 -- so the possible center
frequency tuning range ends up being in the range of ~24 MHz to 1.77 GHz.

However, I was wondering if it would be possible to use a MixDiv of 1 --
to run the mixer frequency directly on the VCO? Has anyone tried that,
or would it fry the device somehow?

Just wondering if the range could be extended (disregarding any
sensitivity issues, of course).


-- Per.


--===============3658010038299116395==--


From None Mon Jan  3 10:57:23 2022
From: None
To: osmocom-sdr@lists.osmocom.org
Subject: None
Date: Mon, 03 Jan 2022 10:57:23 +0000
Message-ID: <164120744349.16541.11492522360265093052.generated@lists>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7769872995172775553=="

--===============7769872995172775553==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

ioctl(5, USBDEVFS_CLAIMINTERFACE, 0x7fd063c4) =3D -1 ENOENT (No such file or =
directory)

The kernel is saying that the interface doesn't exist.

lsusb -v for this device run on the fritzbox would be interesting.


//Peter


--===============7769872995172775553==--


From None Mon Jan  3 10:57:24 2022
From: None
To: osmocom-sdr@lists.osmocom.org
Subject: None
Date: Mon, 03 Jan 2022 10:57:24 +0000
Message-ID: <164120744426.16541.15237801212515989455.generated@lists>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1100053735949500037=="

--===============1100053735949500037==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

developer doesn't really know or care about corner cases and as a
result it's possible for the GUI to show "green" when in fact there
is actually a problem that could be detected. That said, if you've
used zadig to install the driver then it should indeed work.


> but I can confidently say, I've followed every instruction quite
> precisely... I've tried installing the winusb stub for both
> instance 0 and 1

What do you mean by instance here again? Sorry if you already
mentioned that.

If the device has multiple interfaces (a so-called composite device)
it is important to install WinUSB for the actual device, and not for
either of the two interfaces.


> trying everything in both cases in the event that installing it on
> the second instance is itself a problem. there's something quite
> subtle wrong, given that sdrsharp works perfectly...

I don't know how your .exe files were built and if they are using
libusb or the hostile fork libusbx which clobbers the soname and
uses the same API namespace, the latter driven by that same
zadig/libwdi developer. I know the actual libusb very well and it
would be interesting to see output from a debug build of my current
working directory with libusb source. I've built a binary using the
MS C compiler here: http://stuge.se/libusb-1.0.dll

Try putting this in the same directory as the program and see if you
still have the same problem. Even if the program was built using
MinGW that DLL should work well. If yes, the output from the program
would be interesting.


Thanks

//Peter


--===============1100053735949500037==--


From None Mon Jan  3 10:57:27 2022
From: None
To: osmocom-sdr@lists.osmocom.org
Subject: None
Date: Mon, 03 Jan 2022 10:57:27 +0000
Message-ID: <164120744714.16541.9144639080016656108.generated@lists>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1796958901076462654=="

--===============1796958901076462654==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

it was a saturation issue in RF, it would show up no matter what the
sample rate is.

Also :
 - RF filter are often only band specific and not channel specific
(because tunable RF filters to do channel selection would be
prohibitively expensive)
 - IF filter (or BB filters for zero-if) are then used for channel selection.

So in his case being two channel in the same band (and given the
architecture of the dongles), the only saturation that IF filters
would provide would be against ADC saturation and it's easy to check
if this happens or not just looking at the time domain signal.

Cheers,

    Sylvain


--===============1796958901076462654==--


From None Mon Jan  3 10:57:27 2022
From: None
To: osmocom-sdr@lists.osmocom.org
Subject: None
Date: Mon, 03 Jan 2022 10:57:27 +0000
Message-ID: <164120744718.16541.12741235739927895846.generated@lists>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8895959956893047940=="

--===============8895959956893047940==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

VOR from the Oakland airport. And I have now discovered a ridge near my
home with a scenic overlook from which I can receive two.

I've tested the software enough to know that the initial scan function
seems to work, and the morse decoding kind of works, but I am not confident
I'll get it to work very well. (One transmitter's dit looks a lot like
another's dah.) The nav signal decoding is simple. (A 30 Hz AM modulated
tone is phase compared with a 30 Hz tone FM modulated at 9960 Hz. The phase
obtained is the azimuth to the station.)


If I ever get this working, I looking forward to sharing it with the
community. In the process of building this, I created a simple SDR toolkit
of DSP functions. It's like Gnuradio in concept, but 16b fixed-point, and
has no external dependencies, and C89, so is easier to build on weird and
limited platforms. It also has perl bindings. Compared to GR, it looks like
the work of a rank amateur just learning DSP, but I do like the concept of
there being a GR-like library out there, lightweight and embedded-friendly.


Regards,
Dave J


On Tue, Oct 22, 2013 at 3:06 AM, jdow <jdow(a)earthlink.net> wrote:

> He sent me two frequencies in private email. These were in the FM
> broadcast band (in the US). He probably needs to notch them out
> in order to get adequate response.
>
> As for wanting narrow bandwidth - I am not quite sure why he thinks
> that is a benefit. I use a large FFT (about 10 Hz per bin) and use
> the zoom control to see fine detail. (Different FFT settings suite
> different uses. This one seems to be a good compromise with my two
> needs. I'm too lazy to change it.)
>
> {^_^}
>
>
>
> On 2013/10/22 02:08, Sylvain Munaut wrote:
>
>> Effective filtering must occur between antenna and receiver. All the
>>> problems that a saturated preamp and ADC cause can=92t be repaired by
>>> software. Never.
>>>
>>
>> But his original problem is not with saturated preamps or ADC ... it's
>> aliasing ... and that can be solved in the digital domain provided
>> fast enough ADC.
>>
>> Cheers,
>>
>>     Sylvain
>>
>>
>>

--089e01184768dfc65f04e955c0d5
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I originally posted about 115.8 and 116.8 MHz, both square=
 in the VOR band of 108 to 117.95. I might have sent something else in a PM=
, but if so it was a typo. :-) I am definitely only interested in the VOR b=
and right now -- though, as you say, it is adjacent to commercial FM with i=
ts high power.<div>
<br></div><div>My application is simple in concept: A fully auomatic VOR-ba=
sed positioning system, a fallback from GPS. I want to scan the entire VOR =
band, looking for signals in the standard VOR format that can be demodulate=
d. I do the initial scan with a fast sample rate and FFT, just looking for =
peaks. From those, I examine the signals to see if it looks like a VOR sign=
al. From that list, I will &quot;park&quot; on each signal long enough (~30=
s) to decode the VOR&#39;s morse code station ID. From that, I will have a =
short list of VORs that I can currently receive. From those, if the geometr=
y is appropriate (I know the VORs positions from a database) I can calculat=
e a position.</div>
<div><br></div><div>The software then just round-robin tunes the VORs in ra=
nge and continually tries to calculate positions. If too many drop out, it =
returns to the initial scan mode.</div><div><br></div><div>Not being able t=
o receive this VOR or that VOR is not generally a problem, but obviously, t=
he more the better. With extra VORs I have better options for choosing the =
closest ones or the ones with the best geometry.</div>
<div><br></div><div><br></div><div>This is actually quite difficult to test=
, because VORs can generally only be received line-of-sight -- which means =
in the air. I&#39;m a private pilot but I found that flying and noodling wi=
th a laptop is too much trouble. From my office window, on a high floor in =
Oakland, CA, I can receive one VOR from the Oakland airport. And I have now=
 discovered a ridge near my home with a scenic overlook from which I can re=
ceive two.</div>
<div><br></div><div>I&#39;ve tested the software enough to know that the in=
itial scan function seems to work, and the morse decoding kind of works, bu=
t I am not confident I&#39;ll get it to work very well. (One transmitter&#3=
9;s dit looks a lot like another&#39;s dah.) The nav signal decoding is sim=
ple. (A 30 Hz AM modulated tone is phase compared with a 30 Hz tone FM modu=
lated at 9960 Hz. The phase obtained is the azimuth to the station.)</div>
<div><br></div><div><br></div><div class=3D"gmail_extra">If I ever get this=
 working, I looking forward to sharing it with the community. In the proces=
s of building this, I created a simple SDR toolkit of DSP functions. It&#39=
;s like Gnuradio in concept, but 16b fixed-point, and has no external depen=
dencies, and C89, so is easier to build on weird and limited platforms. It =
also has perl bindings. Compared to GR, it looks like the work of a rank am=
ateur just learning DSP, but I do like the concept of there being a GR-like=
 library out there, lightweight and embedded-friendly.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra">Regards,</div><div class=3D"gmail_extra">Dave J</=
div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, O=
ct 22, 2013 at 3:06 AM, jdow <span dir=3D"ltr">&lt;<a href=3D"mailto:jdow(a)e=
arthlink.net" target=3D"_blank">jdow(a)earthlink.net</a>&gt;</span> wrote:<br=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">He sent me two frequencies in private email.=
 These were in the FM<br>
broadcast band (in the US). He probably needs to notch them out<br>
in order to get adequate response.<br>
<br>
As for wanting narrow bandwidth - I am not quite sure why he thinks<br>
that is a benefit. I use a large FFT (about 10 Hz per bin) and use<br>
the zoom control to see fine detail. (Different FFT settings suite<br>
different uses. This one seems to be a good compromise with my two<br>
needs. I&#39;m too lazy to change it.)<br>
<br>
{^_^}<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
On 2013/10/22 02:08, Sylvain Munaut wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Effective filtering must occur between antenna and receiver. All the<br>
problems that a saturated preamp and ADC cause can=92t be repaired by<br>
software. Never.<br>
</blockquote>
<br>
But his original problem is not with saturated preamps or ADC ... it&#39;s<=
br>
aliasing ... and that can be solved in the digital domain provided<br>
fast enough ADC.<br>
<br>
Cheers,<br>
<br>
=A0 =A0 Sylvain<br>
<br>
<br>
</blockquote>
</div></div></blockquote></div><br></div></div>

--089e01184768dfc65f04e955c0d5--


--===============8895959956893047940==--


From None Mon Jan  3 10:57:30 2022
From: None
To: osmocom-sdr@lists.osmocom.org
Subject: None
Date: Mon, 03 Jan 2022 10:57:30 +0000
Message-ID: <164120745052.16541.486036070175887860.generated@lists>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7896763316760076051=="

--===============7896763316760076051==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

direct sampling mode, only from signal processing view):
If you already have analog signal as separated I&Q in baseband (so called
zero-IF), and do I&Q two channel A/D converter, you can processing signal,
highest frequency of which is less than sampling rate, without aliasing.
That means, for example, you can processing signal, frequency of which is
up to 28.8MHz, when sampling rate is 28.8MHz. (There is an implicit
assumption that your zero-IF analog channel is ideal)

If you have to do sampling on a single channel analog signal( not zero-IF,
I&Q not separated by analog circuit, I&Q are still mixed together by an IF
carrier/frequency), you have to ensure the highest frequency of signal less
than half of sampling rate to ensure no aliasing.



On Wed, Jan 29, 2014 at 7:50 AM, Richard Koch <n1gp(a)hotmail.com> wrote:

> Can someone clarify what the frequency range is in Direct sampling mode.
>
> The rtl2832u dongle has a 28.8Mhz osc.
>
> So can the dongle in "direct sampling mode" (with appropriate antenna
> connection)
> receive > 14.4 Mhz (Nyquist) ?
>
> Googling I find conflicting advice.
>
> I've been able to receive > 14.4 Mhz in direct mode, but I'm not sure if
> that's due to some non-optimal method...?
>
> I'm guessing it can because the tuner chip provides both I & Q data
> therefore
> allowing the double rate...?
>
>
>
>

--047d7bf15fc8eed8c404f1137e92
Content-Type: text/html; charset=3DISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D3D"ltr"><div><div>From the point of view of signal processing (not=
=3D
 very clear about your direct sampling mode, only from signal processing vi=3D
ew):<br></div>If you already have analog signal as separated I&amp;Q in bas=3D
eband (so called zero-IF), and do I&amp;Q two channel A/D converter, you ca=3D
n processing signal, highest frequency of which is less than sampling rate,=3D
 without aliasing.<br>
</div><div>That means, for example, you can processing signal, frequency of=3D
 which is up to 28.8MHz, when sampling rate is 28.8MHz. (There is an implic=3D
it assumption that your zero-IF analog channel is ideal)<br><br></div>If yo=3D
u have to do sampling on a single channel analog signal( not zero-IF, I&amp=3D
;Q not separated by analog circuit, I&amp;Q are still mixed together by an =3D
IF carrier/frequency), you have to ensure the highest frequency of signal l=3D
ess than half of sampling rate to ensure no aliasing.<br>
<br></div><div class=3D3D"gmail_extra"><br><br><div class=3D3D"gmail_quote">O=
n =3D
Wed, Jan 29, 2014 at 7:50 AM, Richard Koch <span dir=3D3D"ltr">&lt;<a href=3D=
3D=3D
"mailto:n1gp(a)hotmail.com" target=3D3D"_blank">n1gp(a)hotmail.com</a>&gt;</s=
pan>=3D
 wrote:<br>
<blockquote class=3D3D"gmail_quote" style=3D3D"margin:0 0 0 .8ex;border-left:=
1p=3D
x #ccc solid;padding-left:1ex">


<div><div dir=3D3D"ltr">Can someone clarify what the frequency range is in Di=
=3D
rect sampling mode.<br><br>The rtl2832u dongle has a 28.8Mhz osc. <br><br>S=3D
o can the dongle in &quot;direct sampling mode&quot; (with appropriate ante=3D
nna connection)<br>
receive &gt; 14.4 Mhz (Nyquist) ?<br><br>Googling I find conflicting advice=3D
.<br><br>I&#39;ve been able to receive &gt; 14.4 Mhz in direct mode, but I&=3D
#39;m not sure if<br>that&#39;s due to some non-optimal method...?<br><br>
I&#39;m guessing it can because the tuner chip provides both I &amp; Q data=3D
 therefore<br>allowing the double rate...?<br><br><br><br> 		 	   		  </div=3D
></div>
</blockquote></div><br></div>

--047d7bf15fc8eed8c404f1137e92--


--===============7896763316760076051==--


From None Mon Jan  3 10:57:31 2022
From: None
To: osmocom-sdr@lists.osmocom.org
Subject: None
Date: Mon, 03 Jan 2022 10:57:31 +0000
Message-ID: <164120745118.16541.5357586874010634056.generated@lists>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3124909839531389345=="

--===============3124909839531389345==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

receive. From those, if the geometry is appropriate (I know the VORs =
positions from a database) I can calculate a =
position.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>The software then just round-robin tunes the VORs in =
range and continually tries to calculate positions. If too many drop =
out, it returns to the initial scan mode.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Not being able to receive this VOR or that VOR is not =
generally a problem, but obviously, the more the better. With extra VORs =
I have better options for choosing the closest ones or the ones with the =
best geometry.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>This is actually quite difficult to test, because VORs =
can generally only be received line-of-sight -- which means in the air. =
I'm a private pilot but I found that flying and noodling with a laptop =
is too much trouble. From my office window, on a high floor in Oakland, =
CA, I can receive one VOR from the Oakland airport. And I have now =
discovered a ridge near my home with a scenic overlook from which I can =
receive two.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>I've tested the software enough to know that the =
initial scan function seems to work, and the morse decoding kind of =
works, but I am not confident I'll get it to work very well. (One =
transmitter's dit looks a lot like another's dah.) The nav signal =
decoding is simple. (A 30 Hz AM modulated tone is phase compared with a =
30 Hz tone FM modulated at 9960 Hz. The phase obtained is the azimuth to =
the station.)<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>If I ever get this working, I looking forward to =
sharing it with the community. In the process of building this, I =
created a simple SDR toolkit of DSP functions. It's like Gnuradio in =
concept, but 16b fixed-point, and has no external dependencies, and C89, =
so is easier to build on weird and limited platforms. It also has perl =
bindings. Compared to GR, it looks like the work of a rank amateur just =
learning DSP, but I do like the concept of there being a GR-like library =
out there, lightweight and =
embedded-friendly.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Regards,<o:p></o:p></p></div><div><p =
class=3DMsoNormal>Dave J<o:p></o:p></p></div><div><div><div><p =
class=3DMsoNormal =
style=3D'margin-bottom:12.0pt'><o:p>&nbsp;</o:p></p><div><p =
class=3DMsoNormal>On Tue, Oct 22, 2013 at 3:06 AM, jdow &lt;<a =
href=3D"mailto:jdow(a)earthlink.net" =
target=3D"_blank">jdow(a)earthlink.net</a>&gt; wrote:<o:p></o:p></p><p =
class=3DMsoNormal>He sent me two frequencies in private email. These =
were in the FM<br>broadcast band (in the US). He probably needs to notch =
them out<br>in order to get adequate response.<br><br>As for wanting =
narrow bandwidth - I am not quite sure why he thinks<br>that is a =
benefit. I use a large FFT (about 10 Hz per bin) and use<br>the zoom =
control to see fine detail. (Different FFT settings suite<br>different =
uses. This one seems to be a good compromise with my two<br>needs. I'm =
too lazy to change it.)<br><br>{^_^}<o:p></o:p></p><div><div><p =
class=3DMsoNormal><br><br><br>On 2013/10/22 02:08, Sylvain Munaut =
wrote:<o:p></o:p></p><blockquote style=3D'border:none;border-left:solid =
#CCCCCC 1.0pt;padding:0cm 0cm 0cm =
6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=3DMsoNormal>Effective =
filtering must occur between antenna and receiver. All the<br>problems =
that a saturated preamp and ADC cause can&#8217;t be repaired =
by<br>software. Never.<o:p></o:p></p></blockquote><p class=3DMsoNormal =
style=3D'margin-bottom:12.0pt'><br>But his original problem is not with =
saturated preamps or ADC ... it's<br>aliasing ... and that can be solved =
in the digital domain provided<br>fast enough =
ADC.<br><br>Cheers,<br><br>&nbsp; &nbsp; =
Sylvain<br><br><o:p></o:p></p></div></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></div></div></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></div></div></body></html>
------=_NextPart_000_0073_01CF2656.CE93A820--



--===============3124909839531389345==--


From None Mon Jan  3 10:57:31 2022
From: None
To: osmocom-sdr@lists.osmocom.org
Subject: None
Date: Mon, 03 Jan 2022 10:57:31 +0000
Message-ID: <164120745121.16541.18167992058776698974.generated@lists>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6137272094599311877=="

--===============6137272094599311877==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

o decode the VOR&#39;s morse code station ID. From that, I will have a shor=3D
t list of VORs that I can currently receive. From those, if the geometry is=3D
 appropriate (I know the VORs positions from a database) I can calculate a =3D
position.<u></u><u></u></p>

</div><div><p class=3D3D"MsoNormal"><u></u>&nbsp;<u></u></p></div><div><p cla=
=3D
ss=3D3D"MsoNormal">The software then just round-robin tunes the VORs in range=
=3D
 and continually tries to calculate positions. If too many drop out, it ret=3D
urns to the initial scan mode.<u></u><u></u></p>

</div><div><p class=3D3D"MsoNormal"><u></u>&nbsp;<u></u></p></div><div><p cla=
=3D
ss=3D3D"MsoNormal">Not being able to receive this VOR or that VOR is not gene=
=3D
rally a problem, but obviously, the more the better. With extra VORs I have=3D
 better options for choosing the closest ones or the ones with the best geo=3D
metry.<u></u><u></u></p>

</div><div><p class=3D3D"MsoNormal"><u></u>&nbsp;<u></u></p></div><div><p cla=
=3D
ss=3D3D"MsoNormal"><u></u>&nbsp;<u></u></p></div><div><p class=3D3D"MsoNormal=
">=3D
This is actually quite difficult to test, because VORs can generally only b=3D
e received line-of-sight -- which means in the air. I&#39;m a private pilot=3D
 but I found that flying and noodling with a laptop is too much trouble. Fr=3D
om my office window, on a high floor in Oakland, CA, I can receive one VOR =3D
from the Oakland airport. And I have now discovered a ridge near my home wi=3D
th a scenic overlook from which I can receive two.<u></u><u></u></p>

</div><div><p class=3D3D"MsoNormal"><u></u>&nbsp;<u></u></p></div><div><p cla=
=3D
ss=3D3D"MsoNormal">I&#39;ve tested the software enough to know that the initi=
=3D
al scan function seems to work, and the morse decoding kind of works, but I=3D
 am not confident I&#39;ll get it to work very well. (One transmitter&#39;s=3D
 dit looks a lot like another&#39;s dah.) The nav signal decoding is simple=3D
. (A 30 Hz AM modulated tone is phase compared with a 30 Hz tone FM modulat=3D
ed at 9960 Hz. The phase obtained is the azimuth to the station.)<u></u><u>=3D
</u></p>

</div><div><p class=3D3D"MsoNormal"><u></u>&nbsp;<u></u></p></div><div><p cla=
=3D
ss=3D3D"MsoNormal"><u></u>&nbsp;<u></u></p></div><div><p class=3D3D"MsoNormal=
">=3D
If I ever get this working, I looking forward to sharing it with the commun=3D
ity. In the process of building this, I created a simple SDR toolkit of DSP=3D
 functions. It&#39;s like Gnuradio in concept, but 16b fixed-point, and has=3D
 no external dependencies, and C89, so is easier to build on weird and limi=3D
ted platforms. It also has perl bindings. Compared to GR, it looks like the=3D
 work of a rank amateur just learning DSP, but I do like the concept of the=3D
re being a GR-like library out there, lightweight and embedded-friendly.<u>=3D
</u><u></u></p>

</div><div><p class=3D3D"MsoNormal"><u></u>&nbsp;<u></u></p></div><div><p cla=
=3D
ss=3D3D"MsoNormal"><u></u>&nbsp;<u></u></p></div><div><p class=3D3D"MsoNormal=
">=3D
Regards,<u></u><u></u></p></div><div><p class=3D3D"MsoNormal">Dave J<u></u><u=
=3D
></u></p></div>

<div><div><div><p class=3D3D"MsoNormal" style=3D3D"margin-bottom:12.0pt"><u><=
/u=3D
>&nbsp;<u></u></p><div><p class=3D3D"MsoNormal">On Tue, Oct 22, 2013 at 3:06 =
=3D
AM, jdow &lt;<a href=3D3D"mailto:jdow(a)earthlink.net" target=3D3D"_blank">jd=
ow(a)e=3D
arthlink.net</a>&gt; wrote:<u></u><u></u></p>

<p class=3D3D"MsoNormal">He sent me two frequencies in private email. These w=
=3D
ere in the FM<br>broadcast band (in the US). He probably needs to notch the=3D
m out<br>in order to get adequate response.<br><br>As for wanting narrow ba=3D
ndwidth - I am not quite sure why he thinks<br>

that is a benefit. I use a large FFT (about 10 Hz per bin) and use<br>the z=3D
oom control to see fine detail. (Different FFT settings suite<br>different =3D
uses. This one seems to be a good compromise with my two<br>needs. I&#39;m =3D
too lazy to change it.)<br>

<br>{^_^}<u></u><u></u></p><div><div><p class=3D3D"MsoNormal"><br><br><br>On =
=3D
2013/10/22 02:08, Sylvain Munaut wrote:<u></u><u></u></p><blockquote style=3D
=3D3D"border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;m=
=3D
argin-left:4.8pt;margin-right:0cm">

<p class=3D3D"MsoNormal">Effective filtering must occur between antenna and r=
=3D
eceiver. All the<br>problems that a saturated preamp and ADC cause can&rsqu=3D
o;t be repaired by<br>software. Never.<u></u><u></u></p></blockquote><p cla=3D
ss=3D3D"MsoNormal" style=3D3D"margin-bottom:12.0pt">

<br>But his original problem is not with saturated preamps or ADC ... it&#3=3D
9;s<br>aliasing ... and that can be solved in the digital domain provided<b=3D
r>fast enough ADC.<br><br>Cheers,<br><br>&nbsp; &nbsp; Sylvain<br><br><u></=3D
u><u></u></p>

</div></div></div><p class=3D3D"MsoNormal"><u></u>&nbsp;<u></u></p></div></di=
=3D
v></div></div></div><p class=3D3D"MsoNormal"><u></u>&nbsp;<u></u></p></div></=
=3D
div></div></div></div></div></blockquote></div><br></div>

--001a11346d7c0fd5fd04f20c4ef9--


--===============6137272094599311877==--


From laforge@osmocom.org Mon Jan  3 22:46:48 2022
From: Harald Welte <laforge@osmocom.org>
To: osmocom-sdr@lists.osmocom.org
Subject: lists.osmocom.org migrated to mailman3
Date: Mon, 03 Jan 2022 23:46:41 +0100
Message-ID: <YdN80UeYK2eZizNU@nataraja>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5909219952207807829=="

--===============5909219952207807829==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Dear Osmocom community,

today our mailing list server lists.osmocom.org has finally been migrated
from mailman2-on-freebsd to mailman3-on-linux.  This also included a variety
of changes to DNS.  I'll spare you the details, but everything _should_ be up
and running now.

* The List-Id headers should not have changed.

* all list subscriptions + user accounts have been converted.

* old 'static html' archives are still available (read only) at URLs like
  https://lists.osmocom.org/pipermail/baseband-devel/

* old List URLs like https://lists.osmocom.org/mailman/listinfo/baseband-devel
  are redirected to their respective modern counterparts

In case you notice any mailing list related problem, please don't hesitate to
contact me.

Happy hacking,
	Harald

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

--===============5909219952207807829==--


From martin-osmocom@earth.li Tue Jan  4 05:24:41 2022
From: Martin Ling <martin-osmocom@earth.li>
To: osmocom-sdr@lists.osmocom.org
Subject: [PATCH] Show readable error when hackrf start/stop fails
Date: Tue, 04 Jan 2022 05:24:38 +0000
Message-ID: <YdPaFsuvlf7JsESN@earth.li>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6616560504594136171=="

--===============6616560504594136171==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Error codes from libhackrf are not very legible, and in the case of
HACKRF_ERROR_LIBUSB, don't uniquely describe the cause of the error.

Calling hackrf_error_name() provides a human-readable message, and
in the case of libusb errors, identifies the actual cause rather than
just indicating that the error came from libusb.

This came up whilst trying to diagnose a libhackrf bug which showed
up when using libhackrf, via gr-osmosdr, via gqrx:
https://github.com/greatscottgadgets/hackrf/issues/883
---
 lib/hackrf/hackrf_source_c.cc | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/hackrf/hackrf_source_c.cc b/lib/hackrf/hackrf_source_c.cc
index 03ea3bd..2826924 100644
--- a/lib/hackrf/hackrf_source_c.cc
+++ b/lib/hackrf/hackrf_source_c.cc
@@ -170,7 +170,8 @@ bool hackrf_source_c::start()
   hackrf_common::start();
   int ret =3D hackrf_start_rx( _dev.get(), _hackrf_rx_callback, (void *)this=
 );
   if ( ret !=3D HACKRF_SUCCESS ) {
-    std::cerr << "Failed to start RX streaming (" << ret << ")" << std::endl;
+    const char *msg =3D hackrf_error_name( (enum hackrf_error) ret );
+    std::cerr << "Failed to start RX streaming (" << ret << ": " << msg << "=
)" << std::endl;
     return false;
   }
   return true;
@@ -184,7 +185,8 @@ bool hackrf_source_c::stop()
   hackrf_common::stop();
   int ret =3D hackrf_stop_rx( _dev.get() );
   if ( ret !=3D HACKRF_SUCCESS ) {
-    std::cerr << "Failed to stop RX streaming (" << ret << ")" << std::endl;
+    const char *msg =3D hackrf_error_name( (enum hackrf_error) ret );
+    std::cerr << "Failed to stop RX streaming (" << ret << ": " << msg << ")=
" << std::endl;
     return false;
   }
   return true;
--=20
2.30.2




--===============6616560504594136171==--


From jvde.github@gmail.com Sat Jan  8 16:53:46 2022
From: Jasper van den Eshof <jvde.github@gmail.com>
To: osmocom-sdr@lists.osmocom.org
Subject: [PATCH] librtlsdr: force wait state after lib_cancel_transfer to
 avoid crash on close in windows
Date: Sat, 08 Jan 2022 17:53:31 +0100
Message-ID:
 <CAE+DOAuf8qyi55ef9dFAh=HGJRUCffw_yvZZYD+OCKMFDgzo-w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2311053355788086150=="

--===============2311053355788086150==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Good day!

I was struggling with an occasional crash of the rtl-sdr tools on
windows when closing the device after pressing CTRL-C. Both with the
versions as provided with VCPKG and when directly compiling the latest
version in MSVC (with latest of libusb). It is a bit difficult to spot
a crash at close as usually it is silent but you can see it running it
from MSVC  or in a debugger. It does not happen always but frequent
enough.

Also, consider this example for the binary versions from Jan 2
(https://ftp.osmocom.org/binaries/windows/rtl-sdr/):

C:\>rtl_adsb.exe
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
....
Signal caught, exiting!

User cancel, exiting...

C:\>echo %ERRORLEVEL%
-1073741819

After investigation of the libusb logs and experimentation I think
this crash can be avoided by 1) defining zerotv in rtlsdr_read_async
as 1 ms instead of zero (see libusb/libusb#1043) or 2) include a short
call to Sleep to allow async operations to finish. Please find below a
patch for the latter fix for your consideration.

More information, here: https://github.com/osmocom/rtl-sdr/pull/18 and
here: https://github.com/libusb/libusb/issues/1043
Thanks for your great work on the rtlsdr library and kind regards.


Author: jvde.github <jvde.github(a)gmail.com>
Date:   Sat Jan 8 13:30:34 2022 +0100

    force wait state after cancel of usb transfer and before handling usb eve=
nts

diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 0146298..2682d77 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -1930,6 +1930,9 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev,
rtlsdr_read_async_cb_t cb, void *ctx,
                                        /* handle events after canceling
                                         * to allow transfer status to
                                         * propagate */
+#ifdef _WIN32
+                                       Sleep(1);
+#endif

libusb_handle_events_timeout_completed(dev->ctx,

        &zerotv, NULL);
                                        if (r < 0)

--===============2311053355788086150==--


From steve@steve-m.de Sat Jan  8 19:59:33 2022
From: Steve Markgraf <steve@steve-m.de>
To: osmocom-sdr@lists.osmocom.org
Subject: Re: [PATCH] librtlsdr: force wait state after lib_cancel_transfer to
 avoid crash on close in windows
Date: Sat, 08 Jan 2022 20:59:28 +0100
Message-ID: <64d9dbb0-17ef-8a6f-9ccc-6d95c1b8a0f9@steve-m.de>
In-Reply-To:
 <CAE+DOAuf8qyi55ef9dFAh=HGJRUCffw_yvZZYD+OCKMFDgzo-w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6546026560440316491=="

--===============6546026560440316491==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi Jasper,

thanks for your patch, I've just merged it.

Best Regards,
Steve

--===============6546026560440316491==--


From jvde.github@gmail.com Mon Jan 10 21:08:51 2022
From: Jasper <jvde.github@gmail.com>
To: osmocom-sdr@lists.osmocom.org
Subject: Re: [PATCH] librtlsdr: force wait state after lib_cancel_transfer to
 avoid crash on close in windows
Date: Mon, 10 Jan 2022 21:08:48 +0000
Message-ID: <164184892875.16665.5262666000088032977@lists>
In-Reply-To: <64d9dbb0-17ef-8a6f-9ccc-6d95c1b8a0f9@steve-m.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3874851290000796978=="

--===============3874851290000796978==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Thank you Steve.

For the async to be really watertight we probably cannot assume that all the =
callbacks are executed directly after the cancels without delay. I have been =
 playing with a variation below that  waits for all callbacks to be finished =
based on counting the number of transfers cancelled. This requires a bit more=
 testing as has more code changes.=20

For now the short Sleep has solved my issues on Windows. with device close. T=
hank you for merging it.

Kind regards, Jasper

Author: jvde.github <jvde.github(a)gmail.com>
Date:   Mon Jan 10 21:40:48 2022 +0100

    rework async_wait to ensure all events handled at close

diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 2682d77..a4ae212 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -125,6 +125,7 @@ struct rtlsdr_dev {
 	int dev_lost;
 	int driver_active;
 	unsigned int xfer_errors;
+	int xfer_cb_cancel_count;
 };
=20
 void rtlsdr_set_gpio_bit(rtlsdr_dev_t *dev, uint8_t gpio, int val);
@@ -1706,8 +1707,11 @@ static void LIBUSB_CALL _libusb_callback(struct libusb=
_transfer *xfer)
 			dev->cb(xfer->buffer, xfer->actual_length, dev->cb_ctx);
=20
 		libusb_submit_transfer(xfer); /* resubmit transfer */
+
 		dev->xfer_errors =3D 0;
-	} else if (LIBUSB_TRANSFER_CANCELLED !=3D xfer->status) {
+	} else if (LIBUSB_TRANSFER_CANCELLED =3D=3D xfer->status) {
+		dev->xfer_cb_cancel_count++;
+	} else {
 #ifndef _WIN32
 		if (LIBUSB_TRANSFER_ERROR =3D=3D xfer->status)
 			dev->xfer_errors++;
@@ -1853,9 +1857,9 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_as=
ync_cb_t cb, void *ctx,
 {
 	unsigned int i;
 	int r =3D 0;
+	int ret =3D 0;
+	int cancel_count =3D 0;
 	struct timeval tv =3D { 1, 0 };
-	struct timeval zerotv =3D { 0, 0 };
-	enum rtlsdr_async_status next_status =3D RTLSDR_INACTIVE;
=20
 	if (!dev)
 		return -1;
@@ -1865,6 +1869,7 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_as=
ync_cb_t cb, void *ctx,
=20
 	dev->async_status =3D RTLSDR_RUNNING;
 	dev->async_cancel =3D 0;
+	dev->xfer_cb_cancel_count =3D 0; /* number of cancelled transfers */
=20
 	dev->cb =3D cb;
 	dev->cb_ctx =3D ctx;
@@ -1881,6 +1886,7 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_as=
ync_cb_t cb, void *ctx,
=20
 	_rtlsdr_alloc_async_buffers(dev);
=20
+	/* creating initial submits */
 	for(i =3D 0; i < dev->xfer_buf_num; ++i) {
 		libusb_fill_bulk_transfer(dev->xfer[i],
 					  dev->devh,
@@ -1890,7 +1896,6 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_as=
ync_cb_t cb, void *ctx,
 					  _libusb_callback,
 					  (void *)dev,
 					  BULK_TIMEOUT);
-
 		r =3D libusb_submit_transfer(dev->xfer[i]);
 		if (r < 0) {
 			fprintf(stderr, "Failed to submit transfer %i\n"
@@ -1900,62 +1905,44 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_=
async_cb_t cb, void *ctx,
 					"echo 0 > /sys/module/usbcore"
 					"/parameters/usbfs_memory_mb\n", i);
 			dev->async_status =3D RTLSDR_CANCELING;
+			ret =3D r;
 			break;
 		}
 	}
=20
-	while (RTLSDR_INACTIVE !=3D dev->async_status) {
-		r =3D libusb_handle_events_timeout_completed(dev->ctx, &tv,
-							   &dev->async_cancel);
+	/* handling events until device is cancelled */
+	while (RTLSDR_CANCELING !=3D dev->async_status) {
+		r =3D libusb_handle_events_timeout_completed(dev->ctx, &tv, &dev->async_ca=
ncel);
+
 		if (r < 0) {
-			/*fprintf(stderr, "handle_events returned: %d\n", r);*/
+
 			if (r =3D=3D LIBUSB_ERROR_INTERRUPTED) /* stray signal */
 				continue;
+			ret =3D r;
 			break;
 		}
+	}
=20
-		if (RTLSDR_CANCELING =3D=3D dev->async_status) {
-			next_status =3D RTLSDR_INACTIVE;
-
-			if (!dev->xfer)
-				break;
-
-			for(i =3D 0; i < dev->xfer_buf_num; ++i) {
-				if (!dev->xfer[i])
-					continue;
-
-				if (LIBUSB_TRANSFER_CANCELLED !=3D
-						dev->xfer[i]->status) {
-					r =3D libusb_cancel_transfer(dev->xfer[i]);
-					/* handle events after canceling
-					 * to allow transfer status to
-					 * propagate */
-#ifdef _WIN32
-					Sleep(1);
-#endif
-					libusb_handle_events_timeout_completed(dev->ctx,
-									       &zerotv, NULL);
-					if (r < 0)
-						continue;
+	/* cancel and count all transfers */
+	for(i =3D 0; i < dev->xfer_buf_num; ++i) {
=20
-					next_status =3D RTLSDR_CANCELING;
-				}
-			}
+		if(dev->xfer[i]) {
=20
-			if (dev->dev_lost || RTLSDR_INACTIVE =3D=3D next_status) {
-				/* handle any events that still need to
-				 * be handled before exiting after we
-				 * just cancelled all transfers */
-				libusb_handle_events_timeout_completed(dev->ctx,
-								       &zerotv, NULL);
-				break;
-			}
+			r =3D libusb_cancel_transfer(dev->xfer[i]);
+			if (r =3D=3D 0) cancel_count++;
 		}
 	}
=20
+	/* handle events but expect at least "cancelled" CB calls with LIBUSB_TRANS=
FER_CANCELLED */
+	do
+	{
+		libusb_handle_events_timeout(dev->ctx, &tv);
+	}
+	while (dev->xfer_cb_cancel_count !=3D cancel_count);
+
 	_rtlsdr_free_async_buffers(dev);
=20
-	dev->async_status =3D next_status;
+	dev->async_status =3D RTLSDR_INACTIVE;
=20
 	return r;
 }

--===============3874851290000796978==--


From argilo@gmail.com Sat Jan 15 16:30:40 2022
From: argilo@gmail.com
To: osmocom-sdr@lists.osmocom.org
Subject: [PATCH] Stop applying workaround for libusb < 1.0.9
Date: Sat, 15 Jan 2022 16:30:39 +0000
Message-ID: <164226423972.16665.4562403919809155430@lists>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2574393591935801082=="

--===============2574393591935801082==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

From: Clayton Smith <argilo(a)gmail.com>

Librtlsdr has a workaround for libusb versions that lack
libusb_handle_events_timeout_completed, which was added in version 1.0.9
(released 2012-04-02). The workaround is always applied unless the
HAVE_LIBUSB_HANDLE_EVENTS_TIMEOUT_COMPLETED macro is set, but the cmake
code that sets this macro was removed in
849f8efca42b659bf7e8fe17156ee0aa67b47233. As a result, the workaround is
now always applied. This results in an extra 1-second delay whenever a
GNU Radio flowgraph containing an RTL-SDR block is stopped, which makes
operations like switching between demodulators in Gqrx annoyingly slow.

To solve this problem, I've simply removed the workaround, as it should
no longer be needed.

I wonder if perhaps the workaround recently applied in
2659e2df31e592d74d6dd264a4f5ce242c6369c8 might stem from the same bug.
---
 src/librtlsdr.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 2682d77ec2..096abaeffc 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -39,12 +39,6 @@
 #define LIBUSB_CALL
 #endif
 
-/* libusb < 1.0.9 doesn't have libusb_handle_events_timeout_completed */
-#ifndef HAVE_LIBUSB_HANDLE_EVENTS_TIMEOUT_COMPLETED
-#define libusb_handle_events_timeout_completed(ctx, tv, c) \
-	libusb_handle_events_timeout(ctx, tv)
-#endif
-
 /* two raised to the power of n */
 #define TWO_POW(n)		((double)(1ULL<<(n)))
 
-- 
2.25.1

--===============2574393591935801082==--


From steve@steve-m.de Wed Jan 19 17:01:57 2022
From: Steve Markgraf <steve@steve-m.de>
To: osmocom-sdr@lists.osmocom.org
Subject: Re: [PATCH] Stop applying workaround for libusb < 1.0.9
Date: Wed, 19 Jan 2022 18:01:54 +0100
Message-ID: <8e16b4d6-332e-6910-36e1-7506080ca052@steve-m.de>
In-Reply-To: <164226423972.16665.4562403919809155430@lists>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3506272714828909230=="

--===============3506272714828909230==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,

On 15.01.22 17:30, argilo(a)gmail.com wrote:
> From: Clayton Smith <argilo(a)gmail.com>
> 
> Librtlsdr has a workaround for libusb versions that lack
> libusb_handle_events_timeout_completed, which was added in version 1.0.9
> (released 2012-04-02). The workaround is always applied unless the
> HAVE_LIBUSB_HANDLE_EVENTS_TIMEOUT_COMPLETED macro is set, but the cmake
> code that sets this macro was removed in
> 849f8efca42b659bf7e8fe17156ee0aa67b47233. As a result, the workaround is
> now always applied. This results in an extra 1-second delay whenever a
> GNU Radio flowgraph containing an RTL-SDR block is stopped, which makes
> operations like switching between demodulators in Gqrx annoyingly slow.
> 
> To solve this problem, I've simply removed the workaround, as it should
> no longer be needed.


Thank you, merged.

Regards,
Steve

--===============3506272714828909230==--


From martin-osmocom@earth.li Thu Jan 20 12:40:51 2022
From: Martin Ling <martin-osmocom@earth.li>
To: osmocom-sdr@lists.osmocom.org
Subject: Re: [PATCH] librtlsdr: force wait state after lib_cancel_transfer to
 avoid crash on close in windows
Date: Thu, 20 Jan 2022 12:40:47 +0000
Message-ID: <YelYTzu7ZH2A551d@earth.li>
In-Reply-To: <164184892875.16665.5262666000088032977@lists>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4235881208745578887=="

--===============4235881208745578887==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Jasper,

It was interesting to read your below, because I have just been tackling=20
more or less exactly the same issue in libhackrf [0].

It looks like you're on the right track for fixing it.

In our case there were two orthogonal problems. One was that we weren't
waiting for all the cancellations to complete, which you've addressed
temporarily with the sleep, and are now tackling properly by counting
out the cancelled transfers.

Our other problem was that libhackrf was running libusb_cancel_transfer
from the API call that stops the capture - which gets called from a
different thread, so there was a race in which the USB handling thread
could resubmit a transfer that had just completed while the
cancellations were going on.

I've just looked at librtlsdr and it seems it's immune to the latter
problem, because rtlsdr_cancel_async() just sets a flag, and the actual
cancellation is done from the same thread that handles libusb events
after the handling has been interrupted.

That approach is a lot simpler, but does mean that you have a delay
involved, because libusb_handle_events_timeout_completed() has to either
see an event or time out, before it will notice the flag and break out
of its loop.

That delay could be eliminated though by having rtlsdr_cancel_async()
call libusb_interrupt_event_handler() after setting async_cancel =3D 1.
That might be a change worth making, although I guess the delay is
short if there is plenty of data flowing.

I'm going to try adopting librtlsdr's approach for libhackrf, as it
seems a lot simpler.

Regards,


Martin

[0] https://github.com/greatscottgadgets/hackrf/pull/1029

On Mon, Jan 10, 2022 at 09:08:48PM -0000, Jasper  wrote:
>=20
> Thank you Steve.
>=20
> For the async to be really watertight we probably cannot assume that all th=
e callbacks are executed directly after the cancels without delay. I have bee=
n  playing with a variation below that  waits for all callbacks to be finishe=
d based on counting the number of transfers cancelled. This requires a bit mo=
re testing as has more code changes.=20
>=20
> For now the short Sleep has solved my issues on Windows. with device close.=
 Thank you for merging it.
>=20
> Kind regards, Jasper
>=20
> Author: jvde.github <jvde.github(a)gmail.com>
> Date:   Mon Jan 10 21:40:48 2022 +0100
>=20
>     rework async_wait to ensure all events handled at close
>=20
> diff --git a/src/librtlsdr.c b/src/librtlsdr.c
> index 2682d77..a4ae212 100644
> --- a/src/librtlsdr.c
> +++ b/src/librtlsdr.c
> @@ -125,6 +125,7 @@ struct rtlsdr_dev {
>  	int dev_lost;
>  	int driver_active;
>  	unsigned int xfer_errors;
> +	int xfer_cb_cancel_count;
>  };
> =20
>  void rtlsdr_set_gpio_bit(rtlsdr_dev_t *dev, uint8_t gpio, int val);
> @@ -1706,8 +1707,11 @@ static void LIBUSB_CALL _libusb_callback(struct libu=
sb_transfer *xfer)
>  			dev->cb(xfer->buffer, xfer->actual_length, dev->cb_ctx);
> =20
>  		libusb_submit_transfer(xfer); /* resubmit transfer */
> +
>  		dev->xfer_errors =3D 0;
> -	} else if (LIBUSB_TRANSFER_CANCELLED !=3D xfer->status) {
> +	} else if (LIBUSB_TRANSFER_CANCELLED =3D=3D xfer->status) {
> +		dev->xfer_cb_cancel_count++;
> +	} else {
>  #ifndef _WIN32
>  		if (LIBUSB_TRANSFER_ERROR =3D=3D xfer->status)
>  			dev->xfer_errors++;
> @@ -1853,9 +1857,9 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_=
async_cb_t cb, void *ctx,
>  {
>  	unsigned int i;
>  	int r =3D 0;
> +	int ret =3D 0;
> +	int cancel_count =3D 0;
>  	struct timeval tv =3D { 1, 0 };
> -	struct timeval zerotv =3D { 0, 0 };
> -	enum rtlsdr_async_status next_status =3D RTLSDR_INACTIVE;
> =20
>  	if (!dev)
>  		return -1;
> @@ -1865,6 +1869,7 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_=
async_cb_t cb, void *ctx,
> =20
>  	dev->async_status =3D RTLSDR_RUNNING;
>  	dev->async_cancel =3D 0;
> +	dev->xfer_cb_cancel_count =3D 0; /* number of cancelled transfers */
> =20
>  	dev->cb =3D cb;
>  	dev->cb_ctx =3D ctx;
> @@ -1881,6 +1886,7 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_=
async_cb_t cb, void *ctx,
> =20
>  	_rtlsdr_alloc_async_buffers(dev);
> =20
> +	/* creating initial submits */
>  	for(i =3D 0; i < dev->xfer_buf_num; ++i) {
>  		libusb_fill_bulk_transfer(dev->xfer[i],
>  					  dev->devh,
> @@ -1890,7 +1896,6 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_=
async_cb_t cb, void *ctx,
>  					  _libusb_callback,
>  					  (void *)dev,
>  					  BULK_TIMEOUT);
> -
>  		r =3D libusb_submit_transfer(dev->xfer[i]);
>  		if (r < 0) {
>  			fprintf(stderr, "Failed to submit transfer %i\n"
> @@ -1900,62 +1905,44 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_rea=
d_async_cb_t cb, void *ctx,
>  					"echo 0 > /sys/module/usbcore"
>  					"/parameters/usbfs_memory_mb\n", i);
>  			dev->async_status =3D RTLSDR_CANCELING;
> +			ret =3D r;
>  			break;
>  		}
>  	}
> =20
> -	while (RTLSDR_INACTIVE !=3D dev->async_status) {
> -		r =3D libusb_handle_events_timeout_completed(dev->ctx, &tv,
> -							   &dev->async_cancel);
> +	/* handling events until device is cancelled */
> +	while (RTLSDR_CANCELING !=3D dev->async_status) {
> +		r =3D libusb_handle_events_timeout_completed(dev->ctx, &tv, &dev->async_=
cancel);
> +
>  		if (r < 0) {
> -			/*fprintf(stderr, "handle_events returned: %d\n", r);*/
> +
>  			if (r =3D=3D LIBUSB_ERROR_INTERRUPTED) /* stray signal */
>  				continue;
> +			ret =3D r;
>  			break;
>  		}
> +	}
> =20
> -		if (RTLSDR_CANCELING =3D=3D dev->async_status) {
> -			next_status =3D RTLSDR_INACTIVE;
> -
> -			if (!dev->xfer)
> -				break;
> -
> -			for(i =3D 0; i < dev->xfer_buf_num; ++i) {
> -				if (!dev->xfer[i])
> -					continue;
> -
> -				if (LIBUSB_TRANSFER_CANCELLED !=3D
> -						dev->xfer[i]->status) {
> -					r =3D libusb_cancel_transfer(dev->xfer[i]);
> -					/* handle events after canceling
> -					 * to allow transfer status to
> -					 * propagate */
> -#ifdef _WIN32
> -					Sleep(1);
> -#endif
> -					libusb_handle_events_timeout_completed(dev->ctx,
> -									       &zerotv, NULL);
> -					if (r < 0)
> -						continue;
> +	/* cancel and count all transfers */
> +	for(i =3D 0; i < dev->xfer_buf_num; ++i) {
> =20
> -					next_status =3D RTLSDR_CANCELING;
> -				}
> -			}
> +		if(dev->xfer[i]) {
> =20
> -			if (dev->dev_lost || RTLSDR_INACTIVE =3D=3D next_status) {
> -				/* handle any events that still need to
> -				 * be handled before exiting after we
> -				 * just cancelled all transfers */
> -				libusb_handle_events_timeout_completed(dev->ctx,
> -								       &zerotv, NULL);
> -				break;
> -			}
> +			r =3D libusb_cancel_transfer(dev->xfer[i]);
> +			if (r =3D=3D 0) cancel_count++;
>  		}
>  	}
> =20
> +	/* handle events but expect at least "cancelled" CB calls with LIBUSB_TRA=
NSFER_CANCELLED */
> +	do
> +	{
> +		libusb_handle_events_timeout(dev->ctx, &tv);
> +	}
> +	while (dev->xfer_cb_cancel_count !=3D cancel_count);
> +
>  	_rtlsdr_free_async_buffers(dev);
> =20
> -	dev->async_status =3D next_status;
> +	dev->async_status =3D RTLSDR_INACTIVE;
> =20
>  	return r;
>  }
>=20



--===============4235881208745578887==--


From argilo@gmail.com Sun Jan 23 02:01:38 2022
From: argilo@gmail.com
To: osmocom-sdr@lists.osmocom.org
Subject: [PATCH] rfspace: Add PPM correction
Date: Sat, 22 Jan 2022 21:01:16 -0500
Message-ID: <20220123020116.219009-1-argilo@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7097480461261654244=="

--===============7097480461261654244==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

From: Clayton Smith <argilo(a)gmail.com>

This patch was originally written by Alexandru Csete and posted at
https://github.com/csete/gr-osmosdr-gqrx/commit/d66df300. The only
change I made was to rename the _freq_corr_ppm variable to
_freq_corr, since many other devices use that name.

This patch used to be included in Gqrx releases, so it should work
correctly.
---
 lib/rfspace/rfspace_source_c.cc | 17 +++++++++++++----
 lib/rfspace/rfspace_source_c.h  |  2 ++
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/lib/rfspace/rfspace_source_c.cc b/lib/rfspace/rfspace_source_c.cc
index 314dfc732d..113588a5d4 100644
--- a/lib/rfspace/rfspace_source_c.cc
+++ b/lib/rfspace/rfspace_source_c.cc
@@ -103,6 +103,7 @@ rfspace_source_c::rfspace_source_c (const std::string &ar=
gs)
     _nchan(1),
     _sample_rate(NAN),
     _bandwidth(0.0f),
+    _freq_corr(0.0),
     _fifo(NULL)
 {
   std::string host =3D "";
@@ -446,6 +447,8 @@ rfspace_source_c::rfspace_source_c (const std::string &ar=
gs)
     _thread =3D gr::thread::thread( boost::bind(&rfspace_source_c::tcp_keepa=
live_task, this) );
   }
=20
+  _center_freq =3D get_center_freq();
+
 #if 0
   std::cerr << "sample_rates: " << get_sample_rates().to_pp_string() << std:=
:endl;
   std::cerr << "sample rate: " << (uint32_t)get_sample_rate() << std::endl;
@@ -600,7 +603,7 @@ static size_t read_bytes( int fd, char *data, size_t size=
, bool &run )
     int nread =3D read( fd, &data[nbytes], 1 );
=20
     if ( nread =3D=3D 0 )
-      continue;  =20
+      continue;
=20
     if ( nread < 0 )
       break;
@@ -1378,7 +1381,10 @@ osmosdr::freq_range_t rfspace_source_c::get_freq_range=
( size_t chan )
=20
 double rfspace_source_c::set_center_freq( double freq, size_t chan )
 {
-  uint32_t u32_freq =3D freq;
+  uint32_t u32_freq;
+
+  u32_freq =3D freq * (1.0 + _freq_corr * 0.000001);
+  _center_freq =3D freq;
=20
   /* SDR-IQ 5.2.2 Receiver Frequency */
   /* SDR-IP 4.2.2 Receiver Frequency */
@@ -1395,7 +1401,7 @@ double rfspace_source_c::set_center_freq( double freq, =
size_t chan )
=20
   transaction( tune, sizeof(tune) );
=20
-  return get_center_freq( chan );
+  return _center_freq;
 }
=20
 double rfspace_source_c::get_center_freq( size_t chan )
@@ -1423,12 +1429,15 @@ double rfspace_source_c::get_center_freq( size_t chan=
 )
=20
 double rfspace_source_c::set_freq_corr( double ppm, size_t chan )
 {
+  _freq_corr =3D ppm;
+  set_center_freq( _center_freq, chan );
+
   return get_freq_corr( chan );
 }
=20
 double rfspace_source_c::get_freq_corr( size_t chan )
 {
-  return 0;
+  return _freq_corr;
 }
=20
 std::vector<std::string> rfspace_source_c::get_gain_names( size_t chan )
diff --git a/lib/rfspace/rfspace_source_c.h b/lib/rfspace/rfspace_source_c.h
index 996f47b392..42bb6de6ac 100644
--- a/lib/rfspace/rfspace_source_c.h
+++ b/lib/rfspace/rfspace_source_c.h
@@ -145,6 +145,8 @@ private: /* members */
   size_t _nchan;
   double _sample_rate;
   double _bandwidth;
+  double _center_freq;
+  double _freq_corr;
=20
   gr::thread::thread _thread;
   bool _run_usb_read_task;
--=20
2.25.1


--===============7097480461261654244==--


From jvde.github@gmail.com Sun Jan 23 18:08:18 2022
From: Jasper <jvde.github@gmail.com>
To: osmocom-sdr@lists.osmocom.org
Subject: Re: [PATCH] librtlsdr: force wait state after lib_cancel_transfer to
 avoid crash on close in windows
Date: Sun, 23 Jan 2022 18:08:17 +0000
Message-ID: <164296129730.16665.902783667724313475@lists>
In-Reply-To: <YelYTzu7ZH2A551d@earth.li>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6771132897225234594=="

--===============6771132897225234594==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Martin,

Many thanks for sharing the insights.=20

For my understanding, librtlsdr uses libusb_handle_events_timeout_completed w=
hich should terminate early if the dev->async_cancel flag is set. Is there st=
ill a purpose to call libusb_interrupt_event_handler in this case or is it re=
quired to guarantee the handler inspects the flag immediately, before any tim=
eout or a new event (i.e. like a notification)? That did not became clear to =
me from the libusb documentation.

The easiest way I can see now to assess we can safely free up the transfers i=
s to count the live transfers (increase a counter by one if there was a succe=
ssful resubmit) and reduce by one at the start of a libusb callback. It is th=
en safe to terminate if the counter is zero.  I have implemented that here: h=
ttps://github.com/jvde-github/rtl-sdr/commit/325d47f1f3c1d9fbece9877034828355=
748ddd5c

Seems to work really well but given the various versions of libusb and suppor=
ted platforms around, I am hesitant to submit as patch until it solves a repo=
rted problem.

Thanks, Jasper

--===============6771132897225234594==--


From martin-osmocom@earth.li Sun Jan 23 23:16:09 2022
From: Martin Ling <martin-osmocom@earth.li>
To: osmocom-sdr@lists.osmocom.org
Subject: Re: [PATCH] librtlsdr: force wait state after lib_cancel_transfer to
 avoid crash on close in windows
Date: Sun, 23 Jan 2022 23:16:03 +0000
Message-ID: <Ye3hs84KiWf9paS+@earth.li>
In-Reply-To: <164296129730.16665.902783667724313475@lists>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0140003560135392803=="

--===============0140003560135392803==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 23, 2022 at 06:08:17PM -0000, Jasper  wrote:
>=20
> For my understanding, librtlsdr uses
> libusb_handle_events_timeout_completed which should terminate early if
> the dev->async_cancel flag is set. Is there still a purpose to call
> libusb_interrupt_event_handler in this case or is it required to
> guarantee the handler inspects the flag immediately, before any
> timeout or a new event (i.e. like a notification)? That did not became
> clear to me from the libusb documentation.

Just passing libusb_handle_events_completed() a pointer to the flag
doesn't give it any way to be notified or interrupted when that flag is
changed. It only gives it the ability to look at that flag when it
chooses to - which will be when it's just handled some event and is
deciding whether to wait for another.

Calling libusb_interrupt_event_handler() will interrupt whatever poll()
or similar call libusb_handle_events_completed() is blocked in, causing
it to inspect the flag and return if it's set.

Otherwise, the flag will only be inspected at the next iteration of the
event loop (i.e. when some USB event occurs, or a timeout expires). In
practice that may happen soon anyway, but I still think it makes sense
to interrupt the handler to ensure there is no unnecessary delay.

> The easiest way I can see now to assess we can safely free up the
> transfers is to count the live transfers (increase a counter by one if
> there was a successful resubmit) and reduce by one at the start of a
> libusb callback. It is then safe to terminate if the counter is zero.

The counting approach seems reasonable to me.

In my case I kept a boolean flag for each individual transfer, and
signalled completion once all of the transfers were flagged as finished.
This was partly because when debugging I wanted to be able to see the
state of each transfer.

But in retrospect a count would suffice, and is much simpler, so I think
I'll probably adopt that approach too.

> I have implemented that here:
> https://github.com/jvde-github/rtl-sdr/commit/325d47f1f3c1d9fbece9877034828=
355748ddd5c

I've looked at this version and I see one potential failure mode.

It's the same as one of the problems I tackled on libhackrf - the one I
previously said you were immune to, due to cancellation and event
handling being in the same thread.

On closer inspection though, I think it can still go wrong as follows:

When libusb_cancel_transfer() is called, it's possible that one of the
transfers has just completed at the kernel level - but not yet had its
completion callback called, because the event handling was interrupted
before that happened.

In this case libusb_cancel_transfer() returns LIBUSB_ERROR_NOT_FOUND,
because that transfer is no longer available to be cancelled.

You don't check the result of libusb_cancel_transfer().  But actually
even if you did, there isn't anything very helpful you can do with the
result at that stage. The real problem occurs later - read on.

Next, when libusb_handle_events_timeout_completed() is called again at
line 1930, to await the cancellation callbacks, the completion of that
transfer is still pending and now gets processed - so _libusb_callback()
gets called.

The status seen by _libusb_callback() will be LIBUSB_TRANSFER_COMPLETED,
so the transfer gets resubmitted and the transfer count reincremented.

This then repeats indefinitely - there is no logic in the callback to
prevent a completed transfer being resubmitted, so the same transfer
will be constantly resubmitted and re-run, and live_transfers will
never reach zero.

My suggested fix would be to check dev->async_cancel in the callback,
and not resubmit a transfer if that flag is set.

> Seems to work really well but given the various versions of libusb and
> supported platforms around, I am hesitant to submit as patch until it
> solves a reported problem.

I am very much of the opinion that once concurrency issues are
identified, they want fixing proactively fixed even if the potential
failures aren't being observed in practice.

When failures do occur they can be extremely hard to track down because
of the timing dependency. It's taken multiple reports of intermittent,
hard-to-reproduce problems, over a long period, for us to zero in on
these issues in libhackrf.

We got to a point where only one diligent reporter could reproduce a
failure, that seemed to only show up with their particular distro,
hardware, software versions etc.

Eventually I managed to reproduce it myself, but still had to drill down
through all the layers of gqrx, gr, osmosdr & libhackrf to figure out
what was going wrong.

Having spotted these problems, I say let's fix them properly while we
have the chance.

Regards,


Martin

--===============0140003560135392803==--


From jvde.github@gmail.com Mon Jan 24 18:24:16 2022
From: Jasper <jvde.github@gmail.com>
To: osmocom-sdr@lists.osmocom.org
Subject: [PATCH] fix build issue on macOS by adding libusb shared lib
 directory to search path
Date: Mon, 24 Jan 2022 18:24:13 +0000
Message-ID: <164304865387.16665.12305033469972756780@lists>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2721745460923956892=="

--===============2721745460923956892==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi all, on some systems building librtlsdr can fail when libusb-1.0 is not in=
stalled in the standard library locations (e.g. macOS with libusb installed v=
ia homebrew can have the shared library in /usr/local/Cellar/libusb/1.0.24/li=
b).

The below patch includes LIBUSB_LIBRARY_DIRS in the search path for the linke=
r to correct this issue.=20

For your kind consideration. Thanks, Jasper

Author: jvde.github <jvde.github(a)gmail.com>
Date:   Mon Jan 24 19:21:44 2022 +0100

    fix build for macOS

diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 7b47309..3b8060b 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -21,6 +21,7 @@
 add_library(rtlsdr SHARED librtlsdr.c
   tuner_e4k.c tuner_fc0012.c tuner_fc0013.c tuner_fc2580.c tuner_r82xx.c)
 target_link_libraries(rtlsdr ${LIBUSB_LIBRARIES} ${THREADS_PTHREADS_LIBRARY})
+target_link_directories(rtlsdr PUBLIC ${LIBUSB_LIBRARY_DIRS})
 target_include_directories(rtlsdr PUBLIC
   $<BUILD_INTERFACE:${CMAKE_SOURCE_DIR}/include>
   $<INSTALL_INTERFACE:include>  # <prefix>/include

--===============2721745460923956892==--


From jvde.github@gmail.com Mon Jan 24 18:28:41 2022
From: Jasper <jvde.github@gmail.com>
To: osmocom-sdr@lists.osmocom.org
Subject: Re: [PATCH] librtlsdr: force wait state after lib_cancel_transfer to
 avoid crash on close in windows
Date: Mon, 24 Jan 2022 18:28:39 +0000
Message-ID: <164304891966.16665.14962125386054788203@lists>
In-Reply-To: <Ye3hs84KiWf9paS+@earth.li>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8441070315395416126=="

--===============8441070315395416126==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Thanks Martin. This is helpful. I will do some more automatic testing (starti=
ng/stopping) on a few systems and then submit a patch for consideration.

Regards, Jasper

--===============8441070315395416126==--


From jvde.github@gmail.com Mon Jan 24 19:22:48 2022
From: Jasper <jvde.github@gmail.com>
To: osmocom-sdr@lists.osmocom.org
Subject: [PATCH] count number of open transfers and ensure zero open transfers
 before freeing memory
Date: Mon, 24 Jan 2022 19:22:46 +0000
Message-ID: <164305216696.16665.9392065191825908662@lists>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7891128082297276993=="

--===============7891128082297276993==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

As per discussion with Martin Ling on this mailing list, please find below a =
proposed patch that simplifies the async_read,  keeps track of open tranfers =
and checks for zero open transfers before closing to avoid unidentified behav=
iour at close.

Thanks, Jasper

commit 4b06ae321e91296f13355a0715e9a961b4f57e45
Author: jvde.github <jvde.github(a)gmail.com>
Date:   Mon Jan 24 20:15:34 2022 +0100

    count live transfers before close

diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 096abae..67e30c4 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -119,6 +119,7 @@ struct rtlsdr_dev {
 	int dev_lost;
 	int driver_active;
 	unsigned int xfer_errors;
+	int live_transfers;
 };
=20
 void rtlsdr_set_gpio_bit(rtlsdr_dev_t *dev, uint8_t gpio, int val);
@@ -1695,11 +1696,15 @@ static void LIBUSB_CALL _libusb_callback(struct libus=
b_transfer *xfer)
 {
 	rtlsdr_dev_t *dev =3D (rtlsdr_dev_t *)xfer->user_data;
=20
+	dev->live_transfers --;
+
 	if (LIBUSB_TRANSFER_COMPLETED =3D=3D xfer->status) {
 		if (dev->cb)
 			dev->cb(xfer->buffer, xfer->actual_length, dev->cb_ctx);
=20
-		libusb_submit_transfer(xfer); /* resubmit transfer */
+		if(!dev->async_cancel)
+			if( libusb_submit_transfer(xfer) =3D=3D 0) /* resubmit transfer */
+				dev->live_transfers++;
 		dev->xfer_errors =3D 0;
 	} else if (LIBUSB_TRANSFER_CANCELLED !=3D xfer->status) {
 #ifndef _WIN32
@@ -1847,9 +1852,9 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_as=
ync_cb_t cb, void *ctx,
 {
 	unsigned int i;
 	int r =3D 0;
+	int ret =3D 0;
 	struct timeval tv =3D { 1, 0 };
-	struct timeval zerotv =3D { 0, 0 };
-	enum rtlsdr_async_status next_status =3D RTLSDR_INACTIVE;
+	struct timeval canceltv =3D { 0, 50 };
=20
 	if (!dev)
 		return -1;
@@ -1863,6 +1868,7 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_as=
ync_cb_t cb, void *ctx,
 	dev->cb =3D cb;
 	dev->cb_ctx =3D ctx;
=20
+
 	if (buf_num > 0)
 		dev->xfer_buf_num =3D buf_num;
 	else
@@ -1875,6 +1881,8 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_as=
ync_cb_t cb, void *ctx,
=20
 	_rtlsdr_alloc_async_buffers(dev);
=20
+	dev->live_transfers =3D 0;
+
 	for(i =3D 0; i < dev->xfer_buf_num; ++i) {
 		libusb_fill_bulk_transfer(dev->xfer[i],
 					  dev->devh,
@@ -1894,64 +1902,41 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_=
async_cb_t cb, void *ctx,
 					"echo 0 > /sys/module/usbcore"
 					"/parameters/usbfs_memory_mb\n", i);
 			dev->async_status =3D RTLSDR_CANCELING;
+			ret =3D -3;
 			break;
 		}
+		else
+			dev->live_transfers++;
 	}
=20
-	while (RTLSDR_INACTIVE !=3D dev->async_status) {
+	while (RTLSDR_RUNNING =3D=3D dev->async_status) {
 		r =3D libusb_handle_events_timeout_completed(dev->ctx, &tv,
-							   &dev->async_cancel);
+			&dev->async_cancel);
 		if (r < 0) {
 			/*fprintf(stderr, "handle_events returned: %d\n", r);*/
 			if (r =3D=3D LIBUSB_ERROR_INTERRUPTED) /* stray signal */
 				continue;
-			break;
+			rtlsdr_cancel_async(dev);
+			ret =3D -4;
 		}
+	}
=20
-		if (RTLSDR_CANCELING =3D=3D dev->async_status) {
-			next_status =3D RTLSDR_INACTIVE;
+	if (!dev->xfer) return -5;
=20
-			if (!dev->xfer)
-				break;
+	for(i =3D 0; i < dev->xfer_buf_num; ++i)
+		if (dev->xfer[i])
+			libusb_cancel_transfer(dev->xfer[i]);
=20
-			for(i =3D 0; i < dev->xfer_buf_num; ++i) {
-				if (!dev->xfer[i])
-					continue;
+	for (i =3D 0; i < dev->xfer_buf_num && dev->live_transfers > 0; ++i)
+		libusb_handle_events_timeout_completed(dev->ctx, &canceltv, NULL);
=20
-				if (LIBUSB_TRANSFER_CANCELLED !=3D
-						dev->xfer[i]->status) {
-					r =3D libusb_cancel_transfer(dev->xfer[i]);
-					/* handle events after canceling
-					 * to allow transfer status to
-					 * propagate */
-#ifdef _WIN32
-					Sleep(1);
-#endif
-					libusb_handle_events_timeout_completed(dev->ctx,
-									       &zerotv, NULL);
-					if (r < 0)
-						continue;
-
-					next_status =3D RTLSDR_CANCELING;
-				}
-			}
-
-			if (dev->dev_lost || RTLSDR_INACTIVE =3D=3D next_status) {
-				/* handle any events that still need to
-				 * be handled before exiting after we
-				 * just cancelled all transfers */
-				libusb_handle_events_timeout_completed(dev->ctx,
-								       &zerotv, NULL);
-				break;
-			}
-		}
-	}
+	if(dev->live_transfers > 0) return -6;
=20
 	_rtlsdr_free_async_buffers(dev);
=20
-	dev->async_status =3D next_status;
+	dev->async_status =3D RTLSDR_INACTIVE;
=20
-	return r;
+	return ret;
 }
=20
 int rtlsdr_cancel_async(rtlsdr_dev_t *dev)

--===============7891128082297276993==--


From jvde.github@gmail.com Wed Jan 26 18:13:50 2022
From: Jasper <jvde.github@gmail.com>
To: osmocom-sdr@lists.osmocom.org
Subject: [PATCH] call libsub_intertrupt_event_handler in rtlsdr_cancel_async
Date: Wed, 26 Jan 2022 18:13:48 +0000
Message-ID: <164322082818.16665.11298631265944083884@lists>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5967723677132537805=="

--===============5967723677132537805==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Please find below a patch as per suggestion of Martin Ling: call libusb_inter=
rupt_event_handler in rtlsdr_cancel_async to trigger the event loop handler t=
o look at the async_cancel variable.
(https://lists.osmocom.org/hyperkitty/list/osmocom-sdr(a)lists.osmocom.org/th=
read/7TKOAOP5KNQBBCDJRV7EI67AFKEDTNCP/)

I have tested timings on a windows 11 machine with and without the patch when=
 running a async transfer at two different sampling rates:

sample rate	with		without		theory
1536K		0 - 2 ms	0 - 84 ms	85 ms
288K		0 - 4 ms	0 - 457 ms	455 ms

The table shows the range of timings to cancel the async transfer as measured=
 over a couple of runs.
The "theory" column shows the theoretical time to complete one transfer at th=
e particular sampling rate (i.e. driven by the size of a transfer buffer). An=
d indeed, on some machines it appears that cancelling the async transfer, if =
unlucky, can take as much time as waiting for a full transfer to complete. Th=
e call to libsub_intertrupt_event_handler fixes that. For large transfer buff=
ers and/or low sample rates this can make a difference.

Thanks to Martin for sharing the insight.

Jasper

Author: jvde.github <jvde.github(a)gmail.com>
Date:   Wed Jan 26 19:00:55 2022 +0100

    call interrupt_event_handler in cancel_async

diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 67e30c4..b949692 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -1948,6 +1948,9 @@ int rtlsdr_cancel_async(rtlsdr_dev_t *dev)
        if (RTLSDR_RUNNING =3D=3D dev->async_status) {
                dev->async_status =3D RTLSDR_CANCELING;
                dev->async_cancel =3D 1;
+
+               libusb_interrupt_event_handler(dev->ctx);
+
                return 0;
        }

--===============5967723677132537805==--