Bat detector

Thanks for the suggestions, Edwin. The results are:
  • Playing WAV file shows as expected in display (waterfall) and audible in headphones
  • 3.3v good (well, 3.2v but hopefully close enough) both where you indicated and on the mic board
  • Touching the mic (middle) pin produced no display
  • Touching the audio board AF in produced no display (on max gain)
That suggests to me it must be the audio in part of the audio board (audio out is fine). I'll recheck all the soldering (looked good last time I did). Are there any pins that would only be used by the input circuit (apart from the mic and mic_gnd ones)?

--
David
 
I put an oscilloscope across the AF in on the audio board and touched the middle pin on the mic board and could see some nice noise ~1v peek to peek (not 0.2v as originally states, as someone had forgotten how to use the 'scope!). I assume that signal is large enough! (Jangling keys gives a signal of <1mv at the audio in.) I guess that means things are working past the pre-amp, leaving the audio board at fault :-( I believe the fact I can measure a signal rules out a short at the audio input. All soldering looks OK, but when I have time I'll try remelting all the joints to make sure.
 
Last edited:
Re: The arcticle in the german magazine "Funkamateur"

I'll post some details about the article after takining a nap.. i'm pretty tired and it is friday...
Short: Sound output is via PWM. Input with a ICS40730 microphone, which is, according to the article, difficult to solder.
Martin shows 4 variants of converting the ultrasonic sound to the audible range.

The schematic: The mic ICS-40730 signal goes to the two op-amps of a LM4562, and from there directly to pin A0 which is used as A/D.
Output, as mentioned, is a PWM on pin D4/D7.

No I2S, no audio shield.

Software variant 1: Mixing. The input signal is mixed with a local oszillator signal (DDS). As this allows a small range of frequencies only, there are running 24 mixers in parallel (outputs added)
Software variant 2: Recording and saving a short time, then playing.
Software variant 3: Recording in chunks and playing simulantously, kind of time slice.
Software variant 4: A "analog" frequency divider in software with restoring the amplitude by multiplying the divided frequency somehow with recorded amplitude.
 
Re: The arcticle in the german magazine "Funkamateur"



The schematic: The mic ICS-40730 signal goes to the two op-amps of a LM4562, and from there directly to pin A0 which is used as A/D.
Output, as mentioned, is a PWM on pin D4/D7.

No I2S, no audio shield.

Software variant 1: Mixing. The input signal is mixed with a local oszillator signal (DDS). As this allows a small range of frequencies only, there are running 24 mixers in parallel (outputs added)
Software variant 2: Recording and saving a short time, then playing.
Software variant 3: Recording in chunks and playing simulantously, kind of time slice.
Software variant 4: A "analog" frequency divider in software with restoring the amplitude by multiplying the divided frequency somehow with recorded amplitude.

Hi Frank,

Thanks for sharing, we will only know if something can be learned from the ideas if its tried and tested. Time probably will tell.

cheers
Cor
 
Last edited:
Hi everyone !

New guy here: just finished assembling my device (Thanks Edwin for providing the kit !) and it works like a charm !
I'm very pleased with it and can't wait to use it "for real".

Just to present myself:
Longtime amateur naturalist, essentially botanist but interested in all sort of things, including (of course) bats but also crickets (which I cannot hear, thanks to bad hearing since I was a kid).
I have build several devices over time, for me and my friends, notably a stereo heterodyne device with microphones attached to both sides of the headset, giving the user a "3d sense" of the sound origin.
But all those devices were "classic" analog electronics, no digital sound processing up to now.
I must say that I'm blown away by the sound quality in comparison with what I used before...

So a big thank you to all of you for making this possible !

I'm not much good in electronics or signal processing, and know little about teensy programming, so I probably won't be contributing much... sorry.
I will provide (when I'm sure it's mature) the design of the enclosure I made for 3D printing: I hope it's useful to someone.

One question: Is there a link to the latest / up to date software in hex format ? I'm currently running a version dated October 5 2020.

I would also be very interested by any development towards adding a BT module to send the sound to a wireless headset, or a remote speaker for monitoring. I intend to try some thing on my side, but if anyone has recommendations...

Thanks
Thierry
http://floredefrance.com
 
Hi Thierry, this Oktober 5 version is probably the date you are referring to on my google drive, this is the 1.x version with hex filenames. That is indeed the most recent version that is released.

Cor has been quite busy on the software and we are testing something that looks like it can be released soon.
Unfortunately our tests are limited to generated sounds and we want to test with live sources before deciding if the software is fine to release. The bats are still scarce because of the cold weather.


The easiest bluetooth solution is this.

2021-3-27 19-24-16.jpg

I had one buit-in the detector, just the same unit pried apart and soldered in the detector as far away as possible form the microphone. Unfortunately the RF signals seem to interfere so it was very hard to keep the noise out.

In the picture you can see a Bluetooth transmitter/receiver with a switch to select RX or TX and two jack plugs. Plugged into a powerbank and connected by 3.5mm cable to the headphone connector. I used an extra clamp on ferrite core but this is just out of precaution. Anyway, with tis external plug-in solution you can keep the bluetooth transmitter away from the detector. The bluetooth device needs a trigger to start transmitting so you will miss the first clicks of a bat but it is a nice way to put it in the garden and listen indoors.

Oh, I ran out of circuitboards but I received some today.

Kind regards,

Edwin
 
All soldering looks OK, but when I have time I'll try remelting all the joints to make sure.
Looks like that did the trick, as I now have some signal displayed, if I turn the gain up over 50. However, I hear nothing. (Tried rubbing fingers and jangling keys. I even tried gently rubbing the top edge of the mic board - as I thought that would be guaranteed to generate something.) Suspecting I have done something nasty to the mic!
 
Hi David,

You should hear something if the spectrum shows something or when the waterfall is scrolling.

I normally don't need gain higher as 30 to start seeing some noise if I am near my computer, or switching power supply's like phone chargers or led lighting for example as you can see in this video.

https://youtu.be/iMiBkAZAaV8

I just tested a unit that I am assembling, if the gain is on 30 and I touch the center pin of the microphone (microphone not present), I see a scrolling waterfall and hear lots of noise, not matter what mode I use.

Maybe it is a good idea to start testing in F_D mode. This mode does not need a "trigger" like TE does.

Use F_D (Frequency division)
With gain on 30 and no microphone attached you should hear a little bit of white noise. Higher volume and high gain wil result in unpleasant white noise.

If I touch the center contact (vol55, gain30) the pleasant low volume white noise turns into an unpleasant higher pitched noise.
If I touch the mic in pin of the audioboard (indicated as AF input on the picture I sent before) I can hear a humming sound, even with gain on 30.

These test were done with a complete working unit without the microphone.
I hope this helps you determine where the problem is.

If you do see the waterfall scrolling you should hear some noise. Except in mode "Pass" maybe. HT A-HT F_D and TD should result in audio in your headphones.
Check the volume setting, and your headphones. And do not use headsets (with microphone and four contact jackplug)

I can't think of anyting in the settings that you might have messed up, but you could always restore to defaults by pressing the left button upon powering up the detector.

Kind regards,

Edwin
 
Sorry for the confusion, when I said "I hear nothing" I meant apart from noise. No signal from and sound or ultrasound I can generate.

I'll try harder tomorrow, but tested quickly just now. With the mic attached, gain 30, there is gentle white noise and touching the AF in on the audio board gives a nice low hum and touching the mic middle pin gives a higher tone. Only trouble is, unlike you video, rubbing fingers, jangling keys, rubbing the edge of mic board and tapping the main board produce no noticeable sound or display on the screen. I was going to try a photo, but switching my phone camera on quickly turned the display white!
 
Hi everyone !

New guy here: just finished assembling my device (Thanks Edwin for providing the kit !) and it works like a charm !
I'm very pleased with it and can't wait to use it "for real".

Just to present myself:
Longtime amateur naturalist, essentially botanist but interested in all sort of things, including (of course) bats but also crickets (which I cannot hear, thanks to bad hearing since I was a kid).
I have build several devices over time, for me and my friends, notably a stereo heterodyne device with microphones attached to both sides of the headset, giving the user a "3d sense" of the sound origin.
But all those devices were "classic" analog electronics, no digital sound processing up to now.
I must say that I'm blown away by the sound quality in comparison with what I used before...

So a big thank you to all of you for making this possible !

I'm not much good in electronics or signal processing, and know little about teensy programming, so I probably won't be contributing much... sorry.
I will provide (when I'm sure it's mature) the design of the enclosure I made for 3D printing: I hope it's useful to someone.

One question: Is there a link to the latest / up to date software in hex format ? I'm currently running a version dated October 5 2020.

I would also be very interested by any development towards adding a BT module to send the sound to a wireless headset, or a remote speaker for monitoring. I intend to try some thing on my side, but if anyone has recommendations...

Thanks
Thierry
http://floredefrance.com

Hello Thierry,

Welcome overhere, its nice to see another photographer using Olympus micro 4/3 in this group.

As Edwin allready stated we are planning to release an update soon. Most of the new/changed features have been tested but some of them need "real" bats to get tested properly. The weather in the Netherlands seems to improve the coming days so I hope we can run a good test this week.
We will inform using the forum when the source and pre-compiled hex becomes available, this will be another "development" update. I name these development updates to show that not all the features in those updates will be permanent. Some things we try look interesting initially but after some time we can decide to remove them. This however does not mean these releases are not "stable", we do test before releasing.

The precompiled hex of the initial release and the development update are here
https://github.com/CorBer/teensy_batdetector/tree/master/pre_compiled_hex

regards
Cor
 
I'll try harder tomorrow, but tested quickly just now.

No matter what I try, I cannot generate any signal through the microphone. (I can inject noise by touching various parts of the mic board.) That makes me think my initial guess that I broke the microphone was correct, so I have ordered a couple of replacements from Edwin.

While waiting for them to arrive, I thought I would try to understand the analogue parts of the circuit better, which leads me to some silly questions I hope someone can answer for me. First I wanted to check my assumptions about what signals I should be expecting to see. I started with the SPU0410LR5H-QB datasheet, which gives a sensitivity of -38 dBV/Pa (94 dB SPL @ 1 kHz). A bit of searching suggests this corresponds to ~12.5mV change for 1Pa pressure change. That would be useful if I knew the sound pressure generated by jangling keys, rubbing fingers or even a bat! Next I started from the other end. I believe the audio board input would like to be ~3Vpp, but typically we add a gain setting of 30 in the ADC, but I don't know the units for that! I also don't know the gain for the pre-amp in the appropriate frequency range. (I think I read something like 35dB, but higher gain at higher frequencies.) Can anyone give me some figure for what I should be seeing? (i.e. Vpp output from the mic and the input to the ADC, or the gain or anything else that might be useful.)

A related question is about the ICS-40730 which I thought I read was less sensitive, but the data sheet also states -38 dBV/Pa (94 dB SPL @ 1 kHz). Is the difference because we are interested in much higher frequencies and he ICS drops off more than the SPU?

The next question is perhaps even sillier and shows my great ignorance. I was puzzling over the power supply circuits, specifically the RC pairs. I understand the theory, they are to smooth the supply/low pass filter/decouple different power consumers, but what I don't understand is the R values. R7/C8 and R10/C10 are 4.7 ohms, but R11/C11 is 47 ohms. Is that because if needs to filter a different frequency or because the mic/preamp circuit draws lower power or it needs more decoupling from the rest? How are the values chosen? Is it experience, trial and error, using a simulator and experimenting or is there a formula? (I said it was a silly question.)

Thanks for any knowledge you can share.

--
David
 
Hello Thierry,

Welcome overhere, its nice to see another photographer using Olympus micro 4/3 in this group.

As Edwin allready stated we are planning to release an update soon. Most of the new/changed features have been tested but some of them need "real" bats to get tested properly. The weather in the Netherlands seems to improve the coming days so I hope we can run a good test this week.
We will inform using the forum when the source and pre-compiled hex becomes available, this will be another "development" update. I name these development updates to show that not all the features in those updates will be permanent. Some things we try look interesting initially but after some time we can decide to remove them. This however does not mean these releases are not "stable", we do test before releasing.

The precompiled hex of the initial release and the development update are here
https://github.com/CorBer/teensy_batdetector/tree/master/pre_compiled_hex

regards
Cor

Thanks Cor !
I can't wait to see what you cooked up for us ! :D
Should be soon now: I'm in the north of France and I saw/heard my first bats for the season tonight. Next few days should come with good temperatures at night.
 
Thanks Edwin,
I will go with your BT solution I think: seems safer than to try to have an inside BT module... and I have just the right powerbank for that !
 
Thanks Cor !
I can't wait to see what you cooked up for us ! :D
Should be soon now: I'm in the north of France and I saw/heard my first bats for the season tonight. Next few days should come with good temperatures at night.
Hi Thierry,

Yesterday evening I had my first two pipistrelles flying around our house. So finally I could test one of the new features and I was not unhappy with the result. Unfortunately Edwin was testing at the same moment (a few 100km further N from me) and had problems switching the new feature on/off. So something in the code is not yet as we want it to be. I do hope this is not a major issue but just a variable that is not assigned properly. In the coming days I will try to remove this issue.

regards
Cor
 
Hello !

From the considerable height of my three days of expertise in using the detector, I thought of some suggestions to make...:p
Feel free to discard them, of course !

1 maybe a (minor) bug: on the playback screen the left encoder is set to change SRate. Values go clockwise from 8 to 48, then Direct. Once on direct, if your turn anticlockwise, you should go back to the previous setting that was 48, but instead you go back to 8. Just a minor annoyance really, but...

2 suggestion(s): when in AutoREC mode, on the waiting screen, would it be possible to display the number of existing records for the current session ? That would enable us to see if the detector has already caught something or not, without to have to stop recording. I think it might be useful (and maybe also to display the total number of recordings present on the SD card, and/or free space)

3 this one is really "just for consideration".
As I explained in presenting myself, I'm used to the comfort of stereo listening devices: they enable the user to get the "natural 3D feeling" of where the sound is coming from, which facilitates considerably the eye search and the mapping of trajectories. Of course, while this is true with bats, it is also even more useful with orthopterae, when trying to locate them in the grass to get a picture...
Well I do realize that this is not a simple evolution, but I thought of suggesting it, even if I confess that I do not have a precise idea of what this involves on the hardware side... two mics, obviously, but I suppose the teensy audio is wired for stereo ?

And on a minor note: I think "Pauze" does not come with a z :eek:

Thanks again for the work you did on this: I'm really enjoying myself with this !
Thierry
 
Hello !

From the considerable height of my three days of expertise in using the detector, I thought of some suggestions to make...:p
Feel free to discard them, of course !

1 maybe a (minor) bug: on the playback screen the left encoder is set to change SRate. Values go clockwise from 8 to 48, then Direct. Once on direct, if your turn anticlockwise, you should go back to the previous setting that was 48, but instead you go back to 8. Just a minor annoyance really, but...

2 suggestion(s): when in AutoREC mode, on the waiting screen, would it be possible to display the number of existing records for the current session ? That would enable us to see if the detector has already caught something or not, without to have to stop recording. I think it might be useful (and maybe also to display the total number of recordings present on the SD card, and/or free space)

3 this one is really "just for consideration".
As I explained in presenting myself, I'm used to the comfort of stereo listening devices: they enable the user to get the "natural 3D feeling" of where the sound is coming from, which facilitates considerably the eye search and the mapping of trajectories. Of course, while this is true with bats, it is also even more useful with orthopterae, when trying to locate them in the grass to get a picture...
Well I do realize that this is not a simple evolution, but I thought of suggesting it, even if I confess that I do not have a precise idea of what this involves on the hardware side... two mics, obviously, but I suppose the teensy audio is wired for stereo ?

And on a minor note: I think "Pauze" does not come with a z :eek:

Thanks again for the work you did on this: I'm really enjoying myself with this !
Thierry
Hi Thierry,

Thanks for sharing those usefull comments.

1) This has to do with a bit of "trickery" from my side. When you rotate the encoder on playrates it can set values from 8 to 88, but 88 is a dummy value that signals that the user wants to play "Direct". After selecting this the play_SR is in fact 192Khz and thats outside of the 8 to 88 range. So upon restore you get this behaviour. Its as you say a minor "annoyance"

