Bat detector

If this doesnt work I would like to know since we have been testing this after a request for it arrived.

I'll check again with the BTO pipeline as soon as I have a "real" recording to submit.

Do you have a recommendation on how to read the content of the guano metadata of a file ?
 
Hi,

There isnt much software that can handle this and show all incorporated data, I have made a simple reader to test GUANO myself based on (https://github.com/riggsd ). Its available for several languages (i work mainly in python).

cheers
Cor
 
Wrapping up the development version, a few days to wait still

Hi,

I am planning to share both the HEX-compiled version and the sourcecode of the current update (development). Edwin also has started updating the manual so that will be also following this "development"-update. With these kind of updates I aim to share changes in sourcecode, new ideas. This upcoming version has one major new thing, we introduce a new way for the Auto-TimeExpansion modus.

The current TE (Time Expansion) simply works by replaying an incoming signal (if its ultrasonic) slowed down by a user set amount. The default for this is 1/10.
Those that have tested this (for instance using DirectPlay with recordings from the internet) will have noticed that a setting of 1/10 is nice for species that have a lot of the spectrum below 60Khz. When a large amount of the signal is higher than 60Khz this will result in slowed down sounds with peaks above 6Khz. And although we can hear these sounds they often also are just high tones, not much tonal variation can be heard from them (at least in my view). Thats why I have added a function we currently call TE_detune. The default setting of this is OFF (at startup) but it can be set between 50 and 100 (=OFF). When set to for instance 75 (50-99 range) the slowed down audio is passed through a heterodyne mixer that is set at 75% of the incoming audio. So the 60Khz signal slows down to 6Khz and then passes the mixer and will be heard at 6-(6*0.75)=1.5Khz. THe mixer will adapt continously and thus lowers the signal down to a range where more "tonal" information can be heard. When listening for instance to common pippistrelles (last week, just before winter started again) this tends to let you easier hear if the bat changes frequency or of two animals with slightly different frequencies are flying around. Its definitely experimental and has been tested mainly using DirectPlay (and a bit with live bats last week) but I hope more of you will have a look at it when we release this for testing. YOu will see TE-HT on the screen when in this mode (Time Expansion - HeteroDyne)

Most other changes are less visible and have to do with more control over the processing of incoming signals, rearranging of the menu structure, enhancing WAV file storage (GUANO), more hardware options (temperature/GPS).
Does development stop after this ?
No ... Just today and yesterday Edwin and I had a discussion on the replay of signals. Currently TeensyBat allows you to replay based on a limited set of frequencies, but this does not take into account at what samplerate a wavefile was recorded. Hence the fact that Directplay (where the signal from the wavefile is processed as if it comes directly from a microphone) is currently set to 192Khz,. But we often dont record at 192Khz and then using DirectPlay on such files is not very helpfull. So we will start changing that part, we will read the samplerate as stored in the wavefile and use that at DirectPlay. Moreover we plan to make the slowed down replay a feature where you set a ratio. So if you set the replay at 1/10 of the original samplerate it will do just that, if you push a file recorded at 192Khz or one recorded at 281Khz the slowdown will be alike thus achieving alike sounds when listening to the audio during replay.
And we are - thierry just recently asked this again - planning to switch to a more modern SD library to allow larger filenames and probably some more functionality.

Hope you are all willing to help developing this further, we dont ask for money ... but its helpfull to hear ideas/comments/errors via this forum !

cheers
Cor
 
Last edited:
Hi Cor,

I was wondering what that detune setting was for :)
Thanks for these detailed explanations, looks very interesting and I can't wait for the winter to end (again)...
 
But be aware that things are more complicated. If you want to store and play up 500 files from an SDcard and be able to directly use them on your detector the length of the filename is going to cost you RAM memory. Your proposal for YYYYMMDD_HHMMSS.wav will thus cost twice as much memory as the current setup. RAM is limited on our T3.6 so its something to think about before acting.

Hi Cor,

Does the existing SD Library (or the new one) support the use of folders? If so, you could just store the list of folders and the contents of the current folder in RAM. For example if you set the limit to 200 (folders and files) you could save 40,000 files but still only need to keep 400 entries in memory. It is then a normal space vs time optimisation to pick the right limit values :)

--
David
 
Hi David,

You must have read my mind :) For the next (real, later this year) update I plan to start storing the recordings in folders. Have not yet decided if they are simply YYMM folders or YYMMDD. The latter seems to be more logical as that will not easily surpass 500 (maximum we use in the upcoming (hopefully tomorrow) development update). And it will be not too difficult to search files that way. In fact .. we can then also opt to record the files as HHMMSS.wav, since inside a folder files will not double like this. However if you move the files around (like copying to a PC) and then dont keep the folders ... that might be a problem. Also ... selecting a file for replay becomes slightly more cumbersome as you first need to choose a folder and then a file. But there are ways to solve that, we can probably create an easy way to select an active folder a settingmenu-style. After that the play option allows you to choose from the files in that active folder.

But thats for later. First we want to get the "development" update available for all to test, even with a few things that are nearly new.

cheers
Cor
 
Last edited:
that will not easily surpass 500

I guess it depends how reliable it needs to be. If we must never exceed a fixed limit (e.g. if there is a fixed in-memory buffer limit) it would be better to dynamically partition the files. By that I mean, do not have a fixed time cut-over, instead start a new folder when the old one is full. There are a few schemes for that:
  • Purely sequential (nnn e.g. 000 - first folder created today)
  • Purely temporal (time of first recording YYMMDD_HHMMSS, e.g. 210408_095800)
  • Hybrid (date and sequence YYMMDD_nnn e.g. 210408_001 - second folder created today)

(I would stick with the full date-time in the file name, if possible, for the simplicity of moving them around, e.g. recombining into a single directory.)

When it comes to implementation, let me know if you want to bounce some ideas around (or I could try to help, although I have not written any C++ professionally for over 15 years).

--
David
 
Last edited:
I guess it depends how reliable it needs to be. If we must never exceed a fixed limit (e.g. if there is a fixed in-memory buffer limit) it would be better to dynamically partition the files. By that I mean, do not have a fixed time cut-over, instead start a new folder when the old one is full. There are a few schemes for that:
  • Purely sequential (nnn e.g. 000 - first folder created today)
  • Purely temporal (time of first recording YYMMDD_HHMMSS, e.g. 210408_095800)
  • Hybrid (date and sequence YYMMDD_nnn e.g. 210408_001 - second folder created today)

When it comes to implementation, let me know if you want to bounce some ideas around (or I could try to help, although I have not written any C++ professionally for over 15 years).

--
David

Hi David,

There is no problem with more than 500 files in a folder. The setup we currently use in the development-release simply scans the first 500 filenames, any other file is simply not going to enter the list of files you can play and thus no memory-overflows. Since this is also only a playing issue we dont have to take care a great deal. And the only important thing stays making sure a file has a unique name.
If the transposing to a new SD-library works fine and we can setting for a longer filename I will use that. The earlier implementation was using numbered files ... but this is not reliable and not easy to maintain. For instance if (and this would be valid when storing in a folder too) you make a recording on the SD lets say with sequenceno 100, and a day later you record again ... you hope to get sequenceno 101. But makeing sure you get that 101 is not trivial. Initially I would simply count the files with a filename conforming to a predefined scheme (eg batf_xxxx.raw/batf_xxxx.wav). I would then simply create the next file based on the next logical count ... but if users had deleted a file of that sequence ... you would overwrite a file or use a "vacant" number lower than an older recording. To do such a scheme clean and reliable is more complex than I would have wished for, you need to scan the highest available xxxx before creating a new one.
Thats was one of the main drivers to go to HEXfilenames, that will never fail and will work for a very long time to come (we are currrently at 606ED7BE). And we all known they dont look pretty, but they do sort fine and also prevent any possible overwrite.

