The photograph of a Sprague's pipit already contains a relationship that the radio signal will never describe. A researcher knows which physical nanotag is being attached to which animal, at what place and time. Those facts enter Motus as a tag deployment. Hours or weeks later, a distant receiver may hear only a repeating radio signature.[5][12][13]

That separation gives a Motus detection an unusual life. The radio event is historical, but its assigned animal can remain provisional. A corrected deployment date can make an old signal appear in a project's results; a better candidate can replace an earlier assignment; a false-positive flag can remove a run from public summaries while leaving it available to analysts.[6][7]

Motus is therefore an ecosystem for distributed identity resolution. Tag manufacturers allocate radio patterns. Tagging teams register transmitters and describe deployments. Station hosts maintain receivers and time-bounded station records. Motus processing reconciles pulses with the tags considered active. Researchers then work from read models designed for different audiences: the public explorer and the open motus R package.[1][4][5][8]

The key shared object is not a plotted line. It is a revisable relationship among a radio signature, a tag deployment, a receiver deployment and a processing run.

The network has several kinds of name

Motus avoids asking one identifier to do every job. A physical transmitter may be reused in separate deployments. A receiver may move between installations. A sequence of hits needs a processing identity, and an unresolved sequence needs a way to retain several candidate tags. The resulting namespace is the practical map of the ecosystem:

These names meet in the package's SQLite-backed project data. The cleaning guide explicitly warns that motusTagID alone is insufficient when a tag has been deployed more than once; tagDeployID identifies the particular use. The same data expose receiver-deployment fields, runID, run length and ambigID, so an analyst can preserve the joins instead of reducing every observation to species, latitude and time.[9]

This is also why the cover image matters. “Sprague's pipit” is neither a pulse property nor a receiver inference. It comes from the deployment relationship created while the bird and transmitter are together.[5][12][13]

SensorGnome preserves the observation context

A SensorGnome station gives the later reconciliation process something concrete to work with. The current guide describes a Raspberry Pi running SensorGnome software, USB software-defined radios connected to antennas, GPS, power, storage and a weather-resistant enclosure. The V2 software supports several Raspberry Pi generations and a commercial SensorStation. A networked station can upload automatically; an offline installation requires retrieval.[2][3]

For Lotek tags, the receiver records individual pulses rather than deciding which bird produced them. It also records the operational context needed downstream: time, radio input and logs from the device that heard them. Motus's processing route then applies tagfinder to those pulse data. CTT tags take a different route because their digitally encoded transmissions are decoded through CTT infrastructure before reaching Motus.[1][4]

The physical station and its database deployment must stay synchronized. A receiver serial identifies the box, while recvDeployID supplies the period, coordinates and field configuration relevant to a detection. Move the box, replace an antenna, rotate a directional array or correct an installation interval, and the receiver history needs another accurate chapter. Otherwise a perfectly preserved pulse can inherit the wrong place or station context.

SensorGnome's setup checklist is correspondingly end to end: verify GPS, radios and ports; test with a known tag; check upload; associate the receiver with the correct Motus deployment; and confirm the processed result.[2] A station heartbeat and a test transmission answer different questions. The heartbeat shows that the computer reported. The test tag exercises antenna, cable, radio, timing, storage, upload and processing as one route.

That route also explains why an empty result needs operational history. The animal may have passed beyond the antenna pattern. The station may have lost power, filled its storage, suffered a cable fault, accumulated radio noise or delayed its upload. Antenna direction, tag height, terrain, vegetation and flight behavior all change reception. The foundational Motus paper reports favorable cases in which multiple stations heard a tag from more than 20 kilometres away and gives roughly 15 kilometres as a useful indication for a directional nine-element Yagi, not a universal footprint.[10]

Tagfinder performs a temporal join

Lotek identity is assembled from timing. Four on-off-keyed pulses form a burst; the intervals among those pulses encode the Lotek tag ID. The spacing between successive bursts contributes the Motus identity, which is why at least two bursts are needed even though processing may tolerate skipped bursts. Matching also occurs on the tag's nominal transmit frequency.[1][9]

In compact form, the candidate search is:

nominal frequency + Lotek tag ID + burst interval + active deployment window

The last term comes from people, not radio. Motus's metadata register tells tagfinder which tags are expected to be active when a receiver's pulses were recorded. Required deployment fields include the activation and attachment time, species, release coordinates and a band or ring number when available. Expected lifespan and deployment dates help determine the active window; placeholder deployments keep unused codes from being reissued prematurely.[5]

