Bat detector

Hi,

That makes it difficult to debug your problem as the HEX from Edwin have no DEBUG enabled. Which GPS module are you using ?
Cor
 
It sure is strange that the GPS is not detected.

During switch-on the GPS unit has to be on for it to be detected. Since the GPS consumes a lot of power it has its own power switch.
If for some reason it has worked before it possible time is stored and kept active in the real time clock powered by the Cr2032 coincell.

If you have the gps power switch on and turn on the TeensyBat detector it should show a GPS connected after one second of testing if the GPS is present.

If the led on the GPS is flashing the power supply beshould be fine so there might be just a problem on the G PoS data lines like a bad solder joint.

kind regards,
Edwin
 
Yes, the blue LED of the GPS is flashing. I use the Baitian BN 220
GPS is not recognised at start-up! I will have another look at the two I2C pins and re-solder them if necessary!

Jürgen
 
Yes, the blue LED of the GPS is flashing. I use the Baitian BN 220
GPS is not recognised at start-up! I will have another look at the two I2C pins and re-solder them if necessary!

Jürgen

The GPS on the T4.1 uses the TX/RX from serialpin 0,1 not I2C. The software polls the GPS at different baudrates to see where it is active, when communication is activated it sets the baud
rate to 115200.

cheers
Cor
 
The wiring order on the teensy mainboard and beitian are the same so the wire next to the red wire on the beitian is also next to the red on the mainboard.
Keep the same order (but check where + and - go)

Edwin
 
Hi Edwin,

Everything is in order, GPS is recognised!
The cause was a cold solder joint!
Thanks to Cor and Edwin

kind regards,
Jürgen
 
I have found an error in the GPS date, it shows one day more.
Here is a picture from yesterday.

20220302_115859a.jpg
 
Hey that is a strange one, the realtime clock was running fine but when I got a GPS fix mine also showed march 4.......
 
Hi,

The code for this is rather simple. My guess is that the daylight savings correction isnt working as planned, what happens if you turn that off ?

Cor
 
This has nothing to do with the daylight saving correction. The GPS date is not correct in the display!

Kind regards,

Jürgen
 
It kind of looks like a leap year issue which might have its origin in the sparkfun gnss library or something like that. It requires a bit more investigating. Last weekend we had a group-build of detectors in Belgium and we did not notice this issue, now early March the error suddenly appears.

Edwin
 
This has nothing to do with the daylight saving correction. The GPS date is not correct in the display!

Kind regards,

Jürgen

Hi Jurgen,

The display of the date is constructed by reading out the datetime information from the GPS and then recalculating that to UNIX-time (seconds since 1st jan 1970) to allow the teensy timers to directly use that info. But in that calculation we also adjust for DST and as Edwin stated this weekend this problem was not there. But we are going to see what goes wrong in the code,

Cor
 
Hi Jurgen,

The display of the date is constructed by reading out the datetime information from the GPS and then recalculating that to UNIX-time (seconds since 1st jan 1970) to allow the teensy timers to directly use that info. But in that calculation we also adjust for DST and as Edwin stated this weekend this problem was not there. But we are going to see what goes wrong in the code,

Cor

We are using a sparkfun library and it seems there is an issue with that library:
see https://github.com/sparkfun/SparkFun_u-blox_GNSS_Arduino_Library/issues/125
 
Hi Cor,

Is it possible to change the location display in the GPS menu, for example to: hddd° mm′ ss.ss″ ?
It would then be easier to display the position on Google Earth.

Kind regards,
Jürgen
 
Hi Cor,

Is it possible to change the location display in the GPS menu, for example to: hddd° mm′ ss.ss″ ?
It would then be easier to display the position on Google Earth.

Kind regards,
Jürgen
Hi,

I guess you mean the displayed position when you are in the GPS menu. That would be possible but I do not see any benefit in this and for instance in google maps this is also not necessary. In the searchbar of Google Maps you can simply type in the digital degrees for latitude and longitude and it will go to that location.
Also in our recordings we store the location in digital degrees to allow using of specialized software to have access to the location.

But I will keep this in mind when we are working on the code (not any time soon I think) as a request, I hope you chime in the moment we are announcing a call for "bugs" "requests".

cheers
Cor
 
I put up the latest hex files that should not have this leap-year error on my website.

I also already sent a file to Jürgen but I was not sure my fix was the right one. The info Cor shared seems to be the exact same solution so I simply put up some newly generated files on my website. This only apply's to people using GPS, so the none-GPS users do not need to bother loading new software.

Maybe you could also try the files from the website Jürgen, I generated these this morning after I had some updates on VSC and PIO. It would be nice if you could als help test these. As far as I can see thing work fine.

About the GPS coordinates, they should work fine in Google but there are also used in de Guano metadata. Programs supporting Guano also give the right position based on this.

Edwin
 
Hi,

I guess you mean the displayed position when you are in the GPS menu. That would be possible but I do not see any benefit in this and for instance in google maps this is also not necessary. In the searchbar of Google Maps you can simply type in the digital degrees for latitude and longitude and it will go to that location.
Also in our recordings we store the location in digital degrees to allow using of specialized software to have access to the location.

