From adrian at freebsd.org  Mon Nov  9 18:03:23 2020
From: adrian at freebsd.org (Adrian Chadd)
Date: Mon,  9 Nov 2020 10:03:23 -0800
Subject: [PATCH] [hackrf] Fix hackrf receive hangs by checking before each
 lock wait
Message-ID: <20201109180323.57497-1-adrian@freebsd.org>

Fix receive path hangs if another thread closes down the hackrf
receive whilst this buffer receive function is waiting to be
woken up.

Now:

* Sleep for up to 100ms each time waiting for the cond to be kicked;
* Check whether streaming is still enabled each time rather than
  only when the function is entered.

This fixes hangs where consumers like gqrx via gnuradio
will do a stop_rx/start_rx very quickly to change something, and
the buffer receive path is waiting for a buffer.
---
 lib/hackrf/hackrf_source_c.cc | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/lib/hackrf/hackrf_source_c.cc b/lib/hackrf/hackrf_source_c.cc
index 662d04a..21656f9 100644
--- a/lib/hackrf/hackrf_source_c.cc
+++ b/lib/hackrf/hackrf_source_c.cc
@@ -30,6 +30,7 @@
 
 #include <stdexcept>
 #include <iostream>
+#include <chrono>
 
 #include <gnuradio/io_signature.h>
 
