Intelligent Bat Detector

by Tecwyn Twmffat

17K8339

Intro: Intelligent Bat Detector

Bats emit echo location calls at high frequencies to enable them to 'see' in the dark and we humans need to be able to monitor the species to help prevent destruction of their environment during our ever increasing exploitation of the planet. Recording and analysing bat call audio is a great way to achieve this monitoring, especially if it can be fully automated.

This particular bat detector device can be run off 12 volt batteries and be deployed in the wild for days / weeks at a time with data being transmitted every now and again via a LoRa radio link. Essentially, it records 30 second chunks of audio, does a quick analysis of that audio using machine learning, and then renames the audio file with species, confidence and date if it detected a bat. All other recordings are automatically deleted to save disc space and time for the biologist / researcher.

*These instructions assume you have good Raspberry Pi skills and are able to flash an SD card and use the command line for installing software. Some moderate soldering skills are also required.

Features:

  • Full spectrum ultrasonic audio recording in mono at 384 ks per second.
  • Results can be displayed in real-time with 30 second delay in either text or spectogram or bar chart format.
  • Runs off a 12 V battery or any power supply from 6 to 16 V.
  • Software is optimised for power saving and speed by using asynchronous classification.
  • Average battery life is about 5 hours using 10 x 1.2 V LiMH AA re-chargeable batteries.
  • Automatically classifies the subject in a choice of resolutions eg animal / genus / species.
  • Retains data even if it is only 1% confident up to set limit eg 5 GB and then starts deleting the worst of it to prevent data clogging.
  • Batch data processing mode can be used for re-evaluating any previous data or new data from other sources.
  • Open source software.
  • New models for new geographical zones can be trained using the core software.

STEP 1: What Have Been the Key Challenges in Building This Device?

  • Choosing the right software. Initially I started off using a package designed for music classification called ' PyAudioAnalysis' which gave options for both Random Forest and then human voice recognition Deep Learning using Tensorflow. Both systems worked ok, but the results were very poor. After some time chatting on this very friendly Facebook group: Bat Call Sound Analysis Workshop , I found a software package written in the R language with a decent tutorial that worked well within a few hours of tweaking. As a rule, if the tutorial is rubbish, then the software should probably be avoided! The same was true when creating the app with the touchscreen - I found one really good tutorial for GTK 3 + python, with examples, which set me up for a relatively smooth ride.
  • Finding quality bat data for my country. In theory, there should be numerous databases of full spectrum audio recordings in the UK and France, but when actually trying to download audio files, most of them seem to have been closed down or limited to the more obscure 'social calls'. The only option was to make my own recordings which was actually great fun and I managed to find 6 species of bat in my back yard. This was enough to get going.
  • Using GTK 3 to produce the app. Whilst python itself is very well documented on Stack exchange etc, solving more detailed problems with GTK 3 was hard going. One bug was completely undocumented and took me 3 days to remove! The software is also rather clunky and not particularly user friendly or intuitive. Compared to ordinary programming with Python, GTK was NOT a pleasant experience, although it's very rewarding to see the app in action.
  • Designing the overall architecture of the app - GTK only covers a very small part of the app - the touch screen display. The rest of it relies on various Bash and Python scripts to interact with the main deployment script which is written in R. Learning the R language was really not a problem as it's a very generic languages and and only seems to differ in it's idiosyncratic use of syntax, just like any other language really. The 'stack' architecture initially started to evolve organically with a lot of trial and error. As a Hacker, I just put it together in a way that seemed logical and did not involve too much work. I'm far too lazy to learn how to build a stack properly or even actually learn any language, but, after giving a presentation to my local university computer department, everybody seemed to agree that that was perfectly ok for product development. Below is a quick sketch of the stack interactions, which will be pure nonsense to most people but is invaluable to remind myself of how it all works:
  • Creating a dynamic barchart - I really wanted to display the results of the bat detection system in the most easy and comprehensive way and the boring old barchart seemed like the way forwards. However, to make it a bit more exciting, I decided to have it update dynamically so that as soon as a bat was detected, the results would appear on the screen. Using spectograms might have been ok, but they're quite hard to read on a small screen, particularly if the bat call is a bit faint. After ten days of trial and error, I got a block of code working in the R deployment script such that it produced a CSV file with all the correctly formatted labels and table data that were comprehensible to another Python script using the ubiquitous matplotlib library to creating a PNG image for GTK to display. The crux of it was getting the legend to automatically self initialise otherwise it would not work when switching to a new data set. Undoubtedly, this has saved a whole load of trouble in the future.
  • Parallelism - some parts of the stack, most particularly the recording of live audio, has to be done seamlessly, one chunk after another. This was achieved in Bash using some incredibly simple syntax - the & character and the command wait. It's all done in two very neat lines of code:
    arecord -f S16 -r 384000 -d ${chunk_time} -c --device=plughw:r/home/tegwyn/ultrasonic_classifier/temp/new.wav &
