Re: Tag or message to GUI indicator

[Jacob Gilbert]

Hi Marcin

You can use the QT Edit Box Message block to display the contents of a
message on a GR GUI, there are some limitations but it might fit your need.

Use the block with string type input, not in pair mode, not in static mode.
You can publish a message consisting of just a PMT string and that string
will show up in the box. It's not perfect, and the user can modify the
contents of the box but might work for you.

Jacob



On Tue, Dec 22, 2020, 06:29 Marcin Wachowiak 
wrote:

> Hello,
> May I ask what is the best way to visualize tags or messages in GR GUI?
> For example: there is a head block with reset function that each time it
> has processed specified number of samples sends tag or message "FINISHED".
> I am looking for a way this tag or message would affect a variable or some
> GUI element. Dumping tags or messages to terminal via debug block is quite
> neat , but is there any possibility to show all information in GUI (in a
> form of simple indicator: True/False or value)?.
>
> I didn't wanted to employ any streams or sources triggered by tag or
> message to reduce resources utilization.
>
> Kind regards,
> Marcin Wachowiak
>

Re: [Discuss-gnuradio] Eventstream source latency

[Jacob Gilbert]

Hi Daniel

You might be interested in the gr-pdu_utils and gr-timing_utils modules.
They are about to get a significant update but there is a decent writeup on
the concept of operations in github.

Sub-ms latency is possible depending on host hardware and system
configuration.

Jacob



On Fri, Aug 16, 2019, 10:08 Lundberg, Daniel via Discuss-gnuradio <
discuss-gnuradio@gnu.org> wrote:

> I have a flowgraph with a simple FDMA implementation with two channels.
> One channel has a constant stream.  The other channel has complex sample
> bursts generated in a custom python function, which I package as a PDU.  I
> apply the frequency modulation within the python file to place it in the
> correct frequency channel.  I send the PDU to an eventstream source and
> then add the two channels in an add block before sending the merged signal
> to a USRP sink.  I am seeing latencies of over a second from the PDU
> generation to when the eventstream source sends them on.  My sample rate is
> ~5 Ms/s and my PDU is about 1.25 MS, so about a quarter of a second.  My
> eventstream source block is using ASAP event placement and MEMCPY settings.
>
> Is this level of latency expected?  I do not fully understand the merge
> behavior of the eventstream source, but I would expect perhaps 2X the PDU
> size of latency if it has a PDU length number of zeros in it's buffer
> before inserting the PDU.
>
> Thank you,
> DL
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OOT Modules: PDU Utilities and Timing Utilities

[Jacob Gilbert]

I wanted to point out two general purpose OOT modules we developed for some
internal work and recently published: gr-pdu_utils and gr-timing_utils,
available here:

https://github.com/sandialabs/gr-pdu_utils
https://github.com/sandialabs/gr-timing_utils

These contain a variety of useful blocks for manipulating PDUs, converting
to/from PDUs/streams, and an assortment of functions we've needed over
time. A lightweight method for reasonable (+/- a few samples) timing of
receive bursts is included based on UHD-style rx_time tags, and UHD-style
transmit timing is supported as well for transceiver applications. The PDU
Utils module has a fairly good README describing use, Timing Utils README
is coming soon (the module was published early as a the two are related).

These modules were initially developed for bursty transceiver applications,
but have found use in tons of other ways over the past few years from
vector signal measurements to static data analysis to FHSS systems, and
sometimes it's just more useful to work with messages vs streams.

There are other ways to do some of what we have implemented here, but these
modules were developed to address some features we needed in a lightweight,
easy to use way. We have used the core blocks fairly extensively, and they
should work very well, though I can't promise there aren't edge cases we
haven't worked through yet, and there are some in-progress blocks. Bug
reports/fixes are appreciated - hope some of you find these modules useful.

Jacob
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Profiling Gnuradio message based blocks

[Jacob Gilbert]

Hi Emanuel,

