I have data that is sampled at roughly regular intervals. It's coming in from a network and I time stamp each packet. The jitter is small (< 0.1dt typically), but every now and then it spikes (< about .8dt) or some packets are never sent. The data is packed such that I can create a timestamp (Labview RT) on the UDP packet when received and the sample data (Multiple channels) are packed into each packet. That allows me to align the timestamps perfectly to the data. Network sender clock and Labview RT clocks are sync'd via IRIG. dt is usually around 0.01s. I'd like to be able to detect where missing packets are in the recorded data stream and fill those in with the last known value and the expected timestamp. My first thought is attached. It takes in the timestamp data (Packed into a WFM with the dt set to what the incoming data was sent at) then determines the sample-sample delta (Jitter). Anything > dt(1+threshold) is considered to have a missed sample(s) preceding it. This 'kinda' works but seems like a gross over simplification of how to approach this, especially considering the rare cases where the jitter is large, but not actually missing samples. Are there any VIs that might be useful here? Thanks, XL600

LabVIEW

Missing sample detection

@Kevin_Price...
Overall, if some users want to do detailed timing analysis, I think you'd better pass through the original raw values from the packets -- both timing info and data. For convenience you can also construct the cleaner, mostly redundant, but partly fictional datastreams. By retaining the true raw data, you can defer the processing methodology to those users who care most and who may have different preferences than you or each other. Meanwhile, you've also served the majority of use cases by constructing the convenience waveforms (and tagging them as being manipulated).

I'm a big proponent of retaining raw data whenever feasible. Go ahead and do some inline processing for convenience, but keep the raw data too.

-Kevin P

AMEN!

RAW DATA rules! 😄

Just because later you or someone else has a smarter idea on how to treat it or how to resolve more information from it.

Resampling and/or additional timestamping is always needed if you have different data sources not in sync.

If you want to fill and mark missing data and have some lower (noise) bits to share, you can use them to mark the interpolated/missing datapoint. However I would prefer an extra list of (missing data) timestamps.

Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'