But I will keep this in mind when we are working on the code (not any time soon I think) as a request, I hope you chime in the moment we are announcing a call for "bugs" "requests".

cheers
Cor

Hello Cor,

No problem, it was just a thought of mine.

Kind regards,
Jürgen
 
Edwin,

the bugfix works perfect! Here is my picture from today. Unfortunately, the bats don't fly yet because it's still too cold.
At the moment I am using the training files from your website to get to know the device better.
The sensitivity to the Batdetector 3,6 is already phenomenal!

20220305_121954a.jpg

Kind regards,

Jürgen
 
Last edited:
Edwin,

the bugfix works perfect! Here is my picture from today. Unfortunately, the bats don't fly yet because it's still too cold.
At the moment I am using the training files from your website to get to know the device better.
The sensitivity to the Batdetector 3,6 is already phenomenal!

View attachment 27745

Kind regards,

Jürgen

Be aware that is is a temporary FIX ... Ive just tested the code with a simulationand see that from 1st jan 2023 this will again lead to problems. But we will create a more permanent solution before that time.
 
TeensyBat GPS code updated

HI

Several files for the current development version (1.3) have been updated. As signalled by Josh911/Jurgen(THANKS !) the sparkfun library to use UBLOX with the GPS-module had a flaw that calculated 2022 as a leapyear. Sparkfun have not released a definitive commit for their library but a proposal is in place and we (Edwin) tested this and that seems to work as planned. This should keep this part of the code working as planned until the year 2100.

This means we have changes in two files:
in the src directory : bat_gps.h
https://github.com/CorBer/teensy_batdetector/blob/master/version1_3development/src/bat_gps.h
in the lib/SparkFun_u-blox_GNSS/src directory:
https://github.com/CorBer/teensy_ba...SS/src/SparkFun_u-blox_GNSS_Arduino_Library.h

This is only valid for those that compile code for the teensybat with a GPS module installed.

cheers
Cor
 
Thank for the information Cor, corrected files are on my website for both Teensy 3.6 and 4.1 based detectors. The Teensy 4.1 files are compiled with PSRAM option and four variants are available although only the GPS variants need to be updated, I generated all four versions.

For bugs and requests.

I do see a 0d FIX many times when SIV indicates several satellites. On the bottom of the GPS_STATUS screens I still see fix 3d. I also had the indicator showing the red droplet with a white x when I still had fix 3d in the bottom screen but I was unable to recreate that. I hope someone else had the same issue and was able to recreate it.

For requests a battery indicator on the display to show LIPO charge status.

A feature requested by others is a USB file transfer option although pulling the SD card and putting it into the slot of a computer/USB cardreader probably works much faster. Pulling out the micro-SD is a bit tricky and the question for USB filetransfer came back several times.


I hope some people can confirm the wish for these features, or have more and even better ideas.
(or good reasons why not to invest time in some requests)


Tonight the bats are out.... We had a nice day and a warm start of the evening Nathusii and common pips as wel as well as a noctula have been spotted on the detector several times.

Edwin
 
Thank for the information Cor, corrected files are on my website for both Teensy 3.6 and 4.1 based detectors. The Teensy 4.1 files are compiled with PSRAM option and four variants are available although only the GPS variants need to be updated, I generated all four versions.

For bugs and requests.

I do see a 0d FIX many times when SIV indicates several satellites. On the bottom of the GPS_STATUS screens I still see fix 3d. I also had the indicator showing the red droplet with a white x when I still had fix 3d in the bottom screen but I was unable to recreate that. I hope someone else had the same issue and was able to recreate it.

For requests a battery indicator on the display to show LIPO charge status.

A feature requested by others is a USB file transfer option although pulling the SD card and putting it into the slot of a computer/USB cardreader probably works much faster. Pulling out the micro-SD is a bit tricky and the question for USB filetransfer came back several times.


I hope some people can confirm the wish for these features, or have more and even better ideas.
(or good reasons why not to invest time in some requests)


Tonight the bats are out.... We had a nice day and a warm start of the evening Nathusii and common pips as wel as well as a noctula have been spotted on the detector several times.

Edwin

The easy USB-file transfer is a longtime request for me to. Unfortunately it seems to be less trivial, last year I did follow the progress on this forum on that topic and saw that the developers
were making progress but it was not something that was ready/easy/stable yet. Havent checked that thread for some time ...

Your request for the LIPO charge status is only valid for the most recent batch of T4.1 based Teensybats, I will need to build mine first to be able to test this. It should be simple as the charger chip you used uses I2C to communicate. It would be a good enhancement I think.

The 0d Fix should be investigated further probably. Maybe you can check the debug output when that happens ? Otherwise its rather difficult to guess where the problem sits. The FIX is a direct readout from the module so it should be "true".

Have heard any bats overhere yet but it sure feels like springtime with temps above 15 degrees C.

cheers
Cor
 
Back
Top