Forum: GNU Radio sample time alignment in GRC

00829417ed328095434afb665145b0c5?d=identicon&s=25 Lapointe, Benjamin - 1008 - MITLL (Guest)
on 2014-06-13 19:59
(Received via mailing list)
Attachment: smime.p7s (7 KB)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus Leech (Guest)
on 2014-06-13 20:05
(Received via mailing list)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
00829417ed328095434afb665145b0c5?d=identicon&s=25 Lapointe, Benjamin - 1008 - MITLL (Guest)
on 2014-06-17 16:00
(Received via mailing list)
Attachment: smime.p7s (7 KB)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2014-06-17 16:07
(Received via mailing list)
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
>     Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> 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.
00829417ed328095434afb665145b0c5?d=identicon&s=25 Lapointe, Benjamin - 1008 - MITLL (Guest)
on 2014-06-17 16:19
(Received via mailing list)
Attachment: smime.p7s (7 KB)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
00829417ed328095434afb665145b0c5?d=identicon&s=25 Lapointe, Benjamin - 1008 - MITLL (Guest)
on 2014-06-20 11:44
(Received via mailing list)
Attachment: time_align_test_no_delay.py (7 KB)
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:nlinnenkamp@appcomsci.com]
Sent: Tuesday, June 17, 2014 1:54 PM
To: Robert Kossler; Lapointe, Benjamin - 1008 - MITLL
Cc: discuss-gnuradio@gnu.org
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....

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:usrp-users-bounces@lists.ettus.com] On Behalf
Of Robert Kossler via USRP-users
Sent: Tuesday, June 17, 2014 10:28 AM
To: Lapointe, Benjamin - 1008 - MITLL
Cc: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>;
discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
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
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> 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 Leech [mailto:mleech@ripnet.com<mailto:mleech@ripnet.com>]
Sent: Friday, June 13, 2014 2:04 PM
To: Lapointe, Benjamin - 1008 - MITLL
Cc: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
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
<blapointe@ll.mit.edu<mailto:blapointe@ll.mit.edu>> 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
Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
5b494ac14b6ea73c79b0b19c76f37dfd?d=identicon&s=25 Andy Walls (Guest)
on 2014-06-20 15:22
(Received via mailing list)
> 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
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.