article / 7 December 2023

How to Choose a Biologger - Collaring Koalas with Matthew Stanton

In the penultimate article in my series examining how people find biologging tech for their projects, I spoke with Matthew Stanton about developing custom biologging technology for studying koala behaviour.

Read more about this series here.

I spoke with Matthew Stanton about developing biologgers to study koala behaviour and physiology. His team used a variety of technologies in their study including a GPS collar, an heart rate logger implant and an acoustic monitoring device. Matthew knew that it was likely they would need customised products as their project was pushing the envelope of what had been done with koalas. 

GPS Collars

The main criterion for selecting the GPS was the number of waypoints it could reliably collect in a day for more than a six-month period without recapture.

Initially Matthew had hoped to be able to engage the enthusiasm of some local manufacturers or the engineering school in his university. However, his small demand for units put many companies off and access to the engineering school became limited when COVID-19 hit and they diverted their efforts into solving infection problems.

Instead Matthew and his team began to research what products or companies could fulfil the project’s tech goals. They used word of mouth and previous experience with biologging companies, to narrow down who they reached out to for the hardware they needed. Some academic research was also done to confirm that the companies had worked on similar studies. 

This research gave them a good idea of what companies they would go with and they were able to put this into their funding proposal. Giving them a good idea of the budget they would need and thus flexibility when choosing products. 

There were really only four companies that Matthew looked into that made units to achieve what the project needed. About half the companies responded to his queries but Milsar gave the most satisfactory and obliging responses. From their correspondence, the Milsar solar power system looked to be the best, but until actually testing the units it was difficult to know for sure the system would work for their project.  

Matthew was luckily able to look at a fellow researcher’s Milsar GPS loggers and the data they were delivering in a real-world deployment. This confirmed that the solar performance roughly corresponded with the advertised capabilities, however, the GPS accuracy was not fit for their purposes in monitoring animals in heavy forest. Talking with Milsar about the results, they were able to offer revised firmware GPS units which dramatically improved performance but at a small increase in power use.

Milsar’s willingness to customise for the project’s purposes and that they provided the best and most cost-effective product ultimately made Matthew choose them as their manufacturer’s for their products. 

The Milsar GPS collars with built in accelerometer, magnetometer, temperature and light sensors ended up being mostly reliable although there were occasional glitches with the firmware. The main limitation of the units was their proprietary nature.

Any changes the project wanted to make to the firmware had to go through Milsar and questions they had about the componentry in the units and the power use of various functions remained unanswered. This has made Matthew reconsider the use of proprietary technology for future projects. For the most part Milsar delivered what was needed for the project goals. 

Photo credit: Matthew Stanton

Implanted heart rate logger 

Comparatively, choosing the heart-rate logger implants was simple because only one company was making affordable units; Star-Oddi. They just had to decide what size and sensor capacity they wanted in their units. Star-Oddi were also very responsive and helpful which helped to make the choice easy. 

Star-Oddi is highly recommended by Matthew and his team. Their implantable biologging units were reliable and affordable and their service was fantastic. However, using an implantable device turned out to be problematic for the project’s implementation.

“I will be reluctant to use items that require a surgical procedure on a koala in the future. Getting surgical procedures approved was problematic and having to schedule vet services into multiple parts of the project became complicated (particularly due to COVID-19 restrictions). During this project we established that measuring koala heart-rate with an external audio device was feasible. We would pursue this method in future projects.”

Audio loggers

Selecting an appropriate audio device for recording long-term audio to determine koala behaviour was much tougher because there was nothing specifically available on the market. Instead, Matthew went through a process of purchasing various voice recorders and pulling them apart and testing their acoustic properties and their power draw. Many units turned out to have built-in high pass filters which made them useless for the project’s purposes. The MicroMoth looked promising but had a much greater power draw than the other units they were looking at.

Most of the audio circuitry devices they considered were from unknown original manufacturers who could not be contacted. However, three developers were quite responsive to the project’s queries. The team working on the MicroMoth were great and sent them a sample to test. ASD (Vesper logger) were quite responsive but were unable to answer some important specific questions relating to power draw and low frequency response. 

Laboratory 2 in Moscow had a sales company who were very responsive to Matthew’s queries and organised some minor customisation of their products to meet his needs. This, like the choice to go with Milsar, made them seem like the best choice of manufacturer. 

