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
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 (
This user also saw delay of 10.108 ms, which should definitely not be a
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
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.
Discuss-gnuradio mailing list