Re: [Discuss-gnuradio] ptime get_time(void) precision down to millisec microsec nanosec ?

[Bastien Auneau]

I don't understand why I should do :

> Typically, you call get_time() to get the UTC time
> in seconds, and then set_time_next_pps() to tell the FPGA to sync its
> sample time to the next PPS pulse

why should I use set_time_next_pps() ? Is it needed to init USRP lock to
GPS time ?

My understanding is that USRP is GPS locked because it has GPSDO. then I
use get_time() to ensure that my PC clock will not get delayed by more
than some millisec (+/-) from USRP clock. Taking into account ethernet
delay, and some more internal delay, I was expecting to get some 10 to
20 millisec accuracy. This way I know that I can send all the burst to
USRP with TX_timestamp around 50 millisec in the future.

Without this mechanism, I'm afraid to get the PC clock drifting from
USRP (so GPS) clock, leading to send burst with tx_timestamp in the past

I will then have to use some much bigger margin to send my burst (like
500 millisec) which would add big latency to system

Bastien

On 2011-05-19 16:54, Nick Foster wrote:
> On Thu, 2011-05-19 at 17:07 +0000, Bastien Auneau wrote:
>> Hi
>>
>> I think there is a misunderstanding.
>> I do not want to set the time of the USRP.
>> I want to use the USRP (with GPSDO) as my time reference.
>> This is why I want to query the USRP using the UHD function ptime
>> get_time(void) in
>> /host/lib/usrp/gps_ctrl.cpp @ line 133
>>
>> This function only returns date and time down to seconds, and the
>> toked[] array has a bigger length than what is used :
>> "
>> UHD_ASSERT_THROW(toked.size() == 12); //if it's not we got something
>> weird in there
>>
>> now = ptime( date(
>>   greg_year(boost::lexical_cast<int>(toked[9].substr(4, 2)) + 2000),
>> //just trust me on this one
>>   greg_month(boost::lexical_cast<int>(toked[9].substr(2, 2))),
>>   greg_day(boost::lexical_cast<int>(toked[9].substr(0, 2)))
>>                        ),
>>   hours(  boost::lexical_cast<int>(toked[1].substr(0, 2)))
>>   + minutes(boost::lexical_cast<int>(toked[1].substr(2, 2)))
>>   + seconds(boost::lexical_cast<int>(toked[1].substr(4, 2)))
>> );
>> "
>>
>> So I would like to know the format of the string returned by the
>> safe_gps_read(); function,
>> "
>> reply = safe_gps_read();
> 
> OK, so 4 things:
> 
> 1. Querying the GPS time through the device is going to net you accuracy
> in the 10s of milliseconds, maybe worse. Asking for more precision in
> the GPRMC sentence is meaningless, since the query has to go through
> both the Ethernet transport and the serial port on the N210 on its way
> to you. 
> 
> 2. The GPSDO PPS output is used in the N210 to synchronize the sample
> time across multiple devices. The PPS edge is the ONLY output of the
> GPSDO which is guaranteed to be synchronized, and its synchronization is
> good to (typical) 50ns. That output goes straight into the FPGA to
> provide a sync pulse. Typically, you call get_time() to get the UTC time
> in seconds, and then set_time_next_pps() to tell the FPGA to sync its
> sample time to the next PPS pulse. Then you know the absolute time, and
> you can calculate the absolute time of any given sample from the N210
> based on the absolute time and the sample count.
> 
> 3. The GPRMC sentence provides for decimal time down to the millisecond;
> however, the Jackson Labs Firefly device (like most GPS devices) issues
> sentences on the rising edge of PPS, and so the fractional seconds
> component is always zero.
> 
> 4. The toked vector gives you the GPRMC sentence components in order,
> separated by comma or period.
> 
> --n
> 
>> "
>>
>> or better the description of the toked[] array after it get through
>> "
>> tok.assign(reply);
>> toked.assign(tok.begin(), tok.end());
>> "
>>
>> Bastien
>>
>> On 2011-05-19 14:46, Josh Blum wrote:
>>>
>>>> Is it possible to extract from the reply the milli ? micro ? and nano
>>>> seconds ? For example using toked[2-8] or toked[10-11] (because
>>>
>>> I recommend that you use query the seconds to catch the PPS edge, and
>>> then set the time for the next PPS. This will set the GPSDO time into
>>> the device at the precision of a clock cycle:
>>>
>>> http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#aaa80cd6ee4b3c1bf52afb9c3ef02f64d
>>>
>>> -Josh
>>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
>