The audio devices from Laboritory-2 in Moscow were incorporated into a 3D-printed housing of Matthew’s design. He intended for both the housing and the circuit to be reusable. However, the design of the circuit meant that it could not be easily potted in resin. All communication with the device was through a MicroSD card and a single button on the unit. The microSD card, button and integrated MEMS microphone could not be covered with resin so he relied on the case to keep them waterproof. As well as protecting the circuit and battery, the case had to be able to conduct sound so designing the case was a careful balancing act between acoustics and protection. 

This ended up causing the most trouble as some of the circuits failed during record rainfall. Others also failed, perhaps due to peculiarities with some early versions of the device firmware (for example one unit would always stop recording after the first file). However, they still achieved an average of six weeks of audio data per deployment which is an order of magnitude higher than has ever been achieved before and the audio quality was surprisingly good.

“With Russia the source of the audio circuits, and trade with Russia currently restricted, we would need to find an alternative source of audio devices should we wish to repeat the project. We might consider using ASD devices if they can demonstrate infrasound recording.”

With this case study we can see when researchers will need to develop custom biologging solutions and also the difficulty with this approach as it means a higher degree of tech literacy to navigate through the different options. In Matthew’s case it was especially important to have experience with the tech to figure out what modifications would be necessary. 

Thank you to Matthew Stanton for answering my questions about how he developed his technology and sharing his experiences with using the biologgers for his project. 

Look out for my last article in my series where we discuss using DIY biologgers to help protect endemic plant species from livestock grazing!

Banner photo: KlausMayer


Hi Lars,

Yes, the audio devices had a number of issues when it came to time recording.

  1. The clock on these devices was set via the microSD card. You would program the card with a start time and then have to attempt to match that time with the moment you activated the recorder via the single interface button. That sounds simple enough, but I still managed to get start times out by a couple of minutes or even by an hour in one case.
  2. I had to use a time synchronisation signal (an audio clapper board if you like) with a loud sound marker and a spoken time and date to calibrate the file dates. In theory I would have been using the clapper board at the end of the recording as well but only three of the deployments made it through to that final calibration. I was able to include calibration tones at a couple of times near the start of the deployment but obviously it was less than ideal having to extrapolate rather than being able to interpolate the time.
  3. The card format on these devices was FAT32 which has a number of limitations with regard to time. Firstly the time resolution for FAT32 is two seconds. This may not seem like a big deal but it has been a bit of a headache when labelling sounds that go across sound files when those two files effectively look like they are overlapping according to their time stamps and logical lengths.
  4. To further complicate things, the way UNIX and MS Windows (NTFS) systems convert time stamps is different (and that is before you start copying files onto remote servers). Essentially, file systems have to convert times to their own system and decide if it is UTC or local system time or some other time. There is a nice summary here: 
http://www.pascal-hacker.de/info/it/sw/dst.htm

Unfortunately, I was blissfully unaware of these differences and I was using two different computers while I was copying data (one UNIX based and one Windows based) so I had a nasty surprise on this front. Daylight saving was an added complication for all of the data streams including weather and satellite derived data. Whoever thought daylight saving was a good idea never had to manage continuous data streams across the change period!

5. The audio devices generally kept time to within +1 to +10  seconds per day. This kind of error doesn't sound that bad but it quickly adds up when you are deploying for months. I discovered that the error was different with different versions of the firmware with later versions being substantially better. The problem seemed to come about each time the device closed and opened files. A kind of digital hiccup. If I do this again I would save audio with a larger file size which seems to reduce these errors. And I will always try and incorporate calibration tones as a failsafe mechanism.

6. The GPS devices naturally kept impeccable time but even these had a small issue. You can schedule how often you want various measures to be taken, but there is no telling exactly how long it will take to make that measurement so if you have attempted to synchronise measurements, they quickly get out of sync. Even within the GPS loggers, the burst accelerometry measures could not be kept in sync with the location records because they used different timing methods. The solution was just to take as many measures as we had battery power to spend so as there was always another nearby measurement. The clocks in the Star-Oddi devices seemed to be quite reliable with very little clock drift. They always work in whatever time the computer system time was using when they were started.

I think the long term solution for audio time management is to have the devices linked to a GPS so they are calibrated every time there is a new GPS record made. It would be great to see manufacturers move past FAT32 and at least use exFAT format for their storage media. FAT32 is not really fit for purpose.

Which devices are you using Lars?

Add another post

Want to share your own conservation tech experiences and expertise with our growing global community? Login or register to start posting!