the delay in producer/consumer structure

[frogliang]

Hi everyone, 

I need to trigger an output after an input pulse, I test the input and output signal through the oscilloscope, and found that the output has a delay of around 78ms, is that caused by the analog to the digital signal converting and data transferring? each of the loops won't cause that much delay.

thanks!

[Bob_Schor]

It is difficult to know what you are really trying to do.  My "guess" is that you have a signal (being sampled at 1 kHz) and want to trigger something when the signal undergoes some change.  The nature of the change you are looking for is unclear, but what should be clear is that "you will know it when you see it", but not before.  

This brings to mind a trigger circuit on an oscilloscope.  These typically work on a "level" -- if the signal goes above, say, 1 v, the sweep is triggered and you can see everything that happens after the trigger.  [Modern scopes are "smart" -- they are really A/D converters and can show you data "before" the trigger, but that's really cheating, as those data occur in the past, so you are not seeing the data "as it happens", but delayed by the pre-trigger amount].

Triggering on a level is easy -- examine every sample and if it exceeds the level, send a trigger.  [You need to take a little care to only trigger on "below-to-above threshold" transitions, but that a "Very Beginning Class in LabVIEW" problem].  Suppose you want to trigger on a Peak.  Now you have to "find the peak", which you cannot do until you are past the peak (which introduces a necessary delay, as even LabVIEW cannot predict the future).

I don't know what you are trying to use for a Trigger.  However, it should be possible to do the computations in the 0.99 msec you have free after the single Sample is acquired -- no need for Producer/Consumer.

What do you want the Consumer to do?  That's also unclear.  

I recommend that you write a brief paragraph describing what you want to do.  Tell us about sampling rates for your Analog Signal, what you are looking for in the signal, what you want to do when you see whatever-you-are-looking-for (and what you want to do if you see two of them in a row!).  Also describe briefly what the second process is supposed to be and what it does (again, speak in terms of signals and timing).  Do not worry about the "How" -- as you've already noted, the method (or "how") you are currently using doesn't work well.  Reply here and we'll be better able to make suggestions.

Bob Schor

[frogliang]

hi bob,

thank you!

i collect fluorescent signal and input to oscilloscope and DAQ, the input peak means there is a  fluorescent signal passing through, then i need to respond to the signal, so i need to output a voltage immediately. so i use a peak detector to indicate there is a pulse.

liang

[wiebe@CARYA]

---

@frogliang wrote:

 then i need to respond to the signal, so i need to output a voltage immediately.

---

You'd typically use an FPGA for that.

'Immediately' is undefined, but nothing you can make on a PC will be 'immediately'. 78 ms sound pretty good actually.

On an FPGA you could bring this down to <500 ns, and that's a rough maximum estimate. It won't be less then ~80 ns, as you'll have I\O buffering and cable lengths to consider.

EDIT: On top of not being able to response 'immediately', the delay might have enormous jitter. Not you're measuring 78 ms, next time is might be 50 ms or 250 ms.

[crossrulz]

---

@frogliang wrote:

I need to trigger an output after an input pulse, I test the input and output signal through the oscilloscope, and found that the output has a delay of around 78ms, is that caused by the analog to the digital signal converting and data transferring? each of the loops won't cause that much delay.

---

As has been alluded to, what is an acceptable delay?  What output pulse width do you require?

These types of applications typically are horrible on a PC as a PC is not deterministic when it comes to time.  I have seen Windows randomly take over the CPU for a few seconds, causing all kinds of errors and missed data.  So these applications really should be done on an RT system or an FPGA, with the FPGA giving you the best response time and timing accuracy.