Re: Are there firls and kaiser filter methods for C++ OOT?
Hi George,
You are welcome.
> Q1. If I write a line of code to extract the remez taps, say:
>lpfilter =
> gr::filter::pm_remez ( int order,
> const std::vector< double > & bands,
> const std::vector< double > & ampl,
> const std::vector< double > & error_weight,
> const std::string filter_type = "bandpass",
> int grid_density = 16
> )
> The pm_remez has a squidly line under it and if I hover it with the mouse,
> it says gr::filter has no member function pm_remez. (I tried a bunch of
> different variations of things, but the squidly line remains.)
Marcin: Have you included the appropriate header file in your code? You
should declare: *#include *
Q2. The doc write up states that the pm_remez filter_types are one of:
> bandpass, hilbert or differentiator. It seems like a natural for all these
> filters to provide a lowpass option, what do you think? If I can get rid of
> the squidly line, I would be able to test if "lowpass" works.
Marcin: I think that this depends on what you want to achieve. I cannot
help here because of the lack of exact knowledge about that, sorry.
Marcin
śr., 23 lut 2022 o 19:31 George Edwards napisał(a):
> Hi Marcin,
>
> Thank you very much! I found my error, I forgot the "gain" which is the
> first parameter to the filter. The first parameter I wrote in the filter
> method was the "sample_rate" (which was a large number), hence the filter
> function could not converge. It is all good now, thank you.
>
> I have two questions related to the remez filter (you may or maynot be
> able to give me an answer(s)):
> Q1. If I write a line of code to extract the remez taps, say:
>lpfilter =
> gr::filter::pm_remez ( int order,
> const std::vector< double > & bands,
> const std::vector< double > & ampl,
> const std::vector< double > & error_weight,
> const std::string filter_type = "bandpass",
> int grid_density = 16
> )
> The pm_remez has a squidly line under it and if I hover it with the mouse,
> it says gr::filter has no member function pm_remez. (I tried a bunch of
> different variations of things, but the squidly line remains.)
>
> Q2. The doc write up states that the pm_remez filter_types are one of:
> bandpass, hilbert or differentiator. It seems like a natural for all these
> filters to provide a lowpass option, what do you think? If I can get rid of
> the squidly line, I would be able to test if "lowpass" works.
>
> Thanks again for all your help.
>
> Regards,
> George
>
> On Wed, Feb 23, 2022 at 2:02 AM Marcin Puchlik
> wrote:
>
>> George,
>> Running the below code:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *#include #include using namespace
>> std;int main() { cout << "!!!Hello World!!!" << endl; // prints !!!Hello
>> World!!! std::vector taps = gr::filter::firdes::low_pass(1, 1, 0.3,
>> 0.1); for(int i = 0; i < taps.size(); i++) cout << "tap " << i << ":" <<
>> "\t" << taps[i] << "\n"; return 0;}*
>>
>> *I get the output:*
>>
>> !!!Hello World!!!
>> tap 0: -0.00124749
>> tap 1: 0.0026334
>> tap 2: -3.313e-18
>> tap 3: -0.00722382
>> tap 4: 0.00725102
>> tap 5: 0.0112526
>> tap 6: -0.0272494
>> tap 7: 1.54168e-17
>> tap 8: 0.0582835
>> tap 9: -0.0539706
>> tap 10: -0.0877955
>> tap 11: 0.298026
>> tap 12: 0.600081
>> tap 13: 0.298026
>> tap 14: -0.0877955
>> tap 15: -0.0539706
>> tap 16: 0.0582835
>> tap 17: 1.54168e-17
>> tap 18: -0.0272494
>> tap 19: 0.0112526
>> tap 20: 0.00725102
>> tap 21: -0.00722382
>> tap 22: -3.313e-18
>> tap 23: 0.0026334
>> tap 24: -0.00124749
>>
>>
>>
>>
>> śr., 23 lut 2022 o 02:39 George Edwards
>> napisał(a):
>>
>>> Hi Marcin and Vasil,
>>>
>>> Thank you guys very much!
>>>
>>> Marcin: I did as you suggested and left out win_type and beta.
>>> Vasil: Based on the conversation exchanges between you Marcin, I
>>> followed your suggestion to link in the gnuradio-filter library - in
>>> lib/CMakeLists.txt in target_link_libraries() by adding gnuradio-filter.
>>> Thus, the target_link_libraries in the original OOT lib/CMakeLists.txt
>>> file was:
>>> target_link_libraries(gnuradio-ge_filters gnuradio::gnuradio-runtime)
>>> and I added to it as shown below:
>>> target_link_libraries(gnuradio-ge_filters gnuradio::gnuradio-runtime
>>> gnuradio-filter)
>>> The OOT program compiles and makes the intended Gnuradio block for me to
>>> load in a GRC flowgraph. For experimental purposes, I made the OOT block to
>>> output the filter coefficients. When I run the grc, the lowpass filter
>>> outputs all zeros, so something is wrong!
>>> Marcin: You had written a piece of code to print "Hello World". Please
>>> run your code to print out the returned filter coefficients and let me know
>>> if it works well because mine is having some problems.
>>>
>>> This is how I invoked the filter method (all parameters are defined):
>>> vector lpfilter; //vector variable will contain the filter
>>> coeff's
>>> lpfilter = gr::filter::firdes::low_pass(gain, sampling_freq,
>>> cutoff_freq, transition_bandwidth);
>>>
>>> Thank you guys!
>>>
>>> George
>>>
Re: Are there firls and kaiser filter methods for C++ OOT?
Hi Marcin,
Thank you very much! I found my error, I forgot the "gain" which is the
first parameter to the filter. The first parameter I wrote in the filter
method was the "sample_rate" (which was a large number), hence the filter
function could not converge. It is all good now, thank you.
I have two questions related to the remez filter (you may or maynot be able
to give me an answer(s)):
Q1. If I write a line of code to extract the remez taps, say:
lpfilter =
gr::filter::pm_remez ( int order,
const std::vector< double > & bands,
const std::vector< double > & ampl,
const std::vector< double > & error_weight,
const std::string filter_type = "bandpass",
int grid_density = 16
)
The pm_remez has a squidly line under it and if I hover it with the mouse,
it says gr::filter has no member function pm_remez. (I tried a bunch of
different variations of things, but the squidly line remains.)
Q2. The doc write up states that the pm_remez filter_types are one of:
bandpass, hilbert or differentiator. It seems like a natural for all these
filters to provide a lowpass option, what do you think? If I can get rid of
the squidly line, I would be able to test if "lowpass" works.
Thanks again for all your help.
Regards,
George
On Wed, Feb 23, 2022 at 2:02 AM Marcin Puchlik
wrote:
> George,
> Running the below code:
>
>
>
>
>
>
>
>
>
>
>
>
> *#include #include using namespace
> std;int main() { cout << "!!!Hello World!!!" << endl; // prints !!!Hello
> World!!! std::vector taps = gr::filter::firdes::low_pass(1, 1, 0.3,
> 0.1); for(int i = 0; i < taps.size(); i++) cout << "tap " << i << ":" <<
> "\t" << taps[i] << "\n"; return 0;}*
>
> *I get the output:*
>
> !!!Hello World!!!
> tap 0: -0.00124749
> tap 1: 0.0026334
> tap 2: -3.313e-18
> tap 3: -0.00722382
> tap 4: 0.00725102
> tap 5: 0.0112526
> tap 6: -0.0272494
> tap 7: 1.54168e-17
> tap 8: 0.0582835
> tap 9: -0.0539706
> tap 10: -0.0877955
> tap 11: 0.298026
> tap 12: 0.600081
> tap 13: 0.298026
> tap 14: -0.0877955
> tap 15: -0.0539706
> tap 16: 0.0582835
> tap 17: 1.54168e-17
> tap 18: -0.0272494
> tap 19: 0.0112526
> tap 20: 0.00725102
> tap 21: -0.00722382
> tap 22: -3.313e-18
> tap 23: 0.0026334
> tap 24: -0.00124749
>
>
>
>
> śr., 23 lut 2022 o 02:39 George Edwards
> napisał(a):
>
>> Hi Marcin and Vasil,
>>
>> Thank you guys very much!
>>
>> Marcin: I did as you suggested and left out win_type and beta.
>> Vasil: Based on the conversation exchanges between you Marcin, I followed
>> your suggestion to link in the gnuradio-filter library - in
>> lib/CMakeLists.txt in target_link_libraries() by adding gnuradio-filter.
>> Thus, the target_link_libraries in the original OOT lib/CMakeLists.txt
>> file was:
>> target_link_libraries(gnuradio-ge_filters gnuradio::gnuradio-runtime)
>> and I added to it as shown below:
>> target_link_libraries(gnuradio-ge_filters gnuradio::gnuradio-runtime
>> gnuradio-filter)
>> The OOT program compiles and makes the intended Gnuradio block for me to
>> load in a GRC flowgraph. For experimental purposes, I made the OOT block to
>> output the filter coefficients. When I run the grc, the lowpass filter
>> outputs all zeros, so something is wrong!
>> Marcin: You had written a piece of code to print "Hello World". Please
>> run your code to print out the returned filter coefficients and let me know
>> if it works well because mine is having some problems.
>>
>> This is how I invoked the filter method (all parameters are defined):
>> vector lpfilter; //vector variable will contain the filter
>> coeff's
>> lpfilter = gr::filter::firdes::low_pass(gain, sampling_freq, cutoff_freq,
>> transition_bandwidth);
>>
>> Thank you guys!
>>
>> George
>>
>>
>> On Tue, Feb 22, 2022 at 3:41 PM Marcin Puchlik
>> wrote:
>>
>>> Geroge,
>>> I posted the working code a few messages ago. Try to check this out. BTW
>>> as far as I can see those two arguments are optional (window type and
>>> beta). Try to run your code without them and check if it works.
>>>
>>>
>>> wt., 22 lut 2022 o 19:25 George Edwards
>>> napisał(a):
>>>
Hello Vasil and Marcin,
Thanks very much for your help.
I have all the relevant #include header files and invoke the low_pass
filter as follows:
lpfilter = gr::filter::firdes::low_pass(gain, sampling_freq,
cutoff_freq, transition_bandwidth,
fft::window::win_type::WIN_HAMMING, beta);
Observations:
Using the mouse to hover over WIN_HAMMING, I can see that it
interprets the win_type enum variable and correctly assigns it a value of
"0" (which is the value stated in the Gnuradio C++ API Reference manual).
However, there is a squidly under beta. Hovering over beta, the error
message is:
Argument of type "double" is incompatible with parameter of type
"gr::fft::window::win_type"
If one of you has a working code fragment using one of the C++
Gnuradio filter methods that you can cut, paste and send in your next email
I would
Re: Adding external libs to an OOT block
Hi Dave,
fortunately, the process got simpler.
For now, let's assume the library you want to use supports CMake. In my
experience, every library you can install via `sudo apt install
lib...-dev` supports CMake.
Let's assume you want to use libfmt, then you need:
`find_package(fmt REQUIRED)`
in your top-level CMakeLists.txt.
In your `/lib/CMakeLists.txt` you need to add:
`target_link_libraries({YOUROOTMODULENAME} gnuradio::gnuradio-runtime
fmt::fmt)`.
That's it.
In case of VOLK, the 2 entries are:
`find_package(Volk REQUIRED)`
and
`Volk::volk`
The `REQUIRED` option let's CMake fail if it can't find the necessary
information. Otherwise, you'd have to check everything yourself.
You might have noticed that you can e.g. use VOLK without the CMake
entries in your OOT. That's because you include it with the GNU Radio
CMake config.
Cheers
Johannes
On 22.02.22 19:06, Ryan Volz wrote:
Hi Dave,
On 2/22/22 11:34 AM, David Cherkus wrote:
So, I found
https://stackoverflow.com/questions/48562304/gnuradio-c-oot-extrernal-so-library
which is a very good answer to how to get your OOT block to link to a
shared library from another package.
/As pointed out by the answer of Marcus Müller below I did not
link properly. In fact *one has to edit three different cmake files in
three places to add an external dynamically loaded library (.so) to an
OOT module in GNURadio*. I try to explain briefly what to do:
/
1. /Put a find_package(LIBNAME) in the CMakeLists.txt in the
base directory of the OOT module./
2. /Corresponding to that a FindLIBNAME.cmake file in the
cmake module path is necessary. This file has the purpose to implement
the search for include directories and library files (.so files)./
3. /Once found the path to the library has to be used with
target_link_libraries(...) in lib/CMakeLists.txt (linking)./
4. /The include file path, i.e. LIBNAME.h has to be added as
include directory using include_directories(...) in the CMakeLists.txt
in the base directory of the module.
/
/With ldd it is possible to find out if the external library
is linked correctly./
/
*ldd /usr/local/lib/YOURLIB.so*/
Am wondering if this is documented on the GNUradio web site? I could
use a bit more info, but will give it a go anyway. I did the C++
tutorial (
https://wiki.gnuradio.org/index.php?title=Guided_Tutorial_GNU_Radio_in_C%2B%2B
) and this was the very next thing I wanted to do, and I presume many
others as well. I know it's hard to know where to draw the line on
teaching enough vs too much, but I think this is a pretty frequent use
case, no? Note that I am teaching myself cmake on the fly. That's
OK, I just taught myself enough C++ to understand the tutorial on the
fly as well.
Regards,
Dave.
This can be easier or harder depending on how well the library you want
to link with supports CMake. In more detail, you may or may not have to
do step 2 of the instructions above, and it may be possible to skip 4 as
well if the library's include paths are part of the target that you
"link" with in step 3. So I think it is most helpful to ask: what
library specifically are you needing to link with?
In general I think covering how to use CMake is best left to the CMake
documentation, but the GNU Radio tutorials could probably benefit from a
simple example of linking with a "nice" external library. (That's if
they don't already include that somewhere, and I can't say that I've
looked!)
Cheers,
Ryan
Overflows "O" messages with USRP X300
Hi all,
I try to use a USRP X300 with a 10G Ethernet link at full speed (200MS/s).
I followed all the tips from
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks
but I still receive "O"s from time to time.
I don't have these messages at 100MS/s.
I'm surprised to receive these overflow warnings, because this is not what is
described in
https://files.ettus.com/manual/page_general.html#general_ounotes.
In this document, network-based devices are only supposed to drop ("D") packets
because there is no back-pressure.
So how is it possible to receive "O"s (i.e. the device's internal buffers
become full) with this setup?
Thanks for your answers.
Thomas
Re: Are there firls and kaiser filter methods for C++ OOT?
George,
Running the below code:
*#include #include using namespace
std;int main() { cout << "!!!Hello World!!!" << endl; // prints !!!Hello
World!!! std::vector taps = gr::filter::firdes::low_pass(1, 1, 0.3,
0.1); for(int i = 0; i < taps.size(); i++) cout << "tap " << i << ":" <<
"\t" << taps[i] << "\n"; return 0;}*
*I get the output:*
!!!Hello World!!!
tap 0: -0.00124749
tap 1: 0.0026334
tap 2: -3.313e-18
tap 3: -0.00722382
tap 4: 0.00725102
tap 5: 0.0112526
tap 6: -0.0272494
tap 7: 1.54168e-17
tap 8: 0.0582835
tap 9: -0.0539706
tap 10: -0.0877955
tap 11: 0.298026
tap 12: 0.600081
tap 13: 0.298026
tap 14: -0.0877955
tap 15: -0.0539706
tap 16: 0.0582835
tap 17: 1.54168e-17
tap 18: -0.0272494
tap 19: 0.0112526
tap 20: 0.00725102
tap 21: -0.00722382
tap 22: -3.313e-18
tap 23: 0.0026334
tap 24: -0.00124749
śr., 23 lut 2022 o 02:39 George Edwards napisał(a):
> Hi Marcin and Vasil,
>
> Thank you guys very much!
>
> Marcin: I did as you suggested and left out win_type and beta.
> Vasil: Based on the conversation exchanges between you Marcin, I followed
> your suggestion to link in the gnuradio-filter library - in
> lib/CMakeLists.txt in target_link_libraries() by adding gnuradio-filter.
> Thus, the target_link_libraries in the original OOT lib/CMakeLists.txt
> file was:
> target_link_libraries(gnuradio-ge_filters gnuradio::gnuradio-runtime)
> and I added to it as shown below:
> target_link_libraries(gnuradio-ge_filters gnuradio::gnuradio-runtime
> gnuradio-filter)
> The OOT program compiles and makes the intended Gnuradio block for me to
> load in a GRC flowgraph. For experimental purposes, I made the OOT block to
> output the filter coefficients. When I run the grc, the lowpass filter
> outputs all zeros, so something is wrong!
> Marcin: You had written a piece of code to print "Hello World". Please run
> your code to print out the returned filter coefficients and let me know if
> it works well because mine is having some problems.
>
> This is how I invoked the filter method (all parameters are defined):
> vector lpfilter; //vector variable will contain the filter
> coeff's
> lpfilter = gr::filter::firdes::low_pass(gain, sampling_freq, cutoff_freq,
> transition_bandwidth);
>
> Thank you guys!
>
> George
>
>
> On Tue, Feb 22, 2022 at 3:41 PM Marcin Puchlik
> wrote:
>
>> Geroge,
>> I posted the working code a few messages ago. Try to check this out. BTW
>> as far as I can see those two arguments are optional (window type and
>> beta). Try to run your code without them and check if it works.
>>
>>
>> wt., 22 lut 2022 o 19:25 George Edwards
>> napisał(a):
>>
>>> Hello Vasil and Marcin,
>>>
>>> Thanks very much for your help.
>>>
>>> I have all the relevant #include header files and invoke the low_pass
>>> filter as follows:
>>> lpfilter = gr::filter::firdes::low_pass(gain, sampling_freq,
>>> cutoff_freq, transition_bandwidth,
>>> fft::window::win_type::WIN_HAMMING, beta);
>>>
>>> Observations:
>>> Using the mouse to hover over WIN_HAMMING, I can see that it interprets
>>> the win_type enum variable and correctly assigns it a value of "0" (which
>>> is the value stated in the Gnuradio C++ API Reference manual). However,
>>> there is a squidly under beta. Hovering over beta, the error message
>>> is:
>>> Argument of type "double" is incompatible with parameter of type
>>> "gr::fft::window::win_type"
>>>
>>> If one of you has a working code fragment using one of the C++ Gnuradio
>>> filter methods that you can cut, paste and send in your next email I would
>>> appreciate it.
>>>
>>> Thanks for your help.
>>>
>>> George
>>>
>>> On Tue, Feb 22, 2022 at 6:15 AM Vasil Velichkov
>>> wrote:
>>>
Hi George,
On 21/02/2022 18.31, George Edwards wrote:
> lpfilter = gr::filter::firdes::low_pass(gain, sampling_freq,
cutoff_freq, transition_bandwidth,
> fft::window::win_type <
https://www.gnuradio.org/doc/doxygen/classgr_1_1fft_1_1window.html#a599d7e9625d6cc77203a8b877c4911e2>window
= fft::window::win_type::WIN_HAMMING, beta = 6.76);
>
> This failed and showed a squidly across the line with
fft::window::win_type!
Try adding "gr::" before "fft::window" and make sure
gnuradio/fft/window.h is included.
#include
lpfilter = gr::filter::firdes::low_pass(gain, sampling_freq,
cutoff_freq, transition_bandwidth,
gr::fft::window::win_type window =
fft::window::win_type::WIN_HAMMING, beta = 6.76);
If this does not fix it then provide the exact error you are getting.
Regards,
Vasil
>>>
