Bat detector

[Jean-Do]

Hi CorBee,

The purpose of my developments is slightly different. I go to different people in France who study bats and they face hardware problems. Finance is becoming scarce and the equipment remains very expensive. Or, they have needs that do not exist such as accurate species monitoring. It is with this in mind that I started the development of detectors with the provision of a manufacturing files and setting up participatory workshops. In this context, I developed the following detectors:
- RhinoLogger to monitor the activity of the bands of Rhinolophus, mainly ferrumequinum. About 40 devices were built at several workshops and they equip sites in western and central France. With Passive Recorder, this device will now be used for this type of study.
- PiBatRecorder, a recorder for active Heterodyne listening and passive recording. Built with a Raspberry Pi A + card and an audio card the sampling frequency was only 192kHz. We built 12 copies before the audio card was no longer available. As a result this project is abandoned.
- Passive Recorder, based on the Teensy 3.6 card, offers up to 500kHz sampling frequency and, in addition to the classic passive recording, offers recording modes specific to the Vigie-Chiro project. About 55 copies exist today, at least 20 in Germany and 35 in France (the last 10 built yesterday during a workshop) and I still have 3 workshops of 10 copies planned by the end of April. Given the price (105 €), demand is strong. The main brake is to come to manufacture in the FabLab at Chemillé in Anjou (near Angers). Several projects are trying to carry out workshops elsewhere in France but, for the moment, only Frank has succeeded in Germany (naturalists are not technicians). I do not despair that some people, after participating in one of my workshops, can reproduce elsewhere.
- Bat Player, an ultrasound reader based on the Teensy 3.6 card. It allows replaying wav files recorded with other recorders. It is intended for debugging and verification of recorders, assisting with acoustic training or bat animations. 15 copies exist, 12 of which were made during a workshop and one by Frank in Germany. It is essential for the development of my detectors.

I have heard at least 1 copy of these devices but I do not use much, except for the development. They are mainly used by amateurs or professionals. Consequently, except for the RhinoLogger, they must respect the method used in France for the acoustic identification developed by Michel Barataud in his book "Ecologie acoustique" which is the bible in France for this type of study.

Regards,

Jean-Do.

[CorBee]

Hi Jean-Do,

We have one common goal, make studying bats with detectors easier. I was on the path of the piBatDetector also but the moment I had time to build that the audiocard was gone. I am happy it did ... that way I kept looking around and finally found the work Frank had done allready. I am mainly working on the software as my hardware skills are limited, I have build several heterodynes in the past but cant handle tiny components like some of you do

I am currently changing the code I have worked on last autumn to become easier to use, that work will be mainly on the menu and the way you can make selections etc. But I do have plans to improve the auto_TE part of the detector further.

regards
Cor

[Jean-Do]

Hi Cor,

Concerning the management of modifiers of parameters and modes of operation, I realized a library which allows me to manage this part very easily. It is Teensy and ESP32 compatible. It normally handles any type of screen but I tested only on 2 OLED types 128x64 pixels. I have not published it yet but I will do it soon.

For Surface Mounted Components (SMD), I had no skill ... before trying! Unfortunately, we are forced to use them, the classic components being rare for some.
And, in fact, while remaining within reasonable dimensions, it's quite easy to solder, even MEMS microphones that have an unreachable solder (between the component and the PCB), are quite easy to solder with an air soldering iron as explained in the document "FabMicroMEMS.pdf". I just tested the assembly of a new MEMS found by Frank and the technique works.

Concerning live auto_TE listening, I am not convinced by this technique that I have experimented with an EM3+. It's already complicated at home in front of the computer (especially me with my old ears), so I prefer the heterodyne which gives an idea of the species and allows to decide if the operator must register it for subsequent analysis. Of course, I only ask to be contradicted!

