I have tens of thousands of camera trap bycatch African mammal videos that are available for analysis to anyone who can turn them into published papers, data that is actually useful for conservation, or publicity for wildlife and conservation.

They are already manually sorted into carnivores / herbivores and the carnivores are sorted and/or tagged to species. I do not have the resources to do anything further with them. 

Hi Akio!

Is there any more extensive documentation for Loko than what I see on the website in the link you sent? I'm curious to learn more, such as what the mean and median positional errors are, and how long the battery would last at various fix intervals (such as 5 minutes fixes vs 15 minute fixes), whether the device is capable of taking more than 6,500 consecutive fixes if it is able to regularly connect to the ground device, how it handles failed fixes (i.e. there are no satellites detected), etc.

I'm working on a project in which we are deploying GPS receivers on gopher tortoises. As with many devices, one of our biggest challenges is finding a device that can store a lot of fixes so that we can leave it out for long deployments (we have been looking at devices with pure receivers, and no transmission option), and as someone else mentioned, ruggedness is very important as well- the turtles can be very hard on trackers. These animals present some unique tracking challenges because they spend much of their time underground, meaning that the device will be unable to detect satellites and/or get a good fix most of the time. We also value customizability- someone else pointed out that we biologists have been known to open up devices and DIY them for our own uses- and we are wont to do the same with software as well, if able. For example, for my study we are interested in options where we can choose an adaptive fix interval, for example, every 5 minutes but only during daylight hours, to save on battery as well as memory space. I know triggered firmware is a common request as well- various groups will use different sensors, such as light, temperature, moisture, float, accelerometer, etc. to tell a device when it's appropriate to take a fix (when the animal moves, when it surfaces, etc.).

Best,

Jocelyn

Great discussion — the trade-offs you're navigating with Loko are exactly the right ones for open-source wildlife tracking.

A few thoughts on the points raised, particularly for large animal tracking in Africa with limited budget:

On waterproofing the LoRaWAN antenna — the antenna does need to protrude or be positioned at the surface of the enclosure, but this doesn't have to compromise IP rating. A simple approach is to use a helical or meandered trace antenna on the PCB itself (no external stub needed) and cast the entire PCB in epoxy or use a conformal coating, with the enclosure providing the mechanical protection. For collar deployments on large mammals, the antenna is often routed along the collar belt itself as a flexible element, which also improves radiation pattern.

On geofencing for large animals with infrequent fixes — I'd agree with the caution raised earlier. For animals with large home ranges like elephants or lions in Africa, a 1-4 hour fix interval means an animal can travel 10-30km between fixes. Geofencing only works reliably when you can predict where the base station receiver will be relative to the animal's trajectory. For open savannah, a LoRaWAN gateway on a fixed elevated point (a termite mound, a tree, a ranger station) with 10-20km range is more practical than trying to download when the animal passes close.

On memory — 6,500 records at hourly fixes gives about 270 days of logging, which is enough for most large mammal deployments. The limiting factor in practice is usually battery rather than storage.

I work with LoRaWAN-based tracking systems and have field experience in southern Africa — happy to discuss specific deployment scenarios.

Hi Kristián. Apologies for the late response, but I just noticed your query. In a nutshell, direct LoRa connection is simpe and easy and all you need for reporting sensor data. Also, assuming you only need to send data occaisonally, you can minimise power usage with direct connections whereas LoRaWAN need to be always listening to other nodes.

I have just started a field trial with a few DX SMART LR02 modules to transmit trap activation to a central location. DX SMART modified the modules for me so they transmit their unique ID when activated. You can probably use the same with your sensors. If you send me some detail of the sensors you use, I can have a look at it for you. 

Hi — I've worked with both LoRa and LoRaWAN in field deployments and wanted to add some practical perspective.

The LoRa vs LoRaWAN choice really comes down to three questions: do you need bidirectional communication, do you need to reconfigure devices remotely after deployment, and do you anticipate integrating commercial off-the-shelf sensors in the future?

