discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Does time.sleep() affect PPS sync in E310?


From: Lakshay Narula
Subject: [Discuss-gnuradio] Does time.sleep() affect PPS sync in E310?
Date: Fri, 16 Sep 2016 23:58:01 -0500

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]