* Add sqlite to build requires
* Add missed comma
* Add sqlite dev to more dockerfiles
* Alpine docker fix
* Add sqlite to build requires
* Add sqlite depdendency (Cherry-picks from sfpp)
Store and Forward Plus Plus requires sqlite to work.
This PR cherry picks the commits that added the dependency so that
this can be added, and reduce the amount of effort to review sfpp.
Authored-By: @jp-bennett
---------
Co-authored-by: Jonathan Bennett <jbennett@incomsystems.biz>
KZ_863 was set to wide_lora = true. This was a mistake, induced because the
regulations would allow SHORT_TURBO. However, that interpretation of the code
was incorrect and wide_lora has a different meaning.
Fixes https://github.com/meshtastic/firmware/issues/9054
To assist with onboarding the denizens of the greater internet with
our norms and ways of working, this action will post a message on
PRs and issues from first-timers.
It turns out we had two methods for delaying startup while peripherals
warmed up. They were invented within months of each other and just missed
the chance to merge.
Let's delete PIN_PWR_DELAY_MS and use PERIPHERAL_WARMUP_MS, since it's
most common and earlier in the sequence.
We set the buffer size to about a byte on NRF52480, less than
other platforms:
esp32.ini: -DSERIAL_BUFFER_SIZE=4096
esp32c6.ini: -DSERIAL_BUFFER_SIZE=4096
nrf52.ini: -DSERIAL_BUFFER_SIZE=1024
However, 115200 baud, like the T1000e uses is about 12 times that
- almost 15 bytes per millisecond.
15 bytes * 200 millisecond (our GPS poll rate) = 3000 bytes, which is longer than our buffer
on the nrf52 platform. This causes "GPS Buffer full" errors on the T1000e
and other devices based on NRF52480 with newer GPS chips.
This patch increases SERIAL_BUFFER_SIZE for nrf52480 to 4096 to align with
other platforms. It keeps the original 1024 for the nrf52832, which has
fewer resources.
Fixes https://github.com/meshtastic/firmware/issues/5767
* Update exempt labels for stale bot workflow
Adds triaged and backlog to the list of exempt labels.
* Update meshtastic/web to v2.6.7 (#8381)
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
* Update DFRobot_RTU to v1.0.6 (#8387)
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
* Update mcr.microsoft.com/devcontainers/cpp Docker tag to v2 (#8375)
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
* manual merge stale bot config (#8392)
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Ham Mode ignores region regulatory limits, so regardless of whether
we set a single TX_GAIN_LORA or an array with a non-linear PA,
we shouldn't limit the power.
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
8 months ago, when this was added to the code, the GPS probe code
was still a little flaky.
Particularly after #6114 and #6116 were added, reliability improved
for all devices as we were sending fewer calls on the bus.
Today, the T1000E is the only Meshtastic device that regularly takes
2, 3, or 4 attempts to be detected via the probe code.
Removing these lines, on my T1000E, results in the AG3335 being
detected immediately.
Co-authored-by: Jonathan Bennett <jbennett@incomsystems.biz>
* Wait until after GPS lock hold before updating position, if we can.
After the recent patch, we hold lock for a bit before updating the position.
The positions that come in after the hold are genuinely better positions
than what we've been doing before. However, they only come 20 seconds
after we've got lock.
Previously, we would update the local position as soon as we got a lock as well
as at the end of the hold, since a hold was not always possible.
With this patch, if the settings allow, we should skip that first local position update.
Fixes https://github.com/meshtastic/firmware/issues/8029
* Fix falling edge handling.
* spelling
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Congeal lock handling
* Add named constants
* define unit to avoid confusion
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* ifdef, not if.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Add handling for when we first turn on.
* Don't run if not active
* Reset fixhold
* Logic fixes
* Add path for ACTIVE--> IDLE --> ACTIVE
Previously we only covered HARDSLEEP --> ACTIVE.
* Change hold time to gps_update_interval - 10s
* Update comment
* Add extra buffer to avoid re-starting hold
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
* Introduce non-linear TX_GAIN_LORA
Previously, our TX_GAIN_LORA setting was a single number, intended
to represent the signal gain going through a power amp (plus or minus
antenna, attenuator, and other parts of the RF chain).
It turns out the relationship between the input power (i.e. from an SX1262)
and total output power is often non-linear. While we fudged a 1dBm difference
here and there with existing chips, the Heltec v4 has a 5dBm difference in gain
depending on which end of the input power (and frequency) you are at.
To allow people to run their Heltec v4 at max power when legal, and future
proof our code, this patch introduced an optional array-based TX_GAIN_LORA.
Define NUM_PA_POINTS and set TX_GAIN_LORA to gain values for a given input
power in 1dBm increments, and all will work.
For linear systems, just continue to define TX_GAIN_LORA as a number.
Fixes https://github.com/meshtastic/firmware/issues/8070
* Remove temporary power limit on heltec v4
* Add function RadioLibInterface::checkOutputPower
* Ensure SX126x reaches minimum supported power.
* Keep it simple, instead.
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
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.
Meshtastic no longer fits on the flash of the Picomputer.
Since this is a handheld, portable device, it's unlikely that people are
connecting to it via the webserver. So, disable the webserver and it fits
again:
```
Checking size .pio/build/picomputer-s3-tft/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [=== ] 32.4% (used 106056 bytes from 327680 bytes)
Flash: [==========] 99.1% (used 3313913 bytes from 3342336 bytes)
```
Fixes: https://github.com/meshtastic/firmware/issues/7906
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 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.
* Upgrade trunk (#7763)
Co-authored-by: vidplace7 <1779290+vidplace7@users.noreply.github.com>
* Fix device-install.bat baud rate
As reported by @gruberaaron , work to improve the 1200bps reset for
esptool caused all runs of device-install.bat to use 1200bps as
the baud rate.
This change removes the general SET "ESPTOOL_BAUD=1200" that was causing
the issues and places the baud settings for reset mode inside the conditional.
Fixes https://github.com/meshtastic/firmware/issues/7172
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: vidplace7 <1779290+vidplace7@users.noreply.github.com>
As reported by @gruberaaron , work to improve the 1200bps reset for
esptool caused all runs of device-install.bat to use 1200bps as
the baud rate.
This change removes the general SET "ESPTOOL_BAUD=1200" that was causing
the issues and places the baud settings for reset mode inside the conditional.
Fixes https://github.com/meshtastic/firmware/issues/7172
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
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
We are currently blocked from making the breaking change to fix
EU_433 channel centres until 3.0 (https://github.com/meshtastic/firmware/issues/3371 )
However, as already updated in https://github.com/meshtastic/meshtastic/pull/919
the documentation, the power limit for EU_433 is 10dBm. We can change
the power limit without breaking anything, so this patch sets the
power limit to match the ETSI spec without changing any other settings.
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 .
Expertly triaged by @philon- , turning off wifi using the HTTP API
did not work. That was because we only served the HTTP API if Wifi
was deemed to be available, but mid-way through turning it off Wifi
was still available, but the configuration we were checking said it wasn't.
This patch introduces an additional way the system can determine if Wifi
is available, by referring to the WiFi.status(). This means that in that
limbo state where Wifi has been set to be turned off, but the configuration
has not been saved and it is still up, the HTTP API will stay up long enough
to save the configuration.
Fixes https://github.com/meshtastic/firmware/issues/6965
* Clear position on GPS deactivation, unless using fixed position
As reported by @dreimal8 , and confirmed by @tuxmobil , when using
and then subsequently disabling GPS the last position retrieved from
the GPS was stored and continued to be broadcast.
This change introduces a check to see if we are transitioning from
GPS Enabled to GPS Disabled or Not Present. If we are, and fixed
position is not in use, then we clear the local position.
This will prevent inaccurate and undesired position broadcasts for those
who disable their GPS.
Fixes https://github.com/meshtastic/firmware/issues/7228
* Update triple click to also clear position
---------
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
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
As reported by @KZ1R , Kazakhstan has frequencies in use for Lora devices that are not covered by our existing band selections.
This adds
* KZ_433 433.075 - 434.775 MHz <10 mW EIRP, Low Powered Devices (LPD)
* KZ_863 863 - 868 MHz <25 mW EIRP, 500kHz channels allowed, must not be used at airfields
Legal ref provided in https://github.com/meshtastic/firmware/issues/7204 and verified.
https://www.gov.kz/memleket/entities/mdai/press/article/details/6128
Order of the Ministry of Investments and Development of the Republic of Kazakhstan No. 34 dated January 21, 2015.
Published on 01 July 2024 19:03 Updated on 01 July 2024
Fixes https://github.com/meshtastic/firmware/issues/7204
* Add detection framework for multiple AirQuality sensors
Now we have the ability to detect multiple AirQualitySensors,
follow the lead of other sensor types and create supporting methods
and objects for using this information.
Continued cherry-picking to get #4601 over the line :)
Co-Authored-By: @Coloradohusky
* Update src/main.cpp
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Add detection code for SCD4X
This patch adds I2C detection support SCD40/SDC41 CO2 sensors.
It's a start to get #4601 over the line :)
Co-Authored-By: @Coloradohusky
* Remove SCD4X from Portduino
The Seeed Xiao NRF52840 Kit's default GPS is an L76K which operates
at 9600 baud, so when this variant was defined that baud rate was
specified.
However, this is a development board and it is expected that users
can attach their own devices. This includes GPS, which may operate
at a different baud rate. The current fixed baud rate prevents this,
so this patch removes that setting.
This will revert to the regular automatic probe method. This will
sucessfully detect the L76K as before (probably the same as before
since 9600 baud is the first baud rate checked), but also allow other
GPSes at other baud rates to be detected.
Fixes https://github.com/meshtastic/firmware/issues/7012
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
We don't have terraform, cloudformation, helm templates ... and this check pushes out new versions very frequently which is annoying with out automation :)
The Range Test Module was defined-out by architecture.
No reason it shouldn't work, so add PORTDUINO to the list of
architectures that compile this module.
Tested on Ubuntu. Enables without crashing, will send packets on
the set time. However, for now the CSV file download does not appear
to work.
Partially fixes https://github.com/meshtastic/firmware/issues/5618
* Add detection support for LTR390UV Sensor
The LTR390 is a UV sensor. This patch adds detection support, for
a future patch that will add the full sensor support.
* Update ScanI2C.h
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>
This patch takes a few LOG_INFO messages and turns them into
LOG_DEBUG. The logs appear to be mostly useful to developers, rather
than end users and as such placing them at INFO level is too high a
priority.
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
platformio/espressif32@6.9.0 --> 6.10.0
lewisxhe/XPowersLib@^0.2.6 --> 0.2.7
platformio/framework-arduinoststm32@~Oct 2024 --> 4.20900.0
zinggjm/GxEPD2@^1.4.9 --> 1.6.2
tool-esptoolpy@^1.40500.0 --> 1.40801.0
Used platformio tool to check, kept to minor version updates,
checked release notes for any breaking changes.
As reported by @jstockdale, when writing coloured logs we were
writing the full string, including a null terminator. This caused
issues for programs consuming our logs. The fix as identified is
not to write the null.
Fixes https://github.com/meshtastic/firmware/issues/5945
* [WIP] Attempt upgrade to LovyanGFX 1.1.16
This is the version most used by the TFT branch.
I wonder if this will work with our existing code? :)
* Update Portduino to LovyanGFX 1.20.0
Manuel says it's good to go.
* Update unPhone platformio.ini
---------
Co-authored-by: Manuel <71137295+mverch67@users.noreply.github.com>
* add more locking for shared SPI devices (#5595)
* add more locking for shared SPI devices
* call initSPI before the lock is used
* remove old one
* don't double lock
* Add missing unlock
* More missing unlocks
* Add locks to SafeFile, remove from `readcb`, introduce some LockGuards
* fix lock in setupSDCard()
* pull radiolib trunk with SPI-CS fixes
* change ContentHandler to Constructor type locks, where applicable
---------
Co-authored-by: mverch67 <manuel.verch@gmx.de>
Co-authored-by: GUVWAF <thijs@havinga.eu>
Co-authored-by: Manuel <71137295+mverch67@users.noreply.github.com>
* mesh-tab: lower I2C touch frequency
---------
Co-authored-by: Thomas Göttgens <tgoettgens@gmail.com>
Co-authored-by: mverch67 <manuel.verch@gmx.de>
Co-authored-by: GUVWAF <thijs@havinga.eu>
Co-authored-by: Manuel <71137295+mverch67@users.noreply.github.com>
MESHTASTIC_EXCLUDE_SOCKETAPI disables the API Server when set.
Co-authored-by: mverch67 <manuel.verch@gmx.de>
Co-authored-by: GUVWAF <thijs@havinga.eu>
* In graphics/Screen.cpp, a copy/paste error to do with hearts
* In mesh/http/ContentHandler.cpp, an unused variable
* in mqtt/MQTT.cpp, remove unneded logic " '!A || (A && B)' is equivalent to '!A || B'"
* update indicator board
* Fixed the issue that indicator device uploads via rp2040 serial port in some cases.
* esp debug logs
* USB mode=1 messed up the debug log
* dummy for config transfer (#5154)
---------
Co-authored-by: mverch67 <manuel.verch@gmx.de>
Co-authored-by: virgil <virgil.wang.cj@gmail.com>
Co-authored-by: Thomas Göttgens <tgoettgens@gmail.com>
Selection of minor edits from the TFT branch that are too
challenging to cherry-pick cleanly, including:
* introducing the HAS_TFT flag
* fixing pins in unphone
* Adding pinterdevice to portduino settings
HarukiToreda
