Yes, thanks Riley and Kim. Someone suggested WIS and I am currently in discussions with them. Their system seems especially well suited for the purpose and I am hoping it works out.

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 Phil,

That sounds as if it might work (but probably with a turn trigger of around 45 degrees), and the baboon collar is well within the weight limit. Where can I find more details about the collar?

Peter

Thanks Phil - I have e-mailed you.

Peter

Thank you! I will follow up by email. 

Thanks Kim, yes we're aware that PIR has many pitfalls, especially when it comes to small things far away, which is often the case for us.  But we can accept missing some detections for indexing purposes if we win in other areas like battery life, size or affordability.  We're currently able to detect small birds from a useful distance with Browning trail cameras. 

If I do dust off my soldering iron & actually make something it will be on a scale of 1, for dataset building proof of concept stage, not for large scale use.  It would likely include a variety of sensors so I can make meaningful comparisons & propose a sensible combination.  The detection part could be as simple as pixel subtraction from video footage I imagine.   

Thanks Jack, that's an interesting repo.   

Thank you for this valuable information!

Some of the features you mentioned can be quickly added to Loko, while others require more consideration. Loko’s communication is one-way—meaning the transmitter doesn’t know whether the receiver has received the data. This design choice is made to conserve battery life. However, all data is logged internally and can be accessed via USB.

I will add GeoTIFF loading to the Loko App. Currently, Loko is not suitable for wildlife tracking because it is not waterproof, but I am working on improving its mechanical design.

Loko already supports multiple connections, allowing many transmitters to connect to a single receiver or/and multiple receivers.

Regarding encryption: What do you mean by "Encryption should not be optional"?
Are you suggesting that communication should always be encrypted by default? on loko I made it user-configurable because encrypted data packets are 32 bytes, whereas unencrypted ones are 18 bytes. A smaller data packet improves reception sensitivity and extends the transmission range.

In your opinion, what would be a reasonable price for such a device? This is very important when adding new hardware features.

Cheers, 

Akio)

Hi Herhanu , appreciate for your valuable feedbacks.

1. can you explain what type of release mechanisim do you mean ,   picture will be much helpfull .  do you mean with a remote release mechanisim activates and release the tracker from crocodile collar?
2. how far data need to be sent ?    with a mesh network of Loko receivers wide range of area can be covered i guess.
3. long distance transmission is very challanging  when transmitter is very close the ground , on crocodiles especially. 

for what purpose do would you use accelerometer data? is there any specific use case?

Cheers, )

Thanks so much for all the advice!! This seems very achievable. We don't mind having the fibre optic fixed in place as we planned to have a shorter one specifically for this project. Im currently waiting to hear back from Sexton but if not, we will try DIY something based on your suggestions

Nice one - what kind of thing would you use this for? 

~500mA peak current, it has a similar power profile as the current RockBLOCK product, in that it needs lots of juice for a for a small period of time (to undertake the transmission) we include onboard circuitry to help smooth this over. I'll be able to share more details on this once the product is officially launched!

~500mA peak current, it has a similar power profile as the current RockBLOCK product, in that it needs lots of juice for a for a small period of time (to undertake the transmission) we include onboard circuitry to help smooth this over. I'll be able to share more details on this once the product is officially launched!

@pchwalek Thank you for the response! The project which I am currently developing is exactly as you mentioned in the LoRa use case: a parent unit in the centre of a conservation area which is to recieve one way packets from child sensor units spread around the perimeter of the protected area. The difference in LoRa vs LoRaWAN is much more clear to me now, and I'll try me path with LoRa based on the feedback :)). 

If you happen to have resources to recommend in terms of developing and using LoRa, I'd be glad to have your recommended references as a starting point. 

Best regards,
Kristián

@Eric24 The use case is as I wrote to Patrick: "a parent unit in the centre of a conservation area which is to recieve one way packets from child sensor units spread around the perimeter of the protected area.". The packets are simple pings on whether the sensor wants to send an alarm to the rangers in the conservation area and a percentage accuracy that e.g a poacher is detected on the perimeter. 

The delivery guarantee requirement is thus very high, but it is not necessary to send signals often if an event is not occuring (which should not be more frequent than once a day at max). Perhaps the delivery guarantee could be fixed by simply sending an alarm signal many times? Furthermore, it is not foreseen that the sensors need to be dynamically reconfigured. 

Thank you for the response and insight in your development process! I'm planning to use very similar modules as you described. 

Hi Julia,

Thank you for your reply. Your work on connected acoustic recorders sounds very interesting, and we’d love to learn more about your application and the enhancements to Bugg. We’ll contact you soon to arrange a discussion.

Looking forward to it!

Thank you,

Best regards,

Sebastian

Hi Lucille,

Thank you for your reply! We’d be really interested in learning more about your developments. We’ll contact you soon to arrange a discussion.

Thank you.

Best regards,

Sebastian