Software-Defined Reference Clock

Overview of synchronization concepts

Like many other instruments, the Time Tagger can be locked to an external clock. However, the Time Tagger offers two different concepts for synchronization.

Traditional hardware reference clock

If you look at the inputs of your Time Tagger, you will find one labeled CLK or CLK IN. This input allows you to apply an external frequency reference. If the hardware PLL of the device accepts the frequency, the Time Tagger switches to the external reference which takes over the clock role from the internal oscillator. This means that the FPGA of the Time Tagger that performs the TDC is driven directly by the external clock. But there are three major drawbacks of this concept:

The CLK IN only accepts specific frequencies with narrow bandwidth. For example, a Time Tagger Ultra or Time Tagger X will only accept 10 MHz or 500 MHz. A frequency of 9.5 MHz would already be not accepted. As a consequence, you will typically be not able to lock your Time Tagger to a laser system, although it might be desirable to use your laser as the master clock of your experiment.
For signals that are strongly correlated to the external reference, the self-calibration of the Time Tagger does not work properly anymore. The self-calibration relies on the assumption that the incoming events have a random distribution with respect to the TDC. This is always given if the internal oscillator is used but can fail for an externally defined FPGA clock.
Fixed loop filter in hardware: You cannot configure the cutoff frequency between your external clock and any built-in reference. For drifting references, e.g., high cutoff frequencies allow a faster tracking of the references. And for very stable references, low cutoff frequencies support a better white noise suppression.

There are still use cases that make use of the hardware clock (see Synchronizer).

Software-defined reference clock

The alternative and recommended concept is the software-defined reference clock. It has been introduced in software version 2.10 under the label Software Clock and has been extended in version 2.18 to the Reference Clock. In contrast to the traditional hardware synchronization, the TDC is always performed with respect to the internal oscillator of the Time Tagger. The external reference is applied to one of the standard signal inputs. This means, on the hardware level, it is handled like any other signal. On the software level, however, it is evaluated immediately by a software PLL. Based on the new time base provided by the PLL, the entire time-tag stream is rescaled. This means that the behavior of all virtual channel and measurement objects will feel to the user just like the external clock has been applied to the instrument itself.

Setting up the software-defined reference clock

After connecting a clock signal to one of the inputs of the Time Tagger, you can declare the respective input as the system clock by the setReferenceClock() method:

tagger = TimeTagger.createTimeTagger()
tagger.setEventDivider(channel=1,
                       divider=2)
tagger.setReferenceClock(clock_channel=1,           # channel number
                         clock_frequency=10E6,      # frequency in Hz
                         time_constant=1E-3,        # time constant in seconds
                         wait_until_locked=True)

# This command would be ignored because channel #1 is restricted by the Reference Clock.
# The user receives a warning.
tagger.setEventDivider(channel=1
                       divider=100)

In this example, a 10 MHz clock has been connected to input 1. One important aspect is that the clock_frequency takes the actual frequency of the physical signal at the input. While the Reference Clock is active, an Event Divider cannot be set by setEventDivider(). This means that the Reference Clock is aware of the original frequency before division and is able to inject events at the place of dismissed events.

The locking behavior of the Reference Clock depends mostly on the time_constant parameter. It determines the time until the clock settles upon frequency changes. A small time_constant will follow the frequency quickly at the cost of the advantages of averaging. Large values will provide better average values but the locking might be lost if the frequency changes to fast. More than that, phase noise will affect your measurements more severely for strong averaging. Finding the ideal value depends on the characteristics of your reference. If the Reference Clock jumps out of the lock, the Time Tagger will switch to the overflow mode and timing information is lost.

The following picture demonstrates the effect of the Reference Clock for two signals that are on average 10 MHz. The picture exaggerates frequency fluctuations and measurement jitter for clarity. The actual Reference Clock would not be able to lock to such poor signals:

You can see that the input signal on channel #1 oscillates slower in the first half (sparse events) and faster in the second half (dense signals). For the signal on channel #5, it’s exactly the opposite. Both signals have an additional measurement jitter that causes very close events and wider gaps at random places.

The lower panel shows the effect of declaring channel #1 as the Reference Clock. If you compare the signals on channels #1 and #5 from the lower panel to the upper one, you notice that the channel #1 is now quite homogeneous while the frequency change in channel #5 got even worse. The Reference Clock - and thereby the entire time base of the software representation - followed the frequency changes of channel #1. Note that on both channels, #1 and #5, the jitter of the original measurement is still present.

The bottom row shows the ReferenceClockState::ideal_clock_channel. While the Reference Clock calculates the new timebase, it can mathematically identify the expected timestamps of all events, transmitted and dismissed ones. These “ideal” time tags are separated by a numerically exact time difference. The ReferenceClockState::ideal_clock_channel is based on channel #1 but almost completely eliminates the measurement jitter. Therefore, it can be used as an improved replacement.

Technical limitations

