On Thu, May 12, 2016 at 2:53 PM, Marcus Müller
wrote:
> Hi Johnathan,
>
> blocks can't side effect each other except through really strictly
> controlled, well-defined ways
>
> ... and that was still very clear and dominant to the user under GR 3.4, I
> agree – then we "softened" that concept by
Martin,
I like the first idea. Would it be possible to create a new variable in the
xml file that is assigned numpy.float32 when the user selects the float
option, or is assigned numpy.complex64 when the user selects the complex
option? Another words, I don't want the user to have to select the po
Hi Johnathan,
> blocks can't side effect each other except through really strictly
> controlled, well-defined ways
... and that was still very clear and dominant to the user under GR 3.4,
I agree – then we "softened" that concept by adding stream tags, message
passing, and if you look at things lik
By the way, I can barely decipher your screenshot. I strongly recommend
using the screenshot functionality of your operating system instead of
using a camera to digitize the analog lightwaves that were generated
from a screen that converted the digital picture to light...
that being said, I don't r
On Thu, May 12, 2016 at 9:18 AM, Marcus Müller
wrote:
> Yeah, like the head block, it's a copying operation. But that's
> "relatively cheap".
> I'm not quite sure about the state of this, but at GRCON '14 work was
> started on letting blocks define where their buffers are – maybe, one day,
> as
Hello...
I'm currently (as one month and nice..) too far away my lab and home (approx
6000+ km in ocean).
With this reason, I don't reply for passed messages.. I'm sorry.
FFTW_MALLOC vs. VOLK_MALLOC problem?
In 26 March, i send a message to this list, contains an information for a
buffer overfl
You can either make this a block argument (i.e., you ask the user to
pass in numpy.float32 or whatever), or, to keep consistent with the C++
way of doing things, you can make a block argument called 'sizeof' and
then create a dict that maps sizes to numpy. values, and use that
to set in_sig.
M
On
Yeah, like the head block, it's a copying operation. But that's
"relatively cheap".
I'm not quite sure about the state of this, but at GRCON '14 work was
started on letting blocks define where their buffers are – maybe, one
day, as a side effect, we can actually use the same buffers for in- and
out
If we wanted that behavior, could we do something similar to what gating
blocks do (like the power squelch), where we pass X number of items through
and after that only consume items without ever producing anything. Is there
an efficiency problem with this technique?
On Thu, May 12, 2016 at 6:14 A
On 05/12/2016 08:06 AM, Jason Matusiak wrote:
>> If it's the only .so you need, and you put it in the right place, then
>> that works. Another way is to ssh mount your E310, then run make install
>> DESTDIR=/path/to/sshmount on your build machine (make sure paths match).
>
> Martin, I was misunder
I've seen messages like this pop up when GNURadio isn't installed where
CMake is expecting it to be. For me, this has happened when different
components are installed in different ways, i.e., I installed GNURadio from
your distro repos (apt-get etc.) and tried to build and OOT module from
source (g
Yep, having had a walk over this: if we didn't want to have this
behaviour, we'd need to have some buffer_writer specific done_policy or
so, where we tell the block it should shut down based on whether all or
just any one of its buffer readers signaled WORK_DONE.
We don't have that, so this is the
On Thu, May 12, 2016 at 5:13 AM, Marcus Müller
wrote:
> Yeah, I've been actually scratching my head on whether that is
> intentional or not – if we don't have that behaviour, there's no chance
> that a leaf in a non-path tree-shaped flow graph can stop the flow
> graph, is there?
Definitely in
(And by `glowing` I obviously meant `growing`. No idea what a `glowing`
sponsor list would look like, but it sounds neat.)
Cheers,
Ben
On Thu, May 12, 2016 at 8:07 AM, Ben Hilburn wrote:
> Hi all -
>
> GRCon16 is only four months out, and things are coming together nicely.
> The organizers have
Hi all -
GRCon16 is only four months out, and things are coming together nicely. The
organizers have made a lot of progress in pulling together the conference
plan, and I wanted to share some important updates:
*Hotel*
Firstly, I'm very happy to share that we have negotiated a deal with
the Mille
If it's the only .so you need, and you put it in the right place, then
that works. Another way is to ssh mount your E310, then run make install
DESTDIR=/path/to/sshmount on your build machine (make sure paths match).
Martin, I was misunderstanding some things, but now I think I understand a bit
Yeah, I've been actually scratching my head on whether that is
intentional or not – if we don't have that behaviour, there's no chance
that a leaf in a non-path tree-shaped flow graph can stop the flow
graph, is there?
On 12.05.2016 12:23, Sylvain Munaut wrote:
> Hi,
>
>
>> I thought so, too, at
Hi Muneeba,
please stay on-list with your replies!
So,
On 12.05.2016 12:48, Raja Muneeba wrote:
> Thankyou for your answers. Im trying to solve this. I am now using fft
> Sink at receiver to see the power(db) vs frequency plot. I turn off
> the transmitter and see the power at fft, and consider i
Hi,
> I thought so, too, at first, but then tested:
>
> Null src +-> Head --> Null sink0
> \--> Null sink1
>
>
> stops.
>
> I think this is the "am done" message bubbling up from head to src, then
> src knowing it should be done, then the info "there's no input coming
> anymore"
I thought so, too, at first, but then tested:
Null src +-> Head --> Null sink0
\--> Null sink1
stops.
I think this is the "am done" message bubbling up from head to src, then
src knowing it should be done, then the info "there's no input coming
anymore" bubbling down to sink1.
Hi,
> I don't want the flowgraph to stop. I just want to store a set number but
> leave the flowgraph running.
The head block will only stop the flow graph if there is no other
active sinks that don't have a head block in front of them..
If there is other parts of the flow graph that can still c
I needed that a while back, too. Here is the patch I used:
https://github.com/skoslowski/gnuradio/commit/453a13a6a74cee5c0ca3973d08770940daef87eb
With that applied you can do:
from gnuradio import uhd
uhd.register_msg_handler(uhd.null_msg_handler)
Should disable all output from (gr-)
22 matches
Mail list logo