This is related to a larger issue in which the controlport interface (used
for performance monitoring in addition to other features) is only started
for blocks with at least one stream connection. I submitted a PR for this (
https://github.com/gnuradio/gnuradio/pull/1119) which be included in the
upcoming 3.7.10.2 but if you want it now you can easily patch it in.

Jacob


On Fri, Jan 13, 2017 at 1:13 AM,  wrote:

> Hi all,
>
>
>
> I managed to get Apache thrift up and running and configured by
> environment to use the control port and performance counters.
> gr-perf-monitorx works fine and shows me my flowgraph as intended.
>
> My flowgraph consists of several streaming based blocks and many purely
> message based blocks (message in / message out) between a USRP source and a
> USRP sink.
>
>
>
> My question now is: are purely message based blocks without a work
> function correctly profiled as well?
>
>
>
> I see my  message blocks appearing in the gr-perf-monitorx visualizer with
> a box around, where the box size indicates the runtime usage. However when
> I switch the view to the runtime table and have a look there, I do not see
> my purely message based blocks in the table. Only those blocks which have
> at least one streaming interface are visible there. Any ideas?
>
>
>
> Thanks in advance and thanks to Thomas Rondau et. al. for this kind of
> profiling functionality. A very convenient tool indeed.
>
>
>
> Regards,
>
> Emanuel
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PyBOMBS: Error installing package python-zmq

[Jacob Gilbert]

Cyrille, I recently PR'd python-zmq as a dependency to GR as it is required
for the ZMQ blocks to work from python. I did not check to see if this
worked on arch though. If you want a workaround in the near term you can
uncomment the line in gnuradio.lwr that adds python-zmq as a dependency.

Jacob

On Mon, Aug 1, 2016 at 10:55 AM, Cyrille DERORY  wrote:

> I modified the file ~/.pybombs/recipes/gr-recipes/python-zmq.lwr below the
> port line:
>
> #
> # This file is part of PyBOMBS
> #
> # PyBOMBS is free software; you can redistribute it and/or modify
> # it under the terms of the GNU General Public License as published by
> # the Free Software Foundation; either version 3, or (at your option)
> # any later version.
> #
> # PyBOMBS is distributed in the hope that it will be useful,
> # but WITHOUT ANY WARRANTY; without even the implied warranty of
> # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> # GNU General Public License for more details.
> #
> # You should have received a copy of the GNU General Public License
> # along with PyBOMBS; see the file COPYING.  If not, write to
> # the Free Software Foundation, Inc., 51 Franklin Street,
> # Boston, MA 02110-1301, USA.
> #
>
> category: baseline
> satisfy:
>   deb: python-zmq
>   rpm: python-zmq
>   port: py27-zmq
>   pacman: python2-pyzmq
>
>
>
>
> But it still not working even after I did a manual install of
> python2-pyzmq package with command line:
> sudo pacman -S python2-pyzmq
> (python2-pyzmq-15.2.0-1 is installed)
> https://www.archlinux.org/packages/community/x86_64/python2-pyzmq/
>
> verbosity mode:
>
>  PyBOMBS.PackageManager - DEBUG - Checking if package python-zmq is
> installed.
> PyBOMBS.PackageManager - DEBUG - Checking if package python-zmq is
> installed.
> Install tree:
> |
> \- gr-gsm
>|
>+- libosmocore
>|  |
>|  \- libtalloc-dev
>|
>+- gr-osmosdr
>|  |
>|  +- gr-iqbal
>|  |  |
>|  |  \- gnuradio
>|  | |
>|  | \- python-zmq
>|  |
>|  \- gnuradio
>| |
>| \- python-zmq
>|
>\- gnuradio
>   |
>   \- python-zmq
> PyBOMBS.PackageManager - DEBUG - Checking if package python-zmq is
> installed.
> PyBOMBS.install_manager - INFO - Installing package: python-zmq
> PyBOMBS.PackageManager - DEBUG - install(python-zmq, static=False)
> PyBOMBS.PackageManager - DEBUG - Using packager pip
> PyBOMBS.PackageManager - DEBUG - Using packager pacman
> PyBOMBS.PackageManager - DEBUG - Using packager pkgconfig
> PyBOMBS.PackageManager - DEBUG - Using packager cmd
> PyBOMBS.PackageManager - DEBUG - Using packager source
> PyBOMBS.Packager.source - WARNING - Cannot find a source URI for package
> python-zmq
> PyBOMBS.install_manager - ERROR - Error installing package python-zmq.
> Aborting.
>
>
> Cyrille
>
>
> 2016-08-01 17:55 GMT+02:00 Andrej Rode :
>
>> Hey Cyrille,
>>
>>
>> On 01/08/16 17:20, Cyrille DERORY wrote:
>> > Thank you for your reply,
>> >
>> > my distro/OS is archlinux and package manager is pacman:
>> > https://wiki.archlinux.org/index.php/pacman
>>
>> Try adding:
>>   pacman: python2-pyzmq
>> in ~/.pybombs/recipes/gr-recipes/python-zmq.lwr below the port line.
>> If you can install gnuradio successfully I'll submit a pull-request
>> against gr-recipes master.
>>
>> Best Regards,
>> Andrej
>>
>> P.S. Don't forget to add the mailing-list in your reply. Your answer
>> might be interesting for other folks.
>>
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] Segmentation Fault from uhd::transport when stopping/starting flowgraph

[Jacob Gilbert]

I observed this on GR 3.7.9.1.

On Fri, Mar 25, 2016 at 10:10 AM, Martin Braun <martin.br...@ettus.com>
wrote:

