Can I oversample multiple identical digitized impulses to create a composite? How?

I have a bit of a problem in that I have some digitally sampled seismic data with an unknown sample rate. It's close to 50 s/second, but not quite. Therefore when concatenating large sets of time-history data, the errors stack up until we see a missed sample, or even two samples that fall on the same instant. Our analysis assumes the sample rate is always held to 50.000 s/sec, but it's evident that this assumption isn't true. Fortunately, one of the digitized channels includes a pulse train from a GPS receiver, so there is a constant 100 millisecond square wave impulse that is generated on the beginning of each second. The problem is that the digitizer has some rolloff and therefore the square wave is slewed into a delayed impulse of unknown shape. The 20.something msec sample rate is insufficient to capture the true shape of the pulse.

If I knew what the true shape of the pulse was, I think that they are consistent enough that I could look at a given sample from the existing data, and determine it's position on the 100msec impulse; i.e. does it occur one, two, five, twelve milliseconds, etcetera into the waveform? If I can make a model of the 'typical' impulse, I should be able to resolve a bit better the timing of each sample. If I could do that, I would be able to look at the first impulse in the file, and the last impulse in the file, and figure out how far that first digitized sample of the timing impulse drifted, relative to the stable GPS timing tic. Once I know the drift, I can calculate out the true sample rate and compensate accordingly.

Does anyone have any suggestions into whether or not this would work? I was thinking of identifying each impulse in some C code, then try to come up with a way to automatically overlay them in order to shape a composite waveform. What I am most baffled by is exactly how to determine the overlay. Maybe use the last sample that doesn't move as an indicator, then overlay based on the slope to the next datapoint, coupled with the impulse's position from the file? I think we can assume that the unknown slew is constant enough across the dataset, so the samples either advance or retard at more or less the same rate. I just don't know how to go about coding it quite yet.

First post, my name is Dan, from Michigan State.

If I understand you correctly, you could make something like that work.
I would generate a square wave of 50Hz samples, then subtract the recorded data square waves and generate an error term, by an offset and least squares technique or cross correlation.
I would then generate a new frequency square wave and repeat.
If the error became less, then the next attempt would be a new frequency in the same direction.
If the error was more, I would move the frequency the other way.

Not really my field, but you had no responses yet.

If I understood correctly there's a very simple solution.
Just assume that the sampling rate is 50 sample/s and perform an FFT over the whole batch of data.
You should see the peak at around 1Hz plus its harmonics.
Take note of the exact frequency and correct the sampling rate accordingly.
E.g. measured peak at 1.1Hz --> corrected sampling rate = 50 * 1.1

dave9000 said:

If I understood correctly there's a very simple solution.
Just assume that the sampling rate is 50 sample/s and perform an FFT over the whole batch of data.
You should see the peak at around 1Hz plus its harmonics.
Take note of the exact frequency and correct the sampling rate accordingly.
E.g. measured peak at 1.1Hz --> corrected sampling rate = 50 * 1.1

Click to expand...

I like that idea! I might have to give it a try. One thing I do need to do is re-learn Vbulletin. I screwed up and hit "post new thread" instead of reply. There's another thread that continues the saga here --> https://www.edaboard.com/threads/247074/#post1057565

The nutshell is that I was able to sort out the sample rate by reviewing five files, and watching for the period of the sample glitch. It would "skip" forward 20 milliseconds once per 1100 seconds. This gave me the period of how long it took to advance forward one 20msec sample. Therefore my files are only 4 milliseconds shorter (out of approximately 280,000 milliseconds) than expected. It's low-tech, but good enough to assess whether or not it's going to adversely affect the data during analysis.