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 >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
