I've found what appears to be a bug with the Audio Source block when using
dual outputs.
This can be replicated very simply by attaching a dual output Audio Source
block to a Wav File Sink, it always results in the following error:
ValueError: port number 1 exceeds max of 0
The only solution I've
Hi Marcus,
Thank you for your advice, it is really helpful!!
I successfully made Vflicker.v as a source block in GNU Radio, and it passed
the python QA code with the help of *head* block you suggested.
I actually tried two different ways to build the Vflicker.v source block.
Surprisingly, from
Oh, I nearly forgot you asked for documentation:
https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html#a7f58745d1374b30a7b866406dc97850f
Best regards,
Marcus
On Fri, 2019-05-24 at 15:53 +0200, Sebastian Sahlin wrote:
> Okay, this appears to work:
>
> def start(self):
> threading.Thread(tar
The start() function is something every block is free to override, and
is meant to allow any GNU Radio block to do internal setup just before
the flow graph starts to run.
Its return value is true for "hey, I'm ready" and false for "no, sorry,
something went wrong, the flow graph incorporating me
Okay, this appears to work:
def start(self):
threading.Thread(target=self.send_message('Hello World')).start()
return true
However I am unsure why the return value is necessary (figured it out
through an error message). Is there somewhere in the documentation you can
point me to find more info ab
Hi Marcus,
Aha! I saw hints of this in the documentation but couldn't fully connect
the dots.
Would this be the start() function of top_block, or the block in question?
How would the syntax look like then?
Regards
Den tors 23 maj 2019 kl 18:32 skrev Müller, Marcus (CEL) :
> Hi Sebastian,
>
> c
You can also program a flowgraph in c++ but it's not so simple.
On Fri, May 24, 2019, 14:19 Michael Dickens
wrote:
> Hi Hans - GR Companion generates a Python script that you can run directly
> from the commandline. You can set the name in the config box (upper left)
> in the GRC flowgraph windo
Hi Hans - GR Companion generates a Python script that you can run directly from
the commandline. You can set the name in the config box (upper left) in the GRC
flowgraph window. Guessing this is what you were looking for; if not, keep
asking! - MLD
On Fri, May 24, 2019, at 6:48 AM, Hans Kursche
Hi,
may be my question is too obvious or simple, but I couldn't find
anything in the tutorials.
Given that I have a running flowgraph in companion w/ some real HW
frontend and something like tcp-sink or numerical sink at the end. Now
all creation and testing is finished and in the future I j
I found this script usefull, to convert xml to yaml files.
https://gist.github.com/haakov/4228ff6a14486641add538483093e86b
Am 23.05.19 um 22:01 schrieb Michael Dickens:
Check out < https://github.com/igorauad/gr-osmosdr/tree/gr3.8 > and <
https://github.com/mvaenskae/gr-osmosdr/tree/gr3.8 >.
Hi Bowen,
yeah! Community bonding :) And progress!!
So, the trick with GNU Radio is that you can think of blocks being
"called" by the scheduling algorithm. That always happens when there's
new input to process (doesn't apply to sources), and there's enough
output space to write results to, *as l
Nah, I gonna stick to named pipe, as all processing is local to this
computer, as I used sox and UDP because I followed a guide somewhere
and I want to move the resampler inside Gnuradio to clean up the code
On Fri, May 24, 2019 at 5:38 PM Marcus Müller wrote:
>
> Hum, this is a wild guess, but t
Hum, this is a wild guess, but the sox aspect reinforced it:
somewhere, there's a network buffer overflowing. If that interpretation
is right, sox just adds a quickly-absorbing buffering layer to the
processing chain.
In any case, would sound like the pipe approach would be best. Is there
a reaso
13 matches
Mail list logo
