discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Disable some paths of the flowgraph without stopp


From: Stefan Oltmanns
Subject: Re: [Discuss-gnuradio] Disable some paths of the flowgraph without stopping (C++)
Date: Mon, 6 Nov 2017 03:51:27 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

Hello,

I'm not using GRC, it's an C++ application with no Python at all. That
is the flowgraph:

I've got one OsmoSource, to that are connected several paths like this:

freq xlating fir filter -> quadrature demod -> fir filter -> custom sink

And one path like:

freq xlating fir filter -> stream to vector -> fft -> complex to mag
squared -> nlog10 -> custom calibration sink

I'm demodulating and decoding several signals at once, one problem is
that the RTL SDR tuner is not very frequency stable, so I've created the
calibration path.
I just need to provide a reference frequency, and the application will
make a FFT of that area and my custom sink will provide an floating
average of the maximum position, the maximum level and the average
level. With that data the application can decide if it has picked up the
reference and calculate the correction factor.

That all works fine, but I would like to disconnect the calibration path
when it's not needed to safe resources. But when the freq xlating fir
filter of the calibration path is not connected to the source I'll get a
segfaut.

Best regards
Stefan



Am 06.11.2017 um 01:24 schrieb Brashendeavours:
> Hello,
> 
> It all depends on your use case and potential for reuse, as well as if you 
> are using Gnuradio Companion.  If you use GRC to layout and generate your 
> flow graphs, they will overwrite any custom code you add to the top_block.py.
> 
> Your understanding of the use of the null sink or zero source is right, if 
> you want to disconnect and manipulate the structure of your flowgraph while 
> it is running.
> Your hier black could also simply disconnect, and instantiate new blocks as 
> required.
> 
> Could you supply a diagram (through GRC/or otherwise) to help explain what 
> you want to achieve?
> 
> Blake
> 
>> On Nov 5, 2017, at 1:35 PM, Stefan Oltmanns <address@hidden> wrote:
>>
>> Hello Blake,
>>
>> can you explain what the advantage of using a hier block is? At the
>> moment I cannot see any advantage if I use this kind of block
>> combination only once.
>>
>> I'm sorry, but I don't understand how a null sink alone helps me. If I
>> disconnect the path I've got an unconnected input, no unconnected output.
>>
>> What I think could work is a real null source (IMHO the null source in
>> GNU Radio is a zero source) that is connected to a null sink, which by
>> itself is pretty useless, but then I could switch the block from the
>> real source to the null source whether it should be en- or disabled.
>>
>> Am I thinking wrong? Any better idea?
>>
>> Best regards
>> Stefan
>>
>>
>>> Am 05.11.2017 um 18:40 schrieb Brashendeavours:
>>> Stefan,
>>>
>>> Consider wrapping the blocks you want to switch in/out in a hier block.
>>> Use the setter functions of the hier block parameters to:
>>> 1. lock the flow graph
>>> 2. swap in/out the null sink(s) [1]
>>> 3. unlock the flowgraph
>>>
>>> [1] https://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1null__sink.html
>>>
>>> Respectfully,
>>> Blake
>>>
>>>
>>>
>>> Sent from my iPhone
>>>> On Nov 4, 2017, at 7:13 PM, Stefan Oltmanns <address@hidden> wrote:
>>>>
>>>> Hello,
>>>>
>>>> I've got a flowgraph with one source that will end in several sinks. Not
>>>> all paths of the flowgraph are needed all the time and I would like to
>>>> enable/disable a path without stopping the flowgraph to reduce processor
>>>> load.
>>>> When I leave a path unconnected by default the application will crash.
>>>> I've seen there is a (deprecated) Valve block implemented in Python, but
>>>> I'm all C++.
>>>>
>>>> Is there a solution in C++?
>>>> If there is not, I could probably write a custom block that could either
>>>> just return 0 from work function or copy all data from input to output,
>>>> but I don't like the idea of copying the data, is there a way to just
>>>> handover the pointer?
>>>>
>>>> Best regards
>>>> Stefan
>>>>
>>>>
>>>
>>
> 




reply via email to

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