W dniu 26.02.2018 o 17:22, Marcus D. Leech via USRP-users pisze:
> On 02/26/2018 09:16 AM, Piotr Krysik via USRP-users wrote:
>> W dniu 26.02.2018 o 12:43, Piotr Krysik via USRP-users pisze:
>>> W dniu 26.02.2018 o 11:29, Piotr Krysik via USRP-users pisze:
>>>> W dniu 25.02.2018 o 20:08, Marcus D. Leech via USRP-users pisze:
>>>>> OK, so (and apologies if this was in your previous data) what is the
>>>>> average magnitude of the time discrepancy?
>>>> Usually it was about few hundreds us (random). I will try to perform
>>>> more measurements.
>>>>
>>> I measured some values of the delay - they are in the attachment.
>>> Usually the offset is larger than what I said. It's about ~10ms.
>>>
>>> What is interesting is that the values I got in these measurements were
>>> always positive.
>> Hi Marcus,
>>
>> I've finally found out what the reason for the large offset is !!
>> One of USRPs B210 changes master clock rate AFTER setting the internal
>> time counter.
>> I've found it out when I printed USRPs time at the end of time setting
>> function and seen this:
>>
>> ...
>> -- Asking for clock rate 32.000000 MHz...
>> -- Actually got clock rate 32.000000 MHz.
>> -- Performing timer loopback test... pass
>> -- Performing timer loopback test... pass
>> set_min_output_buffer on block 2 to 10000000
>> USRP1 time: 1.003918125
>> USRP2 time: 1.004056625
>> -- Asking for clock rate 16.000000 MHz... Asking for clock rate
>> 16.000000 MHz...
>> -- Actually got clock rate 16.000000 MHz.
>> -- Performing timer loopback test...
>> -- Actually got clock rate 16.000000 MHz.
>> -- Performing timer loopback test... pass
>> -- Performing timer loopback test... pass
>> -- Performing timer loopback test... pass
>> -- pass
>> ...
>>
>> Whole part below "USRP2 time: 1.004056625" shouldn't be there. The
>> device at that moment is changing its master clock rate from 32MHz to
>> 16MHz. So what I did was setting master clock rate explicitly to 16MHz.
>> *This solved the issue*.
>>
>> Many thanks for your advices that stimulated me to think about solution
>> the problem.
>>
>> I'm attaching the recorder to the post, so others will be able to start
>> synchronizing their B210s from something that works.
>>
>> Best Regards,
>> Piotr Krysik
>>
> Hmmm, but if you're using the same sample rate on both devices (you
> are, as I recall), things should still "work out", I think?
>
> The advice on B2xx has always been to do the clock-sync "dance"
> *after* sample-rates have been set, or to force a specific master-clock
> rate early on, since, indeed, the sample-rate logic can change the
> master-clock rate after start-up
It's hard for me to understand why only one of the devices changes the
master clock rate at that moment. This seems a bit arbitrary. It would
be best that after creation of usrp_source the master clock rate
wouldn't be changed (unless user requests it).
Anyway I should have expected something like this. Some time back I had
similar issue when doing GPS synchronization.
I attach version of 'recorder.py' that has some unnecessary sleeps removed.
#!/usr/bin/env python2
# -*- coding: utf-8 -*-
from recorder_grc import *
import time
class recorder(recorder_grc):
def __init__(self, fc=1000e6, gain1=30, gain2=30, samp_rate=1e6, start_time="", rec_len=1, gain3=30, gain4=30, serial1="", serial2=""):
super(recorder, self).__init__(fc=fc, gain1=gain1, gain2=gain2, samp_rate=samp_rate, rec_len=rec_len, gain3=gain3, serial1=serial1, serial2=serial2)
self.set_time_unknown_pps_costam(uhd.time_spec(0.0))
self.uhd_usrp_source_0.set_start_time(uhd.time_spec(3.0))
self.uhd_usrp_source_0_0.set_start_time(uhd.time_spec(3.0))
def set_time_unknown_pps_costam(self, time_spec):
time_last_pps = self.uhd_usrp_source_0.get_time_last_pps()
while(self.uhd_usrp_source_0.get_time_last_pps() == time_last_pps):
time.sleep(0.01)
self.uhd_usrp_source_0.set_time_next_pps(time_spec)
self.uhd_usrp_source_0_0.set_time_next_pps(time_spec)
time.sleep(1.0)
if __name__ == '__main__':
main(top_block_cls=recorder)
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
