W dniu 22.02.2018 o 23:37, Marcus D. Leech via USRP-users pisze: > On 02/22/2018 09:15 AM, Piotr Krysik via USRP-users wrote: >> Hi all, >> >> There was a thread on this topic started by Hideyuki Matsunaga that >> didn't resolve this question. >> >> I want to reiterate this question here but from different point: it >> seems that at this moment it isn't possible. I did my best to >> synchronize two USRPs B210 (the description is below) and the result was >> negative. >> Please prove my hypothesis is wrong. >> >> >> Here is the description how to reproduce the problem (keep in mind that >> the code below was tested on USRP X310 and it worked correctly): >> >> 1. connect REF and PPS inputs of USRPs to reference clock source (i.e. >> octoclock-G), >> >> 2. connect noise source (i.e. another USRP) at 1GHz central frequency >> (this is default frequency of the recorder) through an attenuator and >> splitter to inputs of USRPs B210, >> >> 3. run: >> >> recorder.py --serial1 <serial_of_first_usrp_b210> --serial2 >> <serial_of_second_usrp_b210> >> >> (recorder.py implements synchronization of two usrp_source objects, the >> function that does that is Python re-implementation of >> set_time_unknown_pps uhd function). >> >> 4. then open octave-cli and in it run: >> >> show_cross_corrs >> >> >> You should get the results like below: >> >> The result of cross-correlation between channels of single USRP: >> >> https://imgur.com/a/66Z2g >> >> Everything is fine here, the correlation peak is in the zero, which >> means that correlated signals are time-synchronized. >> >> >> The result of cross-correlation between channels of different USRPs: >> >> https://imgur.com/a/sCKCS >> >> Here there is problem: the peak is not in zero, the signals recorded by >> two different USRPs *are not time-synchronized*. >> >> >> I tested with UHD installed from Ubuntu 16.04 packages and fresh >> compilation, for different B210s and different Octoclocks-G and the >> synchronization of B210s doesn't work. Why is it the case? I might be >> doing something wrong, but please take into consideration that there is >> something wrong with B210s time-synchronization in general. It would be >> great if someone can reproduce the problem or show that it works for him >> (if yes: how he did it). >> >> >> I attach whole code of the recorder (with grc file that was used to >> generate part of it) and processing and image of the flowgraph. >> > I took a quick look at your flow-graphs. > > Two things come to mind > > (A) What if more than 3 seconds of wall-time occur between your __init > function, and the code finally calling tb.start()? That would cause > the B210 to > begin streaming immediately, and since this is two different > multi_usrps, there's no time-alignment between them. > > (B) There is a 180deg ambiguity in the AD9361 clock logic, so that two > AD9361s given the same clock can have a 180deg phase-difference at the > mixer > (or 0deg phase difference, depending on divider state) this is > probably not your issue, but it is an *additonal* headache you'll have > to deal with. Hi Marcus,
Ad.A I doubted it as the time reported by both USRPs at the end of synchronization function is about ~0.005 s. Anyway I increased the value of start time to 9 seconds - with the same (negative) result. Ad.B When I get these B210s to time-synchronize I plan to implement phase calibration method that doesn't rely on the capabilities provided by B210's LO synthesizer. But I need to get to that point first. BTW 180deg ambiguity is still better than what I expected. -- Best Regards, Piotr Krysik _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