I prefer to test automatic determination methods to either memorize the activity as on the RhinoLogger with easy-to-determine species, or trigger recordings on suspicions of species to target particular species. I think the future is for this type of recorder that allows long poses (several weeks to several months) to sample at length certain species and thus facilitate studies of behaviors. And this type of recorder does not present a sufficient market for interested professional builders.

Regards,

Jean-Do.

[CorBee]

Hi Jean-Do,

I suggest just trying the Auto_TE the current setup can deliver. I can walk through my garden listening to several species of crickets and suddenly notice that a bat is flying around. Alternatively on a holiday location I suddenly realized that there were not only two different bats flying around but they were also different species as the audible clicks where very different and easy to distinguish in auto_TE. Next step then was to record them and look at the real data. Auto_TE is not necessarily the best instrument to detect/identify (you can even miss temporary clicks) but it can be helpfull and for new-bat enthusiasts it brings more information than listening to clicks. Its more like listening to birds, there songs are very different but if you were to only look at their silouet (never tried heterodyne on them they are more difficult to distinguish. But this is my view after playing around with this for some time.

regards
Cor

[Polly]

Hi All,

I've been directed over here by Paul and defragster https://forum.pjrc.com/threads/55386...osteoarthritis. I'm trying to do something similar but also completely different for my PhD. I'm trying to detect the ultrasound produced in knees when moving to predict whether a knee has osteoarthritis.

I'm trying to learn to code (I've only used matlab before for signal processing) and also get my filtering and amplification right before my signals reach the teensy (3.6). What I want to do I don't think is as complicated as what you are achieving with the Bat Detector! All I want to do is put the signals through an ADC conversion and write them to the SD card in an accessible format for processing later.

I know what I want to achieve but I'm struggling to figure out how to do it!

My signals will be filtered to be between 20kHz to 300kHz and amplified to be 0 to +3V.
I need the sample rate to be as fast as possible, but a minimum of 1.8MHz would be best, I can't seem to find a straight answer on how fast this actually is capable of going but my supervisor seems to think it'll be ok
I'm going to use a trigger for recording but want to record a small amount of signal before the trigger is tripped.
Once the trigger has started recording it will record I think for a set time period and stop, but I'm not sure yet.
BUT I don't know whether it would just be better to record a full 10s activity as one file and do a tonne of post processing to look for hits and waveforms.
I'm thinking that the best file for me to write to the SD card too will be a .csv with a column for time and and column(s) for the signal.
I'm also not sure of the data transfer rate of SD cards.

As you can see, I'm a bit lost so any help/ideas/suggestions would be greatly appreciated!

Best Wishes Polly

[DD4WH]

Hi Polly,

I do not think that it is possible to record ultrasound files to SD with a sample rate of 1.8MHz with the Teensy 3.6 . . .

We use a maximum sample rate of 500kHz with 12bit resolution (internal ADC) and that is quite fast already.

The other solution with the audio board is used with sample rates up to 352kHz for the codec. And that is already a multiple of the allowed spec of the codec. Also not anything near 1800kHz !

Why would you need 1.8MHz if you have signals that range from 20-300kHz and are already nicely filtered by an antialias filter, as you say? I would say that a sample rate of a little bit more than 600kHz would be sufficient in that case ?

Have a look at the search function of the forum for your questions on speed of SD recording.

[Polly]

Hiya,

Sorry typo 1.2MHz, still fast though!

No, this is what I am worried about, and as I've not really had to do anything like this before it's almost like I don't even know the search term required. I am learning A LOT though, so that's a bonus.

I have been told by colleagues, that I should be aiming for 3 or 4 times the highest frequency (which is where I get the 1.2MHz), they are worried that I will lose so much of the signal if I go to just double, even though it should be fine with Nyquist, I again am not sure about this, but typically on the static systems they use they tend to capture lots of data and then get rid of lots (I believe).
I just want to look at when we get a waveform in comparison to the gait (walking) cycle.

Thanks for the speedy response

Polly

[Frank B]

