[Discuss-gnuradio] Installation issue -gnuradio-companion disable

[Yong Jang]

During installation gnuradio, I encounter this issue. It seems
gnuradio-companion is not enable.
I found this recommendation though, it is not simple to install cheetah and
lxml.
Numpy is installed for sure in my VM(Ubuntu 14.04), but not sure of cheetah
and lxml.


Any advices welcomes

Thanks,
Harold
--
GNU Radio Companion

   - for the GNU Radio Companion (GRC) you need to install python-numpy,
   python-cheetah and python-lxml



--

harold@ubuntu:~/Documents/gr_source/build$ cmake ../
-- Build type set to Release.
-- Extracting version information from git describe...
-- Compiler Version: cc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-- Compiler Flags: /usr/bin/cc:::-O3 -DNDEBUG  -fvisibility=hidden
-Wsign-compare -Wall -Wno-uninitialized
/usr/bin/c++:::-O3 -DNDEBUG  -fvisibility=hidden -Wsign-compare -Wall
-Wno-uninitialized
-- ADDING PERF COUNTERS
-- Building Static Libraries: OFF
-- Boost version: 1.54.0
-- Found the following Boost libraries:
--   date_time
--   program_options
--   filesystem
--   system
--   thread
-- 
-- Checking for module SWIG
-- Found SWIG version 2.0.11.
-- Requested SWIG version is at least .
-- Disabling SWIG because version check failed.
-- 
-- The build system will automatically enable all components.
-- Use -DENABLE_DEFAULT=OFF to disable components by default.
-- 
-- Configuring python-support support...
--   Dependency PYTHONLIBS_FOUND = TRUE
--   Dependency SWIG_FOUND = FALSE
--   Dependency SWIG_VERSION_CHECK = FALSE
--   Disabling python-support support.
--   Override with -DENABLE_PYTHON=ON/OFF
-- 
-- Configuring testing-support support...
--   Dependency CPPUNIT_FOUND = TRUE
--   Enabling testing-support support.
--   Override with -DENABLE_TESTING=ON/OFF
-- 
-- Configuring VOLK support...
-- Build type set to Release.
-- Extracting version information from git describe...
-- 
-- Python checking for python >= 2.5
-- Python checking for python >= 2.5 - found
-- 
-- Python checking for Cheetah >= 2.0.0
-- Python checking for Cheetah >= 2.0.0 - found
-- Boost version: 1.54.0
-- Found the following Boost libraries:
--   filesystem
--   system
--   unit_test_framework
--   program_options
-- checking for module 'orc-0.4 > 0.4.11'
--   package 'orc-0.4 > 0.4.11' not found
-- orc files (missing:  ORC_LIBRARY ORC_INCLUDE_DIR ORCC_EXECUTABLE)
-- QA Testing is enabled.
--   Modify using: -DENABLE_TESTING=ON/OFF
-- Compiler name: GNU
-- x86* CPU detected
-- ORC support not found, Overruled arch orc
-- CPU width is 64 bits, Overruled arch 32
-- Available architectures:
generic;64;3dnow;abm;popcount;mmx;fma;sse;sse2;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx;avx2
-- Available machines:
generic;sse2_64_mmx;sse3_64_mmx;ssse3_64_mmx;sse4_a_64_mmx;sse4_1_64_mmx;sse4_2_64_mmx;avx_64_mmx;avx2_64_mmx
-- BUILD TYPE = RELEASE
-- Base cflags = -O3 -DNDEBUG  -fvisibility=hidden -Wsign-compare -Wall
-Wno-uninitialized -Wall
-- BUILD INFO ::: generic ::: GNU ::: -O3 -DNDEBUG  -fvisibility=hidden
-Wsign-compare -Wall -Wno-uninitialized -Wall
-- BUILD INFO ::: sse2_64_mmx ::: GNU ::: -O3 -DNDEBUG  -fvisibility=hidden
-Wsign-compare -Wall -Wno-uninitialized -Wall -m64 -mmmx -msse -msse2
-- BUILD INFO ::: sse3_64_mmx ::: GNU ::: -O3 -DNDEBUG  -fvisibility=hidden
-Wsign-compare -Wall -Wno-uninitialized -Wall -m64 -mmmx -msse -msse2 -msse3
-- BUILD INFO ::: ssse3_64_mmx ::: GNU ::: -O3 -DNDEBUG
-fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64
-mmmx -msse -msse2 -msse3 -mssse3
-- BUILD INFO ::: sse4_a_64_mmx ::: GNU ::: -O3 -DNDEBUG
-fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64
-mmmx -msse -msse2 -msse3 -msse4a -mpopcnt
-- BUILD INFO ::: sse4_1_64_mmx ::: GNU ::: -O3 -DNDEBUG
-fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64
-mmmx -msse -msse2 -msse3 -mssse3 -msse4.1
-- BUILD INFO ::: sse4_2_64_mmx ::: GNU ::: -O3 -DNDEBUG
-fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64
-mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mpopcnt
-- BUILD INFO ::: avx_64_mmx ::: GNU ::: -O3 -DNDEBUG  -fvisibility=hidden
-Wsign-compare -Wall -Wno-uninitialized -Wall -m64 -mmmx -msse -msse2
-msse3 -mssse3 -msse4.1 -msse4.2 -mpopcnt -mavx
-- BUILD INFO ::: avx2_64_mmx ::: GNU ::: -O3 -DNDEBUG  -fvisibility=hidden
-Wsign-compare -Wall -Wno-uninitialized -Wall -m64 -mmmx -msse -msse2
-msse3 -mssse3 -msse4.1 -msse4.2 -mpopcnt -mavx -mfma -mavx2
-- Compiler Version: cc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-- c flags:  -fvisibility

Re: [Discuss-gnuradio] Installation issue -gnuradio-companion disable

[Patrick Sathyanathan]

>From the log below it may be because SWIG version check failed:


> -- Disabling SWIG because version check failed

and

> -- Configuring python-support support... 
> --   Dependency PYTHONLIBS_FOUND = TRUE 
> --   Dependency SWIG_FOUND = FALSE 
> --   Dependency SWIG_VERSION_CHECK = FALSE 
> --   Disabling python-support support. 
> --   Override with -DENABLE_PYTHON=ON/OFF 
>

You may need to install a later version of SWIG...

--Patrick

