Digital Channel acquired and saved to TDMS file, Read then search for nth Edge: Efficient Method Recommendation

[_Rollin_]

Hello LabVIEW Community,

I am currently working on a project where I need to search for the nth rising edge on a digital channel that I have acquired and saved to a TDMS file.

­

MY CONTEXT:

I used a NI-MIO 6363 to acquire a digital signal. This card does not support NI-HSDIO API as I am told.

I read from the TDMS entire channel as a long 1D array of Booleans, then compute two arrays:

• One containing indexes of rising edges,
• The other containing indexes of falling edges,

then if I want the 3^rd rising edge, it’s easy: it’s element #3 in the rising array.

The above works in most cases, except if I acquire 1 minute of a 10MHz square wave, my computed transition arrays become too big and cause a computer freeze.

SOLUTION #1:

• I am about to implement this: Update the above code to do the edge index computations by reading chunks instead of the entire channel.

POSSIBLE SOLUTION #2?

• Is there a built-in feature in the TDMS API or in DAQmx that already does this?

Could anyone provide guidance?

Thank you in advance for your assistance,

With Best regards,

Rollin

[santo_13]

There is no easy way to process the long data than in batches, a typical large data analysis problem.

I would guess you're doing something with digital protocol and trying to fit that into a DAQ that was not designed for that application, hence the hassle.

[BertMcMahan · Accepted solution]

There are in fact built-in tools to help do this, though you may still have memory issues.

You want to convert your digital data to "Compressed". Use "DWDT Compress Digital". That will compress your data down to only the transitions.

The "Transitions" array will give you all of the low to high and high to low transitions. The "Data" array (in Get Digital Data Components) gives you the value at each of those transitions. You should be able to go from there to get your desired transition count.

I assume that calculating the transition arrays is the part that's gobbling up your memory. If it's actually the "finding the nth transition", then use the above functions to generate the arrays, then use a similar algorithm to what you're currently using to determine your transition number.

For example: if you're looking for the 3rd rising edge, and your first sample is a 0, then your rising edge is at index 3*2=6, or element 10 in the original array. If the first element is a 1, you can offset the algorithm.

You don't have to traverse the arrays to do any of that math. Since the transitions array is alternating L-H and H-L transitions, you can multiply your desired number by 2, then pick that number as the index to the "Transitions" array. Use the value in that array to know where in your original array the transition occurred.

[_Rollin_]

Bert McMahan,

I really appreciate the solution you provided. It’s brilliant!

I'm grateful for your support!

Rollin