[USRP-users] multiple E310 synchronize

liu Jong jongliu1987 at gmail.com
Tue Oct 17 21:52:09 EDT 2017


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 at 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 at 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 at 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 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/20171018/0df9d7ac/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 73195 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171018/0df9d7ac/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 621463 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171018/0df9d7ac/attachment-0001.png>


More information about the USRP-users mailing list