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 <mwg5...@psu.edu > <mailto:mwg5...@psu.edu>> 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 <derek.ko...@ettus.com > <mailto:derek.ko...@ettus.com>> 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 > <mwg5...@psu.edu <mailto:mwg5...@psu.edu>> 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 > <marcus.muel...@ettus.com > <mailto:marcus.muel...@ettus.com>> 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 >> Discuss-gnuradio@gnu.org >> <mailto:Discuss-gnuradio@gnu.org> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> > _______________________________________________ > Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org > <mailto:Discuss-gnuradio@gnu.org> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> > > _______________________________________________ > Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org > <mailto:Discuss-gnuradio@gnu.org> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
