Bat detector

Two styles of T_4.1 on the desk here:
> single 6 pin (as in p#1024) by Flash top label seems to read "65" >> Last one PJRC sent
> others two smaller discrete 'spec' sized parts there

Both working here with and without vBat powered with edit CardInfo posted below.

With battery warm or cold restart the time is maintained and the SD card details show up:
Code:
Initializing SD card...Wiring is correct and a card is present.

Card type: SDHC

Volume type is FAT32

Volume size (Kbytes): 31154688
Volume size (Mbytes): 30424
Sun Jul 23 12:27:44 2023

edited example > loop() shows TIME to confirm time kept:
Code:
/*
  SD card test */
// include the SD library:
#include <SD.h>
#include <SPI.h>

// set up variables using the SD utility library functions:
Sd2Card card;
SdVolume volume;
SdFile root;

[B]const int chipSelect = BUILTIN_SDCARD;[/B]

void setup()
{
  // Open serial communications and wait for port to open:
  Serial.begin(9600);
  while (!Serial) {
    ; // wait for serial port to connect.
  }

  Serial.print("\nInitializing SD card...");


  // we'll use the initialization code from the utility libraries
  // since we're just testing if the card is working!
  if (!card.init(SPI_HALF_SPEED, chipSelect)) {
    Serial.println("initialization failed. Things to check:");
    Serial.println("* is a card inserted?");
    Serial.println("* is your wiring correct?");
    Serial.println("* did you change the chipSelect pin to match your shield or module?");
    return;
  } else {
    Serial.println("Wiring is correct and a card is present.");
  }

  // print the type of card
  Serial.print("\nCard type: ");
  switch (card.type()) {
    case SD_CARD_TYPE_SD1:
      Serial.println("SD1");
      break;
    case SD_CARD_TYPE_SD2:
      Serial.println("SD2");
      break;
    case SD_CARD_TYPE_SDHC:
      Serial.println("SDHC");
      break;
    default:
      Serial.println("Unknown");
  }

  // Now we will try to open the 'volume'/'partition' - it should be FAT16 or FAT32
  if (!volume.init(card)) {
    Serial.println("Could not find FAT16/FAT32 partition.\nMake sure you've formatted the card");
    return;
  }


  // print the type and size of the first FAT-type volume
  uint32_t volumesize;
  Serial.print("\nVolume type is FAT");
  Serial.println(volume.fatType(), DEC);
  Serial.println();

  volumesize = volume.blocksPerCluster();    // clusters are collections of blocks
  volumesize *= volume.clusterCount();       // we'll have a lot of clusters
  if (volumesize < 8388608ul) {
    Serial.print("Volume size (bytes): ");
    Serial.println(volumesize * 512);        // SD card blocks are always 512 bytes
  }
  Serial.print("Volume size (Kbytes): ");
  volumesize /= 2;
  Serial.println(volumesize);
  Serial.print("Volume size (Mbytes): ");
  volumesize /= 1024;
  Serial.println(volumesize);


  //Serial.println("\nFiles found on the card (name, date and size in bytes): ");
  //root.openRoot(volume);

  // list all files in the card with date and size
  //root.ls(LS_R | LS_DATE | LS_SIZE);
}


[B]void loop(void) {
  time_t t = rtc_get();  // get current time in seconds after 1970-01-01
  Serial.print(ctime(&t));  // pretty print the time
  while (1) delay(10);
}[/B]
 
The .65 marking is the same as i have here.

The last version should have an other 6pin chip.

"Teensy 4.1 manufactured after March 2023 has U4 replaced by TLV75533P, D1-D2 replaced by BAT54CTB6, and a different SD socket (J2)."
I guess the best way to see if you have the latest version is looking at the micro-SD socket. The pins solder connection are no longer visible in the latest version. My picture was with the old socket.

The marking on the 6-pin chip should be TY I guess.

This is the table I see in the datasheet.
BAT54TB6 TH
BAT54ATB6 TJ
BAT54CTB6 TY
BAT54STB6 T6
BAT54DTB6 TL
 
The .65 marking is the same as i have here.
...

Good point - those 'latest' PJRC direct items arrive early FEB - so ".65" not the 'latest' revision for that part.

Though these two PJRC units do have the altered SD socket where soldered pins migrated under the top cover from the forward edge.

The repro test code in prior post would rule out/confirm it isn't from other 'batty software' perhaps if it indeed some 'newer' part is having a bad influence, as they work here.
> Though not on the PCB/hardware as shown in demo.
> Though perhaps battery here is at a diff point in voltage life curve [here at ~2.92 V].
 
Good morning together,

the Teensys I have here are from two different suppliers and I don't think tey are from the same batch.
Both boards have a SD card socket with "invisible" pins, but one has a diode array marked with "TY" and one marked with "65".
I assume the phenomenon has nothing to do with the diode types, because it's all the same behaviour with both boards.

Anyway, I will check the voltages at the diode array...

Regards, Thorsten

Edit:
BTW, if the battery is populated time and parameters are preserved, so this works fine...
 
Man this really is a stange one. Two different Teensy's from different batches give the same error, so it is not expected in the Teensy's
You measured the connections on the mainboard to the teensy and those seemed fine. The software is the precompiled version from Cor's Github as most other uses loaded into their prooject
Maybe I should just send you another mainboard so you can test that, and not only rely on the measurements.

Did you also try the code defragster wrote about?
 
Here are the measurements with the CR2032 inserted, diode array is type "65":

Power off or no LiPo battery connected:

A2 3,064V
K1-4 2,845V
A3 0,251V
A4 0,030V

Power on:

A2 3,070V
K1-4 3,260V
A3 3,300V
A4 2,072V

Regards, Thorsten
 
Good morning together,

the Teensys I have here are from two different suppliers and I don't think tey are from the same batch.
Both boards have a SD card socket with "invisible" pins, but one has a diode array marked with "TY" and one marked with "65".
I assume the phenomenon has nothing to do with the diode types, because it's all the same behaviour with both boards.

Anyway, I will check the voltages at the diode array...

Regards, Thorsten

Edit:
BTW, if the battery is populated time and parameters are preserved, so this works fine...

Was this basic p1025 sketch tried? : pjrc.com/threads/38988-Bat-detector?p=329279&viewfull=1#post329279

Time was ONLY added to that simple sketch to verify each execution after power on that the battery was or was not connected, and of course working as expected on a cold power start.

If that fails then it rules out the loaded sketch and calls into question the Teensy or the PCB supporting it if not removed. If it runs on the PCB - or if the Teensy is not connected to the PCB, as here, it gives more info ...

The FEB 2023 unit with ".65" came as a pair - just tried on the other and pulling that posted sketch works as expected with and without battery. Even edited the comments from this "root.openRoot(volume);" and the .ls() that follows and 7 pages of files listed are displayed.

Also noteworthy perhaps: IDE 1.8.19 with TeensyDuino 1.59 beta 2 is in use here.
 
No coin cell inserted:

Initializing SD card...Wiring is correct and a card is present.

Card type: SDHC

Volume type is FAT32

Volume size (Kbytes): 15549952
Volume size (Mbytes): 15185
Mon Jul 24 09:13:18 2023

Coin cell inserted:

Initializing SD card...initialization failed. Things to check:
* is a card inserted?
* is your wiring correct?
* did you change the chipSelect pin to match your shield or module?
Mon Jul 24 09:17:21 2023

That doesn't look good :-(
 
No coin cell inserted:

...
That doesn't look good :-(

No, it does not look good.
It shows it isn't related to the larger and more complex program though so easier to repro.

What happens if a battery is properly connected to the T_4.1's when not placed in the PCB sockets?

One prior test was on a unit on a PJRC supplied simple PCB, and had headers row mounted to plug in battery.

Two other units tested worked just having male pin wires from the battery (thus the adding of the date print to assure it was being 'connected') just pressed into/against the vBat and GND holes on the T_4.1.

The with the 32GB SDHC card inserted all three worked.
 
Ok, I used my second Teensy and connected the coin cell (with holder) directly to the VBAT pin.
All worked fine. SD is recognized with coin cell inserted.

So I think I will remove the lower pin header on the TeensyBat base board and take a look at the pads...
 
Ok, I used my second Teensy and connected the coin cell (with holder) directly to the VBAT pin.
All worked fine. SD is recognized with coin cell inserted.

So I think I will remove the lower pin header on the TeensyBat base board and take a look at the pads...

Good luck getting it resolved.
 
Hi defragster,

Thanks to you and Edwin for chiming in with this rather odd issue. I hope this resolved the problems. Oddly enough I am subscribed to this thread but never got a message that something was going on. Luckily (for me) it had mainly to do with hardware ;)

