Re: [GNU Radio 3.8] Error loading modules on E310

[Ivan Iudice]

Hi all,
gnuradio-companion calls the interpreter
#!/usr/bin/env python
Thus, the first python in the path is Python 2.7.
Is gnuradio using python 2.7?

Ivan

> Il giorno 20 feb 2020, alle ore 20:51, Philip Balister  
> ha scritto:
> 
> Try:
> 
> $ less `which gnuradio-companion`
> 
> And see which python interpreter gnuradio-companion uses. Hopefully
> someone from Ettus support knows for sure and can help with the OOT.
> 
> Your OOT looks like it is using python3
> 
> Philip
> 
>> On 2/20/20 2:41 PM, Müller, Marcus (CEL) wrote:
>> Hi Ivan,
>> 
>> GNU Radio 3.7: Python2
>> GNU Radio 3.8: Py2 XOR Py3
>> GNU Radio >3.8: Py3
>>> On Thu, 2020-02-20 at 19:35 +0100, Ivan Iudice wrote:
>>> Your help is very welcome!
>>> I’m sorry for the stupid question, however, how can I know which version of 
>>> python is used by gnuradio?
>>> 
>>> Ivan
>>> 
 Il giorno 20 feb 2020, alle ore 19:22, Philip Balister 
  ha scritto:
 
 On 2/20/20 11:25 AM, Ivan Iudice wrote:
> Hi Philip!
> I only have site-package folder in both python2.7 and python3.5 lib 
> folders, no dist-package.
> The problem is that in python3.5/site-package there is not numpy, it’s 
> only in python2.7/site-package.
> Is it not installed for python3? How can I install it in both the sdk 
> sysroot and in the target?
 
 hmm, is gnuradio on the e310 using python 2 or 3? Maybe mixed python
 versions.
 
 Sorry for the short answer, trying to help, but I don't use the Ettus
 builds for gnuradio.
 
 Philip
 
> Thanks so much.
> 
> Ivan
> 
>>> Il giorno 20 feb 2020, alle ore 17:05, Philip Balister 
>>>  ha scritto:
>> 
>> I had some dist-packages versus site-packages with some versions of
>> gnuradio. See if both exist. I'm betting numpy is in site-packages.
>> 
>> Philip
>> 
>>> On 2/19/20 4:46 PM, Ivan Iudice wrote:
>>> I’m curious to know if there is somebody in the list developing for 
>>> E310 using current SDK.
>>> This is a problem that, obviously, everybody wants execute custom 
>>> module could incur.
>>> Any ideas?
>>> 
>>> Ivan
>>> 
> Il giorno 17 feb 2020, alle ore 17:31, kron...@tiscali.it ha scritto:
 
 
 Dear all,
 finally I cross-compiled my OOT module for running on USRP E310.
 Based on the instructions at 
 "https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source";,
  I set the environment variable PYTHONPATH a little bit different, to 
 point the path of the installed OOT module:
 
 export PYTHONPATH=$LOCALPREFIX/lib/python3.5/dist-packages:$PYTHONPATH
 
 Such a way, on the target I can load my custom module in python.
 root@ni-e31x-316AFEA:~# python3 -c "import custom_mod"
 I created a flowgraph that use my OOT module, and I discovered in the 
 newer file system for E310 python3 has not all of the needed libraries.
 root@ni-e31x-316AFEA:~# ./top_block.py
 Traceback (most recent call last):
 File "./top_block.py", line 12, in 
  from gnuradio import blocks
 File 
 "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/blocks/__init__.py",
  line 38, in 
  from .stream_to_vector_decimator import *
 File 
 "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/blocks/stream_to_vector_decimator.py",
  line 23, in 
  from gnuradio import gr
 File 
 "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/__init__.py",
  line 46, in 
  from .top_block import *
 File 
 "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/top_block.py",
  line 32, in 
  from .hier_block2 import hier_block2
 File 
 "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/hier_block2.py",
  line 26, in 
  import pmt
 File 
 "/home/root/localinstall/usr/lib/python3.5/dist-packages/pmt/__init__.py",
  line 61, in 
  from .pmt_to_python import pmt_to_python as to_python
 File 
 "/home/root/localinstall/usr/lib/python3.5/dist-packages/pmt/pmt_to_python.py",
  line 23, in 
  import numpy
 ImportError: No module named 'numpy'
 How could I solve the problem?
 I'm so close to run my OOT modules on the target...
 Thanks so much.
 Ivan
 
 
 
 Con Tiscali Mobile Smart 30 4G hai minuti illimitati, 100 SMS e 30 
 Giga in 4G a soli 8,99€ al mese. http://tisca.li/smart30
 
>>> 
>>> 

Re: Python module: object as a reference (just as "Block ID" in "Function Probe" block)

[Cyrille Morin]

Hi Luke,

I've had this issue before.

The problem is that the Function Probe block is not actually a block, 
it's just a way to write code directly into the top_block python file, 
and do the top_block object is the one calling the block you want, which 
is not an issue since, it knows them, it created them.


Now, whatever block you create doesn't have reference to the other 
blocks, and I could not find a way to give it to them directly, so what 
I found is to give the top_block object to yours, and also the name of 
the block(s) you want, and call them with getattr(top_block_object, 
wanted_block_name).whatever_function() . It needs to be the name used 
for the exact block you want, not the type, you can find it in the id 
field in the parameters, or by reading the top_block file.


The other issue is the fact that, with an embedded block, when you save 
it, GRC creates an instance of the object automatically with the default 
parameters, possibly to find out its signature and be able to display it 
properly. But, at that point, the top block object doesn't exist, so the 
execution will stop and GRC will complain.


If you work with an OOT python block, you won't have this issue, but if 
you really want to stick with embedded, I've done that too:


If the constructor is not the function that gets the top_block as input, 
but another function (not called in the init phase), you can have it be 
called by a function probe (the frequency doesn't need to be high) and 
put "self" as argument. Then you can use it to call whatever in your 
function, or even store it in your block object for later use.


This is really hacky, and there may be a better way to do it but I 
couldn't find at the time, and it works without issue.


Tell me if this was not clear, or if you need example code.

Cyrille

Le 21/02/2020 à 00:24, Lukas Haase a écrit :

Hi,

I am using the "Embedded Python Block" to create a simple controller that 
controls my USRP Source/Sink blocks.
These blocks support a message interface but unfortunately this is pretty 
useless except for the simplest applications (I need to control advanced tuning 
with timed commands, GPIO ports etc).

Hence I need to call the methods of these objects directly but I need a 
reference to them inside my custom block.
Within my python block I cannot reference the parent blocks, hence I need to 
pass a reference to these two objects via the constructor (and parameters).
Basically I want to do the same as parameter "Block ID" from the block "Function 
Probe" does.

What is the best way to implement this?

Thanks,
Luke






PS: Example:

class blk(gr.sync_block):  # other base classes are basic_block, decim_block, 
interp_block
 def __init__(self, sample_rate=1.0, usrp_source_block=''):  # only default 
arguments here
 """arguments to this function show up as parameters in GRC"""
 gr.sync_block.__init__(
 self,
 name='Controller',   # will show up in GRC
 in_sig=[np.float32],
 out_sig=[np.float32]
 )
 # if an attribute with the same name as a parameter is found,
 # a callback is registered (properties work, too).
 self.sample_rate = sample_rate
self.usrp_source_block = usrp_source_block

# here I want to execute for example
self.usrp_source_block.set_gain(5.0)

When I then create an USRP Sink object with ID uhd_usrp_sink_0 and enter as 
parameter I get the error:

Param - Usrp Source Block(usrp_source_block):
Value "uhd_usrp_sink_0" cannot be evaluated:
name 'uhd_usrp_sink_0' is not defined

Re: Python module: object as a reference (just as "Block ID" in "Function Probe" block)

[CEL]

Hi Lukas,

On Fri, 2020-02-21 at 00:24 +0100, Lukas Haase wrote:
> These blocks support a message interface but unfortunately this is pretty 
> useless except for the simplest applications (I need to control advanced 
> tuning with timed commands, GPIO ports etc).

That's very much supported, far as I know: you send PMT dictionaries
containing a time spec and the setting you want to do. 
That is, if your USRP supports that, you can do it with GNU Radio.

> Hence I need to call the methods of these objects directly but I need a 
> reference to them inside my custom block.

From a software architecture point of view: no, you don't :) 

> Within my python block I cannot reference the parent blocks, hence I need to 
> pass a reference to these two objects via the constructor (and parameters).
> Basically I want to do the same as parameter "Block ID" from the block 
> "Function Probe" does.
> 
> What is the best way to implement this?

Not implementing this at all, since the resulting flow graph makes
assumptions on the order of initialization, and other things that you
really shouldn't depend on, since they can't be assumed.

> Param - Usrp Source Block(usrp_source_block):
>   Value "uhd_usrp_sink_0" cannot be evaluated:
>   name 'uhd_usrp_sink_0' is not defined

Exactly this! 

So, really, if this is about setting the gain as a timed command, then
follow [1] and use a "time" field.

For GPIO, you're right, there's no message handler for that. But as far
as I'm concerned, you *really* don't want to set GPIO things without a
message handler, as this could lead to undefined device states if
another thread (here, the one running the work() of your
uhd_usrp_source block, or a message handler) is manipulating device
state. Generally, on classic gen<=3 USRPs, the command queue is head-
blocked – and thus, you'll need to send in all commands in order.
Therefore, a call to get something (e.g. the state of GPIOs) after a
timed command call might then block, and things get logically
complicated pretty quickly.

Now, how to solve your issue?

Honestly: At this point, I'd recommend just patching the
uhd_block_impl.cc, probably. Look for `REGISTER_CMD_HANLDER` and
imitate that line.

Best regards,
Marcus


[1] http://marcus.hostalia.de/gnuradio-3.8.1.0-rc1/page_uhd.html



smime.p7s
Description: S/MIME cryptographic signature

Re: [GNU Radio 3.8] Error loading modules on E310

[Philip Balister]

On 2/21/20 3:21 AM, Ivan Iudice wrote:
> Hi all,
> gnuradio-companion calls the interpreter
> #!/usr/bin/env python
> Thus, the first python in the path is Python 2.7.
> Is gnuradio using python 2.7?

Yes, try convincing cmake to use python2 for your OOT.

Philip

> 
> Ivan
> 
>> Il giorno 20 feb 2020, alle ore 20:51, Philip Balister  
>> ha scritto:
>>
>> Try:
>>
>> $ less `which gnuradio-companion`
>>
>> And see which python interpreter gnuradio-companion uses. Hopefully
>> someone from Ettus support knows for sure and can help with the OOT.
>>
>> Your OOT looks like it is using python3
>>
>> Philip
>>
>>> On 2/20/20 2:41 PM, Müller, Marcus (CEL) wrote:
>>> Hi Ivan,
>>>
>>> GNU Radio 3.7: Python2
>>> GNU Radio 3.8: Py2 XOR Py3
>>> GNU Radio >3.8: Py3
 On Thu, 2020-02-20 at 19:35 +0100, Ivan Iudice wrote:
 Your help is very welcome!
 I’m sorry for the stupid question, however, how can I know which version 
 of python is used by gnuradio?

 Ivan

> Il giorno 20 feb 2020, alle ore 19:22, Philip Balister 
>  ha scritto:
>
> On 2/20/20 11:25 AM, Ivan Iudice wrote:
>> Hi Philip!
>> I only have site-package folder in both python2.7 and python3.5 lib 
>> folders, no dist-package.
>> The problem is that in python3.5/site-package there is not numpy, it’s 
>> only in python2.7/site-package.
>> Is it not installed for python3? How can I install it in both the sdk 
>> sysroot and in the target?
>
> hmm, is gnuradio on the e310 using python 2 or 3? Maybe mixed python
> versions.
>
> Sorry for the short answer, trying to help, but I don't use the Ettus
> builds for gnuradio.
>
> Philip
>
>> Thanks so much.
>>
>> Ivan
>>
 Il giorno 20 feb 2020, alle ore 17:05, Philip Balister 
  ha scritto:
>>>
>>> I had some dist-packages versus site-packages with some versions of
>>> gnuradio. See if both exist. I'm betting numpy is in site-packages.
>>>
>>> Philip
>>>
 On 2/19/20 4:46 PM, Ivan Iudice wrote:
 I’m curious to know if there is somebody in the list developing for 
 E310 using current SDK.
 This is a problem that, obviously, everybody wants execute custom 
 module could incur.
 Any ideas?

 Ivan

>> Il giorno 17 feb 2020, alle ore 17:31, kron...@tiscali.it ha scritto:
>
> 
> Dear all,
> finally I cross-compiled my OOT module for running on USRP E310.
> Based on the instructions at 
> "https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source";,
>  I set the environment variable PYTHONPATH a little bit different, to 
> point the path of the installed OOT module:
>
> export PYTHONPATH=$LOCALPREFIX/lib/python3.5/dist-packages:$PYTHONPATH
>
> Such a way, on the target I can load my custom module in python.
> root@ni-e31x-316AFEA:~# python3 -c "import custom_mod"
> I created a flowgraph that use my OOT module, and I discovered in the 
> newer file system for E310 python3 has not all of the needed 
> libraries.
> root@ni-e31x-316AFEA:~# ./top_block.py
> Traceback (most recent call last):
> File "./top_block.py", line 12, in 
>  from gnuradio import blocks
> File 
> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/blocks/__init__.py",
>  line 38, in 
>  from .stream_to_vector_decimator import *
> File 
> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/blocks/stream_to_vector_decimator.py",
>  line 23, in 
>  from gnuradio import gr
> File 
> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/__init__.py",
>  line 46, in 
>  from .top_block import *
> File 
> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/top_block.py",
>  line 32, in 
>  from .hier_block2 import hier_block2
> File 
> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/hier_block2.py",
>  line 26, in 
>  import pmt
> File 
> "/home/root/localinstall/usr/lib/python3.5/dist-packages/pmt/__init__.py",
>  line 61, in 
>  from .pmt_to_python import pmt_to_python as to_python
> File 
> "/home/root/localinstall/usr/lib/python3.5/dist-packages/pmt/pmt_to_python.py",
>  line 23, in 
>  import numpy
> ImportError: No module named 'numpy'
> How could I solve the problem?
> I'm so close to run my OOT modules on the target...
> Thanks so much.
> Ivan
>
>
>
> Con Tiscali Mobile Smart 30 4G hai minuti illimitati, 100 SMS e 30 
> Giga 

Re: Python module: object as a reference (just as "Block ID" in "Function Probe" block)

[Lukas Haase]

Hi Marcus,

> Gesendet: Freitag, 21. Februar 2020 um 03:44 Uhr
> Von: "Müller, Marcus (CEL)" 
> An: "lukasha...@gmx.at" , "discuss-gnuradio@gnu.org" 
> 
> Betreff: Re: Python module: object as a reference (just as "Block ID" in 
> "Function Probe" block)
>
> Hi Lukas,
> 
> On Fri, 2020-02-21 at 00:24 +0100, Lukas Haase wrote:
> > These blocks support a message interface but unfortunately this is pretty 
> > useless except for the simplest applications (I need to control advanced 
> > tuning with timed commands, GPIO ports etc).
> 
> That's very much supported, far as I know: you send PMT dictionaries
> containing a time spec and the setting you want to do. 
> That is, if your USRP supports that, you can do it with GNU Radio.

I think that's another discussion, but, I don't think so.
I looked into the code of gr-uhd already it it's really just for "toy examples".

Example 1:

tune_request: Like a uhd::tune_request_t, but always uses POLICY_AUTO. This is 
a pair, composed of (target_frequency, lo_offset)

(see https://www.gnuradio.org/doc/doxygen/page_uhd.html)

Example 2: How do select integer-n mode?

tune_req_rx.args=uhd.device_addr(','.join(["mode_n=integer", 
"int_n_step=1000e3",]))
tune_req_tx.args=uhd.device_addr(','.join(["mode_n=integer", 
"int_n_step=1000e3",]))

If this message interface should be useful at all, it needs to support all the 
functions that the API provides. Otherwise I start writing a nice architecture 
using messages and shortly after I realize I need to through everything away 
because the interface just doesn't expose the functions needed.

> > Hence I need to call the methods of these objects directly but I need a 
> > reference to them inside my custom block.
> 
> From a software architecture point of view: no, you don't :) 

Hmm, I can see why, yes.

> > Within my python block I cannot reference the parent blocks, hence I need 
> > to pass a reference to these two objects via the constructor (and 
> > parameters).
> > Basically I want to do the same as parameter "Block ID" from the block 
> > "Function Probe" does.
> > 
> > What is the best way to implement this?
> 
> Not implementing this at all, since the resulting flow graph makes
> assumptions on the order of initialization, and other things that you
> really shouldn't depend on, since they can't be assumed.

Well, at least I could check within my functions if the objects are properly 
initialized (as I expected).

> > Param - Usrp Source Block(usrp_source_block):
> > Value "uhd_usrp_sink_0" cannot be evaluated:
> > name 'uhd_usrp_sink_0' is not defined
> 
> Exactly this! 
> 
> So, really, if this is about setting the gain as a timed command, then
> follow [1] and use a "time" field.

No, see above. Either I don't see it or this interface has not been made for 
any more advanced application.

> For GPIO, you're right, there's no message handler for that. But as far
> as I'm concerned, you *really* don't want to set GPIO things without a
> message handler, as this could lead to undefined device states if
> another thread (here, the one running the work() of your
> uhd_usrp_source block, or a message handler) is manipulating device
> state. Generally, on classic gen<=3 USRPs, the command queue is head-
> blocked – and thus, you'll need to send in all commands in order.
> Therefore, a call to get something (e.g. the state of GPIOs) after a
> timed command call might then block, and things get logically
> complicated pretty quickly.

I am not sure if I understand exactly. So GPIO should only be used with 
messages or NOT with messages?
If with messages, why is there no way to send GPIO messages to the USRP blocks?

Let me briefly tell why these GPIOs are important: In order for them to make 
sense, I need to synchronize them precisely to my signal flow. For example, I 
want to switch something exactly at sample n=1. Otherwise I could just use 
a random I/O board connected in parallel with the USRP. In fact, I just need to 
execute something like

self.uhd_usrp_x310.set_gpio_attr("FP0", "OUT", 1, 1 << 4)

as a timed command. Just as returning the LO.

> Now, how to solve your issue?
> 
> Honestly: At this point, I'd recommend just patching the
> uhd_block_impl.cc, probably. Look for `REGISTER_CMD_HANLDER` and
> imitate that line.

If this is really the only way, I teeth-gnashingly proceed with that.
This unfortunately results in an unmaintable code base that I wanted to avoid 
at all costs.
I use my project at various different machines, by various people, have the grc 
files in git. OOT modules make things already complicated but patching gnuradio 
or usrp itself is even more painful.

I am wondering if I am the first person in the world needing to access more 
than just basic functionality.
And this is my first project in gnuradio, so I am a beginner.

So either I am doing things wrong (in which case I am happy to discuss the 
right way, based on what I wrote above) or gnuradio/uhd/usrp-x310 is not 
powerful enou

Re: Python module: object as a reference (just as "Block ID" in "Function Probe" block)

[CEL]

Hi Lukas,
On Fri, 2020-02-21 at 16:17 +0100, Lukas Haase wrote:
> 
> Example 2: How do select integer-n mode?
> 
> tune_req_rx.args=uhd.device_addr(','.join(["mode_n=integer", 
> "int_n_step=1000e3",]))
> tune_req_tx.args=uhd.device_addr(','.join(["mode_n=integer", 
> "int_n_step=1000e3",]))
> 
> If this message interface should be useful at all, it needs to support all 
> the functions that the API provides. Otherwise I start writing a nice 
> architecture using messages and shortly after I realize I need to through 
> everything away because the interface just doesn't expose the functions 
> needed.

Well, It's really not that I disagree! But: you do realize this is a
FOSS project mainly at the mercy of volunteers?
Sure, there's a company with interest in gr-uhd, but even they are
resource-limited and can't guess your use case. So, you're doing the
right thing here, discussing your use case and proposing change.

> > So, really, if this is about setting the gain as a timed command, then
> > follow [1] and use a "time" field.
> 
> No, see above. Either I don't see it or this interface has not been made for 
> any more advanced application.

Good thing that you can modify the source code of GNU Radio :)

> I am not sure if I understand exactly. So GPIO should only be used with 
> messages or NOT with messages?

Only through message handlers.

> If with messages, why is there no way to send GPIO messages to the USRP 
> blocks?

Because nobody implemented it! That's why I recommended you do that :)

> Let me briefly tell why these GPIOs are important: In order for them to make 
> sense, I need to synchronize them precisely to my signal flow. For example, I 
> want to switch something exactly at sample n=1.

Ah, that sounds even less like you'd want to call a function on the
block: That'd be totally unrelated to the signal flow, and might come
too early, or too late.

For the USRP sink, the right way to work here would be using a stream
tag (but again, you'd want to add a stream tag handler to the
usrp_sink's work() then); for the USRP source, yeah, send a message
with a timed command, and start the stream with a start time, so that
you know when, relative to the first received sample, things will
happen.

> > Honestly: At this point, I'd recommend just patching the
> > uhd_block_impl.cc, probably. Look for `REGISTER_CMD_HANLDER` and
> > imitate that line.
> 
> If this is really the only way, I teeth-gnashingly proceed with that.

Sorry!

> This unfortunately results in an unmaintable code base that I wanted to avoid 
> at all costs.

?!
I don't see why – upstream that change, it's universally helpful, and
it appears in our releases pretty quickly.

> I am wondering if I am the first person in the world needing to
access more than just basic functionality.

Maybe!

> And this is my first project in gnuradio, so I am a beginner.

I can see how this is a bit bad :(

Let me think about this: Maybe we can circumvent the need for you to
modify GNU Radio.
I have never done so, but in principle, you can register message
handlers not only for yourself (if you're a GNU Radio block), but on
other blocks just as well.

So, we could try to:

1. Write a function that takes the arguments you need to properly call
things on the USRP block from a PMT and a USRP block
(say, gpio_at_time(block_handle, PMT))

2. add a new message port "special", i.e.
block_id->message_port_register_in(pmt::mp("special"));

3. register a new message handler on the USRP block, i.e.

block_handle->set_msg_handler(
  pmt::mp("special"),
  [block_handle](pmt::pmt_t msg)
{ 
  gpio_at_time(block_handle, msg);
}
  );

To explain:
3. generates a lambda that calls your setter function, but GNU Radio
makes sure that the function is only ever called when no other
functions in the GNU Radio block execution is trying to use the USRP.

Now, obviously, that doesn't get rid of the need to pass a block
handle, but it'd solve the threading issue here.

To solve the handle issue:

* Write a hier_block that *contains* the USRP block you want to use –
now you know what the block handle is in your hier block's constructor
* do 1.-3. in there
* use that hier block in your overall flow graph instead of the USRP
block itself.

I hope that sounds less crazy than trying to change the UHD blocks
themselves.

Personally, I'd of course prefer a good upstreamed solution, but I can
see how that might not be feasible at this point.


Best regards,
Marcus


smime.p7s
Description: S/MIME cryptographic signature

GNU Radio Transition from SWIG to pybind11 - looking for community involvement

[Morman, Joshua]

Hi All,


As was discussed on the project call yesterday, we are in the process of 
migrating away from SWIG for binding the C++ API into python.  This brings the 
following advantages:

- One less giant dependency

- Faster/less memory usage during compile

- Less cryptic auto-generated code

- More deliberate binding of the API


There are of course tradeoffs, and one of the downsides of moving away from 
SWIG, is that SWIG mostly automates the step of C++ header to compiled binding 
code conversion.  Both Boost.python and pybind11 require bindings to be written 
manually - it is this workflow where we need to focus effort so creating these 
bindings is as seamless as possible.


What I'm seeking involvement from the community is for is the following:

1) Feedback on the general approach

-  We should be having discussion about larger features such as these using the 
GREP (GNU Radio Enhancement Process) mechanism, which lives in github, for this 
specific feature as GREP0015:

https://github.com/gnuradio/greps/blob/master/grep-0015-remove-swig.md


More updated information about the current approach is proposed in this pull 
request:

https://github.com/gnuradio/greps/pull/24

So, feel free to comment, suggest ideas, concerns directly on the pull request 
(or via the mailing list if you are so inclined)


2) Tools for automating the workflow

- The current approach follows the pyuhd code structure and leverages the block 
header parsing tool developed by Arpit G. as a GSoC project for generating the 
binding code

- Needs further integration into modtool, cmake, whatever other mechanisms make 
for a smooth experience

- Especially needs to be as little overhead as possible for OOT transitions to 
the new mechanism


3) Building out GR module tree and updating OOTs (once key design decisions are 
solidified)

- I have pushed forward with making binding code for some of the larger modules

- Mainly to determine feasibility, and find gotchas - there are definitely 
improvements in compile time and memory utilization

- But it will be important to build out these bindings using the tools 
developed in (2)


The current work effort lives on my fork - pybind11 branch:

https://github.com/mormj/gnuradio/tree/pybind11

And I have tried to track progress, issues and improvement opportunities here:



https://github.com/mormj/gnuradio/projects/1


If you are interested in getting involved in this effort, please email me back 
here, or on slack @mormj


Thanks!

Josh

Re: [GNU Radio 3.8] Error loading modules on E310

[Ivan Iudice]

How can I force canale to use python 2.7?
I tried configuring as in:
https://pastebin.com/EZfNkcGy
Cmake said that 3.5 is required, but finished configuring; anyway I compiled 
and installed, but nothing changed.

Ivan

> Il giorno 21 feb 2020, alle ore 16:22, Philip Balister  
> ha scritto:
> 
> On 2/21/20 3:21 AM, Ivan Iudice wrote:
>> Hi all,
>> gnuradio-companion calls the interpreter
>> #!/usr/bin/env python
>> Thus, the first python in the path is Python 2.7.
>> Is gnuradio using python 2.7?
> 
> Yes, try convincing cmake to use python2 for your OOT.
> 
> Philip
> 
>> 
>> Ivan
>> 
 Il giorno 20 feb 2020, alle ore 20:51, Philip Balister 
  ha scritto:
>>> 
>>> Try:
>>> 
>>> $ less `which gnuradio-companion`
>>> 
>>> And see which python interpreter gnuradio-companion uses. Hopefully
>>> someone from Ettus support knows for sure and can help with the OOT.
>>> 
>>> Your OOT looks like it is using python3
>>> 
>>> Philip
>>> 
 On 2/20/20 2:41 PM, Müller, Marcus (CEL) wrote:
 Hi Ivan,
 
 GNU Radio 3.7: Python2
 GNU Radio 3.8: Py2 XOR Py3
 GNU Radio >3.8: Py3
> On Thu, 2020-02-20 at 19:35 +0100, Ivan Iudice wrote:
> Your help is very welcome!
> I’m sorry for the stupid question, however, how can I know which version 
> of python is used by gnuradio?
> 
> Ivan
> 
>> Il giorno 20 feb 2020, alle ore 19:22, Philip Balister 
>>  ha scritto:
>> 
>> On 2/20/20 11:25 AM, Ivan Iudice wrote:
>>> Hi Philip!
>>> I only have site-package folder in both python2.7 and python3.5 lib 
>>> folders, no dist-package.
>>> The problem is that in python3.5/site-package there is not numpy, it’s 
>>> only in python2.7/site-package.
>>> Is it not installed for python3? How can I install it in both the sdk 
>>> sysroot and in the target?
>> 
>> hmm, is gnuradio on the e310 using python 2 or 3? Maybe mixed python
>> versions.
>> 
>> Sorry for the short answer, trying to help, but I don't use the Ettus
>> builds for gnuradio.
>> 
>> Philip
>> 
>>> Thanks so much.
>>> 
>>> Ivan
>>> 
> Il giorno 20 feb 2020, alle ore 17:05, Philip Balister 
>  ha scritto:
 
 I had some dist-packages versus site-packages with some versions of
 gnuradio. See if both exist. I'm betting numpy is in site-packages.
 
 Philip
 
> On 2/19/20 4:46 PM, Ivan Iudice wrote:
> I’m curious to know if there is somebody in the list developing for 
> E310 using current SDK.
> This is a problem that, obviously, everybody wants execute custom 
> module could incur.
> Any ideas?
> 
> Ivan
> 
>>> Il giorno 17 feb 2020, alle ore 17:31, kron...@tiscali.it ha 
>>> scritto:
>> 
>> 
>> Dear all,
>> finally I cross-compiled my OOT module for running on USRP E310.
>> Based on the instructions at 
>> "https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source";,
>>  I set the environment variable PYTHONPATH a little bit different, 
>> to point the path of the installed OOT module:
>> 
>> export 
>> PYTHONPATH=$LOCALPREFIX/lib/python3.5/dist-packages:$PYTHONPATH
>> 
>> Such a way, on the target I can load my custom module in python.
>> root@ni-e31x-316AFEA:~# python3 -c "import custom_mod"
>> I created a flowgraph that use my OOT module, and I discovered in 
>> the newer file system for E310 python3 has not all of the needed 
>> libraries.
>> root@ni-e31x-316AFEA:~# ./top_block.py
>> Traceback (most recent call last):
>> File "./top_block.py", line 12, in 
>> from gnuradio import blocks
>> File 
>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/blocks/__init__.py",
>>  line 38, in 
>> from .stream_to_vector_decimator import *
>> File 
>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/blocks/stream_to_vector_decimator.py",
>>  line 23, in 
>> from gnuradio import gr
>> File 
>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/__init__.py",
>>  line 46, in 
>> from .top_block import *
>> File 
>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/top_block.py",
>>  line 32, in 
>> from .hier_block2 import hier_block2
>> File 
>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/hier_block2.py",
>>  line 26, in 
>> import pmt
>> File 
>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/pmt/__init__.py",
>>  line 61, in 
>> from .pmt_to_python import pmt_to_python as to_p

Re: [GNU Radio 3.8] Error loading modules on E310

[Philip Balister]

What version gnuradio is installed on the E310?

$ gnuradio-config-info -v

There should be a cmake variable to set the python interpreter version.
That might be better than trying to point at libraries in the sdk.

Try -DPYTHON_EXECUTABLE=python (or path to python in the sdk)

Philip

On 2/21/20 11:54 AM, Ivan Iudice wrote:
> How can I force canale to use python 2.7?
> I tried configuring as in:
> https://pastebin.com/EZfNkcGy
> Cmake said that 3.5 is required, but finished configuring; anyway I compiled 
> and installed, but nothing changed.
> 
> Ivan
> 
>> Il giorno 21 feb 2020, alle ore 16:22, Philip Balister  
>> ha scritto:
>>
>> On 2/21/20 3:21 AM, Ivan Iudice wrote:
>>> Hi all,
>>> gnuradio-companion calls the interpreter
>>> #!/usr/bin/env python
>>> Thus, the first python in the path is Python 2.7.
>>> Is gnuradio using python 2.7?
>>
>> Yes, try convincing cmake to use python2 for your OOT.
>>
>> Philip
>>
>>>
>>> Ivan
>>>
> Il giorno 20 feb 2020, alle ore 20:51, Philip Balister 
>  ha scritto:

 Try:

 $ less `which gnuradio-companion`

 And see which python interpreter gnuradio-companion uses. Hopefully
 someone from Ettus support knows for sure and can help with the OOT.

 Your OOT looks like it is using python3

 Philip

> On 2/20/20 2:41 PM, Müller, Marcus (CEL) wrote:
> Hi Ivan,
>
> GNU Radio 3.7: Python2
> GNU Radio 3.8: Py2 XOR Py3
> GNU Radio >3.8: Py3
>> On Thu, 2020-02-20 at 19:35 +0100, Ivan Iudice wrote:
>> Your help is very welcome!
>> I’m sorry for the stupid question, however, how can I know which version 
>> of python is used by gnuradio?
>>
>> Ivan
>>
>>> Il giorno 20 feb 2020, alle ore 19:22, Philip Balister 
>>>  ha scritto:
>>>
>>> On 2/20/20 11:25 AM, Ivan Iudice wrote:
 Hi Philip!
 I only have site-package folder in both python2.7 and python3.5 lib 
 folders, no dist-package.
 The problem is that in python3.5/site-package there is not numpy, it’s 
 only in python2.7/site-package.
 Is it not installed for python3? How can I install it in both the sdk 
 sysroot and in the target?
>>>
>>> hmm, is gnuradio on the e310 using python 2 or 3? Maybe mixed python
>>> versions.
>>>
>>> Sorry for the short answer, trying to help, but I don't use the Ettus
>>> builds for gnuradio.
>>>
>>> Philip
>>>
 Thanks so much.

 Ivan

>> Il giorno 20 feb 2020, alle ore 17:05, Philip Balister 
>>  ha scritto:
>
> I had some dist-packages versus site-packages with some versions of
> gnuradio. See if both exist. I'm betting numpy is in site-packages.
>
> Philip
>
>> On 2/19/20 4:46 PM, Ivan Iudice wrote:
>> I’m curious to know if there is somebody in the list developing for 
>> E310 using current SDK.
>> This is a problem that, obviously, everybody wants execute custom 
>> module could incur.
>> Any ideas?
>>
>> Ivan
>>
 Il giorno 17 feb 2020, alle ore 17:31, kron...@tiscali.it ha 
 scritto:
>>>
>>> 
>>> Dear all,
>>> finally I cross-compiled my OOT module for running on USRP E310.
>>> Based on the instructions at 
>>> "https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source";,
>>>  I set the environment variable PYTHONPATH a little bit different, 
>>> to point the path of the installed OOT module:
>>>
>>> export 
>>> PYTHONPATH=$LOCALPREFIX/lib/python3.5/dist-packages:$PYTHONPATH
>>>
>>> Such a way, on the target I can load my custom module in python.
>>> root@ni-e31x-316AFEA:~# python3 -c "import custom_mod"
>>> I created a flowgraph that use my OOT module, and I discovered in 
>>> the newer file system for E310 python3 has not all of the needed 
>>> libraries.
>>> root@ni-e31x-316AFEA:~# ./top_block.py
>>> Traceback (most recent call last):
>>> File "./top_block.py", line 12, in 
>>> from gnuradio import blocks
>>> File 
>>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/blocks/__init__.py",
>>>  line 38, in 
>>> from .stream_to_vector_decimator import *
>>> File 
>>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/blocks/stream_to_vector_decimator.py",
>>>  line 23, in 
>>> from gnuradio import gr
>>> File 
>>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/__init__.py",
>>>  line 46, in 
>>> from .top_block import *
>>> File 
>>> "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/t

Re: [GNU Radio 3.8] Error loading modules on E310

[Ivan Iudice]

The version compiled and installed on the E310 is 3.8.0.0.
As I stated in my last mail, I tried to compile my OOT module forcing cmake to 
use python 2.7 (see https://pastebin.com/EZfNkcGy), but it did not solve the 
problem.
An other question, why the same version of gnuradio (3.8.0.0) I compiled and 
installed on my host machine uses python 3, and on the E310 uses python 2?

Ivan

> Il giorno 21 feb 2020, alle ore 19:25, Philip Balister  
> ha scritto:
> 
> What version gnuradio is installed on the E310?
> 
> $ gnuradio-config-info -v
> 
> There should be a cmake variable to set the python interpreter version.
> That might be better than trying to point at libraries in the sdk.
> 
> Try -DPYTHON_EXECUTABLE=python (or path to python in the sdk)
> 
> Philip
> 
>> On 2/21/20 11:54 AM, Ivan Iudice wrote:
>> How can I force canale to use python 2.7?
>> I tried configuring as in:
>> https://pastebin.com/EZfNkcGy
>> Cmake said that 3.5 is required, but finished configuring; anyway I compiled 
>> and installed, but nothing changed.
>> 
>> Ivan
>> 
 Il giorno 21 feb 2020, alle ore 16:22, Philip Balister 
  ha scritto:
>>> 
>>> On 2/21/20 3:21 AM, Ivan Iudice wrote:
 Hi all,
 gnuradio-companion calls the interpreter
 #!/usr/bin/env python
 Thus, the first python in the path is Python 2.7.
 Is gnuradio using python 2.7?
>>> 
>>> Yes, try convincing cmake to use python2 for your OOT.
>>> 
>>> Philip
>>> 
 
 Ivan
 
>> Il giorno 20 feb 2020, alle ore 20:51, Philip Balister 
>>  ha scritto:
> 
> Try:
> 
> $ less `which gnuradio-companion`
> 
> And see which python interpreter gnuradio-companion uses. Hopefully
> someone from Ettus support knows for sure and can help with the OOT.
> 
> Your OOT looks like it is using python3
> 
> Philip
> 
>> On 2/20/20 2:41 PM, Müller, Marcus (CEL) wrote:
>> Hi Ivan,
>> 
>> GNU Radio 3.7: Python2
>> GNU Radio 3.8: Py2 XOR Py3
>> GNU Radio >3.8: Py3
>>> On Thu, 2020-02-20 at 19:35 +0100, Ivan Iudice wrote:
>>> Your help is very welcome!
>>> I’m sorry for the stupid question, however, how can I know which 
>>> version of python is used by gnuradio?
>>> 
>>> Ivan
>>> 
 Il giorno 20 feb 2020, alle ore 19:22, Philip Balister 
  ha scritto:
 
 On 2/20/20 11:25 AM, Ivan Iudice wrote:
> Hi Philip!
> I only have site-package folder in both python2.7 and python3.5 lib 
> folders, no dist-package.
> The problem is that in python3.5/site-package there is not numpy, 
> it’s only in python2.7/site-package.
> Is it not installed for python3? How can I install it in both the sdk 
> sysroot and in the target?
 
 hmm, is gnuradio on the e310 using python 2 or 3? Maybe mixed python
 versions.
 
 Sorry for the short answer, trying to help, but I don't use the Ettus
 builds for gnuradio.
 
 Philip
 
> Thanks so much.
> 
> Ivan
> 
>>> Il giorno 20 feb 2020, alle ore 17:05, Philip Balister 
>>>  ha scritto:
>> 
>> I had some dist-packages versus site-packages with some versions of
>> gnuradio. See if both exist. I'm betting numpy is in site-packages.
>> 
>> Philip
>> 
>>> On 2/19/20 4:46 PM, Ivan Iudice wrote:
>>> I’m curious to know if there is somebody in the list developing for 
>>> E310 using current SDK.
>>> This is a problem that, obviously, everybody wants execute custom 
>>> module could incur.
>>> Any ideas?
>>> 
>>> Ivan
>>> 
> Il giorno 17 feb 2020, alle ore 17:31, kron...@tiscali.it ha 
> scritto:
 
 
 Dear all,
 finally I cross-compiled my OOT module for running on USRP E310.
 Based on the instructions at 
 "https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source";,
  I set the environment variable PYTHONPATH a little bit different, 
 to point the path of the installed OOT module:
 
 export 
 PYTHONPATH=$LOCALPREFIX/lib/python3.5/dist-packages:$PYTHONPATH
 
 Such a way, on the target I can load my custom module in python.
 root@ni-e31x-316AFEA:~# python3 -c "import custom_mod"
 I created a flowgraph that use my OOT module, and I discovered in 
 the newer file system for E310 python3 has not all of the needed 
 libraries.
 root@ni-e31x-316AFEA:~# ./top_block.py
 Traceback (most recent call last):
 File "./top_block.py", line 12, in 
 from gnuradio import blocks
 File 
 "/

gnuradio 3.8 errors with gr_modtool

[Laura Arjona]

Hi community,
I encountered 2 problems while creating a new OOT module with GNURadio 3.8,
(never encountered that problem before with older gnuradio versions).

I did debugging, but I have no idea what is causing this problem. Thanks in
advance for your help :)

I have this configuration

$ python3 --version
Python 3.6.9
$gnuradio-config-info --version
3.8.0.0


*Error 1 with newmod*
$ gr_modtool newmod test_block
Creating out-of-tree module in ./gr-test_block...
Traceback (most recent call last):
  File "/usr/bin/gr_modtool", line 30, in 
cli()
  File "/usr/lib/python3/dist-packages/click/core.py", line 722, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/gnuradio/modtool/cli/base.py", line
153, in wrapper
return func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/gnuradio/modtool/cli/newmod.py",
line 64, in cli
run(self)
  File "/usr/lib/python3/dist-packages/gnuradio/modtool/cli/base.py", line
172, in run
module.run()
  File "/usr/lib/python3/dist-packages/gnuradio/modtool/core/newmod.py",
line 91, in run
s = filetext.read()
  File "/usr/lib/python3.6/codecs.py", line 321, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe8 in position 5:
invalid continuation byte



*Error 2:  with add (the files .h in the /include directore are not being
generated)*
/gr-test_block$ gr_modtool add -t general -l cpp block1
GNU Radio module name identified: test_block
Language: C++
Block/code identifier: block1
/bin/sh: 1: git: not found
Please specify the copyright holder: me
Enter valid argument list, including default arguments:
input1
Add Python QA code? [Y/n] n
Add C++ QA code? [Y/n] n
Adding file 'lib/block1_impl.h'...
Adding file 'lib/block1_impl.cc'...
Adding file 'include/test_block/block1.h'...
Traceback (most recent call last):
  File "/usr/bin/gr_modtool", line 30, in 
cli()
  File "/usr/lib/python3/dist-packages/click/core.py", line 722, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/gnuradio/modtool/cli/base.py", line
153, in wrapper
return func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/gnuradio/modtool/cli/add.py", line
81, in cli
run(self)
  File "/usr/lib/python3/dist-packages/gnuradio/modtool/cli/base.py", line
172, in run
module.run()
  File "/usr/lib/python3/dist-packages/gnuradio/modtool/core/add.py", line
141, in run
self._run_lib()
  File "/usr/lib/python3/dist-packages/gnuradio/modtool/core/add.py", line
195, in _run_lib
self._write_tpl('block_def_h',self.info['includedir'], fname_h)
  File "/usr/lib/python3/dist-packages/gnuradio/modtool/core/add.py", line
124, in _write_tpl
with open(path_to_file, 'w') as f:
FileNotFoundError: [Errno 2] No such file or directory:
'include/test_block/block1.h'

-- 
*Laura Arjona *
Washington Research Foundation Innovation Postdoctoral Fellow in
Neuroengineering

*Paul G. Allen School of Computer Science & Engineering*
185 E Stevens Way NE
University of Washington
Seattle, WA 98195-2350

Re: gnuradio 3.8 errors with gr_modtool

[Marcus Müller]

Hi Laura,

On Fri, 2020-02-21 at 10:58 -0800, Laura Arjona wrote:
> /bin/sh: 1: git: not found

could you install git and try again (and, please, report the result)?

Best regards,
Marcus

GNU Radio Viterbi Implementation

[Moses Browne Mwakyanjala]

Hello everyone,
I have a couple of questions on GNU Radio implementation of the Butterfly
macros. I'm somehow familiar with doing butterfly on paper (the trellis)
but could someone explain to me how this macro works? I also don't
understand how the list of butterflies for a specific code (for example the
CCSDS CC(K= 7, R = 1/2) butterflies generated by the program below the
butterfly macro) are generated (in particular, how to derive the partab
lookup).

Regards,

#define BUTTERFLY(i, sym) \

{ \

int m0, m1;   \

  \

/* ACS for 0 branch */\

m0 = state[i].metric + mets[sym];  /* 2*i */  \

m1 = state[i + 32].metric + mets[3 ^ sym]; /* 2*i + 64 */ \

if (m0 > m1) {\

next[2 * i].metric = m0;  \

next[2 * i].path = state[i].path << 1;\

} else {  \

next[2 * i].metric = m1;  \

next[2 * i].path = (state[i + 32].path << 1) | 1; \

} \

/* ACS for 1 branch */\

m0 = state[i].metric + mets[3 ^ sym];  /* 2*i + 1 */  \

m1 = state[i + 32].metric + mets[sym]; /* 2*i + 65 */ \

if (m0 > m1) {\

next[2 * i + 1].metric = m0;  \

next[2 * i + 1].path = state[i].path << 1;\

} else {  \

next[2 * i + 1].metric = m1;  \

next[2 * i + 1].path = (state[i + 32].path << 1) | 1; \

} \

}


*/* Generate the inline BUTTERFLY macro calls for viterbi.c */*

*/* The two generator polynomials for the NASA Standard K=7 code */  *

*#include *

*#define POLYA   0x4f*

*#define POLYB   0x6d  *

*unsigned char Partab[] = {*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 0, 1, 1, 0, 1, 0, 0, 1,*

* 1, 0, 0, 1, 0, 1, 1, 0,*

*};*



*int main(int argc, char *argv[])  *

*{  *

* int e,i;*

* int nNonInv = 1;*

* for(i=0;i<32;i++){  *

* if(nNonInv) {*

* e = Partab[2*i & POLYA] << 1;  *

* e |= Partab[2*i & POLYB];  *

* }*

* else {*

* // CCSDS Poly V27POLYB, -V27POLYA*

* e = Partab[2*i & POLYA] << 1;  *

* e |= 1^Partab[2*i & POLYB];  *

* }*

* printf("BUTTERFLY(%d,%d); ",i,e);*

* if (i % 4 ==3) {*

* printf("\n");*

* }  *

* }  *

* return 0;*

*}  *

Re: [GNU Radio 3.8] Error loading modules on E310

[CEL]

On Fri, 2020-02-21 at 19:44 +0100, Ivan Iudice wrote:
> 
> An other question, why the same version of gnuradio (3.8.0.0) I compiled and 
> installed on my host machine uses python 3, and on the E310 uses python 2?
> 

Because those are built in different environments.


smime.p7s
Description: S/MIME cryptographic signature

Re: GRC 3.8 Output language Py2 or Py3 (Windows)

[CEL]

Hi Geof,

this is just to let you know how much I appreciate your work:

Thank you!

Best regards,
Marcus

On Thu, 2020-02-20 at 17:14 -0500, Geof Nieboer wrote:
> Jerom,
> 
> Confirming what Marus and the others have said, the current installers use 
> py2.7 and only py2.7.  
> 
> It is indeed a major effort to move to py3 (because compilers), and once it's 
> done, it'll be done forever, I can't maintain 2 versions.  So since py2.7 was 
> the legacy standard, I'm planning on one more GR 3.8 build before converting 
> the installers to py3.  
> 
> Py3 once the old code is ripped out will actually be much easier to maintain, 
> but for now, you are stuck.  However, at some point in the 
> future-at-a-date-I-won't-commit-to-because-life, GR3.8+py3 will be available 
> on Windows in a handy-dandy installer.
> 
> Geof
> 
> On Thu, Feb 20, 2020 at 11:55 AM Michael Dickens  
> wrote:
> > If you install from an EXE, then you'll get whatever it was built for (Py27 
> > or Py3). If there's any way to build from source then you can select the 
> > Python version directly. I don't run Windows, nor do I build for it; 
> > hopefully someone is providing different Windows installer for GR38 with 
> > variants for Py27 and Py3 ... - MLD
> > 
> > On Thu, Feb 20, 2020 at 10:08 AM Jerom Maas - LR  
> > wrote:
> > > Hello Michael, thanks for the quick response! 
> > > 
> > > I've just reinstalled GRC, but I've not seen a single option about Py2 or 
> > > Py3. Maybe it's because I use the .exe installer, that it automatically 
> > > chooses Py2 then? As said before, I don't even have Py2 installed on my 
> > > pc. Should I give it a go using Powershell, or try another method?
> > > 
> > > 
> > > 
> > > Jerom
> > > 
> > > Van: Michael Dickens 
> > > Verzonden: donderdag 20 februari 2020 15:50:43
> > > Aan: Jerom Maas - LR
> > > CC: discuss-gnuradio@gnu.org
> > > Onderwerp: Re: GRC 3.8 Output language Py2 or Py3 (Windows)
> > >  
> > > Hi Jerom - I believe GRC outputs Py script based on how GR is installed. 
> > > Since GR38 can be installed using Py27 or Py3, if it's installed using 
> > > Py27 then GRC will output for Py27. If installed for Py3 then it'll 
> > > output for Py3. Pretty sure this is correct. Hence, I'd advise you to 
> > > check how GR is installed in the first place & if for Py27 then see about 
> > > getting it installed for Py3. Hope this is useful! - MLD
> > > 
> > > On Thu, Feb 20, 2020 at 9:06 AM Jerom Maas - LR  
> > > wrote:
> > > > Hello all,
> > > > 
> > > > 
> > > > 
> > > > after installing GRC 3.8, I find that the .py files that are created 
> > > > from grc are python 2, instead of python 3. 
> > > > 
> > > > I use Py3 and not Py2, so that's a problem.
> > > > 
> > > > How do I change the output language of GRC? If I use the 'option block' 
> > > >  I can only choose 'Python'  or ' C++' , but I can't specify the 
> > > > version of Python. I am using Windows.
> > > > 
> > > > 
> > > > 
> > > > Thanks for your help,
> > > > 
> > > > 
> > > > 
> > > > Jerom Maas
> > > > 
> > > > 
> > > > 
> > > > PS I am not so familiar with C, so if the solution is to alter a bit in 
> > > > Cmake or something, can you specifically name the file that needs to be 
> > > > changed? That would be very helpful!
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > -- 
> > > Michael Dickens
> > > Ettus Research Technical Support
> > > Email: supp...@ettus.com
> > > Web: https://ettus.com/
> > 
> > 


