On 06/08/2020 02:24 PM, Sidd Subramanyam wrote:
I am cross-correlating post-facto via a MATLAB script. Could you
provide some Reading regarding the integer N tuning and how it’s used?
I added exactly your command and initially didn’t seem to have too
much of an effect. The logged start times do indeed line up exactly. I
am sampling at 4 MHz collecting 1 second of data so the listed output
is 4 million samples in sc16 format. That code snippet you mentioned
never triggers an overflow of dropped samples.
-Sidd
On Jun 7, 2020, at 4:36 AM, Marcus D. Leech <[email protected]>
wrote:
On 06/06/2020 08:54 AM, Sidd Subramanyam wrote:
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.
I don't immediately see anything wrong with your code, but of course,
this code is just recording samples, which you are presumably
cross-correlating in an "offline" manner post-facto?
Something you might try is to use integer-N tuning, which may result
in a more mutually-coherent LO setting across your two
synthesizers:
tune_req.args = uhd::device_addr_t
<https://files.ettus.com/manual/classuhd_1_1device__addr__t.html>("mode_n=integer");
Also, you log the time when the recording is expected to take
place--are these values actually the same in the two instances?
What sample rate are you using? How much data are you recording?
Is this code ever triggered?
if (time_tmp > 0.000001)
{
std::cout << boost::format("XX %d Get Time of USRP %f\n")
% f % num_dropped_samps;
}
Here is the documentation of the API related to tune requests:
https://files.ettus.com/manual/structuhd_1_1tune__request__t.html
In terms of what it *MEANS*, however, has to do with the way RF
synthesizers work. There are a wide variety of articles "out there" on
both integer-N and fractional-N synthesis:
https://www.analog.com/en/analog-dialogue/articles/pll-synthesizers.html#
https://www.electronics-notes.com/articles/radio/frequency-synthesizer/pll-indirect-digital-fractional-n-synthesis.php
http://www.ti.com/lit/an/swra029/swra029.pdf?ts=1591648395602&ref_url=https://www.google.com
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