Just chime in with ideas on anything in particular you think isnt working right, isnt working logical, isnt there at all :)

cheers
Cor
 
Hello !

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...

Thierry

Hi Thierry,

Ive solved this issue today, and as a bonus PlayDirect will in the upcoming development-version read the recorded samplerate at replay and use that instead of 192Khz (at least if the samplerate is present in our system).

cheers
Cor
 
Cor,

I did some tests tonight (no bats alas) and I remarked that the detune value, even when saved, is not kept after power off.
Is this on purpose ?

And there is a setting called AHT factor which i don't think has been explained before (and that also does reset to OFF on power off)

Would it be possible to have lower value options for max silence ? I think 3 would be nice. Of course that might not be practical, since they currently go in increments of five. So...

Regards,
Thierry
 
Hi Thierry,

Currently this is indeed not saved. But if enough people have tested this and its clearly handy I will change that.
In your pre-release AHT factor is present, that was an attempt to change the way automatic -heterodyne works. As you know in A-HT mode the detector tunes on incoming detected peaks of the signal. So if a 60Khz peak is detected the detector will settle the mixer at 60Khz (minus 1Khz to at least get some sound). The mixer than lets us hear to the difference in Khz between its setting and the incoming signal. So in this case 1Khz (60 Khz incoming, mixer set to (60-1) = 1Khz). My idea was to not tune at 100% of the peak but for instance at 90% of the peak. In theory an incoming 60Khz would get a mixer-signal of (60*0.9)=54Khz so the resulting audible sound would be 6Khz. And for an incoming signal of 40Khz it would be (40*0.9)=36Khz lower so 4Khz. This way you could hear differences between incoming signals in the tone. And the theory is probably right but the signals are too short to make this effect audible. Ive tested this on the pipistrelle and the heterodyne sound was hardly different from before and for me all these crackles from heterodyne are less distinguisable. I prefer TE just for that reason, it makes the sound of species very clearly different. And although some people will argue that the TE might not make you hear "each" pulse ... every pulse is however having a real tonal aspect. But flavours differ and thats why I hoped to improve A-HT with this.


For the silence I do not mind setting that to "seconds" instead of chuncks of 5 seconds. Minimal setting will then be 1 second, maximum 30 ?

regards
Cor

PS: Ive changed the setting for the maximum silence to seconds, 1-30 and the detune setting will also be saved to EEprom.
 
Last edited:
Hi Cor

Thanks for the explanations, and for the changes !

As for TE-HT, I'm very please with what I hear: It really make a lot of difference for high frequency sounds.
I tried it with samples from the test files provided by Edwin and it makes a lot of difference (in a good way) for example with rhinferr.wav
So for me it's a keeper ! I think it is also quite innovative: I don't think I have seen this on any existing device... (translation: prepare to be imitated :cool:)
Maybe it would be good to integrate it as a new setting in the sequence of modes: FD>Pass>HT>A-HT>TE>TE-HT ? that way it would be easy to switch from standard TE to this new option, without having to go through settings again... ?

As for "max Silence", 1 to 30sec would suit me perfectly but others might think differently, so I'm asking: does anyone oppose to that change ?

Best regards
Thierry
 
Hi Cor

Thanks for the explanations, and for the changes !

As for TE-HT, I'm very please with what I hear: It really make a lot of difference for high frequency sounds.
I tried it with samples from the test files provided by Edwin and it makes a lot of difference (in a good way) for example with rhinferr.wav
So for me it's a keeper ! I think it is also quite innovative: I don't think I have seen this on any existing device... (translation: prepare to be imitated :cool:)
Maybe it would be good to integrate it as a new setting in the sequence of modes: FD>Pass>HT>A-HT>TE>TE-HT ? that way it would be easy to switch from standard TE to this new option, without having to go through settings again... ?