cheers
Cor
 
Thanks for the superb project.
Works geat.

Just an Idea
is it possible to jump directly into the settings by long pressing the L-ENC
and activate the Auto-Recorder by long pressing the R-ENC
 
Thanks for the superb project.
Works geat.

Just an Idea
is it possible to jump directly into the settings by long pressing the L-ENC
and activate the Auto-Recorder by long pressing the R-ENC

Hi,

Long press R has allready been programmed to save a screenshot to the SDcard. So it would need a special routine to first catch a long L-Enc and then a long R-Enc.
I will consider this in the next update as a request to activate the auto-recorder directly.

cheers
Cor
 
Hi Cor,

As I said, this is just an idea to possibly make it easier to use.
Especially the direct access to the auto-recorder I see as a golden opportunity.
Then you can give the TeensyBat to a friend - he only needs to turn it on, press the button for 3 seconds and put the device down in the garden.
If you meet him during the day you can also hand over with activate Auto-Recorder in DeepSleep mode. Even easier, but not always possible.

regards, Georg
 
Hi,

If I am not wrong going to autorecord in the current setup is a matter of rotating the left-encoder to autorecord and press the left-encoder. Thats not a very complicated procedure ...

Cor
 
I also handed out my detector in deepsleep to a colleague. He only needed to bring it home and place it in a dry spot outdoors. He did find some droppings he was puzzled about, it turned out he has a family of common pips under the rooftiles from time to time. With a big battery you can tecord several nights.

