Re: [Discuss-gnuradio] GRC programming problem--anyone with any bright ideas? (fwd)

[Vladimir Dergachev]

---------- Forwarded message ----------
Date: Fri, 20 Apr 2012 09:44:34 -0700
From: Nickolas Fotopoulos <address@hidden>
To: Vladimir Dergachev <address@hidden>
Subject: Re: [Discuss-gnuradio] GRC programming problem--anyone with any bright
    ideas? (fwd)

Vladimir,

I might suggest to Marcus that he try a ramdisk cache such that
many-Hz open() calls are quite cheap. Not a perfect solution, but
might be the quickest to implement. Alternatively, he might defer
file-writing until arbitrarily later, storing a queue of lines to be
written to each file.

Take care,
Nick

On Fri, Apr 20, 2012 at 09:37, Vladimir Dergachev <address@hidden> wrote:
> In case you are interested..
>
> ---------- Forwarded message ----------
> Date: Fri, 20 Apr 2012 12:26:08 -0400
> From: Marcus D. Leech <address@hidden>
> To: "address@hidden" <address@hidden>
> Subject: [Discuss-gnuradio] GRC programming problem--anyone with any bright
>    ideas?
>
> I've been working on a flow-graph for meteor-burst detection on VHF (more
> specifically using the NAVSPASUR "space fence" as a signal
>  source).
>
> Part of the flow-graph involves probes that run at several-Hz rate and
> decide whether to start recording signal-power data, based on
>  triggering criteria.  This works just fine.  The
> trigger-detection/recording function also returns a filename (either
> /dev/null if not
>  triggered, or a dynamically-generated filename otherwise).  The intention
> of this is to provide the filename for a gr_file_sink to use
>  to record downsampled baseband data during triggering.  The problem, of
> course, is that if this variable is handed to gr_file_sink,
>  it'll be re-opening files (either /dev/null or the "real" file) at a
> many-Hz rate, which is not the desired semantic.  So I modified gr_file_sink
>  to check for a *change* in filename in the open() method, and only proceed
> with a re-open if the filename has changed.  This isn't really
>  clean and elegant.
>
> GRC doesn't lend itself particularly well to this type of processing.   I
> suppose I could run the baseband streams into a vector sink, and have my
>  poll function unload those vectors whenever the poll function is called.
>  Any hints on how to do that?
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



--
======================
Nickolas Fotopoulos
Postdoctoral Scholar
LIGO Laboratory, Caltech
Phone: 626-395-8740
Fax: 626-304-9834
======================