Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Derek Kozel]

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 <address@hidden> 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 <address@hidden> 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 list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio