Re: bye
be well
Re: Improving GRC usability: How do you deal with changes in .grc file behaviour caused by opening it on newer/older GRC version?
Hi there, I'd like to say thanks to the community members who've contributed to this issue so far, and make another request for anyone interested in giving their input. Has this scenario ever happened to you - You open a .grc file with an older (or newer) version of GRC than the file was created with. When you try to open it the .grc file behaves differently, due to differences in GRC version. -- How did you deal with this scenario? How did you get the .grc to execute as you expected? All GRC users input is very welcome: https://saneuxdesign.survey.fm/dealing-with-changes-in-how-grc-file-behaves-caused-by-opening-it-in-newer-or-older-grc-version Thanks, Bernard On 22/02/2022 11:55, Bernard Tyers - EI8FDB wrote: Hi there, I contribute to usability improvements to GNU Radio, and I'm looking for input from the community. Has this scenario ever happened to you - You open a .grc file with an older (or newer) version of GRC than the file was created with. When you try to open it the .grc file behaves differently, due to differences in GRC version. -- How did you deal with this scenario? How did you get the .grc to execute as you expected? Give your input by completing this short 3 question form: https://saneuxdesign.survey.fm/dealing-with-changes-in-how-grc-file-behaves-caused-by-opening-it-in-newer-or-older-grc-version You don't need to be a GNU Radio expert to give your input. If you've not experienced this scenario, but you have ideas on how you would go about it, your input is welcome. Any questions, please let me know. Thanks in advance, Bernard
QA Tests: Python vs C++
I started writing some QA tests which were missing for some blocks I'm working on (in maint-3.9). I decided to compare using Python vs using C++ when building new tests. When I started looking into the C++ tests, it seems that there are not a lot of examples around, so I started wondering why people may stick to Python over C++. I found Python quicker to code and easier to see what's being tested, but C++ would run the same test as the Python much quicker (according to the time output from make test). Writing in C++ also gives me the ability to run Visual Studio Code in debug easier and target sections of code under test, which is a very nice feature. Visual Studio Code seems to have problems with mixed languages under its visual debugging. Are there other aspects of Python for QA tests that I'm missing as to why it's the preferred method? I'm indifferent as to the tool used because I'll use whatever gets the job done, so I'm not trying to make this a language pro/con question. Thanks, Jeff
Re: QA Tests: Python vs C++
Jeff, When tests are done in C++, they also must be compiled, which adds to the overall gnuradio compilation time. In-tree the c++ tests are reserved mainly for testing the really low level like buffers. I agree with you that an all c++ target makes debugging easy, but you can launch the python flowgraphs with the GDB debugger using program: "/usr/bin/python3" and args: /path/to/the/qa_xxx.py. Josh On Mon, Mar 7, 2022 at 8:37 AM Jeff S wrote: > I started writing some QA tests which were missing for some blocks I’m > working on (in maint-3.9). I decided to compare using Python vs using C++ > when building new tests. When I started looking into the C++ tests, it > seems that there are not a lot of examples around, so I started wondering > why people may stick to Python over C++. > > > > I found Python quicker to code and easier to see what’s being tested, but > C++ would run the same test as the Python much quicker (according to the > time output from make test). Writing in C++ also gives me the ability to > run Visual Studio Code in debug easier and target sections of code under > test, which is a very nice feature. Visual Studio Code seems to have > problems with mixed languages under its visual debugging. > > > > Are there other aspects of Python for QA tests that I’m missing as to why > it’s the preferred method? I’m indifferent as to the tool used because > I’ll use whatever gets the job done, so I’m not trying to make this a > language pro/con question. > > > > Thanks, > > Jeff >
Re: Selecting a SDR as a sink
David, There are a couple of problems with using the selector in this configuration. 1) If you plan to just disable the sinks in GRC, then you don't need the selector at all. That block is intended to be used to change the configuration during runtime. You can just connect all the sinks to the same output and disable with the D key. 2) In the case where devices are present when the flowgraph is run, when the selector output is set to, e.g. 0, the outputs 1 and 2 produce no samples. This will starve the SDR sinks of samples and have some consequences (depends on the sdr) As far as the SDRs being instantiated, this is just how GRC works - it instantiates all the blocks that are present in the flowgraph. So if an SDR isn't present, then the block needs to be disabled - selector doesn't help you. Josh On Thu, Mar 3, 2022 at 11:07 PM David Cherkus wrote: > Asked this on chat, thought it might need a broader audience so am asking > here too... > > Part of my flowgraph looks like: > > [image: Inline image] > > > > I.e. a selector that selects between output to null sink, osmocom sink or > PlutoSDR sink. > > Problem is when I run the flow and no SDR is present (I select Null Sink > by default) the code still tries to instantiate the osmocom Sink and that > fails. If I disable the sinks for radios that aren't present with the 'D' > key, then the selector complains that the output is no longer connected. > Any ideas how to work around this? > > Regards, > Dave, N1AI > > >
bye
bye
Re: QA Tests: Python vs C++
Hi Jeff, since all the data handling is done in C++ land in GNU Radio anyways, the only difference in test performance is when the Python code takes longer to evaluate the the result of some flow graph. For example: if you write a test case where the data from a vector sink is compared to the data from some reference numpy vector, and you do that with a test function that recognizes both reference and test data are iterables, and then, in Python code, compares element-by-element, then that's slow. If you just did self.assertTrue(numpy.array_equiv(reference, self.sink.data())) that should be as fast as doing it C++. Best regards, Marcus On 07.03.22 16:40, Josh Morman wrote: Jeff, When tests are done in C++, they also must be compiled, which adds to the overall gnuradio compilation time. In-tree the c++ tests are reserved mainly for testing the really low level like buffers. I agree with you that an all c++ target makes debugging easy, but you can launch the python flowgraphs with the GDB debugger using program: "/usr/bin/python3" and args: /path/to/the/qa_xxx.py. Josh On Mon, Mar 7, 2022 at 8:37 AM Jeff S mailto:e070...@hotmail.com>> wrote: I started writing some QA tests which were missing for some blocks I’m working on (in maint-3.9). I decided to compare using Python vs using C++ when building new tests. When I started looking into the C++ tests, it seems that there are not a lot of examples around, so I started wondering why people may stick to Python over C++. __ __ I found Python quicker to code and easier to see what’s being tested, but C++ would run the same test as the Python much quicker (according to the time output from make test). Writing in C++ also gives me the ability to run Visual Studio Code in debug easier and target sections of code under test, which is a very nice feature. Visual Studio Code seems to have problems with mixed languages under its visual debugging. __ __ Are there other aspects of Python for QA tests that I’m missing as to why it’s the preferred method? I’m indifferent as to the tool used because I’ll use whatever gets the job done, so I’m not trying to make this a language pro/con question. __ __ Thanks, Jeff
Re: GRC 3.9.4.0 - module porting problem
Hi Ryan,
I eventually managed to port the working GRC code from 3.8.2.0 to 3.9.4.0 by
rebuilding the GRC with pybind11 2.5.0 installed and having replaced version
2.4.3, for all binding operations.
pygxxxml 2.2.1 was also retained.
The porting guide document after re-read is entirely correct about
compatibility.
Thanks again,
David
-Original Message-
From: Ryan Volz
Sent: Friday, March 4, 2022 10:22 PM
To: discuss-gnuradio@gnu.org
Subject: Re: GRC 3.9.4.0 - module porting problem
Hi David,
If it works somewhere with GR 3.9, then it's not a porting problem and
you've done everything right there.
I've recently discovered for myself that an OOT's Python bindings will throw
this error when even the compiler version is different between building GNU
Radio and the OOT, in addition to needing the same pybind11 version. Is
there a chance this is what you're seeing? Run "gnuradio-config-info --cxx"
to see what compiler GNU Radio was built with, and compare with what you're
using to build the OOT module.
(For me, this has happened in building OOT modules for conda-forge when the
conda-forge project recently started using GCC 10 instead of GCC 9. Modules
built with GCC 10 were not compatible with a GNU Radio built with GCC 9. It
turns out that they actually would be compatible, and pybind11 is being too
careful, but I would have had to know that ahead of time to avoid the
problem. So for now I have to stick to the same compiler version for
everything.)
Cheers,
Ryan
On 3/4/22 3:35 PM, David Taylor (manx.net) wrote:
Hi All,
I am sorry to be covering what is old ground, but I am having a final
loading issue with an otherwise working OOT block.
The block works under GRC 3.8.2.0 and GRC 3.9.4.0 was built on another
computer without issue.
ImportError:generic_type "channel_signal_generator_cc" referenced unknown
base type "gr::sync_block"
Ubuntu 20.04
python 3.8
pybind11 2.5.0 – replacing 2.4.3 in accordance with the latest 3.9 Module
Porting Guide (28 Feb 2022)
pygccxml 2.2.1
Additional libraries are found at cmake and during the build. The block
imports correctly with no changes necessary to the .yml file.
The new block was created using 3.9 gr_modtool and code dropped in, noting
the changes to shared_ptr use.
The block was sync_block type at definition, with the virtual block
classes noted in the porting guide automatically inserted during bind in
/python/bindings/
void bind_channel_signal_generator_cc(py::module& m)
{
using channel_signal_generator_cc=
::gr::oot::channel_signal_generator_cc;
py::class_gr::basic_block,
std::shared_ptr>(m,
"channel_signal_generator_cc", D(channel_signal_generator_cc))
.def(py::init(_signal_generator_cc::make),
py::arg("samp_rate"),
py::arg("length_chips"),
py::arg("duration_sec"),
py::arg("filename"),
py::arg("CN0_dB"),
D(channel_signal_generator_cc,make)
)
Any comments would be welcome.
Many thanks,
David GD4FMB
GRC: is it possible to show grid
Dear All, Is there a way to display the grid (to which blocks get locked) on the canvas? If not, any tips on how to implement it? Thanks. M.Patil
Re: GRC: is it possible to show grid
There is no option for that AFAIK. To implement it, you'll want to start here: https://github.com/gnuradio/gnuradio/blob/main/grc/gui/DrawingArea.py#L213 The grid size is defined in https://github.com/gnuradio/gnuradio/blob/main/grc/gui/Constants.py#L50 Best add a color in https://github.com/gnuradio/gnuradio/blob/main/grc/gui/canvas/colors.py To make it optional grep for some action like TOGGLE_SNAP_TO_GRID and add your own in the same manner. Sebastian On Mon, Mar 7, 2022 at 6:32 PM Prof. M.B. Patil wrote: > > Dear All, > > Is there a way to display the grid (to which > blocks get locked) on the canvas? If not, any > tips on how to implement it? > > Thanks. > M.Patil > > > > >
Re: GRC: is it possible to show grid
Thank you. This will be helpful. I was trying to see if Gtk allows grid drawing with a single command, but I could not find that. In that case, I guess I have to do two loops: one for horizontal lines (using move_to/line_to) and one for vertical lines. If there is a better way, please let me know. M.Patil On Mon, 7 Mar 2022, Sebastian Koslowski wrote: There is no option for that AFAIK. To implement it, you'll want to start here: https://github.com/gnuradio/gnuradio/blob/main/grc/gui/DrawingArea.py#L213 The grid size is defined in https://github.com/gnuradio/gnuradio/blob/main/grc/gui/Constants.py#L50 Best add a color in?https://github.com/gnuradio/gnuradio/blob/main/grc/gui/canvas/colors.py To make it optional grep for some action like TOGGLE_SNAP_TO_GRID and add your own in the same manner.? Sebastian On Mon, Mar 7, 2022 at 6:32 PM Prof. M.B. Patil wrote: Dear All, Is there a way to display the grid (to which blocks get locked) on the canvas? If not, any tips on how to implement it? Thanks. M.Patil
