Jump to content
Ornithology Exchange

ebridge

Society Members
  • Content count

    29
  • Joined

  • Last visited

Community Reputation

1 Has posted some good stuff
  1. ebridge

    "sp_dists" not available

    Solved it by uninstalling the sp package and reinstalling. Note that just updating the package did not work.
  2. I'm getting an error when running make.prerun.object in FLightR: > all.in Error in .C("sp_dists", x, y, xx, yy, n, dists, lonlat, PACKAGE = "sp") : "sp_dists" not available for .C() for package "sp" Looking at the sp package there is a function called spDists, so maybe the name got updated. Any thoughts...
  3. ebridge

    SD Card requirements

    Dear Alec, The RFID reader will only work with FAT-16 formatted SD cards. The 64GB card is almost certainly FAT-32, and so the RFID reader won't work with it. I know less about what is compatible with iPads. Obviously your mac is compatible with fat16 which will allow it to read smallish SD cards. It could very well be that the iPad will not read Fat16 and that's all there is to it. You could test this idea by taking one of the 2GB cards and reformatting to FAT32 (use disk utility on your mac). If the IPad comms with the reformatted card, then there's your answer. Of course that card will no longer work with the RFID reader. It might be that the lightening interface device is not FAT16 compatible, but I doubt it. You could test that by plugging it into your mac with the FAT16 card attached.
  4. Chuck, Sorry you haven't gotten any answers. Maybe it's because you have a problem that is hard to replicate. Is there a way to make it happen without 30-40 minutes of work? Can you confirm that it freezes with no error message?
  5. I would go back and baby-step through this analysis. Are you getting reasonable results from a threshold analysis? If not you might want to solve that problem first before going on to FLightR. And ditto what Eldar said about clock drift. That can give you large and directional longitudinal errors.
  6. ebridge

    Deleting Twilights in BAStag

    Just subset the data: twl_d or something like that. But I'd recommend carrying on with the full data set if possible. If you publish or share the data with lines deleted your work is not really repeatable.
  7. ebridge

    Deleting Twilights in BAStag

    I've not looked, but I wonder if the "deleted" twilights are actually just flagged somehow and not actually deleted. Can you show us some of the actual data in twl?
  8. One of the the things SGAT does is essentially take an estimate of twilight error (derived from calibration data) and translate it into location error for the entirety of a tag deployment. So if the same bias you mention is in your calibration data, SGAT might help eliminate it. If the point estimates move ever farther eastward over the course of the deployment period, there may be a clock drift issue. You could also have a "mountainside effect" where one twilight experiences shading but not the other. I suggest you look closely at your calibration data and plot the difference between known and estimated twilights. Do this separately for sunrise and sunset and for before and after calibration periods (if you have both).
  9. ebridge

    plot.lon.lat() in SGAT.

    Hi Amélie As a general approach you could find upper and lower quantiles for the posterior probability for longitude (stored in the output object fit$x) and latitude (fit$y) for each day and plot them along with the means or medians. Are you looking for more of a "how to" guide? Eli
  10. ebridge

    FLightR Error Message.

    I think start_no_polar has something to do with correcting twilights when the tag is near the poles. I guessing this sort of thing should not apply to your data set, but just for fun you could try setting a lower latitude value and see what happens. The make-rerun-objects function is a wrapper that is calling several other functions. the error you see is probably due to a missing parameter in one of those internal functions. I don't think you can set "start_no_polar" in the make-rerun-objects function. But why that error occurs I do not know. Sorry not a very helpful answer. If Eldar does not chime in at some point, then maybe thing about posting your code and data on Github so we can try to replicate your problem.
  11. ebridge

    New HardwareX journal

    Thanks for pointing this out. I think I will definitely be making some contributions here. Cheers, Eli
  12. ebridge

    Trouble with calibration

    @rost8416: Did this fix it?
  13. ebridge

    FlightR and dateline

    Interesting problem. As a work around can you just shift all of your times forward 5 hours and calibration locations east 60 degrees? Just avoid the dateline altogether. Let me see if I can get Eldar to chime in.
  14. ebridge

    waterproofing antennas

    Here's a question that came as an email: I've heard about antenna's being vulnerable to water from other sources too. To waterproof them I'll usually dip them in epoxy or in plastidip (tool dip). In both cases it's a messy job. A colleague of mine uses expoxy putty that you can mold with your fingers. That might be a neater option, but I haven't tried it.
  15. ebridge

    Cannot parse file

    Hi Alan, A likely problem is that the file is too big. TAGS was established when data at 10-minute intervals was the norm. If you have data a 2-minute intervals it is probably more that TAGS can handle (it tries to plot all the data). One thing to try is to cut the data up into smaller chunks. You can also get rid of repeated data (instances where the light level data are the same over and over).
×