Hello all, I have a basic setup which is as follows : · one USRP sends a slot of a duration of 2.5ms, which is a synchronization slot on RF A. This is done using timed commands, in bursted mode. Just after that, on RF B, it has 9 RX slots of 2.5ms, unused so far, then 2ms of nothing (both RX and TX down). This loops indefinitely. · another USRP, launched anytime after the first, tries to catch the synchronization slot sent by the other. So it has basically the same frame structure, except that it has RX slots only. The synchronization search is done over approximately 500µs, so if it didn't catch the synchro on a frame, it changes the time specs for the next frame, applying an offset of 500µs. And eventually, after 5 or 6 frames, the synchronization slot is detected and this USRP changes its frame structure to have basically the contrary to the other USRP : one RX slot (to detect that we remain synchronized) and 9 TX slots, unused so far. · Both USRPs are B210, using their internal clock, each connected to one laptop with USB3, with no external power supply. · Both running with UHD3.9.4 This works quite well except that the synchronization position recorded by the 2nd USRP slowly drifts. Judging by the data of one experiment, the synchronization time drifts by 1µs each 5s, so for example it acquires the synchro at X,XXX420s, 5 seconds later it will be at X,XXX421s (seconds and milliseconds not relevant here) and so on and so on. Is that a known thing or should I look into my code to see if I've done something wrong (really not out of question) ? Thanks in advance, Laurent Louf.

