discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] time triggered filter


From: Kevin Reid
Subject: Re: [Discuss-gnuradio] time triggered filter
Date: Wed, 6 Apr 2016 20:00:36 -0700

On Apr 6, 2016, at 19:06, Philip Hahn <address@hidden> wrote:

>  Is it possible to start and stop a filter within a flowgraph?
> 
>  I have a complex data file which is 300 seconds in length and I only want to 
> filter a few seconds in the middle of the file. Is it possible to trigger a 
> filter on and off based on time or some other data trigger?

Do you want to output _only_ that filtered section (a), or to pass through the 
other  data unfiltered (b)?


If (a), then:

You can use the 'Head' and 'Skip Head' blocks together to discard specific 
sample counts. However, it would be more efficient to just slice up the data 
file yourself.

For other types of triggering, you will need blocks to do the job. If the 
criterion can be described as signal power or the presence of a specific 
frequency, then you can use one of the various 'Squelch' blocks with 'gate' 
mode enabled.

Otherwise, you'll have to write a custom block for whatever criterion you have 
-- it just needs to discard the unwanted data and pass through the wanted data.


If (b), then:

The expensive-but-accurate way is to create a detector for whatever your 
trigger criterion is, and have it output a stream of 1s or 0s (for present or 
absent) at the sample rate. Then use the basic math blocks to calculate the 
result
   (condition-met * filtered-signal + (1 - condition-met) * unfiltered-signal)


Finally, if you were doing this in real-time (not from a file) and could afford 
some unreliable time delay, you could instead write code to monitor a probe 
block or message output for your trigger condition and toggle the settings of a 
'Copy' (for case (a)) or 'Multiply Matrix' (for case (b)) block. This approach 
is maximally flexible, but is subject to the whims of thread scheduling so is 
less precise.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>




reply via email to

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