TDMS non-contiguous waveforms

[GregFreeman]

I have a TDMS file where I would like to log waveform data. But, I am only logging when certain conditions are met. This could result in some condition being met, then the condition going away, then coming back etc. For example, if I want to log when the RPM exceeds a value, I will start on this exceedance. But, maybe RPM drops back below a threshold so I stop logging. Now the RPM comes above the exceedance again, but if I log my waveform to the same channel, it doesn't account for this new t0. Does anyone have any thoughts on work arounds for this? I could make a "timestamp" channel and extrapolate out the timestamps from t0 and dt, but then I need a timestamp channel associated with each DAQ channel. I could have a channel of t0's where a property is the channel it's associated with and the start index of that data from within that channel, but all this is quite in depth. I have also thought about just making a new group or channel for each exceedance, but this could be confusing to the user if using the TDMS viewer. Is there a simpler way?

[asbo]

Are you constantly acquiring data irrespective of RPM? If you are, use the logger to track windows of time which are validate and then "mask out" the data during windows when the logger is disabled. I think that having a separate channel of t0's is unintuitive and potentially awkward to use.

However, I think the correct way is probably to have new groups/channels per instance, unless this adds too much overhead due to event frequency. It also depends on how the data is going to be analyzed. If you're talking about someone using the TDMS viewer to check this data, I would almost think that discrete groups would be more clear, or that writing a custom viewer to tie the waveforms together coherently might be a better solution - you might be trying to solve the problem in the wrong place.

Be sure to consider scenarios where this RPM value could bounce back and forth quickly and the effect the will play in logging.

[GregFreeman]

Thanks for your response. I think I will take the groups approach for each time an exceedance happens because I agree that does make more sense to the end user. Unfortunately it is not exactly as straight forward as just "log when above, don't when not" there are some other conditions like "while exceeding the limit, log x seconds worth of data every x seconds" so there will be time gaps even if the threshold is crossed once and stays above the limit for an extended period of time. I believe I can handle these gaps progammatically with properties, by appending the waveforms in the TDMS file, but writing this time gap and number of samples-per-write as properties. Then when creating a custom viewer, using these properties to split the data back out and put "filler data" of 0's in between, where the gaps were. This keeps the log file smaller, but visually will make sense when displayed to the user.

[Ravi Beniwal]

You could also use the channel properties to store the index and t0 for each segment. That way you have a single channel but you can read individual segments, as needed.

[JamesMc86]

I think all of the ideas you have mentioned are valid but the right decision is going to be based off how you view the data (and how much data there is). If you were going to view it in DIAdem or another tool that can plot non-continuous waveforms based off timestamp channel I would be tempted to add a time channel and keep it in one channel (this will also impact your file size of course). If you did do this though you would also need to be aware of file fragmentation (I wrote an comparision of the affects of TDMS fragmentation here: https://decibel.ni.com/content/docs/DOC-20522)

I would probably agree with asbo though, you can add some nice features then like adding the properties related to the trigger as well. But again if the channels are very short you are going to see a lot of overhead from the headers (which will look like fragmentation although is really an expected consequence of the format).