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? >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