__
> Date: Thu, 7 Apr 2016 00:21:16 -0700 
> From: yj...@eng.ucsd.edu 
> To: Discuss-gnuradio@gnu.org 
> Subject: [Discuss-gnuradio] Installation issue -gnuradio-companion disable 
>  
> During installation gnuradio, I encounter this issue. It seems  
> gnuradio-companion is not enable. 
> I found this recommendation though, it is not simple to install cheetah  
> and lxml. 
> Numpy is installed for sure in my VM(Ubuntu 14.04), but not sure of  
> cheetah and lxml. 
>  
>  
> Any advices welcomes 
>  
> Thanks, 
> Harold 
> -- 
> GNU Radio Companion 
>  
>*   for the GNU Radio Companion (GRC) you need to install  
> python-numpy, python-cheetah and python-lxml 
>  
>  
> -- 
>  
> harold@ubuntu:~/Documents/gr_source/build$ cmake ../ 
> -- Build type set to Release. 
> -- Extracting version information from git describe... 
> -- Compiler Version: cc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4 
> Copyright (C) 2013 Free Software Foundation, Inc. 
> This is free software; see the source for copying conditions.  There is NO 
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 
> -- Compiler Flags: /usr/bin/cc:::-O3 -DNDEBUG  -fvisibility=hidden  
> -Wsign-compare -Wall -Wno-uninitialized 
> /usr/bin/c++:::-O3 -DNDEBUG  -fvisibility=hidden -Wsign-compare -Wall  
> -Wno-uninitialized 
> -- ADDING PERF COUNTERS 
> -- Building Static Libraries: OFF 
> -- Boost version: 1.54.0 
> -- Found the following Boost libraries: 
> --   date_time 
> --   program_options 
> --   filesystem 
> --   system 
> --   thread 
> --  
> -- Checking for module SWIG 
> -- Found SWIG version 2.0.11. 
> -- Requested SWIG version is at least . 
> -- Disabling SWIG because version check failed. 
> --  
> -- The build system will automatically enable all components. 
> -- Use -DENABLE_DEFAULT=OFF to disable components by default. 
> --  
> -- Configuring python-support support... 
> --   Dependency PYTHONLIBS_FOUND = TRUE 
> --   Dependency SWIG_FOUND = FALSE 
> --   Dependency SWIG_VERSION_CHECK = FALSE 
> --   Disabling python-support support. 
> --   Override with -DENABLE_PYTHON=ON/OFF 
> --  
> -- Configuring testing-support support... 
> --   Dependency CPPUNIT_FOUND = TRUE 
> --   Enabling testing-support support. 
> --   Override with -DENABLE_TESTING=ON/OFF 
> --  
> -- Configuring VOLK support... 
> -- Build type set to Release. 
> -- Extracting version information from git describe... 
> --  
> -- Python checking for python>= 2.5 
> -- Python checking for python>= 2.5 - found 
> --  
> -- Python checking for Cheetah>= 2.0.0 
> -- Python checking for Cheetah>= 2.0.0 - found 
> -- Boost version: 1.54.0 
> -- Found the following Boost libraries: 
> --   filesystem 
> --   system 
> --   unit_test_framework 
> --   program_options 
> -- checking for module 'orc-0.4> 0.4.11' 
> --   package 'orc-0.4> 0.4.11' not found 
> -- orc files (missing:  ORC_LIBRARY ORC_INCLUDE_DIR ORCC_EXECUTABLE) 
> -- QA Testing is enabled. 
> --   Modify using: -DENABLE_TESTING=ON/OFF 
> -- Compiler name: GNU 
> -- x86* CPU detected 
> -- ORC support not found, Overruled arch orc 
> -- CPU width is 64 bits, Overruled arch 32 
> -- Available architectures:  
> generic;64;3dnow;abm;popcount;mmx;fma;sse;sse2;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx;avx2
>  
> -- Available machines:  
> generic;sse2_64_mmx;sse3_64_mmx;ssse3_64_mmx;sse4_a_64_mmx;sse4_1_64_mmx;sse4_2_64_mmx;avx_64_mmx;avx2_64_mmx
>  
> -- BUILD TYPE = RELEASE 
> -- Base cflags = -O3 -DNDEBUG  -fvisibility=hidden -Wsign-compare -Wall  
> -Wno-uninitialized -Wall 
> -- BUILD INFO ::: generic ::: GNU ::: -O3 -DNDEBUG  -fvisibility=hidden  
> -Wsign-compare -Wall -Wno-uninitialized -Wall 
> -- BUILD INFO ::: sse2_64_mmx ::: GNU ::: -O3 -DNDEBUG   
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64  
> -mmmx -msse -msse2 
> -- BUILD INFO ::: sse3_64_mmx ::: GNU ::: -O3 -DNDEBUG   
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64  
> -mmmx -msse -msse2 -msse3 
> -- BUILD INFO ::: ssse3_64_mmx ::: GNU ::: -O3 -DNDEBUG   
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64  
> -mmmx -msse -msse2 -msse3 -mssse3 
> -- BUILD INFO ::: sse4_a_64_mmx ::: GNU ::: -O3 -DNDEBUG   
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64  
> -mmmx -msse -msse2 -msse3 -msse4a -mpopcnt 
> -- BUILD INFO ::: sse4_1_64_mmx ::: GNU ::: -O3 

Re: [Discuss-gnuradio] Installation issue -gnuradio-companion disable

[Geof Nieboer]

Harold,

The problem is not cheetah or lxml, the problem is SWIG.  It finds version
2.0.11, but rejects it ... the line about "Request SWIG version is at
least." is the hint, that line is called when SWIG is found but failed a
version check, what's odd is that SWIG_FIND_VERSION is unset... because
there should be a version number about "is at least."

What version of CMake are you running?

Geof

On Thu, Apr 7, 2016 at 10:21 AM, Yong Jang  wrote:

> During installation gnuradio, I encounter this issue. It seems
> gnuradio-companion is not enable.
> I found this recommendation though, it is not simple to install cheetah
> and lxml.
> Numpy is installed for sure in my VM(Ubuntu 14.04), but not sure of
> cheetah and lxml.
>
>
> Any advices welcomes
>
> Thanks,
> Harold
> --
> GNU Radio Companion
>
>- for the GNU Radio Companion (GRC) you need to install python-numpy,
>python-cheetah and python-lxml
>
>
>
> --
>
> harold@ubuntu:~/Documents/gr_source/build$ cmake ../
> -- Build type set to Release.
> -- Extracting version information from git describe...
> -- Compiler Version: cc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4
> Copyright (C) 2013 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> -- Compiler Flags: /usr/bin/cc:::-O3 -DNDEBUG  -fvisibility=hidden
> -Wsign-compare -Wall -Wno-uninitialized
> /usr/bin/c++:::-O3 -DNDEBUG  -fvisibility=hidden -Wsign-compare -Wall
> -Wno-uninitialized
> -- ADDING PERF COUNTERS
> -- Building Static Libraries: OFF
> -- Boost version: 1.54.0
> -- Found the following Boost libraries:
> --   date_time
> --   program_options
> --   filesystem
> --   system
> --   thread
> --
> -- Checking for module SWIG
> -- Found SWIG version 2.0.11.
> -- Requested SWIG version is at least .
> -- Disabling SWIG because version check failed.
> --
> -- The build system will automatically enable all components.
> -- Use -DENABLE_DEFAULT=OFF to disable components by default.
> --
> -- Configuring python-support support...
> --   Dependency PYTHONLIBS_FOUND = TRUE
> --   Dependency SWIG_FOUND = FALSE
> --   Dependency SWIG_VERSION_CHECK = FALSE
> --   Disabling python-support support.
> --   Override with -DENABLE_PYTHON=ON/OFF
> --
> -- Configuring testing-support support...
> --   Dependency CPPUNIT_FOUND = TRUE
> --   Enabling testing-support support.
> --   Override with -DENABLE_TESTING=ON/OFF
> --
> -- Configuring VOLK support...
> -- Build type set to Release.
> -- Extracting version information from git describe...
> --
> -- Python checking for python >= 2.5
> -- Python checking for python >= 2.5 - found
> --
> -- Python checking for Cheetah >= 2.0.0
> -- Python checking for Cheetah >= 2.0.0 - found
> -- Boost version: 1.54.0
> -- Found the following Boost libraries:
> --   filesystem
> --   system
> --   unit_test_framework
> --   program_options
> -- checking for module 'orc-0.4 > 0.4.11'
> --   package 'orc-0.4 > 0.4.11' not found
> -- orc files (missing:  ORC_LIBRARY ORC_INCLUDE_DIR ORCC_EXECUTABLE)
> -- QA Testing is enabled.
> --   Modify using: -DENABLE_TESTING=ON/OFF
> -- Compiler name: GNU
> -- x86* CPU detected
> -- ORC support not found, Overruled arch orc
> -- CPU width is 64 bits, Overruled arch 32
> -- Available architectures:
> generic;64;3dnow;abm;popcount;mmx;fma;sse;sse2;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx;avx2
> -- Available machines:
> generic;sse2_64_mmx;sse3_64_mmx;ssse3_64_mmx;sse4_a_64_mmx;sse4_1_64_mmx;sse4_2_64_mmx;avx_64_mmx;avx2_64_mmx
> -- BUILD TYPE = RELEASE
> -- Base cflags = -O3 -DNDEBUG  -fvisibility=hidden -Wsign-compare -Wall
> -Wno-uninitialized -Wall
> -- BUILD INFO ::: generic ::: GNU ::: -O3 -DNDEBUG  -fvisibility=hidden
> -Wsign-compare -Wall -Wno-uninitialized -Wall
> -- BUILD INFO ::: sse2_64_mmx ::: GNU ::: -O3 -DNDEBUG
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64
> -mmmx -msse -msse2
> -- BUILD INFO ::: sse3_64_mmx ::: GNU ::: -O3 -DNDEBUG
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64
> -mmmx -msse -msse2 -msse3
> -- BUILD INFO ::: ssse3_64_mmx ::: GNU ::: -O3 -DNDEBUG
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64
> -mmmx -msse -msse2 -msse3 -mssse3
> -- BUILD INFO ::: sse4_a_64_mmx ::: GNU ::: -O3 -DNDEBUG
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64
> -mmmx -msse -msse2 -msse3 -msse4a -mpopcnt
> -- BUILD INFO ::: sse4_1_64_mmx ::: GNU ::: -O3 -DNDEBUG
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64
> -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1
> -- BUILD INFO ::: sse4_2_64_mmx ::: GNU ::: -O3 -DNDEBUG
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64
> -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mpopcnt
> -- BUILD INFO ::: avx_6

