Bat detector

Hi,

I do not think it is possible to create this on an ESP8266 or ESP32. Many of the routines used to make the detector run are based on the audio-system that is designed for the teensy. The code is therefore platformspecific in many ways. Secondly I dont think the ESP8266 is capable of this kind of processing, it does not have much active memory to use to store incoming audio-data. The ESP32 might be a better candidate but would require the setup of a good lowlevel audio-processing set of routines. Maybe someone has allready tried to do that but I havent seen this yet (I am using ESP8266 for other projects like IOT).

regards
Cor
 
thank you for your reply, i will follow with interest the discussion thread. At the moment I will make a more compact detector.
 
Hi,

If you have ideas/requests please share them and ... we are always interested to see your compact detector. Which hardware do you plan to use ?

regards
Cor
 
I think this is already quite compact.

The enclosure is quite thick (36mm) but if you want a display and some controls you will probably get something like this size. The 68mm width is perfect for the Teensy and the display.

There is some free space in the enclosure so you could make it even thinner is you want.

The only thing I do not like so much are the "high" encoder knobs but we do need some way to have control over the unit.
This is a standard enclosure (not 3d printed)

I juist built this one for a German batfan, who kind of "lost" the first one to his son.

IMG_20200429_202620838_resize_17.jpg

IMG_20200429_170354201_resize_15.jpg

Kind regards,

Edwin
 
hello, the translator derailed, I said simpler, to start with.
I'm just starting out, bats have been interested in me for a long time, I have three in the garden.
that's why I'm going to follow the thread.
* for now I'm going to start from an ESP.
* Thanks for reading.
 
pe1pwf said:
I think this is already quite compact.

The enclosure is quite thick (36mm) but if you want a display and some controls you will probably get something like this size. The 68mm width is perfect for the Teensy and the display.

There is some free space in the enclosure so you could make it even thinner is you want.

The only thing I do not like so much are the "high" encoder knobs but we do need some way to have control over the unit.
This is a standard enclosure (not 3d printed)

I juist built this one for a German batfan, who kind of "lost" the first one to his son.

View attachment 19896

View attachment 19898

Kind regards,

Edwin
Click to expand...

Hi Edwin

We could change the high-encoder knobs for rotational-switches on the side. I havent looked for those but I am sure they can be found. That would keep the setup thinner.
The rotary encoders are just used as up/down and select buttons. If we can find an equivalent piece of hardware that is slimmer that would be an option.

Something like this: https://www.google.com/url?sa=t&rct...010-ALPS.pdf&usg=AOvVaw2jZfU4weH_n_d-yDIRr0Gp


regards
Cor
 
Last edited:
Hi,

According to me that project was mainly set up to remotely record bat activity, not to listen actively to bats with headphones. But if that is what you were planning to do I am sure it will be fine as Tony Messina is busy with these kind of devices for a long time allready.

regards
Cor
 
Sounds like a standard heterodyne detector, I hope you can build/test this for yourself. I wonder if the total price for this (the ardubat-logger) is however not close to the detector we are building. But as stated the design of Tony is mainly ment for stand-alone remote recording.

regards
Cor
 
Last edited:
117/5000
the price is 23 euros including shipping.
I already have arduino and esp8266.
I think it will be good to start
 
Tony uses the same frequency division detector concept in Manu of his designs. A double lm386 as amplifier for the UST and a 4024 IC as devider.

I have been unwanted oscillations in the audioamplifier. I suggest you add 10nF and 10ohms resistor as found in the data sheets.

Using the UST this will work best on 40 KHz, the MEMS element we use gives better frequency response over a broad range. Ik have no Idea how that works with the double lm386.

He also has information on a scanning heterodyne receiver. That might be a nice one to but if you are willing to spend a bit more money. The Teensy bat detector offers so much more.

I do have to admit I am also trying to build the scanning heterodyne. Just for fun... Made my own SMD PCB though.

Edwin
 
hello, regarding smd i don't know.
so that leaves little choice.
thank you for your return to arduibat. what is the scanning heterodyne model? the batscanner?
thank you
 
Yes I ment the batscanner,


You basically have two options if you want to build something simple.

Frequency division, this does not require any tuning, it works by amplifying the received signal until it makes a square wave which is than divided by a counter IC or something like that.

Heterodyne, this is like a radio receiver, mixing the high frequency to an audible signal. This requires tuning and allows you to hear only as small portion of the ultrasound spectrum. The received signal is usually considered better quality.



