Hi Marcus, Derek,
Thank you both so much for your feedback and for all of your suggestions on this, I really appreciate it. My apologies for the delayed response -- I have been out of town for several days.
Based on feedback from you all and some experimentation, I came up with a workaround for the problem I was having -- turns out the time precision needed is not as rigorous as I expected, (plus or minus a few seconds is fine), so I am using the Python time module to record the time at which the flowgraph starts to run (using time.time() in top_block.py), set a timer (using time.sleep()) which dictates how long the flowgraph runs, and then I obtain time stamps for each vector by dividing the total time spent observing by the number of vectors obtained, and add this increment to the start time repeatedly until the number of time stamps matches the number of vectors. Kind of a 'rough and ready' solution, but I think it should work for my purposes. The reason I need the time stamps is mainly to sync up the spectrum readings with temperature readings taken by a Raspberry Pi which is running simultaneously, and since the outdoor temperature will be changing on fairly slow time scales (minutes rather than seconds), that means it is ok for the time stamps to be off by as much as a few seconds.
So that's where I am with that! I will be emailing with another, mostly unrelated, question here soon... in the meantime, thank you again for the advice, and hope you have a good afternoon!
Best,
Ellie
On Wed, Jul 10, 2019 at 6:04 PM Marcus D. Leech <patchvonbraun@gmail.com> wrote:
On 07/10/2019 04:19 PM, Ellie White wrote:
> Hi Marcus,
>
> Thanks for getting back to me! I really appreciate your suggestion --
> why didn't I think of that! I have done similar calculations before to
> determine the amount of time from the beginning of a run, but for a
> much less precise application.
>
> This brings me to another question, though -- I notice that when I
> read the metadata header, the time ("Seconds" field) always says zero
> when I get the file from the TCP client flowgraph, but when I save a
> metadata header file on the machine that the Ettus is connected to, it
> gives me some fractional answer (always different, never zero). Not
> sure why that is, or what time standard the UHD is using (this is the
> one I have, by the way:
> https://files.ettus.com/manual/page_usrp1.html)? Maybe the Ettus just
> needs to be connected to an external clock source -- the final system
> will have a 10 MHz clock source connected, but the temporary system
> that is set up now doesn't have an external clock. If you have any
> thoughts on this, I would be interested to hear them.
>
> Thanks again, and have a good afternoon!
Also, other random questions:
What type of USRP (There are a plethora these days!)
What type of computer is direct-connected to the USRP?
Can you share the flow-graph for the computer that is direct-connected
to the USRP?
> Best,
> Ellie
>
>
> On Wed, Jul 10, 2019 at 3:07 PM Marcus D Leech <patchvonbraun@gmail.com> wrote:
>> The thing to note is that the UHD sends a time stamp only on start of streaming and whenever there's an overrun.
>>
>> You can know the time of any given sample by knowing the sample rate and offset from the beginning.
>>
>> In your case you will have to throw in some more factors to account for FFT size and decimation etc.
>>
>> More later when I get to a real computer.
>>
>> Sent from my iPhone
>>
>>> On Jul 10, 2019, at 2:54 PM, Ellie White <elliewhite1420@gmail.com> wrote:
>>>
>>> Hello!
>>>
>>> I am working on a radio astronomy project with the Green Bank
>>> Observatory / NRAO Central Development Lab this summer, utilizing GNU
>>> Radio and an Ettus Research SDR, and I've got a question regarding how
>>> to collect metadata information from a filesink.
>>>
>>> I have attached the flowgraph I am using to this email. The project
>>> requires that I use two computers in tandem for data collection -- one
>>> is connected to the Ettus -- it is the TCP server, and sends an
>>> interleaved data stream to the TCP client flowgraph (attached) on the
>>> machine which will be storing the data. As you can see, I am saving
>>> integrated spectra to a file. My question is simply, how do I retrieve
>>> a time stamp corresponding to each spectra using the metadata time
>>> sink? I have been fiddling with this all afternoon attempting to get
>>> it to work properly, and I have been able to save data to a file, read
>>> out spectra (using attached Python program), and display header
>>> information using the command gr_read_file_metadata in the terminal,
>>> but this is just showing me a timestamp for the beginning of the data
>>> collection run, rather than showing me timestamps for each spectrum
>>> which is saved to file, and I am not sure how to implement this.
>>>
>>> Any advice would be much appreciated! If I can provide any more info
>>> about my system or what steps I have tried, please let me know. Thank
>>> you so much for your time -- have a good afternoon!
>>>
>>> Best,
>>> Ellie
>>> <ettus-filesink.grc>
>>> <dataGraphing.py>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment