Further to https://github.com/meshtastic/firmware/pull/7897 ,
there was another log line that was triggering indiscriminantly on
GPS_INTERVAL_THRESHOLD .
Rather than logging a bad time 4000 times, let's just log one good time
when it is set.
In 2.7.7 / 2.7.8 we introduced some new checks for time accuracy.
In combination, these result in a spamming of the logs when a bad time is found
When the GPS is active, we're calling the GPS thread every 0.2secs.
So this log could be printed 4,500 times in a no-lock scenario :)
Reserve this experience for developers using GPS_DEBUG.
Fixes https://github.com/meshtastic/firmware/issues/7896
* Fix excluded modules configuration handling
- Add excluded_modules flags in getDeviceMetadata() for MQTT, PAXCOUNTER, STOREFORWARD, RANGETEST, NEIGHBORINFO
- Add conditional compilation guards in AdminModule for RANGETEST, AUDIO, PAXCOUNTER, STOREFORWARD, EXTNOTIF, DETECTIONSENSOR, AMBIENTLIGHTING
- Add skip logic in PhoneAPI for excluded modules during config enumeration
- Add conditional has_* flags in NodeDB only for included modules
Fixes issue where excluded modules still appeared in client applications and sometimes caused PAYLOADVARIANT_NOT_SET errors.
* Fix excluded modules issues and refactor code
- Restore original PAXCOUNTER logic: only exclude on non-ESP32 platforms due to memory constraints
- Fix has_store_forward flag to be conditionally compiled based on MESHTASTIC_EXCLUDE_STOREFORWARD
- Refactor PhoneAPI module config skipping logic to use helper function skipExcludedModuleConfig()
- Reduce code duplication in PhoneAPI by extracting common skip logic
This addresses the three issues identified in the code review:
1. PAXCOUNTER memory impact on non-ESP32 devices
2. Unconditional has_store_forward flag setting
3. Duplicated state management logic across multiple #else blocks
* Fix ambient lighting module exclusion in PhoneAPI and AdminModule
- Add conditional compilation guards for ambient lighting in PhoneAPI.cpp
- Replace old HAS_RGB_LED logic with MESHTASTIC_EXCLUDE_AMBIENTLIGHTING check in AdminModule.cpp
- Ensure ambient lighting module is properly excluded when MESHTASTIC_EXCLUDE_AMBIENTLIGHTING=1
* Phone GPS display on Position Screen
This is a PR to show when a phone shares GPS location with the node so you can reliably know what coordinate is being shared with the Mesh.
* Account for low resolution wide screen OLEDs
* Allow picking of Device Role and new Display Formatter for Device Role
* Add remainder of client roles to display formatter
* Don't update the role unless you pick a value
* Mascots are fun
* Fix warnings during compile time
* Improve some menus
* Mascots need to work everywhere
* Update Chirpy image
* Fix Trunk
* Update protobufs
* Add date to Clock screen
* Analog clocks love dates too
* Finalize date moves for analog clock
* Add a new GPS model CM121.
* Add CM121 to Unicore.
* Trunk fixes, remove unneded NMEA lines
---------
Co-authored-by: Tom Fifield <tom@tomfifield.net>
Adding a counter to show the last time a GPS coordinate was detected to ensure the user is aware how long since the coordinate updated or to identify any errors.
* Start portduino_config refactor
* refactor GPIOs to new portduino_config
* More portduino_config work
* More conversion to portduino_config
* Finish portduino_config transition
* trunk
* yaml output work
* Simplify the GPIO config
* Trunk
* Show ExternalNotification as excluded if it is
* Enable ExternalNotification, SerialModule and RangeTest on STM32WL
* Misc fixes for #7797 - ARCH_STM32 -> ARCH_STM32WL, use less flash by dropping weather station support for serialmodule, set tx/rx pins before begin
* Enable Serial1 on RAK3172, make SerialModule use it (console is on LPUART1)
* Fix SerialModule on RAK3172, fix board definition of RAK3172 to include the right pin mapping.
* Show ExternalNotification as excluded if it is
* Enable ExternalNotification, SerialModule and RangeTest on STM32WL
* Misc fixes for #7797 - ARCH_STM32 -> ARCH_STM32WL, use less flash by dropping weather station support for serialmodule, set tx/rx pins before begin
* Enable Serial1 on RAK3172, make SerialModule use it (console is on LPUART1)
* Fix SerialModule on RAK3172, fix board definition of RAK3172 to include the right pin mapping.
* Fix GPS that hard code 2080 as the start time.
Some GPS chips, such as the AG3335 in T1000e and L96 have a hardcoded
time of 2080-01-05 when they start up.
To fix that in a way that seems permanent, let's ignore times that
are more than 40 years since the firmware was built. We should followup
in late 2039 to see if any changes are needed.
Reported-By: @b8b8
* Update src/gps/RTC.cpp
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Put FORTY_YEARS in header and use in both places.
* Restore Ben's nicer log lines.
---------
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Fix GPS that hard code 2080 as the start time.
Some GPS chips, such as the AG3335 in T1000e and L96 have a hardcoded
time of 2080-01-05 when they start up.
To fix that in a way that seems permanent, let's ignore times that
are more than 40 years since the firmware was built. We should followup
in late 2039 to see if any changes are needed.
Reported-By: @b8b8
* Update src/gps/RTC.cpp
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Put FORTY_YEARS in header and use in both places.
* Restore Ben's nicer log lines.
---------
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Hold for >20s after GPS lock
GPS chips are designed to stay locked for a while to download some data and save it.
This data is important for speeding up future locks, and making them higher quality.
Our present configuration could make every lock perform similar to first lock.
This patch sets a hold of between 20s and 10% of the lock search time after lock
is acquired. This should allow the GPS to finish its work before we turn it off.
Fixes https://github.com/meshtastic/firmware/issues/7466
* Remove T1000E-specific GPS holds
The new code does the same thing, for all devices.
* Fix publishing settings
* Cleanups, removing unused variables.
* ifdef log line with GPS_DEBUG
* fixQual is not a bool.
* Hold for >20s after GPS lock
GPS chips are designed to stay locked for a while to download some data and save it.
This data is important for speeding up future locks, and making them higher quality.
Our present configuration could make every lock perform similar to first lock.
This patch sets a hold of between 20s and 10% of the lock search time after lock
is acquired. This should allow the GPS to finish its work before we turn it off.
Fixes https://github.com/meshtastic/firmware/issues/7466
* Remove T1000E-specific GPS holds
The new code does the same thing, for all devices.
* Fix publishing settings
* Cleanups, removing unused variables.
* ifdef log line with GPS_DEBUG
* fixQual is not a bool.
Further to https://github.com/meshtastic/firmware/pull/7772 ,
we discovered that some RTCs have hard-coded start times well in the
past.
This patch gives RTCs the same treatment as GPS - if the time is
earlier than BUILD_EPOCH, we don't use it.
Fixes#7771Fixes#7750
Further to https://github.com/meshtastic/firmware/pull/7772 ,
we discovered that some RTCs have hard-coded start times well in the
past.
This patch gives RTCs the same treatment as GPS - if the time is
earlier than BUILD_EPOCH, we don't use it.
Fixes#7771Fixes#7750
* Merge pull request #7777 from meshtastic/create-pull-request/bump-version
Bump release version
* Only send Neighbours if we have some to send. (#7493)
* Only send Neighbours if we have some to send.
The original intent of NeighborInfo was that when a NeighbourInfo
was sent all of the nodes that saw it would reply with NeighbourInfo.
So, NeighbourInfo was sent even if there were no hop-zero nodes in
the NodeDB.
Since 2023, when this was implemented, our understanding of running city-wide
meshes has improved substantially. We have taken steps to reduce the impact
of NeighborInfo over LoRa.
This change aligns with those ideas: we will now only send NeighborInfo
if we have some neighbors to contribute.
The impact of this change is that a node must first see another directly
connected node in another packet type before NeighborInfo is sent. This means
that a node with no neighbors is no longer able to trigger other nodes
to broadcast NeighborInfo. It will, however, receive the regular periodic
broadcast of NeighborInfo, and will be able to send NeighborInfo if it
has at least 1 neighbor.
* Include all the things
* AvOid memleak
* We don't gotTime if time is 2019. (#7772)
There are certain GPS chips that have a hard-coded time in firmware
that they will return before lock. We set our own hard-coded time,
BUILD_EPOCH, that should be newer and use the comparison to not set
a bad time.
In https://github.com/meshtastic/firmware/pull/7261 we introduced
the RTCSetResult and improved it in https://github.com/meshtastic/firmware/pull/7375 .
However, the original try-fix left logic in GPS.cpp that could
still result in broadcasting the bad time.
Further, as part of our fix we cleared the GPS buffer if we didn't
get a good time. The mesh was hurting at the time, so this was a reasonable
approach. However, given time tends to come in when we're trying to get
early lock, this had the potential side effect of throwing away valuable
information to get position lock.
This change reverses the clearBuffer and changes the logic so if time
is not set it will not be broadcast.
Fixes https://github.com/meshtastic/firmware/issues/7771
Fixes https://github.com/meshtastic/firmware/issues/7750
---------
Co-authored-by: Tom Fifield <tom@tomfifield.net>
* Add On-Screen Keyboard for UpDownInterrupt. Pls notice the new keyboard layout was inspired and adviced by https://github.com/csrutil
* Add longPress event for RotaryEncoder Press.
* Update UpdownInterrupt UP and DOWN on main UI.
* Change the interrupt trigger mode from rising edge to falling edge to improve button response.
There are certain GPS chips that have a hard-coded time in firmware
that they will return before lock. We set our own hard-coded time,
BUILD_EPOCH, that should be newer and use the comparison to not set
a bad time.
In https://github.com/meshtastic/firmware/pull/7261 we introduced
the RTCSetResult and improved it in https://github.com/meshtastic/firmware/pull/7375 .
However, the original try-fix left logic in GPS.cpp that could
still result in broadcasting the bad time.
Further, as part of our fix we cleared the GPS buffer if we didn't
get a good time. The mesh was hurting at the time, so this was a reasonable
approach. However, given time tends to come in when we're trying to get
early lock, this had the potential side effect of throwing away valuable
information to get position lock.
This change reverses the clearBuffer and changes the logic so if time
is not set it will not be broadcast.
Fixes https://github.com/meshtastic/firmware/issues/7771
Fixes https://github.com/meshtastic/firmware/issues/7750
There are certain GPS chips that have a hard-coded time in firmware
that they will return before lock. We set our own hard-coded time,
BUILD_EPOCH, that should be newer and use the comparison to not set
a bad time.
In https://github.com/meshtastic/firmware/pull/7261 we introduced
the RTCSetResult and improved it in https://github.com/meshtastic/firmware/pull/7375 .
However, the original try-fix left logic in GPS.cpp that could
still result in broadcasting the bad time.
Further, as part of our fix we cleared the GPS buffer if we didn't
get a good time. The mesh was hurting at the time, so this was a reasonable
approach. However, given time tends to come in when we're trying to get
early lock, this had the potential side effect of throwing away valuable
information to get position lock.
This change reverses the clearBuffer and changes the logic so if time
is not set it will not be broadcast.
Fixes https://github.com/meshtastic/firmware/issues/7771
Fixes https://github.com/meshtastic/firmware/issues/7750
* Only send Neighbours if we have some to send.
The original intent of NeighborInfo was that when a NeighbourInfo
was sent all of the nodes that saw it would reply with NeighbourInfo.
So, NeighbourInfo was sent even if there were no hop-zero nodes in
the NodeDB.
Since 2023, when this was implemented, our understanding of running city-wide
meshes has improved substantially. We have taken steps to reduce the impact
of NeighborInfo over LoRa.
This change aligns with those ideas: we will now only send NeighborInfo
if we have some neighbors to contribute.
The impact of this change is that a node must first see another directly
connected node in another packet type before NeighborInfo is sent. This means
that a node with no neighbors is no longer able to trigger other nodes
to broadcast NeighborInfo. It will, however, receive the regular periodic
broadcast of NeighborInfo, and will be able to send NeighborInfo if it
has at least 1 neighbor.
* Include all the things
* AvOid memleak
