# Sample time alignment in GRC **URL:** \ **Category:** GNU Radio\ **Created:** [June 13, 2014, 7:59pm UTC](https://www.ruby-forum.com/t/sample-time-alignment-in-grc/230373 "2014-06-13T19:59:48Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![jason\_sam](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7993a0/32.png) [@jason\_sam](https://www.ruby-forum.com/u/jason_sam)\ **Post date:** [June 13, 2014, 7:59pm UTC](https://www.ruby-forum.com/t/sample-time-alignment-in-grc/230373/1 "2014-06-13T19:59:48Z")
* * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) ---
**Author:** ![LapointeS\_Benjamin\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/77aa72/32.png) [@LapointeS\_Benjamin\_S](https://www.ruby-forum.com/u/LapointeS_Benjamin_S)\ **Post date:** [June 13, 2014, 8:05pm UTC](https://www.ruby-forum.com/t/sample-time-alignment-in-grc/230373/2 "2014-06-13T20:05:44Z")
* * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) ---
**Author:** ![LapointeS\_Benjamin\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/77aa72/32.png) [@LapointeS\_Benjamin\_S](https://www.ruby-forum.com/u/LapointeS_Benjamin_S)\ **Post date:** [June 17, 2014, 4:00pm UTC](https://www.ruby-forum.com/t/sample-time-alignment-in-grc/230373/3 "2014-06-17T16:00:11Z")
* * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) ---
**Author:** ![LapointeS\_Benjamin\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/77aa72/32.png) [@LapointeS\_Benjamin\_S](https://www.ruby-forum.com/u/LapointeS_Benjamin_S)\ **Post date:** [June 17, 2014, 4:07pm UTC](https://www.ruby-forum.com/t/sample-time-alignment-in-grc/230373/4 "2014-06-17T16:07:20Z")
On 06/17/2014 09:58 AM, Lapointe, Benjamin - 1008 - MITLL wrote: > USRP Source 2 > For recording the data streams I have USRP Source → Head (5K) → File > > and 1 PPS signals are locked. > > ``` > from sig gen = pulsed 10.005 MHz, input is split with matched > signals, I expect time alignment between the two sample streams. > Discuss-gnuradio mailing list > removed_email_address@domain.invalid > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ``` > > * * * > > Discuss-gnuradio mailing list > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) > What daughtercards are you using again? There _will_ be a random phase offset between the two “sides” here, because GRC flow-graphs can’t take advantage of timed-commands to phase-align the LOs on WBX and SBX cards. ---
**Author:** ![LapointeS\_Benjamin\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/77aa72/32.png) [@LapointeS\_Benjamin\_S](https://www.ruby-forum.com/u/LapointeS_Benjamin_S)\ **Post date:** [June 17, 2014, 4:19pm UTC](https://www.ruby-forum.com/t/sample-time-alignment-in-grc/230373/5 "2014-06-17T16:19:15Z")
* * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) ---
**Author:** ![LapointeS\_Benjamin\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/77aa72/32.png) [@LapointeS\_Benjamin\_S](https://www.ruby-forum.com/u/LapointeS_Benjamin_S)\ **Post date:** [June 20, 2014, 11:44am UTC](https://www.ruby-forum.com/t/sample-time-alignment-in-grc/230373/6 "2014-06-20T11:44:05Z")
Nicholas, Thanks for your message, I implemented your changes to my top\_block.py file, but was unable to get the two data streams from the X310s to start sampling at the same time. I verified with the print statements that python was doing the time conversions and math correctly. I used a WX Scope Sinc and analyzed recorded data in MATLAB to look at time offsets in the two data streams. I also set the 1 second waits to 2 second waits. I generally saw time offsets in the range of 5 to 25 samples (1 to 5 usec with 5MHz output), and one occurrence of ~200 sample offset between the two sample streams. Nicholas, how did you verify sample time alignment? I attached my top\_block python file, in case anyone has time to look at it. Any other ideas/comments? Thanks! -Ben From: Linnenkamp, Nicholas [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: Tuesday, June 17, 2014 1:54 PM To: Robert Kossler; Lapointe, Benjamin - 1008 - MITLL Cc: removed\_email\_address@domain.invalid Subject: RE: [USRP-users] sample time alignment in GRC Ben/Rob, I addressed the issue of getting time aligned samples going for USRP devices sometime back. I had similar issues until I did a deep dive and worked out some of the problems. There is a bit more to the process than just setting sync and reference sources. [http://lists.ettus.com/pipermail/usrp-users\_lists.ettus.com/2014-April/009277.html](http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-April/009277.html) That contains code for getting gnu-radio to perform the required initialization for the devices so that they sample at the same time. Perhaps someone from the gnuradio camp can figure out how to do it automagically. Nicholas From: USRP-users [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Robert Kossler via USRP-users Sent: Tuesday, June 17, 2014 10:28 AM To: Lapointe, Benjamin - 1008 - MITLL Cc: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid); removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [USRP-users] sample time alignment in GRC Hi Ben, I am having a similar (but not identical issue). I have a single X310 for which I am trying to make sure both channels are time aligned. I have tried both the internal PPS signal and an external PPS signal. I noticed channel-to-channel time delays of 1, 2, or 3 “clock” cycles (at clock rate, not sample rate) which varied from run to run. My measurements were done with a modified “rx\_samples\_to\_file” program and Matlab processing. I have not yet duplicated using GRC. Rob On Tue, Jun 17, 2014 at 9:58 AM, Lapointe, Benjamin - 1008 - MITLL via USRP-users \ wrote: Hi All, I am still having trouble time aligning sample streams from two USRP X310 devices. In GRC I noticed a random time offset from run to run in the two data streams using a WX GUI Scope Sink. Looking at recorded data in MATLAB I also see a random time offset from run to run in the two data streams (8, 18, and 24 sample offset). I verified that the two data streams that I am inputting into the X310 devices are time aligned using a physical scope. My GRC setup: USRP Source 1 (with internal GPSDO-MINI) - ``` Sync = unknown PPS ``` - ``` Mb0: Clock Source = Default ``` - ``` Mb0: Time Source = Default ``` USRP Source 2 - ``` Sync = unknown PPS ``` - ``` Mb0: Clock Source = External ``` - ``` Mb0: Time Source = External ``` For looking at the data streams I have USRP Source → Complex to Mag → WX GUI Scope Sink. For recording the data streams I have USRP Source → Head (5K) → File Sink (Unbuffered: OFF) Ref Out SMA of USRP 1 is connected to Ref In SMA of USRP 2 with a 6” SMA cable. PPS Trig Out SMA of USRP 1 is connected to PPS Trig In SMA of USRP 2 with a 6” SMA cable. RF input to USRP devices is a pulsed RF signal, to make it easier to look at time offset. GPS on USRP 1 is locked; however, I work with tall buildings completely surrounding me and so I don’t know the strength of the GPS lock. I have an OctoClock-G on order to distribute 10 MHz Ref and 1 PPS signals, but until then… Does anyone have any other ideas for getting time-aligned samples from run to run in GRC, or what I am doing wrong? I would expect at most a minimal constant time offset between data streams if the 10 MHz Ref and 1 PPS signals are locked. Thanks! -ben From: Marcus L. [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: Friday, June 13, 2014 2:04 PM To: Lapointe, Benjamin - 1008 - MITLL Cc: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Discuss-gnuradio] sample time alignment in GRC Make sure that you specify that the 2nd X310 uses external clock and 1PPS, and all of them should use time synch of “unknown PPS”. Also, there has been a bug in the scope sink (dunno if fixed) where samples are _not_ time-aligned in the scope sink. The except is that a complex-pair will be time-aligned internally, but not necessarily to other streams being displayed. on Jun 13, 2014, Lapointe, Benjamin - 1008 - MITLL \ wrote: Hi, I have two USRP X310 devices that I am trying to time align in GNU Radio Companion. One X310 has a GPSDO that is sending 10 MHz reference and 1 PPS signals to the other one. The GPS is locked. Ideally I would have matched length cables for 10 MHz reference and 1 PPS, but I think my setup is close enough. (Input signal from sig gen = pulsed 10.005 MHz, input is split with matched length cables, USRP output sampling rate = 5M, USRP center frequency = 10M.) I am using WX GUI Scope Sink to look at the magnitudes of each stream from the USRP devices. I expect to see no/minimal delay between the two signal streams, but I am seeing delays of 24, 13, 9, 0, 3, 6, 25, 24 samples from run to run between the two signal streams. The period of the signal is 50 samples, so the maximum delay difference is 25 samples. Am I missing something in my configuration? Since I am using a 10 MHz reference and 1 PPS signals, I expect time alignment between the two sample streams. Is there a GRC block for forcing time alignment? Thanks! -Ben * * * * * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) ---
**Author:** ![LapointeS\_Benjamin\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/77aa72/32.png) [@LapointeS\_Benjamin\_S](https://www.ruby-forum.com/u/LapointeS_Benjamin_S)\ **Post date:** [June 20, 2014, 3:22pm UTC](https://www.ruby-forum.com/t/sample-time-alignment-in-grc/230373/7 "2014-06-20T15:22:42Z")
> that python was doing the time conversions and math correctly. > > I attached my top\_block python file, in case anyone has time to look > at it. > > Any other ideas/comments? FWIW, I wrote a custom block that monitors the X310 USRP w/GPSDO time at the PPS and resets the X310 time, if they are off by more than 1 microsecond. I often get my debug output looking like this: ``` uhd_foo_impl::run(): Setting USRP time to 1401798161 seconds on ``` next PPS uhd\_foo\_impl::run(): USRP time was 1401798159.993764020 seconds on last PPS ``` uhd_foo_impl::run(): Setting USRP time to 1401802468 seconds on ``` next PPS uhd\_foo\_impl::run(): USRP time was 1401802467.000001295 seconds on last PPS The first pair of lines always happens right at block start up. The UHD driver does an initial time setting from the GPSDO, but I’m guessing it must do some hardware magic with the X310 to cause it to lose 3 to 6 milliseconds. The second pair of lines occasionally happens, usually after the first power on of the X310. I do not know the cause. This particular example is odd, in that the jump happened 72 minutes later. It usually happens sooner. BTW, GPS units can throw in leap seconds unannounced in two cases: 1. When GPS ground stations add or remove a leap second to the GPS-UTC offset at the end of June or December. 2. When your GPS has an old GPS-UTC offset in NVRAM at power on, and then gets the correct GPS-UTC offset from the almanac which it downloads from the GPS satellites up to 12.5 minutes after power up. Regards, Andy