2) That is odd as the code shows me that we have a line that shows the incrementing number when using autorecord (starts at 0 when you start autorec). Can you share more details on the version and the settings ? The screen should read "AUTO RECORD # xxx" where XXX is the number of the current recording. Displaying the no of recordings on the card can be done, I dont know how easy I can read free space but I will look into that. But in the case (like my setup) where you also have prerecorded files with many species (at 192Khz to demo the system) the counter will simply tell how many WAV/RAW files can be found. Nothing fancier than that. Where should that information be shown BTW, its not part of the default screen as that is allready cluttered enough.
EDIT: There is in the current library we use for SD reading/writing no option to estimate free space. I am considering to look into upgrading to a more recent SD library.


3) Stereo sounds simple but with the current setup would demand quite a bit of changes. First of all on the soundcard (SGTL5000) we only have one microphone entry, so for stereo we would have to switch to line_in. This is however not impossible as the soundcard has L and R linein. But you would also need to change the PCB to preamplify quite a bit more and for two instead of one channel. Not impossible again, but demands quite a bit of changes on the PCB ... and we dont have that much space on the PCB. But Edwin is the master on that field a nd he will probably chime in later. On the software side, this will give quite a bit of challenges I think. We use large buffers in memory for processing/saving. Those buffers will for some parts need to double in size to work in the same fashion. But we dont have that much memory. And I also wonder if this would not demand a switch to the Teensy 4.1 as the processing power will demand also more to keep the delay between microphone and output as short as possible. And finally ... setting up a pair of microphones for stereo isnt trivial also. So for the moment being ... I dont think we will jump into this straight away :)