> Jacob,
>
> This is a gr-uhd issue (not UHD) if it is what I think it is, so the uhd
> version is probably immaterial. Which gnu radio version are you running?
>
> M
> On 25 Mar 2016 07:53, "Jacob Gilbert" <mrjacobagilb...@gmail.com> wrote:
>
>> I have tried it two ways:
>>
>> 1) calling stop() wait() on the top_block
>> 2) having a block return WORK_DONE to the scheduler to stop the flowgraph
>>
>> Both ways result in segfaults. I'll try calling stop() on the USRP block
>> directly. I am currently running the 3.9.2 release but will update when I
>> get a chance.
>>
>> Thanks
>>
>> On Thu, Mar 24, 2016 at 10:34 PM, Martin Braun <martin.br...@ettus.com>
>> wrote:
>>
>>> Oh, I see -- you're calling stop() on the top_block, or the usrp block?
>>> I know we fixed a segfault issue in
>>> 4ae7a6015ba719a4720f61cc6f3857de2ebda89f (the praise goes to Marcus
>>> Müller for the fix), but this is not on maint, only on master. What are
>>> you running?
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 03/24/2016 05:25 PM, Jacob Gilbert wrote:
>>> > Sorry for not being explicit, I am doing this using GR (stock gr-uhd).
>>> >
>>> > Jacob
>>> >
>>> > On Thu, Mar 24, 2016 at 5:22 PM, Martin Braun via USRP-users
>>> > <usrp-us...@lists.ettus.com <mailto:usrp-us...@lists.ettus.com>>
>>> wrote:
>>> >
>>> > Jacob,
>>> >
>>> > are you using GNU Radio or straight UHD? Your email seems to imply
>>> the
>>> > former, but I want to confirm.
>>> >
>>> > Your backtrace looks familiar; in benchmark_rate we used to
>>> sometimes
>>> > run into cases where we'd segfault and then they might look like
>>> this.
>>> > The reason was we were shutting down stuff out of order.
>>> >
>>> > If you have your custom app, make sure the streamer is stopped,
>>> then
>>> > flushed, then destroyed before the multi_usrp object is destroyed.
>>> > If you don't do that, the recv thread might be trying to access
>>> samples
>>> > for which there are no more valid buffers. The converter would be
>>> the
>>> > first to see this => matches your bt.
>>> >
>>> > Cheers,
>>> > Martin
>>> >
>>> >
>>> > On 03/24/2016 06:54 AM, Jacob Gilbert via USRP-users wrote:
>>> > > I have a flowgraph that requires stopping and starting to
>>> reconfigure
>>> > > its output, and have run into two different segfaults
>>> originating from
>>> > > within UHD.
>>> > >
>>> > > Starting and stopping is done based on user input and by either
>>> > issuing
>>> > > the stop() wait() sequence, or by having a block return
>>> "WORK_DONE"
>>> > > (-1). Both have been shown to produce both types of segfault,
>>> however
>>> > > the WORK_DONE method anecdotally appears to be less frequent. The
>>> > errors
>>> > > always occur while waiting for the wait() function to return and
>>> > > occasionally hang for an extremely long time before actually
>>> throwing
>>> > > sigsev.
>>> > >
>>> > > BT's of the segfaults are here:
>>> > >
>>> > > 
>>> > >
>>> > > Program received signal SIGSEGV, Segmentation fault.
>>> > > [Switching to Thread 0x7f8704fe9700 (LWP 103995)]
>>> > > 0x7f87b25589d0 in
>>> > >
>>> >
>>>  uhd::transport::sph::recv_packet_handler::converter_thread_task(unsigned
>>> > > long) () from /usr/local/lib/libuhd.so.003
>>> > > (gdb) i trace
>>> > > No tracepoints.
>>> > > (gdb) bt
>>> > > #0  0x7f87b25589d0 in
>>> > >
>>> >
>>>  uhd::transport::sph::recv_packet_handler::converter_thread_task(unsigned
>>> > > long) () from /usr/local/lib/libuhd.so.003
>>> > > #1  0x7f87b26e8433 in
>>> > task_impl::task_lo

Re: [Discuss-gnuradio] [USRP-users] Segmentation Fault from uhd::transport when stopping/starting flowgraph

[Jacob Gilbert]

I have tried it two ways:

1) calling stop() wait() on the top_block
2) having a block return WORK_DONE to the scheduler to stop the flowgraph

Both ways result in segfaults. I'll try calling stop() on the USRP block
directly. I am currently running the 3.9.2 release but will update when I
get a chance.

Thanks

On Thu, Mar 24, 2016 at 10:34 PM, Martin Braun <martin.br...@ettus.com>
wrote:

