Metadata informs Motus when to look for tags in raw detection data, when tag codes can be reissued, helps ensure that the permanent data archive is accurate and complete, and makes data presentable to the public.
All tags used with Motus must first be registered.
The table below outlines the minimum requirements for tag metadata to acquire detections from Motus.
Name | Importance | Description |
---|---|---|
To ensure the most accurate detection data, please enter your updated tag metadata as soon as possible, and allow 24 hours before uploading your receiver detection data after submitting tag metadata.
Do not enter a deployment end date unless the tag was actually recovered and deactivated. Otherwise, Motus will automatically calculate the end date of the tag using a generous buffer in case the tag lasts longer than anticipated.
If you do you end up not deploying tags and holding on to them for future use, create a placeholder deployment record with a start date well in the future to ensure that the tag code / burst interval combo is not reissued.
Metadata is a critical part of the Motus infrastructure. Not only does it inform our algorithms which search for tag detections on when to look for specific tags, it also helps make sense of data that are presented to the public. As the Motus community grows, the importance of accurate and up to date metadata grows exponentially.
Motus stations receive radio signals from Lotek radio transmitters (i.e.; tags attached to animals) as a series of pulses that are all on the same frequency. It's the specific timing between these radio pulses that encodes the ID number of these tags (see How Tags Work). We decode Lotek tags from radio signals ourselves using a complex algorithm called tag finder. This algorithm takes into account the possibility of multiple tags being present and emitting a signal at the same time.
To improve the performance and accuracy of tag finder, Motus only search for tags that are known to be active at any given time. To accomplish this, tag finder references a master list of all registered tags along with the dates when they were active (‘deployments’). Occasionally, some tag detections are missed because _tag finder _doesn't know that certain tags are active, usually because of missing or inaccurate metadata in our system.
Most tags are deployed on animals and never seen again, so most tag deployments will have a start date, but no end date. This is the correct way to enter deployment metadata if a tag is not retrieved again after deployment as it allows our system to calculate the end date on its own. This end date is calculated as the predicted lifespan (provided to us by the manufacturer) plus an additional 50% to account for unusually long-lasting tags. This predicted lifespan is calculated based on the tag model number, so it’s important to ensure that information is correct as well. The examples below use a theoretical tag with a predicted lifespan of 60 days.
In reality, it’s impractical to enter tag deployment metadata immediately upon releasing each animal, so we have built in a couple safe guards to help mitigate this issue. The first is that tags will be searched for by Motus immediately upon registration if no deployment exists for those tags. The registration date has historically been recorded as the quarter-annum, so tag finder will act as though each tag was deployed on the first day of that quarter-annum. Not desirable, but better than nothing.
Default deployment dates are only present as a backup in case the researcher has forgotten to include their earliest anticipated start date during tag registration. An anticipated start date is basically the earliest day on which the researcher plans to deploy tags. This should provide ample time to update the tag metadata after the field season is over.
Once a tag has been deployed, it's deployment metadata should be updated to reflect the real deployment date. Otherwise, tag finder might think the tag expired too early.
Remember: providing an anticipated deployment date will buy you more time before you need to update these data.
Because of the limited number of tag code / burst interval combinations, tags with these properties may be reissued to other projects if the tags are presumed to be dead or inactive. Tags that were not deployed during the expected tagging period should be given placeholder deployment recorders well into the future. This will ensure that they remain on the "active tags" list and are not reissued.
Example: You had 20 tags you expected to deploy in June 2023 and for which you made placeholder deployment record with anticipated start dates (as described above). However you were only able to deploy 18 of the tags and want to retain the remaining two tags for next year. You would modify the deployment record for the two undeployed tags and change the start date to some date in the future -- say July 1, 2024. This will ensure that the tag codes will not be reissued to another project. After you do finally deploy them, update the tag deployment metadata to reflect the actual deployments.
Undeployed tags should:
1) be stored in correct conditions. See Tag Storage for more information
2) be given placeholder deployments with start dates well into the future to ensure that the unique code/burst interval combo is not reissued
Bad metadata to be information related to deployments which is either missing or inaccurate. We can use the example scenario above to predict what might happen when metadata isn't kept up to date.
If there is no deployment data for a tag, tag finder will assume the tag has expired and will stop searching for it long before it should. In our example, the default deployment period has no overlap with the actual active period, meaning it will only search for the tag before it was actually ever deployed. Therefore, no detections would exist for this tag.
If only an anticipated deployment date exists, there may be some overlap with the actual deployment period, but there could still be a lot of data missing from the end of the tag lifespan.
If there are left over tags after the field season or if a tag is recovered and the existing deployments aren't terminated, manufacturers might reissue the tags which can result in ambiguous detections. That means there could be two tags deployed at the same time that appear identical to each other deployed at the same time, making it difficult or impossible to accurately identify the individual.
Deployment start date and time
Required
The time when the tag was activated and attached to an animal
Species
Required
The species the tag was attached to. For tests, please do not enter a species and check the 'test deployment' box.
Latitude and longitude
Required
The location where the animal was released with the tag attached and activated
Federal band (ring) number
Required (when available)
The band number or ring number of the bird or bat. Insect tag numbers are optional.
Other measurements
Recommended
Any additional measurements of the tagged animal, such as weight, age, and sex, should also be included.
Tags are the eyes and ears of Motus. Without them, we wouldn't have any data to speak of. Similarly, without accurate metadata we won't be able to make sense of the data we collect.
This chapter is in development
This section pertains to the management of tag metadata: i.e., the registration of tags and their deployments. To learn more about tags models and how to deploy them, see our chapter on tags:
In this chapter you will find:
Tags are the individual radio transmitters compatible with Motus which are manufactured by either CTT or Lotek. They each have a digitally encoded ID (manufacturer ID), a burst rate (a.k.a., 'burst interval' or 'period'), and a model.
Tag deployments
A deployment is considered to be each instance when a tag was attached to animal and then released. Most tags are never recovered therefore most tags have only one deployment. Tag deployments record all the information regarding the animal that it was attached to, including: date/time of release, location of deployment, species, age, sex, weight, and any other metrics that can be provided.
Every time a Motus tag is deployed, this needs to be recorded in our database, otherwise there may be missing detections. This section covers the following topics:
All tags are automatically registered to your Motus project before shipment, regardless of the manufacturer (CTT or Lotek). However, you must tell the manufacturer the Motus project ID for them to register the tag to the correct project. For more information, see Tag Registration.
A deployment is a single instance where a tag was attached to an animal (or was used in a "tag test"). The deployment begins when the animal is released. The deployment ends either: automatically (Motus calculates when the tag is expected to expire based on the tag model); or manually (when a collaborator recovers the tag from the animal).
Deployments are a necessary way for Motus to efficiently search for tag IDs within radio data. Without tag deployments, data will be missing.
Most Motus tags are never recovered so very few tag deployments should be given an end date.
While tag deployments are necessary for detections to occur, it is impractical to register deployments immediately after each one is deployed. Anticipated deployments are essentially placeholders for real deployments and begin on the earliest date which tags are expected to be deployed.
You must still confirm anticipated deployments after the anticipated date has passed by updating the tag deployment metadata. For more information about anticipated deployments, see Tag Metadata.
Example 1
Laura wants to deploy 50 tags on Bank Swallows in the summer of 2022. She anticipates to be in the field by June 10th, at the earliest. Using the bulk editor, she registers deployments for all 50 tags with a start date of 2022-06-10.
Over the course of the field season, she ends up deploying 47 of her tags and stores 3 of them for later use. Shortly after her field season is complete, she goes back to her Motus project's tag management page to correct the deployment start dates and fill in the rest of the metadata for each of her tags. With the 3 tags that she stored for later use, she removes the start dates and species using the bulk editor.
Tags can be used to test whether a receiver or specific antennas are functioning as expected. However, we don't want these data to be included in analyses of animal movements, nor do we want them presented to the public since it can be confusing. To flag these deployments as tests, check the box reading 'make this a test deployment' while registering your tag deployment and leave the 'Species' field blank.
Multiple tag deployments can be registered and/or modified at once using the tag deployment bulk editor. This can be found by clicking on "Upload tag deployments" under Tag Management. Follow the instructions on the page to upload tag deployments.
Deploying tags without registration is futile – always ensure tags are registered to your Motus project prior to deployment.
All tags used with Motus must first be registered before any data can be acquired from Motus stations.
With some exceptions, all tags purchased from Lotek or CTT are registered automatically to a Motus project upon shipment. This means you must provide the tag manufacturer with your Motus project ID when ordering your tags.
Register with Motus
Create or join a project
Provide the manufacturer (CTT or Lotek) with your project ID when purchasing tags.
Double check that your tags are registered to the correct project before deployment.
In some specific instances, it may be necessary for you to register your tags manually. Only do this if you have been instructed by Motus.
Please do not register tags more than once. If you need tags transferred between projects contact us.
Register with Motus
Register your tags: Instructions on registering tags can be found here. To register a tag, you need to make a short recording of its output using a funcubedongle attached to a PC. Tag Registration Kits can be purchased from Motus. Each kit includes a funcube, whip antenna, and tag activator. We strongly encourage you to test and register all tags immediately after receiving them to ensure they’re ready for deployment. Always check your Manage Tags page after registration to ensure they have all been uploaded correctly.
Upload tag registrations: Send us your completed tag registrations from step 2 here using your Motus login information.
Sometimes bad recordings can result in tag registrations with burst intervals that are an integer multiple of the true burst interval. This is because the recording quality was poor and certain tag bursts were skipped during the registration process.
This issue should be resolved in a timely manner by contacting us with the details including the Motus Tag ID and the true burst interval that should have been recorded.
If this issue is not resolved it will result in missed detections and at least 50% shorter runs.
Your project will be invoiced based on the number of tags registered following the Motus Collaboration Policy and Fee Schedule.
Please contact us if you have any questions regarding tag fees.