I have been working with a new (to me) recording system called PMAR-XL. This system is available commercially as a passive acoustic package for the Seaglider. It was originally developed by the University of Washington's Applied Physics Laboratory (they originally developed the Seaglider before handing it over for commercial sale to a series of companies, which is now Huntington Ingalls Industries).

There is almost no information about this acoustic system available on the internet. It is listed as an invention on some UW faculty profiles (example here). And there is this report for the precursor to this system (I'm pretty sure...). It's a relatively new add-on by the manufacturer (and they are not acousticians) so their materials are pretty basic and just about operation.

The sampling rate of the system is set using a configuration file, and the maximum value is 180 000 Hz. The data is then lowpass filtered to prevent aliasing, and the max setting for this filter is 60 000 Hz. For each glider dive, a .eng file reports on the status of the acoustic system. In this output file, the sample rate is reported, and it is NOT 180 kHz. It can actually vary slightly from glider dive to glider dive, but is typically 180260.0312, but is sometimes 180259.1719 or 180260.9062. This is leading to some issues when I'm trying to use my normal analysis approaches, because they are expecting identical sample rates for all files.

So, my question is, how is a non-integer sample rate, that varies from file to file, possible? Could anyone explain this to me in as basic a way as possible?

My understanding of sample rate (with the caveat that I am a biologist becoming a bioacoustician rather than an engineer to bioacoustician knowledge base, so its basic) is that a signal comes in on a hydrophone or microphone, then this is digitized at the sample rate, meaning samples are taken at some specified interval...how would that change?

3 Answers 3


The sample-rate of an acoustic recorder is controlled, like many things in computers, by a "clock" which regularly triggers the computations - in our case, triggers the recording of a new sample (e.g. it is set up to trigger 180 thousand times per second). However, these "clocks" are not perfect, and it is very common that the exact time-step experiences drift. This means that after 180 thousand "ticks of the clock", we might not have had an entire second, but one second minus a bit, or one second plus a bit.

For short recordings, drift is no problem, but for long recordings, or recordings which need to be precisely synchronised with others, it leads to problems such as mis-aligned recordings or poorly-estimated timestamps for events.

So what to do about the drift problem? Some devices (and I assume your device is doing this) use the exact timing information that they get from a GPS signal, to give them an external reference for the precise time. They use these exact timestamps to calculate what the "real" effective sampling rate was (i.e. the number of ticks that really happened in 1 second). Of course, it's usually the nominal sample rate (180k) plus or minus some small decimal amount.

This correction is a good thing because the audio file metadata is not being misleading about the duration of time that the audio file represents. However, if you do not need this precision for your analysis, and if the precise values are confusing for your analysis tools, you can artificially ignore it (e.g. by loading the file and re-saving it with a claimed sample rate of exactly 180k).

  • 1
    That is the approach we are taking with the resampling - the data are written as .dat files (with header info) so there is some code to convert to .wav and we've got a setting now that we can force the sample rate to be 180260 (since it seems to very ever so slightly around that integer).
    – selene
    Aug 26 at 18:55
  • Having the drift recorded as a "single value" seems like it wouldn't give you the desired correction, especially if that drift was changing during the dive. It sounds like rate is computed over the entire dive duration?
    – Steve
    Aug 29 at 17:45

The heart of an electronic clock is typically a crystal oscillator. The crystal or quartz is a purely analog component that is engineered to resonate at a specific target frequency. A quartz does not know what an integer number is. A commercial 10 MHz quartz will only by chance oscillate at 10 MHz, but merely oscillate within a narrow frequency interval around 10 MHz. This is the main reason why two household appliances with a time display will sooner or later disagree on what time it is, even if they experience the same temperature.

Temperature is indeed a major cause of the drift mentioned by Dan. It may very well explain why your device reports a different clock frequency from one dive to another. The relationship between temperature and the resonance frequency of crystal is non-linear. Some crystal oscillators include additional electronics to compensate for temperature fluctuations, so that clock drift is kept within tight boundaries.

Since GPS is difficult to use underwater, I guess the reported "effective sampling frequency" is an average over the duration of the dive.

  • Yeah, I was going to say something similar about round numbers in arbitrary units like seconds not being physically special. A quartz crystal also doesn't know what a second is, and its physical definition (a multiple of the period of Cesium atom oscillations) has no connection. With the right time base, any frequency could be a round number multiple of something. You could also say that physically, the more natural thing to look at is the period, the time for one oscillation. And that's not an integer number of anything, it's the reciprocal of a round number of seconds (ideally). Aug 27 at 7:12

Dan beat me.

I also suspect that the glider acq system estimates the effective sampling rate based on GPS resynchronization during surfacing periods. The clock of the acq is certainly kept fixed all the time (180 kHz) but due to temperature variation during diving the clock may speed up a little bit so that you have a couple of samples more every minute or so.

The fact that the sampling rate has 256 samples more every second is most likely due to the not very precise clock generation for the acq. I would also say that 256 samples more every second (1.4e-3) is certainly not a sign of quality

Edit: according to documentation (comment by @selene) 180 kHz is considered the desired sampling frequency, but the processor may choose a different one, so that the internal logic (clock multiplier/divider) results in a sampling rate using a reasonable (or acceptable) rational number. For example: using a RTC xtal of 32.768 kHz a multiplication by 11 followed by a division of 2 would result in 180.224 kHz. Would be interesting to know which xtal the processor is using.

  • Yes, I think it is resynching every surfacing, which is about every 4-6 hours.
    – selene
    Aug 26 at 18:54
  • 3
    I just dug through the reference manual and the setting of 180 kHz sampling rate is the "desired value - the software will select the nearest achievable sample rate based on hardware limitiations and use that rate" which is why it ends up oscillating just around 180260 Hz.
    – selene
    Aug 26 at 19:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.