There are new 64MBIT (8 MBytes) SPI PS-RAMS - It should be possible to use such a RAM as fast buffer, before writing to the SD Card.
I have some of them on my desk, since yesterday. Could not do much more than a quick test so far, all I can say is "it will work with a Teensy". I think, with one or two of these chips, it will be much easier.

[defragster]

There are new 64MBIT (8 MBytes) SPI PS-RAMS - It should be possible to use such a RAM as fast buffer, before writing to the SD Card.
I have some of them on my desk, since yesterday. Could not do much more than a quick test so far, all I can say is "it will work with a Teensy". I think, with one or two of these chips, it will be much easier.

Frank - those 8 MB RAM's are the same outline and pinout as the FLASH chips that worked with your prior PCB's? That would be single SPI access - not quad?

[Frank B]

yes.
They can work in both modes.

[pe1pwf]

Hi Jean-Do,

I solder my mems using an old hot plate to keep te koffee pot warm.
It looks quite silly but there are 3 spots on that plate that become just a tiny bit hotter tan the rest of the plate.
I puts some folder on the pads of my SPU0410LR5H, put it on the PCB and put the om the hot plate. I just wait a little and can see the MEMS falling into place.

I burnt some before using hot air but this silly old heating plate works like a charm.


I wonder what other MEMS you guys have discovered.

Kind regards,

Edwin

Hi Cor,

-----
-----
-----

For Surface Mounted Components (SMD), I had no skill ... before trying! Unfortunately, we are forced to use them, the classic components being rare for some.
And, in fact, while remaining within reasonable dimensions, it's quite easy to solder, even MEMS microphones that have an unreachable solder (between the component and the PCB), are quite easy to solder with an air soldering iron as explained in the document "FabMicroMEMS.pdf". I just tested the assembly of a new MEMS found by Frank and the technique works.

------
------
------


Regards,

Jean-Do.

[Jean-Do]

Hi Edwin,

For MEMS welding, I use this device. I sold more than 40 microphones without problems. With a conventional soldering iron, I put a little solder on the 5 points (not on the central circle, there is too much risk to plug the hole) then I stuck the PCB with the MEMS in a crocodile clip and I warm in hot air (230 °, 45s). I test the PCB just after the weld and sometimes have malfunctions, all due to too much weld deposit before heating. Then simply desolder the MEMS, remove the overflow of solder with a conventional soldering iron and warm up.

The new MEMS discovered by Frank is the ICS40730. I let Frank describe the improvements made by this model. The cold weather has not allowed me to test it yet. I made a small PCB identical to that of the SPU0410LR5H and completed the manufacturing document of the microphone including this MEMS. I hope to find some time to publish them next week.

With which model of detector do you use the SPU0410LR5H ?

Regards,

Jean-Do.

[pe1pwf]

Hey, my reply got lost... well, I probably wrote it and accidentally closed the browser window.


Jean-Do,

I am using the SPU0410LR5H in the CorBee detector. I had a whole lot of fun sofar with this detector and drew up a pcb for it.

I looked into the datasheet of the ICS40730 and did not see any ultrasonic properties. Maybe it is some undocumented feature.

I recently got some SPU0410HR5H by accident, these look very much like the SPU0410LR5H but I have the feeling ultrasonic properties are not as good as the SPU0410LR5H. The SPU0410HR5H also has no ultrasonic properties described in the datasheet.

If you do want to do some comparison between microphones, you could use SA9227+PCM5102A DAC board and a ribbon speaker. For around 35-40 euro's you have some nice ultrasonic source. You can generate tones or play bat recordings.
You don't have to wake the local bats to get a test sound :-)



Kind regards,

Edwin

[AlainD]

Hi

I've read the ICS40730 mems mic properties and to me it seems a very nice device, but I'm not looking at ultrasound ;-)
Am I reading the specs correctly that it even can be used without an external preamp? (DC bias 0.66V and going -0.4V ~ +0.4V around the bias)