wait

    Choosing to use the Bash environment for recording audio chunks was a bit of a no brainer due to the ease of use of the Alsa library and it's ability to record at 384 ks per second. I did not even consider the possibility of doing this any other way. More recently, I realised that some parts of the stack needed to be linear, in that blocks of code needed to run one after the other, and other blocks needed to run concurrently. This was most obvious with the deployment of the Random Forest models in that they only needed to be loaded into memory once per session rather than loading them into memory every time a classification was required. It was actually quite fun to re-organise the whole stack, but required that I documented what every script did and thought really carefully how to optimise it all. The different parts of the stack, written in different languages, communicate with each other by polling various text files in the 'helpers' directory which very often don't even have any contents!

  • Finding a decent battery to 5V switching regulator and fuel gauge - It's quite amazing - nobody has yet created a compact 5V power supply that can both monitor the battery state of charge AND deliver a steady 5V from a lead acid battery AND work at a frequency above 384 kHz. Fortunately, after pouring over various datasheets for a day or two, I found one chip made by Monolithic that seemed to meet all the specs. And even more fortuitous was that the company supplied a nice evaluation board at a reasonable price that did not attract customs and handling fees from the couriers. Well done Monolithic - we love you soooooo much! After running a full CPU stress test for 10 minutes, the chip temperature was only 10 degrees above ambient.

  • Optimising the code for minimal power useage and minimal SD card stress - This involved completely redesigning part of the stack such that the classification scripts, written in R, became asynchronous, which means that, on pressing the start button, the script runs in a continuous loop ever waiting for a new .wav chunk to appear in the 'unknown_bat_audio directory'. The advantage in doing this is that the first part of the script can be isolated as a 'set-up' block which loads all the .rds model files into memory in a one off hit, rather than having to constantly do this for every audio chunk created.

STEP 2: Install the Software

  1. Flash a 128 Gb SD card with the latest Raspberry Pi image using Balena Etcher or such like.
  2. Boot up the Pi and create a new user called tegwyn (rather than pi) as below:

  3. Open a terminal and run:

  4. sudo adduser tegwyn
sudo adduser tegwyn sudo
echo 'tegwyn ALL=(ALL) NOPASSWD: ALL' | sudo tee /etc/sudoers.d/010_tegwyn-nopasswd
sudo pkill -u pi

    Login as tegwyn and run:

     git clone  https://github.com/paddygoat/ultrasonic_classifie...
  5. Find the file: 
    ultrasonic_classifier_dependancies_install_nano.sh

    in home/ultrasonic_classifier and open it in a text editor. Follow the instructions within.

  6. The whole script could be run from a terminal using:
    cd /home/tegwyn/ultrasonic_classifier/ && chmod 775 ultrasonic_classifier_dependancies_install.sh && bash ultrasonic_classifier_dependancies_install_nano.sh
  7. .... Or install each line one by one for better certainty of success.
  8. Find the file: run.sh in the ultrasonic_classifier directory and edit the password at line 156 accordingly. Also, remove the line: 
    sudo -S jetson_clocks

    at line 6 as this is for a Nvidia Nano only.

  9. Find the bat icon on the desktop and double click to run the app.

STEP 3: Soldering and Wiring

  1. Plug the AB electronics ADC hat onto the Pi, some extension pins will be required to get above the Pi's case.
  2. The Pi MUST have a fan, which should be wired to one of the 5 V pins.
  3. Find R10 on the Monolithic eval board and replace it with a high tolerance 270 ohm 0806 resistor. Check that this now outputs 5.0 V with a volt meter. The eval board will accept up to 16 V input.
  4. Wire in the power supply with a 48.7 K resistor from the 12 V battery pack to analog pin 1 on the ADC hat.
  5. Wire the 5 V out to ADC pin 2 via a 3.3 K resistor AND direct to the 5 V pins on the Pi.
  6. Connect USB and HDMI cables to the touchscreen.
  7. Set the enable switch on the eval board to 'on'.