@@ -203,8 +204,22 @@ int hackrf_source_c::work( int noutput_items,
   {
     std::unique_lock<std::mutex> lock(_buf_mutex);
 
-    while (_buf_used < 3 && running) // collect at least 3 buffers
-      _buf_cond.wait( lock );
+    // XXX adrian - tomorrow, turn this loop into a wait_for (1 second)
+    // and re-check dev.get / running !
+    // Otherwise this will hang reasonably reliably if we race where
+    // receive is stopped in one thread, and we've already passed
+    // the hackrf_is_streaming() check; we'll never finish this loop
+    // and consumers (eg gqrx) will fail.
+
+    while (_buf_used < 3 && running) { // collect at least 3 buffers
+      _buf_cond.wait_for( lock , std::chrono::milliseconds(100));
+
+      // Re-check whether the device has closed or stopped streaming
+      if ( _dev.get() )
+        running = (hackrf_is_streaming( _dev.get() ) == HACKRF_TRUE);
+      else
+        running = false;
+    }
   }
 
   if ( ! running )
-- 
2.28.0



From adrian at freebsd.org  Mon Nov  9 18:04:08 2020
From: adrian at freebsd.org (Adrian Chadd)
Date: Mon, 9 Nov 2020 10:04:08 -0800
Subject: [PATCH] [hackrf] Fix hackrf receive hangs by checking before each
 lock wait
In-Reply-To: <20201109180323.57497-1-adrian@freebsd.org>
References: <20201109180323.57497-1-adrian@freebsd.org>
Message-ID: <CAJ-Vmok3eyOJTR7nJzOCPpH9ZH2HNnbROdE1W5uy+Dq84_k=5A@mail.gmail.com>

Err, weirdly I thought I had updated this commit to remove the
comment; lemme do that and resend.


-a

On Mon, 9 Nov 2020 at 10:03, Adrian Chadd <adrian at freebsd.org> wrote:
>
> Fix receive path hangs if another thread closes down the hackrf
> receive whilst this buffer receive function is waiting to be
> woken up.
>
> Now:
>
> * Sleep for up to 100ms each time waiting for the cond to be kicked;
> * Check whether streaming is still enabled each time rather than
>   only when the function is entered.
>
> This fixes hangs where consumers like gqrx via gnuradio
> will do a stop_rx/start_rx very quickly to change something, and
> the buffer receive path is waiting for a buffer.
> ---
>  lib/hackrf/hackrf_source_c.cc | 19 +++++++++++++++++--
>  1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/lib/hackrf/hackrf_source_c.cc b/lib/hackrf/hackrf_source_c.cc
> index 662d04a..21656f9 100644
> --- a/lib/hackrf/hackrf_source_c.cc
> +++ b/lib/hackrf/hackrf_source_c.cc
> @@ -30,6 +30,7 @@
>
>  #include <stdexcept>
>  #include <iostream>
> +#include <chrono>
>
>  #include <gnuradio/io_signature.h>
>
> @@ -203,8 +204,22 @@ int hackrf_source_c::work( int noutput_items,
>    {
>      std::unique_lock<std::mutex> lock(_buf_mutex);
>
> -    while (_buf_used < 3 && running) // collect at least 3 buffers
> -      _buf_cond.wait( lock );
> +    // XXX adrian - tomorrow, turn this loop into a wait_for (1 second)
> +    // and re-check dev.get / running !
> +    // Otherwise this will hang reasonably reliably if we race where
> +    // receive is stopped in one thread, and we've already passed
> +    // the hackrf_is_streaming() check; we'll never finish this loop
> +    // and consumers (eg gqrx) will fail.
> +
> +    while (_buf_used < 3 && running) { // collect at least 3 buffers
> +      _buf_cond.wait_for( lock , std::chrono::milliseconds(100));
> +
> +      // Re-check whether the device has closed or stopped streaming
> +      if ( _dev.get() )
> +        running = (hackrf_is_streaming( _dev.get() ) == HACKRF_TRUE);
> +      else
> +        running = false;
> +    }
>    }
>
>    if ( ! running )
> --
> 2.28.0
>


From adrian at freebsd.org  Mon Nov  9 18:04:26 2020
From: adrian at freebsd.org (Adrian Chadd)
Date: Mon,  9 Nov 2020 10:04:26 -0800
Subject: [PATCH] [hackrf] Fix hackrf receive hangs by checking before each
 lock wait
Message-ID: <20201109180426.57557-1-adrian@freebsd.org>

Fix receive path hangs if another thread closes down the hackrf
receive whilst this buffer receive function is waiting to be
woken up.

Now:

* Sleep for up to 100ms each time waiting for the cond to be kicked;
* Check whether streaming is still enabled each time rather than
  only when the function is entered.

This fixes hangs where consumers like gqrx via gnuradio
will do a stop_rx/start_rx very quickly to change something, and
the buffer receive path is waiting for a buffer.
---
 lib/hackrf/hackrf_source_c.cc | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/lib/hackrf/hackrf_source_c.cc b/lib/hackrf/hackrf_source_c.cc
index 662d04a..03ea3bd 100644
--- a/lib/hackrf/hackrf_source_c.cc
+++ b/lib/hackrf/hackrf_source_c.cc
@@ -30,6 +30,7 @@
 
 #include <stdexcept>
 #include <iostream>
+#include <chrono>
 
 #include <gnuradio/io_signature.h>
 
@@ -203,8 +204,15 @@ int hackrf_source_c::work( int noutput_items,
   {
     std::unique_lock<std::mutex> lock(_buf_mutex);
 
-    while (_buf_used < 3 && running) // collect at least 3 buffers
-      _buf_cond.wait( lock );
+    while (_buf_used < 3 && running) { // collect at least 3 buffers
+      _buf_cond.wait_for( lock , std::chrono::milliseconds(100));
+
+      // Re-check whether the device has closed or stopped streaming
+      if ( _dev.get() )
+        running = (hackrf_is_streaming( _dev.get() ) == HACKRF_TRUE);
+      else
+        running = false;
+    }
   }
 
   if ( ! running )
-- 
2.28.0



From dchardware at gmail.com  Wed Nov 11 20:16:10 2020
From: dchardware at gmail.com (Sipos Csaba)
Date: Wed, 11 Nov 2020 21:16:10 +0100
Subject: [patch]: add xtrx support
Message-ID: <CALQr=E--zTH+harHVPeXHbwBgariKC0E4v6NJHtF+QPGeuiDBg@mail.gmail.com>

Dear Eric,

About two weeks ago I sent in a patch that adds XTRX support to gr-osmosdr.
I wanted to ask if there is any problem with it, or maybe there are some
other reasons it did not get merged?

Please let me know if any further work is needed.

Regards,
Csaba
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20201111/d245f7b5/attachment.htm>

From argilo at gmail.com  Wed Nov 18 12:51:54 2020
From: argilo at gmail.com (argilo at gmail.com)
Date: Wed, 18 Nov 2020 07:51:54 -0500
Subject: [PATCH] Add back pkg-config
Message-ID: <20201118125154.30327-1-argilo@gmail.com>

From: Clayton Smith <argilo at gmail.com>

When gr-osmosdr was updated to GNU Radio 3.8, generation of
gnuradio-osmosdr.pc was removed. Other software uses pkg-config to find
gr-osmosdr, so I think we should add it back.

This fixes http://osmocom.org/issues/4423
---
 CMakeLists.txt         | 37 +++++++++++++++++++++++++++++++++++++
 gnuradio-osmosdr.pc.in | 15 +++++++++++++++
 2 files changed, 52 insertions(+)
 create mode 100644 gnuradio-osmosdr.pc.in

diff --git a/CMakeLists.txt b/CMakeLists.txt
index c23cb49530..868057dcc8 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -275,6 +275,43 @@ if(ENABLE_PYTHON)
 endif(ENABLE_PYTHON)
 add_subdirectory(docs)
 
+########################################################################
+# Create Pkg Config File
+########################################################################
+FOREACH(inc ${Boost_INCLUDE_DIRS})
+    LIST(APPEND GR_OSMOSDR_PC_CFLAGS "-I${inc}")
+ENDFOREACH(inc)
+
+FOREACH(lib ${Boost_LIBRARY_DIRS})
+    LIST(APPEND GR_OSMOSDR_PC_LIBS "-L${lib}")
+ENDFOREACH(lib)
+
+# use space-separation format for the pc file
+STRING(REPLACE ";" " " GR_OSMOSDR_PC_REQUIRES "${GR_OSMOSDR_PC_REQUIRES}")
+STRING(REPLACE ";" " " GR_OSMOSDR_PC_CFLAGS "${GR_OSMOSDR_PC_CFLAGS}")
+STRING(REPLACE ";" " " GR_OSMOSDR_PC_LIBS "${GR_OSMOSDR_PC_LIBS}")
+
+# unset these vars to avoid hard-coded paths to cross environment
+IF(CMAKE_CROSSCOMPILING)
+    UNSET(GR_OSMOSDR_PC_CFLAGS)
+    UNSET(GR_OSMOSDR_PC_LIBS)
+ENDIF(CMAKE_CROSSCOMPILING)
+
+# fake gnuradio cpack behavior as long as we don't use it directly
+set(CPACK_PACKAGE_NAME "gnuradio-osmosdr")
+set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "GNU Radio block for various radio hardware")
+set(CPACK_PACKAGE_VERSION ${VERSION})
+
+CONFIGURE_FILE(
+    ${CMAKE_CURRENT_SOURCE_DIR}/gnuradio-osmosdr.pc.in
+    ${CMAKE_CURRENT_BINARY_DIR}/gnuradio-osmosdr.pc
+ at ONLY)
+
+INSTALL(
+    FILES ${CMAKE_CURRENT_BINARY_DIR}/gnuradio-osmosdr.pc
+    DESTINATION ${GR_LIBRARY_DIR}/pkgconfig
+)
+
 ########################################################################
 # Print Summary
 ########################################################################
diff --git a/gnuradio-osmosdr.pc.in b/gnuradio-osmosdr.pc.in
new file mode 100644
index 0000000000..5f1ae694e3
--- /dev/null
+++ b/gnuradio-osmosdr.pc.in
@@ -0,0 +1,15 @@
+prefix=@CMAKE_INSTALL_PREFIX@
+exec_prefix=${prefix}
+libdir=${exec_prefix}/@GR_LIBRARY_DIR@
+includedir=${prefix}/@GR_INCLUDE_DIR@
+
+Name: @CPACK_PACKAGE_NAME@
+Description: @CPACK_PACKAGE_DESCRIPTION_SUMMARY@
+URL: http://sdr.osmocom.org/trac/wiki/GrOsmoSDR
+Version: @CPACK_PACKAGE_VERSION@
+Requires: gnuradio-runtime gnuradio-blocks
+Requires.private: @GR_OSMOSDR_PC_REQUIRES@
+Conflicts:
+Cflags: -I${includedir} @GR_OSMOSDR_PC_CFLAGS@
+Libs: -L${libdir} -lgnuradio-osmosdr
+Libs.private: @GR_OSMOSDR_PC_LIBS@
-- 
2.25.1



From 246tnt at gmail.com  Wed Nov 18 13:10:41 2020
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 18 Nov 2020 14:10:41 +0100
Subject: [PATCH] Add back pkg-config
In-Reply-To: <20201118125154.30327-1-argilo@gmail.com>
References: <20201118125154.30327-1-argilo@gmail.com>
Message-ID: <CAHL+j08w-2Pw1J82Xdcd55jir=mm6R7uokKEJ4qPmT5EzNH0ag@mail.gmail.com>

Other software should be fixed, not re-adding legacy to the code base.


From gdt at lexort.com  Wed Nov 18 14:14:30 2020
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 18 Nov 2020 09:14:30 -0500
Subject: [PATCH] Add back pkg-config
In-Reply-To: <CAHL+j08w-2Pw1J82Xdcd55jir=mm6R7uokKEJ4qPmT5EzNH0ag@mail.gmail.com>
 (Sylvain Munaut's message of "Wed, 18 Nov 2020 14:10:41 +0100")
References: <20201118125154.30327-1-argilo@gmail.com>
 <CAHL+j08w-2Pw1J82Xdcd55jir=mm6R7uokKEJ4qPmT5EzNH0ag@mail.gmail.com>
Message-ID: <rmiv9e2ycop.fsf@s1.lexort.com>


Sylvain Munaut <246tnt at gmail.com> writes:

>> From: Clayton Smith <argilo at gmail.com>

>> When gr-osmosdr was updated to GNU Radio 3.8, generation of
>> gnuradio-osmosdr.pc was removed. Other software uses pkg-config to find
>> gr-osmosdr, so I think we should add it back.

> Other software should be fixed, not re-adding legacy to the code base.

Since when are .pc files "legacy".  They have been the normal way for
build systems to find out about other packages for a long time, and I
think they are still normal.

Perhaps this is due to a view  that $SHINY_NEW_BUILD_SYSTEM
is the one true way and that any other software that does not
immediately change to that build  system is old - but if so I think
that's unresonable.

If you mean something else, please explain.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20201118/7a56eb14/attachment.bin>

From 246tnt at gmail.com  Wed Nov 18 14:57:16 2020
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 18 Nov 2020 15:57:16 +0100
Subject: [PATCH] Add back pkg-config
In-Reply-To: <rmiv9e2ycop.fsf@s1.lexort.com>
References: <20201118125154.30327-1-argilo@gmail.com>
 <CAHL+j08w-2Pw1J82Xdcd55jir=mm6R7uokKEJ4qPmT5EzNH0ag@mail.gmail.com>
 <rmiv9e2ycop.fsf@s1.lexort.com>
Message-ID: <CAHL+j0_0wQcj0J=shWoY0YaZFBf3_b8U3hzpSqhaF0dput2fog@mail.gmail.com>

I mean this is a gnuradio OOT, you can only use it with gnuradio.
And gnuradio now has its own way of finding oot that doesn't use the
.pc files, so there is no point in including one.
Whatever legacy gnuradio app still uses the .pc file should move to
the new way of gnuradio to do stuff.


On Wed, Nov 18, 2020 at 3:14 PM Greg Troxel <gdt at lexort.com> wrote:
>
>
> Sylvain Munaut <246tnt at gmail.com> writes:
>
> >> From: Clayton Smith <argilo at gmail.com>
>
> >> When gr-osmosdr was updated to GNU Radio 3.8, generation of
> >> gnuradio-osmosdr.pc was removed. Other software uses pkg-config to find
> >> gr-osmosdr, so I think we should add it back.
>
> > Other software should be fixed, not re-adding legacy to the code base.
>
> Since when are .pc files "legacy".  They have been the normal way for
> build systems to find out about other packages for a long time, and I
> think they are still normal.
>
> Perhaps this is due to a view  that $SHINY_NEW_BUILD_SYSTEM
> is the one true way and that any other software that does not
> immediately change to that build  system is old - but if so I think
> that's unresonable.
>
> If you mean something else, please explain.


From gdt at lexort.com  Wed Nov 18 15:14:44 2020
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 18 Nov 2020 10:14:44 -0500
Subject: [PATCH] Add back pkg-config
In-Reply-To: <CAHL+j0_0wQcj0J=shWoY0YaZFBf3_b8U3hzpSqhaF0dput2fog@mail.gmail.com>
 (Sylvain Munaut's message of "Wed, 18 Nov 2020 15:57:16 +0100")
References: <20201118125154.30327-1-argilo@gmail.com>
 <CAHL+j08w-2Pw1J82Xdcd55jir=mm6R7uokKEJ4qPmT5EzNH0ag@mail.gmail.com>
 <rmiv9e2ycop.fsf@s1.lexort.com>
 <CAHL+j0_0wQcj0J=shWoY0YaZFBf3_b8U3hzpSqhaF0dput2fog@mail.gmail.com>
Message-ID: <rmipn4awvbv.fsf@s1.lexort.com>


Sylvain Munaut <246tnt at gmail.com> writes:

> I mean this is a gnuradio OOT, you can only use it with gnuradio.
> And gnuradio now has its own way of finding oot that doesn't use the
> .pc files, so there is no point in including one.
> Whatever legacy gnuradio app still uses the .pc file should move to
> the new way of gnuradio to do stuff.

Thanks; that makes sense.  I am used to seeing osmo stuff used in the
rtl-sdr world, but I guess not this module.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20201118/d094da02/attachment.bin>

From ewild at sysmocom.de  Wed Nov 18 15:45:18 2020
From: ewild at sysmocom.de (Eric Wild)
Date: Wed, 18 Nov 2020 16:45:18 +0100
Subject: [patch]: add xtrx support
In-Reply-To: <CALQr=E--zTH+harHVPeXHbwBgariKC0E4v6NJHtF+QPGeuiDBg@mail.gmail.com>
References: <CALQr=E--zTH+harHVPeXHbwBgariKC0E4v6NJHtF+QPGeuiDBg@mail.gmail.com>
Message-ID: <3e52c232-31cf-a147-cf85-786792f05752@sysmocom.de>

Hi Csaba,

as far as I know I've merged that patch quite some time ago - it took 
some time because I've tried to give my fairly old xtrx prototype a go 
first.

-Eric



From adrian at freebsd.org  Wed Nov 18 15:52:43 2020
From: adrian at freebsd.org (Adrian Chadd)
Date: Wed, 18 Nov 2020 07:52:43 -0800
Subject: [PATCH] [hackrf] Fix hackrf receive hangs by checking before each
 lock wait
In-Reply-To: <20201109180426.57557-1-adrian@freebsd.org>
References: <20201109180426.57557-1-adrian@freebsd.org>
Message-ID: <CAJ-Vmo=LXFmYc2ZOGXLKxqdeY0Yq7=sLEq4tZh864dwPkqqU4A@mail.gmail.com>

hi!

It's been a week and a half; I don't suppose I could get some feedback
on this? :-)

Thanks!



-adrian

On Mon, 9 Nov 2020 at 10:04, Adrian Chadd <adrian at freebsd.org> wrote:
>
> Fix receive path hangs if another thread closes down the hackrf
> receive whilst this buffer receive function is waiting to be
> woken up.
>
> Now:
>
> * Sleep for up to 100ms each time waiting for the cond to be kicked;
> * Check whether streaming is still enabled each time rather than
>   only when the function is entered.
>
> This fixes hangs where consumers like gqrx via gnuradio
> will do a stop_rx/start_rx very quickly to change something, and
> the buffer receive path is waiting for a buffer.
> ---
>  lib/hackrf/hackrf_source_c.cc | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/lib/hackrf/hackrf_source_c.cc b/lib/hackrf/hackrf_source_c.cc
> index 662d04a..03ea3bd 100644
> --- a/lib/hackrf/hackrf_source_c.cc
> +++ b/lib/hackrf/hackrf_source_c.cc
> @@ -30,6 +30,7 @@
>
>  #include <stdexcept>
>  #include <iostream>
> +#include <chrono>
>
>  #include <gnuradio/io_signature.h>
>
> @@ -203,8 +204,15 @@ int hackrf_source_c::work( int noutput_items,
>    {
>      std::unique_lock<std::mutex> lock(_buf_mutex);
>
> -    while (_buf_used < 3 && running) // collect at least 3 buffers
> -      _buf_cond.wait( lock );
> +    while (_buf_used < 3 && running) { // collect at least 3 buffers
> +      _buf_cond.wait_for( lock , std::chrono::milliseconds(100));
> +
> +      // Re-check whether the device has closed or stopped streaming
> +      if ( _dev.get() )
> +        running = (hackrf_is_streaming( _dev.get() ) == HACKRF_TRUE);
> +      else
> +        running = false;
> +    }
>    }
>
>    if ( ! running )
> --
> 2.28.0
>


From dchardware at gmail.com  Wed Nov 18 16:15:48 2020
From: dchardware at gmail.com (Sipos Csaba)
Date: Wed, 18 Nov 2020 17:15:48 +0100
Subject: [patch]: add xtrx support
In-Reply-To: <3e52c232-31cf-a147-cf85-786792f05752@sysmocom.de>
References: <CALQr=E--zTH+harHVPeXHbwBgariKC0E4v6NJHtF+QPGeuiDBg@mail.gmail.com>
 <3e52c232-31cf-a147-cf85-786792f05752@sysmocom.de>
Message-ID: <CALQr=E9j3mjLTm+Lyje6Ra66-+c7OQV_fQsm53uEW0Ct+CVeXw@mail.gmail.com>

Hi Eric,

Thanks for the answer.

I may be mistaken, but looking at the gr-osmosdr master here
http://cgit.osmocom.org/gr-osmosdr/ , I can't seem to find my xtrx support
patch merged. That is why I asked if there is any problem with it. Am I
looking at the wrong place?

Regards,
Csaba

Eric Wild <ewild at sysmocom.de> ezt ?rta (id?pont: 2020. nov. 18., Sze,
16:45):

> Hi Csaba,
>
> as far as I know I've merged that patch quite some time ago - it took
> some time because I've tried to give my fairly old xtrx prototype a go
> first.
>
> -Eric
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20201118/47f650d7/attachment.htm>

From ewild at sysmocom.de  Wed Nov 18 16:20:06 2020
From: ewild at sysmocom.de (Eric Wild)
Date: Wed, 18 Nov 2020 17:20:06 +0100
Subject: [patch]: add xtrx support
In-Reply-To: <CALQr=E9j3mjLTm+Lyje6Ra66-+c7OQV_fQsm53uEW0Ct+CVeXw@mail.gmail.com>
References: <CALQr=E--zTH+harHVPeXHbwBgariKC0E4v6NJHtF+QPGeuiDBg@mail.gmail.com>
 <3e52c232-31cf-a147-cf85-786792f05752@sysmocom.de>
 <CALQr=E9j3mjLTm+Lyje6Ra66-+c7OQV_fQsm53uEW0Ct+CVeXw@mail.gmail.com>
Message-ID: <afec3c01-1e8c-134d-3d5a-bd30c2a63d39@sysmocom.de>

Oh no, you might be right, looks like I accidentally dropped it while 
reordering the patches - I'll fix that later today...

Am 18.11.2020 um 17:15 schrieb Sipos Csaba:
> Hi Eric,
>
> Thanks for the answer.
>
> I may be mistaken, but looking at the gr-osmosdr master here 
> http://cgit.osmocom.org/gr-osmosdr/ 
> <http://cgit.osmocom.org/gr-osmosdr/> , I can't seem to find my xtrx 
> support patch merged. That is why I asked if there is any problem with 
> it. Am I looking at the wrong place?
>
> Regards,
> Csaba
>
> Eric Wild <ewild at sysmocom.de <mailto:ewild at sysmocom.de>> ezt ?rta 
> (id?pont: 2020. nov. 18., Sze, 16:45):
>
>     Hi Csaba,
>
>     as far as I know I've merged that patch quite some time ago - it took
>     some time because I've tried to give my fairly old xtrx prototype
>     a go
>     first.
>
>     -Eric
>

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