Re: [Discuss-gnuradio] sine_table.h

[Marcus Müller]

Hi Trek,

as Martin noted, yes, if you search the GNU Radio source tree for that
file name, you'll find it. And also, yes, GNU Radio is Free Software,
and one of the main credos of that is that you should be able to use
everything from it for your own purposes (as long as you adhere to the
freeness that the part you're using demands; for GNU Radio, that's
GPLv3). However, to be honest, a linear approximation-based 8kB sine
table might or might not be the right tool for your problem – usually,
one would just think about what one needs and generate the sine table
oneself, matching exactly the requirements at hand.

Us being DSP nerds, I guess some of us are curious: what is your fixed
point application? Are you planning to use this on some microcontroller,
or some programmable logic device, or do you need a sin where you
transform fixed point values (e.g. from an ADC) to floating point
values? What is the algorithm you're building with that?

However, are you /sure/ a sine table is the optimum for your specific
problem?
I'm not an overly big fan of uniform sine tables (they make a lot of
sense on e.g. microcontrollers that don't have advanced math functions,
and if you don't need the accuracy), but if you look at VOLK, you'll
find things that are comparably fast, or in my case, even faster; using
a benchmarking stub I've got lying around (didn't specify any compiler
optimizations, i.e. gcc will not optimize).

Doing 1 operations.
fixed point
 0.781710s wall, 0.78s user + 0.00s system = 0.78s CPU (99.8%)
standard libc float32 sin
 2.700463s wall, 2.70s user + 0.00s system = 2.70s CPU (100.0%)
VOLK float32 sin
Using Volk machine: avx2_64_mmx_orc
 0.331708s wall, 0.33s user + 0.00s system = 0.33s CPU (99.5%)
dummy memory bandwidth test: copy out- to input
 0.404707s wall, 0.40s user + 0.00s system = 0.40s CPU (98.8%)
dummy memory bandwidth test: copy in- to output
 0.406990s wall, 0.41s user + 0.00s system = 0.41s CPU (100.7%)


Volk of course only makes sense if you can arrange your algorithms so
that you get a lot of sin input values continuously in memory.

Four observations:

 1. This sine-table implementation is but three times faster than the
standard libc sin, not even counting the fact that you'd have to
first come up with the proper input scaling. Unless your program is
really dominated by sin() performance, this might not be even worth
considering. A general hint: run "perf record -a yourprogram"; "perf
report" to find out where your PC spent it's time. Well, at least
without compiler optimizations.
 2. The VOLK routine is twice as fast as the fixed point implementation,
and being a six-summand Taylor series approximation probably more
accurate.
 3. Enabling compiler optimizations (CFLAGS=-Ofast make) will probably
double the speed of sin (my experience), and severely cut the the
time that the fixed point implementation takes, probably slightly
below the time of Volk (which will not change measurably). That's
because the compiler will inline everything in the fixed point
routine. Whether that slight advantage then will be worth the
accuracy loss is up to you.
 4. VOLK's sin is faster than float-wise copy (here, without compiler
optimizations); what seems paradox shows that making extensive use
of memory alignment and SIMD brings you much closer to the memory
bandwidth barrier. Knowing my machine, I now have a guess for the
performance of the fixed point sin table approach under heavy
compiler optimization: it will take around ¼ of the time one of the
dummy copies takes; that's how fast you get with 4-float32 SIMD
here, assuming this is really only bandwidth-limited. Trying this
verifies my suspicion!

As you can see, the question what approach is fast really depends on
what your compiler does, what SIMD instructions you can make use of
(VOLK's sin only has optimizations for SSE4.1, I think) and how your
data lies in memory.

Best regards,
Marcus

On 07.04.2016 05:26, Trek Liu wrote:
> What is the purpose of this file? There is zero documentation in this
> file, is it ever being used? 
> I am looking for a sin/cos table for speed optimization, is there one
> inside gnuradio?
>
> Thanks. 
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Rx overflow with high sample rate and high CPU utilization

[Marcus Müller]

Dear SangHyuk,

On 07.04.2016 08:25, SangHyuk Kim wrote:
> Hi all,
>
> I'm trying to solve Rx overflow problem.
>
> I am using USRP N210 and CBX daughter board. As I know, my machine's
> maximum sample rate is up to 25 MSps.
No, that is the maximum number of 16bit complex samples you can get over
Gigabit ethernet; I think I've done the math before, but here it goes
again :)

$\frac{\SI{1}{\giga\bit\per\second}}{\SI{16}{\bit\per Integer}\text{[I]}
+ \SI{16}{\bit\per Integer}\text{[Q]}} =
\frac{\SI{1e9}{\bit\per\second}}{\SI{32}{\bit\per S}}=\SI{31.25}{\mega
S\per\second}$

and because the USRP can only give you integer fractions of its master
clock rate 100MHz as sampling rate, 25MS/s is the maximum you get.
> Yes, it works well at Tx (ex ./benchmark -f 2.5G -r 2500).
> However, when I use USRP to Rx mode (ex ./benchmark -f 2.5G -r
> 2500), letter 'D' (overflow) be occurred.
>
> Rx overflow 'D' is happened when host cannot consume packet fast enough.
... and that to a degree that the network stack, not UHD, decides to
drop packets (not to "O"verflow). That is a very bad sign.
> I observed incoming packet from USRP to host using wireshark tool.
Which will pose a significant additional load on your CPU, something
that will influence your measurement.
> After Rx command be launched (ex ./benchmark -f 2.5G -r 2500),
> USRP sends many packet to host very fast.
Of course.
>
> So, I checked cpu utilization at those moments. As a result, cpu
> utilization is over 200% (PC has 2.7GHz quad-cores). I couldn't
> believe it.
Why? How is that surprising? More than two cores under full load sounds
like a reasonable load here.
>
> However, I found "interrupt coalescing".
> Incoming packet occurs interrupt to host and interrupt coalescing
> adjust how long/many packets make one interrupt to PC.
> So, I changed these value using ethtool -C eth0 rx-usecs 1000
> rx-frames 200.
> But, it doesn't any effect for my case.
Well, then these values simply don't help; honestly, your PC is
overwhelmed, and that not only by the interrupt load.
>
> I'm using tg3 network driver and my setting like below:
> /Supported ports: [ TP ]
> Supported link modes:   10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Supported pause frame use: No
> Supports auto-negotiation: Yes
> Advertised link modes:  10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Advertised pause frame use: Symmetric
> Advertised auto-negotiation: Yes
> Link partner advertised link modes:  1000baseT/Half 1000baseT/Full
> Link partner advertised pause frame use: Transmit-only
> Link partner advertised auto-negotiation: Yes
> Speed: 1000Mb/s
> Duplex: Full
> Port: Twisted Pair
> PHYAD: 1
> Transceiver: internal
> Auto-negotiation: on
> MDI-X: on
> Supports Wake-on: g
> Wake-on: g
> Current message level: 0x00ff (255)
>drv probe link timer ifdown ifup rx_err tx_err
> Link detected: yes/
>
> Did I miss something ?
>
> How can I solve Rx overflow problem at high sample rate ?
Does UHD's

benchmark_rate --rx_rate 25e6

work? If that's the case, the receiver flowgraph is simply too difficult
for your PC to handle in real time. Nothing you can really do about that
but get a faster PC, or design a less complex receiver.

Best regards,
Marcus
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] sine_table.h

[Marcus Müller]

Forgot to include the link to my benchmarking tool:
https://github.com/marcusmueller/table_vs_volk
Had too look intensely for your mail:
Trek, please don't "hijack" other threads by replying to them with a
completely unrelated topic. If starting a new topic, simply send an
email to the mailing list, without using the "reply" functionality, or
else, most people won't even see it, because it's buried in a discussion
thread irrelevant to them.

