That is a great point and the current international trade climate has been making supply chain even more difficult. This also deeply affects US companies given much of the US goods manufacturing and assembly happening in China. Over the last few years, I have been seeing US hardware companies (e.g. drone platform and component OEMs) sourcing their goods from India, Turkey, Canada, and more recently in African and South American nations. Because of the last 3-to-5 years of increasingly restrictive and costly international hardware trade, there has been a emergence of specialized component manufacturers internationally. For European companies interested in providing hardware services to the US, I would suggest diversifying the supply chain beyond China. Given the current climate and trends, that added supply chain resilience may be a good idea, regardless of work with the US.

True, the US ecosystem is a challenging space right now, for basically all sectors. 

We should not let the US chaos prevent us from engaging with opportunities in other nations' multi-use markets. A company's ability and journey to tap into other markets is very unique to them (product, team, finances, infrastructure, agility), and some simply cannot adapt. There is no one size fits all (or even most) solution when it comes to multi-use strategies. It is important that  we are systematic about evaluating the cost to adapt our product-service to a different market, and the value of new opportunities in that new market, without losing track of underlying conservation and social good needs.

Thank you @loveness 

Hi Carly,

Thanks so much for your thoughtful message—and for introducing me to Freaklabs! BoomBox looks awesome, and it’s exciting to see how closely our goals align. There’s definitely potential for collaboration, and I’d be happy to chat more. Their system is super efficient and I think both of our systems have a place in this space. 

Affordability and reliability were key considerations when I started building Orpheus. I wanted to create something rugged enough to survive in the field year-round while still being accessible for conservationists with limited budgets. The full-featured unit is €1500, and the basic model is €800. That pricing reflects both the hardware and the considerable time I’ve spent writing and refining the system—it’s all about balancing performance, durability, and keeping it sustainable for the long term.

Even the base unit is more than just a playback device. It logs every playback event, duration, and species, with enough onboard storage for two years of data, and it automatically converts the logs to line protocol for easy integration into platforms like InfluxDB.

On top of that, Orpheus actively logs and graphs temperature, humidity, atmospheric pressure, and battery voltage. During deep sleep, it interpolates the environmental data to preserve meaningful trends without wasting energy. You can view any of these on it's 5" touch screen or view it in the cross-platform app that will support both Android and IOS once I'm done programming it.

As for audio specs:

• Recording is supported up to 96kHz,
• Playback is full 24-bit, both MP3 and WAV formats
• The system currently supports recording audio clips, reviewing them, and even adding those clips directly to playlists on the device.

That said, for bat research, I know ultrasonic capability is essential. While the current hardware doesn’t capture over 100kHz, I’ve already done the research and identified alternative audio interfaces that would support that range. If that’s a need researchers are interested in, I’d be open to building out a dedicated version to meet those requirements.

Power-wise, it runs indefinitely on solar, even under partly cloudy conditions. It uses a LiFePO₄ battery, and depending on usage, it can operate for up to two weeks on battery alone. It also supports external power from 12V or 24V systems, and solar input from 12V to 70V, so it’s pretty adaptable to various field setups. it also can operate from -5 to 70C (still testing that), but the hardware should be capable according to specs. Your correct though in places like the rain forest that could be challenging and an alternative would need to be considered. 

The software is written modularly to allow for expansion based on user needs. For instance, I’ve already integrated support for a rain sensor that can pause playback if the user chooses that, and could easily include PIR, microwave, or other sensors for more specialized triggers.

Regarding durability, I’m currently testing mesh cable sheathing to deter rodents and other wildlife from chewing the wires—this was a concern raised by one of the teams using Orpheus, and I’m designing around it.

Also, Orpheus includes a seasonal scheduling engine—you can define your own seasons (like Migration, Breeding, etc.) and assign unique playback playlists to each. The device uses astronomical data (sunrise/sunset) based on your provided lat/lon and time zone, and automatically adjusts timing offsets like “1 hour before sunrise.” The goal is truly fire-and-forget deployment.

I'm open to adding any features or sensors that might be useful within reason.

I’m curious though, what specs would make a recording device for bats an indispensable tool? What features don’t already exist  on the market that should?

Warm regards,
Travis

Thanks for the reply Alan.

The research question is: 

If I modify the infrastructure (roads, wildlife crossings, fences, water features etc basically any geospatial feature) in the environment can we predict where the deer/elk will move to based on those modifications? 

The goal is to prototype the new layout/features of an area that contains a large road to establish the best measures (wildlife crossings, fences) and placement to prevent elks crossing the large road as much as possible. The team want to minimize vehicle collisions. 

The second order effects are also interesting. If we close off an area they are used to going, does that change where they go, and if so, where?

Hi Vivian,

Thank you so much for your reply! I appreciate the pointers on species mixing, to clarify: I have been experimenting with deer data, but for once the project is underway I will be given access to lots of elk data, which I would then use for the elk simulation. The elk data will be from the location of interest.

A few questions if you have time...

1. When you say 'model', do you mean an AI model, or do you mean a more general take: a set of programmatic rules you have encoded to control the agent?
2. Similar to above, when you say 'analyze the data', are you manually extrapolating rules from looking at charts you make of the data, or are you selecting data parameters for funnelling into a machine learning model?
3. When you say account for different time/distance scales, are you suggesting that looking at immediate next move is not sufficient and I need a second "layer" for agent decision-making which might be about seasonal drivers, or at least next move is date/season aware?
4. In the models you have made are you ever encoding rules as "forces"?.. some things attract the animal to move to it, other things repel the animal to move away from it and the animal moves based on all the "forces" combined?

I have more questions, like whether you include feeding or memory in the agent, if you primarily examine land type it is on and can move to, topography... but the 4 listed questions will give me a great starting point.

If you have any good examples/literature for elk/deer on movement models I would love to take a look.

Thank you so much!

David