Bat detector

[benlenkar]

Hi,

The amplitude will be depending on the distance from the key-ring to your detector, the loudness of your ring (intensity), the gain for the one-transistor amplifier (which design ?) and the mic_gain setting of the teensy_batdetector .

One thing you can try to get a bit better understanding of the sensitivity is listening to for instance a constant high frequent signal coming from many devices with clocks inside. I have for instance an audio-player that emits this signal and I can pick it up about a meter away or so ... depending on the gain I use. Or a programmable timer (to switch appliances) will also. When you have a good and reliable source you can start recording/testing your device settings against that.

Cor

EDIT: this is my current 1-transistor amplifier (BC547=BC550c)
Attachment 17298

I use almost the same

/bengt

[CorBee]

I use almost the same

/bengt

I think Edwin has removed C2 from his design later on. But the simulation with LT-spice does show this is probably not going to change the amplification

[pe1pwf]

I think Edwin has removed C2 from his design later on. But the simulation with LT-spice does show this is probably not going to change the amplification

Yes I removed C2, it was supposed to "short" RF signals to ground.
Working with the opamp amplifier it just seemed to pick up display update noise so I chose not to place it.

Also C1 can be changed, If you want to attenuate lower frequency sounds you can lower the value of C1. I guess you should not bring it below 220pF
I do like 220pF myself but you can notice a bit less gain on 20Khz which is not a big problem because the microphones alleady have stronger signals on lower frequencies.

For the microphone, if you have it inside the box, create a seal between the microphone and the box.
Do not use it inside the box just behind a small hole.


I use a cone that I can screw into the box. The cone is because it seems like the microphone behind a "long" audio channel does not work best. The cone also provide some amplification.



I added a picture.

On the left the construction I use,
the second is a microphone behind a hole in the box. I do not recommend that.
The third is a microhone in the box but with a seal, If you can construct that it, it is fine. (do not use a thick seal)
The fourth picture is what I would suggest of the box wall is quite thick
picture number five is just keeping the microphone outside the box.




I do not have any commercial detector so I can not compare.
I was on a bat excursion two days ago, at some moments it seemed my own build picked up earlier, at other times the 300 euro commercial device picked up better.
We were a few meters apart so maybe that also made some difference.

Edwin

[pe1pwf]

Compiling again in windows.

I just put all the files I used together in this zip file.

The text below is also in the zip file..





Compiling Teenst Batdetector in Arduino under windows.



The code written by Cor Berrevoets was made in Linux and not using Arduino. I guess a lot of people are using Windows and Arduino to compile code.
I am absolutely no code writer so there might be a better way to get things going. All I know this works for me.

I used a slightly older version of Arduino IDE. https://www.arduino.cc/en/Main/OldSo...eases#previous
we choose version 1.8.7 since 1.8.9 have me some problems earlier.

To be able to use teensy in Arduino we should also install Teensyduino
https://www.pjrc.com/teensy/td_144/
Version 1.44 works fine with Arduino 1.8.7

Maybe newer Arduino IDE can work but 1.8.7 plus Teensyduino 1.44 or 1.46 work for sure.

We need to copy all the contents of this .zip file to “My Documents”\Arduino
This means we have a folder Libraries and a folder containing the code which now is called teensybat097win.ino in a folder with the name teensybat097win.



Important changes made to the code.

The .ino file actually is the main.cpp by Cor Berrevoets with two small changes.
Around line 206 we have #include <TimeLib.h> this file seems to give us problems in windows so I changed it to #include <TimeAltLib.h> (the TimeAltLib is in the libraries folder you copied to “My Documents”)
The second change was adding this line #include <ff.h> to the libraries.

Now the code should compile in Windows.
Kind regards,
Edwin

[CorBee]

Hi,

I have uploaded the source an hex to Github. No major changes, some cosmetic improvements in the screens (settings).

Added a option to change the libraries used during compilation, #define COMPILER xxxx. As I am working using PlatformIO in Visual Studio Code the default is PIO but it can be switched to ARDUINO for those compiling using the ARDUINO/TEENSY IDE.

Routines added to monitor the voltage on VIN when a resistor-divider and capacitor is added between AGND-pin17(a3)-VIN.

Also added a routine (currently getting tested) to control the TFT-backlight using PWM (pin3). This can be used directly on TFT modules that have a Q1 transistor allready on the PCB, otherwise a few components can be used to achieve this. Pin3 from the teensy should be connected to the base of a NPN-transistor (eg. BC547) using a 1k resistor. The collector of the transistor is connected to VCC using another resistor (can be seen as a current-limiting setting), the value of this resistor will set the maximum backlight-intensity and no "default" is yet known. The Emitor of the transistor can be connected directly to GND and finally the LED-connection from the TFT should be connected to the collector of the transistor. The backlight can than be controlled by 1) setting #define USE_PWMTFT during compilation and setting the param value in the settings-page. Param=0 is maximum intensity, Param=25 is lowest intensity. As stated this is a featured to be tested !

regards
Cor

[CorBee]

Hi,

In the past few days I have been trying to find out if the settings for the microphone on the SGTL5000 codec can be changed to improve the quality of the incoming ultrasound signals.

For this I have used a simple UST (eg Monacor UST-40T) as a speaker directly connected to a TI Stellaris Launchpad that generates a standard sequence of signals. This generates 5 short (0.5 seconds) signals of 25, 35, 45, 55 and 65 Khz followed by a pause of 2 seconds (total sequence is 4.5 seconds). As the UST-40 was made for frequencysignal of 40Khz it can be expected that the 35 and 45 Khz signals will be stronger than the other signals, how much is something I cannot quantify. In the images below this effect is apparent but I cannot state that this is only due to the UST or partially due to the sensitivity of the microphone for a given frequency. The detector and signalgenerator weres for every measurement at exactly the same location/distance. The measurements were also made in a sequence and the settings of the two SGTL5000 registers I was testing was read from the SGTL and stored in a logfile directly after recording.

This is a screenshot of the sequence after loading the RAW file inside audacity


The tests have been done on:
CHIP_MIC_CTRL 0x002A // microphone gain & internal microphone bias (default 0x017x x=dependent on microphone gain)
and
CHIP_REF_CTRL 0x0028 // bandgap reference bias voltage and currents(default 0x01f2)

More info on the options for these settings they can be read at https://www.nxp.com/docs/en/referenc...SGTL5000RM.pdf on page 60/61


I have tested both for MIC_CTRL and REF_CTRL many different variations and these are the settings I found the most interesting:

First (leftside graphs) the spectrum over the full recorded sequence including pause for the default settings and
MIC_GAIN 29 in the second (rightside) graph only the 45Khz signal and I also added the measurement from the contrast function inside Audacity.
IMPORTANT (the graphs are shown rather small and the left-side scales are different, so you need to click on the graphs !!)

MIC_GAIN 29 REF_CTRL 0x01F2 MIC_CTRL 0x0170 DEFAULT
@45 Constrast 18dB

MIC_GAIN 29 REF 0x01F2 CTRL 0x0100
@45 Contrast 20dB

MIC_GAIN 29 REF 0x0002 M_CTRL 0x0170
@45 Contrast 27dB Attachment 17505

MIC_GAIN 29 REF 0x0002 M_CTRL 0x0100
@45 Contrast 28dB Attachment 17504

To me a few things look interesting, first off all changing REF_CTRL seems to give a very strong difference compared to the defaults. The signals at the 25/35/45/55/65 frequencies are (for the same MIC_GAIN) a lot stronger and the backgroundsignal is lower. Secondly most of the harmonics seen in the default graph (look at 75Khz and 90Khz) are nearly invisible in the lowest graphs.

As I have not found any other references to people testing these settings on the internet (looked at several fora and also the PJRC-forum) I also wonder why this was not tested before ? All I did - to make this possible - is adding a public routine to the SGTL5000 library that allows me to read/write to a register.

The results have been so interesting that I have allready built the setting REF=0x0002 and CTRL=0x100 into the next release of batdetector code.

Hope that anybody who has a proper understanding of this (I am NO expert on this) can check if what I have done/tested and concluded are indeed right.
EDIT: The raw datafiles and corresponding logfiles can be found overhere https://github.com/CorBer/teensy_bat...aster/rawfiles

Cor

[remis]

Hello Corbee,
Interresting Test.Could-you add more reference about the generator*?

I think you have too much sub-systems in your test-setup. The first step is the conducted test with a well knowed amplitude , frequency , and impedance generator connected to the input with capacitor. Check with osciloscope too. You will see the effect of parameter change with exactly the same input signal. Adjust the input level*: you will define the best signal input range value. I suggest to start to 0dB internal gain. We have many amplifier before. Don’t change reference for internal ADC.

Thus You wil define the parameters for beautifulest FFT, without harmonics, with best results..and also the range for amplitude signal far from saturation,

If all is OK you should see the best result for 0dB gain with amplitude little lower than max fullscale ( 1,8Vpp?) of ADC. If not there is someting wrong.

