Re: [Discuss-gnuradio] File Sink & Buffering

[Tom Rondeau]

On Tue, Jul 19, 2011 at 2:58 PM, Ryan Pape <address@hidden> wrote:

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 1:08 PM, Wolfarth, Ryan <address@hidden> wrote:

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

On Sun, Jul 17, 2011 at 1:03 PM, Ryan Pape <address@hidden> wrote:

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?

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