If the answer to all three is no — for example, a simple one-way sensor network sending periodic GPS or environmental data to a fixed gateway — raw LoRa is perfectly adequate and significantly simpler to implement. The SX1276/SX1278 modules are cheap, the API is straightforward, and you avoid the overhead of OTAA/ABP join procedures, MAC layer management, and duty cycle limitations.

However, there are two scenarios where LoRaWAN is worth the added complexity: first, if you want to send downlinks to reconfigure sensors in the field without physical access — invaluable for wildlife tracking collars where changing sampling rates or triggering a GPS fix remotely can extend battery life significantly. Second, if you want to plug into existing infrastructure like The Things Network or ChirpStack without building your own backend from scratch.

My practical recommendation: for a small closed network of fixed environmental sensors, start with raw LoRa. For anything involving animal-borne tags, multi-site deployments, or integration with platforms like EarthRanger, go LoRaWAN from the start — retrofitting it later is painful.

Happy to share more on specific hardware choices if you describe your use case.

Brett, you may reach out to @Lucille, who under the auspices of the Partnership  for Observation of the Global Ocean (POGO), the Scientific Committee of Ocean Research (SCOR), and the International Quiet Ocean Experiment (IQOE) is managing the development of LC-MARE a low cost marine acoustic recorder.  An ultra low power ADC is indeed an important component, so there may be some synergies.

This is really interesting — especially the part about experimenting with different high-value uses.

I’m currently working on a small edge AI project for ecosystem monitoring, and it’s made me realize how different things can look outside of controlled environments.

Out of curiosity, during those experiments, what ended up being the biggest constraint — was it more about technical feasibility, cost, or something unexpected in real-world conditions?

cool! 
When you say: "...first usable result that validates our hardware and software signal chain." can you share what those chains are? 

As for connectivity, yeah, that's a HUGE challenge ... Can you do SMS-level connectivity to Starlinks?

I presume you'd want to log basic temp/salinity, and perhaps include a basic accelerometer for wave motion over something like MQTT. 

As for pushing down bioacoustic processing to the devices, yeah, would be awesome to do some minimal envelope threshold detection, and just send back compressed versions of 'the good stuff' .  Maybe even listen for propellers and/or fishing sonar too, and send EarthRanger alerts.

And of course you'd want to do OTA updates, which in turn introduces security, etc.

Fun project!

Hi Andrew,

If near real-time data is of interest, another option is to move away from standalone loggers and use a low-power wireless sensor approach. The BME280 Harold mentioned would be fairly straightforward to integrate where I²C/SPI interfaces are supported.

The main advantage is visibility. Instead of discovering issues perhaps months later, you would see both data and device health in real time. That can be useful if a unit fails or gets damaged, which sounds like risk in these nesting boxes. It also allows you to vary sampling rates if you want higher resolution during periods of interest.

Deployment practicality will depend on site conditions, but these types of systems are already being used in remote ecological settings, including arboreal installations where infrastructure is mounted in/around canopy environments.

Happy to share more detail if it is of interest.

Cheers,

Simon

Hi Andrew,

We used some bluemaestro discs and they seemed to be very good, until they stopped working. No reason, they would stop working, they were indoors. 

So wouldn't recommend them, specially for a challenging environment (nests).

Good luck.

Hi Andrew,

We (Margo Supplies) are in beta release of our temp logger project. This is a marine sensor for us so humidity is not packaged in. There may be some potential to do that depending on timeline? Feel free to send me a DM with project details and we can discuss. 

Cheers,

Jared 

Greetings Nik, it is interesting to see to the project you are working on.  If there's anything I can do to help with my skillset let me know.

Thanks, Mike

do I see in the diagram some elements positioned below the sand? (perhaps below the tide-line and saturated with water..?)

Hi @jennamkline , are you in the SCB Drones and Data Working Group? I think it would be great to have that as a topic for discussion during the next meeting! I'd be keen to hear more about this work.

@annavallery this might be of interest to you.