As for "max Silence", 1 to 30sec would suit me perfectly but others might think differently, so I'm asking: does anyone oppose to that change ?

Best regards
Thierry

Hi Thierry,

Glad to hear you like the new mode also. One of the reasons was exactly those sounds from rhinolophus species. At 80Khz or higher slowing it down by 10 you still hardly can hear them. Slowing it down and then passing it through HT does make a difference. I havent started to patent on it :) And its "free" for anybody that wants to copy the idea.

As we can switch between TE en TE-HT currently from the settings I will wait to add it as a new "mode". But if more people ask for it I will, and I have allready decided to push the setting to EEprom. So if you use it you have it available at startup directly.

Anybody agains the range of 1-30 seconds waiting time during a recording for a new signal should state so today or ... otherwise change it themselves in the code. Its not very difficult.

cheers
Cor
 
V1.1development release available

Hi,

Ive uploaded both the code (see the src directory) and a set of compiled HEX files (other directory) on https://github.com/CorBer/teensy_batdetector

The sourcecode is more or less organized as before, except that I have moved the #defines section of the code into a separate file "bat_defines.h". This allows
easier adaptating for those compiling the code themselves, if you arrange that file to fit your hardware you can keep it for a next update.

The two HEX files I have uploaded are both without the PWMTFT feature since its my guess that not many people allready have added the necessary (albeit minor) bits
of hardware.

Edwin also has added a few HEX files on his google_drive based on (...nearly) the same code but with PWMTFT/GPS and the DS18B20 temperature enabled.
Feel free to use any of those and if you run against an issue ... dont forget to tell.

A few important things:
- the EEprom version is different from the previous versions so you will initially loose your old settings. After installing you will need to set your preffered settings again and "save" them.
- there is only one major difference in the audible processing and thats the TE_detune setting to lower the frequency of the TE output (see discussion in the forum). This can be set in the "SETTINGS" menu and can be saved. I would advice to experiment with this, Ive set mine at 75.
-during replay the waterfall and spectrum screens will be working again.
-using playDirect on a file that was recorded using one of TeensyBat's "standard" samplerates the replay will (automatically) try using that speed, for unknown samplerates it will use
192Khz.
-menu's have been restructured. We now have 4 sections (5 when GPS is used).
-several settings have been slightly changed (more on that later)
-most controls work as you are all used to
-i must have forgotten things ;)

I hope that those that will try this update out will report whats good/whats bad/what needs changing/what is missing still ... as we are probably not going to wait a long time before starting to work towards a real update. But I like the updates to be well tested, and although Edwin and I do a lot of testing we cant mimick everybody's settings and everybody's hardware.

Have a good time, hopefully the bats will be awake or wake up soon at your location.

cheers
also on behalf of Edwin who has again helped a great deal,

Cor
 
Hi Cor,