I guess the long press options could be placed on the wishlist of future versions. We all know most whishes do not come true but if there is nothing in its way, it is worth to look at it I guess.
 
Last week I received Thorstens (dl9sec) perfectly soldered detector. I tested every Teensy pin against the V-bat input with both the Teensy in place and the Teensy removed but I could not find any strange leaks but could not find anything wrong. (I had a second detector to compare against).

Than I tested the SD card in another detector, and found that sometimes no SD appeared also on that detector so there is not something related to the hardware Thorsten was using. One of my Kingston and Sandisk cards in Thorstens detector did not bring up the "no SD" message which points to the Sandisk SD card Thorsten was using.

I tried Thorstens card on the computer an tested it with speedout and found it is not fast enough during writing to match up with the class10 standard. Speedout seems to hang sometimes during the writing process for short periods of time and has different results each time I run the test. I also used H2testw to check ith the 16GB card actually holds 16GB and the card does seem to be a true 16GB. After a slow format of the sd card using sd formatter speedout still had different results.

For some strange reason the card seems to work most of the times and I used it on one of my own detectors the last two nights. It appeared to work fine but a few recordings have some strange artefacts. I have the feeling this sd card can not be trusted.

The fact that it did not seem to work only when the backup coin cell was in place still puzzels me. Maybe there is some difference in timing during the boot sequence and reading the real time clock and accessing the card but I can not understand why that happens. I do not know if the card in place detection is just the card-contact or also involves some data communication. The standard SD library is used.

