12
$\begingroup$

In the past, I used Osprey and I am aware of the script by Malinka et al., 2020. What other methods/scripts/software folks have used and would recommend?

Here's some background on the dataset: I have recordings made with a 4-unit SoundTrap array. Sensors were self-recording independently of each other resulting in 4 independent .wav files. Units were programmed to start recording at the same time but the end of the recording is different for each one due to battery performance differences. The deployment is about 7 days long and we have sounds produced at known times every other day to use as anchors for the time alignment. I am aware that the intervals between these sounds are not ideal and I am aware that the clock drift of SoudTraps can be huge... But I am curious about how folks have been time-aligning.

Thanks!

$\endgroup$
2

2 Answers 2

3
$\begingroup$

Info: Do you have a pinger/synchronization sound that you can use? Without that what you are trying to do will be near impossible to do with accuracy. As good as the Malinka paper is, there is still a ((small)) margin of error because the recordings are not being made with the same sound card.

However, you may be able to get a loose synchronization, which may be OK depending on what signal you want to look at.

Did program your SoundTraps with the same computer, and reset the time? This would give all of your sound traps the similar starting point for their internal clocks. You will need the times of Clock Reset for each individual unit. In this example, I will call this: timeGPSreset

Upon retrieval, using the same computer you used to reset the clocks, note the clock drift of each unit. In this example, I will call these units timeGPSstop (real time) and timeClockstop (ST clock time).

You can then use a linear interpolation to adjust for clock drift. Here is an example of how to do it in Matlab.

    %timeGPSreset -  Should be present for all deployments. This was the
    %time that the unit was synced with a GPS before deployment.
    
    %timeClockstop - Time on the unit when the data was offloaded.
    
    %timeGPSstop - Time according to the GPS or time.is when data was
    %offloaded.
          
    %DT_all - Datetime series you wish to adjust for Clock Drift
    
    %n - length of vectors you would like to interpolate over.

    %Create linear vectors of fixed length to interpolate on.
        timeGPSdiff=datenum(linspace(timeGPSreset,timeGPSstop,n));
        timeClockdiff=datenum(linspace(timeGPSreset,timeClockstop,n));
        %Convert date times to datenum
        DTall_num=datenum(DT_all);
        %Interpolate!
        newDTall=datetime(interp1(timeClockdiff,timeGPSdiff,DTall_num),'ConvertFrom','datenum');

This will give you a loose synchronization, as the timestamps across units will be adjusted for clock drift. It is not exact, however. And you will need to figure out what your margin of error is, as that will need to be included in your subsequent analysis.

If you have a pinger/synchronizing sounds in your recordings that are produced at known/regular times, you can get a much more accurate synchronization. You can adjust the code above to include those timestamps in the interpolation.

$\endgroup$
1
  • $\begingroup$ Hi etgriffiths, thank you so much for your response! For this specific deployment I do not have pingers - I will have them for the next deployment in a few weeks. I agree that the interpolation of the time drift across the whole deployment will be the best solution %for now %. The objective is to loosely localize calls to identify if they come from inside or outside the array area which can be done with amplitude differences in these cases. The code you provided will be very useful! Thanks! $\endgroup$ Commented Jun 30, 2022 at 18:35
-1
$\begingroup$

From your 'localization' tag I assume you wanted to estimate the time delay of sound between the Soundtraps. What I would do is

  • detect the known transmissions on all 4 units
  • if you know location of transmission and recorders, correct for travel time
  • assume that temperature is constant during deployment
  • conclude (assume) that clock drift rate is constant
  • correct timeseries (detections) of all transmissions align

from your post I deduce that you already doing that

$\endgroup$
3
  • 1
    $\begingroup$ Hi WMXZ, thanks for your response. I am fully aware of the workflow, I am looking for alternate methods to conduct the time alignment of the tracks using calibration signals which means I won't have to assume constant clock drift at least when I have calibration info, and therefore, I will have more accurate localization results. $\endgroup$ Commented Jun 26, 2022 at 21:20
  • 1
    $\begingroup$ I effectively answered: "But I am curious about how folks have been time-aligning." $\endgroup$
    – WMXZ
    Commented Jun 28, 2022 at 4:59
  • $\begingroup$ Indeed, and thank you. I am looking for scripts\software that allows for the implementation of the concepts you described. Please share if you are aware of any. $\endgroup$ Commented Jun 28, 2022 at 18:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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