Increasing the gain will also increase amplitude , saturations, harmonics witch is confirmed by your results.

The next step will be*: check amplifier stage to be sure that amplitude at codec input in as the same order, as your previous conducted generator, little lower.

Sorry to say it again*: the common mistake is to try all together and pray.
Step by step is the best solution, used also to go to the moon...

I describe some basic amplitude test, fullscale and impedance check in previous message #371.
Could you confimed the mic gain used in your previous version*?
Regards

[CorBee]

Hi Remis,

I do not have equipment to do that kind of testing but maybe others can. The "generator" is as stated a simple MCU generating a PWM signal for a given frequency that is than transmitted using a UST. The only thing I (can) do is use the detector to listen/record those signals using many settings. I cannot measure "parts" of the system as the SGTL5000 is a closed system. Mic_input goes into the SGTL5000, gets processed and can be recorded directly. Be aware that you also see the "top" of all the tests I ahve tried in the past days. I have been first testing step-by-step differences for each register separately to get to the current values for the two settings. But this kind of testing is not difficult and if you have the right equipment to test parts of the setup better I encourage you to do so.
I think the tests I have conducted show that the default settings (as setup in the SGTL5000 library) are not necessary the best settings, NXP not for nothing added the option to change these registers to tune things.

regards
Cor

[remis]

Ok i understand.
Other intermédiate solution could be : compile an oscilloscope :Use the bat detector as a simple oscilloscope to check the fullscale, and the level and the signal seen by the ADC. Some people will say that it is the same as FFT view...but without calculation artefact and FFT windowing effect.
For different parameters you will see the effect on FFT screen

But a low cost oscilloscope with USB connection could be a good calculation also for futur design...

Remi

[CorBee]

Hi,

Isnt the data you can see in the files (raw files on github) allowing that ?


Cor

[remis]

Yes your are right! I forgot the simplest way....
I suggest to start with typical audio spectrum, close to typical application( 3Khz signal with SR=44Khz ) to try understanding and confirm the effect of MIC CTRL paramètres changes, following NXP use case.
Use a low cost DDS sine generator from audio to Ultrasonic test : less than 10$ It could help for your next test.
Regards

[CorBee]

Hi,

I invite anybody who has this kind of equipment to try and test this. For me this was a test and I am allready happy with the progress I made.

Another option would be to generate (using the SGTL5000) a sine, send it out via the DAC of the SGTL5000 and connect the output to the MIC_INPUT.
Both the sine and the DAC are completely controlled so you can set both frequency, signallevel and outputlevel ...

This is the SGTL5000 schematic, you could also bypass the MIC_GAIN part by connecting the sine from lineout to linein. That way you "isolate" effects from the mic pre_amp which only has 4 levels.



regards
Cor

[CorBee]

Hi,

If anybody is willing to do such a test and record the data in a raw-audio file I will be volunteering to do the analysis of the datasets in a standardized way. For this I will be studying some python code to easily do analysis of chuncks of data from a large dataset.

Cor

[CorBee]

What happened before ?
At the beginning of september I tested if changing the MIC_CTRL and REF_CTRL settings on the SGTL5000 had effects on signalstrength and spectrum. My tests were showing clear effects but it was suggested that the results I had obtained could be due to many factors since my testing setup was not standard. As I have no real testing equipment I asked for others to step in to be able to test the effects of these settings in a more controlled environment.
Fortunately Edwin/PE1PWF (THANKS !!) stepped in a few days after I asked for this. He had a Yuntek SY6600 60Mhz DDS signal generator ready for this. After 3 weeks of recording and studying the data its time to share !

Testing setup Hardware

The DDS signal generator was connected using properly shielded cables and a 100nF capacitor to MIC_IN on the audioboard. The normal preamp we are using for the batdetector therefore was not used in these tests. For most tests the signal-generator was set to generate a frequencysweep climbing from 20-60Khz over a period of 5 seconds after which it would restart again. The signal was set to 0.05Vpp.

Since we also wanted to record some "silence" a reed-relay was used to connect/disconnect the signal coming from the signal-generator. This relay was controlled by a 555-IC to allow 8 seconds of signal followed by 2 seconds of "silence".

Testing setup Software
The standard batdetector software was changed to allow automatic recording of a lot of different settings without intervention. After starting a recording the batdetector recorded 10 seconds of data, than changed the setting and recorded another batch until all settings had been recorded. After each recording the setting of REF_CTRL was read from the SGTL5000 and this was stored together with the gain-setting in a seperate logfile.

