Closed jbrzusto closed 7 years ago
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
This shows the problem is the removal of tag 20380 from the graph (which occurs between the 4th and 5th plots) is incomplete.
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.
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?)