LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Solved!
Go to solution

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 3rd 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

0 Kudos
Message 1 of 4
(263 Views)

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.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
Message 2 of 4
(233 Views)
Solution
Accepted by topic author _Rollin_

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.

 

Example_VI.png

 

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.

Message 3 of 4
(212 Views)

Bert McMahan,

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

I'm grateful for your support!

Rollin

0 Kudos
Message 4 of 4
(163 Views)