Dataset
A total of 594 files has been recorded by Edwin. Tested samplerates are 176, 192, 234, 281, 352 and 384. Gain settings were tested in steps of 8 db from 0 to 40 and finally 9 different REF_CTRL settings were used. This results in 6 (samplerate) * 11 (gain) * 9 (ref_ctrl)=594 files.

Processing
All data was processed in a Jupyterlab notebook using python. This setup allows interactive programming and graph output using python. All RAW data was converted to WAV and stored in a separate directory to allow easy processing.

[remis]

Hello Corbee.
It is a good idea to test many configuration with this minimal hardware setup : no preamp, no filter, ( only 100nF) , tun on, off. The only issue could be the small lenght of open wire ( add noise). But is a detail compared with the inital topic : find good parameters for codec input with high sample rate
And use the SD card registering sytem for more analisys is a good idea if we are confident in registerin process.. I'd like to help you. But, As you know I can not compile your big project on arduino .

May be the intermediate solution, with arduino code for me could be the separation of issue :
1/Build a new simple project on arduino for codec
2/Check the behaviour and saturation limits with knowed signal ( DDS)
3/change the parametres and see the effect during a simple loop : input audio direct copy to output ( need simple low cost osciloscope for chek)
4/add a minimal analysis in code to detec saturation and send message on serial ouput.

May be this example is available with the prjc audio design tool. Il will see.
Regards.

[CorBee]

Initial Processing
The WAV files were directly loaded into the jupyterlab-environment using the SciPy library. After loading the data was scaled to a maximum -1..1 range by dividing with 32768.
All data was then processed using a 1024 wide FFT spectrogram using a "hanning" window and overlapping segments. This resulted for each WAV file in a dataset with a few thousand spectra.

The data was then converted to the Pandas database-format for easy handling in python. All FFT data was converted from raw-values to dB. For each FFT-spectrum in the database the local maximum and its bin-location(associated frequency) in the FFT was recorded.

A typical plot of the recorded maxima looks like this (dB on left-axis):

The "silence" in the recording can be clearly seen as the signal drops from -30dB to -70dB.

The same file but than the bin-location of the maxima (estimated frequency on left axis):


Notice that although high-frequency bin-locations are estimated for the "silence" these have no
realistic meaning. Thats why the dataset is automatically cut into two sections.
The cut in the dataset is set for the halfway-point between the smallest and biggest signals.
In the above example the cut is set at -45dB, any spectrum with a maximum larger than -45 dB is considered
to be part of the signal, anything smaller is considered to be part of the "silence".

After this initial processing some tests have been done, they are explained in the next part

[CorBee]

Hi Remis,

Maybe wait with this until you have been able to inspect the results of this work ... I am going to show step by step the process and the results. Doing this all in a single post would be too long

[CorBee]

Testing the frequencyresponse
We are using the SGTL5000 well above its normal specifications to record the frequencies of the incoming signals. Since it was unclear if the SGTL5000 could handle all frequencies equally a simple test was conducted.

We plotted maximum-recorded signalstrength against the frequency of the corresponding FFT-bin(frequency) for GAIN=0 and everything else set to default. For this Edwin generated an extra dataset with several sweeps reaching also above far above 100Khz.

The results can be seen here:

The legend shows the REF_CTRL setting (here default 01F2) and the samplerate.

It is clear that all samplerates do record the data for different frequencies without very large differences in the maximum recorded signalstrengthls within a samplerate.
There is however a clear and constant difference (albeit a few dB) in the signalstrength between the samplerates. To allow additional testing for samplerate 281 and 384 extra long sweeps were generated. These samplerates now also clearly show where the nyquist-criterion kicks in. For all samplerates the maxima of the signals did stay rather stable until the frequency reached 0.42*samplerate .

The same test was repeated with other settings for GAIN and REF_CTRL. Although the average signal-strength for each samplerate was different compared to the above figure it always was rather constant until the 0.42*samplerate point.

The first conclusion for the further tests is that we do not have to look at the response for different frequencies of the sweep.

[CorBee]

REF_CTRL tests
The REF_CTRL setting on the SGTL5000 has two parts that can be changed, the VAG (VAG is the internal voltage reference for the ADC and
DAC) and BIAS which controls the bias currents for the ADC).
The VAG can be controlled in 25mV steps starting with 0x00 as its lowest setting (0.8v) and 0x1F as its highest setting (1.575v), the latter
is the default.
The BIAS can be set between 0..7. The Default setting is 2 where the bias-current is 12.5% above nominal. For our testset we have kept BIAS most of
the time at 2.

