On 04/20/2012 03:45 PM, Vladimir Dergachev wrote:
---------- Forwarded message ----------
Date: Fri, 20 Apr 2012 09:44:34 -0700
From: Nickolas Fotopoulos <fo...@caltech.edu>
To: Vladimir Dergachev <volo...@caltech.edu>
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
I actually worked out a different solution, involving reflexive FIFOs
seems to work.
On Fri, Apr 20, 2012 at 09:37, Vladimir Dergachev
<volo...@caltech.edu> wrote:
In case you are interested..
---------- Forwarded message ----------
Date: Fri, 20 Apr 2012 12:26:08 -0400
From: Marcus D. Leech <mle...@ripnet.com>
To: "Discuss-gnuradio@gnu.org" <Discuss-gnuradio@gnu.org>
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
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
