pothosware / gr-pothos Goto Github PK

The GNU Radio Zero MQ blocks do not seem to be able to be wrapped correctly in Pothos.

This is running on Ubuntu 18.04 with Pothos installed from the PPA (0.6.1) and GNU Radio installed from the package manager (3.7.11) .

From @guruofquality on May 12, 2016 4:19

From @guruofquality on September 7, 2014 20:1

• this will enable all of the toolkits log reporting to work together nicely
• proper log reporting when blocks are instantiated on remote hosts

Copied from original issue: pothosware/gnuradio#1

Copied from original issue: pothosware/gr-runtime#5

Hi I've been looking into the GNU radio block support. specifically with the gr-pothos.
Specifically the Utility Assumptions https://github.com/pothosware/gr-pothos/wiki#utility-assumptions

• There is a library called libgnuradio-foo.so
• Headers are installed to include/gnuradio/foo/*.h
• GRC files are installed to share/gnuradio/grc/blocks/foo_*.xml

When I install a new OOT module for gnu radio, via pybombs or manually, it is placed in appropriate prefix directory. Whether /usr/local/, ~/prefix/, or whatever. Some of the OOT Headers are installed in different Directories.

e.g. gr-ccsds(https://github.com/lofaldli/gr-ccsds)
It has the following

• There is a library called libgnuradio-ccsds.so
• Headers are installed to include/ccsds/*.h (Doesn't match up with Assumptions)
• GRC files are installed to share/gnuradio/grc/blocks/ccsds_ccsds*.xml

I'm not sure if there is a way to specify the header_path manually from the cmake build.
Or to scan additional include paths.

Thanks

From @guruofquality on May 12, 2016 4:21

From @guruofquality on July 3, 2015 7:44

We have registered conversions for several type-to-pmt calls in this commit: pothosware/gnuradio@ceab657

This enables arbitrary types to be entered as a parameter when the input type of the call is pmt. Pothos figures out how to convert the object to pmt using the available registered conversions. Complete this work by handling remaining to-pmt conversions for container types. And provide the reverse from-pmt conversions in case those become useful later.

Copied from original issue: pothosware/gnuradio#12

Copied from original issue: pothosware/gr-runtime#7

Needed for Unpacked to Packed, Packed to Unpacked

if this line is
boost::shared_ptrgr::block d_msg_accept_block;

everything builds w/o error....

It could be useful to place the gr-pothos gnuradio blocks under their own sub-tree in the Block Tree GUI panel. Something along the lines of Liquid DSP blocks that they have their own subtree.
This can be useful in order to facilitate keeping track of where individual blocks come from and which are the native pothos blocks.

EDIT1
this can be achieved if we substitute line 704 in GrPothosUtil.py
categories = [c.replace('[Core]/', '') for c in categories]
with
categories = [c.replace('[Core]/', 'GNURadio/') for c in categories]

We can probably just make a conversion from an array of object to FSM to support the trellis blocks

• Reference: pothosware/PothosCore#173

Currently on master and for GNU Radio 3.8, whenever that comes along, GRC has moved over to using YAML files to describe GNU Radio blocks, and gr_modtool generates these for new OOT modules.

For compatibility with GNU Radio 3.8, GrPothosUtil.py will need to be able to parse these.

Cmake can test for number of possible arguments in a for loop with simple compiler tests https://cmake.org/cmake/help/v3.0/module/CheckCXXSourceCompiles.html -- That way we can avoid skipping blocks that could otherwise be supported just because certain compilers have issues with too many arguments.

This is needed for multiply_matrix_cc/ff.

The generated factory functions will call block->output/input(index)->setAlias(name); We will probably ignore simple names from the XML like in and out or in0 and out0, that would just make the port names lengthier, only aliases that have meaningful values should be used.

• blocking on API addition: pothosware/pothos-library#102

I installed gr-pothos and ran PothosUtil --self-test and got the following error.

Testing /gnuradio/tests/test_copy_stream... FAIL!
 +--------------------------------------------------------------------------------------------------------------------------------------------+
 | Testing /gnuradio/tests/test_copy_stream...                                                                                                |
 | Exception: Pothos::Testing test_simple_blocks.cc:45                                                                                        |
 |   Unexpected error after last checkpoint                                                                                                   |
 |   Proxy Exception Message: Assertion violation: CollectorSink::verifyTestPlan(): Value check for element 0: expected 347596851 -> actual 0 |
 +--------------------------------------------------------------------------------------------------------------------------------------------+

In test_simple_blocks.cc if I comment out testPlan["enableLabels"] = true; I still get the error. Which leads me to think it has something to do with testPlan["enableBuffers"] = true; ???

These same tests pass on my x86-64, so I imagine it has something to do with 32-bit. I don't understand the testing infrastructure, but if you point me in a direction, I can see what I can find.

PothosGui crashes with the following message

Exception: Assertion violation: _readfd != -1 in file "/build/poco-HOje2L/poco-1.7.8.2/Foundation/src/PipeImpl_POSIX.cpp", line 66

the presence of
/usr/local/lib/Pothos/modules0.5/gnuradio/libfosphorSupport.so
seems to be at the source of it, since removing it permits the GUI to start

PS: under Debian stretch with MyriadRF and pothosware-support/framework PPA's enabled for zesty

Now that this is free of the gr-runtime fork, we should be in a good position to package it up on the PPA.

More TBD

• FFT: Window parameter needs std::vector<float>, default value is "window.blackmanharris(1024)"
• Blocks needing boost::shared_ptr as parameter
  • fec_encoder
  • fec_decoder
  • fec_async_encoder
  • fec_async_decoder
  • protocol_formatter_async
  • protocol_parser
  • packet_sink
  • packet_headerparser_b
• Blocks with Rate parameter set to rate (no quotes, not a string)
  • audio_sink
  • audio_source
  • wavfile_sink
  • freq_xlating_fir_filter
  • dvb2_pilot_generator_cc
  • dvbt2_paprtr_cc
  • file_meta_sink
  • tagged_file_sink
  • throttle
  • header_payload_demux
• Blocks with empty vlen parameter
  • and
  • or
  • xor
  • not
• multiply_const: Constant parameter takes in std::vector, populates with single number
• quadrature_demod_cf: gain parameter populated with math using usual GRC variables
• burst_shaper: Window Taps populated with "([])", needs quotes removed to be valid

The bytemask parameter is parsed as a char, rather than an unsigned char. Given this, Pothos complains that 0xFF is outside the parameter's range.

ex complex to float