We're developing a GNURadio application that requires us to have separate
blocks running simultaneously and passing messages to each other
asynchronously.
We are thinking of using the ZeroMQ blocks that are built into GRC with a
publish/subscribe model. Are there any advantages of disadvantages to
I'm trying to implement a Python block that will take a signal (complex64
array of 1,024 values) and return a float32 array that includes the max,
min, and mean of the norm for the complex values.
So something with an input array of 1,024 complex elements and an output
array of 3 float elements. F
I may have just answered it. I change the sync_block to a basic_block and
it seems to be working.
-Tony
On Tue, Jun 6, 2017 at 11:12 AM, G Reina wrote:
> I'm creating a Python block that calculates a custom FFT. I need to ensure
> that I get at least 1024 data points for every i
I'm creating a Python block that calculates a custom FFT. I need to ensure
that I get at least 1024 data points for every input to the block.
>From my reading, it looks like I should just be able to do this with the
forecast() function in the Python block. So I've done this:
class blk(gr.sync_blo
tream it:
> https://github.com/skoslowski/gnuradio/commits/epy_block_port_map
>
> Sebastian
>
> On Mon, Jun 5, 2017 at 5:37 AM G Reina wrote:
>
>> I see that GRC had an "embedded python" block. I'd like to take a
>> np.complex64 input, process it in Pyt
I see that GRC had an "embedded python" block. I'd like to take a
np.complex64 input, process it in Python, and return a np.float64. When I
try to modify the python code to do this I get the error:
Param - Code(_source_code):
> Can't map dtype('float64') to GRC port type
>
>
Can having a diff
The "selector" module in GRC is listed as "deprecated". Is there a
replacement for it?
I am trying to just get a way for the GUI dropdown box to allow me to
select different constellation objects (BPSK, QPSK, QAM16) for the input to
my graph. The selector works fine for this, but I'm assuming it w
