Send USRP-users mailing list submissions to
        usrp-users@lists.ettus.com

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
        usrp-users-requ...@lists.ettus.com

You can reach the person managing the list at
        usrp-users-ow...@lists.ettus.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."


Today's Topics:

   1. Does time.sleep() affect PPS sync in E310? (Lakshay Narula)


----------------------------------------------------------------------

Message: 1
Date: Sat, 17 Sep 2016 00:01:27 -0500
From: Lakshay Narula <lakshay.nar...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Does time.sleep() affect PPS sync in E310?
Message-ID:
        <cakmrq1ph68gcqaf0-awqpg5scp4kjnt04lhbirzjzgstrej...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello,

I am seeing something interesting with my E310 when I try to use an
external PPS on the SYNC connector. Here is what I am trying to do: Lock
the internal reference clock to external PPS and generate a burst output
every second using tx_time tags. Feed this output to an oscilloscope, where
I also feed the reference PPS. I just want to check if the E310 can
generate bursts accurately (within a clock cycle).

Here is my procedure:
1. Set time source to "external", and poll the "ref_locked" sensor. I
observe that the sensor indicates lock in about 12 seconds most of the time.
2. Monitor the time_last_pps till a change is seen. Then set the time to
zero at next PPS.
3. Wait for another PPS so that new time is updated.
4. Generate a burst with an integer seconds time tag, for example 10
seconds.
5. Observe what happens on the oscilloscope.

On the oscilloscope, I see the required pulse is about 10.109 ms later than
the reference PPS. I could live with the delay, but this delay varies from
run to run within 10 microseconds. Then I came across another thread about
the E310 PPS sync (http://lists.ettus.com/pipermail/usrp-users_lists.
ettus.com/2015-November/016936.html). This user also saw delay of 10.108
ms, which should definitely not be a coincidence.

I did some more debugging, and I observed the following. If I skip step 3,
that is, I do not put the GNU Radio flowgraph to sleep for 1 sec for the
time to set to zerp, the 10 ms delay disappears, and there is no
microsecond-level variability in the output time of the pulse. Moreover,
even if I increase that sleep duration to as large as 60 secs, the delay
remains close to 10 ms and does not increase. I have repeated this test
multiple times and I can confirm that there is no other change except
removing that time.sleep() call. (Here I would like to point out that
without this sleep call some of my initial bursts arrive late, since the
tx_time tag is 10 secs and the reset to zero has not happened till the next
PPS.)

So the question is that does putting the flowgraph to sleep affect PPS sync
in some way? It is strange in that increasing the sleep interval has no
effect. But I do not see any other reason for this strange behavior.

Best,
Lakshay.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160917/6b2139b7/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


------------------------------

End of USRP-users Digest, Vol 73, Issue 15
******************************************

Reply via email to