Marcus, Seems like that did the trick! I also ran the command
ln -s /dev/null /tmp/nirvana.hdr (the directory and file names I used for the last argument were different for my system but I modified them here for the sake of consistency) As without that I was getting a very small header file containing the tags that I was not recording in that directory, which kept overwriting itself and was very small/inconsequential, but no point in leaving it there. I'll have to run some tests before I field this system but I think I'm all set and this is definitely progress. Thanks everyone -Mike G On Tue, Aug 16, 2016 at 11:14 PM Marcus Müller <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> >> 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 <[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 > [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