Some nice mic info I did find on the web :Assembling cheap, high-performance microphones for recording terrestrial wildlife: the Sonitor system I found the effects on cable length a bit strange and found the info about horn's very useful.


Alain

[Jean-Do]

Hi,

Thank you Edwin for these clarifications. I also used the SPU0410LR5H for these ultrasonic capabilities described in the manufacturer's documents. I think that many micro type MEMS have ultrasonic capabilities not described by the manufacturers, sales hopes in this area are too small to be interested.
I actually use an ultrasound reader for my tests. At first, I used this DAC with a small ultrasonic HP but now I have a standalone player made from a Teensy 3.6 card.
You can find the description of this project on this link. An autonomous device allows a simpler use, even for animations or formations with heterodyne. Just adjust the gain for the first reading of each wav file to best manage the 12 bits of the DAC of the Teensy card.

Alain, thank you for the link on this document. I knew him but I had lost the link. I do not use a horn, they are too directional, my goal is to record the maximum number of animals passing around the microphone. For the length of the cable, I have a better result with a cable of 3m than without cable.

Regards,

Jean-Do.

[AlainD]

Hi,

....

Alain, thank you for the link on this document. I knew him but I had lost the link. I do not use a horn, they are too directional, my goal is to record the maximum number of animals passing around the microphone. For the length of the cable, I have a better result with a cable of 3m than without cable.

Regards,

Jean-Do.

Hi

I found the "FabMicroMEMS-PCB.odt " very instructive as you're other documents.

[CorBee]

Hi All,