Best regards,
Marcus
On 07.04.2016 11:40, Marcus Müller wrote:
> Hi Trek,
>
> as Martin noted, yes, if you search the GNU Radio source tree for that
> file name, you'll find it. And also, yes, GNU Radio is Free Software,
> and one of the main credos of that is that you should be able to use
> everything from it for your own purposes (as long as you adhere to the
> freeness that the part you're using demands; for GNU Radio, that's
> GPLv3). However, to be honest, a linear approximation-based 8kB sine
> table might or might not be the right tool for your problem – usually,
> one would just think about what one needs and generate the sine table
> oneself, matching exactly the requirements at hand.
>
> Us being DSP nerds, I guess some of us are curious: what is your fixed
> point application? Are you planning to use this on some
> microcontroller, or some programmable logic device, or do you need a
> sin where you transform fixed point values (e.g. from an ADC) to
> floating point values? What is the algorithm you're building with that?
>
> However, are you /sure/ a sine table is the optimum for your specific
> problem?
> I'm not an overly big fan of uniform sine tables (they make a lot of
> sense on e.g. microcontrollers that don't have advanced math
> functions, and if you don't need the accuracy), but if you look at
> VOLK, you'll find things that are comparably fast, or in my case, even
> faster; using a benchmarking stub I've got lying around (didn't
> specify any compiler optimizations, i.e. gcc will not optimize).
> Doing 1 operations.
> fixed point
>  0.781710s wall, 0.78s user + 0.00s system = 0.78s CPU (99.8%)
> standard libc float32 sin
>  2.700463s wall, 2.70s user + 0.00s system = 2.70s CPU (100.0%)
> VOLK float32 sin
> Using Volk machine: avx2_64_mmx_orc
>  0.331708s wall, 0.33s user + 0.00s system = 0.33s CPU (99.5%)
> dummy memory bandwidth test: copy out- to input
>  0.404707s wall, 0.40s user + 0.00s system = 0.40s CPU (98.8%)
> dummy memory bandwidth test: copy in- to output
>  0.406990s wall, 0.41s user + 0.00s system = 0.41s CPU (100.7%)
>
> Volk of course only makes sense if you can arrange your algorithms so
> that you get a lot of sin input values continuously in memory.
>
> Four observations:
>
>  1. This sine-table implementation is but three times faster than the
> standard libc sin, not even counting the fact that you'd have to
> first come up with the proper input scaling. Unless your program
> is really dominated by sin() performance, this might not be even
> worth considering. A general hint: run "perf record -a
> yourprogram"; "perf report" to find out where your PC spent it's
> time. Well, at least without compiler optimizations.
>  2. The VOLK routine is twice as fast as the fixed point
> implementation, and being a six-summand Taylor series
> approximation probably more accurate.
>  3. Enabling compiler optimizations (CFLAGS=-Ofast make) will probably
> double the speed of sin (my experience), and severely cut the the
> time that the fixed point implementation takes, probably slightly
> below the time of Volk (which will not change measurably). That's
> because the compiler will inline everything in the fixed point
> routine. Whether that slight advantage then will be worth the
> accuracy loss is up to you.
>  4. VOLK's sin is faster than float-wise copy (here, without compiler
> optimizations); what seems paradox shows that making extensive use
> of memory alignment and SIMD brings you much closer to the memory
> bandwidth barrier. Knowing my machine, I now have a guess for the
> performance of the fixed point sin table approach under heavy
> compiler optimization: it will take around ¼ of the time one of
> the dummy copies takes; that's how fast you get with 4-float32
> SIMD here, assuming this is really only bandwidth-limited. Trying
> this verifies my suspicion!
>
> As you can see, the question what approach is fast really depends on
> what your compiler does, what SIMD instructions you can make use of
> (VOLK's sin only has optimizations for SSE4.1, I think) and how your
> data lies in memory.
>
> Best regards,
> Marcus
>
> On 07.04.2016 05:26, Trek Liu wrote:
>> What is the purpose of this file? There is zero documentation in this
>> file, is it ever being used? 
>> I am looking for a sin/cos table for speed optimization, is there one
>> inside gnuradio?
>>
>> Thanks. 
>>
>>

Re: [Discuss-gnuradio] Rx overflow with high sample rate and high CPU utilization

[SangHyuk Kim]

Dear Marcus,

I'm always appreciated your help.

I did ./benchmark_rate --rx_rate 25e6 and it worked well.

Then, I should make it simple.

Very thanks you!


2016-04-07 18:49 GMT+09:00 Marcus Müller :

> Dear SangHyuk,
>
> On 07.04.2016 08:25, SangHyuk Kim wrote:
>
> Hi all,
>
> I'm trying to solve Rx overflow problem.
>
> I am using USRP N210 and CBX daughter board. As I know, my machine's
> maximum sample rate is up to 25 MSps.
>
> No, that is the maximum number of 16bit complex samples you can get over
> Gigabit ethernet; I think I've done the math before, but here it goes again
> :)
>
> [image: $\frac{\SI{1}{\giga\bit\per\second}}{\SI{16}{\bit\per
> Integer}\text{[I]} + \SI{16}{\bit\per Integer}\text{[Q]}} =
> \frac{\SI{1e9}{\bit\per\second}}{\SI{32}{\bit\per S}}=\SI{31.25}{\mega
> S\per\second}$]
>
> and because the USRP can only give you integer fractions of its master
> clock rate 100MHz as sampling rate, 25MS/s is the maximum you get.
>
> Yes, it works well at Tx (ex ./benchmark -f 2.5G -r 2500).
> However, when I use USRP to Rx mode (ex ./benchmark -f 2.5G -r 2500),
> letter 'D' (overflow) be occurred.
>
>
> Rx overflow 'D' is happened when host cannot consume packet fast enough.
>
> ... and that to a degree that the network stack, not UHD, decides to drop
> packets (not to "O"verflow). That is a very bad sign.
>
> I observed incoming packet from USRP to host using wireshark tool.
>
> Which will pose a significant additional load on your CPU, something that
> will influence your measurement.
>
> After Rx command be launched (ex ./benchmark -f 2.5G -r 2500), USRP
> sends many packet to host very fast.
>
> Of course.
>
>
> So, I checked cpu utilization at those moments. As a result, cpu
> utilization is over 200% (PC has 2.7GHz quad-cores). I couldn't believe it.
>
> Why? How is that surprising? More than two cores under full load sounds
> like a reasonable load here.
>
>
> However, I found "interrupt coalescing".
> Incoming packet occurs interrupt to host and interrupt coalescing adjust
> how long/many packets make one interrupt to PC.
> So, I changed these value using ethtool -C eth0 rx-usecs 1000 rx-frames
> 200.
> But, it doesn't any effect for my case.
>
> Well, then these values simply don't help; honestly, your PC is
> overwhelmed, and that not only by the interrupt load.
>
>
> I'm using tg3 network driver and my setting like below:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Supported ports: [ TP ] Supported link modes:   10baseT/Half
> 10baseT/Full 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full Supported pause
> frame use: No Supports auto-negotiation: Yes Advertised link
> modes:  10baseT/Half 10baseT/Full 100baseT/Half
> 100baseT/Full 1000baseT/Half 1000baseT/Full
> Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes
> Link partner advertised link modes:  1000baseT/Half 1000baseT/Full
> Link partner advertised pause frame use: Transmit-only Link partner
> advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full
> Port: Twisted Pair PHYAD: 1 Transceiver: internal
> Auto-negotiation: on MDI-X: on Supports Wake-on: g Wake-on: g
> Current message level: 0x00ff (255)drv probe
> link timer ifdown ifup rx_err tx_err Link detected: yes*
>
> Did I miss something ?
>
> How can I solve Rx overflow problem at high sample rate ?
>
> Does UHD's
>
> benchmark_rate --rx_rate 25e6
>
> work? If that's the case, the receiver flowgraph is simply too difficult
> for your PC to handle in real time. Nothing you can really do about that
> but get a faster PC, or design a less complex receiver.
>
> Best regards,
> Marcus
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Rx overflow with high sample rate and high CPU utilization

[Marcus Müller]

Dear SangHyuk,

please be aware that digital receivers aren't really easy to make more
CPU efficient; a real-world receiver not only has to convert received
symbols to bits, but has to do the frequency and frame synchronization
as well as a timing recovery; high-bandwidth transceivers must go
through significant amounts of equalization (OFDM is one way to approach
this, converting one giant channel into a lot of narrow, hence, nearly
flat, channels that can be single-tap equalized, at the expense of doing
FFTs and inserting pilots/redundancy), too. The Benchmark_* tools aren't
really doing anything to equalize (if I remember correctly), so they
aren't really applicable to wideband channels, and if you do
equalization, you'll probably be even slower.
As said on numerous occassions, go ahead and try the rx_ofdm.grc and
tx_ofdm.grc examples from gr-digital. They are much more modern.