Some first tests this morning,using the precompiled hex, nothing fancy: fingers brushing and keys jangling... no bats at hand in my office :(
No major problems, except for the one below, but which might be my fault anyways...
All the rest looks perfectly fine and is working as designed.
All in all a very nice upgrade, thanks !

Now for my little problem, which probably isn't one.
My current settings:
Sample rate : 192k
SR rec : 384k (same value for Auto record)
SR play : Direct

On playback with these settings I experience extreme slowness, in screen refresh, and sound playback, with interruptions of sound.
This happens with SRate Direct only. When I switch to SR 48 or lower, playback is perfectly fine.
This does not happen with Edwin's sample files, that are also on my SD card and for which SR is 192K only.

If I take SR rec down to 192K, the problem disappears completely.
No slowness for SR values of 234 ,281 , 352... only for 384K, which leads me to...
...the fact that I'm currently using a Sandisk card that is NOT a class 10 (I broke the one I had while working on the enclosure ;)) and I'm beginning to think that it's all caused simply by poor reading speeds of my current card...
If you think this is the source of the problem, please ignore...

On a side note: while in playback, if I use left enc to change the file, the playback doesn't switch to the new file, as it did before (I think), and I have to press left button twice to playback the new file.

More as soon as those damned bats decide to come out and play again :cool:

Regards,
Thierry
 
Last edited:
Hi Thierry,

I think this has to do with the recording being exactly 384k whilst our setting for 384K is in fact 383.5K. The debug should show that, if it finds a "known" samplerate it will tell. Otherwise it switches back to 192K. Can you check this with the DEBUG HEX ?

EDIT:This is what I see when I start playing a 192K and a 384k recording. It tells me that there is a recorde SR of 192000 and a recorded SR of 3835000 ... Its my guess you dont get to see known and probably a recordedSR of 384000
Code:
START PLAYING                                                                   
   barbbarb.wav                                                                 
 recordedSR  192000                                                             
 known SR  192  


START PLAYING                                                                   
   6071c5~1.wav                                                                 
 recordedSR  383500                                                             
 known SR  384


cheers
Cor
 
Last edited:
Here is what I get:
Code:
START PLAYING

   6071cb29.wav

 recordedSR  383500

 known SR  384

PLAY SR 10

384 PLAYER SampleRate: 383500

PLAY DIRECT  CHANGE DETECTOR: AHeterodyne

 outMixer from  heterodyne

  secs(fromHEX)  1618070313

  dateTime  0410 155833

STOP PLAYING
 
Odd, it shows the player reads the 383500 and states it is a known SR. So thats fine but the PLAY SR 10 is not what I was expecting. It should have been PLAY SR 14 (the 14th entry in the known SRs).
Thats odd, I will see into that now. Nice find, not many people use 384K as it is on the edge and probably the least sensitive mode. But ... it should work as expected.

cheers
Cor
PS: the PLAY SR 10 is "before" the knownSR was set, the player SamplerRate is the actual play frequency and that is as expected. So its not the code, question therefore is ... can T3.6 replay at 384K ... Can you share a proper recording with me via PM ?
 
Odd, it shows the player reads the 383500 and states it is a known SR. So thats fine but the PLAY SR 10 is not what I was expecting. It should have been PLAY SR 14 (the 14th entry in the known SRs).
Thats odd, I will see into that now. Nice find, not many people use 384K as it is on the edge and probably the least sensitive mode. But ... it should work as expected.

cheers
Cor

Glad to help !
In the meantime I will fallback to a more reasonable SR.
Thanks for the diagnosis.

Thierry
 
Hi Cor,

I just installed the latest update and have been playing with the settings.

Could you briefly explain 'SampleRate Play' (or point me to any previous discussion)? I notice it changes from 22 --> 32 --> 44 --> 48 --> DIRECT, but once it gets to DIRECT it is stuck on this setting.

Anyway, as always, I am impressed with the effort that goes into these updates, and a very professional looking bat detector/recorder. I'm looking forward to some warmer nights - seems like we have sleet/snow forecast tonight :(

Best regards,

Adrian
 
Hi Adrian,

On my detector I simply can rotate through 8-48Khz and then Direct but if I keep rotating it start (as planned) at 8 again ...

Cor
 
Last edited:
Hi Adrian,

On my detector I simply can rotate through 8-48Khz and then Direct but if I keep rotating it start (as planned) at 8 again ...

Cor

Hi Cor,

I get that behaviour from the main screen, but in the settings menu where I want to save my defaults, once it gets to DIRECT it stays stuck at that setting.

Regards,

Adrian
 
Hi Cor,

I get that behaviour from the main screen, but in the settings menu where I want to save my defaults, once it gets to DIRECT it stays stuck at that setting.

Regards,

Adrian

OK. Thats something I have not checked ... Thanks. I will report back.
 
Confirmation. This indeed locks at direct ... thats unwanted behaviour. I will change that ASAP. Luckily you still have the control from the main-screen :)
 
Back
Top