As a sidenote, my tests yesterday in the garden were succesfull. The new feature worked as planned and I have the feeling the issues Edwin had the day before have been wiped in yesterdays update. Edwin told me last evening he had a rather large test with autorecord where he had recorded 700 files or so, only a few were without bats. So I think most features we have tested with good results are ready to be tested by more people. As stated, the next update is a development release so ... nothing is perfect not even during the Pauze ... or Pause :)

cheers
Cor
 
Last edited:
I read that as Edwin had recorded "...700 flies...", and was thinking that's a lot of flies! :)

Anyway, I'm always happy to try out a new development version. Looking forward to using the new features.
 
I read that as Edwin had recorded "...700 flies...", and was thinking that's a lot of flies! :)

Anyway, I'm always happy to try out a new development version. Looking forward to using the new features.

We might try adding a "fly-detecting mode", as it is the 1st of April that would be something for a topic

I am hoping to wrap things up in the coming days. The largest change will be in the TE-mode, for all other modes the changes are less visible/audible.

So for those that actively follow this topic: Anybody interested in testing an early HEX-only version ?

This will have all new changes in it except for using GPS/DS18B20 as that would only be usefull for those that have a GPS/DS18B20 temperature sensor available.
It will only work in the default microphone setup (so no ADC or LINE_IN)
It has the option to use PWMTFT (so presets for screen brightness, screen OFF in outrecord)
Is without the new fly-detecting mode ...

