TinyGPS Fix Quality has this information:
0 - fix not available,
1 - GPS fix,
2 - Differential GPS fix (values above 2 are 2.3 features)
3 = PPS fix
4 = Real Time Kinematic
5 = Float RTK
6 = estimated (dead reckoning)
7 = Manual input mode
8 = Simulation mode
the previous Airoha code would allow quality >0 , which includes
estimated positions. These wouldn't be passed through to the mesh
due to other checks, but would affect the Airoha GPS_FIX_HOLD_TIME
calculations.
Changes the calculation to 1 >= quality <=5 .
As determined by @b8b8 , enabling NAVIC meant the more modern L5 GPS
signal was not used (L1 GPS is always available).
NAVIC, India's GNSS, probably provides the best coverage in India and
the neighbouring region. However, outside of NAVIC's coverage area, L5
GPS is highly desirable.
This patch amends the AG3335-family GPS configuration to enable L5 GPS
coverage by default. If the Lora region is set to India or Nepal,
NAVIC will be enabled instead.
We have two perhapsSetRTC functions, which are called to set the time.
The one with 3 parameters had a helpful check to reject an invalid time,
by comparing the time from the source against when the firmware was compiled.
The one with 2 parameters, which is called from the GPS lookForTime did not.
As a result, certain GPS with bad time handling could set a time that was
in the past.
This patch adds the same epoch check code to the other perhapsSetRTC method.
Fixes https://github.com/meshtastic/firmware/issues/7364
* Enable GPS for Wio-E5 variant on Serial2
* Add ability to override GPS serial port using GPS_SERIAL_PORT, and make RAK2560 use it.
* Don't try to send ATAK packets if ATAK is disabled, +4k flash
* Update platformio inis for stm32 platform and wio-e5 variant for enabling i2c
* Don't reference timezone functions if MESHTASTIC_EXCLUDE_TZ is defined
* Use custom pow_of_two in RadioInterface instead of floating-point pow()
* First pass: enable sensors for STM32wL
* Fix AirQualityTelemetryModule being created if the PM25AQI header is missing
* Link in power sensor libraries
* more ini tweaks
* Add =1 to EXCLUDE defines, fix indentation.
* Drop HAS_WIRE in ini, it's defined in architecture.h
* Fix build when power sensor libraries are missing
Make MAX sensor integration into Power.cpp optional based on its library header existing.
Also make NullSensor expose a voltage and current sensor, because Power calls directly into these for INA sensors.
This lets us remove all the deps for the STM32WL platform.
* Change default I2C for RAK3172 to be I2C1, not I2C2
* Respect the laws of mathematics (oops)
In the GPS probe code we write commands on the serial line and
determine which GPS we have based on the result.
GPS units in the same family sometimes use the same command,
but return different results (eg AG3335 and AG3332 both use $PAIR021*39).
Currently we run the command once per GPS. Instead we should run each
command only once per family, record the result, and select the GNSS MODEL
based on the result, which is what this patch does.
Before the change, we put 12 commands on the serial bus.
Now we only put 6.
This should markedly improve the speed and reliability of GPS detection.
Fixes https://github.com/meshtastic/firmware/issues/5193
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
In 2020 there was a bad batch of tbeams whose ubloxen went a little
loopy. We factory reset them to bring them sane again.
It's now 2025, the problem with tbeam is long fixed, and this is not
necessary for any other devices we're aware of. Removing the function to
make our code more maintainable.
There is an associated protobuf entry did_gps_reset that we might be able
to re-purpose for something else, or remove in 3.0.
Last release a change introduced different branching functions in
gps.cpp based on the model of a device. This makes the code less
readable and introduces the potential for bugs.
This patch creates a new variable, GPS_PROBETRIES that can be set
in variant.h of devices that will control how many times we will
probe for GPS presence. It sets up the T1000-E to use this variable
and cleans the code in gps.c
* GPS.h cleanups round 3.
No effective behavior change.
Protected members can be private so make it so. (Supporting
subclasses needs a lot more work.)
Moves uBloxGnssModelInfo into file scope.
Moves uBloxProtocolVersion into uBloxGnssModelInfo.
Moves baud rate arrays into file scope.
Removes unused/ unimplemented powerStateToString.
Signed-off-by: Christopher Hoover <ch@murgatroid.com>
* Trunk Format.
---------
Signed-off-by: Christopher Hoover <ch@murgatroid.com>
Co-authored-by: Tom Fifield <tom@tomfifield.net>
* Move yet more stuff out of GPS.h and into file scope.
* Protect code macros from eating semicolons.
* Remove unused (and unimplemented) getDOPString.
* clang-format with project style file on affected files.
Signed-off-by: Christopher Hoover <ch@murgatroid.com>
https://github.com/meshtastic/firmware/pull/5160 introduced a change
which made first publication of GPS information take up to 15mins.
For that initial period, displays would show "No GPS Present", even
if one was detected.
This change fixes that bug, triggering publication immediately after
a GPS module is detected.
* Optimise GPS Baud Rate cycle
Previously, our baud rate cycled through one list twice.
There were some rarer baudrates in there, so this code
separates out those into a dedicated list that is only
run through if detection fails for common bauds. We also
only run through each baud rate once.
* Fix first time around bug
Would have always reset GPS baudrate every time.
* Add support for fixing GPS_BAUDRATE
If GPS_BAUDRATE is set in variant.h, the deployer knows something we
don't about the GPS. Used especially when the GPS is soldered to a board
in a commercial product :) If we see that, we don't try other baud rates
at all.
* Don't print blank lines in GPS_DEBUG.
* Try GPS_BAUDRATE first, not only.
* Fix spelling mistakes in comments
* Only use GPS_BAUDRATE if specified in variant.h
* Modify RareSerial Speeds based on FIXED or not.
* Update GPSUpdateScheduling.cpp
Default value is too short, resulting in unstable GPS locks on T1000-E (possibly others). Fix has been tested an confirmed working with no adverse effects, by multiple users. Also discussed at length on Discord
* Coerce minimum instead of hardcode
* config
---------
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
After the recent change to move logging line breaks to a central
location, GPS_DEBUG is now emitting one character per line,
making the logs unusable.
Patch uses local strings and appends to collate and then print
in the right places.
Fixes https://github.com/meshtastic/firmware/issues/5099
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
Triple Press on buttons toggles GPS enable/disable.
This enhancement plays a triple-beep so that users of devices with buzzers can get audible feedback about whether they have turned the GPS off or on. This is especially valuable for screenless devices such as the T1000E where it may not be immediately obvious the GPS has been disabled.
remove newline from logging statements in code. The LOG_* functions will now magically add it at the end.
---------
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
Recently there have been reports of intermittent difficulties
detecting U-Blox chips. This patch proposes a new approach that should
be more reliable.
Previously we were fighting with NMEA messages to try and send binary
commands. We unusually also tried changing the Baud rate of U-Blox
chips, something we don't do with any other GPS.
It turns out U-Blox has another method to disable NMEA
messages. PUBX,40 is a text-based command, supported on all the
U-Blox versions we care about that can set the rate of NMEA messages
to zero.
This is what we attempt to do with all other GPS and it works quite
well.
So this patch alters the probe code to:
1. Remove UBX binary code to stop NMEA messages
2. Remove code that tries to reset UBX chips to 9600 baud
3. Add UBX proprietary text commands messages to stop the NMEA flood
4. Improve log strings sent to the user.
Tested on Ublox 6, Ublox 9, and Ublox 10 on multiple devices.
Also tested on several devices with
non-Ublox GPS to ensure it does not interfere with their detection
(heltec-wireless-tracker, wio-tracker-wm11110)
@allanmac noted we were not enabling QZSS on the UC6580.
QZSS is an augmentation service that runs on the same frequency
as GPS, so turning it on should not have any impact on usage other
than improving performance for users in the Asia Pacific.
Fixes https://github.com/meshtastic/firmware/issues/5009