Fastest way to retrieve datas from TTL input

What do you need: Do you need latency or throughput?
How fast: What "speed" do you need (quantitative)?
Where to: Do you need to retrieve to the host or to the coredevice?
What's the data: Do you need histograms, timestamps, or something else?

Given what you tried, the fastest way would be passing a list to an async RPC. You'll get a few ms.

Concerning the list handling: As mentioned in the FAQ (https://m-labs.hk/artiq/manual/faq.html), variable length arrays are not supported for @kernel functions. This means, that operations like append and concatenating two lists will not work in @kernel functions. Outside of them (on the host I guess), you can use variable length lists though.

So the way I take care of it is to preallocate a list with some default value that is used in @kernel functions and just use that or by @rpc methods I pass values to a separate list on the host, that is being managed there and I can use all of Python's tools if necessary. The same is the case for numpy arrays.

I also want to briefly mention the method append_to_dataset (https://m-labs.hk/artiq/manual/core_language_reference.html) which is useful if you just want to save some values in a list for external evaluation. Then a whole list is sometimes not even needed.

As an example of list handling, here is my experiment for reading out a PMT live through a TTL. It is probably not the optimal way (e.g. I do not use append_to_dataset here, because it is an older experiment and I did not know this method back then), but maybe helps anyway:

class PMTTimeSeries(EnvExperiment):
    
    def build(self):
        self.setattr_device("core")
        self.setattr_device("ttl0")
        self.setattr_device("scheduler")
        self.setattr_device("ccb")
      
        self.setattr_argument("t_accu", NumberValue(
            min = 0*us, 
            max = 10*s,
            default = 10*ms,
            unit = "ms"), 
        tooltip="Accumulation time")
        
        self.setattr_argument("samples",  NumberValue(
            min = 10, 
            max = 100000), 
        tooltip="Number of displayed samples")
        
    @kernel
    def run(self):
        self.ccb.issue("create_applet", "pmt_time_series", 
            "${artiq_applet}plot_xy n_photons", ["PMT"])
        self.set_dataset("n_photons", [None], broadcast=True)
        
        while True:
            self.core.break_realtime()
            try:
                photon_count = self.ttl0.count(self.ttl0.gate_rising(self.t_accu))
                if self.cb(photon_count):
                    break
            except RTIOOverflow:
                continue
                
    def cb(self, photon_count) -> TBool:
        n_photons = self.get_dataset("n_photons")
        if n_photons[0] is None:
            n_photons[0] = photon_count
        else:
            n_photons.append(photon_count)
        if len(n_photons) > self.samples:
            n_photons.pop(0)
            
        self.set_dataset("n_photons", n_photons, broadcast=True)
        
        try:
            self.scheduler.pause()
        except TerminationRequested:
            return True
        return False

Vanimiaou photon_count = self.ttl0.count(self.ttl0.gate_rising(meas_time))

This line runs the compiler twice and returns to the interpreter in between, which is probably not what you want. Make a kernel function that wraps it so that the compiler is invoked only once.

You also need to set the time cursor somewhere with e.g. core.reset() or break_realtime().

I'm not sure what you are trying to achieve - if it is counting some photons at intervals timed by the slow and jittery time.sleep (+ kernel compilation and loading), then add break_realtime() at the beginning of get_photon_count() and remove the calls to delay() which are not necessary.

Vanimiaou What would be the quickest way to retrieve the data do you suggest ? I saw the comment of @rjo using an async RPC but I haven't tried it yet because I do not have the knowledge on that and still have to read about it, do you know where would be a good starting point and whether if there is any example on your github ?

@rpc(flags={"async"})
def collect_data(self, datapoint):
   self.mutate_dataset("n_photons", self.i, datapoint)
   self.i += 1

@kernel
def my_kernel(self):
  ...
  self.collect_data(datapoint)
  ....

Hi all,

I have a related question. Suppose I want to schedule a bunch of ttl gates back to back, like below. I want to do some math on the counts during each gate and decide when to end based on what I find. What is the minimum recovery time I need to give between each gate? I am finding that the required delay to avoid underflowing upon scheduling the next gate_rising_mu ("L" in the code below) grows together with binT, so that in the end I can only have the TTL gated for about half the time. So if I try to run with 10 us gates, I need to burn 10 us between each, if 20, then 20 and so on.

I was really hoping to do something like this, but with a negligible delay between gates, ideally 1*us. Does anyone know what the delay is attributed to? I'm counting 60 kcps, so in a 10 us gate period average 0.6 photons. Could I get around it by sending my PMT signal to TWO ARTIQ TTL's and gating them in an interleaved fashion?

Thanks so much in advance to Sebastien or anyone else who has a chance to weigh in!

@kernel
def countSeveralBins(self):

    binT = 10*us
    tstart = now_mu()
    tdone = self.pmt.gate_rising_mu(binT)

    bin = 0
    Tot = 0

    while True:
        #collect one bin worth of photons.
        #this also forces the timeline up, so after this now_mu() would return tdone.
        thisN = self.pmt.count(tdone)

        #schedule the next bin
        tdone = self.pmt.gate_rising_mu(binT)

        #do math on the current bin's count thisN
        Tot += thisN
        bin += 1
        if Tot > bin*2:
            break
        elif Tot > bin:
            Tot += 100
            break
        elif bin>10:
            Tot = 0
            break

        delay(L*us)

    thisN = self.pmt.count(tdone)
    return T

I think the problem may be that the kernel's ALU (if it has such a thing) is not available for doing math concurrently with gating for TTL input. Can anyone confirm? I'm finding that any math I try to do directly after scheduling a TTL gate doesn't actually get done until after the gate concludes, even if I'm not advancing the timeline cursor.