Read and write single square pulse with USB-6008

[irPaul]

Hi,

I'm trying to send and receive start/stop signals to and from an external piece of hardware. Before I did this with an Arduino, now I have to do it with a USB-6008.

The start/stop signals are simple 5V pulses (square waves). The pulse time can be set from 10-5000 ms and the pulse can be configured as high or low active. Given these pulse lengths, strict timing is not crucial.

My question is, what is the most elegant LabView method to send and receive these pulses? Especially for the receiving signal (that is, from the device to the USB-6008) I'm not sure how to detect the rising (high active) or falling (low active) edges. I found various solutions and would like to get some feedback on it.

For the outgoing pulse I have programmed two options based on analog output, one doing on/off with a delay (Snippet 1) and one using a square wave (Snippet 2). Which would be preferred? For the square wave solution, how can know/set the sampling rate to set the corresponding number of samples to get the correct pulse length?

The for incoming edge detection, I have a digital counter (Snippet 3) and crude analog edge detection (Snippet 4).

With the counter I can simply loop the counter value and compare to this. But I would like to add a crude high-frequency filter to reduce noise from the lab. On the Arduino I use a microsecond delay of 250 microseconds: detect signal low/high, wait 250 microseconds, still low/high? Real signal. This gives a crude 4000 Hz cut-off.

In LabView I can do something similar with a delay on the analog input (Snippet 4). The minimum delay is 1 ms, but this is still acceptable. (Note: this snippet has rising/falling not implemented yet.)

Which one would be the nicest LabView solution?

I look forward to the experts' input on this (seemingly) simple matter.

1. Send simple on/off analog pulse

2. Send single square wave

3. Receive with digital counts

 

4. Receive with analog input and crude low-pass filter

[Kevin_Price]

With the (limited) USB-6008 device, there are no perfect solutions, plenty of unsuitable ones, and *just maybe* some that are good enough to live with.  From where I sit, I think you understand this point and already recognize that you're trying to choose "the lesser evil" among them.

Here's the kicker about that choice: it depends.

How inexact can the timing be?  How robust do you want your noise suppression to be?

For pulse generation, it'd be simplest to use something like your 1st snippet if you can tolerate the timing variability you get with software timing (probably within 5 msec the vast majority of the time, occasionally something in the 10's to low 100's of msec, but no guarantees it can't be even worse).  But I think you should probably try to use digital output instead of analog output.

For edge detection, the counter is inherently preferable (at least in theory...) because its hardware is reacting to things even when your software isn't.  With analog, you only see what's happening at the instants that you happen to sample.

   However, noise suppression can be tricky, as can the fact that your counter can only count falling edges, and you also have only 1 of them to use.   Dunno if you need to react to more than 1 input signal.

A whole other non-ideal scheme for edge detection would use Digital Input.  This is probably the way to go if you have 2 or more input signals to monitor for edges.  Here's an outline of a possible approach:

- iterate a software loop at some reasonable rate for your needed reaction time.  Let's just say 100 msec.

- Each iteration of *that* loop, go into a tight DI Read loop that reads 5-10 samples as fast as possible, accumulating an array of results.  (This may take somewhere from single digits to low 10's of msec total).  From that array, determine your "most likely" digital state now.  Compare to the prior "most likely" state to detect an (apparent) edge.

-Kevin P

[irPaul]

Thanks for the elaborate answer, Kevin_Price. You understood my point exactly indeed; I know the 6008 is limited, and I am looking for the most practical solution. For me that is, least resources, does the job.

The tolerance on the incoming and outgoing signals is quite high. I can easily allow for 10-100 ms of lag. The pulses can be configured from 10-5000 ms to accommodate. Generally I use a pulse time of 300 ms. Any high-frequency noise at least 100 Hz.

For the outgoing signal I can use the same waveform-generation as my snippet on a digital output. That might be better indeed, correct?

On the Arduino the incoming signal is wired to an interrupt pin. I found that on the 6008 the counter is wired to the interrupt, so I understand why the counter is preferred. I can live with the limitation of only falling edges. Either I set the pulse time on my external device to 10-20 ms to reduce the lag, or I simply set it to "low active" and detect the falling edge at the beginning of the signal. It does not have any filtering though.

I was just looking into the other modes of the counter input, like Pulse Width or Two Edge Separation to use with digital filter, but these are not supported by the 6008.

I will try the counter first and see if we have any issues with false triggering. I can also add an inline capacitor or RC-filter to filter high-frequency noise. Or I can work with your solution of accumulating a few datapoints and detecting a rising/falling edge in it. That would be easy too.

[Kevin_Price]

For the outgoing signal I can use the same waveform-generation as my snippet on a digital output. That might be better indeed, correct?

If you generate with Digital Output, you should follow your snippet #1 since your timing requirements are loose enough.  I'm pretty sure your device doesn't support hardware-clocked sampling for DIO, which is how your "waveform" method works in snippet #2.

If you detect pulses with the counter, and the incoming pulses are infrequent compared to how often you poll for the count value, you should expect count differences of either 0 (nothing happened) or 1 (a pulse was received).  A difference >1 suggests noise and the possibility of false triggering, though it's unclear to me what you can or should do about it after the fact.

 If noise & false triggering prove to be a real issue, maybe you can resort to hardware clocked AI sampling of the input signal (because you can't hw-clock a DI task).  You'll then need to do some post-processing, but having a time history of the data can help you interpret noise, likely states, and apparent transitions.  Not totally trivial to implement well, but not too awfully bad.

-Kevin P