Re: Creating my own Random Source
Hey, `byte` in itself is not a C++ type (`std::byte` might be, don't know).
Just use
`char` or `uint8_t` if you mean that. Are you the one introducing the type
`byte` by any
chance?
> I did
> gr_complex and I thought gr_byte
no, that doesn't exist.
You seem to be in need of a little more C++ practice! Writing a whole random
source might
be a bit much for a start.
Best regards,
Marcus
On 08.11.21 23:05, Mario Moran wrote:
> Good afternoon,
>
> I know there is already a Random Source, but my advisor would like me to
> create my own out
> of tree modules and use them in a flowgraph. So, I am creating my own block,
> here are my
> steps so everyone can see what I have done.
>
> gr_modtool newmod Random
> gr_modtool add my_Random_Byte_Source
> Block Type: Source
> Language: Cpp
> No arguments(Side note I might redo this and make arguments but for now it
> will be
> specific for one need)
> Add python QA code: n
> Add C++ QA code: y
> I then opened the my_Random_Byte_Source_impl.cc file and added:
> #include
> /*
> * The private constructor
> */
> my_Random_Byte_Source_impl::my_Random_Byte_Source_impl()
> : gr::sync_block("my_Random_Byte_Source",
> gr::io_signature::make(0, 0, 0),
> gr::io_signature::make(1, 1, sizeof(byte)))
> {}
>
> unsigned byte
> my_Random_Byte_Source_impl::get_bytes(const byte &sample)
> {
> return gr::random::random(0,0,4)
> }
>
> int
> my_Random_Byte_Source_impl::work(int noutput_items,
> gr_vector_const_void_star &input_items,
> gr_vector_void_star &output_items)
> {
> byte *out = (byte *) output_items[0];
>
> for(int i = 0; i < noutput_items; i++)
> {
> out[i] = get_bytes(i)
> }
>
> // Tell runtime system how many output items we produced.
> return noutput_items;
> }
>
> Then in the yml file I changed it up to be:
>
> id: Random_my_Random_Byte_Source
> label: my_Random_Byte_Source
> category: '[Random]'
>
> templates:
> imports: import Random
> make: Random.my_Random_Byte_Source()
>
> outputs:
> - label: out
> dtype: byte
>
>
> # 'file_format' specifies the version of the GRC yml format used in the file
> # and should usually not be changed.
> file_format: 1
>
> Now, I created the build directory and used cmake
> -DCMAKE_INSTALL_PREFIX=/home/mariom/prefix-3.8/ .. and it was able to
> complete this but it
> failed the make install. Here is the error:
>
> /home/mariom/gr-Random/lib/my_Random_Byte_Source_impl.cc: In constructor
> ‘gr::Random::my_Random_Byte_Source_impl::my_Random_Byte_Source_impl()’:
> /home/mariom/gr-Random/lib/my_Random_Byte_Source_impl.cc:46:51: error: ‘byte’
> was not
> declared in this scope
> 46 | gr::io_signature::make(1, 1, sizeof(byte)))
> | ^~~~
> /home/mariom/gr-Random/lib/my_Random_Byte_Source_impl.cc: At global scope:
> /home/mariom/gr-Random/lib/my_Random_Byte_Source_impl.cc:57:5: error:
> expected initializer
> before ‘my_Random_Byte_Source_impl’
> 57 | my_Random_Byte_Source_impl::get_bytes(const byte &sample)
> | ^~
> /home/mariom/gr-Random/lib/my_Random_Byte_Source_impl.cc: In member function
> ‘virtual int
> gr::Random::my_Random_Byte_Source_impl::work(int, gr_vector_const_void_star&,
> gr_vector_void_star&)’:
> /home/mariom/gr-Random/lib/my_Random_Byte_Source_impl.cc:67:7: error: ‘byte’
> was not
> declared in this scope
> 67 | byte *out = (byte *) output_items[0];
> | ^~~~
> /home/mariom/gr-Random/lib/my_Random_Byte_Source_impl.cc:67:13: error: ‘out’
> was not
> declared in this scope
> 67 | byte *out = (byte *) output_items[0];
> | ^~~
> /home/mariom/gr-Random/lib/my_Random_Byte_Source_impl.cc:67:26: error:
> expected
> primary-expression before ‘)’ token
> 67 | byte *out = (byte *) output_items[0];
> | ^
> /home/mariom/gr-Random/lib/my_Random_Byte_Source_impl.cc:71:24: error:
> ‘get_bytes’ was not
> declared in this scope
> 71 | out[i] = get_bytes(i)
> | ^
> make[2]: *** [lib/CMakeFiles/gnuradio-Random.dir/build.make:63:
> lib/CMakeFiles/gnuradio-Random.dir/my_Random_Byte_Source_impl.cc.o] Error 1
> make[1]: *** [CMakeFiles/Makefile2:301:
> lib/CMakeFiles/gnuradio-Random.dir/all] Error 2
> make: *** [Makefile:141: all] Error 2
>
> So, I know it doesn't like byte but I'm not sure why. I know when I did the
> tutorial I did
> gr_complex and I thought gr_byte would work but it did not so I tried the
> byte by itself
> but it still did not work. So, I imagine that the problem is there but is
> there anything I
> did wrong? How can I fix this? Please and thank you for your help everyone.
>
> P.S. I am using ubuntu 20.04, gnuradio 3.8.4.0, and I installed it using
> pybombs which is
> why I used cmake -DCMAKE_INT
Re: Creating my own Random Source
Well working with the tutorial called, " Guided Tutorial GNU Radio in C++"
there is a line of code:
gr::io_signature::make(1,1, sizeof(gr_complex)),
So that got me thinking, since I know that complex is not a normal complex
is not a normal data type so I thought that using "gr" was part of GNU
Radio I thought adding it in front of byte would be the correct way of
going. Would you recommend me using a double instead? Since then I might be
handling high values?
Also, I do know I am out of practice with C++, I have been working on my
coding skills these past few weeks. If you know any good practice websites
or videos that would also be great. I have been following a 10 hour lesson
video and taking notes and following along with Visual Studio 2019.
Thank you for your help.
-Mario Moran
On Tue, Nov 9, 2021 at 4:52 AM Marcus Müller wrote:
> Hey, `byte` in itself is not a C++ type (`std::byte` might be, don't
> know). Just use
> `char` or `uint8_t` if you mean that. Are you the one introducing the type
> `byte` by any
> chance?
>
> > I did
> > gr_complex and I thought gr_byte
>
> no, that doesn't exist.
>
> You seem to be in need of a little more C++ practice! Writing a whole
> random source might
> be a bit much for a start.
>
> Best regards,
> Marcus
>
> On 08.11.21 23:05, Mario Moran wrote:
> > Good afternoon,
> >
> > I know there is already a Random Source, but my advisor would like me to
> create my own out
> > of tree modules and use them in a flowgraph. So, I am creating my own
> block, here are my
> > steps so everyone can see what I have done.
> >
> > gr_modtool newmod Random
> > gr_modtool add my_Random_Byte_Source
> > Block Type: Source
> > Language: Cpp
> > No arguments(Side note I might redo this and make arguments but for now
> it will be
> > specific for one need)
> > Add python QA code: n
> > Add C++ QA code: y
> > I then opened the my_Random_Byte_Source_impl.cc file and added:
> > #include
> > /*
> > * The private constructor
> > */
> > my_Random_Byte_Source_impl::my_Random_Byte_Source_impl()
> > : gr::sync_block("my_Random_Byte_Source",
> > gr::io_signature::make(0, 0, 0),
> > gr::io_signature::make(1, 1, sizeof(byte)))
> > {}
> >
> > unsigned byte
> > my_Random_Byte_Source_impl::get_bytes(const byte &sample)
> > {
> > return gr::random::random(0,0,4)
> > }
> >
> > int
> > my_Random_Byte_Source_impl::work(int noutput_items,
> > gr_vector_const_void_star &input_items,
> > gr_vector_void_star &output_items)
> > {
> > byte *out = (byte *) output_items[0];
> >
> > for(int i = 0; i < noutput_items; i++)
> > {
> > out[i] = get_bytes(i)
> > }
> >
> > // Tell runtime system how many output items we produced.
> > return noutput_items;
> > }
> >
> > Then in the yml file I changed it up to be:
> >
> > id: Random_my_Random_Byte_Source
> > label: my_Random_Byte_Source
> > category: '[Random]'
> >
> > templates:
> > imports: import Random
> > make: Random.my_Random_Byte_Source()
> >
> > outputs:
> > - label: out
> > dtype: byte
> >
> >
> > # 'file_format' specifies the version of the GRC yml format used in the
> file
> > # and should usually not be changed.
> > file_format: 1
> >
> > Now, I created the build directory and used cmake
> > -DCMAKE_INSTALL_PREFIX=/home/mariom/prefix-3.8/ .. and it was able to
> complete this but it
> > failed the make install. Here is the error:
> >
> > /home/mariom/gr-Random/lib/my_Random_Byte_Source_impl.cc: In constructor
> > ‘gr::Random::my_Random_Byte_Source_impl::my_Random_Byte_Source_impl()’:
> > /home/mariom/gr-Random/lib/my_Random_Byte_Source_impl.cc:46:51: error:
> ‘byte’ was not
> > declared in this scope
> >46 | gr::io_signature::make(1, 1, sizeof(byte)))
> > | ^~~~
> > /home/mariom/gr-Random/lib/my_Random_Byte_Source_impl.cc: At global
> scope:
> > /home/mariom/gr-Random/lib/my_Random_Byte_Source_impl.cc:57:5: error:
> expected initializer
> > before ‘my_Random_Byte_Source_impl’
> >57 | my_Random_Byte_Source_impl::get_bytes(const byte &sample)
> > | ^~
> > /home/mariom/gr-Random/lib/my_Random_Byte_Source_impl.cc: In member
> function ‘virtual int
> > gr::Random::my_Random_Byte_Source_impl::work(int,
> gr_vector_const_void_star&,
> > gr_vector_void_star&)’:
> > /home/mariom/gr-Random/lib/my_Random_Byte_Source_impl.cc:67:7: error:
> ‘byte’ was not
> > declared in this scope
> >67 | byte *out = (byte *) output_items[0];
> > | ^~~~
> > /home/mariom/gr-Random/lib/my_Random_Byte_Source_impl.cc:67:13: error:
> ‘out’ was not
> > declared in this scope
> >67 | byte *out = (byte *) output_items[0];
> > | ^~~
> > /home/mariom/gr-Random/lib/my_Random_Byte_Source_impl.cc:67:26: error:
> expected
> > primary-expression before ‘)’ token
> >67 | byte
Re: Undefined symbol _ZN2gr12msg_accepter4postEN5boost13intrusive_ptrIN3pmt8pmt_baseEEES5_
On Mon, 8 Nov 2021 16:28:30 +0100 Marcus Müller wrote: > Hi John, > > as discussed on chat: this happens if, and only if, you're linking at > build time to a different library than your runtime shared library > loader finds. > > The fix is simple: make sure you've *not* got two versions of GNU > Radio around, one of which your linker finds during building of > gr-osmosdr, and a different one your ld.so finds. > > Best regards, > Marcus Yes, Marcus... I am certainly not an expert, and I've used C++ only sporadically. Still, this must be the first time that I haven't solved a compilation problem on my own (after 25+ years of linux). I'm not a frequent IRC visitor, for the same reason. I can't find any obvious mixup between versions. In each case I carefully looked for old version laying around, checked */cmake directories and */pkgconfig dirs for possible confusion. The only issue I detected was about the fact that there were both -gr38 (which is version 0.2.0) and real -0.2.0 versions to be found on the 'net. Please have a look at my reply to Vasil, and I'd really appreciate pointers to where I went wrong. John
Re: Undefined symbol _ZN2gr12msg_accepter4postEN5boost13intrusive_ptrIN3pmt8pmt_baseEEES5_
Hi Vasil. Thanks for replying! Below are the outputs of the commands you proposed. As you can see from the 'find', there is only one libgnuradio-runtime installed. Also, the 'ldd' on osmosdr seems to confirm the missing symbols, and everything is linked against the same libgnuradio-runtime.so.3.8.4 > Also make sure that you don't have multiple gnuradio versions > installed at the same time in /usr/ and /usr/local/ I also checked /usr/lib64/pkgconfig and /usr/local/lib64/pkgconfig to see if there were any misleading indications. Could it be that there are errors in the link commands for gnuradio-osmosdr? No errors appear during the linking process. All of the missing symbols seem related to 'pmt'. >From what's below, I cannot detect what I have to change. > find /usr/ -name "libgnuradio-runtime.so*" /usr/lib64/libgnuradio-runtime.so.3.8.4 /usr/lib64/libgnuradio-runtime.so.3.8.4.0 /usr/lib64/libgnuradio-runtime.so > ldd -r /usr/lib64/libgnuradio-osmosdr.so.0.2.0 linux-vdso.so.1 (0x7ffe0e323000) libboost_chrono.so.1.76.0 => /usr/lib64/libboost_chrono.so.1.76.0 (0x7f8349178000) librt.so.1 => /lib64/librt.so.1 (0x7f8349168000) libgnuradio-blocks.so.3.8.4 => /usr/lib64/libgnuradio-blocks.so.3.8.4 (0x7f8348ea8000) librtlsdr.so.0 => /usr/local/lib64/librtlsdr.so.0 (0x7f8348e9) libgnuradio-runtime.so.3.8.4 => /usr/lib64/libgnuradio-runtime.so.3.8.4 (0x7f8348d18000) libboost_system.so.1.76.0 => /usr/lib64/libboost_system.so.1.76.0 (0x7f8348d1) libthrift-0.15.0.so => /usr/lib64/libthrift-0.15.0.so (0x7f8348c5) libgnuradio-pmt.so.3.8.4 => /usr/lib64/libgnuradio-pmt.so.3.8.4 (0x7f8348bf) libboost_thread.so.1.76.0 => /usr/lib64/libboost_thread.so.1.76.0 (0x7f8348bd) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f8348ba8000) libboost_program_options.so.1.76.0 => /usr/lib64/libboost_program_options.so.1.76.0 (0x7f8348b5) libboost_filesystem.so.1.76.0 => /usr/lib64/libboost_filesystem.so.1.76.0 (0x7f8348b3) libboost_regex.so.1.76.0 => /usr/lib64/libboost_regex.so.1.76.0 (0x7f8348ae8000) liblog4cpp.so.4 => /usr/lib64/liblog4cpp.so.4 (0x7f8348aa8000) libgmpxx.so.4 => /usr/lib64/libgmpxx.so.4 (0x7f8348a98000) libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x7f8348a18000) libvolk.so.2.5 => /usr/lib64/libvolk.so.2.5 (0x7f8348578000) libdl.so.2 => /lib64/libdl.so.2 (0x7f834857) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x7f83483a) libm.so.6 => /lib64/libm.so.6 (0x7f834825) libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x7f834823) libc.so.6 => /lib64/libc.so.6 (0x7f834805) /lib64/ld-linux-x86-64.so.2 (0x7f8349258000) libusb-1.0.so.0 => /usr/lib64/libusb-1.0.so.0 (0x7f834803) libssl.so.1.1 => /lib64/libssl.so.1.1 (0x7f8347f98000) libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x7f8347cb8000) libicudata.so.69 => /usr/lib64/libicudata.so.69 (0x7f8346158000) libicui18n.so.69 => /usr/lib64/libicui18n.so.69 (0x7f8345e28000) libicuuc.so.69 => /usr/lib64/libicuuc.so.69 (0x7f8345c28000) liborc-0.4.so.0 => /usr/lib64/liborc-0.4.so.0 (0x7f83459a8000) libudev.so.1 => /lib64/libudev.so.1 (0x7f834598) libz.so.1 => /lib64/libz.so.1 (0x7f8345768000) undefined symbol: _ZN2gr12msg_accepter4postEN5boost13intrusive_ptrIN3pmt8pmt_baseEEES5_ (/usr/lib64/libgnuradio-osmosdr.so.0.2.0) undefined symbol: _ZN3pmt8list_hasEN5boost13intrusive_ptrINS_8pmt_baseEEERKS3_ (/usr/lib64/libgnuradio-osmosdr.so.0.2.0) undefined symbol: _ZN3pmt21intrusive_ptr_releaseEPNS_8pmt_baseE (/usr/lib64/libgnuradio-osmosdr.so.0.2.0) undefined symbol: _ZN3pmt3eqvERKN5boost13intrusive_ptrINS_8pmt_baseEEES5_ (/usr/lib64/libgnuradio-osmosdr.so.0.2.0) undefined symbol: _ZN3pmt21intrusive_ptr_add_refEPNS_8pmt_baseE (/usr/lib64/libgnuradio-osmosdr.so.0.2.0) undefined symbol: _ZN3pmt12dict_has_keyERKN5boost13intrusive_ptrINS_8pmt_baseEEES5_ (/usr/lib64/libgnuradio-osmosdr.so.0.2.0) > ldd -r /usr/lib64/libgnuradio-runtime.so linux-vdso.so.1 (0x7ffc3fb5b000) libgnuradio-pmt.so.3.8.4 => /usr/lib64/libgnuradio-pmt.so.3.8.4 (0x7ff30a19) libvolk.so.2.5 => /usr/lib64/libvolk.so.2.5 (0x7ff309cf) libboost_program_options.so.1.76.0 => /usr/lib64/libboost_program_options.so.1.76.0 (0x7ff309c98000) libboost_filesystem.so.1.76.0 => /usr/lib64/libboost_filesystem.so.1.76.0 (0x7ff309c78000) libboost_system.so.1.76.0 => /usr/lib64/libboost_system.so.1.76.0 (0x7ff309c7) libboost_regex.so.1.76.0 => /usr/lib64/libboost_regex.so.1.76.0 (0x7ff309c28000)
Information on the hackfest2110
Hello Gnuradio list, I was wondering if anyone had any info on the hackfest2110. I didn't know it was going on as I am new to GNUradio and would like to use CUDA with GNUradio on USRPs. Thanks, Mike Seguin
Calculating Symbol Sync Parameters
Hello all, I've been working with the symbol sync block and I was wondering how to calculate the parameters (TED Gain, Loop bandwidth, etc) given information from the protocol. There are some answers to how to calculate the TED gain on the internet but are still unclear to me, so hopefully someone out there can clarify. Any help would be appreciated Thanks, Patrick
Re: Undefined symbol _ZN2gr12msg_accepter4postEN5boost13intrusive_ptrIN3pmt8pmt_baseEEES5_
Hi John, On 09/11/2021 22.58, John Coppens wrote: > As you can see from the 'find', there is only one libgnuradio-runtime > installed. >> objdump -T /usr/lib64/libgnuradio-runtime.so | grep >> _ZN2gr12msg_accepter4postEN5boost13intrusive_ptrIN3pmt8pmt_baseEEES5_ > > (Does not return anything) > >> objdump -T /usr/lib64/libgnuradio-runtime.so | grep msg_accepter | > grep post > > 0009c9e0 gDF .text0147 Base > _ZN2gr12msg_accepter4postEN5boost10shared_ptrIN3pmt8pmt_baseEEES5_ Comparing the two symbols (the one your OOT is looking for with the one available in libgnuradio-runtime.so) you can see that the only difference is the boost pointer type (boost13intrusive_ptr vs boost10shared_ptr) _ZN2gr12msg_accepter4postEN5boost13intrusive_ptrIN3pmt8pmt_baseEEES5_ _ZN2gr12msg_accepter4postEN5boost10shared_ptrIN3pmt8pmt_baseEEES5_ $ c++filt _ZN2gr12msg_accepter4postEN5boost13intrusive_ptrIN3pmt8pmt_baseEEES5_ _ZN2gr12msg_accepter4postEN5boost10shared_ptrIN3pmt8pmt_baseEEES5_ gr::msg_accepter::post(boost::intrusive_ptr, boost::intrusive_ptr) gr::msg_accepter::post(boost::shared_ptr, boost::shared_ptr) In msg_accepter.h the post function is declared as void post(pmt::pmt_t which_port, pmt::pmt_t msg); And in pmt.h the pmt::pmt_t is declared as typedef boost::shared_ptr pmt_t; In aa9e2ec7abd [1] the type has been changed from boost::intrusive_ptr to boost::shared_ptr and this commit is available since gnuradio v3.8.0.0 $ git tag --sort version:refname --contains aa9e2ec7abd | head -1 v3.8.0.0 So most probably your OOT has been built with an older pmt.h from gnuradio 3.7.*. To find where pmt.h has been included from go in the gr-osmosdr's build directory and grep pmt.h recursively grep -R pmt.h . You can also try finding pmt.h from the root directory as it is can be installed in /opt/ or somewhere else. find / -name pmt.h You need to delete all leftovers from previous installations and have only one version of gnuradio headers and libraries. Then delete libgnuradio-osmosdr rm -f "/usr/lib64/libgnuradio-osmosdr.so*" Go in the gr-osmosdr source directory, remove the build directory and start from scratch. To get an error for undefined symbols configure it with cmake -DCMAKE_SHARED_LINKER_FLAGS="-Wl,--no-undefined" .. [1] https://github.com/gnuradio/gnuradio/commit/aa9e2ec7abd4f70f73ca9b83dc00c59cd7ba45d1 Regards, Vasil