cheers
Cor
 
Last edited:
Cor,

For point 1: I can live with it, no problem.

Point 2: sorry I was not precise enough. All you say is correct and I can see the numbers while the recording runs.
What I meant is that in between the recordings, current (or next) record number is not displayed.
So if I come to the device and it is not recording at that time, I can't see how many (or even if any) recording have been made and I have to wait for the next one to start to see the current number of records for the session (and sometimes this can be quite a long wait: where I am, bat can be few and far between).
The alternative is currently either to trigger a "false" recording or stopping the operation altogether and go to "play" and check the last recording number, both of which are not very satisfying.
So if the screen could display the current record count between recordings, that would be nice so that we can decide that we have or not enough recordings to stop the session.
Is that clearer ? I hope ;)

Point 3: Well, I was quite sure that would be the case, but I thought I would put it as a "feature request" if there is a V2 of the hardware sometimes in the future.
In the meantime, I still can use my previous device which has bad sound but in stereo :p

As for the next version of the software, I can't wait to see what you cooked up: you sure know how to warm up your audience !:D
 
Cor,

For point 1: I can live with it, no problem.

Point 2: sorry I was not precise enough. All you say is correct and I can see the numbers while the recording runs.
What I meant is that in between the recordings, current (or next) record number is not displayed.
So if I come to the device and it is not recording at that time, I can't see how many (or even if any) recording have been made and I have to wait for the next one to start to see the current number of records for the session (and sometimes this can be quite a long wait: where I am, bat can be few and far between).
The alternative is currently either to trigger a "false" recording or stopping the operation altogether and go to "play" and check the last recording number, both of which are not very satisfying.
So if the screen could display the current record count between recordings, that would be nice so that we can decide that we have or not enough recordings to stop the session.
Is that clearer ? I hope ;)

