Improve speed calculations to take into account receiver detection range

[hugomflavio]

When arrays are close together, the receiver range can heavily influence the real distance that the animals traveled. This, in turn, affects the calculated speed, and can generate unnecessary speed warnings. Taking into account the receiver range when calculating speeds would fix this.

Addressing this will pave the way to fix YuriNiella/RSP#12 .

[hugomflavio]

Some important points from the discussion with Devon:

Objective 1: Provide a range column for each deployment

Objective 2: Provide range as a new input, of format receiver, timestamp, range. This could work nicely with both manual range testing logs and also with the output of range test estimators.

this function checks the speeds in actel, but it doesn't actually calculate them:

actel/R/check.R

Line 443 in d7f157c

checkSpeeds <- function(movements, tag, detections, valid.movements,

this is the one responsible for most of speed calculations work:

actel/R/movements.R

Line 182 in d7f157c

movementSpeeds <- function(movements, speed.method, dist.mat) {

and then there's this one to well, do what it says it does:

actel/R/movements.R

Line 286 in d7f157c

speedReleaseToFirst <- function(tag, bio, movements, dist.mat, speed.method){

If range is going to be incorporated into the speed calculations, then these need to be changed.

we'd probably want to split the speed column into two: a minimum and a maximum speed

where the max speed uses the receiver distance + both ranges
and the min speed uses the receiver distance - both ranges
and if the distance - both ranges is <0, then the fish could have not moved
so the min speed in that case is 0

[hugomflavio]

Some more updates following a discussion with @jdpye

Range is not just a function of the receiver and time, but also of the tag type used, and whether it was set to high or low power. Even so, our road map here is sound (start simple, build in complexity later).

This means that ultimately, we may want to add a third objective, where the ranges input has a few more columns:
receiver, tag, power, timestamp, range

This format raises questions of what should be done when the tag we're detecting is not the one that was used for the range testing (or is not on the same power setting). However, I think this is something we can think of far ahead in the future.

This is also where someone else who actually wants to do this can step in and help out :)