Counting with Arm Start Trigger with Python - NI-DAQmx

[JonDOEreal]

Kevin ... thanks for the help so far. 

I am coming back to this topic as we had worked around the problem by using the trigger signal to reset the counter and use that as a way to trigger the acquisition. It's still not very satisfying. 

It seems that the fundamental issue is with the DAQ board we have (PCIe-6363), which doesn't support external trigger for digital counter applications. I am now considering to purchase a PCI-6601. However I am not sure if this board would support external trigger. Do you know if that's case or maybe it's equivalent to the PCIe-6363?

The whole idea behind this is to use the DAQ board as a triggerable or gated photon counter - saving money on a SR400, for example. 

[Kevin_Price]

Can you describe in more thorough detail what you mean by a "triggerable or gated photon counter"?  I've been in a number of threads here about photon counting, many successful, though it's not something I've ever done myself.  I've seen the SR400 referenced often enough, but don't have any real knowledge about it.

I'll bet there's a way to implement an Arm Start trigger in Python, I just don't know any of the specifics.  It also might not end up being necessary, depending on the big picture of what you're trying to do.  The regular Start Trigger is only available for counter *output* tasks.  The Arm Start Trigger is the *only* kind available for counter *input* tasks (but it can be used on output tasks as well, with or without the regular Start Trigger).

The PCIe-6363 will almost certainly be preferable over the PCI-6601 -- for multiple reasons.  Stick with it.

What signals are you working with, what are their pulse widths and frequency ranges, what are the critical timing relationships you need to characterize?

-Kevin P

[JonDOEreal]

It's great that you could come back to help me, Kevin. Let me first "dump" our code here so you can read through and understand what we are doing. 

With an analog channel, we would like to create a trigger and then do two readout (see the diagram I used in the first post a year ago). Here I am calling it a dummy in the first couple of lines. My purpose was to do the same with the counter channel that follows. I commented some of our trials, and so far the reset method worked well, however, I have a feeling it took data without waiting for the trigger signal. So now I am thinking maybe the gated method would work, see what I wrote here after "#configure the gate signal". I haven't run the gate code yet, but will give it a try today. What do you think? 

        #Create and configure a DAQ task
        NsampsPerDAQread=2*Nsamples
        readTask = nidaqmx.Task()
        
        #create a "dummy" analog channel
        dummy = readTask.ai_channels.add_ai_voltage_chan(DAQ_APDInput,"",TerminalConfiguration.RSE,minVoltage,maxVoltage,VoltageUnits.VOLTS)
        #Configure sample clock
        readTask.timing.cfg_samp_clk_timing(DAQ_MaxSamplingRate,DAQ_SampleClk,Edge.RISING,AcquisitionType.FINITE, NsampsPerDAQread)
        #Configure convert clock
        readTask.timing.ai_conv_src=DAQ_SampleClk
        readTask.timing.ai_conv_active_edge = Edge.RISING
        #Configure start trigger
        readStartTrig = readTask.triggers.start_trigger
        readStartTrig.cfg_dig_edge_start_trig(DAQ_StartTrig,Edge.RISING)
        
        #create a counter channel. 
        channel = readTask.ci_channels.add_ci_count_edges_chan(DAQ_APDInput,"", initial_count=0, edge=Edge.RISING, count_direction=CountDirection.COUNT_UP)  
        channel.ci_count_edges_term = DAQ_APDTerm

        #readTask.timing.cfg_samp_clk_timing(DAQ_MaxSamplingRate,DAQ_SampleClk,Edge.RISING,AcquisitionType.FINITE, NsampsPerDAQread)
        #Configure gate signal
        channel.ci_count_edges_gate_enable = True
        channel.ci_count_edges_gate_term = DAQ_SampleClk
        
        #print(channel.ci_count_edges_gate_enable)
        
        #Configure the counter reset signal
        #channel.ci_count_edges_count_reset_enable = True
        #channel.ci_count_edges_count_reset_term = DAQ_StartTrig
        #channel.ci_count_edges_count_reset_active_edge = Edge.RISING
        
        #Configure the arm start trigger
        #readArmTrig = readTask.triggers.arm_start_trigger
        #readArmTrig.dig_edge_src=DAQ_StartTrig
        #readArmTrig.trig_type = TriggerType.DIGITAL_EDGE
        #readArmTrig.dig_edge_edge = Edge.RISING
        #readArmTrig.sync_type = SyncType.SLAVE
        #readArmTrig.dig_edge_dig_sync_enable = True

        
        #Configure sample clock
        #readTask.timing.cfg_samp_clk_timing(DAQ_MaxSamplingRate,DAQ_SampleClk,Edge.RISING,AcquisitionType.FINITE, NsampsPerDAQread)
        
        #dummyTask.timing.cfg_samp_clk_timing(DAQ_MaxSamplingRate,DAQ_SampleClk,Edge.RISING,AcquisitionType.FINITE, NsampsPerDAQread)
        #Configure start trigger on dummy task
        #dummyStartTrig = dummyTask.triggers.start_trigger
        #dummyStartTrig.cfg_anlg_edge_start_trig("Dev1/ai0")
        #dummyStartTrig.cfg_dig_edge_start_trig(DAQ_StartTrig,Edge.RISING)
        #print(dummyStartTrig.sync_type)
        #dummyStartTrig.retriggerable = True
        #dummyStartTrig.sync_type = SyncType.MASTER
        #readStartTrig = readTask.triggers.start_trigger
        #readStartTrig.sync_type = SyncType.MASTER