This makes field metadata executable. A late start date can exclude the correct tag from tagfinder's candidate set. A tag left incorrectly active can compete with a reused pattern. If two physical tags with the same nominal frequency, Lotek tag ID and burst interval are active at the same time, the detection is ambiguous. The package can associate such detections with an ambigID and several candidate motusTagID values, but the waveform has no hidden species field with which to settle the choice.[5][9]

CTT tags illustrate that this behavior belongs to a specific radio design rather than to wildlife telemetry in general. They use frequency-shift keying and can encode a 32-bit identifier in one transmission. Their identifier space and processing route differ from the Lotek timing scheme, even when the resulting detections eventually share Motus interfaces.[1][4]

Reprocessing reconciles an old observation with a new registry

Motus reruns receiver data because the candidate registry changes after first upload. Reprocessing occurs at the receiver level, not only for the tagging project that corrected a record, and there is no fixed rerun schedule. That collaborative scope is important: one receiver may hold signals from many projects, while one project's tags may appear at many independently operated receivers.[6][10]

The documentation distinguishes three user-visible changes. First, a missing detection can appear when corrected metadata adds the right active candidate. Second, a detection assigned to a merely plausible tag can switch when a better candidate becomes available. Third, a detection later identified as noise or aliasing can disappear from public summaries after it is flagged; this last case is adjacent to rerunning but is a filtering action rather than a new radio match.[6][7]

In all three cases, the receiver did not rewrite its night in the field. What changed was the relationship attached to the recorded pulses. That is why a Motus result should carry a reconciliation state: extraction date, latest known receiver rerun, tag- and receiver-deployment tables, package version, analysis code and any later corrections the researchers chose to incorporate.

A paper can reasonably use the most current data available at analysis time. Reproducibility requires preserving that particular extract as well. Otherwise “download the latest data” asks a future reader to reproduce a moving registry rather than the result that supported the original conclusion.

The explorer and the R package are different read models

Motus serves at least two legitimate audiences. The public explorer needs a clear, responsive account of stations and movements. It applies broad presentation filters, including rules that hide many short runs and flagged false detections. The project warns that these filters trade errors in both directions: some genuine detections can be hidden and some false ones can survive.[7]

The GPL-3.0 motus R package serves researchers who need the fuller record. It retrieves project data into a local database and exposes runs hidden from public views along with fields such as runID, runLen, motusFilter, ambigID, signal strength, frequency offset, tag deployment and receiver deployment. Those fields support a reviewable decision about which detections enter a particular analysis.[7][8][9]

Calling these interfaces different read models is more precise than treating one as a polished version of the other. The explorer is optimized for communication across a large collaboration. The package is optimized for inspection and analysis. A public track can change after a flag or rerun, while a retained package extract can show exactly which run and identity relation an analyst used.

The package guide recommends a sequence grounded in those identifiers: check receiver names and coordinates, examine run lengths and timing, inspect network flags, identify ambiguous tags, compare detections with plausible movement, and keep excluded rows available for contextual review.[9] A short run during heavy interference and the same run at a quiet station need not receive identical treatment. The analysis rule and its exceptions belong beside the extract.

Fine-scale position requires another receiver geometry

The namespace also prevents a subtle spatial mistake. recvDeployLat and recvDeployLon describe the receiver deployment. They are not estimated coordinates of the animal. A detection means that a signal reached an antenna whose response varies with direction, height, obstruction, noise and tag orientation.[9][10]

Fine-scale localization can be built on automated radio telemetry, but it adds a dense, calibrated array and an explicit model. An independent 2022 study tested signal-strength localization and found that receiver spacing, node geometry and analytical filters materially changed accuracy. Its strongest filter combinations produced median errors between 28 and 73 metres across tested configurations.[11] Those results describe engineered local arrays, not a default precision attached to every continental-network hit.

The practical data-model rule is simple: keep the station coordinate and any modeled animal coordinate in separate fields with separate methods. The first belongs to recvDeployID; the second belongs to a particular receiver geometry, calibration and estimator. This distinction lets Motus support both broad movement studies and specialized local arrays without forcing them into the same spatial claim.

Identity has stewards as well as maintainers

Open source covers important endpoints of this ecosystem. SensorGnome makes a field receiver inspectable and adaptable. The motus package makes retrieval and analytical filtering scriptable. Between them sits a mixed network: commercial tags and some commercial receivers, manufacturer-specific processing routes, a central Motus registry and database, and field installations maintained by many organizations.[3][4][8]

The responsibilities follow the names. The tagging project registers the transmitter and maintains each tagDeployID, including animal, place and time. The station project maintains the receiver, antenna configuration, operating record and recvDeployID. Motus processing runs tagfinder, records reruns and publishes the shared detection products. The analyst pins an extract, reviews runID, motusFilter and ambigID, and documents any extra exclusions. Manufacturers and receiver builders keep the radio specifications and hardware interoperable with the relevant route.[2][4][5][9]

This division of labor is what makes a continental collaboration possible: a receiver maintained by one group can hear a tag deployed by another. It is also the main adoption cost. Building a SensorGnome does not supply safe attachment protocols, permits, animal-welfare review, reliable hosts, travel for maintenance, clean deployment metadata or a researcher prepared to inspect ambiguity.

Pilot the reconciliation, not only the reception

A useful pilot should deliberately test the identifiers and return paths on a test deployment, without introducing duplicate live codes. Register a known test tag, bench-test it, install one receiver with documented antenna bearings and a valid receiver deployment, verify GPS and upload, and confirm that tagfinder produces the expected motusTagID and runID. Then retrieve the project with the R package and join that run to its tagDeployID and recvDeployID.[2][5][9]

Next, rehearse controlled corrections. In a test record, amend an inaccurate deployment time or receiver interval and compare extracts before and after the next receiver rerun. Use an existing sample or known ambiguous case to practice ambigID review rather than transmitting a conflicting code. Retain both extracts and write a compact reconciliation note: which metadata changed, which candidate set changed, which run moved or appeared, and which biological conclusions were affected.[6][9]

The pilot is ready to expand when the team can explain a detection from both directions. Starting with the field event, it can find the receiver deployment, processing run, candidate tag and animal deployment. Starting with a published result, it can recover the exact data snapshot, filters and rerun state. It can also detect a station outage before turning a blank table into a movement story.

Motus hears a reusable radio pattern before it knows which bird passed. The ecosystem's achievement is to keep the later act of naming explicit: a time-bounded relation among transmitter, animal, receiver and run, maintained by several organizations and open to reconciliation when better metadata arrives.

Sources

1. Motus Wildlife Tracking System, “How Tags Work” — Lotek pulse and burst timing, CTT frequency-shift encoding, raw receiver pulses, identity constraints and timing tolerance.
2. SensorGnome User Guide, “Introduction and Overview” — V2 receiver components, supported computers, logs, network behavior and the end-to-end deployment checklist.
3. Motus Wildlife Tracking System, “Receivers” — compatible receiver families and SensorGnome's open-source hardware and software status.
4. Motus Wildlife Tracking System, “How Data are Processed” — receiver- and tag-specific routing, Lotek pulse processing, tagfinder, CTT processing and public-versus-package data paths.
5. Motus Wildlife Tracking System, “Tag Metadata” — required deployment fields, active-candidate selection, tag-code reuse and ambiguity caused by missing or overlapping records.
6. Motus Wildlife Tracking System, “Reprocessing receiver data” — why metadata corrections can add, remove or reassign detections.
7. Motus Wildlife Tracking System, “Public Data Filters” — short-run and manual filters, website-only presentation filters, false-positive tradeoffs and the fuller R-package record.
8. MotusWTS, motus — GPL-3.0 source repository for the R package that retrieves and handles Motus radio-telemetry data.
9. MotusWTS, “Chapter 5 — Data Cleaning” — SQLite-backed project data, alltags, run and ambiguity fields, receiver checks, exclusions and contextual review.
10. Philip D. Taylor et al., “The Motus Wildlife Tracking System: a collaborative research network to enhance the understanding of wildlife movement,” Avian Conservation and Ecology 12(1), 2017 — system design, receiver geometry, range limits, shared infrastructure and research boundaries.
11. Kristina L. Paxton et al., “Optimizing trilateration estimates for tracking fine-scale movement of wildlife using automated radio telemetry networks,” Ecology and Evolution 12(2), 2022 — independent tests of signal-strength filters, receiver geometry and localization accuracy.
12. U.S. Fish and Wildlife Service, “Motus Stations” — field context identifying the photographed Sprague's pipit and its attached Motus nanotag.
13. U.S. Fish and Wildlife Service, “Sprague's Pipit by Smithsonian's National Zoo & Conservation Biology Institute” — photograph source, credit, date and usage-rights record.