Tony does not have the complete circuit on his website for the batscanner, there is something missing in the display pinout. I hope my schematic is complete but I do not have my pcb's yet so I can not test.

This is my SMD version of Tony and Frank's batscanner.
unnamed.png


I did buit a batlistener from this site for the kisd at school.

http://integraonline.com/~wolfden/detector.html

I was able to gather materials for only about 10 euro's

BLvoorbeeld.jpg

I think I have a spare PCB, it works nice enough for most common bats here in the area.

Maybe it is better to discuss things somewhere else because it is no more teensy related.
If you want the batscanner schematic I have or if there are other tings interesting mail me at my callsign at gmail.com or try a personal message.

Kind regards,

Edwin
PE1PWF
 
Hi all, on recommendation from Frank I was going through this thread specifically looking to see if it is possible to increase the sampling rate for the audio library. On a few other threads here I saw that it is not an easy task.
What changes were required to make it sample at 96khz in the bat detector? I saw the initial versions of the bat detector code base on the first few pages of this thread, and I saw it being set using "set_sample_rate (sample_rate);" in the setup. Is that all there is to it? I'm sure I am missing something but I don't know where.

To give some brief information on my use for the higher sampling rate, I am trying to use a Teensy4 and mic + speaker combo to do acoustic ranging. By listening to a tone of a particular frequency I hope to note the elapsed time between the ping and hearing it to get the distance. Currently with the FFT256 and sampling rate of 44.1khz my best time resolution is 5.8ms as Pete (el_supremo) mentioned on a different thread, and that would mean the least distance I can reliably detect is 2m. Thanks!

-Akshay
 
Hi all,

Currently I am (together with Edwin) working on part of the code for the Teensy Batdetector, if there are requests for features or changes in features or bugreports please tell us.

regards
Cor
 
I finally built my detector, using Edwin's board and MEMS mic PCBs. Truly an amazing project. I'm so grateful to all involved.
I added a tiny LiPo charger from Adafruit to handle the battery charging. I also made a 3D-printed enclosure using OpenSCAD so it should be easy for others to modify to suit their needs. I'll put complete info on my website in the next week and provide a link. Lots of 23kHz noise but I'm sure I can improve it.
Teensy_Bat_box_OpenSCAD_with_knobs.jpgTeensy_Bat_box_OpenSCAD.pngTeensy_Bat_with_charger.jpg
Meanwhile, my wishlist for the code:

1) It would be great to have another detector mode that uses the regular granular engine with a short buffer (5-20ms) so it operates constantly, not requiring a trigger. Sometimes I'm listening to continuous ultrasonic sounds that don't match the dynamics of typical bats. I can fool Auto_TE by turning up the gain to cause constant triggers but it would be nice to have a continuous pitch shift sometimes (although choppy of course). This is also useful for listening to distant bats.

2) Since I'm powering directly with a LiPo, I love the new option to display a voltage. I read the code comments but I'm still somewhat confused about what the displayed number represents. I realize that this requires calibration since the divider resistors vary. Maybe there could be a menu option to set the max and min ADC counts and the display could scale that to percentage, perhaps based on a lookup table since LiPo discharge isn't linear?

3) This may be a noob question, but is there an existing library somewhere for generating WAV headers, so the recorded files could be directly played without converting from raw?

(Lots of ideas but I appreciate that none of them are easy!)
 
Last edited:
One more code request:
4) It would be very convenient to have variable increments in the RTC clock set menu item (so when the encoder turns faster, the increments are minutes, but switch to seconds when the encoder turns slower?) It took me 20 minutes of turning to set the clock.
 
Hi,

Nice to see that you are adding something to this project by opensourcing your design for an enclosure. THe noise on 23Khz is something Edwin and I also have been exposed to. Having an TFT near a microphone setup does seem to give some problems when trying to isolate. Thats why we shut down most of the TFT when recording sounds, that helps a great deal.

On your requests:
1) This is unfortunately not possible simply due to the nature of Auto_TE, we record sound in a buffer and replay this sound slowed down. So the replay takes more time than the recording and thus it cannot be done continous. When testing Auto-TE I tend to listen to the sound of some LED-lighting in the kitchen or the clock-timers in many electronics(often at 33Khz). Those sounds are continous and they are presented to me continous but with small stops in it. But maybe you can share your source that you would like to hear better ?