If I had a diagnosis, still, your PC is probably simply too slow for
receivers that aren't highly optimized; GNU Radio really does its best
with efficient filter, FFT, synchronizer structures, but it might not be
able to compensate that at 2.7GHz x 4 cores, you only have 432 CPU
cycles per sample at 25MS/s, if your application was perfectly scalable
(which it's not). That's not really much for a complicated receiver, if
you consider that includes all the data handling (ie. getting data from
the network card, converting it to something your CPU can deal with,
writing the results somewhere), filtering, synchronization, channelizing
(if doing *FDM), symbol decision, de-framing, channel decoding (no one
would build a real-world transceiver without that), and as said,
benchmark_rx (from the gr-digital/examples/ofdm directory, we're not
talking about the narrowband one) isn't that optimally structured – it's
really just a proof of concept.

Best regards,
Marcus

On 07.04.2016 13:39, SangHyuk Kim wrote:
> Dear Marcus,
>
> I'm always appreciated your help.
>
> I did ./benchmark_rate --rx_rate 25e6 and it worked well.
>
> Then, I should make it simple. 
>
> Very thanks you!
>
>
> 2016-04-07 18:49 GMT+09:00 Marcus Müller  >:
>
> Dear SangHyuk,
>
> On 07.04.2016 08:25, SangHyuk Kim wrote:
>> Hi all,
>>
>> I'm trying to solve Rx overflow problem.
>>
>> I am using USRP N210 and CBX daughter board. As I know, my
>> machine's maximum sample rate is up to 25 MSps.
> No, that is the maximum number of 16bit complex samples you can
> get over Gigabit ethernet; I think I've done the math before, but
> here it goes again :)
>
> $\frac{\SI{1}{\giga\bit\per\second}}{\SI{16}{\bit\per
> Integer}\text{[I]} + \SI{16}{\bit\per Integer}\text{[Q]}} =
> \frac{\SI{1e9}{\bit\per\second}}{\SI{32}{\bit\per
> S}}=\SI{31.25}{\mega S\per\second}$
>
> and because the USRP can only give you integer fractions of its
> master clock rate 100MHz as sampling rate, 25MS/s is the maximum
> you get.
>> Yes, it works well at Tx (ex ./benchmark -f 2.5G -r 2500).
>> However, when I use USRP to Rx mode (ex ./benchmark -f 2.5G -r
>> 2500), letter 'D' (overflow) be occurred.
>>
>> Rx overflow 'D' is happened when host cannot consume packet fast
>> enough.
> ... and that to a degree that the network stack, not UHD, decides
> to drop packets (not to "O"verflow). That is a very bad sign.
>> I observed incoming packet from USRP to host using wireshark tool.
> Which will pose a significant additional load on your CPU,
> something that will influence your measurement.
>> After Rx command be launched (ex ./benchmark -f 2.5G -r
>> 2500), USRP sends many packet to host very fast.
> Of course.
>>
>> So, I checked cpu utilization at those moments. As a result, cpu
>> utilization is over 200% (PC has 2.7GHz quad-cores). I couldn't
>> believe it.
> Why? How is that surprising? More than two cores under full load
> sounds like a reasonable load here.
>>
>> However, I found "interrupt coalescing".
>> Incoming packet occurs interrupt to host and interrupt coalescing
>> adjust how long/many packets make one interrupt to PC.
>> So, I changed these value using ethtool -C eth0 rx-usecs 1000
>> rx-frames 200.
>> But, it doesn't any effect for my case.
> Well, then these values simply don't help; honestly, your PC is
> overwhelmed, and that not only by the interrupt load.
>
>>
>> I'm using tg3 network driver and my setting like below:
>> /Supported ports: [ TP ]
>> Supported link modes:   10baseT/Half 10baseT/Full
>> 100baseT/Half 100baseT/Full
>> 1000baseT/Half 1000baseT/Full
>> Supported pause frame use: No
>> Supports auto-negotiation: Yes
>> Advertised link modes:  10baseT/Half 10baseT/Full
>> 100baseT/Half 100baseT/Full
>>  

[Discuss-gnuradio] Difference between XML file and Python File

[Ankit Saharia]

>From what i have know through the website is that we can make our own block
from XML File Definiton as well as through python coding.

Can someone please tell me the difference between the two?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error while executing a flow graph

[Ankit Saharia]

Thank you all for your help.

I am now able to execute WX widget flow graph in Windows.

Would like to share my experience.

>From what i have learned,my suggestion would be,if you want to install
GNURadio for windows then follow the steps very carefully and also the
version of each packages should be installed as it is given and not a
higher version or a lower version.

On Fri, Apr 1, 2016 at 10:57 PM, Geof Nieboer  wrote:

> Ankit,
>
> While I would still continue pressing with the change to Qt, I did check
> my PyOpenGL version and it's 3.1.0 so it is different than yours.
>
> Geof
>
> On Fri, Apr 1, 2016 at 4:36 AM, Ankit Saharia  wrote:
>
>> The errors are still the same.
>>
>> On Fri, Apr 1, 2016 at 5:40 AM, Derek Kozel 
>> wrote:
>>
>>> Hello Ankit,
>>>
>>> Have you tried installing the other version of PyOpenGL? How does that
>>> change the errors you see?
>>>
>>> Also, the fastest way for you to move on with your project is likely to
>>> use the GNU Radio Live Environment.
>>> https://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
>>>
>>> Regards,
>>> Derek
>>>
>>> On Thu, Mar 31, 2016 at 4:54 PM, Ankit Saharia 
>>> wrote:
>>>
 Geof,

 I think i have installed PyOpenGL 3.1.1 instead of PyOpenGL 3.1.0a1
 that is why it is not working?

 Any suggestions on that

 Ankit

 On Wed, Mar 30, 2016 at 10:30 AM, Ankit Saharia 
 wrote:

> Geof,
>
> Thank you for the advice.
>
> It is indeed a nice project that you are working on.
> It will help the Windows user working in GNURadio
>
> All the best for the project.
>
> Ankit
> On 30-Mar-2016 10:24 AM, "Geof Nieboer"  wrote:
>
>> Ankit,
>>
>> The mailing list overall is always ready help, though they are here
>> to help you solve a puzzle, not solve the puzzle for you. As long as you
>> bear that in mind, this is a very helpful group.
>>
>> As for the windows install, I can't easily give you simple
>> instructions on how to install it.  The difficult part is not GNURadio,
>> it's getting all the dependencies right, and one little thing can break
>> it.
>>
>> However, my project right now is to build a set of ".msi" files that
>> will allow windows users to simply install GNURadio with all dependencies
>> like any other Windows program.  It also has a script so that users can
>> build it themselves.  Bad news is that it is not yet ready, perhaps in a
>> month it will be fully complete.
>>
>> In the meantime, if Qt is working, I highly recommend that route, I
>> think you will find it is a much easier change to make than starting over
>> with your installation.
>>
>> On Wed, Mar 30, 2016 at 4:19 AM, Ankit Saharia 
>> wrote:
>>
>>> Geof
>>>
>>> What are the steps that you followed to install GNU Radio in WIndows.
>>>
>>> I can maybe follow that and install GNU once again
>>>
>>> Ankit
>>>
>>> On Wed, Mar 30, 2016 at 6:01 AM, Ankit Saharia 
>>> wrote:
>>>
 Thank you Sir for taking the time and helping me out for my project.

 I'll do as per your instructions.

 Can I get back to you Sir if I face any problem again?

 On Tue, Mar 29, 2016 at 1:18 AM, Ankit Saharia >>> > wrote:

> Thankyou Sir for your response. Sorry for replying late Sir. I
> didnot receive your mail so i had to go to the website and check it.
>
>
> I tried to add the WX GUI FFT Sink to my audio tone signal flow
> graph.But after the execution the same error persists.
>
>
> Then I changed the WX GUI Sink to QT GUI Sink, it was working well
> and the graph can also be seen.
>
>
> So as you have mentioned, it is a problem with the WX components.
>
>
> Below attached is the .grc file for my project.
>
>
> Another doubt Sir is that,are all the WX components replacable by
> the QT components.
>
>
> Thankyou
>



 --
 cooldude