The image below shows the effect of changing REF_CTRL on the average signalstrength for our group of samplerates and 3 different gains (0,8,16).
Graphs for higher gains are available but do show effects of a fully saturated signal and are therefor less easy to compare.


The settings for VAG go up from left to right in this graph(Xaxis is REF_CTRL) with the default VAG setting at the rightmost position of the graphs.
The 352/384 samplerates show the largest changes in signal-strength. The conclusion can be that lowering VAG does increase signal strength and that this effect is different per samplerate but comparable for different settings of MIC_GAIN (for instance all lines for SR=176) are sloping in an alike manner. Another conclusion can be that the effect of MIC_GAIN is as expected, the lines are about 8dB apart for any given samplerate.

Next up (tomorrow) is how all this affects the noise (silence recording) and if we get a higher contrast (in dB) between our signal and the recorded silence.

[WMXZ]

Cor, as you are playing with SGTL5000,
In case you missed it, you may be interested in
https://forum.pjrc.com/threads/52798...l=1#post181609
Walter

[CorBee]

Hi Walter,

I know you did those tests but the discussion at that time more or less ended rather fast. Since we had all this data - with the purpose of testing the effects of using REF_CTRL - I thought it would be good to check if there are strong frequency-dependent effects in signalstrength. As in your data we do not see those effects which is a good sign. If you still have the datasets you produced I am interested in them to see if you see the same differences in the signalstrength depending on the samplerate. Off course the differences are just a few dBs so dont matter but ... I like to understand.

Thanks

Cor

[pe1pwf]

Thank you for the nice pictures Cor.

I hope I can show the effects of VAG setting with a few Audacity screenshots.
It will show it is hard to know when the system gets saturated because the signals differ quite a lot with different VAG settings. That is one of the reasons to make a bunch of recordings with different gain settings.

I will show you pictures with two recording on 384Khz samplerate one with VAG set to 1F and ons set to 08 the signal was injected directly into the audioboard using a 100nF capacitor and good shielded cable. The signals injected are 25, 35, 45, 55 and 65 Khz

This first picture shows the wave forms, you can easily see a lot of difference in the signals the lower, set to 08 is much stronger.



next is a picture showing the spectrogram.
You will notice a difference in signal strength, harmonics but to the right you see a huge difference where there is no signal.





The next pictures shoe the spectrum of a portion of the 45Khz signal.
You will notice the 1F recording as lower signal in the 1st harmonic (fundamental frequency) but also the 2nd and 3rd harmonics are stronger.



The picture below is the recording on 08
Where te 1F had a signal of about -11.4 this recording has a fundamental frequency at about -5.3dB



The last pictures show a contrast measurement using a portion of 45Khz signal in contrast to the silent part.

1F


08



The struggle now is to find the best settings per samplerate, fnrunately Cor has a very nice way to do good analysis but.... Best signal to noise ration does not always mean we have the best signal to harmonics contrast so what choice do we want to make.

I do not like the harmonics in my recordings but unfortunetely there just are harmonics to deal with. Even is you cant really see the in the waveform Audacity will show them.

I had my best looking recordings sofar on just 176.400 but one can see the best setting for the lowest harmonics is near 1F (1D maybe or even just 1F or should we pick 1E to be in the middle.)

Anyway lots of data to interpret and lots of choices to make. Whatever values are chosen it will probably never be completely perfect but hey what fun is this audiochip and how much fun is this nice little detector.
Every time I use it, I am amazed by the sounds it picks up.

Kind regards,

Edwin

[aethertech]

Greetings to everyone,

I have been following this thread as time permits with great interest. I have a fair degree of experience with analog and analog to digital conversion at the frequencies of interest. Being an "analog guy", I can only tip my hat in envy to the digital gurus once the analog crosses into the digital domain.

That said, I do have a few suggestions. I looked at the data for the SGTL5000, and, as you likely know, you are not dealing with the best ADC for this job. The most important spec's with regard to a bat detector are bandwidth, S/N, and THD. I am amazed you are squeaking out the bandwidth with the SGTL5000 (i.e., the high sample rate). The very limited performance data provided for the SGTL5000 says you should be able to achieve a S/N approaching 90dB, which is decent. However, the best THD specs state -72dB as possible using the LINE input, and that spec appears to be for a 1.02kHz signal (so likely not achievable at the high ultrasonic frequencies). The mic input doesn't even rise to the level of an honorable mention with regard to performance and appears to be intended mainly for voice.