In the past weeks I have been changing the setup of the detector-code on my github (https://github.com/CorBer/teensy_batdetector). I am currently mainly focussing on setting up the menus more logical etc. Edwin (pe1wf) has kindly requested me and his work on the hardware is inspiring !

WARNING: for those that compile on the windows platform. I am purely working from Linux and I know there can be compiling problems due to the usage of the TimeLib library in my code to set/read the RTC-time. I have no clear solution for this yet. Anybody that can provide help on this is welcome.

Compared to the code of last year this is a short summary of the changes implemented:

The most important change is that the different DETECTOR modes can now be changed regardless of the DISPLAY mode(none, spectrum, waterfall). In the initial code you could for instance not change the detector to AUTO_TE (automatic time_expansion) when not in the "waterfall" graphics mode.
Also the function of the pushbuttons is shown on screen, the same is valid for time.

- left/right pushbuttons (separate from the encoders that can also be pushed) now get better controllable functionality.
The functionality of the left button can be set using the left_encoder with menuoption (BUTTONL), by default the left-button controls the DISPLAY mode. But it will also be used to allow RECORDING/PLAYING easier (can be choosen but not yet fully implemented)
- The functionality of the right button is currently set to a default to change the DETECT mode (heterodyne, auto_heterodyne, divider, auto_te, passive)

Ive added a menu option to allow users to change the RTCtime. You can choose the function only with the leftencoder (SetTime) and after selection the time can be adjusted by turning the encoder. Turning it fast will change the time more at each step than turning it slow.

Thats a short summary, since I have picked up development again I am interested in suggestions for additional/changed functionality.

kind regards
Cor

[AlainD]

...
The new MEMS discovered by Frank is the ICS40730. I let Frank describe the improvements made by this model.
...

Regards,

Jean-Do.

Could Frank decribe the improvements?

Jean-Do: are you using it in "differential output" mode?


Alain

[Jean-Do]

Hi Alain,

No, I do not use the MEMS microphone ICS40730 in "differential output" mode but in GND-Output mode as for the SPU0410LR5H. This means that both MEMS microphones are directly compatible with Passive Recorder.
However, I would like to use the internal ADC of the processor in differential mode to gain a bit of resolution (12 bits to 13 bits) but, if software side modification is simple, on the hardware side, I have no idea of how to proceed !

Regards,

Jean-Do.

[DD4WH]

Salut Alain, Edwin, Cor, Jean-Do. and all others interested,

Darras et al. (2018) in their paper use the ICS40720, which is an older version of the MEMS. Also they do not describe any frequency response higher than 40kHz, which makes their suggestions for bat call recording a little vague.

ICS40730 is -up to my knowledge- the MEMS mic with the highest SNR on the market (74dBA), thats why I tested it in comparison to the widely used SPU0410. You can see the frequency response here (tested with the BatPlayer by Jean-Do., see his posting for a link. Note that the BatPlayer does not have a linear frequency response, so comparisons can only be made between recordings made with exactly the same setup. Also I would like to add, that this is an evaluation not only of the MIC, but of the entire audio recording chain: MIC & PREAMP & DIGITAL PROCESSING & µSD RECORDING. Noise floor has been measured using Audacity using the feature Analysis --> contrast):

https://github.com/DD4WH/Teensy-Bat-...2019_04_05.pdf

To summarize in short my conclusions from this:

* use the ICS40730 for ultrasound recording devices !
* it has higher SNR
* it has better high ultrasound frequency response than any other MEMS mic that I know of
* it is a bit larger and soldering thus is a bit easier
* I cannot say anything about the differential mode, because I have not tested the mic in that mode
* do not use SPU0410 any more, for the reasons stated above
* Especially do NOT USE the old version of the SPU0410 (SPU0410HR5H) any more! It has really bad high frequency response

Have fun!

Frank DD4WH

[AlainD]

Salut Alain, Edwin, Cor, Jean-Do. and all others interested,

Darras et al. (2018) in their paper use the ICS40720, which is an older version of the MEMS. Also they do not describe any frequency response higher than 40kHz, which makes their suggestions for bat call recording a little vague.

ICS40730 is -up to my knowledge- the MEMS mic with the highest SNR on the market (74dBA), thats why I tested it in comparison to the widely used SPU0410. You can see the frequency response here (tested with the BatPlayer by Jean-Do., see his posting for a link. Note that the BatPlayer does not have a linear frequency response, so comparisons can only be made between recordings made with exactly the same setup. Also I would like to add, that this is an evaluation not only of the MIC, but of the entire audio recording chain: MIC & PREAMP & DIGITAL PROCESSING & µSD RECORDING. Noise floor has been measured using Audacity using the feature Analysis --> contrast):

https://github.com/DD4WH/Teensy-Bat-...2019_04_05.pdf

To summarize in short my conclusions from this:

* use the ICS40730 for ultrasound recording devices !
* it has higher SNR
* it has better high ultrasound frequency response than any other MEMS mic that I know of
* it is a bit larger and soldering thus is a bit easier
* I cannot say anything about the differential mode, because I have not tested the mic in that mode
* do not use SPU0410 any more, for the reasons stated above
* Especially do NOT USE the old version of the SPU0410 (SPU0410HR5H) any more! It has really bad high frequency response

Have fun!

Frank DD4WH

Thanks for the good work.

[AlainD]

Hi Alain,

No, I do not use the MEMS microphone ICS40730 in "differential output" mode but in GND-Output mode as for the SPU0410LR5H. This means that both MEMS microphones are directly compatible with Passive Recorder.
However, I would like to use the internal ADC of the processor in differential mode to gain a bit of resolution (12 bits to 13 bits) but, if software side modification is simple, on the hardware side, I have no idea of how to proceed !

Regards,

Jean-Do.

Hi

Thanks

I also did read somewhere that there's an amp in differential mode, but I'm very unsure and it beyond my knowledge.

Alain

[DD4WH]

Hi Alain,

the datasheet of the ICS40730 states that the mic has a sensitivity that is 6dB lower in single-ended mode vs. differential mode. However, the high SNR of 74dBA is the same irrespective of the sensitivity and how you connect it to the preamp. So, if I interpret the data sheet correctly, there is no amp in the ICS40730 that would make the MIC useable without a preamp in differential mode.

Jean-Do., I do not think a 6dB higher sensitivity would be worth the effort of totally rethinking the preamp for differential input. The MIC has enough sensitivity for bat work: we should even think about lowering the gain of the preamp as can be seen from the ADC overload in the graphs . . .

But for differential input to the ADC I see potential for improvement. If that could really mean 1 bit more, i.e.6 dB more SNR, that would be great!!! But, unfortunately I cannot be of large help, because thats beyond my capabilities in analog circuit construction.

All the best,

Frank DD4WH

[AlainD]

Hi Alain,

the datasheet of the ICS40730 states that the mic has a sensitivity that is 6dB lower in single-ended mode vs. differential mode. However, the high SNR of 74dBA is the same irrespective of the sensitivity and how you connect it to the preamp. So, if I interpret the data sheet correctly, there is no amp in the ICS40730 that would make the MIC useable without a preamp in differential mode.

Jean-Do., I do not think a 6dB higher sensitivity would be worth the effort of totally rethinking the preamp for differential input. The MIC has enough sensitivity for bat work: we should even think about lowering the gain of the preamp as can be seen from the ADC overload in the graphs . . .

But for differential input to the ADC I see potential for improvement. If that could really mean 1 bit more, i.e.6 dB more SNR, that would be great!!! But, unfortunately I cannot be of large help, because thats beyond my capabilities in analog circuit construction.

All the best,

Frank DD4WH

Hi

I did read that there was a PGA (programmable Gain Amplifier) inside the teensy, but it's only in the 3.2.

if I did the calculations right 12 bit divided by 2 (wave form) gives a SNR of 66db, so adding 1 bit could make a difference.


Alain

[remis]

Hello
I'm new on this project. I follow work of DD4WH and Corber project. I try to compile under arduino 1.8.9 and teensyduino available for 1.8.9.
I hope it could help people if I detailed my issue, and may be solved it :-)
I use the main.cpp renamed in maincpp.ino
#define batversion "v0.82 20190410" in https://github.com/CorBer/teensy_batdetector

Library Installation is done under : /home/remi/arduino-1.8.9/
I follow detailed pdf Edwin, 30-12-2018 with libraries change and I create /hardware/teensy/avr/libraries/uSDFS directory with theirs files

First I need to remove some old SD library previously installed in /home/remi/arduino/ to suppress multiple definition error

in main.cpp code ( renamed as maincpp.ino ) we have many compilations options:

choice : #define USESD1
in this case : compilation error:

/tmp/arduino_build_911967/libraries/uSDFS/sdio.c.o: In function `sdhc_isr':
/home/remi/arduino-1.8.9/hardware/teensy/avr/libraries/uSDFS/src/sdio.c:600: multiple definition of `sdhc_isr'
/tmp/arduino_build_911967/libraries/SD/utility/NXP_SDHC.cpp.o:/home/remi/arduino-1.8.9/hardware/teensy/avr/libraries/SD/utility/NXP_SDHC.cpp:911: first defined here
/home/remi/arduino-1.8.9/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld: Disabling relaxation: it will not work with multiple definitions

I confirm that we have two definition of sdhc_isr function in :

/home/remi/arduino-1.8.9/hardware/teensy/avr/libraries/uSDFS/src/sdio.c:600
and in :
/home/remi/arduino-1.8.9/hardware/teensy/avr/libraries/SD/utility/NXP_SDHC.cpp :911

choice: #define USESD2
in need the logger_setup.h file that I can not found

choice; #define USESD
lot other compilator error, missing declaration and others
FRESULT' has not been declared
error: 'root' was not declared
error: variable 'tm tx' has initializer but incomplete type
…

I suppose that I miss a lot of configuration. If someone could tell me how to compile? Maybe, without SD card features, to begin slowly
Many thanks.

Rémi