discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink
Date: Wed, 17 Aug 2016 01:12:58 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

You could try by creating a symbolic link to /dev/null somewhere you can create arbitrary files; eg.

ln -s /dev/null /tmp/nirvana

and use that instead of /dev/null


On 16.08.2016 23:40, Derek Kozel wrote:
Hello Michael,

Unfortunately we've reached past my depth in the file sinks and tags. Hopefully someone with more experience can step in at this point. My guess with the detached headers is that Nate's trick with the filenames and /dev/null fails because there's a suffix being added for the detached header and /dev/null.metadata (or whatever the suffix is) doesn't exist.

Regards,
Derek

On Tue, Aug 16, 2016 at 2:32 PM, Michael Giallorenzo <address@hidden> wrote:
Derek,

Funny you should mention the file meta sink block... originally that was what we had implemented using a copy block to create the push button recording functionality, but that introduced errors in the alignment between headers and the IQ data since the copy block did not play nice with absolute item numbers.

I was hoping that writing to a null file would then produce() as much data and keep the headers and IQ data in sync so I tried using the same file name construction used in Nate's flowgraph with .dat replaced with .cfile
(prefix + datetime.now().strftime("%Y.%m.%d.%H.%M.%S") + ".cfile" if recording_checkbox else "/dev/null"), but I am noticing a few problems again.

If the meta data file sink is set to have a detached header, which would be ideal, I get a runtime error when I try to run the flowgraph (RuntimeError: file_meta_sink: can't open file). 

On the other hand, with the detached header field turned off, the recording process doesn't throw any errors and everything appears to function the way I'd like. However when playing back one of these recorded files using a file meta source, I get the following error:

RuntimeError: pmt::deserialize: malformed input stream, tag value = : 31

Not sure what to make of either of these.

Thanks again,

Mike G


On Tue, Aug 16, 2016 at 8:24 PM Derek Kozel <address@hidden> wrote:
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
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

reply via email to

[Prev in Thread] Current Thread [Next in Thread]