Thank you for this clarification regarding the 10 MHz drift and the 1 PPS pulse. When you mention that the 10 MHz outputs will not precisely track each other in the short run but better in the long run, could you provide an estimate for the duration at which the behavior will track better? My previous email had stated how in a 1 second interval I was experiencing around a ~300 nanosecond drift. However, in other samples I had taken spanning upto 30 seconds, this drift seemed to worsen upto ~15-17 microseconds. From your email regarding how much the 10 MHz deviates during the short run as well as its long term behavior I’m very sure I must be doing something wrong in my code setup.
I have provided some code sections of how I am attempting to synchronize
the time. I start this script at roughly the same time (within about a
couple of seconds) on both USRPs, and they begin to initialize settings
such as bandwidth and center frequency. I then have them wait to start
collection at the nearest rounded up 10 second time multiple of GPS time in
seconds, since the initialization can take varying time for both USRPs to
initialize. I also attached the full code to this email.
*1. Setting Center Frequency *
//set the center frequency
usrp->clear_command_time();
usrp->set_command_time(usrp->get_time_now() + uhd::time_spec_t(0.1));
//set cmd time for .1s in the future
uhd::tune_request_t tune_request(freq);
usrp->set_rx_freq(tune_request);
boost::this_thread::sleep(boost::posix_time::milliseconds(1100));
//sleep 110ms (~10ms after retune occurs) to allow LO to lock
usrp->clear_command_time();
*2. Set to GPSDO time*
//Set references to GPSDO
usrp->set_clock_source("gpsdo", 0);
usrp->set_time_source("gpsdo", 0);
*3. Check for 10 MHz “ref_locked” and for ** GPS “gps_locked” From
Motherboard sensors*
*4. Set internal time to GPS time at the next PPS*
//Set to GPS time
uhd::time_spec_t gps_time =
uhd::time_spec_t(time_t(usrp->get_mboard_sensor("gps_time",
0).to_int()));
usrp->set_time_next_pps(gps_time + 1.0, 0);
//Wait 2 seconds. Known issue
boost::this_thread::sleep(boost::posix_time::seconds(2));
//Check times
gps_time = uhd::time_spec_t(time_t(usrp->get_mboard_sensor("gps_time",
0).to_int()));
uhd::time_spec_t time_last_pps = usrp->get_time_last_pps(0);
//std::cout << "USRP time: " << (boost::format("%0.9f") %
usrp->get_time_last_pps(0).get_real_secs()) << std::endl;
//std::cout << "GPSDO time: " << (boost::format("%0.9f") %
gps_time.get_real_secs()) << std::endl;
if (gps_time.get_real_secs() == time_last_pps.get_real_secs())
std::cout << "USRP time synchronized to GPS time" << std::endl
<< std::endl;
else
std::cerr << "Failed to synchronize USRP time to GPS time" <<
std::endl
<< std::endl;
*5. Command Stream to start at 10 second GPS multiple*
cmd.stream_now = (buff_ptrs.size() == 1);
cmd.stream_mode = uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS;
cmd.stream_now = false;
//Calculate next 10 second GPS time to start
double timeNow = usrp->get_time_now().get_real_secs();
cmd.time_spec = uhd::time_spec_t(ceil(timeNow / 10.0) * 10.0);
rx_stream->issue_stream_cmd(cmd);
-Sidd
On Fri, Jun 5, 2020 at 10:38 PM Marcus D. Leech <[email protected]>
wrote:
> On 06/05/2020 04:35 PM, Sidd Subramanyam wrote:
>
> By clock bias I am referring to the difference between true GPS time and
> the USRP time.
>
> For example, in my application I am running 2 Separate B210 USRPs each
> side by side with a split signal coming from a single S band antenna.
> However, they are both disciplined using separate GPSDOs with separate
> antennas to simulate being 2 independent devices. They are being
> synchronized as described in method 2 in this article (
> https://files.ettus.com/manual/page_sync.html) and then the data
> collection is being commanded to start at the same GPS time for both
> devices.
>
> My goal is to try to create as phase coherent of an operation as possible
> between the 2 USRPs.
> When I cross correlate the 2 split S band signals to calculate difference
> in phase between the 2 signals, there is a significant drift over time.
> This phase difference converted is about 300 nanoseconds over the course of
> 1 second (300 PPB).Because of this, I wished to see if I could use the
> calculated clock bias that I described above to compensate for this drift
> in phase.
>
> However, now that you have mentioned that I should in fact be getting 1
> PPB accuracy when synchronized to GPS time, I am questioning if I am doing
> the time synchronization process wrong altogether Since I seem to be
> getting drift around 300 PB after following the instructions in the link
> above.
>
> Sidd
>
>
> It would be useful to see the parts of your source-code that set up your
> devices--including clock synch, etc.
>
> Further, I'll note that two randomly chosen GPSDO units, even connected to
> the same antenna, will be producing a 1PPS pulse up to several
> (possibly 10s) of nanoseconds different from one another--which is the
> typical spec on the 1PPS pulse.
>
> In *addition* to this, two (or more) GPSDOs will not produce a 10MHz
> output that precisely track each other, even when connected to the
> same antenna. Their long-term behavior is good, but short-term, they
> can disagree with one another, in my experience, so building a
> perfectly-coherent system from two separate GPSDO units doesn't work
> nearly as well as you might hope, particularly not a lower-cost
> unit such as is used in the B2xx (where "lower cost" is kind of a
> relative term--the high-end GPSDOs that use a local Rb oscillator are
> considerably pricey, but not easily packaged into something like the
> USRP B210).
>
>
>
gpssync.cpp
Description: Binary data
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