Point 3: Well, I was quite sure that would be the case, but I thought I would put it as a "feature request" if there is a V2 of the hardware sometimes in the future.
In the meantime, I still can use my previous device which has bad sound but in stereo :p

As for the next version of the software, I can't wait to see what you cooked up: you sure know how to warm up your audience !:D

Hi Thierry

point 2: I will add that to the code. Thats easy to arrange in the upcoming update. When waiting for a new trigger it will display the no of recordings thusfar during this AutoRecord run.
UPDATE: added to the code "WAIT for signal rec# xxx"

And for the next version .. its not even an easter egg ... Ive uploaded a hex-tester on github ... This is however NOT yet the final updateV2 we are working on. But I think its very close, allways good to have early adapters trying to give it a push.

Cor
 
Last edited:
Thanks Cor !

Will try this tonight.

Noob question (again): is there a way to enter programming mode without pressing the Teensy button ?
I thought it was possible to use the "reboot.exe" utility but this give me an error:
Teensy Loader is unable to read your compiled sketch (r) This error should never happen.

Well it does... ;)

Of course I can always reopen the enclosure...
 
Hi,

I never have to use that mode since I am using a rather different setup (linux with direct programming via VisualStudio Code and platformIO over the USBport), but I am sure other can tell.

Cor
 
In another thread Paul states: https://forum.pjrc.com/threads/46894-Uploading-hex-files-via-teensy_loader_cli-without-pressing-the-reset-button

Run teensy_reboot first. You can find a copy in Arduino's hardware/tools folder.

There is *never* a perfect guarantee of a reboot into bootloader mode without the button press. If your code disables interrupts or stays in a low power mode or shuts off the USB hardware, teensy_reboot will not be able to communicate with your code to request the reboot.

Every Teensy is made with a pushbutton dedicated only to entering programming mode, because these scenarios are possible. The only way to recover if your program prevents USB communication is a physical button press... or pulling the Program pin low, which is all the button really does.
 
Back
Top