Buffer sizes for UDPSink, UDPSource?
Hi, I’m running gnuradio v3.7.13.5 under macOS Catalina. We’ve set up transmit and receive flow graphs for a simple BPSK system. We pass UDP messages which are received by a UDPSource at the start of the Rx flow graph, modulation is performed, and the carrier and symbols are sent to the Tx flow graph via a UDPSink. The Tx flow graph receives the data in a UDPSource, performs the demodulation, and outputs an assembled message from the bytes. When I send smaller messages, less than 256 bytes in original length, they pass through both flow graphs just fine, and we receive exactly what we sent. When I send larger messages, above 256 bytes (actually, they’re about 430 bytes), they don’t make it out of the UDPSource on the front end of the Rx flow graph. I’ve placed a file sink just before sending the complex data, and one just after receiving. The actual amount of data going across the UDP Sink —> Source is quite large - a single 180 byte message results in about 700K of complex data. But the larger messages never get finished. I’ve set the payload size on the UDPSource and UDPSink to 1024, and there’s been no problem with the smaller messages. Is there some kind of buffer overrun going on? When we send the 430 byte message, it expands to about 1.4 MB of data, which is all captured on the send side of the interface in the file, but on the receive side, there’s always only about 1.35 MB, which amounts to about 420 characters. Any ideas on this? Thank in advance! -Jeff
Re: Cannot compile and build a QTGUI OOT eye_sink
I'll second what Marcus wrote about your GR being out of date. Using the
latest GR37 or GR38 release would be a much better way to go if you can do
so.
I cloned your repo & had a heck of a time getting it to build. A few
comments on the code itself first:
* when you #include a GR header, it will be "#include " ..
not "#include " nor
"#include" . If you do the latter 2,
your code will either require more "include_directories" paths, or just
won't be portable beyond anyone using "/usr/local" for the GR install
prefix.
* similarly, your local files should be found at "#include "
not "#include ".
The above said, after digging around some on both GR37 and GR38 latest,
there might be an issue with the way GR is exporting class symbols in
QtGui. If you're up for some hacking to test out this theory, send me a
private email & I'll provide some info for your testing.
Cheers! - MLD
On Fri, Nov 8, 2019 at 9:32 AM Müller, Marcus (CEL) wrote:
> Hi Christophe,
>
> it's indeed a bit surprising that in 2019, I still have to mention
> that, but:
>
> Please don't use GNU Radio 3.7.11 to develop new GNU Radio software;
> Ubuntu 18.04 is a bit behind the curve on development; the current
> release of the 3.7 series is 3.7.13.5, and we've really fixed a lot of
> bugs since 3.7.11.
> I'd recommend updating to the latest and greatest Ubuntu to at least
> get that, anyways, but you can also use our Ubuntu PPA¹ for GNU Radio
> 3.8, that Josh thankfully set up. It would really make sense to do your
> QtGUI work with GNU Radio 3.8 – that uses Qt5 (only) and hence is
> future proof.
> By the way, if your eye diagram sink is universally useful, I'd
> certainly be very interested in you upstreaming it, but realistically,
> that would only happen if developed against master (or at least maint-
> 3.8), not the "maintenance and legacy mode" 3.7 series.
>
> Now, regarding your problem:
>
> > 2- insert in this module the gnuradio C code related to the original
> > time_sink; see my code on github
> > https://github.com/ChristopheSeg/eye_sink
>
>
> That is actually pretty much, pretty well-documented code there! I like
> it!
>
> Small correction, because relevant:
>
> > gnuradio C code
>
> That's C++! And as such, it has namespaces; your trigger_mode lives in
> gr::qtgui, your class lives in gr::csqtgui, and hence, just saying
> "trigger_mode" doesn't point to any existing type.
> What should work is using `gr::qtgui::trigger_mode` as type.
> You could also add a `using gr::qtgui::trigger_mode;` to the top of
> your header file, but: That requires C++11, and GNU Radio 3.7 isn't
> C++11, so that might or might not work.
>
> > .. namespace in those files
> > namespace gr {
> >namespace qtgui {
> >
> > all .cc files object are created , but cmake fails with a lot of
> > undefined reference to : DisplayForm::, gr::block::, boost, CppUnit,
> pmt>
>
> Yeah, so that's one source of problem down (living in the same
> namespace means that `trigger_mode` now defines a known type), but you
> did something I'm not sure you really want to do: put your OOT in the
> same name space as an in-tree module. I'd probably avoid the confusion
> and stay in your gr::csqtgui namespace, and explicitly use the
> `gr::qtgui::` namespace declaration when you want to use gr::qtgui
> things.
>
> Now, after the compilation works, the linking step tries to find the
> implementations of all the functions your code says it uses, and fails.
>
> Your attempts with direct g++ invocations are a way of investigating
> this, but in the end, you really want your CMake to correctly generate
> makefiles that do these calls for you, so I'd recommend not even trying
> to do that.
>
> That probably means you haven't told the build system that you want to
> *link* against gr-qtgui! Lemme check that in your CMakeLists.txt:
>
> > set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS QTGUI PMT VOLK)
>
> That's good, you're linking against qtgui; sure you want to link
> against blocks?
> Anyway, let us check lib/CMakeLists.txt:
>
> > target_link_libraries(gnuradio-csqtgui ${Boost_LIBRARIES}
> ${GNURADIO_ALL_LIBRARIES})
>
> Hm, that looks good!
>
> Can you actually do the following:
>
> 1. Make a clean build/ directory,
> 2. run `cmake .. > /tmp/log_cmake` from there; make sure there's no
> errors!
> 3. run `make VERBOSE=1 > /tmp/log_make` after
> 4. share the two files in /tmp/ with us (gist.github.com or fpaste.org
> or so)
>
> Best regards,
> Marcus
>
> ¹ that can be done via
> sudo add-apt-repository ppa:gnuradio/gnuradio-releases
> sudo apt-get update
> On Fri, 2019-11-08 at 14:38 +0100, Christophe Seguinot wrote:
> > Dear all
> >
> > I working under ubuntu 18.04 and GNURadio 3.7.11 and attempt to define a
> > QTGUI eye_sink block to display eye pattern under gnuradio-companion.
> > Without any knowledge of the best method to achieve this, I decided to:
> > 1- define a new OOT module using gr_modtool
> > gr_modtool newmod csqtgui
> > cd gr-csqtgui/
> >
Re: [Discuss-gnuradio] PyBOMBS documentation recommendations
Hi Glen, You're welcome. It's a much needed area. I am including comments from Mike Piscopo via Slack #docs with his permission: I had an issue a year or two ago where my pybombs install got messed up between python2 and python3. I had to make sure it was removed with both pip and pip3, then installed specifically with pip3 to bind to python3. Given that GR is moving away from python2, do we want to update the docs to specifically use pip3 and python3-pip? Also it may be worth recommending anyone upgrading to pip remove pybombs and pip3 install pybombs to make sure they're using the correct versions? Thoughts? -- Barry Duggan KV4FV On Fri, 8 Nov 2019 08:43:10 -0500 Glen Langston wrote: Thanks for all your documentation efforts!
Re: Cannot compile and build a QTGUI OOT eye_sink
Hi Christophe,
it's indeed a bit surprising that in 2019, I still have to mention
that, but:
Please don't use GNU Radio 3.7.11 to develop new GNU Radio software;
Ubuntu 18.04 is a bit behind the curve on development; the current
release of the 3.7 series is 3.7.13.5, and we've really fixed a lot of
bugs since 3.7.11.
I'd recommend updating to the latest and greatest Ubuntu to at least
get that, anyways, but you can also use our Ubuntu PPA¹ for GNU Radio
3.8, that Josh thankfully set up. It would really make sense to do your
QtGUI work with GNU Radio 3.8 – that uses Qt5 (only) and hence is
future proof.
By the way, if your eye diagram sink is universally useful, I'd
certainly be very interested in you upstreaming it, but realistically,
that would only happen if developed against master (or at least maint-
3.8), not the "maintenance and legacy mode" 3.7 series.
Now, regarding your problem:
> 2- insert in this module the gnuradio C code related to the original
> time_sink; see my code on github
> https://github.com/ChristopheSeg/eye_sink
That is actually pretty much, pretty well-documented code there! I like
it!
Small correction, because relevant:
> gnuradio C code
That's C++! And as such, it has namespaces; your trigger_mode lives in
gr::qtgui, your class lives in gr::csqtgui, and hence, just saying
"trigger_mode" doesn't point to any existing type.
What should work is using `gr::qtgui::trigger_mode` as type.
You could also add a `using gr::qtgui::trigger_mode;` to the top of
your header file, but: That requires C++11, and GNU Radio 3.7 isn't
C++11, so that might or might not work.
> .. namespace in those files
> namespace gr {
>namespace qtgui {
>
> all .cc files object are created , but cmake fails with a lot of
> undefined reference to : DisplayForm::, gr::block::, boost, CppUnit,
pmt>
Yeah, so that's one source of problem down (living in the same
namespace means that `trigger_mode` now defines a known type), but you
did something I'm not sure you really want to do: put your OOT in the
same name space as an in-tree module. I'd probably avoid the confusion
and stay in your gr::csqtgui namespace, and explicitly use the
`gr::qtgui::` namespace declaration when you want to use gr::qtgui
things.
Now, after the compilation works, the linking step tries to find the
implementations of all the functions your code says it uses, and fails.
Your attempts with direct g++ invocations are a way of investigating
this, but in the end, you really want your CMake to correctly generate
makefiles that do these calls for you, so I'd recommend not even trying
to do that.
That probably means you haven't told the build system that you want to
*link* against gr-qtgui! Lemme check that in your CMakeLists.txt:
> set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS QTGUI PMT VOLK)
That's good, you're linking against qtgui; sure you want to link
against blocks?
Anyway, let us check lib/CMakeLists.txt:
> target_link_libraries(gnuradio-csqtgui ${Boost_LIBRARIES}
> ${GNURADIO_ALL_LIBRARIES})
Hm, that looks good!
Can you actually do the following:
1. Make a clean build/ directory,
2. run `cmake .. > /tmp/log_cmake` from there; make sure there's no
errors!
3. run `make VERBOSE=1 > /tmp/log_make` after
4. share the two files in /tmp/ with us (gist.github.com or fpaste.org
or so)
Best regards,
Marcus
¹ that can be done via
sudo add-apt-repository ppa:gnuradio/gnuradio-releases
sudo apt-get update
On Fri, 2019-11-08 at 14:38 +0100, Christophe Seguinot wrote:
> Dear all
>
> I working under ubuntu 18.04 and GNURadio 3.7.11 and attempt to define a
> QTGUI eye_sink block to display eye pattern under gnuradio-companion.
> Without any knowledge of the best method to achieve this, I decided to:
> 1- define a new OOT module using gr_modtool
> gr_modtool newmod csqtgui
> cd gr-csqtgui/
> gr_modtool add -t sink -l cpp eye_sink_c
> gr_modtool add -t sink -l cpp eye_sink_f
> 2- insert in this module the gnuradio C code related to the original
> time_sink
> see my code on github https://github.com/ChristopheSeg/eye_sink
> 3- try to compile and install this OOT (at this step it should be a
> duplicate of the time-sink block)
> mdkir build
> cd build
> cmake ../
> qmake ../
> make
> 4- modify oot code to implement an eye-pattern plot
>
> But I'm stuck at step 3, unable to compile my OOT. (I succesfully tested
> the square_ff OOT module proposed in OOT tutorial 2)
>
> if I use csqtgui namespace in files eye_sinc_*.h eye_sink_*_impl.cc
> eye_sink_*_impl.h: no .o object file are generated
> namespace gr {
>namespace csqtgui {
>
> the error is than
> In file included from ../lib/eye_sink_c_impl.h:25:0,
> from ../lib/eye_sink_c_impl.cc:26:
> ../../gr-csqtgui/include/csqtgui/eye_sink_c.h:145:37: error:
> ‘trigger_mode’ has not been declared
> virtual void set_trigger_mode(trigger_mode mode, trigger_slope
> slope,
>
> When using
Re: [Discuss-gnuradio] PyBOMBS documentation recommendations
Thanks for all your documentation efforts! > On Nov 8, 2019, at 8:27 AM, Müller, Marcus (CEL) wrote: > > Hi Hans, > > I like that idea, but revision dates are a central feature of what a > Wiki like ours offers: you can click on "Versions" and see when the > current version was last edited. > > Sure, that might have just been a typo fix, but whether or not to > update the "state of" written statement is still as subjective, so I'd > argue: We've got an automatism for that that's just as good as the > human hand, so save the time of the human hand :) > What IS very helpful, especially in the context of installations, is > stating the platforms and versions of these used: they are not part of > what a Wiki can automatically track. I very much agree that the documentation is much more helpful if it includes a reference to the software revision number that is being described, along with the OS environment being used. > Best regards, > Marcus > > On Fri, 2019-11-08 at 13:31 +0800, HansFong wrote: >> Adding to this, please always add a revision date to any documentation, >> preferably at the top. It is so difficult to guess if documentation is >> current or not. Thank you --Hans (BX2ABT) >> >> On 11/8/19 11:12 AM, Barry Duggan wrote: >>> Greetings, >>> >>> I have found four URLs giving instructions on using PyBOMBS: >>> >>> https://wiki.gnuradio.org/index.php/InstallingGR#Using_PyBOMBS >>> https://github.com/gnuradio/pybombs/README.md >>> https://github.com/gnuradio/gnuradio/README.md >>> https://www.gnuradio.org/blog/2016-06-19-pybombs-the-what-the-how-and-the-why/ >>> >>> >>> >>> >>> In various comments in Discuss-gnuradio, I have concluded that most of >>> the PyBOMBS users who have failed were due to using old or incomplete >>> instructions. Also I think that most new users read the >>> InstallingGR#Using_PyBOMBS instructions only. >>> >>> As an advocate of having a single place to document instructions, I >>> highly recommend picking one site for those instructions, and then >>> having links to that page from all others. From what I see, the >>> https://github.com/gnuradio/pybombs/README.md page seems to be the >>> logical choice since it is revised as PyBOMBS is revised. >>> >>> If you choose to have the >>> https://wiki.gnuradio.org/index.php/InstallingGR#Using_PyBOMBS page >>> contain the current instructions as well, I can convert the >>> pybombs/README.md instructions to Mediawiki and put them in >>> InstallingGR#Using_PyBOMBS. >>> >>> Once you have decided what you want done, I can take care of the >>> edits, if you would like. >>> >>> Best regards,
Cannot compile and build a QTGUI OOT eye_sink
Dear all
I working under ubuntu 18.04 and GNURadio 3.7.11 and attempt to define a
QTGUI eye_sink block to display eye pattern under gnuradio-companion.
Without any knowledge of the best method to achieve this, I decided to:
1- define a new OOT module using gr_modtool
gr_modtool newmod csqtgui
cd gr-csqtgui/
gr_modtool add -t sink -l cpp eye_sink_c
gr_modtool add -t sink -l cpp eye_sink_f
2- insert in this module the gnuradio C code related to the original
time_sink
see my code on github https://github.com/ChristopheSeg/eye_sink
3- try to compile and install this OOT (at this step it should be a
duplicate of the time-sink block)
mdkir build
cd build
cmake ../
qmake ../
make
4- modify oot code to implement an eye-pattern plot
But I'm stuck at step 3, unable to compile my OOT. (I succesfully tested
the square_ff OOT module proposed in OOT tutorial 2)
if I use csqtgui namespace in files eye_sinc_*.h eye_sink_*_impl.cc
eye_sink_*_impl.h: no .o object file are generated
namespace gr {
namespace csqtgui {
the error is than
In file included from ../lib/eye_sink_c_impl.h:25:0,
from ../lib/eye_sink_c_impl.cc:26:
../../gr-csqtgui/include/csqtgui/eye_sink_c.h:145:37: error:
‘trigger_mode’ has not been declared
virtual void set_trigger_mode(trigger_mode mode, trigger_slope
slope,
When using sqtgui namespace in those files
namespace gr {
namespace qtgui {
all .cc files object are created , but cmake fails with a lot of
undefined reference to : DisplayForm::, gr::block::, boost, CppUnit, pmt
the error is than
g++ -m64 -Wl,-O1 -o gr-csqtgui eye_sink_c_impl.o eye_sink_f_impl.o
qa_csqtgui.o qa_eye_sink_c.o qa_eye_sink_f.o test_csqtgui.o
-L/usr/lib/x86_64-linux-gnu -lQtDeclarative -lQtGui -lQtCore -lpthread
eye_sink_c_impl.o: In function
`gr::qtgui::eye_sink_c_impl::set_update_time(double)':
eye_sink_c_impl.cc:(.text+0xc4): undefined reference to
`DisplayForm::setUpdateTime(double)'
I already modified my CMakelists.txt to include corresponding libraries
without any success
set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS QTGUI PMT VOLK)
find_package(Gnuradio "3.7.2" REQUIRED)
I tried to add -lgnuradio-blocks -lgnuradio-runtime -lgnuradio-qtgui
-lgnuradio-pmt in the last g++ command for testing but get the same errors
I didn't find any usefull help in GNURadio OOT pages, nor in other OOT
modules published on CGRAN.
Who could please tell me what is wrong in my method?
Regards, Christophe
Re: [Discuss-gnuradio] PyBOMBS documentation recommendations
Hi Hans, I like that idea, but revision dates are a central feature of what a Wiki like ours offers: you can click on "Versions" and see when the current version was last edited. Sure, that might have just been a typo fix, but whether or not to update the "state of" written statement is still as subjective, so I'd argue: We've got an automatism for that that's just as good as the human hand, so save the time of the human hand :) What IS very helpful, especially in the context of installations, is stating the platforms and versions of these used: they are not part of what a Wiki can automatically track. Best regards, Marcus On Fri, 2019-11-08 at 13:31 +0800, HansFong wrote: > Adding to this, please always add a revision date to any documentation, > preferably at the top. It is so difficult to guess if documentation is > current or not. Thank you --Hans (BX2ABT) > > On 11/8/19 11:12 AM, Barry Duggan wrote: > > Greetings, > > > > I have found four URLs giving instructions on using PyBOMBS: > > > > https://wiki.gnuradio.org/index.php/InstallingGR#Using_PyBOMBS > > https://github.com/gnuradio/pybombs/README.md > > https://github.com/gnuradio/gnuradio/README.md > > https://www.gnuradio.org/blog/2016-06-19-pybombs-the-what-the-how-and-the-why/ > > > > > > > > > > In various comments in Discuss-gnuradio, I have concluded that most of > > the PyBOMBS users who have failed were due to using old or incomplete > > instructions. Also I think that most new users read the > > InstallingGR#Using_PyBOMBS instructions only. > > > > As an advocate of having a single place to document instructions, I > > highly recommend picking one site for those instructions, and then > > having links to that page from all others. From what I see, the > > https://github.com/gnuradio/pybombs/README.md page seems to be the > > logical choice since it is revised as PyBOMBS is revised. > > > > If you choose to have the > > https://wiki.gnuradio.org/index.php/InstallingGR#Using_PyBOMBS page > > contain the current instructions as well, I can convert the > > pybombs/README.md instructions to Mediawiki and put them in > > InstallingGR#Using_PyBOMBS. > > > > Once you have decided what you want done, I can take care of the > > edits, if you would like. > > > > Best regards, smime.p7s Description: S/MIME cryptographic signature
Re: [Discuss-gnuradio] cannot find block tree panel in grc
Hi, I kind of had this experience a few days ago. Basically the block tree panel was just minimized to the right. i.e. the width was 0 and a mouse over and click fixed it. I hope this helps. It seems so obvious but it wasn't. Cheers Johannes On 07.11.19 22:16, Achilleas Anastasopoulos wrote: > > Have you fixed this issue? > I got the same thing in Ubuntu 18.04 since yesterday and cannot figure > out what happened... > > Achilleas