>>>
>>>
>>>
>>> --
>>> cooldude
>>>
>>
>>


 --
 Regards
 Ankit Saharia

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


>>>
>>
>>
>> --
>> Regards
>> Ankit Saharia
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>


-- 
Regards
Ankit Saharia
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Difference between XML file and Python File

[Marcus Müller]

Dear Ankit,

that is not true.

A GNU Radio block is always implemented in C++ or Python.

A Block, as you can use it in GRC, is a logical "wrapper" around such a
GNU Radio block.

To define how that wrapper looks like, you always need to use XML.

Hope that explained things well!

Best regards,
Marcus

On 07.04.2016 17:45, Ankit Saharia wrote:
> From what i have know through the website is that we can make our own
> block from XML File Definiton as well as through python coding.
>
> Can someone please tell me the difference between the two?
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] FW: HF transmitter hardware solutions

[John Petrich]

Dan, Lou, Ron, and others,

Dan you are doing a great job of beating the drum: searching for "solutions
for transmitting on HF"  The question is a big one and can be broken down
into three basic issues.  The basic or elemental SDR platform solutions are
changing rapidly.  With the third generation SDRs, and tightly integrated
RFICs, there are a number of excellent, high performance, solutions, as has
been pointed out, and as you well know.

I think your real question, Dan, asks about the rest of the HF system: the
elements necessary to complete the transmitter for practical communication
purposes.  The question moves beyond SDR hardware to that of station
building.  That station building part of the system, I call the "interface".
The "interface" provides the receive and transmit filtering and antenna
switching, power control, amplifier stages, and other functions.  The
"interface" is built upon analog technology.  Much information along these
lines is addressed by the QRP (low power) movement within Amateur Radio.
The American Radio Relay League (ARRL) publishes small paperback books
devoted to QRP equipment and station building, and available for purchase
on-line.  The material covers homemade solutions, as well as purchased kits
and turnkey solutions.  Maybe, a group of interested GRC/SDR enthusiasts can
collect and publish a few example systems as starters for those who want to
experiment in this area.

The second aspect of the "solutions" question asks if there are suitable GRC
DSPs as starters, at least.  With Lou's help, I have authored a library of
transceiver DSPs for all of the commonly used HF transmission modes.  The
GRC DSPs are  'ham friendly' in the sense that they implement functional,
ordinary and familiar transceiver interfaces.  However, I have no easy means
to publish the DSP's.  Would collecting and publishing GRC DSPs be helpful
at addressing your "solutions" question?  If so, what is the best approach
for maximum visibility to the experimenter community?

Last but not least, a third issue for communication system functionality, is
to use the GRC GUI to control the auxiliary functions of an HF transmitter,
e.g. transmit / receiver relay.  I do not know of a means to access the GPIO
from the GRC GUI.  My present solution is to use current from the USRP
transmit or receive LED signal to control external equipment via a relay
system.  Maybe someone can publish a different solution.

Looking forward to further discussion on the HF transmit solution question.

Regards,
John Petrich

-Original Message-
From: Ron Economos [mailto:w...@comcast.net] 
Sent: Wednesday, April 6, 2016 7:23 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] HF transmitter hardware solutions

There's a transverter for the bladeRF.

https://www.nuand.com/blog/product/hf-vhf-transverter/

hackRF specification has been changed to 1 MHz to 6 GHz.

https://greatscottgadgets.com/hackrf/

Ron

On 04/06/2016 07:02 AM, Daniel Pocock wrote:
>
> What solutions are people using for transmitting on HF bands (1 - 30 MHz)?
>
> There is a lot of information online about upconverters for receiving 
> the HF bands.
>
> However, like receivers, many of the SDR transmitters only seem to 
> cover bands above 30MHz[1] e.g.
>
> HackRF: 30MHz - ...
> bladeRF :  300MHz - ...
> USRP B2x0:  50MHz - ...
>
> Is anybody using a downconverter or is there some other SDR model that 
> natively supports the HF spectrum and is accessible to hobbyists?
>
> Some other things come to mind:
> - power amps for HF bands
> - RF switches for using a single antenna in half-duplex mode, 
> alternating between receive and transmit
>
>
>
> 1.
> http://www.taylorkillian.com/2013/08/sdr-showdown-hackrf-vs-bladerf-vs
> -usrp.html
>





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] Switching and high spike in spectrum

[bob wole]

Hi,

Sorry for late reply. I was running out of time, so I used the offset tune
future of UHD to handle that spike. See the following link, hope it helps,

http://files.ettus.com/manual/structuhd_1_1tune__request__t.html

--
Bob

On Sat, Apr 2, 2016 at 7:41 AM, hanwen  wrote:

> Hi Bob,
>
> I came up with the same issue and I hope the DC leakage from Tx should
> disappear right after the Tx burst is finished, but acturally I still saw
> the strong DC during the pure Rx time lot.
> Have you got a solution for that? Thanks.
>
> Br, Hanwen
>
> 2014-10-31 7:31 GMT+01:00 bob wole :
>
>>
>>
>>
>> On 10/29/2014 01:54 PM, bob wole via USRP-users wrote:
>>> >
>>> > USRPN210r4 with SBX
>>> >
>>> > I am observing a strong spike at the center of the receive spectrum
>>> > when I start burst transmission.
>>> >
>>> > My top flowgraph contains following two hierarchical blocks
>>> >  1) A transmitter flow graph with (tx_time, tx_sob, tx_eob)
>>> >  2) A receiver flow graph
>>> >
>>> > When I run top flowgrpah (without transmitting anything) and observe
>>> > the FFT of the received signal the spectrum does not contain high
>>> > spike in the center.
>>> >
>>> > But as soon as I start transmitting in burst mode I see a very high
>>> > spike in center of the received signal FFT spectrum. It looks like LO
>>> > (transmitter or receiver ) is being received? Which one is it ? And
>>> > why is it happening?  How can I avoid it because it is affecting my
>>> > packets.
>>> >
>>> > When I apply the offset in digital using DDC/DUC, the spike moves out
>>> > of the band.
>>> >
>>> >
>>> > --
>>> > Bob
>>> >
>>> >
>>> > ___
>>> > USRP-users mailing list
>>> > usrp-us...@lists.ettus.com
>>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> That spike in the middle is a consequence of using direct conversion in
>>> both the RX and TX paths--it'll be there in both to some degree.
>>>
>>> You can use offset-tuning to move the DC offset outside your passband:
>>>
>>> http://files.ettus.com/manual/page_general.html
>>>
>>>
>>> In built-for-a-particular-purpose radios, there will also be undesired
>>> LO leakage and mixing products--those are generally dealt with using an
>>>application/band-specific filter to eliminate them.  For
>>> general-purpose SDRs, that isn't possible to do "as manufactured", you
>>> have to deal
>>>with RF hygiene and plumbing issues yourself.
>>>
>>> So, moving the LO leakage outside your passband is part of the
>>> picture--use offset tuning for that.  Then, if you have "this won't meet
>>>our hygiene requirements", you have to look at filtering.
>>>
>>> Another thing you really should do is to run the calibration utilities,
>>> which will attempt to balance I/Q amplitude and phase, which can improve
>>>some of these issues, but not, usually, eliminate them entirely.
>>>
>>>
>>>
>> Yes, I know that LO leakage/DC offset is an issue present in direct
>> conversion receiver. But as I mentioned earlier, the received spectrum
>> looks fine (a very little spike at DC around -70dB) while the burst
>> transmission is not running. The spike becomes much more significant ( high
>> spike at DC -20dB) when burst transmission (tx_time,tx_eob, tx_sob )
>> starts  and all the spectrum just shifts up and down with it. I am using
>> TX/RX antenna in both usrp source and usrp sink. I want to know why the
>> burst transmission is affecting the received spectrum on the same node.
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] XM on GR

[Jason Matusiak]

