Detect Analog Input threshold

[hauschka]

Dear community,

I'm building a custom setup to read out a fluorescent signal.
I need to activate some hardware components at the exact moment the fluorescent signal crosses a certain threshold.
These other hardware components are all implemented in Python.

I bought the following components:

Photodiode (output 0-5V) --> NI 9215 (BNC) --> cDAQ-9171 --> USB --> Python

I'm currently using the nidaqmx Python package to read the input stream and plot it "live".

I am now looking for a way to detect the exact moment I'm passing a certain threshold.
- Would I implement this on the hardware side (eg trigger once treshold is passed)?
- Would I implement this on the Python side? (I guess I'm running into timing offsets, then..?)

What would be the most exact way of detecting the very moment a voltage is breached and continuously acquire/plot the signal?
Any help is appreciated, also implementations in Labview, I can then look into ways of transitioning this to Python.

Best,
-h

[santo_13]

The best method is to implement on the hardware, configuring the DAQ for analog start trigger and number of samples to capture.

Please look at the Voltage - Finite/Continuous Input example of DAQmx

I hope that the 9215 supports Analog trigger.

[Kevin_Price]

If you need an instantaneous reaction, you DEFINITELY need to work this on the hardware side.   Especially considering that you have USB between your application software and your DAQ devices.

cDAQ isn't an area of strong expertiese for me, but I'm not so sure that the cDAQ equipment you mentioned is even capable of analog triggering.  You may need different DAQ hardware to get the instant response you want.

-Kevin P

[hauschka]

Thanks for your reply, much appreciated.

I just read here that the 9215 dooes not support HW triggering.
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kIhASAU

Let's put it this way:
If I know I always have an offset of eg 500 msecs, then I can compensate for this later on.
But ideally this offset doesn't change uncontrollably.

With this in mind, could I then do it using the hardware I have?

[Kevin_Price]

Maybe you should describe your whole system more.  There might be other useful workarounds, now that you've backed off from the originally stated need for *instant* response to being able to tolerate a known delay of 500 msec.

Reaction times of <= 500 msec should be very doable with software based methods, but the exact time won't be highly controllable or repeatable.

-Kevin P

[hauschka]

Hi Kevin,

Thanks for taking the time.

The system needs to detect fluorescent particles that flow past a detector.
the particles are excited with UV light and the fluorescent response is detected.

The moment I'm detecting the presence of a particle, I'm activating valves downstream to "separate" it from the main stream.

My initial statement regarding the * exact * moment of detection relates to knowing when the particle passe by the detector.
However, if I know for example that my signal is always offset by 500 msecs, then I can position the valves a bit further away downstream, which will give me time to react and still separate the particle.

It's a pity, I went through this problem description with a sales person from NI before buying the equipment. At no point it was mentioned that HW triggering would be required or not supported on that device 😞

Kevin, you briefly mentioned some other ideas to solve this. Would be great to hear them!

[Kevin_Price · Accepted solution]

Ok, let's just use the 500 msec figure for the sake of discussion.

Let's suppose you place the valves downstream at a point where 500 msec reaction time gets them activated to the right state just before the particle arrives.  Is it *also* important not to react too soon?   What if you activate within 100 msec?

In other words, are you trying to get very close to 500 msec exactly or are you just trying to make sure you don't *exceed* 500 msec?

If you merely need to not *exceed* 500 msec, you can probably be >99% successful.  Just realize that under Windows, across USB, using software timing, etc., you'll never get to a guaranteed 100%.  But with a big window of time like 500 msec, you can probably get pretty close.

Here's an idea for an approach:

1. Configure your analog task as a buffered task with a hardware clock and set it up for Continuous Sampling (all this is done with a call to DAQmx Timing).  Start it right before you enter your reading/monitoring loop.

2. Put a modest Wait function in the loop, maybe about 50 msec.  Use the special (and default) value of -1 as the number of samples to read.  That'll give you all the data available in the buffer and "catch you up" as much as possible.

3. Examine your data to detect the desired triggering criteria.  The position within the data array and your sample rate will tell you how long ago in the past that criteria was satisfied.

4. Two choices now.  You can immediately fire the valves if you only need to avoid *exceeding* 500 msec.  Or if you want to target activation to happen more nearly *exactly* at 500 msec, you can call (or better yet launch) a subvi that will fire the valves after a specific delay you can wire as an input parameter.

An approach like this should be able to work at any sample rate your device supports.

-Kevin P

[hauschka]

Thnaks a lot for your input!