That's a drift of about 200PPB. Which is about what you'd expect using independent internal clocks. If you no-drift timing between two USRPs, you need an external timing source giving 1PPS and 10MHz reference signals. On 2016-09-06 09:26, LOUF Laurent via USRP-users wrote: > Hello all, > > I have a basic setup which is as follows : > > · one USRP sends a slot of a duration of 2.5ms, which is a synchronization slot on RF A. This is done using timed commands, in bursted mode. Just after that, on RF B, it has 9 RX slots of 2.5ms, unused so far, then 2ms of nothing (both RX and TX down). This loops indefinitely. > > · another USRP, launched anytime after the first, tries to catch the synchronization slot sent by the other. So it has basically the same frame structure, except that it has RX slots only. The synchronization search is done over approximately 500µs, so if it didn't catch the synchro on a frame, it changes the time specs for the next frame, applying an offset of 500µs. And eventually, after 5 or 6 frames, the synchronization slot is detected and this USRP changes its frame structure to have basically the contrary to the other USRP : one RX slot (to detect that we remain synchronized) and 9 TX slots, unused so far. > > · Both USRPs are B210, using their internal clock, each connected to one laptop with USB3, with no external power supply. > > · Both running with UHD3.9.4 > > This works quite well except that the synchronization position recorded by the 2nd USRP slowly drifts. Judging by the data of one experiment, the synchronization time drifts by 1µs each 5s, so for example it acquires the synchro at X,XXX420s, 5 seconds later it will be at X,XXX421s (seconds and milliseconds not relevant here) and so on and so on. Is that a known thing or should I look into my code to see if I've done something wrong (really not out of question) ? > > Thanks in advance, > > Laurent Louf. > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Yes, Marcus is dead on wrt my experience sync'ing two radios. I compensated using a blind estimation TOA algorithm that both (all) radios run to keep their clocks aligned. Since the alg is blind and the radios are often 30km or more apart, the average offset is on the order of 100 us. It can be (much) better when they are closer or if you can have radios measure their inter-radio delay. Steven Knudsen, Ph.D., P.Eng. www.techconficio.ca www.linkedin.com/in/knudstevenknudsen > On Sep 6, 2016, at 09:22, Marcus D. Leech via USRP-users <usrp-users@lists.ettus.com> wrote: > > That's a drift of about 200PPB. Which is about what you'd expect using independent internal clocks. > > If you no-drift timing between two USRPs, you need an external timing source giving 1PPS and 10MHz reference signals. > > > > > > >> On 2016-09-06 09:26, LOUF Laurent via USRP-users wrote: >> >> Hello all, >> >> >> >> I have a basic setup which is as follows : >> >> · one USRP sends a slot of a duration of 2.5ms, which is a synchronization slot on RF A. This is done using timed commands, in bursted mode. Just after that, on RF B, it has 9 RX slots of 2.5ms, unused so far, then 2ms of nothing (both RX and TX down). This loops indefinitely. >> >> · another USRP, launched anytime after the first, tries to catch the synchronization slot sent by the other. So it has basically the same frame structure, except that it has RX slots only. The synchronization search is done over approximately 500µs, so if it didn’t catch the synchro on a frame, it changes the time specs for the next frame, applying an offset of 500µs. And eventually, after 5 or 6 frames, the synchronization slot is detected and this USRP changes its frame structure to have basically the contrary to the other USRP : one RX slot (to detect that we remain synchronized) and 9 TX slots, unused so far. >> >> · Both USRPs are B210, using their internal clock, each connected to one laptop with USB3, with no external power supply. >> >> · Both running with UHD3.9.4 >> >> >> >> This works quite well except that the synchronization position recorded by the 2nd USRP slowly drifts. Judging by the data of one experiment, the synchronization time drifts by 1µs each 5s, so for example it acquires the synchro at X,XXX420s, 5 seconds later it will be at X,XXX421s (seconds and milliseconds not relevant here) and so on and so on. Is that a known thing or should I look into my code to see if I’ve done something wrong (really not out of question) ? >> >> >> >> Thanks in advance, >> >> Laurent Louf. >> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Thanks to both of you for your quick answers, that’s something I can live with, I’ll just use the information about the drift that I get from my synchronization slot to periodically apply an offset on one of the two USRPs. Problem solved ! Laurent Louf. De : ee.knud@gmail.com [mailto:ee.knud@gmail.com] Envoyé : mardi 6 septembre 2016 18:17 À : mleech@ripnet.com Cc : LOUF Laurent; usrp-users@lists.ettus.com Objet : Re: [USRP-users] Temporal drift between two B210 ? Yes, Marcus is dead on wrt my experience sync'ing two radios. I compensated using a blind estimation TOA algorithm that both (all) radios run to keep their clocks aligned. Since the alg is blind and the radios are often 30km or more apart, the average offset is on the order of 100 us. It can be (much) better when they are closer or if you can have radios measure their inter-radio delay. Steven Knudsen, Ph.D., P.Eng. www.techconficio.ca<http://www.techconficio.ca> www.linkedin.com/in/knudstevenknudsen<http://www.linkedin.com/in/knudstevenknudsen> On Sep 6, 2016, at 09:22, Marcus D. Leech via USRP-users <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote: That's a drift of about 200PPB. Which is about what you'd expect using independent internal clocks. If you no-drift timing between two USRPs, you need an external timing source giving 1PPS and 10MHz reference signals. On 2016-09-06 09:26, LOUF Laurent via USRP-users wrote: Hello all, I have a basic setup which is as follows : • one USRP sends a slot of a duration of 2.5ms, which is a synchronization slot on RF A. This is done using timed commands, in bursted mode. Just after that, on RF B, it has 9 RX slots of 2.5ms, unused so far, then 2ms of nothing (both RX and TX down). This loops indefinitely. • another USRP, launched anytime after the first, tries to catch the synchronization slot sent by the other. So it has basically the same frame structure, except that it has RX slots only. The synchronization search is done over approximately 500µs, so if it didn’t catch the synchro on a frame, it changes the time specs for the next frame, applying an offset of 500µs. And eventually, after 5 or 6 frames, the synchronization slot is detected and this USRP changes its frame structure to have basically the contrary to the other USRP : one RX slot (to detect that we remain synchronized) and 9 TX slots, unused so far. • Both USRPs are B210, using their internal clock, each connected to one laptop with USB3, with no external power supply. • Both running with UHD3.9.4 This works quite well except that the synchronization position recorded by the 2nd USRP slowly drifts. Judging by the data of one experiment, the synchronization time drifts by 1µs each 5s, so for example it acquires the synchro at X,XXX420s, 5 seconds later it will be at X,XXX421s (seconds and milliseconds not relevant here) and so on and so on. Is that a known thing or should I look into my code to see if I’ve done something wrong (really not out of question) ? Thanks in advance, Laurent Louf. _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

You could also have a GPSDO at each site. But if you can correct algorithmically, that reduces your power/hardware footprint. On 2016-09-07 03:08, LOUF Laurent wrote: > Thanks to both of you for your quick answers, that's something I can live with, I'll just use the information about the drift that I get from my synchronization slot to periodically apply an offset on one of the two USRPs. Problem solved ! > > Laurent Louf. > > DE : ee.knud@gmail.com [mailto:ee.knud@gmail.com] > ENVOYÉ : mardi 6 septembre 2016 18:17 > À : mleech@ripnet.com > CC : LOUF Laurent; usrp-users@lists.ettus.com > OBJET : Re: [USRP-users] Temporal drift between two B210 ? > > Yes, Marcus is dead on wrt my experience sync'ing two radios. I compensated using a blind estimation TOA algorithm that both (all) radios run to keep their clocks aligned. Since the alg is blind and the radios are often 30km or more apart, the average offset is on the order of 100 us. It can be (much) better when they are closer or if you can have radios measure their inter-radio delay. > > Steven Knudsen, Ph.D., P.Eng. > > www.techconficio.ca [1] > > www.linkedin.com/in/knudstevenknudsen [2] > > On Sep 6, 2016, at 09:22, Marcus D. Leech via USRP-users <usrp-users@lists.ettus.com> wrote: > > That's a drift of about 200PPB. Which is about what you'd expect using independent internal clocks. > > If you no-drift timing between two USRPs, you need an external timing source giving 1PPS and 10MHz reference signals. > > On 2016-09-06 09:26, LOUF Laurent via USRP-users wrote: > > Hello all, > > I have a basic setup which is as follows : > > · one USRP sends a slot of a duration of 2.5ms, which is a synchronization slot on RF A. This is done using timed commands, in bursted mode. Just after that, on RF B, it has 9 RX slots of 2.5ms, unused so far, then 2ms of nothing (both RX and TX down). This loops indefinitely. > > · another USRP, launched anytime after the first, tries to catch the synchronization slot sent by the other. So it has basically the same frame structure, except that it has RX slots only. The synchronization search is done over approximately 500µs, so if it didn't catch the synchro on a frame, it changes the time specs for the next frame, applying an offset of 500µs. And eventually, after 5 or 6 frames, the synchronization slot is detected and this USRP changes its frame structure to have basically the contrary to the other USRP : one RX slot (to detect that we remain synchronized) and 9 TX slots, unused so far. > > · Both USRPs are B210, using their internal clock, each connected to one laptop with USB3, with no external power supply. > > · Both running with UHD3.9.4 > > This works quite well except that the synchronization position recorded by the 2nd USRP slowly drifts. Judging by the data of one experiment, the synchronization time drifts by 1µs each 5s, so for example it acquires the synchro at X,XXX420s, 5 seconds later it will be at X,XXX421s (seconds and milliseconds not relevant here) and so on and so on. Is that a known thing or should I look into my code to see if I've done something wrong (really not out of question) ? > > Thanks in advance, > > Laurent Louf. > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com Links: ------ [1] http://www.techconficio.ca [2] http://www.linkedin.com/in/knudstevenknudsen

