* Add null check for p_encrypted before MQTT publish
A user on BayMesh observed a strange crash in MQTT::onSend that seemed to be a null pointer dereference of this value.
* Trunk
* Calculate hops correctly even when hop_start==0.
* Use the same type (int8_t) in the loop, avoiding signed/unsigned mismatches.
* Clarify defaultIfUnknown is returned for encrypted packets.
* fix on nrf52_promicro
* try fix for GPS issue
* fix GPS pin assignment in variant.h
* cleared up some comments and confirmed pinouts from schematics
---------
Co-authored-by: macvenez <macvenez@gmail.com>
* Client_Base - Dont rebroadcast in early (Router) window
Removed early rebroadcast check for CLIENT_BASE role.
* Client_Base - Clamp rebroadcast to late (Router_Late) window on dupe
* Only clamp to Router_Late window if packet from fav'd node
---------
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
* Be more judicious about sending want_response in existing meshes and responding to nodes we already heard from
* Turns out we don't actually use this
* Implement Long_Turbo preset
* Oops
* Start to DRY up menu handler by actually using OO concepts instead of jank separate arrays
* Move the implementation back into the method
* Dummy comment
* Listen to copilot feedback and prevent dangling pointer
* Static and optional
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
* Mark implicit ACK for MQTT as MQTT transport
* TRUNK
* Fix build
* Make sure implicit ACKs from MQTT do not stop retransmissions in ReliableRouter
---------
Co-authored-by: GUVWAF <78759985+GUVWAF@users.noreply.github.com>
* Mark implicit ACK for MQTT as MQTT transport
* TRUNK
* Fix build
* Make sure implicit ACKs from MQTT do not stop retransmissions in ReliableRouter
---------
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>