> Oh, I see -- you're calling stop() on the top_block, or the usrp block?
> I know we fixed a segfault issue in
> 4ae7a6015ba719a4720f61cc6f3857de2ebda89f (the praise goes to Marcus
> Müller for the fix), but this is not on maint, only on master. What are
> you running?
>
> Cheers,
> Martin
>
> On 03/24/2016 05:25 PM, Jacob Gilbert wrote:
> > Sorry for not being explicit, I am doing this using GR (stock gr-uhd).
> >
> > Jacob
> >
> > On Thu, Mar 24, 2016 at 5:22 PM, Martin Braun via USRP-users
> > <usrp-us...@lists.ettus.com <mailto:usrp-us...@lists.ettus.com>> wrote:
> >
> > Jacob,
> >
> > are you using GNU Radio or straight UHD? Your email seems to imply
> the
> > former, but I want to confirm.
> >
> > Your backtrace looks familiar; in benchmark_rate we used to sometimes
> > run into cases where we'd segfault and then they might look like
> this.
> > The reason was we were shutting down stuff out of order.
> >
> > If you have your custom app, make sure the streamer is stopped, then
> > flushed, then destroyed before the multi_usrp object is destroyed.
> > If you don't do that, the recv thread might be trying to access
> samples
> > for which there are no more valid buffers. The converter would be the
> > first to see this => matches your bt.
> >
> > Cheers,
> > Martin
> >
> >
> > On 03/24/2016 06:54 AM, Jacob Gilbert via USRP-users wrote:
> > > I have a flowgraph that requires stopping and starting to
> reconfigure
> > > its output, and have run into two different segfaults originating
> from
> > > within UHD.
> > >
> > > Starting and stopping is done based on user input and by either
> > issuing
> > > the stop() wait() sequence, or by having a block return "WORK_DONE"
> > > (-1). Both have been shown to produce both types of segfault,
> however
> > > the WORK_DONE method anecdotally appears to be less frequent. The
> > errors
> > > always occur while waiting for the wait() function to return and
> > > occasionally hang for an extremely long time before actually
> throwing
> > > sigsev.
> > >
> > > BT's of the segfaults are here:
> > >
> > > 
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > [Switching to Thread 0x7f8704fe9700 (LWP 103995)]
> > > 0x7f87b25589d0 in
> > >
> >
>  uhd::transport::sph::recv_packet_handler::converter_thread_task(unsigned
> > > long) () from /usr/local/lib/libuhd.so.003
> > > (gdb) i trace
> > > No tracepoints.
> > > (gdb) bt
> > > #0  0x7f87b25589d0 in
> > >
> >
>  uhd::transport::sph::recv_packet_handler::converter_thread_task(unsigned
> > > long) () from /usr/local/lib/libuhd.so.003
> > > #1  0x7f87b26e8433 in
> > task_impl::task_loop(boost::function
> > > const&) ()
> > >from /usr/local/lib/libuhd.so.003
> > > #2  0x7f87be684e7a in ?? () from
> > > /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0
> > > #3  0x7f87d2831182 in start_thread (arg=0x7f8704fe9700) at
> > > pthread_create.c:312
> > > #4  0x7f87d255e47d in clone () at
> > > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> > >
> > > 
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > [Switching to Thread 0x7fce1cff9700 (LWP 112591)]
> > > 0x7fcebb8e0b83 in
> > >
> >
>  
> __convert_sc16_item32_be_1_fc32_1_PRIORITY_SIMD::operator()(uhd::ref_vector > > const*> const&, uhd::ref_vector<void*> const&, unsigned long) ()
> from
> > > /usr/local/lib/libuhd.so.003
> > > (gdb) bt
> > > #0  0x7fcebb8e0b83 in
> > >
> >
>  
> __convert_sc16_item32_be_1_fc32_1_PRIORITY_SIMD::operator()(uhd::ref_vector > > const*> const&am

Re: [Discuss-gnuradio] OOT Module Template Expansion Issues

[Jacob Gilbert]

Just as a little more information, it looks like the top-level gr_modtool
CMake template does attempt to set it's own module directory as the top
priority (
https://github.com/gnuradio/gnuradio/blob/master/gr-utils/python/modtool/gr-newmod/CMakeLists.txt#L35),
however the find_package command (
https://github.com/gnuradio/gnuradio/blob/master/gr-utils/python/modtool/gr-newmod/CMakeLists.txt#L114)
makes the system module path a higher preference.

Re-adding the OOT module directory to the top of CMAKE_MODULE_PATH fixes
this (though it now appears twice in CMAKE_MODULE_PATH) and allows the fix
mentioned above to succeed. Is this an acceptable way of handling things?

Jacob

On Thu, Mar 24, 2016 at 7:00 PM, Jacob Gilbert <mrjacobagilb...@gmail.com>
wrote:

> I agree my current approach of clobbering the generate_helper.py file
> that GrMiscUtils sticks into build/lib and build/include is not a good
> one. I am only using it because right now the `include(GrMiscUtils)` points
> to the module in /lib/cmake/gnuradio/GrMiscUtils.cmake.
> I'd rather it be pointed to the module inside the OOT at
> /cmake/Modules/GrMiscUtils.cmake, where almost everything I
> put above already lives.
>
> If that can work we just have to add the appropriate:
>
> sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python')
> or
> sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../../python')
>
> lines in the GR_EXPAND_X... macros inside the gr_modtool template here:
> https://github.com/gnuradio/gnuradio/blob/master/gr-utils/python/modtool/gr-newmod/cmake/Modules/GrMiscUtils.cmake
> . I just don't understand cmake enough to understand how to get it to use
> the GrMiscUtils inside the OOT module.
>
> Jacob
>
> On Thu, Mar 24, 2016 at 6:48 PM, Martin Braun <martin.br...@ettus.com>
> wrote:
>
>> You can't point to the module inside GNU Radio, because that might not
>> be installed when you're developing a module.
>>
>> If your way works, that's great, but maybe this can be factored out into
>> a single CMake module as not to bloat the individual CMakeLists.txt files.
>>
>> Cheers,
>> Martin
>>
>>
>> On 03/24/2016 05:24 PM, Jacob Gilbert wrote:
>> > Thanks Martin,
>> >
>> > I added something like this to the CMakeLists.txt files in lib and
>> > include/testmod:
>> >
>> > file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/generate_helper.py
>> > "#!${PYTHON_EXECUTABLE}
>> > import sys, os, re
>> > sys.path.append('${GR_RUNTIME_PYTHONPATH}')
>> > sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python')
>> > os.environ['srcdir'] = '${CMAKE_CURRENT_SOURCE_DIR}'
>> > os.chdir('${CMAKE_CURRENT_BINARY_DIR}')
>> > if __name__ == '__main__':
>> >   import build_utils
>> >   root, inp = sys.argv[1:3]
>> >   for sig in sys.argv[3:]:
>> >   name = re.sub ('X+', sig, root)
>> >   d = build_utils.standard_impl_dict2(name, sig, '${component}')
>> >   build_utils.expand_template(d, inp)
>> > ")
>> >
>> > Is that what you mean? Or can I tell CMake to use the module in
>> > tesmod/cmake/Modules/GrPlatform.cmake?
>> >
>> > I'd like to know the recommended way, and we can get this added into the
>> > modtool templates.
>> >
>> > Jacob
>> >
>> > On Thu, Mar 24, 2016 at 6:05 PM, Martin Braun <martin.br...@ettus.com
>> > <mailto:martin.br...@ettus.com>> wrote:
>> >
>> > The short answer is, the templated in-tree stuff has access to some
>> > modules we don't actually export to OOTs. You'll need to copy the
>> > template infrastructure into your OOT.
>> >
>> > Cheers,
>> > Martin
>> >
>> > On 03/24/2016 11:25 AM, Jacob Gilbert wrote:
>> > > I am attempting to add several templatized blocks to an OOT
>> module and
>> > > am having trouble with getting things to build correctly.
>> > >
>> > > After using modtool to add the new block, adding the .t
>> extensions to
>> > > the impl.cc/imp.h/.h <http://impl.cc/imp.h/.h>
>> > <http://impl.cc/imp.h/.h> files, and adding test
>> > > code, I added the following to ../lib/CMakeLists.txt:
>> > >
>> > >
>> > > include(GrMiscUtils)
>> > > GR_EXPAND_X_CC_H(testmod testblock_X_impl  c f i
>> s b)
>> > >
>> > > ...
>> > >
>> > > list(APPEND testmod_sources
>> > >

Re: [Discuss-gnuradio] OOT Module Template Expansion Issues

[Jacob Gilbert]

I agree my current approach of clobbering the generate_helper.py file that
GrMiscUtils sticks into build/lib and build/include is not a good one. I am
only using it because right now the `include(GrMiscUtils)` points to the
module in /lib/cmake/gnuradio/GrMiscUtils.cmake. I'd rather
it be pointed to the module inside the OOT at
/cmake/Modules/GrMiscUtils.cmake,
where almost everything I put above already lives.

If that can work we just have to add the appropriate:

sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python')
or
sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../../python')

lines in the GR_EXPAND_X... macros inside the gr_modtool template here:
https://github.com/gnuradio/gnuradio/blob/master/gr-utils/python/modtool/gr-newmod/cmake/Modules/GrMiscUtils.cmake
. I just don't understand cmake enough to understand how to get it to use
the GrMiscUtils inside the OOT module.

Jacob

On Thu, Mar 24, 2016 at 6:48 PM, Martin Braun <martin.br...@ettus.com>
wrote:

> You can't point to the module inside GNU Radio, because that might not
> be installed when you're developing a module.
>
> If your way works, that's great, but maybe this can be factored out into
> a single CMake module as not to bloat the individual CMakeLists.txt files.
>
> Cheers,
> Martin
>
>
> On 03/24/2016 05:24 PM, Jacob Gilbert wrote:
> > Thanks Martin,
> >
> > I added something like this to the CMakeLists.txt files in lib and
> > include/testmod:
> >
> > file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/generate_helper.py
> > "#!${PYTHON_EXECUTABLE}
> > import sys, os, re
> > sys.path.append('${GR_RUNTIME_PYTHONPATH}')
> > sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python')
> > os.environ['srcdir'] = '${CMAKE_CURRENT_SOURCE_DIR}'
> > os.chdir('${CMAKE_CURRENT_BINARY_DIR}')
> > if __name__ == '__main__':
> >   import build_utils
> >   root, inp = sys.argv[1:3]
> >   for sig in sys.argv[3:]:
> >   name = re.sub ('X+', sig, root)
> >   d = build_utils.standard_impl_dict2(name, sig, '${component}')
> >   build_utils.expand_template(d, inp)
> > ")
> >
> > Is that what you mean? Or can I tell CMake to use the module in
> > tesmod/cmake/Modules/GrPlatform.cmake?
> >
> > I'd like to know the recommended way, and we can get this added into the
> > modtool templates.
> >
> > Jacob
> >
> > On Thu, Mar 24, 2016 at 6:05 PM, Martin Braun <martin.br...@ettus.com
> > <mailto:martin.br...@ettus.com>> wrote:
> >
> > The short answer is, the templated in-tree stuff has access to some
> > modules we don't actually export to OOTs. You'll need to copy the
> > template infrastructure into your OOT.
> >
> > Cheers,
> > Martin
> >
> > On 03/24/2016 11:25 AM, Jacob Gilbert wrote:
> > > I am attempting to add several templatized blocks to an OOT module
> and
> > > am having trouble with getting things to build correctly.
> > >
> > > After using modtool to add the new block, adding the .t extensions
> to
> > > the impl.cc/imp.h/.h <http://impl.cc/imp.h/.h>
> > <http://impl.cc/imp.h/.h> files, and adding test
> > > code, I added the following to ../lib/CMakeLists.txt:
> > >
> > >
> > > include(GrMiscUtils)
> > > GR_EXPAND_X_CC_H(testmod testblock_X_impl  c f i s
> b)
> > >
> > > ...
> > >
> > > list(APPEND testmod_sources
> > > ${generated_sources}
> > > 
> > >
> > >
> > > and the following to ../include/testmod/CMakeLists.txt:
> > >
> > >
> > > include(GrMiscUtils)
> > > GR_EXPAND_X_H(testmod testblock_X  c f i s b)
> > >
> > > add_custom_target(testmod_generated_includes DEPENDS
> > > ${generated_includes}
> > > )
> > >
> > > ...
> > >
> > > install(FILES
> > > ${generated_includes}
> > >
> > > 
> > >
> > >
> > >
> > > These were borrowed from in-tree templates like fir_filter_XXX; I
> was
> > > unable to find an OOT module using templates. I also added
> appropriate
> > > #include, %include, and GR_SWIG_BLOCK_MAGIC2 to
> > swig/testmod_swig.i for
> > > each of the generated blocks. However, when I attempt to build I
> > get the
> > &g

Re: [Discuss-gnuradio] OOT Module Template Expansion Issues

[Jacob Gilbert]

Thanks Martin,

I added something like this to the CMakeLists.txt files in lib and
include/testmod:

file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/generate_helper.py
"#!${PYTHON_EXECUTABLE}
import sys, os, re
sys.path.append('${GR_RUNTIME_PYTHONPATH}')
sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python')
os.environ['srcdir'] = '${CMAKE_CURRENT_SOURCE_DIR}'
os.chdir('${CMAKE_CURRENT_BINARY_DIR}')
if __name__ == '__main__':
  import build_utils
  root, inp = sys.argv[1:3]
  for sig in sys.argv[3:]:
  name = re.sub ('X+', sig, root)
  d = build_utils.standard_impl_dict2(name, sig, '${component}')
  build_utils.expand_template(d, inp)
")

Is that what you mean? Or can I tell CMake to use the module in
tesmod/cmake/Modules/GrPlatform.cmake?

I'd like to know the recommended way, and we can get this added into the
modtool templates.

Jacob

On Thu, Mar 24, 2016 at 6:05 PM, Martin Braun <martin.br...@ettus.com>
wrote:

> The short answer is, the templated in-tree stuff has access to some
> modules we don't actually export to OOTs. You'll need to copy the
> template infrastructure into your OOT.
>
> Cheers,
> Martin
>
> On 03/24/2016 11:25 AM, Jacob Gilbert wrote:
> > I am attempting to add several templatized blocks to an OOT module and
> > am having trouble with getting things to build correctly.
> >
> > After using modtool to add the new block, adding the .t extensions to
> > the impl.cc/imp.h/.h <http://impl.cc/imp.h/.h> files, and adding test
> > code, I added the following to ../lib/CMakeLists.txt:
> >
> >
> > include(GrMiscUtils)
> > GR_EXPAND_X_CC_H(testmod testblock_X_impl  c f i s b)
> >
> > ...
> >
> > list(APPEND testmod_sources
> > ${generated_sources}
> > 
> >
> >
> > and the following to ../include/testmod/CMakeLists.txt:
> >
> >
> > include(GrMiscUtils)
> > GR_EXPAND_X_H(testmod testblock_X  c f i s b)
> >
> > add_custom_target(testmod_generated_includes DEPENDS
> > ${generated_includes}
> > )
> >
> > ...
> >
> > install(FILES
> > ${generated_includes}
> >
> > 
> >
> >
> >
> > These were borrowed from in-tree templates like fir_filter_XXX; I was
> > unable to find an OOT module using templates. I also added appropriate
> > #include, %include, and GR_SWIG_BLOCK_MAGIC2 to swig/testmod_swig.i for
> > each of the generated blocks. However, when I attempt to build I get the
> > following error:
> >
> >   File
> > "/home/jacob/gr-testmod/build/include/testmod/generate_helper.py",
> > line 9, in 
> > import build_utils
> > ImportError: No module named build_utils
> >
> >
> >
> > This obviously does not happen to in-tree modules. I attempted to modify
> > the gr-testmod/cmake/Modules/GrMiscUtils.cmake file where the
> > GR_EXPAND_.X..() macros are defined to explicitly include the
> > appropriate path, however it appears that by default the include
> > statement I am using actually uses the GrMiscUtils.cmake installed with
> > gnuradio (into /usr/local/lib/cmake/gnuradio/ in my case). If I modify
> > the used GR_EXPAND_X... macros and manually add the correct path
> > (sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python') or
> > '../../python' in the case of the include macro), expansion works
> > correctly, however this makes the code very un-portable.
> >
> > Given my elementary understand of CMake, I have no idea what I am doing
> > incorrectly, or what changes if any should be made to modtool, but I was
> > unable to find any other documents on how to go about doing this.
> >
> > Thanks,
> > Jacob
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OOT Module Template Expansion Issues

[Jacob Gilbert]

I am attempting to add several templatized blocks to an OOT module and am
having trouble with getting things to build correctly.

After using modtool to add the new block, adding the .t extensions to the
impl.cc/imp.h/.h files, and adding test code, I added the following to
../lib/CMakeLists.txt:


include(GrMiscUtils)
GR_EXPAND_X_CC_H(testmod testblock_X_impl  c f i s b)

...

list(APPEND testmod_sources
${generated_sources}



and the following to ../include/testmod/CMakeLists.txt:


include(GrMiscUtils)
GR_EXPAND_X_H(testmod testblock_X  c f i s b)

add_custom_target(testmod_generated_includes DEPENDS
${generated_includes}
)

...

install(FILES
${generated_includes}





These were borrowed from in-tree templates like fir_filter_XXX; I was
unable to find an OOT module using templates. I also added appropriate
#include, %include, and GR_SWIG_BLOCK_MAGIC2 to swig/testmod_swig.i for
each of the generated blocks. However, when I attempt to build I get the
following error:

  File "/home/jacob/gr-testmod/build/include/testmod/generate_helper.py",
line 9, in 
import build_utils
ImportError: No module named build_utils



This obviously does not happen to in-tree modules. I attempted to modify
the gr-testmod/cmake/Modules/GrMiscUtils.cmake file where the
GR_EXPAND_.X..() macros are defined to explicitly include the appropriate
path, however it appears that by default the include statement I am using
actually uses the GrMiscUtils.cmake installed with gnuradio (into
/usr/local/lib/cmake/gnuradio/ in my case). If I modify the used
GR_EXPAND_X... macros and manually add the correct path
(sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python') or '../../python'
in the case of the include macro), expansion works correctly, however this
makes the code very un-portable.

Given my elementary understand of CMake, I have no idea what I am doing
incorrectly, or what changes if any should be made to modtool, but I was
unable to find any other documents on how to go about doing this.

Thanks,
Jacob
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] lack of understanding the different formats to store samples

[Jacob Gilbert]

Ralph,

If I understand this, each 8-bit byte of data contains four two-bit IQ
samples, in which case the "Unpack K Bits" block is likely what you are
looking for. It will treat each bit in a byte (from Byte File Source in
this case) as an individual item, which can then be type-converted and
interleaved to give you complex data. There are a couple other tools under
the category of "Byte Operators" that may be helpful.

Jacob

On Fri, Mar 11, 2016 at 2:24 AM, Ralph A. Schmid, dk5ras 
wrote:

> Hi,
>
> Being an RF guy I must admit that I am somehow lost in the different ways
> how samples are stored in files. I stumbled over this question when I
> experimented with https://github.com/osqzss/gps-sdr-sim. It works great
> when
> using 16 bit samples and using a simple two-block grc file, feeding them
> directly from a file source to the UHD sink. However the 1 bit variant
> sounds promising, as the files are much smaller this way and also the
> generation of them runs much faster.
>
> It must only be a matter of finding the right blocks and the right settings
> to convert this, but my google search was highly confusing, most probably
> due to different names for the same thing.
>
> So I do not only ask for how to use "four 1-bit I/Q samples into a single
> byte" (taken from the readme of the gps-sdr-sim), but for a more general
> overview how this stuff is done, to be prepared for other upcoming
> questions
> of this kind :) Up to now I solved those issues by an educated guess or
> even
> by try and error, what is not very satisfying...
>
> Ralph.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PMT Pairs/Dictionaries type checking bug

[Jacob Gilbert]

Fair enough - it's a functional workaround at least. I'm going to submit a
pull request to add a warning to the doxygen about this as it is currently
incorrect.

On Thu, Mar 10, 2016 at 8:14 PM, Martin Braun <martin.br...@ettus.com>
wrote:

> Yeah, we had some discussions about making the dicts more explicit, but
> eventually didn't. So this code is currently all you can do.
>
> Cheers,
> M
>
> On 03/10/2016 06:59 PM, Jacob Gilbert wrote:
> > Looks like this is known to at least some other folks. Here is a fix
> > borrowed from:
> >
> https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/lib/usrp_block_impl.cc#L459
> >
> > void block::msg_handler(pmt::pmt_t msg)
> > {
> >   try {
> >   pmt::pmt_t keys = pmt::dict_keys(msg);
> >   } catch (const pmt::wrong_type ) {
> >   msg = pmt::dict_add(pmt::make_dict(), pmt::car(msg), pmt::cdr(msg));
> >   }
> >
> > <<< rest of message handler here... input msg will be a dictionary >>>
> > }
> >
> >
> > On Thu, Mar 10, 2016 at 9:26 AM, Jacob Gilbert
> > <mrjacobagilb...@gmail.com <mailto:mrjacobagilb...@gmail.com>> wrote:
> >
> > It appears that PMT dictionaries and pairs are treated identically
> > when it comes to using the pmt::is_() checking functions.
> >
> > Example:
> >
> >   pmt::pmt_t test_pair = pmt::cons(pmt::mp("pair"), pmt::mp(1));
> >   pmt::pmt_t test_dict = pmt::dict_add(pmt::make_dict(),
> > pmt::mp("dict"), pmt::mp(1));
> >
> >   if (pmt::is_pair(test_pair)) std::cout << "Pair is a pair" <<
> > std::endl;
> >   if (pmt::is_pair(test_dict)) std::cout << "Dict is a pair" <<
> > std::endl;
> >   if (pmt::is_dict(test_pair)) std::cout << "Pair is a dict" <<
> > std::endl;
> >   if (pmt::is_dict(test_dict)) std::cout << "Dict is a dict" <<
> > std::endl;
> >
> > output is:
> >
> > Pair is a pair
> > Dict is a pair
> > Pair is a dict
> > Dict is a dict
> >
> > Naturally this causes issues if you attempt to use these PMTs (eg:
> > get the keys from a pair). I'm not sure if this is an issue with GNU
> > Radio or with some external PMT handling library, but at a minimum
> > it seems like the doxygen
> > (
> http://gnuradio.org/doc/doxygen/namespacepmt.html#a936ecb38da9a2a1bb107c090e194700f
> )
> >
> > "PMT_API bool pmt::is_pair (const pmt_t )   Return true if obj
> > is a pair, else false."
> >
> > should be updated to reflect this issue for both pmt::is_pair() and
> > pmt::is_dict().
> >
> > Jacob
> >
> >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PMT Pairs/Dictionaries type checking bug

[Jacob Gilbert]

Looks like this is known to at least some other folks. Here is a fix
borrowed from:
https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/lib/usrp_block_impl.cc#L459

void block::msg_handler(pmt::pmt_t msg)
{
  try {
  pmt::pmt_t keys = pmt::dict_keys(msg);
  } catch (const pmt::wrong_type ) {
  msg = pmt::dict_add(pmt::make_dict(), pmt::car(msg), pmt::cdr(msg));
  }

<<< rest of message handler here... input msg will be a dictionary >>>
}


On Thu, Mar 10, 2016 at 9:26 AM, Jacob Gilbert <mrjacobagilb...@gmail.com>
wrote:

> It appears that PMT dictionaries and pairs are treated identically when it
> comes to using the pmt::is_() checking functions.
>
> Example:
>
>   pmt::pmt_t test_pair = pmt::cons(pmt::mp("pair"), pmt::mp(1));
>   pmt::pmt_t test_dict = pmt::dict_add(pmt::make_dict(),
> pmt::mp("dict"), pmt::mp(1));
>
>   if (pmt::is_pair(test_pair)) std::cout << "Pair is a pair" <<
> std::endl;
>   if (pmt::is_pair(test_dict)) std::cout << "Dict is a pair" <<
> std::endl;
>   if (pmt::is_dict(test_pair)) std::cout << "Pair is a dict" <<
> std::endl;
>   if (pmt::is_dict(test_dict)) std::cout << "Dict is a dict" <<
> std::endl;
>
> output is:
>
> Pair is a pair
> Dict is a pair
> Pair is a dict
> Dict is a dict
>
> Naturally this causes issues if you attempt to use these PMTs (eg: get the
> keys from a pair). I'm not sure if this is an issue with GNU Radio or with
> some external PMT handling library, but at a minimum it seems like the
> doxygen (
> http://gnuradio.org/doc/doxygen/namespacepmt.html#a936ecb38da9a2a1bb107c090e194700f
> )
>
> "PMT_API bool pmt::is_pair (const pmt_t )   Return true if obj is a
> pair, else false."
>
> should be updated to reflect this issue for both pmt::is_pair() and
> pmt::is_dict().
>
> Jacob
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] PMT Pairs/Dictionaries type checking bug

[Jacob Gilbert]

It appears that PMT dictionaries and pairs are treated identically when it
comes to using the pmt::is_() checking functions.

Example:

  pmt::pmt_t test_pair = pmt::cons(pmt::mp("pair"), pmt::mp(1));
  pmt::pmt_t test_dict = pmt::dict_add(pmt::make_dict(),
pmt::mp("dict"), pmt::mp(1));

  if (pmt::is_pair(test_pair)) std::cout << "Pair is a pair" <<
std::endl;
  if (pmt::is_pair(test_dict)) std::cout << "Dict is a pair" <<
std::endl;
  if (pmt::is_dict(test_pair)) std::cout << "Pair is a dict" <<
std::endl;
  if (pmt::is_dict(test_dict)) std::cout << "Dict is a dict" <<
std::endl;

output is:

Pair is a pair
Dict is a pair
Pair is a dict
Dict is a dict

Naturally this causes issues if you attempt to use these PMTs (eg: get the
keys from a pair). I'm not sure if this is an issue with GNU Radio or with
some external PMT handling library, but at a minimum it seems like the
doxygen (
http://gnuradio.org/doc/doxygen/namespacepmt.html#a936ecb38da9a2a1bb107c090e194700f
)

"PMT_API bool pmt::is_pair (const pmt_t )   Return true if obj is a
pair, else false."

should be updated to reflect this issue for both pmt::is_pair() and
pmt::is_dict().

Jacob
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Building ControlPort support into OOT module

[Jacob Gilbert]

I'm having some trouble adding ControlPort hooks to an OOT module. Is there
a guide on this I am missing? I followed the ControlPort manual page
including the #ifdef statements, however GR_CTRLPORT is not set and the
controlport code never gets built.

If I force the code to be built, the build fails as none of the controlport
stuff is included. There appears to be some CMake or include statements I
am missing. I tried to modify the top-level/lib/swig cmake files to emulate
what in-tree modules have done but to no avail.

ControlPort and thrift are definitely built into the GR installation and
works just fine. Any pointers are appreciated. GR is release 3.9.2

Thanks, Jacob
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Building ControlPort support into OOT module

[Jacob Gilbert]

Tom -

So as it turned out, I had the rpcbasic_register_set<> value types
mismatched (signed vs unsigned) and that error was hidden within a huge
mess of errors that appeared to be "could not find rpcbasic_register_set"
errors. Sorry for the confusion.

Thank you for the #include. That builds with GR_CTRLPORT set. Are there any
recommendations for what the "suggestion" pmt's should be for string-type
values?

Thanks


On Wed, Feb 10, 2016 at 11:42 AM, Tom Rondeau <t...@trondeau.com> wrote:

> On Wed, Feb 10, 2016 at 11:37 AM, Jacob Gilbert <mrjacobagilb...@gmail.com
> > wrote:
>
>> I'm having some trouble adding ControlPort hooks to an OOT module. Is
>> there a guide on this I am missing? I followed the ControlPort manual page
>> including the #ifdef statements, however GR_CTRLPORT is not set and the
>> controlport code never gets built.
>>
>
>
> For this, use:
>
> #include 
>
> That file defines GR_CTRLPORT (if it's been enabled in GNU Radio).
>
>
>
>> If I force the code to be built, the build fails as none of the
>> controlport stuff is included. There appears to be some CMake or include
>> statements I am missing. I tried to modify the top-level/lib/swig cmake
>> files to emulate what in-tree modules have done but to no avail.
>>
>> ControlPort and thrift are definitely built into the GR installation and
>> works just fine. Any pointers are appreciated. GR is release 3.9.2
>>
>> Thanks, Jacob
>>
>
>
> Can you post the error you're seeing? All ControlPort functionality is
> built into gnuradio-runtime, which you should be linking against by default
> in any gr_modtool project. But yeah, the actual error will help narrow this
> down to what the real problem is.
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] e100 OpenBTS Linux Kernel missing

[Jacob Gilbert]

oops, wasn't sure since the page in question is hosted on the gnuradio site but 
that makes sense.

Thanks for looking into this, will you post here when it is updated?

Jacob

- Original Message -
From: Philip Balister phi...@balister.org
Date: Tuesday, November 15, 2011 6:58 pm
Subject: Re: [Discuss-gnuradio] e100 OpenBTS Linux Kernel missing
To: Jacob Gilbert jgilb...@jhu.edu
Cc: discuss-gnuradio@gnu.org


 On 11/15/2011 06:54 PM, Jacob Gilbert wrote:
  I was attempting to download the uImage linux kernel from the 
 following website and got a dropbox 404 page.
  
  
  
  Is there a mirror or am I using an outdated e-100 OpenBTS page?
 
 usrp-users is a better place to ask this ...
 
 That said, Tom Tsou and I are looking at doing an update ASAP.
 
 Philip
 
  
  Thanks,
  
  Jacob
  
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  
  

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] e100 OpenBTS Linux Kernel missing

[Jacob Gilbert]

I was attempting to download the uImage linux kernel from the following website 
and got a dropbox 404 page.

http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSE100

Is there a mirror or am I using an outdated e-100 OpenBTS page?

Thanks,

Jacob

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio