# Introduction to real-time wireless camera trapping Lessons learned from deploying and managing wireless camera trap networks in remote environments ## Background Since 2018, The Nature Conservancy of California's [Conservation Tech Team](https://www.nature.org/en-us/about-us/where-we-work/united-states/california/stories-in-california/advancing-conservation-through-technology) has been using wireless camera trap networks in service of various conservation problems that benefit from real-time camera trap imagery. Our primary pilot site for this technology has been [Santa Cruz Island](https://www.nature.org/en-us/get-involved/how-to-help/places-we-protect/santa-cruz-island-california/), a 96-square-mile island located off the coast of Southern California, where we partnered with TNC's [Island Resilience Team](https://www.nature.org/en-us/about-us/where-we-work/united-states/california/stories-in-california/california-oceans-program/#island-resilience) to deploy camera networks as a monitoring and early-detection system for invasive species. For an in-depth overview of that project, check out the video below and its feature in [Wired](https://www.wired.com/story/rats-are-invasive-menaces-these-cameras-spy-on-them/). We are now in the process of scaling this approach to other preserves, but a lot of the applicable use-cases (e.g. [biosecurity](https://en.wikipedia.org/wiki/Biosecurity), [human-wildlife conflict](https://en.wikipedia.org/wiki/Human%E2%80%93wildlife_conflict)) are global in nature, and we can't do it all ourselves. We hope that by sharing some of the lessons we've learned, this document might serve as a resource for other organizations and researchers who are interested in using wireless camera traps for conservation. Our goal is to provide folks with a framework to weigh costs and benefits, get off the ground quickly, and minimize costly experimentation and evaluation. If you have questions, corrections, or suggestions–please [reach out](/about-us/contact-us)! We intend for this to be a living document and to update it as the technology and our experience develops.

Diagram of how The Nature Conservancy's invasive species monitoring system works on Santa Cruz Island

