[USRP-users] rx_time for radar application

Aaron Smith aaron.smith22 at gmail.com
Tue Mar 22 14:17:43 EDT 2016


Tom,

Given my location I'll only be able to see the signal that bounces off the ionosphere, I won't get a direct signal from WWV. Since that signal is timed, I'll use my rx_time tag to determine the sample locations of the second markers. This should give me information on the location of the ionosphere. Since WWV has several carrier frequencies between 2.5 and 30 MHz, I'll get several samples of the electron density profile. It sounds like your familiar with the concept! Once I can get accurate timing and ranging from WWV, I'll start working on the transmit side. For now though, I'm only receiving.

Aaron Smith

Sent from my iPhone

> On Mar 22, 2016, at 11:40 AM, Thomas Wagner <twagner at kurma.com> wrote:
> 
> Hi Aaron,
> I am working on a similar timing  problem and need very accurate sample timing between several receivers.  Any information on Rx timing will be helpful.  
> Are you trying to measure the time delay between the direct WWV signal and the ionospheric bounce, or transmit a signal to measure how long it takes to get back?  Do you want the electron density profile?
> 
> Regards,
> Tom
> 
> 
> Tom Wagner
> twagner at kurma.com
> Tom.Wagner at tautechnologies.com
> 310-387-4929 cell
> 
> 
>> On Mar 22, 2016, at 09:46, Aaron Smith via USRP-users <usrp-users at lists.ettus.com> wrote:
>> 
>> Hello,
>> 
>> I was hoping someone with experience could help me with the situation below.
>> 
>> Background:
>> 
>> My research group is trying to use a N210 USRP to sense the altitude of the ionosphere. Originally we were going to transmit our own signals, so to test this, I connected my TX daughterboard directly to my RX daughterboard.
>> 
>> I then used the function set_start_time() on my tx and rx to build up a little test case. I had a vector source -> repeat block -> usrp sink -> usrp source -> fir dec low pass filter -> file sink and this caused a discrepancy in samples of +50 samples (which would translate into kilometers--big deal). I attributed this to buffer loading and several other forms of non-zero lag between blocks. 
>> 
>> To simplify the issue, I'm going to focus on precise receiving. I am going to attempt to capture the WWV atomic clock signal out of Colorado, but I still need to be able to convince myself the the time I think I received the first sample, is actually the time I received my first sample. 
>> 
>> I am going to abandon using the set_start_time() as an absolute and instead hope to use the file meta sink to extract the rx_time tag. To handle clock synchronization, I am using the set_clock_source() and set_time_unknown_pps() functions with a GPS pps signal.
>> 
>> Questions:
>> 
>> Is this as simple as connecting a USRP source block up to a meta file sink block? If I add a block in between the USRP source and the meta file sink (like a decimator), will that impact my rx_time tag? Can I trust the the rx_time tag is the time that the receiver received it's first sample? Would you recommend this approach, or is there a better way?
>> 
>> Thank you for your time,
>> 
>> 
>> 
>> Aaron Smith
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160322/83312daa/attachment-0002.html>


More information about the USRP-users mailing list