STEP 4: Record and Classify !!!!

Click on the bat icon on the desktop and the GUI should appear as above. Select 'Record and classify' and hit the 'Graphical reporting button. Then press play and rattle some house keys in front of the mic to test that the system is working. It should display a pink bar on the graph with 'house keys' in the legend after about 30 seconds.

STEP 5: Optional Step: Connect to the Cloud

This step is not essential and is still in development.

  1. Follow the Adafruit tutorial to connect to The Things Network (TTN). This will get data through a local gateway if one is in range, but will not store the data or produce fancy graphs.
  2. At the end, find the 'Payload Format' tab and paste in this code:
    function Decoder(bytes, port) {
  // Decode an uplink message from a buffer
  // (array) of bytes to an object of fields.
  var decoded = {};

  if (port === 1)  decoded.temp = (bytes[1] + bytes[0] * 256)/100;
  if (port === 1)  decoded.field1 = (bytes[1] + bytes[0] * 256)/100;
  if (port === 1)  decoded.humid = (bytes[3] + bytes[2] * 256)/100;
  if (port === 1)  decoded.field2 = (bytes[3] + bytes[2] * 256)/100;
  if (port === 1)  decoded.batSpecies = (bytes[5] + bytes[4] * 256);
  if (port === 1)  decoded.field3 = (bytes[5] + bytes[4] * 256);
    
  return decoded;
}
  3. Register with ThingSpeak and find 'Create new Channel' to process the data. Their instructions are very good and it's dead easy!
  4. Go back to TTN and find the 'Integrations' tab and add ThingSpeak with the appropriate channel ID and write API key from the new ThingSpeak channnel.
  5. Now use the lora_test_01.py script to send data from the Raspberry Pi.

28 Comments

petemahndahar 3 years ago

Wow this is super cool. I'm curious what was wrong with pyaudioanalysis? What made you search for a better approach? I'm considering making something like this, but wondering if I I need to go into the R world like you...Thanks!

Mano82 4 years ago

Ok love this article.... and great to see that I am not the only one who is interested in building a SMART Bad detector! I tried... and failed to also make a SMART Bad-detector by reengineering an old Ship Sonar and Ultra Mic. Both devices where connected to a digital Dashboard from https://dataanalytics.nl/ so I could record and view all the data received. Both devices did work separately but I couldn't get them to communicate to provide one data-stream. This article inspired me to try it again with some new input from this article.... So NO Netflix next week and back to my lab... actually just my basement, but lab sounds more cool. Keep up the amazing articles guys!

Mano82 3 years ago

Well since my last reply I made some steps.

Finally have the Ship Sonar and Ultra Mic Linked, Did get some help to be honest from some buddy that study at the TU in Delft... but hey it works :-) The data is then captured inside a Dashboard which is made based on Microsoft Power BI. The Graphics in the Dashboard our made with lot's of humor ... shout-out to the guys from https://www.viewglue.com/animatie-film-laten-maken/ who draw all the Vector files.... Kinda looks like an Atari Game now. But hey should be fun!

So now about the functionalities:
I can track the bat's and even have a recording which can be played back or exported in a heat map. This could be great for research, so if anybody from National Geographic is reading... You know where to find me...Hahaha. Oke now the Downside, the really small once not always show (yet-I will try to find a second hand stronger Boat Sonar and try to connect this to the other one for a stronger signal. My rang is max 3km now.... But my next plan is the get an extra Sonar on a drone which I will try link to the Dashboard. Also another Idea is connecting a Night camera Which also can play-back with the sonar recordings so that I can 100% confirm its a bat and not a bird for example..

Next month I will try to make a little recording or pictures to share... It still looks a little mua... so I first want to put it in a Flightcase and make it a bit sexier. Keep you guys updated.

Redrichie 3 years ago

Hi. Am in need of a LoRaWAN bat monitoring solution for a protected area for a UK county council. Does anyone have a solution that is commercially available? Thanks Rich

z1log 4 years ago

Great project. Did you see or consider this board for supplying power/monitoring battery state?

https://pimodules.com/product/ups-pico-hv3-0b-plus...

