* Initial work to get NimbleBluetooth working reliably, and cross-task mutexes cleaned up
* Pre-fill toPhoneQueue when safe (during config/nodeinfo): runOnceToPhoneCanPreloadNextPacket
* Handle 0-byte responses breaking clients during initial config phases
* requestLowerPowerConnection
* PhoneAPI: onConfigStart and onConfigComplete callbacks for subclasses
* NimbleBluetooth: switch to high-throughput BLE mode during config, then lower-power BLE mode for steady-state
* Add some documentation to NimbleBluetooth.cpp
* make cppcheck happier
* Allow runOnceHandleToPhoneQueue to tell runOnce to shouldBreakAndRetryLater, so we don't busy-loop forever in runOnce
* Gating some logging behind DEBUG_NIMBLE_ON_READ_TIMING ifdef again; bump retry count
* Add check for connected state in NimBLE onRead()
---------
Co-authored-by: Jonathan Bennett <jbennett@incomsystems.biz>
* Add general-purpose packet cache
This commit adds a caching system that will save packet data in a much
more compact form than the regular MeshPacket protobuf. It cannot be
worked with directly to the same degree (although the packet header is
available), but consumes *much* less memory, and as a result can be used
to temporarily store large numbers of packets.
Cached packets can be retrieved either by their (from, id) tuple, or by
their hash.
This cache is a pre-requisite for the upcoming packet replay feature.
* Remove debug initialiser
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Fix ordering
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Add missing size assignment
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Add comments for hash & bucket macros
* Make it clear that this field stores a map of the original data
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Ben Meadors <benmmeadors@gmail.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>
* feat: add adaptive polling intervals to WebServer
Replace fixed 5ms polling with adaptive intervals based on HTTP activity:
- 50ms during active periods (first 5 seconds after request)
- 200ms during medium activity (5-30 seconds)
- 1000ms during idle periods (30+ seconds)
Reduces CPU usage significantly during idle periods while maintaining
responsiveness when handling HTTP requests.
* Fix integer overflow and magic numbers in WebServer
- Handle millis() overflow in getAdaptiveInterval()
- Replace magic numbers with named constants
- Improve code readability and maintainability
* Null out user.id except for sending to phone
* Fix
* Update src/modules/NodeInfoModule.cpp
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Copilot garbage
* This is unnecessary, because we don't stored user.id on userlite
* Don't need this
* Fix warning
* Just alter the protobuf
* Alter protobuf doesn't do anything with the altered data, so let's re-encode it
* Check inputbroker before access
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* RoutingModule::sendAckNak takes ackWantsAck arg to set want_ack on the ACK itself
* Use reliable delivery for traceroute requests (which will be copied to traceroute responses by setReplyTo)
* Update ReliableRouter::sniffReceived to use ReliableRouter::shouldSuccessAckWithWantAck
* Use isFromUs
* Update MockRoutingModule::sendAckNak to include ackWantsAck argument (currently ignored)
---------
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.
* Add seenRecently = true if wasUpgraded is true but unable to remove from queue (i.e. already sent/processed).
* Consistent comment between FloodingRouter and HopRouter
* Add seenRecently = true if wasUpgraded is true but unable to remove from queue (i.e. already sent/processed).
* Consistent comment between FloodingRouter and HopRouter
