Re: gr-iqbal, gr-fosphor, gr-osmosdr updated to Gnuradio 3.8
> We use pkgconfig(gr-iqbal) style BuildRequires in our rpm spec files for > installation during package builds where we can and are somewhat > confused as to why you did this. Because GR 3.8 doesn't use .pc files to determine which path to include and which libs are needed to build and I don't like have two independent "source of truth". New modules created by gr-modtool also don't include pc files. It uses some new CMake magic which I'm not entirely sure how it works really but it seems it does. My understanding is it's automatically generated from the scoping of the target_link_libraries / target_include_directories (i.e. PUBLIC ones will be passed on to children) using the whole autogenerated FindGnuradioIqbalance.cmake thing that cmakes creates and installs automatically. That should be enough for building or do you get link / include issues ? > I have only looked at gr-iqbal so far, so if any of the others have had > the same treatment then ... :) > > Oh yes and I could not find any path to a release tarball for > gr-iqbal-0.38.1. > If there is a spec. friendly one I would love to know where it is. > I can normally find them in github or SF but cgit is another story. There isn't, we disabled it in cgit. Lots of crawlers wouldn't obey the robots.txt and kept crawling the link and since that archive is dynamically generated, it would overload the server with crawlers trying to download every archive of every branch and every tag for every projects ... You either need to make and host your own, or download from the github mirror ( https://github.com/osmocom/gr-iqbal/releases ) Cheers, Sylvain
GRC General Comment & Question
Good morning Marcus, and to the other erudite, frequent contributors to this e-mail list. I'm far from a subject matter expert on the GNU Radio Companion (GRC) but consider it to be one of the best examples of a user-friendly, mouse-driven, object-oriented programming environment. My hat's off to its original creator(s). Oh yeah, and the price is right ;-) The number of devices/tools available right out of the box is quite impressive IMO and the fact that GRC generates executable Python source code is a bonus. My question is how relatively difficult is it to create a new device (USRP, filters, modulators etc) that can be dragged to the GRC work area? Thanks for your time and comment. VTY, J.B. Wood
Re: GRC General Comment & Question
Dear John, you mean an external device that can interact with GNU Radio's sample streams? Well, I'd say it's not very hard per se – all you need is to write a driver for that device. That driver needs to have an interface that you can use to transmit samples from your PC to the device, or get samples from that device into your PC. Then, you'd call that from within a GNU Radio block. It's pretty much exactly what the USRP sink and source, or the audio sink and source do. The question of "how hard is it" is, however, tends to be dominated by boundary conditions: How fast do you need things to be? How experienced are you at building devices, and how experienced at writing drivers? Or do driver and device already exist, and you only need to write that GNU Radio block? Then it's mostly a question of programming proficiency. Best regards, Marcus On Wed, 2020-01-08 at 06:41 -0500, John Wood via GNU Radio, the Free & Open-Source Toolkit for Software Radio wrote: > Good morning Marcus, and to the other erudite, frequent contributors to this > e-mail list. I'm far from a subject matter expert on the GNU Radio Companion > (GRC) but consider it to be one of the best examples of a user-friendly, > mouse-driven, object-oriented programming environment. My hat's off to its > original creator(s). Oh yeah, and the price is right ;-) The number of > devices/tools available right out of the box is quite impressive IMO and the > fact that GRC generates executable Python source code is a bonus. My > question is how relatively difficult is it to create a new device (USRP, > filters, modulators etc) that can be dragged to the GRC work area? Thanks > for your time and comment. VTY, > > > J.B. Wood smime.p7s Description: S/MIME cryptographic signature
Re: GRC General Comment & Question
On 1/8/20 7:14 AM, Müller, Marcus (CEL) wrote:
Dear John,
you mean an external device that can interact with GNU Radio's sample
streams?
Well, I'd say it's not very hard per se – all you need is to write a
driver for that device. That driver needs to have an interface that you
can use to transmit samples from your PC to the device, or get samples
from that device into your PC.
Then, you'd call that from within a GNU Radio block. It's pretty much
exactly what the USRP sink and source, or the audio sink and source do.
The question of "how hard is it" is, however, tends to be dominated by
boundary conditions: How fast do you need things to be? How experienced
are you at building devices, and how experienced at writing drivers? Or
do driver and device already exist, and you only need to write that GNU
Radio block? Then it's mostly a question of programming proficiency.
Best regards,
Marcus
Marcus,
Thanks much for the quick reply. I guess I was thinking mostly about
GRC control of an external device but as you point out that would
require both a representation in GRC as well as a driver. I have one
candidate in mind, the RFnest RF channel emulator. It comes with its
own GUI ("RFView") but as a GRC block might be valuable in that it could
be used with USRPs or other GRC-defined block radios within the GRC
environment in performing link-quality assessments (oexpected perating
range/propagation loss, Doppler shift, multipath etc). VTY,
John Wood
Re: GnuRadio 3.9 : from gnuradio import channels issue
I working under Ubntu 18.04 and finally discovered that the issue
was related to the existence of 2 locations for my python3
dist-packages:
/usr/local/lib/python3.6/dist-packages/gnuradio/gr
/usr/local/lib/python3/dist-packages/gnuradio/gr (the latest
build)
whilst my python sys.path was using the older build
/usr/local/lib/python3.6/dist-packages/gnuradio/gr
I don't undestand how I get this situation (does this results
from multiple builds on different version of GNURadio?)
The only non elegant way I was able to solve this was using a
PYTHONPATH environment variable (export
PYTHONPATH='/usr/local/lib/python3/dist-packages')
Regards, Christophe
On 06/01/2020 22:50, Christophe
Seguinot wrote:
Hi
I'm finalizing an in tree QTGUI eye_sink block. I use a GRC
example which was working fine until I decided to upgrade my
local GNURadiorepro (GnuRadio and Volk upgraded to latest commit
on January 5 2020, I was previously using 3.9 master uploaded in
November 2019 ).
My eye_sink module is functional, however when using a
"channel model" I'm getting a python issue (I tested 2
different channels with similar issue).
Trying importing channels under python3 (from gnuradio
import channels) gives the same issue.
May be this can be related to
this commit ... but I did not succeeded in solving the
issue.
Regards, Christophe
=== error messages obtained under GRC
Generating:
'/home/seguinot/sdr_stuff/gnuradio-dev/gnuradio/gr-qtgui/examples/pyqt_eye_sink.py'
Executing: /usr/bin/python3 -u
/home/seguinot/sdr_stuff/gnuradio-dev/gnuradio/gr-qtgui/examples/pyqt_eye_sink.py
Traceback (most recent call last):
File
"/usr/local/lib/python3.6/dist-packages/gnuradio/channels/channels_swig.py",
line 14, in swig_import_helper
return importlib.import_module(mname)
File "/usr/lib/python3.6/importlib/__init__.py", line 126, in
import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 994, in
_gcd_import
File "", line 971, in
_find_and_load
File "", line 955, in
_find_and_load_unlocked
File "", line 658, in
_load_unlocked
File "", line 571, in
module_from_spec
File "", line 922,
in create_module
File "", line 219, in
_call_with_frames_removed
ImportError:
/usr/local/lib/python3.6/dist-packages/gnuradio/channels/_channels_swig.so:
undefined symbol:
_ZN2gr8channels23selective_fading_model24makeEjfbfiSt6vectorIfSaIfEES4_S4_S4_i
During handling of the above exception, another exception
occurred:
Traceback (most recent call last):
File
"/usr/local/lib/python3.6/dist-packages/gnuradio/channels/__init__.py",
line 31, in
from .channels_swig import *
File
"/usr/local/lib/python3.6/dist-packages/gnuradio/channels/channels_swig.py",
line 17, in
_channels_swig = swig_import_helper()
File
"/usr/local/lib/python3.6/dist-packages/gnuradio/channels/channels_swig.py",
line 16, in swig_import_helper
return importlib.import_module('_channels_swig')
File "/usr/lib/python3.6/importlib/__init__.py", line 126, in
import_module
return _bootstrap._gcd_import(name[level:], package, level)
ModuleNotFoundError: No module named '_channels_swig'
During handling of the above exception, another exception
occurred:
Traceback (most recent call last):
File
"/usr/local/lib/python3.6/dist-packages/gnuradio/channels/channels_swig.py",
line 14, in swig_import_helper
return importlib.import_module(mname)
File "/usr/lib/python3.6/importlib/__init__.py", line 126, in
import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 994, in
_gcd_import
File "", line 971, in
_find_and_load
File "", line 955, in
_find_and_load_unlocked
File "", line 658, in
_load_unlocked
File "", line 571, in
module_from_spec
File "", line 922,
in create_module
File "", line 219, in
_call_with_frames_removed
ImportError:
/usr/local/lib/python3.6/dist-packages/gnuradio/channels/_channels_swig.so:
undefined symbol:
_ZN2gr8channels23selective_fading_model24makeEjfbfiSt6vectorIfSaIfEES4_S4_S4_i
During handlin
Re: GRC General Comment & Question
Hi John,
If there's already a C++ or Python driver (or one that can be easily
wrapped/called by one of those languages) then the additional code (an
Out Of Tree module) to expose the device into GRC is usually very
straightforward. I've done a few hardware devices now from DC power
supplies up to more complicated pieces of equipment. The GNU Radio
tutorials cover how to do this.
https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_Python#3.2._Where_Do_Blocks_Come_From.3F
It looks as if IAI's website is down, and I don't see much in the way of
signs of life from the company in the last two years. Looking at the
RFNest's documentation from Google's cache they don't mention any user
facing API code, but have documented all the control packets. Perhaps
you have access to more information than is publicly available.
https://webcache.googleusercontent.com/search?q=cache:gNq-u32akcEJ:https://www.i-a-i.com/wp-content/uploads/2017/07/RFnest_API_v2.pdf+&cd=1&hl=en&ct=clnk&gl=uk&client=ubuntu
GNU Radio does have some channel model blocks already included in it's
core and it would be excellent to see more developed. I think it's
pretty safe for me to say that we'd welcome enhancements to existing
blocks and new functionality into the core codebase.
https://www.gnuradio.org/doc/doxygen/group__channel__models__blk.html
Regards,
Derek
On 08/01/2020 13:22, John Wood via GNU Radio, the Free & Open-Source
Toolkit for Software Radio wrote:
> On 1/8/20 7:14 AM, Müller, Marcus (CEL) wrote:
>> Dear John,
>>
>> you mean an external device that can interact with GNU Radio's sample
>> streams?
>>
>> Well, I'd say it's not very hard per se – all you need is to write a
>> driver for that device. That driver needs to have an interface that you
>> can use to transmit samples from your PC to the device, or get samples
>> from that device into your PC.
>> Then, you'd call that from within a GNU Radio block. It's pretty much
>> exactly what the USRP sink and source, or the audio sink and source do.
>>
>> The question of "how hard is it" is, however, tends to be dominated by
>> boundary conditions: How fast do you need things to be? How experienced
>> are you at building devices, and how experienced at writing drivers? Or
>> do driver and device already exist, and you only need to write that GNU
>> Radio block? Then it's mostly a question of programming proficiency.
>>
>> Best regards,
>> Marcus
>>
> Marcus,
>
> Thanks much for the quick reply. I guess I was thinking mostly about
> GRC control of an external device but as you point out that would
> require both a representation in GRC as well as a driver. I have one
> candidate in mind, the RFnest RF channel emulator. It comes with its
> own GUI ("RFView") but as a GRC block might be valuable in that it
> could be used with USRPs or other GRC-defined block radios within the
> GRC environment in performing link-quality assessments (oexpected
> perating range/propagation loss, Doppler shift, multipath etc). VTY,
>
>
> John Wood
>
Re: gr-iqbal, gr-fosphor, gr-osmosdr updated to Gnuradio 3.8
On 1/8/20 3:07 AM, Sylvain Munaut wrote: >> We use pkgconfig(gr-iqbal) style BuildRequires in our rpm spec files for >> installation during package builds where we can and are somewhat >> confused as to why you did this. > > Because GR 3.8 doesn't use .pc files to determine which path to > include and which libs are needed to build and I don't like have two > independent "source of truth". New modules created by gr-modtool also > don't include pc files. > > It uses some new CMake magic which I'm not entirely sure how it works > really but it seems it does. My understanding is it's automatically > generated from the scoping of the target_link_libraries / > target_include_directories (i.e. PUBLIC ones will be passed on to > children) using the whole autogenerated FindGnuradioIqbalance.cmake > thing that cmakes creates and installs automatically. > > That should be enough for building or do you get link / include issues ? > >> I have only looked at gr-iqbal so far, so if any of the others have had >> the same treatment then ... :) >> >> Oh yes and I could not find any path to a release tarball for >> gr-iqbal-0.38.1. >> If there is a spec. friendly one I would love to know where it is. >> I can normally find them in github or SF but cgit is another story. > > There isn't, we disabled it in cgit. Lots of crawlers wouldn't obey > the robots.txt and kept crawling the link and since that archive is > dynamically generated, it would overload the server with crawlers > trying to download every archive of every branch and every tag for > every projects ... > > You either need to make and host your own, or download from the github > mirror ( https://github.com/osmocom/gr-iqbal/releases ) Standard warning, github is known to regenerate tarballs with different contents that lead to sha has mismatches with time making it hard to validate the downloaded tarball. Don't depend on githb downloaded tarballs if you care about supply chain integrity. Philip > > Cheers, > > Sylvain >
Re: gr-iqbal, gr-fosphor, gr-osmosdr updated to Gnuradio 3.8
Hi Phil, > > > > You either need to make and host your own, or download from the > > github mirror ( https://github.com/osmocom/gr-iqbal/releases ) > > Standard warning, github is known to regenerate tarballs with > different contents that lead to sha has mismatches with time making > it hard to validate the downloaded tarball. Don't depend on githb > downloaded tarballs if you care about supply chain integrity. This is a bit imprecise: The contents of the tarball are not different, but rather are timestamps might differ for _automatic_ generated tarballs. This is due to GitHub sometimes regenerating tarballs on the fly. If a release tarball is created manually and uploaded as asset for a release tag there is no problem. Cheers A pgpSnPIESw7zZ.pgp Description: OpenPGP digital signature
Re: gr-iqbal, gr-fosphor, gr-osmosdr updated to Gnuradio 3.8
Jep; that's why I also upload all GNU Radio release tarballs to github. Cheers Marcus On Wed, 2020-01-08 at 17:59 +0100, Andrej Rode wrote: > Hi Phil, > > > > > You either need to make and host your own, or download from the > > > github mirror ( https://github.com/osmocom/gr-iqbal/releases ) > > > > Standard warning, github is known to regenerate tarballs with > > different contents that lead to sha has mismatches with time making > > it hard to validate the downloaded tarball. Don't depend on githb > > downloaded tarballs if you care about supply chain integrity. > > This is a bit imprecise: The contents of the tarball are not > different, but rather are timestamps might differ for _automatic_ > generated tarballs. This is due to GitHub sometimes regenerating > tarballs on the fly. > > If a release tarball is created manually and > uploaded as asset for a release tag there is no problem. > > Cheers > A > smime.p7s Description: S/MIME cryptographic signature
Ideas for Dissertation Topics
Hello All I'm in the process of trying to figure out a topic for my dissertation and I figured I would come here since this forum has provided much help for me throughout the years. I've done research involving spectrum sensing, physical layer security and I'm currently looking into lpi/lpd communications. I think this is a pretty interesting topic, however, I'm having some difficulty coming up with a unique topic. Are there any interesting topics you guys have come across? Tellrell White
FSK and Timing Recovery Questions
Hello Mailing List, Happy New Year! I've been playing around with this ( http://aaronscher.com/GNU_Radio_Companion_Collection/Audio_Modem_loop_back_test_FSK.html) FSK audio modem and have a few issues/questions. 1) Is the PFB block the way to go for FSK timing recovery? I have issues where if I start the receiver before the transmitter, the system doesn't work. And if I start the transmitter before the receiver, it will eventually lose sync and never recover. I added a message strobe to send dummy data once a second (like a keep alive/heartbeat) and this helps it from losing sync in between time of when I send meaningful data. 1a) Reading docs on both PFB and M&M blocks, do I need a moving avg. filter after quad demod to round out the square pulses to allow PFB and M&M to better find peaks or is the moving avg filter implemented within the block? 2) Is the pre-amble being muxed doing anything more than just padding my data to help the PFB lock in before actual data arrives? 3) Would the Correlation Estimator help since it can send "time_est" tags downstream to the PFB and if so, where would be the ideal place to put it? Cheers, Alex
Wrong values with IIR_Filter in my OOT-Module design
Hi community! First, thanks for dedicating time to help me
I have a problem with using an *IIR filter* in my OOT module, which cannot
solve
I get different outputs using the
a)IIR_filter in grc and
b)using the filter as a block in my OOT module.
A
nd the outputs I get with b) are wrong.
Any advice or hint why I get wrong IIR-filter output values with my OOT
module design?
--
In both scenarios, I set the input vector and taps to be the same. I have
checked that.* The input is a vector with 8 float values*
The only difference is that in a) the input is a *vector_source block*, and
in b) the input is the output of an OOT block that I created in C++.
*a) **top_block.py*
self.iir_filter_xxx_0 = filter.iir_filter_ffd(((0.0173, 0,-0.0520,
0,0.0520,0,-0.0173)), ((1.,-3.0140,4.8671,-4.8327,3.2074
,-1.2968,0.2844)), False)
self.blocks_vector_source_x_0 = blocks.vector_source_f((-7.82476e-06 ,
6.03754e-06 , -4.76197e-06 , -2.3359e-05 , 4.91579e-06 , -9.69721e-06 ,
-5.10805e-06 , 2.64173e-05 ), False, 1, [])
self.connect((self.blocks_vector_source_x_0, 0),
(self.iir_filter_xxx_0, 0))
self.connect((self.iir_filter_xxx_0, 0), (self.blocks_file_sink_0, 0))
*b)**/apps/main.py*
self.bpf_filter0 = filter.iir_filter_ffd(((0.0173, 0,-0.0520,
0,0.0520,0,-0.0173)), ((1.,-3.0140,4.8671,-4.8327,3.2074
,-1.2968,0.2844)), False)
self.connect((self.my_OOT_block,0), (self.bpf_filter0,0))
* /lib/my_OOT_block_Impl.cc*
//main parts of my OOT block
void
my_OOT_block_impl::forecast (int noutput_items, gr_vector_int
&ninput_items_required)
{
ninput_items_required[0] = noutput_items;
}
int
car_filter_impl::general_work (int noutput_items,
gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const float *in0 = (const float *) input_items[0];
float *out0 = (float *) output_items[0];
int consumed = ninput_items[0];
int written = 0;
//Send 8 float values to the filter
for (int i = 0; i<8; i ++){
out0[i] = my_vector[i];
written ++;
}
produce(0,written);
consume_each (consumed);
return WORK_CALLED_PRODUCE;
}
--
*Laura Arjona *
Washington Research Foundation Innovation Postdoctoral Fellow in
Neuroengineering
*Paul G. Allen School of Computer Science & Engineering*
185 E Stevens Way NE
University of Washington
Seattle, WA 98195-2350
Re: Wrong values with IIR_Filter in my OOT-Module design
Forgot to say that I get the same values when I pass samples one by one
from my OOT block to the filter (instead of passing them in vectors of 8
samples)
On Wed, Jan 8, 2020 at 2:24 PM Laura Arjona wrote:
> Hi community! First, thanks for dedicating time to help me
>
> I have a problem with using an *IIR filter* in my OOT module, which
> cannot solve
> I get different outputs using the
> a)IIR_filter in grc and
> b)using the filter as a block in my OOT module.
> A
> nd the outputs I get with b) are wrong.
>
> Any advice or hint why I get wrong IIR-filter output values with my OOT
> module design?
>
> --
>
> In both scenarios, I set the input vector and taps to be the same. I have
> checked that.* The input is a vector with 8 float values*
> The only difference is that in a) the input is a *vector_source block*,
> and in b) the input is the output of an OOT block that I created in C++.
>
>
> *a) **top_block.py*
> self.iir_filter_xxx_0 = filter.iir_filter_ffd(((0.0173, 0,-0.0520,
> 0,0.0520,0,-0.0173)), ((1.,-3.0140,4.8671,-4.8327,3.2074
> ,-1.2968,0.2844)), False)
> self.blocks_vector_source_x_0 = blocks.vector_source_f((-7.82476e-06 ,
> 6.03754e-06 , -4.76197e-06 , -2.3359e-05 , 4.91579e-06 , -9.69721e-06 ,
> -5.10805e-06 , 2.64173e-05 ), False, 1, [])
> self.connect((self.blocks_vector_source_x_0, 0),
> (self.iir_filter_xxx_0, 0))
> self.connect((self.iir_filter_xxx_0, 0), (self.blocks_file_sink_0, 0))
>
> *b)**/apps/main.py*
> self.bpf_filter0 = filter.iir_filter_ffd(((0.0173, 0,-0.0520,
> 0,0.0520,0,-0.0173)), ((1.,-3.0140,4.8671,-4.8327,3.2074
> ,-1.2968,0.2844)), False)
> self.connect((self.my_OOT_block,0), (self.bpf_filter0,0))
>
> * /lib/my_OOT_block_Impl.cc*
> //main parts of my OOT block
> void
> my_OOT_block_impl::forecast (int noutput_items, gr_vector_int
> &ninput_items_required)
> {
> ninput_items_required[0] = noutput_items;
>}
>
> int
> car_filter_impl::general_work (int noutput_items,
>gr_vector_int &ninput_items,
>gr_vector_const_void_star &input_items,
>gr_vector_void_star &output_items)
> {
> const float *in0 = (const float *) input_items[0];
> float *out0 = (float *) output_items[0];
> int consumed = ninput_items[0];
> int written = 0;
>
> //Send 8 float values to the filter
> for (int i = 0; i<8; i ++){
> out0[i] = my_vector[i];
> written ++;
>
> }
>
> produce(0,written);
> consume_each (consumed);
>
> return WORK_CALLED_PRODUCE;
> }
>
>
>
> --
> *Laura Arjona *
> Washington Research Foundation Innovation Postdoctoral Fellow in
> Neuroengineering
>
> *Paul G. Allen School of Computer Science & Engineering*
> 185 E Stevens Way NE
> University of Washington
> Seattle, WA 98195-2350
>
--
*Laura Arjona *
Washington Research Foundation Innovation Postdoctoral Fellow in
Neuroengineering
*Paul G. Allen School of Computer Science & Engineering*
185 E Stevens Way NE
University of Washington
Seattle, WA 98195-2350
