Issues with false detections

Analysis and Data
1

Hi,
Thanks for accepting me in the group. I hope this is the right platform for asking this…if not, my apologies.
I’m analysing bird detection data from fixed receiver stations that use Lotek SRX1200 data loggers. We are facing the issue of false detections of ‘fake’ and real tag ID’s, which might be due to a ‘noisy’ environment with other radio signals, e.g. due to aircraft.
Has anyone had similar problems, and do you have experience with how to deal with these false detections, other than reducing the gain, which significantly reduces the detection range?
We get occasional detections for any numbers between 1-999, usually just on some days, with 1-2 detections (but sometimes more, up to 20-30) in a day for several different numbers. This is not a problem for numbers (‘tag ID’s’) we know don’t exist in our system, but becomes problematic when it happens with actual tag ID numbers. We’re doing a study where we try to detect birds that are migrating past the receivers, so they might only get detected a few times anyway before flying out of range, which makes distinguishing real detections from false detections very tricky.
I’d be grateful for advice.

I’ll attach an example. None of these tag ID’s (1-10) are real tags worn by birds. In March the gain was set to 85 for one antenna and 90 for the other. In April, the gain for both was reduced to 80.

Thank you!

pic of false detections.png
pic of false detections.png752×93 4.86 KB

2

We definitely have this problem from the ‘tag’ end; I get detections of Common Nighthawks that are clearly TRUE, detections that are clearly FALSE, single detections in plausible locations that I cannot distinguish whether they’re true or false, and single detections in locations that are implausible (but not impossible). It all keeps me scratching my head.
Kristina

3

Hi Johanne and Kristina,

single false positives are common and to be expected, particularly in environments where there is radio interference.

This topic is covered in the Motus R Book: https://motuswts.github.io/motus/articles/05-data-cleaning.html

The most reliable way to exclude false positives is to rely on the concept of runs (i.e. consecutive series of detections of the same tag that match the exact period between 2 radio bursts). Lotek tag identification relies both the code ID (e.g. 123) and the period between bursts (or burst interval), and single bursts are generally not considered safe for use as they have a much higher risk of being false positive, and may also be tags from other projects. The minimum number of consecutive bursts in a run that you should use depends on various things, such as the amount of radio noise around the time of the detection. Runs of 2 hits also have a relatively high rate of false positives, and this should decrease as the runs become longer. We generally don’t recommend relying on runs of length 2. In noisier environments, the minimum level to consider safely could increase to 4 or 5.

Once you download your data from the Motus R package, it will come with the runID identifiers that allow you to assess the quality of the data, which is explained in the link above.

Note that runs are only created when the period between bursts match exact the expected period (e.g. 5.30 seconds), plus or minus a small error allowance, but runs do allow a certain number of missed bursts during a run (e.g. 10.6 or 15.9 seconds), up to about 20 missed bursts before a new run is initiated. Runs are also detections of the same tag on the same antenna, not across the receiver.

There are other properties of the detections that can help users also triage real and false detections. For instance, if you have many gaps (missed bursts) during a run, it could be associated with a lower probability of being valid. Three bursts in a run detected over a period a 3 minutes for instance should be regarded as potentially less reliable than a run with 3 consecutive detections (e.g. within 10.6 seconds).

The algorithm that chains the single detections into runs also consider other factors such as the amount of variation in the signal strength during a burst, etc. but those generally are less applicable to data collected with Lotek SRX receivers, as the tag identification happens on the unit itself, and the run processing is done in the Motus server.

Changing the gain settings or moving your antennas to reduce interference are also ways to potentially reduce false positives at the source, but this is something that others likely have a much better handle on than I have.

I hope this helps!

Denis

image002.png

1 Like
4

Hej,

Thanks Denis, this is a really good explanation on the problem and good advice on how to reduce the number of false positives. But I think it is fair to acknowledge that even after doing all this and even with rather high thresholds (>5 hits), you will almost always still have some detections that are either clearly false or that are highly implausible. That is a problem we will probably never be able to fully eliminate when working with Motus data. This is something that I think every Motus user should be aware of: some false positives will always remain.

Best wishes

Arne Hegemann,

Lund University, Sweden

image002.png

1 Like
5

Hi all,

For the tags that I’ve been tracking, I’ve found that the freqsd seems like a fairly reliable way to distinguish between real and false detections. As Arne mentioned above, there is no way (that I am aware of) to be absolutely certain if a hit was real without being there and seeing the bird fly by, but probably ~95% of the hits that I was suspicious of had a freqsd > 0.1 and very few of the hits that I trust have a freqsd > 0.1. What I ended up doing was looking at daily proportions, for individual tags at individual receivers, of hits that failed that freqsd filter (freqsd > 0.1), and I removed anything with more than 25% of hits failing in a given day. That was helpful because there were some towers that had good hits at some times and suspicious hits at other times. That threshold might be different for you and your tags though - I found it helpful to plot everything out and compare hits that I trusted with those that I didn’t.

I also removed runs of 2, for the reasons that Denis mentioned above, but I did keep runs of 3+ if the freqsd was ok (the burst interval on my tags was quite long so that increased the likelihood of having shorter runs if the bird was flying by). There were some towers though (and one tag) that I did not trust at all so I was more strict with those hits.

Cheers, Sarah

6

Dear all,

Thanks so much for your very helpful responses, it is much appreciated! It’s reassuring to know that false detections are a common problem at least…
Sarah, where do I find the freqsd value please? I don’t think that this shows up on my .CSV exports from the loggers…

Many thanks,
Johanne

7

FredSD is provided in the hits table of the data available from the Motus r package. I don't think it is provided with SRX receivers however, but I may remember incorrectly.

It measures the standard deviation of the frequency of the 4 individual pulses for each detection. If the detection is from a real tag, you would expect all pulses to have very similar frequency (and signal strength). If this is a false positive, you are more likely to have pulses from different sources that mimick a tag, so they will be more variable.

With sensor gnomes, those that have too large SD are not considered as valid hits, and don't make it to the data. There's no magic number though to separate real and false detections, so we provide users with more detections than less, on the assumption that it is better to have more false positives than miss too many real detections.

We have various ideas to apply more filtering flags with the data, but there are many things to consider, so these are complex models to automate at the moment and relies on users to examine their data. That will probably never completely go away, to be honest, but I think there are achievable steps that could help.

Another common issue to watch for are called tag aliases. Basically when the signal from 2 or more tags overlap in time and create the appearance of a different tag. If you have several animals at the same time around a receiver, and especially tags with the same period that overlap over multiple bursts, you will likely see false positives. Colonial and roosting birds would be a more extreme example of this.

In those situations, using tags with longer periods and different periods between them, would be highly advisable to reduce the occurrence of overlapping signals.

Denis Lepage, PhD dlepage@birdscanada.org

Senior Director, Data Science and Technology | Directeur principal – Science des données et technologie

[cid:storage_emulated_0__EmailTempImage_2_TempSignature_signature_BirdsCanada-logo-en-176x89-1_0_png_1682879741868] Birds Canada | Oiseaux Canada birdscanada.org | oiseauxcanada.org

signature_BirdsCanada-logo-en-176x89-1_0.png