Currently in response to a message in a message queue, I am opening a
file
sink which is connected a bit stream of about 10K/sec (one byte per
bit). I
keep this file sink open until I receive another message in the queue to
stop the capture, at which time I close() it.
Ideally, the capture would start immediately upon the triggering event,
but
there is some latency with the overheard of the message
enqueue/dequeue/file
open which I believe is causing me to miss data. The first bits missing
are
part of frame sync, which is causing me to throw out the rest in some
instances.
Is there a way with the current existing blocks to build a buffer (say
10K -
or about 1 second), such that once I open the sink I am essentially
looking
back in time to capture the bits that happened AFTER my triggering event
but
BEFORE I processed the message from the queue? I know there is a built
in
buffer block, but I would think ideally I want to buffer and then drain
the
buffer as fast as possible (potentially faster than new samples are
incoming?)
Or, would it be best to build a custom file sink block with this
behavior
integrated into it?
Hi Ryan,
What version of GNU Radio are you using? I’m working with the USRP2 to
collect GPS data and I have a similar scheme: I have a cyclic buffer
that
holds data that was recorded just prior to a triggering event. Once a
trigger event is received, incoming data is written to an open file
sink.
Once the trigger is relaxed, the data in the cyclic buffer is written to
the
front of that file. I managed to do this in UHD by modifying
rx_samples_to_file.cpp. That file can be found in uhd/host/examples.
I’m not sure exactly how to answer your question since I don’t know what
equipment you’re using, but hopefully I have pointed you in a helpful
direction.
Take care,
Ryan Wolfarth
I am using the current GIT version. I’m using data collected from a
USRP1
at an earlier time but captured to disk. Incidentally, after further
analyzing the situation, I do not believe the latency in starting my
“save
to disk” operation is the problem. I think it is more esoteric and
probably
unrelated…but it will be something I watch. I will look at the file
you
have referenced and implement something similiar in the event the
problem
persists…it sounds like there is no ready made block to serve as this
buffer, which was my main question.
Thanks for the help
On Tue, Jul 19, 2011 at 2:58 PM, Ryan P. [email protected] wrote:
rx_samples_to_file.cpp. That file can be found in uhd/host/examples.
This sounds like a job for STREAM TAGS! The block that looks for the
triggering events would generate the tag and send it down the flow
graph.
You would have to rewrite the file sink to look for the tags to start
and
stop the writing.
You could also have a block that looks for your triggering event that
just
throws away the samples until the trigger, then sends it down the line
to
the file sink until the end trigger is observed. This is simpler but
less
flexible.
Tom