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
One thing to note is that with any pair of GPS/GPSDO units, the 1PPS
pulse will happen at slightly different times for each unit (The LC_XO
unit used in the B210 is specced to +/-50NS). This will inevitably
result in a phase/time offset in the sample streams from each unit, which
you will need to resolve. However, once this offset is calculated,
the streams SHOULD NOT drift with respect to one another.
Now, a "robustly coherent" receiver system will ALWAYS use a shared LO
(best) or at least a shared 10MHz reference clock (2nd best). In your
case, you're not sharing the 10Mhz reference, but using independent
GPSDO units to provide a reference clock. The effective mutual
phase noise between the two will be non-zero, and have components at
both low frequencies and high frequencies.
You might want to stick a dual-trace scope on the 10MHz outputs on your
two units to see what the magnitude of the mutual phase-noise
between the two units is.
The schematics are here:
https://files.ettus.com/schematics/b200/b210.pdf
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;
}
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