I was thinking about XM radio today and how channel 1 on it is sent in the clear (if you don't have a subscription, you can tune to it and hear their adds).  I haven't found a lot of information (so I think I know the answer), but has anyone looked into an XM receiver in GR?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRCON 16 hotels

[Ben Hilburn]

Hi Jason -

Hotels will get posted on the website shortly. If you need something right
away, this will be one of the recommended places:

*Millennium Hotel* 

www.millenniumhotels.com
1345 28th St
Boulder, CO 80302
(303) 443-3850


I'm not sure who started a rumor about GRCon running buses from Denver, but
I'll go ahead and squash that one, now, hah. That said, I would be very
surprised if there isn't already a selection of hotel bus services that do
exactly this. We'll try to locate some information on these and get them on
the website, as well.


Cheers,

Ben

On Tue, Apr 5, 2016 at 8:58 AM, Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> Do we have an idea when preferred hotels will be announced?  Also I heard
> rumor that there might be some shuttles lining up to take people from DEN
> to the hotels, is that still a possibility (just trying to book things
> soon)?
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [Docker] New GNU Radio images with GUI support

[Nick Foster]

On Thu, Apr 7, 2016, 3:48 PM Ben Hilburn  wrote:

>
> What was your experience like when it came to using the RTL dongle? Was
> there any complexity there? If you have hardware that can stream at higher
> rates, I'd be interested in how those perform in the container, as well.
>

Performance is, for all intents and purposes, unaffected. Network
performance may be very slightly affected by the virtual network device. If
your application is very sensitive, just use the "--net host" option when
invoking the container.

I have benchmarked X310 performance using the "--net host" option and
gotten effectively identical results inside a container vs. running
natively. I do not consider Docker containers to affect performance in any
way.

--n


>
> On Wed, Apr 6, 2016 at 4:23 AM, Stefan Wunsch <
> stefan.wun...@student.kit.edu> wrote:
>
>> Hi all!
>>
>> I have build a docker tool-chain for an image with GNU Radio and UHD
>> installed via PyBOMBS on top of Ubuntu. It's even possible to run it
>> dockerized with a GUI using VNC and it should work as well on windows
>> and mac (so far, not tested). The build files are available on github
>> and the precompiled images on hub.docker.com. If you are interested,
>> have a look! In the following, I will give a short description.
>>
>> How to run the image with VNC server and how to access the container:
>>
>> # Run the image with GNU Radio and VNC server:
>> # The run command will download (pull) the image automatically.
>> # Use the additional option '-device=/dev/bus/usb' for USB access,
>> # e.g., to use rtl dongles. You have to plugin the devices before you
>> # start the container!
>>
>> $ docker run -it --rm -p 5901:5901 -e USER=root \
>> stwunsch/docker-pybombs-gnuradio-vnc bash -c \
>> "vncserver :1 -geometry 1280x800 -depth 24 && tail -F /root/.vnc/*.log"
>>
>> # Get graphical access using a VNC client. I suppose you are running
>> # the container on the same machine. Here an example command using
>> # vncviewer. As well, it's possible to use X forwarding.
>>
>> $ vncviewer localhost:5901
>>
>> So far, it's only tested on a Linux machine, but it should work on every
>> system with an installed docker daemon. I was able to run a rtl dongle
>> with gr-osmosdr. To install new OOTs, just open a terminal and type, for
>> example, 'pybombs install gr-osmosdr'.
>>
>> Here, the image chain. You can pull these images from hub.docker.com.
>> All images are build automatically on change of the appropriate GitHub
>> repository (except the GNU Radio base image, see below for more info on
>> that).
>>
>> Base-image: ubuntu 14.04
>> -> ubuntu + pybombs (stwunsch/docker-pybombs)
>> -> ubuntu + pybombs + uhd (stwunsch/docker-pybombs-uhd)
>> -> ubuntu + pybombs + uhd + gnuradio dependencies
>> (stwunsch/docker-pybombs-gnuradio-depsonly)
>> -> ubuntu + pybombs + uhd + gnuradio (stwunsch/docker-pybombs-gnuradio)
>> -> ubuntu + pybombs + uhd + gnuradio + vnc server
>> (stwunsch/docker-pybombs-gnuradio-vnc)
>>
>> A single problem so far: It is not possible to build the GNU Radio image
>> (docker-pybombs-gnuradio) on the docker servers, because they have a 2h
>> build limitation. I have preinstalled everything (pybombs and all
>> dependencies), but it is not possible to run the compilation below 2h on
>> a single core.
>>
>> Does anyone know whether it's possible to split the compilation or speed
>> it up (without using the -jX flag)? Now the image has to be build
>> locally and then pushed to hub.docker.com manually. Not the best
>> solution!
>>
>> I would be highly interested whether it really works on other systems,
>> especially on windows! That could be a nice alternative to MSVC
>> compilations.
>>
>> Greetings
>> Stefan
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [Docker] New GNU Radio images with GUI support

[Ben Hilburn]

Hi Stefan -

This is really cool! Thanks so much for sharing your images and for posting
instructions. It looks like a number of people have started playing with
GNU Radio containers - I recognize some of the other names that have
publicly shared images (e.g., Nick Foster aka 'bistromath'). We chatted a
bit about using Docker as a way to get a "known state" machine
up-and-running with GNU Radio quickly at GRCon15, and it seems like it
could greatly simplify the installation process for certain use cases.

What was your experience like when it came to using the RTL dongle? Was
there any complexity there? If you have hardware that can stream at higher
rates, I'd be interested in how those perform in the container, as well.

Cheers,
Ben

On Wed, Apr 6, 2016 at 4:23 AM, Stefan Wunsch  wrote:

> Hi all!
>
> I have build a docker tool-chain for an image with GNU Radio and UHD
> installed via PyBOMBS on top of Ubuntu. It's even possible to run it
> dockerized with a GUI using VNC and it should work as well on windows
> and mac (so far, not tested). The build files are available on github
> and the precompiled images on hub.docker.com. If you are interested,
> have a look! In the following, I will give a short description.
>
> How to run the image with VNC server and how to access the container:
>
> # Run the image with GNU Radio and VNC server:
> # The run command will download (pull) the image automatically.
> # Use the additional option '-device=/dev/bus/usb' for USB access,
> # e.g., to use rtl dongles. You have to plugin the devices before you
> # start the container!
>
> $ docker run -it --rm -p 5901:5901 -e USER=root \
> stwunsch/docker-pybombs-gnuradio-vnc bash -c \
> "vncserver :1 -geometry 1280x800 -depth 24 && tail -F /root/.vnc/*.log"
>
> # Get graphical access using a VNC client. I suppose you are running
> # the container on the same machine. Here an example command using
> # vncviewer. As well, it's possible to use X forwarding.
>
> $ vncviewer localhost:5901
>
> So far, it's only tested on a Linux machine, but it should work on every
> system with an installed docker daemon. I was able to run a rtl dongle
> with gr-osmosdr. To install new OOTs, just open a terminal and type, for
> example, 'pybombs install gr-osmosdr'.
>
> Here, the image chain. You can pull these images from hub.docker.com.
> All images are build automatically on change of the appropriate GitHub
> repository (except the GNU Radio base image, see below for more info on
> that).
>
> Base-image: ubuntu 14.04
> -> ubuntu + pybombs (stwunsch/docker-pybombs)
> -> ubuntu + pybombs + uhd (stwunsch/docker-pybombs-uhd)
> -> ubuntu + pybombs + uhd + gnuradio dependencies
> (stwunsch/docker-pybombs-gnuradio-depsonly)
> -> ubuntu + pybombs + uhd + gnuradio (stwunsch/docker-pybombs-gnuradio)
> -> ubuntu + pybombs + uhd + gnuradio + vnc server
> (stwunsch/docker-pybombs-gnuradio-vnc)
>
> A single problem so far: It is not possible to build the GNU Radio image
> (docker-pybombs-gnuradio) on the docker servers, because they have a 2h
> build limitation. I have preinstalled everything (pybombs and all
> dependencies), but it is not possible to run the compilation below 2h on
> a single core.
>
> Does anyone know whether it's possible to split the compilation or speed
> it up (without using the -jX flag)? Now the image has to be build
> locally and then pushed to hub.docker.com manually. Not the best solution!
>
> I would be highly interested whether it really works on other systems,
> especially on windows! That could be a nice alternative to MSVC
> compilations.
>
> Greetings
> Stefan
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FW: HF transmitter hardware solutions

[Ron Economos]

"However, I have no easy means to publish the DSP's"

Most of us are using Github these days. Here's mine (mostly digital 
television transmitters, but gr-paint is the most popular).


https://github.com/drmpeg

Here's a couple with just GRC flow graphs and utilities.

https://github.com/argilo/sdr-examples

https://github.com/drmpeg/dtv-utils

