discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] How to create a python block


From: Dennis Glatting
Subject: Re: [Discuss-gnuradio] How to create a python block
Date: Thu, 17 Mar 2016 18:41:25 -0700

On Thu, 2016-03-17 at 11:41 -0700, Martin Braun wrote:
> Current GRC on master allows you to type Python code directly into
> the
> flow graph to be executed as a block. Simply insert a 'Python block'.
> 

This is a great help. Thank you.




> M
> 
> On 03/16/2016 02:34 PM, Dennis Glatting wrote:
> > 
> > On Wed, 2016-03-16 at 16:58 -0400, James Humphries wrote:
> > > 
> > > Hi Dennis,
> > > 
> > > Have you seen these:
> > > 
> > > https://gnuradio.org/doc/doxygen/page_python_blocks.html
> > > 
> > > and
> > > 
> > > http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutoria
> > > l_GN
> > > U_Radio_in_Python
> > > 
> > > They have some good info on how to setup your Python block.
> > > 
> > This is where I am confused, not being a Python hack. I didn't want
> > to
> > create the graph by connecting things together in a python script,
> > such
> > as:
> > 
> > src = blocks.vector_source_f (src_data)
> > mult = multiply_py_ff (2)
> > snk = blocks.vector_sink_f ()self.tb.connect (src, mult)
> > self.tb.connect (mult, snk)
> > 
> > Rather I wanted the python block to be part of the GUI run graph.
> > Specifically, my graph looks like this:
> > 
> > 
> > Rx -> Demod C++ ------> MITM ---> Mod C++ -> Tx
> > ^       ^               ^  ^        ^        ^
> > > 
> > >       |               |  |        |        |
> > --------|               |  |        |        |
> > Controls                |  |        |        |
> >                         |  |        |        |
> > Fixed extensions--------|  |        |        |
> > Python extensions ---------|        |        |
> >                                     |        |
> > Controls ---------------------------|--------|
> > 
> > My thinking is within the properties field of a block a person
> > could
> > type some python code where the block imports the code and runs it.
> > Sounds like that isn't the workable approach? (The MITM block has
> > canned messages and fixed manipulations based on GUI controls,
> > which is
> > fairly limiting as a penetration test tool.)
> > 
> > When I looked at some examples I saw either C++ blocks or Python
> > blocks
> > but the python code created the whole graph itself.
> > 
> > I think what you are telling me (and looking through the web pages)
> > is
> > I could have an ugly, fixed C++ MITM block /and/ a separate python
> > block (i.e., two MITM blocks) with the python block part of the
> > build,
> > or both could be incorporated into the python block for a better
> > design. Yes?
> > 
> > Sorry, I'm not a python hack so it isn't evident to me.
> > 
> > TIA.
> > 
> > 
> > > 
> > > -Trip
> > > 
> > > On Wed, Mar 16, 2016 at 4:51 PM, Dennis Glatting <address@hidden
> > > om>
> > > wrote:
> > > > 
> > > > This is probably a dumb question but someone has to ask them...
> > > > 
> > > > 
> > > > I have a run graph with c++ blocks: a receiver block, a
> > > > transmitter
> > > > block, and a manipulator block. I want to have the manipulator
> > > > block
> > > > editable from the run graph where the user can insert python
> > > > code.
> > > > Specifically:
> > > > 
> > > > 1) The block has two message ports: an "in" port and an "out"
> > > > port.
> > > > 
> > > > 2) A user can write and type python code into the block to
> > > > manipulate
> > > > the message received on the input port and post the manipulated
> > > > message
> > > > on the output port.
> > > > 
> > > > 3) The python code may have to call other functions, such as
> > > > updating a
> > > > hash code.
> > > > 
> > > > How might I do that? I could do a c++ wrap around exec() but I
> > > > believe
> > > > there has to be an easier way since GNURadio is a combination
> > > > of
> > > > python
> > > > and c++.
> > > > 
> > > > The incoming messages arrive at a low frequency and a low data
> > > > rate
> > > > so
> > > > I'm not really concerned about processing time.
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Discuss-gnuradio mailing list
> > > > address@hidden
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > > > 
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



reply via email to

[Prev in Thread] Current Thread [Next in Thread]