Hi Michael, what USRP are you using, and which version of UHD?
Best regards, Marcus On 16.08.2016 17:41, Michael Giallorenzo wrote: > Hi everyone, > > I'm currently trying to develop a gui for recording selected samples > of data while viewing the spectrum (the user can watch a waterfall > display of the readings being taken on an Ettus x310, and press and > hold a button to record data when the spectrum looks interesting). > > The combination of the burst tagger block and the tagged file sink > block in GRC seem to be the perfect solution to this, but I'm noticing > an error whenever i change the frequency during execution. The > timestamps recorded in the resulting filenames rapidly jump ahead in > time (easily confirmed by comparing the filenames to the output of the > tag debug block or writing the same data to a metadata file and > reading its header). When I'm using my GPSDO as a time source, the > time starts out in sync with GPS but rapidly gets corrupted as i > change the frequency. Likewise when I use relative time, timestamps > start at 0 but increase too quickly. > > As far as I can tell, this is because the tagged file sink block is > not seeing the rx_time tags on the data stream and is instead trying > to calculate the time based on the sample rate, but is confused when > the changing frequency results in extra tags that are effectively > being generated faster than expected. > > I'm fairly new to gnuradio and my background isn't really software but > I've been experimenting with OOT modules and have modified a few built > in blocks to suit my needs before. In "tagged_file_sink_impl.cc" > around line 100, i believe time_tags_outer.size() is returning a value > of 0 and that may be the source of my problems. Perhaps this stems > from my lack of understanding of how the scheduler calls the work > function (ie how is the value of noutput_items determined?), but I'm > not really sure how to modify this or really why this is happening. > > Sorry if my thoughts here are kind of all over the place. Any insight > or reading material that anyone could offer would be greatly appreciated. > > Thanks, > > Mike G > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
