I created an hier block that does exactly that: run it once, reload your blocks, and then use the "QT GUI Record Button" block as a sink in other flowgraphs.
Thank you Derek for sharing Nate's flowgraph - my block had been using a selector block, and created a 0-byte file every time a flowgraph using it was run. Using "if/then" in the file sink like Nate did eliminates that! Best, Michael Morrison On Tue, Aug 16, 2016 at 12:47 PM, Derek Kozel <[email protected]> wrote: > Hello Mike, > > Here is a simple, but clever, flowgraph put together by Nate Temple which > does exactly what you describe. It isn't an answer to the time errors > you've seen, but I hope it is useful anyways. > > Regards, > Derek > > On Tue, Aug 16, 2016 at 9:08 AM, 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 > >
push-to-record.grc
Description: application/gnuradio-grc
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
