©2019 Open Acoustic Devices

Apr 11, 2018

Python based batcall detector

6 comments

https://github.com/macaodha/batdetect Well I've got it running on with Anaconda 3 and it scanned 480 files and flagged 40 odd as containing bats calls - which is looking correct so far. What I'm failing on is getting it to look for the wave files on an external drive ie f:\, anyone know if you can only have the files as a subdirectory or am I missing something simple? should I have the python files on the F: drive?

Apr 25, 2018

That's interesting. I got an horrendous error rate with the files I was using but perhaps they had more noise than expected. (under a road bridge over a river in the rain). I've been discussing it with the authors.

May 16, 2018

I should have some time to return to this after the weekend. I now have some recordings in a much quieter place so will try to run those. Depending on how you are running your script, you may find that the drives are mounted under /f/ instead of F:.

May 30, 2018

I've been trying this. I can happily set a mounted drive by setting it to "E:\\Path/to/my/data/"

and it then runs fine. I have fettled it to run under Python3.

The quality of the output is variable. The audiomoths have periodic noise that is interpreted as a lot of calls. Depending on the species you are looking at, you may want to post-process the output and reject assigned calls that are too close together. My thinking is that a new set of models need to be developed for the AudioMoth, or the data needs some pre-cleaning to denoise it.

May 30, 2018

Thanks, unbelievable timely as this morning's job is to scan some cards...

Jun 8, 2018

I've been trying batdetect and also BatClassify. I have some success with Batclassify, running at 384 kHz, 15 second file length. It does assign Ppyg social calls to NSL ( and has no Pnat) model. Batdetect runs faster but I haven't had much of a chance to get into the data. If I find the time I'll compare the two. I did find that BatDetect (anecdata alert) was not great at picking out all the calls from a file and was very prone to false positives. For what I am doing at the moment I take the spreadsheet of the 2500 or so file results from batclassify and rank them by score for each species in turn. I can then manually examine files down to a cutoff value (species dependent) to see if they are correct. Typically anything over .8 is definite for pips but you are not sure if there is something else in there, and I had some very faint echolocation with loud social calls that flagged up as NSL. For a moment I thought there was a Leislers in Scotland but more careful examination showed it to be a ppyg social call.

 

Batdetect takes an hour or so to run on 2500 files on my not very high spec laptop and requires some python skills. Batclassify takes about 6 hours (ie overnight) for each directory of about that size.

Jun 26, 2018

Also Batclassify will run when batdetect falls over complaining about "corrupt" files - I may have lets the batteries run too low <shamed face>

New Posts
  • Hi, in all my recordings there's a "clicking" noise (26-28kHz). This is an issue that I had before with some recordings but now the noise is louder and it is present in all recordings. The batteries are Energizer AA (new) and the SD card is the SanDisk Extreme 32GB. Is there Anything I can do to make the "clicking" noise disappear?
  • Amazing work! https://www.openacousticdevices.info/mmoth Clearly it is early days, but obviously so many questions pop into mind ... - Off board Lithium ion battery, with a onboad connecter? (So you can choose any size LiOn? or LiPo? like - https://hobbyking.com/en_us/turnigy-2000mah-1s-1c-lipoly-w-2-pin-jst-ph-connector.html ?) - Any Battery life / runtime estimates vs AM1.1? - Cost? Double side so more expensive? - etc, etc, etc ... Anything else to share with us yet??
  • Hi, I'm attempting to modify the basic firmware, and I'm progressing quite well however there are a couple of sneaky scenarios which require a lower level debugging capability. Can you please advise how you debug the firmware, on the device? I've modified the firmware to call 'AudioMoth_setupSWOForPrint' at the end of AudioMoth_initialise() and added a couple of debug statements such as printf("Debugging enabled"); Throughout the code, being executed. These changes, along with my other alterations were then successfully flashed to the AudioMoth device. I've then connected my J-Link debug probe https://www.segger.com/products/debug-probes/j-link/ , which appears to support the EFM32WG980F256 chip. https://www.segger.com/downloads/supported-devices.php 1. PC -> USB -> AudioMoth USB plug (normal USB connection for an AudioMoth) 2. PC -> USB -> JLink Debug Probe -> SWD via Dupont Connectors -> AudioMoth Debug pads Here's a couple of photos to highlight what I'm doing. Sure, those connections are soldered a little rough but have been verified to be fine. As a simple dump, here's what I'm using. I'm expecting you're doing something similar when modifying the firmware. JLinkExe SEGGER J-Link Commander V6.52c (Compiled Oct 11 2019 15:44:58) DLL version V6.52c, compiled Oct 11 2019 15:44:50 .... Type "connect" to establish a target connection, '?' for help J-Link> connect Please specify device / core. <Default>: EFM32WG980F256 Type '?' for selection dialog Device> Please specify target interface: J) JTAG (Default) S) SWD T) cJTAG TIF> S Specify target interface speed [kHz]. <Default>: 4000 kHz Speed> Device "EFM32WG980F256" selected. Connecting to target via SWD Found SW-DP with ID 0x2BA01477 Scanning AP map to find all available APs AP[1]: Stopped AP scan as end of AP map has been reached AP[0]: AHB-AP (IDR: 0x24770011) Iterating through AP map to find AHB-AP to use AP[0]: Core found AP[0]: AHB-AP ROM base: 0xE00FF000 CPUID register: 0x410FC241. Implementer code: 0x41 (ARM) Found Cortex-M4 r0p1, Little endian. FPUnit: 6 code (BP) slots and 2 literal slots CoreSight components: ROMTbl[0] @ E00FF000 ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7 ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM ROMTbl[0][4]: E0040000, CID: B105900D, PID: 003BB923 TPIU-Lite ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM Cortex-M4 identified. J-Link> SWORead 0 bytes read (0 bytes in host buffer) J-Link> SWOView Receiving SWO data @ 4000 kHz. Data from stimulus port 0: ----------------------------------------------- Occasionally I'll get SWO output, but its all garbled and meaningless. On other hardware I would think this was a mismatch of the receiving clock (4000 kHz), but maybe I'm attacking this incorrectly. I appreciate this is getting down into the lower levels of core programming on the device but I suspect other users may wish to also understand these debugging aspects when modifying the firmware to suit their needs also. Without a device level debugging capability the only way to check out changes is to flash the device with extra LED flashes to highlight state changes, or log to the microSD via the AudioMoth_appendFile operation. Which SWO debug probe do you use to validate changes to the base firmware? What code changes do you make to enable debugging? Are there Simplicity Studio changes which you utilise to support debugging on the device? Are you debugging the code off the device instead, on a PC using a 32-bit ARM emulator or 32-bit x86 target toolchain? Are you implementing Unit Testing on your version of the firmware?
Before posting, be sure to check the FAQ.