Hi,Daniel, Thank you for your reply. It is drift over a long time. I also found that said it was a bug: http://permalink.gmane.org/gmane.comp.hardware.usrp.e100/16889 best regards Jon 2017-10-17 23:57 GMT+08:00 Daniel May <danielmay83@gmail.com>: > Jon, > > I've gone through the exercise of sample-synchronizing multiple E310's via > GPS, so I might be able to help. > > When you observe this sample offset, does it remain constant, or does it > drift? If the offset is constant over a long period of time, then at least > your internal clock is being disciplined. > > I noticed this same offset, but the offset would remain constant over > time. I also noticed that if I stopped the stream, and restarted it on > another PPS edge (using the same multi_usrp object), the offset would go > away. You may want to give that a try. > > -Daniel > > On Mon, Oct 16, 2017 at 10:19 PM, liu Jong via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Maybe the accuracy of PPS is not enough ?Any suggestion is welcome. >> thank you. >> best regards >> Jon >> >> 2017-10-16 17:17 GMT+08:00 liu Jong <jongliu1987@gmail.com>: >> >>> Hi,all, >>> >>> I'm using tow E312 to estimate the arrive time difference between >>> received signals.The >>> program is explained as follows: >>> >>> uhd::usrp::multi_usrp::sptr UsrpDev = uhd::usrp::multi_usrp::make(“”); >>> UsrpDev->set_time_source("gpsdo"); >>> UsrpDev->set_clock_source("internal", uhd::usrp::multi_usrp::ALL_MBO >>> ARDS); >>> ... >>> uhd::stream_args_t StreamArgs; >>> StreamArgs.cpu_format ="fc32"; >>> StreamArgs.channels.clear(); >>> StreamArgs.channels.push_back(0); >>> uhd::rx_streamer::sptr RxStreamDev = UsrpDev->get_rx_stream(StreamArgs); >>> ... >>> UsrpDev->set_rx_gain(curGain); >>> UsrpDev->set_rx_rate(curRxRates); >>> UsrpDev->set_rx_freq(tune_request, 0); >>> ... >>> UsrpDev->set_time_next_pps(uhd::time_spec_t(GpsTime + 1.0)); >>> ... >>> uhd::stream_cmd_t CapCmdContStart( uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS >>> ); >>> CapCmdContStart.stream_now = false; >>> CapCmdContStart.num_samps = IQ_NUMS; >>> CapCmdContStart.time_spec >>> = uhd::time_spec_t((double)nextBoardTime); >>> RxStreamDev->issue_stream_cmd(CapCmdContStart); >>> ... >>> size_t RxNums = RxStreamDev->recv( RecvBuffVec, RecvNums, RxMetaData, >>> timeoutD, false ); >>> ... >>> >>> >>> Right now, the data blocks received from the two receivers have strictly >>> aligned time stamps: >>> >>> [image: 内嵌图片 1] >>> >>> However, the time difference between IQ data is irregular. In repeated >>> tests, the range of thetime difference of the signal at the same location >>> may reach thousands of sampling points. >>> For example, the IQ data of the two data blocks are shown in the >>> following figure. These two blocks are captured from the GSM downlink by >>> two E312 in same location, and the blocks >>> have the same start timestamps. In the figure, the red line is I, and >>> yellow line is Q.According to the GSM frequency correction burst, we can >>> see that the TDOA error of the two data >>> blocks is very large. There is no GSM frequency correction burst in the >>> first data block, but there is a GSM frequency correction burst in the >>> second data blocks(2200~2500). >>> >>> >>> [image: 内嵌图片 2] >>> >>> >>> On the other hand, we use “STREAM_MODE_NUM_SAMPS_AND_DONE” commands >>> to collect data, and the time difference is equally large and irregular. >>> We use Linux ppstest command to test the PPS of the GPS, and the display >>> is normal. >>> >>> Our problem is that , >>> 1) does the E312 of the GPS have a dedicated 1PPS output pin available >>> to the FPGA?; >>> 2) can E312 be used for TDOA measurement and, if possible, how to >>> implement it in the >>> program? >>> We should appreciate an early reply, a prompt reply would help us >>> greatly. >>> >>> best reagrds >>> Jon >>> >>> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> >