Seems like it should do away with the need for a separate ADC? Not sure which version of the board would be most suitable though as they produce several?

jannisg 4 years ago

Hey tecwyn-awsom project. we are about to build four detectors, combined with automatic vhf-radiotracking and IR-video. I just found your project yesterday and unfortunately we already bought the 250k ultramics. Is there any news if it works with them?

TechPaul 4 years ago

Surely a MEMS microphone would work, and with savings an Intel Neural Compute Stick would help with the classification

Tecwyn Twmffat 4 years ago

That's not a bad idea Paul, NCS would be great for deep learning which I'll be implementing some time soon (this year), but on a Jetson Nano.

JamesA41 4 years ago

Nice! The open source ID system is an excellent idea.

dodotronic 4 years ago

The detection of ultrasound is not a simple problem and it's very hard to find a good sensor. I tested hundred of sensor and what is reported on datasheet over 20kHz is often not real. The only way to test what I am saying is to have a reference microphone and a waveform generator with an adequate speaker (I have a very expensive B&K system). This is not the place where to bring a technical discussion but the best ultrasonic sensors on the market are these ones: SPU0410LR5H and FG-23629-P16, for other sensors the sensitivity decrease and stops over 60-70kHz. The greatest part of commercial audio digitalyzer (even if the sampling rate reach 768kHz) have an internal low pass filter for audio and in order to avoid aliasin on ultrasound.

JamesA41 4 years ago

Excellent dodotronic! I was wondering about the SPU0410LR5H as I saw listed on eBay and not the SPH0611LR5H that Franzis noted using. Looks like the SPU0410LR5H is in stock at Digikey and a little better price than the SPH0611LR5H. The FG-23629-P16 is in stock too, though costing more... I'm thinking easier to work with integrating into existing systems. Obviously, your Ultramic 384K BLE microphone seems the easiest and most cost effective for use in standalone or existing system integration. Thanks for the support, feedback and experienced insight.

dodotronic 4 years ago

Thanks James
SPH0611LR5H doesn't go at high frequencies as SPU0410LR5H, moreover it is more senitive in the range around 50kHz than FG-23629-P16 but this one has a more flat frequency response. MEMS sensor have a big problem: dust and water can make the sensor completely deaf while electret are almost immune to this. I tested also the VM1000 from Vesper, it is piezo and immune to dust and water but unfortunately the frequency response greatly reduces in ultrasonic field. The solution I'm finding is to use an equalizer for MEMS so to flatten the frequency response.

JamesA41 4 years ago

Awesome post and thanks for sharing! Neat to see the build with the Ultramic 384 from Dodotronic. I've been debating between theirs, Wildlife Acoustics and Pettersson Eletronik's. I've contacted the later two manufacturers and they have great customer support not even owning the device yet. Ultra Sound Advice also has great support as they have the Neumic that I was looking at also since I own a Mini-3 Bat Detector and was inquiring how to upgrade to the S-25 or U30 performance (up to 200kHz detection).

Amazing how these bat detectors can be used with antennas also for monitoring or detecting the RF also and not just the pressure waves. I'm focusing on the loop antennas and MEMS sensor mods for now.

I'm afraid there is more to detect in the ultrasonic range that needs to be disclosed more that can be adverse to our health as noted in the last CBS News 60 Minutes report regarding and was noted by Matt Wixey at a Defcon 27: https://www.cbsnews.com/news/brain-trauma-suffered...


Why not start detecting bats as a youth (or whenever) as I did thanks to the nature centers? Bat's are a great source of fertilizer and they eat bugs too so are a natural pesticide.

The microphones and a 384kHz or higher sampling rate sound card devices is the way to go since can real time view the signals over the range of frequency without aliasing like with say a 192kHz sampling rate system, i.e. half the sampling rate (96kHz) is about the highest range until aliasing artifacts might appear.

Thanks again for sharing!

TechPaul 4 years ago

Maybe a MEMS microphone fed into an RTL-SDR dongle, operating on the baseband input ie Shortwave That should get a 8bit ADC with Mic for less than $20

JamesA41 4 years ago

Will take a look, just scraped the video and will read into and watch later... then when I have the time watch the youtube video all the way through for their metrics. Interesting idea. Wondering about using the amplifier from an active mini-whip or E-Field antenna amplifier now with the MEMS and transducer dodotronic's noted. Budgeting in for next month.
More Comments