Derek,
Thanks for responding, that is indeed very close to the functionality I'm
after. However there is one small(?) deviation from what I'm after and that
is that I'm trying to use GPS time stamps with the intent of synchronized
acquisitions between separate X310 units at a later time.
To that end, I changed the filename in the file sink block to:
prefix +
str(self.uhd_usrp_source_0.get_mboard_sensor("gps_time").to_real()) +
".dat" if recording_checkbox else "/dev/null"
And its throwing the error :
"IOError: [Errno 2] No such file or directory:
'/home/acquisitions/temp_1388780308.0.dat'"
Apparent loss of precision on the timestamp from the GPSDO aside, I am
confused as that directory (/home/acquisitions/) does exist and normally
the file would be created and written to (the append file field is still
set to "overwrite" and in this respect the block functions as intended when
the filename is set to datetime.now()...
I realize this changes the nature of my original question, but any further
help would be greatly appreciated!
-Mike G
On Tue, Aug 16, 2016 at 1:49 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
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