smime.p7s
Description: S/MIME cryptographic signature

Re: [GNU Radio 3.8] Error loading modules on E310

[Ivan Iudice]

Now, do you suggest to build and install gnuradio on my host machine forcing 
use of python 2.7 to have aligned versions?
After done, should I re-create my OOT module, and build it, to work fine?
Thank you.

Ivan

> Il giorno 21 feb 2020, alle ore 20:28, Müller, Marcus (CEL)  
> ha scritto:
> 
> On Fri, 2020-02-21 at 19:44 +0100, Ivan Iudice wrote:
>> 
>> An other question, why the same version of gnuradio (3.8.0.0) I compiled and 
>> installed on my host machine uses python 3, and on the E310 uses python 2?
>> 
> 
> Because those are built in different environments.

Re: gnuradio 3.8 errors with gr_modtool

[Maitland Bottoms]

On Fri, 21 Feb 2020 10:58:18 -0800
Laura Arjona  wrote:

> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe8 in position
> 5: invalid continuation byte

The problem comes from Python byte-compiled files used as templates.

Perhaps the template processor is choking on a .pyc file?

The solution is to remove all .pyc files found under
/usr/share/gnuradio/modtool/gr-newmod
(or whatever the correct path is for the modtool template directory
in your installation.)

If you have files like
.../gnuradio/modtool/gr-newmod/python/build_utils_codes.pyc
.../gnuradio/modtool/gr-newmod/python/build_utils.pyc
.../gnuradio/modtool/gr-newmod/python/__init__.pyc

then this is likely the trouble.

In Debian, this bug is #946120
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946120

It has been fixed in Debian's gnuradio 3.8 packages, so I am curious
about how you might have ended up with this trouble.

Hope that helps,
-Maitland