Marcus is right and reminds me that I should have mentioned my constraints were that a GPSDO could not be assumed to always be available for all radios and that no information that could identify a transmitting radio was allowed to be included in a transmission. Unfortunately, I am not allowed to publish information on this system and its algorithms. I assume it’s obvious, but will say it anyway, that measuring drift has to be relative to a superior time source, or the drift information has to be communicated to a host with a superior time source for analysis and time correction. Again, one of my constraints was that there could be no time master in the network. That complicates things a fair bit, but at least avoids the whole issue of master selection and election. For added complication, unless you have a synchronous system, you may have to account for periods when there are no transmissions and, hence, you can’t rely on received packet timing to keep slots aligned. TDMA can be so much fun :-/ Steven Knudsen, Ph.D., P.Eng. www. techconficio.ca www.linkedin.com/in/knudstevenknudsen An Fortschritt glauben heißt nicht glauben, daß ein Fortschritt schon geschehen ist. Das wäre kein Glauben. - Franz Kafka Post hoc ergo propter hoc. > On Sep 7, 2016, at 07:52, mleech@ripnet.com wrote: > > You could also have a GPSDO at each site. But if you can correct algorithmically, that reduces your power/hardware footprint. > > > > > On 2016-09-07 03:08, LOUF Laurent wrote: > >> Thanks to both of you for your quick answers, that's something I can live with, I'll just use the information about the drift that I get from my synchronization slot to periodically apply an offset on one of the two USRPs. Problem solved ! >> >> >> >> Laurent Louf. >> >> >> >> De : ee.knud@gmail.com [mailto:ee.knud@gmail.com] >> Envoyé : mardi 6 septembre 2016 18:17 >> À : mleech@ripnet.com >> Cc : LOUF Laurent; usrp-users@lists.ettus.com >> Objet : Re: [USRP-users] Temporal drift between two B210 ? >> >> >> >> Yes, Marcus is dead on wrt my experience sync'ing two radios. I compensated using a blind estimation TOA algorithm that both (all) radios run to keep their clocks aligned. Since the alg is blind and the radios are often 30km or more apart, the average offset is on the order of 100 us. It can be (much) better when they are closer or if you can have radios measure their inter-radio delay. >> >> Steven Knudsen, Ph.D., P.Eng. >> www.techconficio.ca <http://www.techconficio.ca/> >> www.linkedin.com/in/knudstevenknudsen <http://www.linkedin.com/in/knudstevenknudsen> >> >> On Sep 6, 2016, at 09:22, Marcus D. Leech via USRP-users <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: >> That's a drift of about 200PPB. Which is about what you'd expect using independent internal clocks. >> If you no-drift timing between two USRPs, you need an external timing source giving 1PPS and 10MHz reference signals. >> >> >> >> On 2016-09-06 09:26, LOUF Laurent via USRP-users wrote: >> Hello all, >> >> I have a basic setup which is as follows : >> · one USRP sends a slot of a duration of 2.5ms, which is a synchronization slot on RF A. This is done using timed commands, in bursted mode. Just after that, on RF B, it has 9 RX slots of 2.5ms, unused so far, then 2ms of nothing (both RX and TX down). This loops indefinitely. >> · another USRP, launched anytime after the first, tries to catch the synchronization slot sent by the other. So it has basically the same frame structure, except that it has RX slots only. The synchronization search is done over approximately 500µs, so if it didn't catch the synchro on a frame, it changes the time specs for the next frame, applying an offset of 500µs. And eventually, after 5 or 6 frames, the synchronization slot is detected and this USRP changes its frame structure to have basically the contrary to the other USRP : one RX slot (to detect that we remain synchronized) and 9 TX slots, unused so far. >> · Both USRPs are B210, using their internal clock, each connected to one laptop with USB3, with no external power supply. >> · Both running with UHD3.9.4 >> >> This works quite well except that the synchronization position recorded by the 2nd USRP slowly drifts. Judging by the data of one experiment, the synchronization time drifts by 1µs each 5s, so for example it acquires the synchro at X,XXX420s, 5 seconds later it will be at X,XXX421s (seconds and milliseconds not relevant here) and so on and so on. Is that a known thing or should I look into my code to see if I've done something wrong (really not out of question) ? >> >> Thanks in advance, >> Laurent Louf. >> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>