2) The voltage I am presenting currently is based on this message: https://forum.pjrc.com/threads/26369-Measure-Vcc-like-Arduino-SecretVoltmeter
So we read directly from the internals. I added this feature especially for Lipo (I use those myself) to allow tracking of the draining of the battery. My idea was (the code is currently only a number at startup and the VIN_ADC routine is by default not used) to for instance allow the user to store a baselevel in the EEprom. After that you only need to track the VCC and see how fast it changes (or record the time it has been active ?), when the battery is close tot its depletion point the VCC will start dropping faster. We could use that as a sign. If you are willing to work on the hardware (what works reliable) I am willing to expand this into the code, just send me a direct message from the forum to start cooperating on this. If it works we will add it to the code and share it overhere.
EDIT: additional info in https://forum.pjrc.com/threads/2611...ow-battery-alert?p=69683&viewfull=1#post69683

3)You can play the files directly in Audacity for instance, the only thing I dont like about adacity is the fact that I need to set the SampleRate myself before I can do a proper playback. But next to that it works. Audacity allows you to also playback sections slowed down.

4) By chance Edwin asked me about this the other day, I have changed the code on this point quite a bit. When you send me a PM you can try the code we are working on and see if this new setup is better or not.

Thanks for joining in and adding something to this development !

regards
Cor
 
Last edited:
Hi Zip,

I did some readup on #2 of your requests and added 2 links to older discussions on this forum that might be helpfull. I think the graph in (https://forum.pjrc.com/threads/2611...ow-battery-alert?p=69683&viewfull=1#post69683) is very helpfull. This shows that the readout from Vin (so without the need of any external resistor network) can be helpfull in detecting low power. As far as I know a Lipo starts with a full charge at 4.2V then becomes nominal at 3.7 before dropping off to lower voltages and these should not go below 3V since that can damage the Lipo.
We will not see anything of the voltagedrop of the Teensy until it reaches 3.5v. At that moment the internal reference will start to drop below normal values. To "see" above 3.5V seems to be only possible by adding an external network. It will be easy in the code to simply (lets say every minute) monitor the referencevoltage and keep track of the average value. As long as this value is stable nothing is happening, the moment it does show a tendency to drop we might warn. But this needs good testing, a good way to do this might be to fully charge a lipo and monitor its voltage using the internal refernce over time. For testing purposes its possible to write out these regular readings to an SDcard thus constructing a timebased graph of the discharge of that particular lipo. It would be helpfull to also know the real voltage of the lipo (not every minute but every hour ? 30 minutes ?) measured externally with a proper multimeter.
Based on that I hope to see that we can detect the point in the Lipo voltage drop where the T3.6 starts to also show this. That point can then be used as a warning to the user that the battery is getting drained. Additionaly I would hope that such an experiment also gives some idea as to how much time the system will still continue working properly (writing to an SDcard for instance). That way we can establish the internal voltage level that we should prevent from reaching as the system starts to malfunction. If you are into trying that I can make a special version for you to run a test. Again, use a PM so we can continue working on this.

regards
Cor
 
Hi Zip, nice to see you have some ideas.

And thanks for the pictures of your nice work.

The 23khz is a known issue and seems hard to beat so I hope you have an easy way to improve that. Maybe someone can test with a knowles FG microphone. I am quite sure the larger 23hkz signals are coming form the microphone. If you see the datasheet you can see it peaks at 23khz. Microphone mounting is quite important. Maybe you have seen a document about the microphone and cones in my google drive. The most important is to have the microphone behind a thin wall. I now usually drill a shallow cone in the enclosure so the wall thickness of the box is a few tenths of a millimeter at the microphone port.

I usually run my detector with around 20db than you do not really notice the stronger 23khz signals, when i do some recording I try to be closer and lower the gain so I see less noise in the recording.

The time should be set at compiling, but for people loading a hex file it could meen quite a bit of turning. We recently spoke about it. There already were quicker steps in the code depending on the turning speed. Somehow my encoders also were not able to do the largest steps so in the 0.111 version of the software it already works better (yes there are a lot of newer versions, almost something to be released) .
I tried to convince Cor I'd like something that sets hours when turning quickly, and minutes when turning slowly with some dead band in between. For now we have a version that can turn several quicker steps but maybe there are even better ways.

I just discovered this file did not end up on my google drive.
https://drive.google.com/drive/u/2/folders/1NRtWXN9gGVnbPbqapPHgUCFOQDGjEV1q

It describes how to use the recorded files, the older version of Batexplorer works fine for that purpose, just click open wav, select the raw and enter the sample rate in te windows that pops-up.

Kind regards,

Edwin
 
You must log in or register to reply here.
Back
Top