jbrzusto / find_tags

search raw data streams for patterns from registered tags
GNU General Public License v2.0
2 stars 0 forks source link

tag deactivation events not (always?) working? #23

Closed jbrzusto closed 7 years ago

jbrzusto commented 7 years ago

e.g.

SG-0816BBBK0268 boot session 10 is finding tag M.18303 on 14 April 2017, well after its deactivation event (in the events database) on Sat Sep 10 13:46:53 GMT 2016

The detection is really of a physically identical tag M.23072 whose dateBin gives it the effective deployment date: 1 Jan 2017 (also in the events table).

So is this because the second tag doesn't have a ".1" suffix on its mfgID? (and the second, while serving to activate the first, is not being added to the database with its correct motusID?)

jbrzusto commented 7 years ago

Example

The tag database:

tagID mfgID period
14750 44.1 12.6950
20380 44 12.6954
22152 44 10.2952
23297 044 12.6952

and their events:

ts tagID event
2016-04-09 12:05:00 14750 1
2016-06-30 12:16:00 20380 1
2016-07-06 02:27:07 14750 0
2016-10-01 00:00:00 22152 1
2017-01-26 11:11:02 20380 0
2017-04-01 00:00:00 23297 1
2017-04-07 15:27:15 22152 0
2017-06-27 14:23:05 23297 0

when run like so:

find_tags_motus --pulses_to_confirm=8 --frequency_slop=0.5 --min_dfreq=0 --max_dfreq=12 
   --pulse_slop=1.5 --burst_slop=4 --burst_slop_expansion=1 --use_events --max_skipped_bursts=20 
   --default_freq=166.376 --bootnum=10  ./testtags1.sqlite --src_sqlite  /sgm/recv
   /SG-0816BBBK0268.motus

Gives the plots below

issue_23_graph.pdf

This shows the problem is the removal of tag 20380 from the graph (which occurs between the 4th and 5th plots) is incomplete.

jbrzusto commented 7 years ago

Here's the causal sequence:

All of which begs the question why removal of a tag should care about edge labels. It shouldn't. Why did I model removal so closely on addition? Fix: just delete nodes and edges based on presence of specified tag in the node's TagPhase set.