Anyway, the problems encountered seem to be related to the microSD-card.

Maybe someone knows what card detect does and if there could en any relation to reading the real time clock or simply start the clock from 00:00, I am quite sure it is not a problem in the hardware although the ultimate test for this would be to remove the v-bat pin from the main board and connect the backup battery + directly to the vbat pin of the Teensy without routing anything through the main board.

Kind regards,

Edwin
 
Hi Edwin,

This looks as if the card used is not a class10 card but could be a counterfeit SD card. They can still have the full 16Gb capacity but read/write speeds of those cards often is far lower than normal.

cheers
Cor
 
Hi All,

As the bat-season in the N-hemisphere is slowly wrapping up I encourage users of our hard/software to share ideas and issues that have not been reported thusfar. That way we (Edwin and I) can try to see if we can solve those for the next season.

cheers
Cor
 
Hello everyone,

Firstly a big thank you to everyone, especially Cor and Edwin for the great project.
The BatRecorder works perfectly and has many impressive features.

The following points are a nice-to-have.
They would simplify or expand my personal workflow. But they might also be useful and valuable for other users.

1) As described above - long press a button to start AutoRec

2) Playback - here a big praise from my side. It is very impressive how quickly and clearly the information is displayed.
I like to scroll through the recordings after a night out and look at the various frequency spectra. They are beautifully displayed at the top of the screen.
I then look at the recording for certain frequency spectrums.
Two additional features are useful here.
Clear the screen before starting playback. To hide the calls of other recordings or live display.
Also helpful if you want to show the recordings to someone and then only the calls of the respective recording are displayed. Or making a screenshot and be sure only the calls from this recoring is displayed.
Sometimes I do the screening visually without headphones. It would be useful here if you could set the standard playback speed/mode. Or possibly an additional one where only the main screen is filled as quickly as possible. So 10x instead of 1/10.
This would also allow you to quickly find special sequences with certain calls in the centre of the recording, e.g. Feeding Buzz, and then play them to anyone else.
That would be a great help during bat walks and field use.
 
Hi OE5GHO,

Thanks for the feedback. Thusfar you are the first adding a more detailed request good to see that you took the time and also
explain the motivation behind your requests.

As stated earlier - for the longpress to start autorec - we will have to think this through as we allready use longpress for other features. Longpressing the rotating buttons (encoders) would be an option but I dont "trust" their response as much as from the
real buttons. So this is "if its possible and does not break other options".

Clear the screen before playback will become "clear the screen at the start of playback". Thats no problem to implement.

Fast replay is more or less scanning the original data without translating them to audible and I even wonder if the system can do that fast readout of data from the file. Be aware that these are data-dense files at samplerates often >192K/second. Dont think this is going to happen fast. Replay at 1x should be possible but you will not hear anything. Again this will demand a good look at if/where this fits into the current code-set.

cheers
Cor
 
Hi,

I am about to start updating the code to create V1_7. Currently on the wishlist are:
- optionally add a prefix to each recording to recognize individual TB-machines
- restore last recorded GPS position in deepsleep to allow recording without GPS active
- allow autorecord duration to be set in seconds
- easy playback of the last recording (one-press)
- longpress to start autorecord directly
- clear screen before playback

I cannot guarantee that all of these will be possible but most of these requests seem to be "not too complex".
If you have anything important to add to this please share that.

cheers
Cor
 
Last year we worked on a clearer visual overview of the functions of the buttons on the Teensybat but never shared that. I have attached the V1_6 version for reference.
 

Attachments

  • basic_functionsV1_6.png
    basic_functionsV1_6.png
    349.8 KB · Views: 79
Hello
After I built and tested the second TeensyBat, I would be happy if the following function could be added. Recognition of the bat species If this is too complicated, perhaps a database of bat species could be stored. Similar to the Android app “BatLib” with images of the bat species and the most important data such as frequency and wingspan. Thank you for the great project
 
Back
Top