{% embed url="" %} From Months to Minutes: Real-time Biosecurity Monitoring with Wireless Camera Traps & AI {% endembed %} {% hint style="info" %} **DISCLAIMER OF ENDORSEMENT** Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by The Nature Conservancy. {% endhint %} # Are wireless camera traps right for you? Wireless camera traps are generally more expensive than traditional, SD-card based camera traps (in some cases >2x the cost) and can be more cumbersome to install, so it's worth evaluating whether this technology is a good fit for your use-case. The first step is understanding the benefits that wireless wildlife cameras provide. ## Benefits of wireless camera traps ### Real-time data Since camera traps were invented, [over 100 years ago](https://en.wikipedia.org/wiki/George_Shiras_III), the literal nuts and bolts of camera traps have evolved - they are now digital, passive infrared motion sensors have replaced silk tripwires, and it’s all become vastly cheaper and more accessible. But fundamentally, the practice of camera trapping has remained the same. You go out into the field, you set up your camera, you let it sit there for a long time and collect data, and then you go back out into the field (often months later) to retrieve the images it captured. Wireless camera traps, on the other hand, offer a different paradigm: because they send a stream of images to the cloud in near-real-time, and because many of them can be powered from solar panels, you don't need to return to the camera to fetch the data, and you can access the images from anywhere with internet as soon as they were taken. ***Real-time data means that you can respond to and act on that data, if need be, much, much faster than traditional camera traps.*** For certain use-cases in which response time is critical, like responding to an invasive species incursion or mitigating human-wildlife conflict, access to real-time data can have profound advantages and potentially help avert expensive and ecologically devastating outcomes. ### Maintenance savings Regardless of whether or not real-time images are important for your use-case, the fact that you don't have to return to the cameras virtually at all until you're ready to take them down means that you don't need to spend nearly as much time in the field servicing the cameras. We have cameras that have been siting out in the field for many years and are have been operating non-stop without any upkeep or intervention. ***If the cameras are in hard-to-access locations, the maintenance time savings alone might warrant the use of wireless cameras and could offset the added cost of the hardware.*** Also, a good amount of the maintenance can be done without leaving your house: because the communication between the cameras and the users is often bi-directional, you can typically configure settings, get status reports, and manually trigger the cameras all remotely. So if you notice that a camera is firing too much during certain hours or is over exposed at night, you can adjust those settings right from your computer. The efficiency gains in upkeep and maintenance translate directly to a smaller boots-on-the-ground footprint for running these cameras, and thus a greater potential for scalability - both in terms of the numbers of cameras you can operate at a given time, and also in terms of how far-afield, and how remote, you can comfortably deploy them. ### More data, better data With the SD-card based camera trap workflow, you set up your camera, say a little prayer, and then come back many weeks or months later hoping that your camera didn’t get knocked over, a patch of grass didn't shoot up and obscure the frame, and the batteries didn’t get depleted because some leaves were blowing around in the background. All of this happens quite frequently and can severely impact the quality and quantity of the images you collect. But with wireless cameras and access to real-time images, ***you know right away when something goes wrong, so you can be more targeted with your maintenance efforts, and if you address those issues quickly, you end up with much more usable data, for less effort and less time.*** On Santa Cruz Island, fore example, we found that that with our previous SD-card based cameras we had been losing >10% of our monitoring days due to SD card or battery malfunctions alone. ## Use-case considerations Given the strengths outlined above, we typically recommend wireless camera traps for projects in which one or more of the following applies: 1. **Real-time data matters** - you could use insights derived from camera data to take action or intervene in some way, and those interventions are time-sensitive 2. **long-term deployments** - the longer the cameras are out in the field, the more the maintenance efficiency gains offset the the added cost and setup complexity of the wireless cameras 3. **hard-to-access locations** - servicing the cameras is costly and time consuming 4. **existing internet connectivity or cell service** - without at least one point of existing internet connectivity in your area of study or reliable cell service, wireless camera networks require satellite and become either more expensive to install or more limited in utility. You can read more about connectivity considerations in [Types of wireless camera traps](/fundamentals/types-of-wireless-camera-traps). # Types of wireless camera traps Breaking down the strengths and weaknesses of different approaches to connecting camera traps to the cloud ## Cellular cameras Cellular cameras are the most common, cheapest, and easiest to install of all wireless camera traps. Most major camera manufacturers make cellular models, and [Trailcampro.com](https://www.trailcampro.com/collections/cellular-trail-cameras) does a fantastic job maintaining up-to-date ratings and reviews of what's commercially available (their customer support is also very knowledgeable and happy to help guide you towards making smart hardware decisions). Typically, if you have decent cellular service in ***all*** the locations you want to put cameras (usually >50%, or over 3-bars, of AT\&T or Verizon), we recommend using them. We do not recommend moving forward with cellular cameras without first testing service on the ground, everywhere you plan on deploying, but a good place to start if you're curious whether there might be coverage in your area of interest (and it's in the US) is the [FCC's national map of cell carrier coverage](https://fcc.maps.arcgis.com/apps/webappviewer/index.html?id=6c1b2e73d9d749cdb7bc88a0d1bdd25b). **Note**: when testing for cellular signal strength on the ground, use the exact camera trap model and cellular carrier you are interested in deploying, rather than using your cell phone or some other cellular connected device as they are not a reliable proxy. Cellular camera traps typically have much larger antennas than your cell phone and may have different algorithms for reporting the signal strength, so they may produce you inconsistent or unreliable results. {% hint style="success" %} **Pros:** * Cheapest of all wireless camera trap types and most user-friendly * Each camera is autonomous and does not need be wirelessly linked together or maintain line-of-sight with any others * Real-time access to the full resolution images {% endhint %} {% hint style="danger" %} **Cons**: * Strictly limited to areas with decently strong cell service (>50% signal strength) * Recurring data costs (approximately $10-15 per month, per camera) {% endhint %} ## Locally-networked, radio-based camera traps Locally-networked, radio-based camera traps, such as those sold by [Buckeye](https://www.buckeyecameras.com/), [Unmanned Wireless Systems](https://unmannedwireless.com/), and [Cuddelink](https://www.cuddeback.com/cuddelink), are less common and much more expensive than cellular cameras, but ***they can be deployed in locations that lack cell service.*** In these systems, cameras on the ground are wirelessly linked together to form a radio "mesh" network: when an animal trips one, that camera takes a photo and broadcasts it out to the next-closest camera in the field, and the cameras repeat this pattern of receiving and then rebroadcasting the image up through the network until it reaches a centralized base station. The base stations typically consist of a radio receiver, which demodulates the wireless RF signal into a digital image, and a field computer, which either stores the image locally if it doesn't have internet access, or uploads it to the cloud if it does (see note about **backhaul** options below). {% hint style="info" %} **Backhauls** In [IoT](https://en.wikipedia.org/wiki/Internet_of_things) parlance, the *backhaul* is the method by which a local network is connected to the broader internet. If you are operating in a location that already has some points of internet connectivity (e.g. maybe a comms. tower or field station), placing your base station at one of those locations and leveraging the existing internet will be the cheapest way to get your data to the cloud. If not, you have a couple options: * use a [cellular-connected base station](https://store.buckeyecam.com/wireless-receivers/x80-cellbase-multiple-carrier.html) (requires that there's at least one point of strong cell service in the vicinity) * install a high-bandwidth satellite connection (e.g. [Starlink](https://www.starlink.com/)) * use the network "offline". Many use cases don't necessitate transmitting data to the cloud at all, but having camera trap images wirelessly transmitted to a centralized hub or base station in real-time is still valuable for reducing fieldwork {% endhint %} The key takeaway is that aside from the base stations - which serve as the gateways to the internet - none of the other cameras or devices in the networks require any WiFi or cell service - again, they communicate 100% through VHF radio. So this, combined with the fact that you can daisy-chain them together to extend their range and circumvent challenging topography, is what allows users to capture real-time imagery across vast, remote locations with little-to-no internet access. ### Line of sight On Santa Cruz Island, we have had a lot of success using Buckeye X80 cameras and repeaters to transmit images over long distances (6-7+ miles between camera/repeater "nodes") across extremely mountainous topography. ***However, one of the major drawbacks is that to communicate with one another every camera in the network needs to maintain line-of-sight (LoS) to at least one other camera or repeater in the network.*** Large landmasses like bluffs and ridgelines will likely block signal and LoS, and dense tree-canopy and foliage can also attenuate and block the signal. In our experience on Santa Cruz Island, we've found that strategically placed repeater nodes can help circumvent just about any LoS challenge, but it should be noted that the need for repeaters adds additional cost to the network and complexity to the deployment. When evaluating LoS and the need for repeaters, we recommend conducting a viewshed analysis using [Google Earth Pro](https://www.google.com/earth/versions/) (for desktop)'s viewshed functionality or something similar. See our [guide for planning deployments](/tnc-wireless-camera-trap-documentation/buckeye-x80-networked-wireless-cameras/deploying-and-moving-the-cameras-and-repeaters/before-you-begin#plan-your-deployments) for more information. {% hint style="success" %} **Pros:** * Local networks can be deployed across vast, remote locations that lack cell service * Operational and data costs are low if you can piggy-back off an existing point of internet connectivity in the vicinity * Real-time access to the full resolution images (if the camera network is connected to the internet via some form of backhaul) {% endhint %} {% hint style="danger" %} **Cons:** * Significant up-front investment (cameras themselves are expensive and you may need additional hardware such as base stations and repeaters) * Cameras need to maintain line-of-sight with at least one other camera/repeater to connect with the network {% endhint %} ## Satellite camera traps Satellite-connected camera traps are a bit more of a nascent technology and less common than the other types (to the best of our knowledge no major commercial camera trap maker offers them off-the-shelf), but there are a handful of conservation groups and hardware developers working on bringing these systems to the market. The most sophisticated and general purpose is probably Conservation X Labs' [Sentinel](https://conservationxlabs.com/sentinel), but there are a number of other satellite-connected camera traps that were designed for narrower use-cases such as [poaching](https://www.resolve.ngo/trailguard.htm) or [biosecurity](https://zip.org.nz/videos-1/2020/7/zero-invasive-predators-zip-back-country-camera). The following description is a bit of a generalization because there are nuances to each system, but at a high-level there are a few things to be aware of when considering satellite-connected camera traps. Because satellite-connected camera traps can autonomously transmit data from each individual device directly to the cloud and don't require the cameras to be locally networked (although sometimes they are), ***they offer similar on-the-ground simplicity to cellular cameras in that there's no need to set up repeaters, base-stations, or consider line-of-sight between devices. Unlike cellular cameras, however, they typically can deployed in much more remote locations, not just in areas with strong cell service.*** At first glance this makes them highly practical and appealing, but there are some important limitations to be aware of. Again, these limitations may not apply to all systems, so it's important to do your homework and evaluate each product on it's own merits. ***The most significant limitation that may surprise users is that most satellite cameras do not transmit images to the cloud/end-users, they transmit text that describes the images.*** That is not 100% true across the board - e.g. some cameras will transmit some high-priority images but not all, others will transmit compressed thumbnails - but in order to make using the devices cost effective at scale they typically rely on low-bandwidth satellite services such as [Swarm](https://swarm.space/), which is designed for transmitting small packets of text & numerical data from IoT devices in the field (think temperature and humidity data from sensors and weather stations) rather than large image files. In short, they are highly bandwidth-constrained. That leads us to another limitation that users should be aware of: in order to generate text descriptions of what is in an image (i.e. "*a rhinoceros was detected at camera 5 at 3:15 on 1/1/23*") the cameras use on-board artificial intelligence, or "[edge detection](https://guides.animl.camera/fundamentals/pages/3nxGnnMaZnPCogWVwEGT#cloud-vs.-fog-vs.-edge-detection)", to guess what's in them. And because humans have limited ability to look at the images themselves to verify that the AI was correct in real-time, that means you need to really trust the AI models will detect what you're hoping to see, which, in the case of camera trap images, are [notoriously error-prone](https://arxiv.org/abs/1807.04975). For use-cases in which a false-negative or false-positive might have costly implications, not being able to see the images remotely might make this technology a bad fit. However, there are use-cases that have higher tolerances for AI inaccuracy, or situations in which you can compensate for the uncertainty with more cameras. For example, if you have a grid of satellite-connected cameras on the ground and many of them start reporting wildebeest detentions all at once, there's a very good chance that there's a heard of wildebeest moving through your area of study. Or perhaps you're conducting an invasive species eradication and you're interested in long-term population dynamics - in that case, textual data with some level of inaccuracy might be just fine for charting the decline in detections of the animal over time or creating heatmaps of the distribution of the detections. {% hint style="success" %} **Pros:** * Satellite-connected cameras do not need to be locally networked with one another * Can be deployed in remote areas without cellular or internet access {% endhint %} {% hint style="warning" %} **Cons:** * Satellite-connected cameras with edge detection likely transmit text descriptions of the images rather than the images themselves * Requires a high degree of confidence in the AI models that are generating the text * Recurring data costs (approximately \~$30 per month, per camera) {% endhint %} # Integrating artificial intelligence Cloud vs. fog vs. edge: where to run inference? {% hint style="info" %} **Prerequisites** [Types of wireless camera traps](/fundamentals/types-of-wireless-camera-traps) are discussed below; it's worth reviewing and understanding them before diving into this page. It's also worth reviewing out [Intro to AI for processing camera trap data](https://docs.animl.camera/getting-started/intro-to-ai-for-processing-camera-trap-data). {% endhint %} Having access to real-time data is nice, but individual camera traps can easily produce tens-of-thousands of images in a short amount of time (many of which are empty or don't contain animals of interest), so in order to leverage the real-time nature of the data you need automated image processing - and that likely will involve using machine learning (ML) models to predict what's in the images. Before proceeding it's also worth noting that using machine learning for camera trap image classification is [a surprisingly difficult data science challenge](https://docs.animl.camera/getting-started/intro-to-ai-for-processing-camera-trap-data#ml-offers-increased-efficiency-not-automation), and at the moment, ***while ML can greatly increase labeling efficiency and help surface much of what you're interested in detecting in an automated fashion, it doesn't replace the need to review images entirely***. For most use-cases, you will still need a "human-in-the-loop" to review a lot if not all of the images. ## Cloud vs. Fog vs. Edge detection There are essentially three places where your machine learning models can live and be executed (requesting an ML model prediction is called "inference"), each with different strengths and weaknesses: * **Edge detection** is when the inference is performed on each individual camera itself before being transmitted. This is most applicable to [satellite-connected cameras](/fundamentals/types-of-wireless-camera-traps#satellite-camera-traps) (and to a lesser degree cellular cameras) in which bandwidth is highly limited and it's important to only send the smallest and most relevant amount of information to the cloud / end-user. The advantage is that it makes satellite-cameras more cost effective to scale; the disadvantage is that you need to either trust your ML models or have a use-case with some tolerance for false-positive/negatives because the end users likely have very limited ability to verify that the predictions are correct (see the section on [satellite cameras](/fundamentals/types-of-wireless-camera-traps#satellite-camera-traps) in the "Types of wireless camera traps" page for more on that). Machine learning is also a power-intensive process and edge detection may require the installation of larger batteries and solar panels at each device. * **Detection in the Fog** is similar to edge detection in that the machine learning is run locally, on-the-ground, before transmitting images to the cloud, but the difference is that instead of performing inference on each individual camera, it's done at a centralized base-station computer after the local cameras have transmitted their images to it. This is most applicable to [locally-networked, radio-based camera traps](/fundamentals/types-of-wireless-camera-traps), and may be useful in situations in which you're semi-bandwidth constrained (perhaps you're using an existing low-bandwidth satellite internet connection as your backhaul and you want to filter out all empty images before uploading them to the cloud) or perhaps you don't need the image data to be uploaded and available on the cloud at all but still want to use real-time data and ML processing. * **Detection in the Cloud** is, just like it sounds, when the machine learning processing happens in a cloud environment after the images have been uploaded. It's useful if you're not bandwidth constrained and it's not cost-prohibitive to transmit all of your images to the cloud and perform automated labeling and filtering there. For this reason, it's most applicable to [cellular cameras](/fundamentals/types-of-wireless-camera-traps#cellular-cameras) and [locally-networked, radio-based camera traps](/fundamentals/types-of-wireless-camera-traps) with high-throughput backhauls. ### Thinking about your end-user first In addition to considering budget and and existing connectivity options, another thing to think about is who will be using the data, where will they be physically located, and what they will be doing with the information they get from it. To take an example from the biosecurity (invasive species management) world, you can split the biosecurity monitoring use-cases into two broad buckets: **incursion detection** and **eradication monitoring**. For an incursion detection deployment, in which long-term monitoring cameras are set up on remote islands to try to detect new unwanted invasive species incursions, inference in the cloud might make sense because the people who are going to have to react to an incursion and make decisions about them are likely to be in an office somewhere on the mainland rather than on the ground. If you're using cameras for an on-going eradication effort, however, it's the opposite: the team using the detection information most immediately are already on the the island itself - so it might not make sense for the camera data to get uploaded to the cloud at all. They may also be trying to use the labeled data to do population modeling on the fly to assess whether their efforts are having impact and/or where they should direct their trapping resources, so having a system for wirelessly collecting the data and processing using machine learning might be very helpful. In this case, performing detection in the fog might make the most sense. # Intro Documentation on how to replicate and maintain the same wireless camera trap systems The Nature Conservancy utilizes on its preserves ## Who this documentation is for The following documentation is for TNC staff who are actively scaling and managing wireless camera trap networks and using [Animl](https://animl.camera) for data processing, and for anyone interested in replicating similar systems elsewhere! The system we use integrates [locally-networked, radio-based camera traps](/fundamentals/types-of-wireless-camera-traps#locally-networked-radio-based-camera-traps) (Buckeye X80s) and cellular camera traps ([RidgeTec Lookout 4G LTEs](https://www.trailcampro.com/products/ridgetec-lookout-4g-lte)) with [Animl](https://animl.camera), a software platform we've developed for managing camera trap data and performing machine learning inference in the cloud.

Diagram of how The Nature Conservancy's invasive species monitoring cameras work on Santa Cruz Island

This documentation is meant to supplement the existing product documentation published by the camera manufacturers, provide specific guidance for integrating these types of cameras with Animl, and share lessons-learned/best practices for long-term deployments in the field. {% hint style="info" %} **Access to Animl** If you're interested in using Animl for data processing and managment for your project, please reach out to Nathaniel Rindlaub at \.\@tnc.org {% endhint %} # Buckeye X80 networked wireless cameras {% hint style="info" %} **Not official Buckeye documentation!** This documentation is intended to supplement the Buckeye X80 user manual, which can be found [here](https://www.buckeyecam.com/x80manual/x80_camera_manual.pdf). {% endhint %} ## About the network [Buckeye X80s](https://store.buckeyecam.com/x80-series-wireless-camera.html) wireless camera traps, in addition to being able to take pictures in the field and transmit them to a base station via radio, can also receive and relay images taken from other X80 cameras or rebroadcast image data from “Echo” repeaters. This feature allows users to link the cameras together to form a wireless mesh network that can be deployed to cover vast and difficult-to-access terrain without WiFi or cellular service. Each camera/repeater ("node") in the network is solar powered and self-sustaining, so once deployed, maintenance and human intervention is minimal. The only part of the system that requires an internet connection is the base station; the rest of the communication between cameras and repeaters is accomplished through radio. This allows users to remotely (i.e., from anywhere in the world with an internet connection) access images, adjust camera settings, monitor vegetation overgrowth in the camera’s field of view, and monitor the camera’s status (battery, connection strength, etc.). ## Network components 1. A **base station**, which consists of: * An antenna (e.g. a [64”, 9dBi high gain antenna](https://store.buckeyecam.com/accessories/antennas-and-cables/antennas/64-omni-high-gain-antenna-pro-series.html)) * [CA-400 antenna cable](https://store.buckeyecam.com/accessories/antennas-and-cables/cables/20-ft-cable-400-series.html#product-details-tab-specification) - to connect the antenna to the PC Base Receiver * [Buckeye X80 PC Base Receiver](https://store.buckeyecam.com/wireless-receivers/x80-pc-base-receiver.html) - receives and decodes the RF frequency into digital images * A (preferably) Linux-based field computer to run the Buckeye network management software and [animl-base](https://github.com/tnc-ca-geo/animl-base/), which uploads images to Animl. We have used a variety of computers in the field before, including [Raspberry Pi 4B](https://www.raspberrypi.org/products/raspberry-pi-4-model-b/), [Cincoze DA-1000](https://www.cincoze.com/goods_info.php?id=59), and OnLogic fanless industrial computers. We have also set up animl-base on Windows computers, but that is less optimal. * A weather-proof enclosure to house the field computer and PC Base Receiver. If your enclosure is small and you're in an environment that gets hot, be sure to get a field computer that's rated to withstand and operate at high temperatures (60-70° C).

A Cincoze DA-1000 field computer (left) and Buckeye PC Base Receiver (right) installed on Catalina Island

1. **Camera nodes** * [Buckeye X80 camera](https://store.buckeyecam.com/x80-series-wireless-camera.html) (NOTE: we now have two generations of Buckeye X80’s in the field: the newer ones, which you interact with out in the field using bluetooth and mobile phone app, and the older versions, which you interact with via a small LCD screen on the camera itself.) * 12v AGM battery * Antenna (8” stock dipole antenna, [22” high gain antenna](https://store.buckeyecam.com/accessories/antennas-and-cables/antennas/omni-repeater-high-gain-antenna-6dbi.html), or 44” high gain antenna) * 11.25 W Solar Panel 2. **Repeater nodes** (Echos) * [Buckeye X80 Echo](https://store.buckeyecam.com/wireless-repeaters-sensors-and-controllers/x80-echo-motion-sensor-and-repeater-kit.html) * 12v AGM battery * Antenna (8” stock dipole antenna, [22” high gain antenna](https://store.buckeyecam.com/accessories/antennas-and-cables/antennas/omni-repeater-high-gain-antenna-6dbi.html), or 44” high gain antenna) * 11.25 W Solar Pan # Managing the camera network The camera, repeater, and network settings are managed through ***Buckeye MulitBase SE***, a browser-based application that is served by and can be accessed on the field computer that the ***Buckeye PC Base Receiver*** is plugged into (hereafter referred to as the Base Station computer). Accessing the software entails: 1. Remotely accessing the base station field computer via AnyDesk 2. Opening a browser window, and navigating to \*\*[http://localhost:8888\*\*\ ](https://guides.animl.camera/tnc-wireless-camera-trap-documentation/buckeye-x80-networked-wireless-cameras/http:/localhost:8888**\ ); 3. Logging into the Buckeye MultiBase SE application {% hint style="info" %} **Note** We manage the images/data that camera networks produce and the machine learning pipelines with [Animl](https://animl.camera), a separate (but integrated), cloud-based application {% endhint %} # Anydesk You will first need to download AnyDesk on your personal computer/workstation; download and installation instructions can be found [here](https://anydesk.com/en/downloads/). You will also need the base station computer’s AnyDesk ID that you are trying to target, which, if you're a TNC employee, you can find in the [password document](https://tnc.app.box.com/file/762650708780) in Box. ### **Setting up Anydesk** Unless you want to be able to access your computer remotely for some other reason (it’s not required for managing the camera network), we recommend disabling unattended access in your security settings. On a Mac, navigate to **Preferences** > **Security** and uncheck “Enable unattended access”. ### Logging in Open AnyDesk on your computer, and enter the AnyDesk ID/Address you'd like to connect to and click **Connect**. When AnyDesk prompts you for a password, use the one referenced in the password document. When the desktop is displayed, select the “Animl” user, and input the “Animl” user account password listed in the password document. ### Transferring images & files to your computer Though not necessary, sometimes it’s helpful to transfer files (like log files) off of the Base Station computer and onto your own. To do so, you can use AnyDesk’s File Manager functionality: while logged into the Base Station computer via AnyDesk, click on the **lightning bolt icon** in the AnyDesk navigation bar, and then select **File Manager**. From there, you can find the file or image you want on the Base Station computer, select it, and click **Download**. # Buckeye MultiBase SE Managing camera settings through Buckeye's GUI ## Launching app & logging in ***Buckeye MultiBase SE*** is a self-hosted web app, which means you access it through a browser, but it’s only accessible on the computer it’s being served on (the Base Station computer). To open it, open a new browser window on the remote computer, then enter **** in the URL bar. The Admin username and PW are in the password document. ## Manage the network Almost all of the useful network administrative tools can be found by clicking on/expanding the bar that says **“B8301D8F - Valley Peak - X80 PCBase…”** (this may differ if you are trying to manage a network other that Valley Peak) and then clicking the **Admin** button in the panel that gets revealed. This should bring you to the network tree view:

A screenshot of Buckeye MultiBase SE’s user interface

## Checking a camera/repeater's status To check the battery health and signal strength of a camera/repeater (also referred to here as node), click on the node in the network tree diagram, and then click **Check Status** in the sidebar that pops up. ## Changing camera settings To change camera settings, click on one of the cameras or repeaters, and click **Settings** in the side panel. Most of these settings are self explanatory. *Be sure to click **Update** when you are done with configuration.* We are using the following settings for most of our Santa Cruz island biosecurity cameras: * **Text 1:** secret exposure and gain codes. This is not intuitive and we wouldn’t have known this had we not contacted Buckeye support because we found that when the cameras are close to and pointed at a large physical object (i.e. a tree trunk, the ground, a wall), the IR flash is too strong bounces off the surface, causing the image to be blown out. However, you can adjust the exposure by entering a secret code with the following format: **`#E30 #G20`** where E = exposure and G = gain. The lower the exposure, the darker the image, with **`#E2`** appearing to be the lowest the exposure will go (**`#E1`** and **`#E0`** don’t seem to work for some reason). The default/baseline is **`#E75 #G20`**. * **Text 2:** name of camera (and check “show on pictures”) * **Image format**: 1 Megapixel Picture * **Delay between motion triggers**: 1 second * **Pictures per motion trigger:** 3 pictures * **Motion sensor:** 100% * **Blink LED when motion detected:** no * **Camera schedule:** this can be useful, e.g., if a camera is firing too much during the day you can turn down it’s sensitivity or the # of pictures it takes per motion trigger, but keep it maxed out at night, or if you need to turn the exposure down at night, but keep it at its default during the day, there is a setting to “enable/disable hash codes” for a given camera schedule * **Triggered cameras:** Triggered cameras (likely none - we don’t really use this feature) * **Transmit last picture first:** no * **Use IR flash at night:** yes * **Enhance night images:** no * **Power down camera when battery is low:** no * **Define GPS coordinates:** Yes, please define GPS coordinates! Azimuth and altitude aren’t as important * **Automatically delete files:** Never ## Disable motion sensors on Echos Buckeye Echos (the repeaters) can also serve as remote triggers for other cameras in the network. However, if you don’t need the the motion sensor functionality, you can disable it by clicking on each Echo, then selecting **Settings** > **Motion Sensor** > **Off**. ## Change camera routing To change which upstream repeater / camera a given node is routed to, select the **hamburger menu** (three horizontal lines) in the upper right hand corner, click **Change Routing**, select the node you want to re-route, then allow it to search for alternative routes and select from the available options. ## Adding new cameras/repeaters to the network There are three ways to add a new camera to the network: 1. **Manually**: if you are physically close to or have the camera/repeater (node) you’d like to connect in hand, and the node is: * within radio range/line of site of an existing registered node in the network or the base station, * is not currently registered to another network, * and you have a computer with internet access (and thus can access the Base Station computer and MulitBase SE app) you can manually pair it to the network by (1) turning on the camera/repeater, (2) clicking **Add/Remove device** in the upper left hand corner of the MulitBase SE app (Note: the camera settings sidebar must be closed for this button to appear), and (3) selecting the type of device you want to add, thus initiating a search for unregistered devices to add to the network. (4) Once your new device appears, select it, and it will be paired with the network. If your device does not appear, try “restoring the network” (see instructions below).
2. **Automatically through “Search and registration” mode:** Alternatively, if you do not have radio signal where you are, but you do have access to a computer with internet, you can set the base and/or any of the nodes in the network to “Search and registration mode” for a configurable amount of time, during which the nodes will search for new devices to add to the network on an interval (every 2 mins, I believe). Once out in the field with the device and within signal range, if your new node has been “found” by a node in “Search and registration” mode, it will prompt you and ask if you want to join the network. \ To activate Search and Registration mode, click. **Add/Remove device**, then **more…** in the upper right corner, and follow the instructions (select a start time, duration, add a “reference name”, and select a node to broadcast the search message from, and click **Activate**). Note: once a node has been registered to any node in the network, it can be moved around and re-routed as needed from the physical node itself (either via the LCD screen interface or the Buckeye X80 Remote phone app, depending on which generation of the cameras you have), or remotely via the MultiBase SE web app, as described above.
3. **Targeted registration:** An important limitation of both of the above approaches is that you have to have the new camera/repeater in hand in order to complete the registration with the network. If you are in a situation in which you need to pair a node to a new network but aren’t physically close to it, a work-around is to follow the above steps to activate “Search and Registration” mode, but be sure to enter the serial number of the node you are trying to connect to preceded by “#” as the “reference name” (e.g. “#X8115CBC”) in the Search and Registration form. Then select a node that you know is within line of sight to the one you’re trying to pair to broadcast from, select **Activate**, and wait a few minutes. If successful, the node you’ve targeted should appear in your network tree diagram. ## Restoring the network In rare circumstances, the base may have trouble finding devices that were previously registered to the base and need to be re-registered (e.g., I’ve had to do this when re-configuring the base station computers from scratch but using a PC Base Receiver that had previously been in use and had had cameras registered to it). If this happens, try restoring the network by clicking on the **hamburger menu** in the upper right > **Restore Network** {% hint style="info" %} **Note** “Restoring” is a bit misleading. This does not reset the network to some previous state and override all of your current settings. I’m not entirely sure what’s going on under the hood when you click Restore Network, but in essence it just seems to find old cameras that were previously paired with the base but are now not being found. {% endhint %} ## Removing (unregistering) cameras/repeaters from a network There are two ways to remove/unregister a camera from a network: 1. **Via the Buckeye Multibase SE software:** You can remove a device from the network by logging into the Multibase SE software, selecting **Add/Remove device** in the upper left hand corner of the MultiBase SE app (Note: the camera settings sidebar must be closed for this button to appear), and (3) selecting the device in the network tree diagram you want to remove, and accepting the “are you sure you want to remove this device from the network” prompt. 2. **Hard reset from the physical device:** If you are, for example, in the field and do not have the ability for whatever reason to connect to the Buckeye Multibase SE software to remove the device, you can perform a hard reset on the device itself, which will unregister it from a currently paired network. \ \ To perform a hard reset on one of the older (non-bluetooth) models: 1. open up the device housing and press the **Next** button, 2. hold **Next** for 1 second, and while holding **Next**, also press and hold the **Change** button, 3. you will be prompted to unregister the device - press **Enter** to do so \ To perform a hard reset on one of the newer bluetooth enabled models: 1. Connect to the device via the mobile app, 2. swipe between to the left of the space to the right of where it says "camera", 3. An unregister option should appear # Advanced ## Pulling logs ### Buckeye MultiBase SE Logs The Buckeye server application (MulitBase SE) log file is located at `/home/animl/data/[base station id]/log.txt`. I have found it’s easiest to access if you download it to your local computer via AnyDesk’s File Manager functionality. While logged into the Base Station computer via AnyDesk, click on the **lightning bolt icon** in the AnyDesk navigation bar, and then select **File Manager**. From there, you can find the `log.txt` file on the Base Station computer, select it, and click **download**. ### Animl-base logs [Animl-base](https://github.com/tnc-ca-geo/animl-base/) is a separate node application that is responsible for watching for new images added to the Base Station computer and uploading them to s3. We use [PM2](https://pm2.keymetrics.io/) to daemonize animal-base and a separate temperature monitoring script. Complete PM2 logs can be found at: `/home/animl/.pm2/logs/` ## Rebooting the Base Station via the networked power switch If a base station crashes, it should reboot automatically in a couple of minutes. However, as a failsafe, we also try to plug the base station computers into networked power strips, so if it freezes and becomes unresponsive, you may want to try power-cycling it via the networked power switch that it’s drawing power from. # Deploying and moving the cameras & repeaters # Before you begin ## Plan your deployments We highly recommend downloading and using [Google Earth Pro](https://www.google.com/earth/versions/#earth-pro) and its viewshed analysis functionality to plan your deployment locations before you go out into the field. Because the nodes need line-of-site to communicate with one another, the viewshed from a particular node is a good proxy for all of the potential areas you would have decent connectivity to that node. Some rules of thumb when planning new deployments: * **Range:** They can transmit images quite far. We have successfully transmitted images up to 7 miles using only the small, 8” stock dipole antennas. The range depends on a lot of conditions, however, including ambient RF interference and humidity. * **Line of sight:** Transmitting images between nodes requires near perfect line-of-sight. They have some tolerance/ability to transmit through tree canopy/foliage, but they can not transmit through hills, buildings, or other large land masses. That’s why making sure where you want to place a camera falls within its parent camera/repeater’s viewshed ahead of time is so important. Repeater nodes are incredibly effective tools for expanding signal to hard-to-reach locations, but they come at an extra cost, and in general it’s good practice to try to keep the number of “hops” an image has to make between nodes to a minimum. * **Positioning repeaters:** If you’re trying to place a camera in a difficult-to-connect-to location (e.g., a deep drainage), a good strategy is to position repeaters on elevated ridges/hills across from drainages, rather than above them. For example we failed to connect directly from Valley Peak to the following drainages off of the South Ridge of Santa Cruz Island because the drainages were too deep and too far west, relative to VP:

We initially failed to get LoS from the base-station (lower left) and the two cameras located in deep drainages (upper right)

However, by positioning a repeater further west along the North Ridge, directly across from the drainages, we were able to connect to them:

A srategically placed repeater on the opposite (North) ridge allowed us to reach the cameras

## Download Buckeyes “X80 Remote” iPhone app The newer Buckeye cameras do not have an LCD screen and physical buttons to interact with it; you instead interact with it via bluetooth and a phone app. That means you need to have the app loaded on your phone in order to perform basic setup tasks. If you have an iPhone, you can find the app by searching “X80 Remote” in the App Store. I believe it’s called the same thing in the Android/Google Play Store. ## Charge batteries Make sure the 12v AGM batteries are charged before leaving. A 12v battery charger & tender like this [one](https://www.amazon.com/NOCO-G1100-Advanced-Battery-Maintainer/dp/B004LX3AXQ/) works well. ## Assemble solar panels This can also be done in the field, but they require a little finesse to put together and require working with small nuts and bolts in tight, awkward areas so it's easier to do before departing. It also might require drilling larger holes in the angled bracket - newer solar panel brackets appear to have impossibly small and oddly-shaped holes for the machine screws it comes with it. We also recommend using [thread-locker](https://www.amazon.com/Threadlocker-H-271-Permanent-0-4-Fl/dp/B09FGBH34Q/ref=sr_1_2_sspa?keywords=lock+tight\&qid=1675831743\&sr=8-2-spons\&psc=1\&spLa=ZW5jcnlwdGVkUXVhbGlmaWVyPUExQUtSVVdUUkdMOVAwJmVuY3J5cHRlZElkPUEwMzg3OTUwMlNPMjdFQVk1MUxCRiZlbmNyeXB0ZWRBZElkPUEwNjQzNDAxMjJXUEsyWEM3Tk9HVSZ3aWRnZXROYW1lPXNwX2F0ZiZhY3Rpb249Y2xpY2tSZWRpcmVjdCZkb05vdExvZ0NsaWNrPXRydWU=) on all nuts as vibrations from wind can work these screws loose, which can result in the entire node being knocked offline. ## Register new cameras/repeaters to the network Before you head out into the field to deploy a camera/repeater, be sure to register it with the network (and first UNREGISTER it from any previous networks, if it is currently paired with a different one). This is critical as it’s not possible to deploy a node that is not either already registered to the network, or who’s parent node has not been set to “Search and Registration” mode, and both approaches require access to internet. Full instructions can be found in the[ Adding new cameras to the network](/tnc-wireless-camera-trap-documentation/buckeye-x80-networked-wireless-cameras/managing-the-camera-network/buckeye-multibase-se#adding-new-cameras-repeaters-to-the-network) section of this documentation. {% hint style="danger" %} if you forget to do this and you are out in the field, at the very least make sure you have the serial number of the camera/repeater written down, because you can perform a targeted registration after the fact once you’re back to internet and can access Buckeye Multibase SE (instructions for targeted registration are also in the “Adding new cameras to the network” section) {% endhint %} ## Disable the motion trigger on the cameras It’s also not a bad idea to temporarily disable the motion trigger on the cameras while you’re setting them up and/or working on them. You will trigger the camera dozens of times, which bogs down the network, drains battery, and pollutes our data. To disable the cameras, log into Buckeye MultiBase SE, click the camera you wish to disable, and click **Disable Sensor**. If you forget to do this before you leave, you can set the camera to “Walk test” mode while configuring it out in the field, which will prevent the camera from taking and sending pictures for a period of time of your choosing. # Setting up a camera / repeater node ## Testing signal strength The first thing you’ll want to do when you’ve found a place you’d like to install a camera is to make sure the signal is adequate. Open up the camera (or connect to the camera using the mobile App if it’s a newer model) and click the **Next** button a few times until you get to the screen that says “Signal to \[node that it’s pinging to] - measuring…”. Wait a moment, and it should display the strength of the signal in decibels. The higher the value the better (note - decibels are negative values, so -50dBi is a stronger signal than -60dBi. Decibles are also lograithmic, not linear). You may also see “No response!” displayed intermittently. We believe this is due to radio interference, and some amount of “No response!” warnings (i.e., <25% of the time) seems to be acceptable. ## Improving the signal strength / antenna selection We recommend first testing the signal strength with the small, 8” stock antenna. They seem to be more than adequate in most situations. However, these radios need near perfect line-of-sight to whichever node they’re sending data to, and while in our testing and experience they can transmit through a decent amount of tree canopy/foliage, but they can not transmit through or around large land masses. Because of this, it may be advantageous to use a larger, detached antenna (connected to the camera via antenna cable) to get it elevated or around objects that are blocking line-of-sight. Any gains you get in signal from larger antennas may be partially or entirely negated by having to travel the length of antenna cable, so the actual decibel improvement may be small when upgrading to a larger antenna. Their real purpose is to allow for more flexible positioning. ## Changing what parent node the camera is routed to To change the route of the node (select a new parent node to ping to), click **Next** until you get to the screen that says “Routed to \[parent node]”, click **Change**, wait for it to perform its search, and then select the node you’d like to reroute to. This may be slightly different if you’re changing the routing of a bluetooth X80 via the mobile app. ## Buckeye-specific hardware assembly recommendations There are a few non-intuitive aspects of assembling Buckeye hardware. They include: * **Use self-tapping screws to connect solar panels to the solar panel mounting arm**. The Buckeye solar panels and mounting arms come with a small bag of various machine screws, washers, and pieces hardware, but of them you only need the self-tapping screws (pictured below).

Self-tapping screws for Buckeye solar panels

* **Pad batteries with cardboard to prevent jostling**. The 12v batteries don't fit perfectly snugly in the Buckeye battery housing, so we recommend making cardboard wedges and spacers to make it more secure and prevent the batteries from moving around within he housing:

Folding corrugated cardboard into a spring-like shape and placing it between the battery and the lid of the housing will help keep it secure

## Follow hardware deployment best practices All other best practices are applicable. Click the link below for guidance on positioning solar panels, mounting hardware, wire managment, etc.: {% content-ref url="/pages/DkgupSLl5xbWCPicQEaQ" %} [Hardware deployment best practices](/tnc-wireless-camera-trap-documentation/hardware-deployment-best-practices) {% endcontent-ref %} # When you return to your desk ## Configure camera settings in Buckeye Multibase SE Be sure to log into the Buckeye MultiBase SE app, check the composition of the images (what’s in frame), check the exposure at night (if the IR flash is too bright, you can reduce the camera’s exposure with a secret code in Text box 2 as described [here](/tnc-wireless-camera-trap-documentation/buckeye-x80-networked-wireless-cameras/managing-the-camera-network/buckeye-multibase-se#changing-camera-settings), and any other settings that you want to adjust. Also please set the coordinates that you recorded in the field on the camera! ## Register camera to Animl In addition to registering the physical camera to the local Buckeye network (which allows the Base Station to recognize and communicate with the physical cameras), in order to route the camera’s images into the correct Animl Project, you also need to register every new camera’s serial number with your Project, and create a deployment record for the new Deployment. * **Register Camera**: documentation on registering an new camera can be found [here](https://docs.animl.camera/fundamentals/camera-management). * **Create Deployment**: Once you’ve registered a new camera, you will also likely want to create a new Deployment record for it. For more information on Deployments and guidance on how to create one in Animl, view the documentation [here](https://docs.animl.camera/fundamentals/camera-management#creating-deleting-updating-deployments). ## Update installation notes/maintenance logs/KML files /photo archive This will depend on your organization’s system for inventory tracking, but we highly recommend that you maintain some record keeping system for tracking what's out in the field. # Deploying a new Base Station Detailed instructions for configuring a new Base Station Computer can be found in the [animl-base](https://github.com/tnc-ca-geo/animl-base) Github repository: {% embed url="" %} # Reconyx HyperFire cellular cameras {% hint style="info" %} **Not official Reconyx documentation!** This documentation is intended to supplement the Reconyx HyperFire Cellular user manual, which can be found [here](https://www.reconyx.com/img/file/HF2ProCellManual20231226.pdf). {% endhint %} ## Set up and pairing with TNC CA's Reconyx Enterprise account The Nature Conservancy of California maintains a Reconyx Enterprise account, which allows us to (a) consolidate billing in one central place and (b) integrate the image feeds into Animl. If you're interested in using Reconyx cellular cameras and managing their data with Animl, you'll need to contact ** for set up support. #### 1. Download the Reconyx Connect app on your phone and create a new "End User Account" for your project Download the Reconyx Connect app from the [Apple App Store](https://apps.apple.com/us/app/reconyx-connect/id1497202185) or [Google Play](https://play.google.com/store/apps/details?id=com.reconyx.reconyx2\&hl=en-US\&pli=1). Upon opening the app, tap "Sign in with Email" and then "Create Account". Step through the account creation process. Finally, be sure to sure to change the “Account Name” to something identifiable with your project (preferably the name of your project or study site rather than a person's name). {% hint style="info" %} **End User Accounts vs Member Accounts** If you are starting a new camera trapping "project" - i.e. all of the cameras that belong to it will be charged to the same billing unit - we recommend first creating a new "End User Account" that serves as the primary owner of that project. This account will have to be associated with a single email address, so ideally it should be someone who anticipates being able to maintain and own these cameras for the entire duration of the project. If you have additional collaborators that you want to grant access to, they can be added as "Members" of your End User Account in a [later step](#optional-adding-more-users-to-your-reconyx-end-user-account). {% endhint %} {% hint style="warning" %} **Do not use a preexisting End User Account** In order for the Animl integration to work, *all of the cameras in each End user account must be associated with an Enterprise Account*. So if you have a preexisting End User account that contains cameras which are not associated with an Enterprise Account (which is likely the case), the integration will not work. If you are just getting started with Animl and integrating a fresh set of Reconyx cell cameras, we recommend creating a new End User account dedicated to your Animl cameras to avoid this issue. {% endhint %} #### 2. Send all of your new camera serial numbers to We will need them to pair all of the new cellular cameras you want to use to our Enterprise Account. * ***For TNC CA Enterprise Account Admins only:*** * to add new cameras to our Enterprise Account, log in at this url: * go to the “Devices/Accounts” page and select “Add New Device" * once added, these cameras will show in the Devices list with the assigned account information and status. Keep in mind, they may not show on an account or have an active status at this time. This will update once the cameras get activated on a Reconyx Connect app account. #### 3. Activate the new cameras via the Reconyx Connect app Insert the SD card, turn on the camera, and follow the in-app instructions to activate the camera. #### 4. Set up image forwarding in the Reconyx Connect app To configure the cameras to forward their image to Animl, for each camera, navigate to the "Advanced Settings" page ("Camera details" page -> menu -> "Advanced settings") and fill out the form with the following values: * **Image Forward Base URL:** * **API Id**: animl * **API Token**: \ for API token> * **Image Group:** \ Click "Test Connection" If this is the first camera you're setting up of many, we recommend clicking "Save as Default" so that you can load those settings for each additional camera you pair. Finally, follow the same steps for all additional cameras, but click "Load Defaults" to pull in the same information you just entered. #### 5. Register the camera with your Animl Project Navigate to your Animl Project at and [register the new cameras](https://docs.animl.camera/fundamentals/camera-and-deployment-management#registering-a-wireless-camera). #### 6. Arm the camera and take some test images If everything is working correctly, you should see new images show up in both the Reconyx Connect app and in your Animl Project. #### Optional: adding more users to your Reconyx "End User Account" If you have additional collaborators that you'd like to grant access to your End User Account so that they can interact with the cameras or add new ones via the Reconyx Connect App, first have the collaborators download the Connect app and create new accounts with their own email addresses. Once they have accounts, from the End User Account in the Reconyx Connect app, click the menu icon in the upper left, then select "Account" > "Add Member". Add their name and give them a Role, and click "Add". This will generate an invite link that you can email/text them to activate their Membership to that End User Account. # RidgeTec Lookout cellular cameras {% hint style="info" %} **Not official RidgeTec Documentation!** This documentation is intended to supplement the RidgeTec Lookout user manuals, which can be found [here](https://ridgetecoutdoors.com/pages/user-manuals). {% endhint %} ## Intro RidgeTecs are well built, well [reviewed](https://www.trailcampro.com/products/ridgetec-lookout-4g-lte), affordable cell cameras that are ideal for locations with decent Verizon or AT\&T service. Their customer service is also second-to-none. The fact that each individual camera communicates directly with cell towers means you don't need to deal with setting up local networking hardware (like repeaters and base stations), and if one camera fails the rest won't be affected. RidgeTec cameras also have a very convenient screen that lets you preview the images' framing/composition as you’re positioning them, and many of the settings can be configured through the web-based RidgeTec Portal, allowing you to make adjustments remotely from anywhere with an internet connection. For all of these reasons we try to use RidgeTecs anywhere we can; however, there are limitations to where they can be deployed and run off solar power (see Cellular and power requirements below). ## Cellular and power requirements You will need to have either Verizon or AT\&T service - AND - if you are running the camera off of the [10w solar power kit](https://ridgetecoutdoors.com/collections/accessories/products/solar-power-kit) (and [12v external battery](https://www.amazon.com/gp/product/B017U3L9W2/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8\&psc=1), which is not included), you'll need to have ***over 50% signal strength*** in order for the cameras to run sustainably. Signal strength and power consumption are inversely related because with a poor connection the cameras spend more time "awake" as they attempt to make a handshake with the cell tower and transmit data, thus depleting their batteries. ### Evaluating signal A good place to begin if you're curious if RidgeTecs might work in your study area is the [FCC's national map of cell carrier coverage](https://fcc.maps.arcgis.com/apps/webappviewer/index.html?id=6c1b2e73d9d749cdb7bc88a0d1bdd25b). However, be aware that this map indicates presence/absence of cell service for particular carriers, not signal strength. We highly recommend going to each place you intend on deploying a camera with one of the cameras in-hand (rather than using a cell phone as a proxy) to test signal strength on-the-ground. ***The signal strength is indicated on the cameras with a number between 0 and 32; to ensure the standard 10w solar panel will suffice, you'll want the signal strength to read between 16 and 32 (i.e., over 50%).*** ### Adding power or increasing signal strength If you don't have >50% signal strength, you have a few options: * Use the "schedule" feature in the RidgeTec's settings to schedule and limit the number of times per day the camera will connect to the cell tower and transmit images (these settings can be found in the online portal) * Add an additional 10w solar panel with RidgeTec's [solar expansion kit](https://ridgetecoutdoors.com/collections/accessories/products/solar-expansion-kit) * Power the cameras directly off 120v AC (if available) using their [12v AC adapter](https://ridgetecoutdoors.com/collections/accessories/products/12-volt-ac-adapter) * Boost reception with a stronger [4G LTE antenna](https://ridgetecoutdoors.com/collections/accessories/products/omni-4g-lte-antenna) ## Settings, integration with Animl Most of the settings must be configured through the web-based RigeTec Portal, so you'll need a computer with access to internet to configure them. We recommend the following settings as a starting point: * **Photo resolution:** 6MP 16:9 * **Flash**: Bright * **Photo burst:** 3 * **Burst delay:** 250ms * **Upload resolution:** High res MAX (1600x) - *NOTE: this is important for integration with Animl. To get access to 1600px 900x width in photo mode you must request RidgeTec support to set a flag in your account to allow that in the options.* * **Upload quality:** Low * **Wireless mode**: Schedule * **Schedule interval**: Every 4 hours * **Schedule file limit**: 50 files * **Skip report**: Yes * **Heartbeat interval:** Every 12 hrs * **Quite time**: 0 To integrate the camera with Animl, you'll need to do two things: 1. In the camera's settings in the RidgeTec Portal, make sure you've added `animl@codefornature.org` as a contact\*, and in the Notifications section, check **Send Mobile Push Notifications** and make sure `animl@codefornature.org` is also checked on. 1. \*NOTE: to initially add `animl@codefornature.org` as a contact you'll need to have Nathaniel Rindlaub confirm the verification email. Please email him at \.\@tnc.org to have him do so. You only need to do this once for each new RidgeTec account. 2. On Animl, make sure to [register the new camera](https://docs.animl.camera/fundamentals/camera-management) with your project using the camera's IMEI number as its unique identifier. The IMEI number is also called the "Module ID" in the RidgeTec Portal and can be found under **Overview** > **Status** > **More info**:
## Advanced ### Changing focal length The RidgeTec Lookouts have a default focal length of "infinity" which is suitable for most scenarios. However, if you are trying to focus on much closer and potentially smaller animals (as is often the case in biosecurity applications), there are a couple ways to change the focal length: you can order them w/ focal lengths set for much shorter distances (as short as 18”), or if you've already purchased your cameras, you can send them back to RidgeTec to have them adjusted professionally. You can also adjust the focal length yourself, but we do not recommend this as it requires dismantling the camera housing and may compromise its weather proofing or other components. If you are compelled to do it, however, you can change the focal length by opening up the camera body, peeling away the dab of hot glue that prevents the lens from rotating, screwing the lens in/out to adjust the focal length, and putting another dollop of hot glue on it to fix it in place. We've found that the focal length is **very** **sensitive** to small adjustments and recommend making small incremental changes and testing the effects. You can also use a caliper to measure the gap between the two ridged outer barrels of the lens cylinder (see picture below) and use the following guide as a starting point for making your adjustments: | Distance between lens barrels | Focal length | | -------------------------------------- | ------------ | | 2.55 mm | 9-16” | | 2.42 mm (quarter turn tighter) | 17” - 36” | | 2.32 mm (another quarter turn tighter) | 36” - 12’+ |
### When to use AA batteries in addition to the 12v external battery TL;DR: RidgeTec support recommends ***not to use internal AA batteries for very remote cameras*** on solar. However, if the camera is not that far away, they recommend using NiMH AAs in the battery bay so that they can act like a back up when the external battery is fully drained in the solar kit. The disadvantage of using AAs is that if the external battery is dead and the camera is running on internals and they die and the camera shuts down, ***the camera will not power back on even after the sun charges the external battery back up***. If there are no AAs in the camera, however, a sudden loss of power tends to increase the potential for firmware corruption. ### SD card requirements The specs RidgeTec recommend for SD Cards are: * Class 10 speed * 64GB or lower * Full-sized cards only; no micro cards with adapters as they often have compatibility issues * Preferred brands are San Disk and Delkin # Cuddelink cameras How to integrate Cuddelink cameras with Animl More information on Cuddelink cameras on their site ## Integration with [Animl](https://animl.camera/) Log into your Cuddeback account management portal and do the following: 1. **Set Cam IDs on every camera** - when new images come into the Animl backend, it needs to figure out which Project they belong to. How this works is users "[register](https://docs.animl.camera/fundamentals/camera-management#registering-a-camera)" a list of all their wireless cameras' Serial Numbers (or some other unique identifier) to their project using the Animl user, and when a new image gets sent to Animl, it looks at the images' metadata and then routes it to the correct Project. For Cuddebacks, Animl looks at their "Cam ID" field to figure out which camera an image came from, but by default Cam IDs are not set, so you'll need set Cam ID on every camera using the Cuddeback portal. * To set Cam IDs, log into the portal (), and for each camera that you want integrated, click "Details" -> "Device Settings" and then for each listed connected camera, click "View/Edit" and then fill in the CAM ID field (see attached screenshot) and click "Save". * NOTE: the Cam IDs need to be unique not just to your Project but unique to all other cameras registered to Animl. So we recommend using something like "*\-cuddelink-\*" or something along those lines. . Also avoid spaces, special characters, and capital letters.\ We recommend ***not*** including too much location-specific descriptors in your Cam IDs, as the cameras may be moved elsewhere over time and the Cam IDs should ideally not be changed. If you want to represent more human-readable, location-related descriptors to help determine which camera is which, you can do so later on by creating Deployments for the Camera in Animl. More information on Deployments can be found in the Animl Documentation: . 2. **Make sure the Cuddelink relay emails are being sent to** [***animl@codefornature.org***](mailto:animl@codefornature.org)***.*** This can be set by clicking "Details" on each camera in your portal homepage, clicking "Edit", and adding the email address to "Relay Email Addresses" and clicking "Save". # Spartan cellular cameras How to integrate Spartan 4G/LTE cameras with Animl {% hint style="info" %} **Not official Spartan documentation!** This documentation is intended to supplement the Spartan Camera user manual, which can be found [here](https://sites.google.com/spartancamera.com/spartancamerausermanual/table-of-content). {% endhint %} {% hint style="warning" %} **Animl does not support video** Some Spartan cellular camera models support recording video, but Animl only supports the ingestion and processing of still images. Please keep video mode disabled. {% endhint %} ## Overview Integrating Spartan 4G/LTE cameras with Animl is a four step process: 1. **Set up and activate your Spartan Camera -** Camera setup and activation is out of the scope of this documentation, but instructions can be found in Spartan's [user manual](https://sites.google.com/spartancamera.com/spartancamerausermanual/table-of-content). 2. **Enroll in Spartan's "Premium Service" plan -** In order to send automated email alerts, which is required to ingest images into Animl, you must use Spartan's [Premium Service](https://sites.google.com/spartancamera.com/spartancamerausermanual/premium-and-auto-feature-comparison). 3. **Configure your camera to send email alerts -** Animl scrapes and ingests Spartan emails that contain images sent to **. 4. **Register your camera's "serial number" with Animl** - In order for Animl to route your images to your Project, you first need to [register](https://docs.animl.camera/fundamentals/camera-and-deployment-management#registering-a-wireless-camera) it. More detailed instructions on steps 3-4 can be found below. ## Configuring your camera to send email alerts After activating your camera and enrolling in Spartan's Premium Service (steps 1-2 above), you will need to configure your camera to send emails to **. This can be done through the Spartan Web Portal (). ### Email alerts Once you've logged in, navigate to **Account** > **Email Delivery** > [**Email Contacts**](https://my.spartancamera.com/account/contacts) and add <_animl@codefornature.org>:\_
You may also want to add a personal email address temporarily to confirm sure the cameras are sending alerts. Next, navigate to **Account** > **Email Delivery** > [**Delivery Options**](https://my.spartancamera.com/cameras) to make sure that for each new camera, ** is checked ON under the "Email Recipients For: \" section. ### Thumbnail settings We recommend setting your thumbnails to "large". The larger the thumbnail that gets sent along with the emails, the more pixels Animl's AI models have to work with, and the more accurate the predictions will be. However there are battery/solar and data usage tradeoffs associated with sending larger images and thumbnails. Good guidance on which image and thumbnail size settings should be used for different Spartan camera models in different circumstances can be found [here](https://support.spartancamera.com/hc/en-us/articles/360010407633-Photo-MP-resolutions-and-thumbnail-normal-vs-large-settings). ## Register the camera with your Animl Project The final step is to [register the new cameras](https://docs.animl.camera/fundamentals/camera-and-deployment-management#registering-a-wireless-camera) with your Animl Project. Before you leave the Spartan Web Portal or mobile App, make a list of all of your new cameras' "*Descriptions*". Spartan images to not contain camera serial numbers in their metadata, so Animl uses the camera Descriptions as unique identifiers instead. If you have not [changed your cameras' Descriptions](https://support.spartancamera.com/hc/en-us/articles/360010538953-How-to-change-the-camera-name-description), they will be the cameras' unique IDs (often something like `GL-MLTeb-231554`). Those IDs are fine to use from Animl's perspective, but if you do change the Descriptions to something more human-readable, you'll need to use those updated Descriptions in place of the unique IDs as "serial numbers" when you register your camera with Animl. If you are unsure whether you have changed the Description or what to use if not, send a test email to your personal email account. The emails' subject line template is "**\[date photo taken] - \[camera description]**". So if you don’t change the camera description, the email subject lines will look like something like “**2025-01-31 14:35:00 – GL-MLTeb-231554**”, and you can use the “**GL-MLTeb-231554**” part as the "serial number" when registering your camera with Animl. If you did change the Description (e.g. to something like "Camera 2 East"), the subject line would be "**2025-01-31 14:35:00 – Camera 2 East**”, and you'd use “**Camera 2 East**” as the "serial number" when registering the camera with your Animl Project. #### Arm the camera and take some test images Follow Spartan's [instructions for testing the camera](https://sites.google.com/spartancamera.com/spartancamerausermanual/test-the-camera?authuser=0). If everything is working correctly, you should see new images show up in both the Spartan web/mobile app and in your Animl Project. # Hardware deployment best practices Tips for installing camera traps in the field ## Equipment to bring {% tabs %} {% tab title="Materials" %} * t-posts - or tripod, pole, and hardware mesh * Hose clamps / [hose clamp fabricating materials](https://www.amazon.com/gp/product/B09NSQWLSB/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8\&psc=1) * Pressure treated wood wedge spacer (if the camera needs to be angled down towards the ground) * Gear ties * Zip ties (the [reusable kind ](https://www.amazon.com/gp/product/B06XG8G91Y/ref=ppx_yo_dt_b_asin_title_o01_s01?ie=UTF8\&psc=1)are a plus) * [Rescue tape](https://www.amazon.com/gp/product/B001JT73D8/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8\&psc=1) * Electrical tape * Electrical conduit (if you need to place cables on the ground) * Desiccant packs (e.g. silica gel packs) {% endtab %} {% tab title="Tools" %} * sledge hammer * ratcheting screwdriver or socket wrench with sockets (for tightening hose clamps) * pliers and tin-snips (if fabricating your own hose-clamps) * box-cutter * screwdriver * cordless drill, titanium drill bits (if you need to drill through metal) * hack-saw (if using electrical conduit for cables) {% endtab %} {% endtabs %} ## Positioning solar panels Ideally, solar panels should be south facing and in plenty of light, but in our experience you can get away with solar panels positioned in pretty shaded areas. ## Hardware / mounting recommendations We found that using heavy duty [T-posts](https://www.lowes.com/pd/T-Post-Post/3160019) as a stake, and attaching the camera/repeater, batteries, solar panel, and antenna to the post directly via hose clamps worked well in most conditions. In order to angle the camera more towards the ground (for detecting small rodents for biosecurity purposes), we will often place a wood wedge fabricated out of pressure treated lumber between the camera and the T-post. If it is a particularly windy location, it’s safest to install two t-posts side-by-side: one with the camera, and one that can sway freely in the wind with the battery and solar panel.

A camera set up on two T-posts (camera on one, battery and solar panel on the other) to reduce wind-sway-induced motion sensor triggers.

### Dealing with impenetrable ground If the ground is too hard to pound a stake into, we have had luck wiring a \~3’x3’ sheet of hardware mesh to the feet of a tripod and piled rocks on top of the mesh, and that seems to provide enough stability:

Beneath the pile of rocks is a sheet of metal hardware mesh that the feet of the tripod are wired to. The tripod is not physically fixed to the ground.

### Wire management Try to keep the wires as tidy as possible. You should always leave a little length to create ***drip loops*** anywhere the wire is entering a camera/repeater/battery, and be sure to apply rescue tape and then a layer of electrical tape at all connection points. The tape should be wrapped around the wires starting at the bottom (closer to the ground) and spiraling upwards (to the sky). This layering effect will allow the tape to act like shingles or siding on a house, keeping the water running down the wire and not infiltrating any cracks in the tape. As an extra precaution, a final small zip-tie around the top of the taped section will help prevent the electrical tape from unwinding over time due to exposure to the elements. Also, many animals will chew on the wires if they’re too low to to the ground, so try to keep all cables at least \~14” off the ground, and if you must lay cable on the ground (for example, if the solar panel is mounted on a different post than the camera and battery), use a length of conduit to protect the wire. ### Dealing with humidity & wet conditions We recommend adding fresh desiccant packets to all battery and camera housing before leaving. For cameras, where the space within the housing may be limited, we recommend using desiccant [sheets](https://www.reconyx.com/product/desiccant-sheets-universal) sold by Reconyx. ### Before you leave the newly installed device * Write down the camera/repeater’s Serial Number * Note down the Lat/long of location * Take ***lots*** of photos! They can be an very helpful to reference, months from now, when you can’t remember what the set up looks like and need to perform maintenance on it. You won’t be sorry! # Network cost calculator Estimating the cost of deploying a wireless camera network The Nature Conservancy uses the [following spreadsheet](https://docs.google.com/spreadsheets/d/1bNzgoUpzB279hKlVgqEsDH7lPRs8el1AP3Bu3lkhfs4/edit?usp=sharing) to estimate the cost of networked camera trap deployments. A few things to keep in mind: The different network sizes in the spreadsheet (e.g. "*Medium RidgeTec network*", "*Large Buckeye network*") are hypothetical deployments used as a starting point for ball-park estimates of various types of networks. The hardware needs of each network are highly variable and location-specific, and large hardware purchases should generally not be done without visiting the locations and ground-truthing assumptions (testing available cell-service, line-of-sight challenges, etc.). In particular, the need for more or less repeaters in a Buckeye network can significantly affect the total cost of a network, and that will depend heavily on your location's topography and foliage. \ \ That said, you can get pretty far without needing to go out in the field, so to get a more accurate estimate for your project we recommend the following workflow: 1. Determine camera needs (quantity, locations) 2. Using the [FCC's national map of cell carrier coverage](https://fcc.maps.arcgis.com/apps/webappviewer/index.html?id=6c1b2e73d9d749cdb7bc88a0d1bdd25b), evaluate whether cellular cameras might be an option (if so, you'll likely want to use them) 3. If not, you'll need to use Buckeyes or another camera trap with local networking capabilities. Use Google Earth Pro for desktop to conduct a [viewshed analysis](/tnc-wireless-camera-trap-documentation/buckeye-x80-networked-wireless-cameras/deploying-and-moving-the-cameras-and-repeaters/before-you-begin#plan-your-deployments) to evaluate quantity and location of repeaters and base stations you'll need to reach your desired camera locations. 4. Download/copy the cost calculator spreadsheet and edit quantities to estimate total costs. To download the spreadsheet and edit it to estimate the cost of your own network, follow the link above and navigate to **File** > **Download** > **Microsoft Excel** You can also copy it to a new editable Google sheet by navigating to **File** > **Make a Copy**. {% hint style="danger" %} We will try to keep the per-unit costs up-to-date, but be advised that the prices may have changed since last publishing it. {% endhint %} {% embed url="" %} # Contact us If you have any questions or feedback on the information in this guide, we'd love to hear from you! We just ask that because we're a small team with limited capacity, please search the documentation before reaching out to make sure your questions haven't been answered elsewhere. If not, feel free to drop **Nathaniel Rindlaub** a line at **\.\@tnc.org**. # Recommended Citation The Nature Conservancy, California. \[year]. Wireless camera trapping guide. San Francisco, California. . (Date Accessed)