synchronizing sgdata and motus reference tables

[denislepage]

I don't think this is currently in place, but can we have the sgdata server use Motus as it's source for things like tag models? That table appears currently in sync between sgdata and Motus (according to this https://sensorgnome.org/VHF_Tag_Registration), but new tag models will undoubtedly be added.

Having a single master list in Motus from which SGdata acquires its copy would be desirable, so we only need to maintain a single list. That would require a new API entry in Motus, and a process to refresh the metadata for that table. We may need to add some extra properties in our table as well(?).

There may be a few other tables in the same situation (receiver model, etc.), but there may be other places in the code that would need to be modified if we were to add new values?

Let us know if that is possible, and if not, what are the complications.

[jbrzusto]

I'll add entries to the status API to query and update the list of tag models and to supply new lifespan data, which are used to estimate active tag lifetime.

[denislepage]

I'd prefer not to have to maintain the list of tags on sgdata or other locations outside the Motus database. If we set up a Motus API entry that gives you the tag models and details needed, can you set up a process to add new tags to your tables as part of your daily metadata updates?

We already have replicated much of the same properties that you need in our database, so we'd just need to know which properties you need from us for each tag model.

[jbrzusto]

I would need label and modelled lifespan. Do you have the latter?

[denislepage]

Catherine has implemented the same calculations and parameters you had documented for lifespan, and these are now integrated into the database, so would be easy to provide through the API.

For each tag model, we store D and rt, and a buffer (1.5).

For any given tag with a known dutyCycle and period, we calculate lifespan as follow:

SELECT @lifespan = (D / (1 + (rt @dutyCycle)/@period)) lifespan_buffer FROM lk_tag_models WHERE model = @model

These are the values we have at the moment, and which we can provide through an API. Do you need anything more? We have a few more properties (dimensions and weight, etc.).

Alternatively, we could provide the modeled lifespan with each tag based on the above formula.

model D rt ACT-393 1839.75736 24.27907 ACT-521 304.1473 20.0563 ACT-626 608.29454 20.0563 ANTC-M1-1 72.77200013 12.2528759 ANTC-M2-1 114.7255953 12.24443758 ANTC-M3-2 271.5543067 11.93482379 ANTC-M4-2 546.9617011 11.79558399 ANTC-M4-2L 546.9617011 11.79558399 ANTC-M4-2S 546.9617011 11.79558399 ANTC-M6-1 775.5279688 11.71992407 ANTC-M6-2 1469.035276 11.66201256 ANTCW-M1-1 72.77200013 12.2528759 ANTCW-M2-1 114.7255953 12.24443758 ANTCW-M3-2 271.5543067 11.93482379 ANTCW-M4-2 546.9617011 11.79558399 ANTCW-M4-2L 546.9617011 11.79558399 ANTCW-M4-2S 546.9617011 11.79558399 ANTCW-M6-1 775.5279688 11.71992407 ANTCW-M6-2 1469.035276 11.66201256 NTQB-1 72.77200013 12.2528759 NTQB-1-LW 48.51466676 12.2528759 NTQB-2 114.7255953 12.24443758 NTQB-3-2 271.5543067 11.93482379 NTQB-4-2 546.9617011 11.79558399 NTQB-6-1 775.5279688 11.71992407 NTQB-6-2 1469.035276 11.66201256 NTQBW-2 114.7255953 12.24443758 NTQBW-3-2 271.5543067 11.93482379 NTQBW-4-2 546.9617011 11.79558399 NTQBW-6-2 1469.035276 11.66201256

[jbrzusto]

So how are you handling the situation where you get a new tag model and new lifespan data for it from Lotek?

[denislepage]

I'm not sure I understand your question. How do we get the D and rt values you mean?

Is there anything not already outlined in this document: https://github.com/jbrzusto/motusServer/blob/94eccd9a113a5f4762554d3d06f8f4c0e9da6df5/inst/doc/modelLotekTagLifeSpan.Rmd

My original intent was to provide you whatever table you need to generate the calculations on your end, which I understood to be the table above with model, D and RT.

If a new tag model is added, we need to generate those properties, store them in our database and they become available to the tag finder through our API.

In addition to the lifespans, we'd also need to make sure that those new tags can be registered and processed.

[jbrzusto]

Okay, there are two places where motusServer uses this information:

• when building the events table of tag activation / death for the tag finder. This table is built daily when the motus metadata are refreshed.

• when processing a tag registration, it checks the user-supplied tag model against a list. I could just drop that test and pass the model along to you as supplied, so that a tag could be registered with a new model without waiting the up to 24 hours for the next metadata refresh.

So if you supply the model, D, rt table above via an API call, I can just use that. But it means someone at motus.org is going to have to run something equivalent to the modelling code in modelLotekTagLifeSpan.Rmd for estimating D and rt for a new tag model if it uses a new battery type or has a different power consumption profile as indicated by Lotek-supplied performance data.

The alternative is for me to incorporate the modelling code into an API entry on my end which you call to provide a new tag model name and possibly new battery/power data.

[denislepage]

Given the time you have left, let’s put this aside.

I think it is likely that we will replicate the process at our end to do the necessary calculations for new tag models, but I don’t think we’re going to resolve this in the coming 2 weeks.

If you have an outline of the steps we would need to take to add new tag models and properties into the tag finder, that would be helpful.

Are the properties for tag models used by tag finder stored in MariaDB or someplace else?