I'd recommend leaving the filenames as is. The call to the mboard sensor will cause delays and doesn't reflect the time that the samples actually were acquired. Instead change to using a File Meta Sync which will store the timestamp tags produced by the USRP and gr-uhd. These contain the USRP's internal time which eliminates most sources of error in the time stamps. Setting the USRP's internal time is covered in the manual and a few times on the list. If you have any trouble with that please let us know.
Regards, Derek On Tue, Aug 16, 2016 at 1:02 PM, Michael Giallorenzo <[email protected]> wrote: > Marcus, > > Thanks for getting back to me so quickly. > > I'm currently using an Ettus X310 with a UBX-160 daughterboard, and the > output of uhd_usrp_probe is as follows: > > linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-156-g2d68f228 > > Thanks again, > > Mike G > > > On Tue, Aug 16, 2016 at 12:11 PM Marcus Müller <[email protected]> > wrote: > >> 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 >> [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> _______________________________________________ >> 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 > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
