Jump to content
Ornithology Exchange
  • 0
L Halpin

dealing with calibration periods

Question

I am using FLightR (ver.0.4.5) to process light-level data from Migrate Technology GLS deployed on burrow nesting seabirds.  Most GLS were deployed directly on the birds with no calibration period on the island where they nest.
 
However, I kept a subset of different GLS near to the location where GLS were deployed on birds (i.e. within 20 km) in an open location, without artificial light and without any foliage shading, for 1 week.

Of course, we know the location of the burrows, and those coordinates could be used as a calibration location, but the problem is that these birds go long distances (up to several hundred km) between attending their burrow and they only come and go from their burrows during dark hours of the night. The birds are long distance travelers and can be a long way from the colony by the time the sun rises.
 
Therefore, as I see it, light-levels of the device would not correspond well with the actual light levels at the calibration location if I used the colony site as the calibration location.
 
I would appreciate any advice on how best to deal with calibration in FLightR based on this scenario.
 
Cheers,
Luke

Share this post


Link to post
Share on other sites

7 answers to this question

Recommended Posts

  • 0

Luke,

 

Looks like your calibration point was in the wrong hemisphere (positive longitude puts you in far east Russia). Your position should be listed as: CapLocs=c(-127.9704, 50.4475)

 

Jeremy

Share this post


Link to post
Share on other sites
  • 0

Dear Luke,

 

I am also using FlightR to analyze Light Data from Migrate Technology, however I used them on skua and not on burrow nesting seabirds. I am not a modelling expert, but let me share my experience with you. For calibration, I have put all retrieved loggers post deployment in an open space for rooftop calibration. Ideally you have pre and post deployment calibrations, but the post calibration only seems to work fine for me. Ideally, you perform the calibration on each logger that was actually on the bird. However, I have tried using other logger's for calibration where only few or poor calibration data from the actual logger was available. The results do not differ much in most instances. The way I understand it, it does not really matter where you perform your calibration as long as you enter the correct calibration location into FlightR. The way I understand it, the calibration is used to compare the actual light curves measured by the logger with theoretical light curves for that specific location. So it should not matter at all where your birds were at the time of calibration, since you know where your calibration loggers were at the time. Please let me know if I got something wrong. I hope I could help you, but lets see what Eldar says! :)

 

PS: Maybe just try and create a calibration object with one of your calibration loggers. then load the light data of one of your birds (create a Proc.data object), and subsequently create a pre-run object with those. Run the model and see whether the results make sense! From my experience (skuas data is very shady during breeding) it is best to exclude very shady data and only use actual migration periods (i.e, times the birds were pelagic) for analysis.

 

Hendrik

Share this post


Link to post
Share on other sites
  • 0

  Hi Luke, 
I totally agree with Hendrik,

 You can try calibration from one tag with the other and it will likely work.

   Eldar

Share this post


Link to post
Share on other sites
  • 0

Hi Hendrik, Eldar,

 

Thank you very much for your responses.

I am going to try your suggestion. I only have 6 twilight events on each calibrator tag, but I'll give it a go - hopefully it is enough calibration data.

 

I have previously analyzed this data in GeoLight and position of birds are as expected.  Unfortunately now I am experiencing errors with the make.calibration function.  It may be something that I have done incorrectly, but I can't tell.  First I defined twilights using GeoLight and then transform the twilights using GeoLight2TAGS function.  After that my code looks like this.  The error I experience is at the end. 

 

> X894.data
 
Detected Intigeo_Mode_4 tag
tag saved data every 300 seconds, and is assumed to measure data every 60 seconds, and write down max 
 
> CapLocs=c(127.9704, 50.4475)
 
> Calibration.periods
+ calibration.stop = as.POSIXct(c("2016-06-28", NA)),
+ lon = CapLocs[1],
+ lat = CapLocs[2])
 
> Calibration.periods
  calibration.start calibration.stop      lon      lat
1                     2016-06-28 127.9704 50.44757
2        2016-06-05             127.9704 50.44757
 
> Calibration
+ plot.each = FALSE, plot.final = TRUE, likelihood.correction = "auto",
+ suggest.irrad.borders = FALSE)
 
 dusk 21 was excluded from the calibration
Error in `$
  replacement has 1 row, data has 0
In addition: Warning messages:
1: In is.na(First.LogIrrad) :
  is.na() applied to non-(list or vector) of type 'NULL'
2: In is.na(Last.LogIrrad) :
  is.na() applied to non-(list or vector) of type 'NULL'
3: In is.na(First.LogIrrad) :
  is.na() applied to non-(list or vector) of type 'NULL'
4: In is.na(Last.LogIrrad) :
  is.na() applied to non-(list or vector) of type 'NULL'
 
Thanks,
Luke

Share this post


Link to post
Share on other sites
  • 0

  Hi Luke,

 Here is your problem:

Calibration.periods<-data.frame(calibration.start = as.POSIXct(c(NA, "2016-06-05")),
+ calibration.stop = as.POSIXct(c("2016-06-28", NA)),
+ lon = CapLocs[1],
+ lat = CapLocs[2])

Should be

Calibration.periods<-data.frame(calibration.start = as.POSIXct("2016-06-05"),
 calibration.stop = as.POSIXct("2016-06-28"),
 lon = CapLocs[1],
 lat = CapLocs[2])

  Eldar

Share this post


Link to post
Share on other sites
  • 0

Hi Eldar,

 

Thanks for your response.  I reran the make.calibration function as suggested.

I still get the first part of the error about dawn/dusk exclusion from calibration:

 

 dusk 11 was excluded from the calibration
Error in `$
  replacement has 1 row, data has 0
 
 
The error is similar to the error reported in this post:
 
However, changing model.ageing command does not help.  
 
Luke

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×