Before setting up the Reference Clock, you should consider some limitations. We need to answer two questions, namely which signals you can use as clock signals and which accuracy you can achieve theoretically.

Input signal limitations

In comparison to the traditional hardware clock that would only accept 10 MHz or 500 MHz on a Time Tagger Ultra, the software-defined Reference Clock is extremely flexible. On a Time Tagger Ultra and Time Tagger X, it accepts any frequency from 1 kHz to the maximum frequencies of 475 MHz or 700 MHz, respectively. Tracking and evaluating periodic signals requires a sufficient internal oscillator, which the Time Tagger 20 is lacking, unfortunately. For this reason, the Time Tagger 20 will not achieve the performance discussed in this article. As soon as you set up the Reference Clock on a Time Tagger 20, you will face a warning that the resulting jitter will be bad. Whether this is acceptable or not, depends on your experiment, but we will not consider the Time Tagger 20 here anymore.

Resolution limitations

The picture above shows the TDEV of a 1 MHz signal on two inputs. It can be interpreted as the resolution limit for the various Time Tagger models using the Reference Clock. The TDEV is a metric that can be measured using the FrequencyStability measurement class. It is an estimator of the timing error you will find on events of the signal separated by tau under consideration of averaging all available data points. The measurement is performed by using a power splitter to route the 1 MHz signal to two inputs, 1 and 5. While these split signal is, of course, phase-locked for all times, the measurement jitter on both inputs is independent. In that sense, the question is: How much can the individual measurement error be suppressed by averaging?

In the experiment, channel 1 is used as the clock_channel in setReferenceClock(), while channel 5 is investigated by FrequencyStability. On the left, the tau axis starts at 1 µs, corresponding to the 1 MHz signal. The data point at 1 µs represents the shortest sample of subsequent events possible which does not allow averaging. Thus the data start on the left on the level of the specified timing-resolution of the respective model. Larger timescales allow for more and more averaging which improves the timing resolution. The TDEV settles between 100 and 200 femtoseconds for both, the Time Tagger Ultra and the Time Tagger X. This means, that for both models, there is a more or less common non-white noise floor. While white noise can be eliminated at a rate of $\frac{1}{\sqrt{n}}$ by averaging over $n$ events, this is not the case, e.g., for $\frac{1}{f}$ -noise.

Advanced features

Emulating the Conditional Filter

In most cases it is neither necessary nor desriable to transmit the full clock signal to the PC. For periodic signals like the clock, the straight-forward way to reduce the data rate would be the EventDivider. For a typical 10 MHz clock, you can easily apply an event divider of 100 without performance reduction.

But imagine a fluorescence lifetime experiment: A femtosecond-laser (which can be considered a clock as well) excites a sample, and now and then there will be a photon emitted a few nanoseconds later. In this case, one of the signals is aperiodic, and the traditional filter solution would be the ConditionalFilter: Every photon will allow exactly one laser event to pass to the PC. With that, you have pairs of events, in most cases one photon and one laser event. Their time differences can be easily evaluated by measurements like Histogram.

But this approach has two drawbacks in comparison to the EventDivider approach:

You have to sacrifice 50% of your used bandwidth for laser events instead of reducing it by a factor of 100 with the EventDivider.
You cannot exploit the improved temporal resolution of the ReferenceClock on the periodic channel - because the transmitted signal is not periodic anymore.

For this scenario, the ReferenceClock includes a feature that emulates the ConditionalFilter behavior while it actually uses the EventDivider. The following code shows how to set up the emulator:

tagger.setEventDivider(channel=1,
                       divider=100)
reference_clock_state = tagger.getReferenceClockState()
tagger.setConditionalFilter(trigger=[2],
                            filtered=[reference_clock_state.ideal_clock_channel])
tagger.setReferenceClock(clock_channel=1,
                         clock_frequency=80E6)

As you can see, the emulator is configured like the hardware ConditionalFilter by setConditionalFilter(). It works as a modification of the way events are injected in the ReferenceClockState::ideal_clock_channel. The dismissed events are recreated during the rescaling process and immediately filtered by trigger events. The effect is shown in the following sketch:

Note that the jitter of the measured laser events is widely eliminated in the ideal clock and that comparatively few events need to be transferred.

Averaging of rising and falling edges

On the Time Tagger Ultra and Time Tagger X, there is an experimental feature that typically allows to improve the noise characteristics of periodic signals: By using the TimeTagger::xtra_setAvgRisingFalling() method, you can configure the Time Tagger such that it transmits the average of a close-by rising and falling edge. This eliminates anti-correlated noise. Low-frequency noise (e.g. flicker $1/f`$ ) on the analog input voltage shifts the trigger level transitions in the opposite direction on rising and falling edges (for similar rise vs fall times). For the white noise part (which is per definition uncorrelated), it yields $\sqrt(2)$ . It is not yet fully clear which effects contribute to this improvement but the graph below clearly shows that this makes it possible to push the TDEV below 100 fs.