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

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! 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. 

Hello, we do not have a website yet. We are exploring where our technology can provide the most significant value compared to existing products. We would be very interested in discussing this with you.

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

Currently, the main focus is visual footage as we don't render audio data in the same way as we do for acceleration (also: the highly different frequencies can be hard to show sensibly side by side).

But In this sense, yes, the new module features 'quick adjust knobs' for time shifts: you can roll-over a timestamp and use a combination of shift/control and mouse-wheel to adjust the offset of the video by 1/10/60 seconds or simply enter the target timestamp manually down to the millisecond level. This work can then and also be saved in a custom mapping file to continue synchronisation work later on.

 

No, not yet. The player we attached does support slower/faster replay up to a certain precision, but I'm not sure that this will be sufficiently precise for the kind of offsets we are talking about. Adding an option on the frontend to adjust this is quite easy, but understanding the impact of this on internal timestamp handling will add a level of complexity that we need to experiment with first. 

As you said, for a reliable estimate on this kind of drift we need at least 2 distinct synchronized markers with sufficient distance to each other, e.g. a precise start timestamp and some recognizable point event later on.

I perfectly agree that providing an easy-to-use solution does make perfect sense. We'll definitely see into this.

Thanks for the advice Wade!

It will be great to hear Tim's feedback, but thanks for your advice! I think Lithium batteries are the next step for us. I have successfully gotten it working with a power bank attached, but that really impedes its portability. Will also fiddle around with the GPS per your recommendations...

 

Hello Walter

Thanks for your input. I have achieved better results with the puc when hooking it up to a powerbank. Have got them set up to "recording only", and GPS to low power mode. Looking to now try eliminating the need for a power bank as that impairs the portability of the puc.

 

Hi Kim, the yellow sticky paper I have today is around 10cm by 30cm. I took a picture with a really good cellphone of the whole paper and the resolution was not good enough (3072 × 4080 in Ultra HDR). This gave me 10pixels / mm, but I could not get a precise enough model with yolo at this resolution for the Thrips... I will play around with the cellphone for a bit more and see if 2 or 4 pictures are enough. We even made a support for the cellphone to have always the same distance (but if I could avoid this for practical reasons in the future would be fine too). With the digital microscope we used we got over 50 pixels per mm and so got a quiet good model in identifying them (but time consuming), sometime dust also shows up and with the phone camera you can't differentiate Thrips and dust ;)))) Lets see if I can edit my post to include some cellphone images into it.

So, updated the text a bit with images cropped at 100% zoom :) we are already happy with the time reductions we got, but... would like to get at least 90% time reduction instead of 70% :))) we know that with a very expensive and high power camera we could probably do it, so one approach we are thinking of is just taking a closer macro picture with a cellphone of let's say 1/3 or 1/4 of the sticky paper and use this data instead of everything...  or take 2-3 pictures (but we don't want to waste time in sticking the images together).