Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Currently we always claim GPS is available on TTGO boards #11

Closed
geeksville opened this issue Feb 29, 2020 · 3 comments
Closed

Currently we always claim GPS is available on TTGO boards #11

geeksville opened this issue Feb 29, 2020 · 3 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@geeksville
Copy link
Member

Based on a comment from @claesg that he got the TBEAM load working with this: https://www.banggood.com/LILYGO-TTGO-LORA32-868Mhz-SX1276-ESP32-Oled-Display-bluetooth-WIFI-Lora-Development-Module-Board-p-1248652.html?cur_warehouse=UK

We should probably change the way we set the flag in NodeDB.cpp:

    myNodeInfo.has_gps = true;

based on board type. But really, we should always set that flag based on "have we ever successfully talked to the GPS" - this should be done from GPS.cpp if the encode() routine ever returns true.

This would allow proper reporting of that flag to phones based on what we dynamically discovered to actually be connected on our board. This is important, because if the phone sees that flag as false, it assumes the local device doesn't have a GPS so the phone spends battery to periodically use the android GPS to send location data for the current node.

@geeksville geeksville added enhancement New feature or request good first issue Good for newcomers labels Feb 29, 2020
@claesg
Copy link
Contributor

claesg commented Mar 1, 2020

Well, I am using the Heltec build for the TTGO LORA32 board. I choose that one since it had no GPS and the pins had the same connections as my board.

@geeksville geeksville added this to the BeforeBeta milestone Mar 12, 2020
@girtsf
Copy link
Contributor

girtsf commented Mar 14, 2020

I'll poke at this today.

@geeksville
Copy link
Member Author

fixed in 64109b2

geeksville added a commit to geeksville/Meshtastic-esp32 that referenced this issue Mar 15, 2020
… Heltec...

devices.  It caused bogus i2c transactions when device would go to sleep.
Fixed now, also, I now treat GPS usage uniformly between TBEAM and HELTEC
we always probe for and use the GPS if we find it.

Which means for the extra nerds
(someone requested this, I'm sorry - I don't remember who) you can now
optionally attach an external GPS to HELTECs if you want.  The pins are:

 #define GPS_RX_PIN 34
 #define GPS_TX_PIN 12

(@girtsf, sorry about including formatting changes in this PR, apparently
I had my IDE set to not autoreformat until just now
geeksville added a commit to geeksville/Meshtastic-esp32 that referenced this issue Mar 15, 2020
… Heltec...

devices.  It caused bogus i2c transactions when device would go to sleep.
Fixed now, also, I now treat GPS usage uniformly between TBEAM and HELTEC
we always probe for and use the GPS if we find it.

Which means for the extra nerds
(someone requested this, I'm sorry - I don't remember who) you can now
optionally attach an external GPS to HELTECs if you want.  The pins are:

 #define GPS_RX_PIN 34
 #define GPS_TX_PIN 12

(@girtsf, sorry about including formatting changes in this PR, apparently
I had my IDE set to not autoreformat until just now
geeksville added a commit to geeksville/Meshtastic-esp32 that referenced this issue May 3, 2020
mc-hamster added a commit that referenced this issue Sep 29, 2020
Merge pull request #446 from mc-hamster/master
@GUVWAF GUVWAF mentioned this issue Apr 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants