On Tue, Jul 19, 2011 at 2:58 PM, Ryan Pape <ryan.p...@gmail.com> 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 <wolfa...@muohio.edu>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 <ryan.p...@gmail.com> 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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