[JonDOEreal]

The way we configured the arm start trigger didn't throw any DAQ errors. Now I would like to take two consecutive photon counts after each trigger. So I configure a two sample clock signal, right? Would the counter treat them as gate signals, or would it just continue counting without reset?

[JonDOEreal]

If you read the datasheet of the 6363 card (https://www.ni.com/docs/en-US/bundle/pcie-6363-specs/page/specs.html), it states for the counters that you could use these properties: Gate, Source, HW_Arm, Aux, A, B, Z, Up_Down, Sample Clock.

However when we try to enable the gate, it will throw an DAQ error -  "Specified property is not supported by the device or is not applicable to the task. Property: DAQmx_CI_CountEdges_Gate_Enable". 

It doesn't throw any error when we configure the arm trigger. However, our test shows that the returned photon counts are not synchronized with laser pulse at all. 

The reset function works fine, but it doesn't serve as a trigger for the synchronization purpose. That's so far the conclusion we have. 

I mentioned about the SR400 as a photon counter which does have all these functions with trigger, and gating capabilities. The datasheet of the 6363 indicates that it could offer similar functions, but so far we haven't been able to enable them. 

[Kevin_Price]

I don't think I have a clear understanding of *exactly* what you're hoping to do.  Let me think out loud and then you can correct, clarify, and fill in blanks as needed.

1. There's a laser pulse signal.  I assume it's TTL compatible and can be wired direct to a terminal block for the 6363.

    What is the width of the pulse?  What is the frequency range?  Do you intend to perform distinct measurements for every pulse?  Or do you just need to know that each time you *do* perform measurements there's a fixed and known timing relationship from the pulse to the measurement time?

2. There's a photon detector.  I assume it's also putting out a TTL compatible signal for the 6363.

    You mention wanting to take 2 consecutive photon counts after each trigger.  That will give you 2 count values, but I assume you'll want to know the time interval between them, right?

3. So that's probably why you talk about a sample clock signal.

4. In prior similar threads, photon *rate* seemed to be the key characteristic of interest.  Usually people seem to want that as a streaming measurement, to show a trend over time.   When you talk about sampling exactly 2 count values per trigger, it seems you'll get a single data point for rate rather than a graphable trend.

    Is 2 samples per trigger *really* what you want, or is it just what you thought you had to be stuck settling for?

5. In prior threads, there have been 2 basic approaches:

A. Binning.  This has usually been more successful.  The counter task is configured for edge counting of the photon detector pulses.  The count value is sampled at a constant rate, then a finite difference is performed to give you "bins" containing the # photons detected in each interval -- i.e., an average rate.

B. Direct photon rate measurement.  The counter task is configured for frequency (or period) measurement using the "Implicit Timing" sampling mode.   The counter is actually incrementing counts according to a very high frequency internal clock.  Then each photon pulse latches the instantaneous count as a sample and also resets the count to 0 for the next interval.

    This is a more direct measurement of photon rate for each individual detected photon.  However, it's prone to failure if you get very high rate of photons that the system can't keep up with.

    Counters can *count* very high rate signals b/c that's happening on the hardware.  Capturing *samples* is limited to slower rates because it involves coordination of the hardware, the driver, and the application software.

-Kevin P

[JonDOEreal]

I think we are really getting close to what I want. Let me fill the blank first - please also refer to the figure I posted 08-07-2020 11:23 AM. 

I like the binning approach. Do you have an example to share? Or a thread to follow up with? 

------------------------------------------

1. There's a laser pulse signal.  I assume it's TTL compatible and can be wired direct to a terminal block for the 6363.

The laser pulse width can be adjusted but we normally set it at microseconds, and it's running at ~10 KHz. We intend to count photons for each pulse and find out adjacent pulse to pulse difference. And "there's a fixed and known timing relationship from the pulse to the measurement time".

2. There's a photon detector.  I assume it's also putting out a TTL compatible signal for the 6363.

    "You mention wanting to take 2 consecutive photon counts after each trigger.  That will give you 2 count values." This is want I want. 

    "I assume you'll want to know the time interval between them, right?" We know this; it's set. 

3. So that's probably why you talk about a sample clock signal.

--- yes

4. In prior similar threads, photon *rate* seemed to be the key characteristic of interest.  Usually people seem to want that as a streaming measurement, to show a trend over time.   When you talk about sampling exactly 2 count values per trigger, it seems you'll get a single data point for rate rather than a graphable trend.

---  Yes, 2 samples per trigger. 

[Kevin_Price]

Let me rephrase to see if I've got it.

It looks like you want the first measurement to coincide with the rising edge of the laser pulse, the second measurement to coincide with the falling edge, and then nothing else until the next pulse.   Is that right?

If so, here's good news: this is actually much easier than where I thought we were heading, though there are a few details about config and syntax to wade through.

1. You'll configure the counter for buffered Pulse Width measurement of the laser pulse signal.  

2. But you'll define the photon detector pulses to be the timebase used for doing the measurement

And that's basically all there is.  So for every laser pulse that comes in, the counter will track the # photon pulses that arrive while the laser pulse signal is in the high state.  It'll start over from 0 for the next pulse.  You'll be filling up a buffer of counts per pulse values, which is exactly what you want (I think).

More breadcrumbs (using pseudo-code, this isn't correct syntax):

- you'll configure the task for Implicit timing with units='Ticks'. 

- you'll define Task.PulseWidth.Input.Terminal to be the PFI pin where you connect the laser pulse signal

- you'll define Task.PulseWidth.Timebase.Source to be the PFI pin where you connect the photon detector signal.

-Kevin P

[JonDOEreal]

This is great. Sounds like a method to gate the counter (https://www.ni.com/docs/en-US/bundle/crio-905x-features/page/samp-clock-buff-pulse-width-meas.html). I'd like to know the difference between the two counts in the first and second sample clock, so it would still be great to use an external trigger with the sample clock. Is there a scheme to do that? 

[Kevin_Price]

No scheme, no triggers, no sample clock.

Buffered pulse width measurement directly gives you the "differences" you want.  It gives you the # of photons counted between each pair of the laser pulse's rising and falling edges.

Try it and see!  (Attend to the details I mentioned in a previous reply)

-Kevin P