Waiting for trigger

fschmid

Hello everyone,

I was wondering how to properly wait for a trigger signal in an experiment. Here is a code example I came up with:

from artiq.experiment import *

class LineTrigger(EnvExperiment):

    def build(self):
        self.setattr_argument("use_line_trigger", BooleanValue(default=True))

        self.setattr_device("core")
        self.setattr_device("ttl2")
        self.setattr_device("ttl9")

    @kernel
    def wait_for_line1(self, trig_delay):
        """Wait for line trigger with configurable delay

        :trig_delay: delay after line trigger in s
        """
        t_gate = self.ttl2.gate_rising(20*ms)
        t_trig = self.ttl2.timestamp_mu(t_gate)
        at_mu(t_trig)
        delay(trig_delay)

    @kernel
    def wait_for_line2(self, trig_delay):
        """Wait for line trigger with configurable delay

        :trig_delay: delay after line trigger in s
        """
        while True:
            t_gate = self.ttl2.gate_rising(10*ms)
            t_trig = self.ttl2.timestamp_mu(t_gate)
            if t_trig > 0:
                at_mu(t_trig)
                delay(trig_delay)
                break
            delay(10*us) # No trigger, try again

    @kernel
    def run(self):
        self.core.reset()
        while True:
            if (self.use_line_trigger):
                self.wait_for_line1(100*us)
                #self.wait_for_line2(100*us)
            self.ttl9.pulse(10*us)
            delay(10*us)

This experiment is running a loop that optionally waits for a trigger on ttl2 before putting out a 10 µs pulse on ttl9, followed by a 10 µs delay.

wait_for_line1() works fine on the first loop, but fails on the second one since timestamp_mu() returns the "-1" result from the timeout at the end of the gate period in the previous run. As a workaround, in wait_for_line2() I simply run timestamp_mu() in an infinite loop, until it returns a valid timestamp. I don't find this solution particularly elegant, and one might miss trigger pulses that occur during the delay(10*us) that is required for processing the if condition. Is it somehow possible to flush the result queue, such that timestamp_mu() does not return a "-1" value from a previous run?

sb10q

fschmid wait_for_line1() works fine on the first loop, but fails on the second one since timestamp_mu() returns the "-1" result from the timeout at the end of the gate period in the previous run.

I don't think this is what is happening. timestamp_mu() returns -1 when the timestamp passed as parameter has been reached by the RTIO time counter.

sb10q

What may happen, on the other hand, is the gating gets messed up because you are setting the time cursor backwards when calling at_mu() and then the 20ms gating periods overlap, which isn't handled nicely. You are getting -1 because triggers are missed due to the gate being closed too early.

Can you leave the gate open for the entire period that you want to receive triggers?

sb10q

Or we could allow overlapped gating in ARTIQ, it should just be a counter in the PHY that is incremented when it receives an open command and decremented when it receives a close command. Then the gate is open when counter > 0.

fschmid

Keeping the gate open for the whole experiment is an option, but I have run into several issues:

A new trigger pulse might arrive before the sequence is finished. In this case, timestamp_mu() returns a value pointing to the past and the at_mu() command will fail. This can again be avoided by calling timestamp_mu() in a loop until it returns a valid timestamp, but I don't find this a particularly nice solution:

from artiq.experiment import *

class LineTrigger(EnvExperiment):
    def build(self):
        self.setattr_device("core")
        self.setattr_device("ttl2")
        self.setattr_device("ttl9")

    @kernel
    def run(self):
        self.core.reset()
        t_gate = self.ttl2.gate_rising(10*s)
        t_pulse_end = 0
        while True:
            t_trig = self.ttl2.timestamp_mu(t_gate)
            if t_trig > 0:
                if t_trig < t_pulse_end:
                    continue
                at_mu(t_trig)
            else:
                break
            delay(10*us)
            self.ttl9.pulse(21*ms)
            delay(10*us)
            t_pulse_end = now_mu()

Another issue is that the overall length of the experiment (and thus the required gate time) might not be clear from the beginning.

Also having the gate open on ttl2 somehow broke my ttl_counters in the following example:

from artiq.experiment import *

class LineTrigger(EnvExperiment):

    def build(self):
        self.setattr_device("core")
        self.setattr_device("ttl2")
        self.setattr_device("ttl9")
        self.setattr_device("ttl_counter0")
        self.setattr_device("ttl_counter1")
        self.pmt_exposure_time = 1*ms

    @kernel
    def run(self):
        self.core.reset()
        t_gate = self.ttl2.gate_rising(10*s)
        t_pulse_end = 0
        while True:
            t_trig = self.ttl2.timestamp_mu(t_gate)
            if t_trig > 0:
                if t_trig < t_pulse_end:
                    continue
                at_mu(t_trig)
            else:
                break
            delay(10*us)
            self.ttl9.pulse(1*ms)
            delay(10*us)
            with parallel:
                self.ttl_counter0.gate_rising(self.pmt_exposure_time)
                self.ttl_counter1.gate_rising(self.pmt_exposure_time)
            num_rising_edges0 = self.ttl_counter0.fetch_count()
            num_rising_edges1 = self.ttl_counter1.fetch_count()
            t_pulse_end = now_mu()

The program seems to get stuck on the fetch_count() calls.

Probably the cleanest solution would be to have functions for manually closing the gates and for discarding unwanted events.