The above said, I would suggest the following:

1. Stop using the mic input and instead feed your signal into the line input. The ADC can be configured as mono from the left line input using the ADC_MONO register.

2. Do not use any internal gain within the SGTL5000. The internal gain stages are meant for audio BW and will likely run out of gas (and THD correcting negative feedback) if operated at gain.

3. Stop using the transistor preamp. Edwin posted a schematic for an IC opamp based preamp. Using the schematic in his post #369, make the following changes to the components:

A. Do not use R1 and C2 for now (C2 may be added later).

B. Increase C1 to between 1uF and 4.7uF.

C. Increase R2 to 10K. For more decoupling, consider leaving R2 "as is" and add a 10uF cap connected between the top of R2 and ground, and then cut the trace so as to insert a new 10K resistor (R2A) between the top of R2 and the non-inverting input.

D. Change the value of R3 to 51R and the value of R4 to 2.2K. The lower values will generate less noise and the values given will yield around 32dB of gain. R3 can be further reduced to 10R for more gain (47dB with 10R). Start out with the 51R

E. Increase the value of C3 to at least 10uF (or larger). This caps value will determine the amps LF rolloff. However, its ESR will also reduce gain and add noise in the desired passband. Make this cap as large as possible without producing unwanted clipping from LF ambient audio frequency sources (Edwin's cone/horn is likely going to have a LF rolloff below 15k anyway). Also, it is very important that this cap be selected to have a low ESR and a stable capacitance versus voltage curve (C0G/NP0 ceramic or a tantalum). An electrolytic can be used, but use at least 47uF.

F. Increase C5 to at least 1uF, preferably larger. I'd use the same value cap selected in E above, a C0G/NP0 ceramic, a tantalum, or a large electrolytic. The tant and the electrolytic are polarized, technically the positive terminal should be at a higher voltage than the negative terminal (particularly with the tant). I am not sure if the ADC's line input is held at VCC/2 (need to dig a bit more) but there will be some DC offset in the opamp due to the mismatched input impedances. Measure the DC voltage at the opamp output and the ADC's line input and orient the polarity of the cap accordingly.

G. Change out IC1 for a better opamp. I'd use an AD4841-2. Great performance for a low power amp...

One last suggestion. Add an anti-alias filter! It isn't just high frequency signals above the Nyquist that fold back into the desired passband. Noise above the Nyquist will also fold back and add to the noise that's already in the passband. An eighth order brick wall filter with a 160k cutoff would be ideal (though a bit complex), but even a steep second order filter will reduce folded HF noise considerably. The second section of the opamp can be configured as a unity gain second order low pass and would definitely help with folded noise. A -3dB point of 140k-160k is reasonable.

I hope to build this gizmo as time permits and will make some measurements.

Well, that concludes my first post,
aethertech

Added:

I forgot one. Regarding the microphone's VCC, add a 2-5K resistor between VCC 3V3 and the mic's power input. Decouple the microphone side of the added resistor with a cap to ground. Use at least 10uF.

Proper grounding is going to be another discussion and is likely involved in the observed display update noise. That will have to be for another time...

[aethertech]

Hello again,
Regarding my hastily added comment regarding a resistor and decoupling cap between VCC 3V3 and the mics power input, use a resistor between 499R to 1K. I would also use a .1uF ceramic in parallel with a larger 10uF or greater cap for the decoupling cap(s). Placing the .1uF on the mic PCB would be ideal.

Cheers...

[CorBee]

Hi

Welcome to this forum ! I am interested to hear and see your progress in building the batdetector. Several people have been building the system using either the transistor or the IC opamp and it would be nice to see the results of your proposed changes. As I am not a hardware person I am mainly interested in following the improvements people have proposed which often have been helpfull in getting a better signal/noise. For me the biggest step thusfar was to change from a wired-up system using perfboard to a proper designed PCB (by edwin), that helped a great deal in lowering the unwanted system-noise (for instance due to the TFT) creeping in the system.

Have you tried simulating the differences you propose in the hardware in for instance LT-SPICE, previously that has been used to share ideas for the pre-amp. On the SGTL5000 you state not using the gain at all and using the line-input. I have tried using the line-input in the past and with the preamp I had at that time the signal was far to weak to be usefull. You also state that the gain probably will give an increase in the THD. Today I hope to share the results of the tests we (edwin and I) have run recently with respect to background-noise at different gain settings and also the harmonics

Once again, welcome !

regards
Cor