BTW, love the LED TX/RX switching hack.

Ron W6RZ

On 04/07/2016 11:01 AM, John Petrich wrote:

Dan, Lou, Ron, and others,

Dan you are doing a great job of beating the drum: searching for "solutions
for transmitting on HF"  The question is a big one and can be broken down
into three basic issues.  The basic or elemental SDR platform solutions are
changing rapidly.  With the third generation SDRs, and tightly integrated
RFICs, there are a number of excellent, high performance, solutions, as has
been pointed out, and as you well know.

I think your real question, Dan, asks about the rest of the HF system: the
elements necessary to complete the transmitter for practical communication
purposes.  The question moves beyond SDR hardware to that of station
building.  That station building part of the system, I call the "interface".
The "interface" provides the receive and transmit filtering and antenna
switching, power control, amplifier stages, and other functions.  The
"interface" is built upon analog technology.  Much information along these
lines is addressed by the QRP (low power) movement within Amateur Radio.
The American Radio Relay League (ARRL) publishes small paperback books
devoted to QRP equipment and station building, and available for purchase
on-line.  The material covers homemade solutions, as well as purchased kits
and turnkey solutions.  Maybe, a group of interested GRC/SDR enthusiasts can
collect and publish a few example systems as starters for those who want to
experiment in this area.

The second aspect of the "solutions" question asks if there are suitable GRC
DSPs as starters, at least.  With Lou's help, I have authored a library of
transceiver DSPs for all of the commonly used HF transmission modes.  The
GRC DSPs are  'ham friendly' in the sense that they implement functional,
ordinary and familiar transceiver interfaces.  However, I have no easy means
to publish the DSP's.  Would collecting and publishing GRC DSPs be helpful
at addressing your "solutions" question?  If so, what is the best approach
for maximum visibility to the experimenter community?

Last but not least, a third issue for communication system functionality, is
to use the GRC GUI to control the auxiliary functions of an HF transmitter,
e.g. transmit / receiver relay.  I do not know of a means to access the GPIO
from the GRC GUI.  My present solution is to use current from the USRP
transmit or receive LED signal to control external equipment via a relay
system.  Maybe someone can publish a different solution.

Looking forward to further discussion on the HF transmit solution question.

Regards,
John Petrich

-Original Message-
From: Ron Economos [mailto:w...@comcast.net]
Sent: Wednesday, April 6, 2016 7:23 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] HF transmitter hardware solutions

There's a transverter for the bladeRF.

https://www.nuand.com/blog/product/hf-vhf-transverter/

hackRF specification has been changed to 1 MHz to 6 GHz.

https://greatscottgadgets.com/hackrf/

Ron

On 04/06/2016 07:02 AM, Daniel Pocock wrote:

What solutions are people using for transmitting on HF bands (1 - 30 MHz)?

There is a lot of information online about upconverters for receiving
the HF bands.

However, like receivers, many of the SDR transmitters only seem to
cover bands above 30MHz[1] e.g.

HackRF: 30MHz - ...
bladeRF :  300MHz - ...
USRP B2x0:  50MHz - ...

Is anybody using a downconverter or is there some other SDR model that
natively supports the HF spectrum and is accessible to hobbyists?

Some other things come to mind:
- power amps for HF bands
- RF switches for using a single antenna in half-duplex mode,
alternating between receive and transmit



1.
http://www.taylorkillian.com/2013/08/sdr-showdown-hackrf-vs-bladerf-vs
-usrp.html







___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] XM on GR

[Steve Katzberg]

Jason,

I am involved in a project that needs the bit stream from XM but we do not need 
it decrypted.  The acquisition of the unencrypted Channel 1 would be fun to do, 
but so far I cannot get Gnuradio blocks to properly lock on to the signal.  The 
Costas loop drifts through he QPSK constellation, but won't stay locked on it.  
That probably means I don't have something right in GRC or there is an overlay 
modulation that confuses the Costas loop phase locking.  Until either my hybrid 
hardware/GRC setup starts locking onto the XM signal there will be no Channel 1.

Steve Katzberg
  - Original Message - 
  From: Jason Matusiak 
  To: GNURadio Mailing List 
  Sent: Thursday, April 07, 2016 5:14 PM
  Subject: [Discuss-gnuradio] XM on GR


  I was thinking about XM radio today and how channel 1 on it is sent in the 
clear (if you don't have a subscription, you can tune to it and hear their 
adds).  I haven't found a lot of information (so I think I know the answer), 
but has anyone looked into an XM receiver in GR?


--


  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Ubunto 15.04 (right off the .iso) recipe for success

[Gregory W. Ratcliff]

Greetings,
Has anyone gone start to finish with  64 bit, desktop, 15.04, new pip and 
pybombs 2+. ?
I would like to get back to enjoying gnuradio as quickly as possible.
Thank you,
Mr. Lazy.
 Gregory W. Ratcliff




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] XM on GR

[Chris Kuethe]

I think there is an overlay modulation. I'll try dig up the source where I
saw that.
On Apr 7, 2016 16:30, "Steve Katzberg"  wrote:

> Jason,
>
> I am involved in a project that needs the bit stream from XM but we do not
> need it decrypted.  The acquisition of the unencrypted Channel 1 would be
> fun to do, but so far I cannot get Gnuradio blocks to properly lock on to
> the signal.  The Costas loop drifts through he QPSK constellation, but
> won't stay locked on it.  That probably means I don't have something right
> in GRC or there is an overlay modulation that confuses the Costas loop
> phase locking.  Until either my hybrid hardware/GRC setup starts locking
> onto the XM signal there will be no Channel 1.
>
> Steve Katzberg
>
> - Original Message -
> *From:* Jason Matusiak 
> *To:* GNURadio Mailing List 
> *Sent:* Thursday, April 07, 2016 5:14 PM
> *Subject:* [Discuss-gnuradio] XM on GR
>
> I was thinking about XM radio today and how channel 1 on it is sent in the
> clear (if you don't have a subscription, you can tune to it and hear their
> adds).  I haven't found a lot of information (so I think I know the
> answer), but has anyone looked into an XM receiver in GR?
>
> --
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ubunto 15.04 (right off the .iso) recipe for success

[Chris Kuethe]

I'm using 15.10 with little difficulty. I suppose I should spin up a 15.04
test vm.
On Apr 7, 2016 19:04, "Gregory W. Ratcliff"  wrote:

> Greetings,
>
> Has anyone gone start to finish with  64 bit, desktop, 15.04, new pip and
> pybombs 2+. ?
>
> I would like to get back to enjoying gnuradio as quickly as possible.
>
> Thank you,
>
> Mr. Lazy.
>
> Gregory W. Ratcliff
>
>
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] XM on GR

[Marcus Müller]

Hello Steve,

that sounds like an interesting project; a couple of friends and I went
to the US for GRCON'14, rented a car and somehow Sirius and XM spiked
our interest, but as you can imagine, it's kind of hard to receive those
in Europe.

Could you share a bit of your flowgraph with the community? What
synchronizer blocks are you using?

Not having played around with them overly much, I've heard people having
great success using the PFB clock recovery, as that seems to be pretty
robust against amplitude variation, so that'd be my "Hm, I guess you
could try that" idea.

Cheers,
Marcus

On 08.04.2016 01:30, Steve Katzberg wrote:
> Jason,
>  
> I am involved in a project that needs the bit stream from XM but we do
> not need it decrypted.  The acquisition of the unencrypted Channel 1
> would be fun to do, but so far I cannot get Gnuradio blocks to
> properly lock on to the signal.  The Costas loop drifts through he
> QPSK constellation, but won't stay locked on it.  That probably means
> I don't have something right in GRC or there is an overlay modulation
> that confuses the Costas loop phase locking.  Until either my hybrid
> hardware/GRC setup starts locking onto the XM signal there will be no
> Channel 1.
>  
> Steve Katzberg
>
> - Original Message -
> *From:* Jason Matusiak 
> *To:* GNURadio Mailing List 
> *Sent:* Thursday, April 07, 2016 5:14 PM
> *Subject:* [Discuss-gnuradio] XM on GR
>
> I was thinking about XM radio today and how channel 1 on it is
> sent in the clear (if you don't have a subscription, you can tune
> to it and hear their adds).  I haven't found a lot of information
> (so I think I know the answer), but has anyone looked into an XM
> receiver in GR?
>
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio