19 Jun How to Apply Clock Corrections to Your Data for GPE3
Setting your tags to the proper UTC time is important to ensure that your data are properly decoded and utilized in GPE3. GPE3 works to match tag derived light curves with theoretical light curves based on astronomical equations. If your tag is set properly at the time of programming to the correct UTC time, relatively minor clock drifts of one minute or less are not likely to have perceptible effects on your model outputs. However, if the recorded times of the tag derived light curves are off, that can result in GPE3 wanting to fit curves that are shifted in longitude away from the true tag location. For every minute of clock error, you move 0.25 degrees in longitude away from the true location. If you forgot to account for daylight savings time and programmed your tag off by one hour, for example, you can expect errors of 15 degrees in longitude if using light data alone! Setting tags to local time, if you are several hours away from Greenwich, could result in even larger errors. GPE3 does use other data to estimate locations, including known locations, depth and surface temperature, so the estimates may not be as far off as they would be if the light data were the only observations, nevertheless, the model will fail to properly utilize the light data if there are time offsets.
Once in the Wildlife Computers Data Portal, you can apply clock corrections to ensure that the proper UTC times are associated with your light curves. In order for the clock offsets to be properly corrected in GPE3, there needs to be a pair of offsets identified in the metadata at the start and end of the deployment. You may also have other clock offsets during the deployment if your tag sent status messages while underway. The algorithm corrects the clock assuming a linear shift between the times when there are clock offsets.
Clock offsets prior to deployment can be derived from your setup file, or, if you have conducted an Argos Transmitter Test prior to deployment, a clock offset may appear in the metadata from a Status message. Clock offsets at the end of the deployment can be derived from the .wch file generated at the time of download, or from Argos transmissions made at the end of the deployment.
If a clock offset (even if it is supposed to be zero) is not shown for the start of the deployment, then you will need to manually enter a clock offset in the metadata. If you have programmed your tag with Tag Agent while connected to the internet, and have reset the tag’s clock to UTC internet time when prompted, then the starting clock offset will be zero. Below are a couple of examples showing what you may see when the clock was correct at deployment, and one that was set to local time at deployment (in this case UTC – 10h). For these tags, clock corrections were manually entered for the start of the deployments.
As always, if you have any questions, please do not hesitate to contact us at tags@wildlifecomputers.com or support@wildlifecomputers.com.
Suzy Kohin joined Wildlife Computers in June 2018. Kohin holds a bachelor’s degree in Math and French from Washington University in St. Louis and a Ph.D. in Biology from UC Santa Cruz. Kohin’s research includes analyzing and applying electronic tagging data to questions regarding habitat-use, foraging ecology, population structure, survivorship, and fisheries management. At Wildlife Computers, Kohin interacts with researchers about their needs and helps investigate novel ways that tagging technologies can advance science and conservation efforts. Suzy has published extensively in fisheries, quantitative ecology, and physiology. You can find a full list of her publications here.