Sample time alignment in GRC


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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
[email protected] <mailto:[email protected]>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
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.


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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:[email protected]]
Sent: Tuesday, June 17, 2014 1:54 PM
To: Robert Kossler; Lapointe, Benjamin - 1008 - MITLL
Cc: [email protected]
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

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:[email protected]] On Behalf
Of Robert Kossler via USRP-users
Sent: Tuesday, June 17, 2014 10:28 AM
To: Lapointe, Benjamin - 1008 - MITLL
Cc: [email protected]mailto:[email protected];
[email protected]mailto:[email protected]
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
<[email protected]mailto:[email protected]> 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:[email protected]mailto:[email protected]]
Sent: Friday, June 13, 2014 2:04 PM
To: Lapointe, Benjamin - 1008 - MITLL
Cc: [email protected]mailto:[email protected]
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
<[email protected]mailto:[email protected]> 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
[email protected]mailto:[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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