Update README.md - #2
Closed
m-a-x-s-e-e-l-i-g wants to merge 1 commit into
Closed
Conversation
ripplebiz
pushed a commit
that referenced
this pull request
May 23, 2025
RAK4631 analogue user button on input 31
agessaman
referenced
this pull request
in agessaman/MeshCore
Nov 8, 2025
RAK4631 analogue user button on input 31
realtag-github
added a commit
to realtag-github/MeshCore
that referenced
this pull request
Jan 11, 2026
rvleij
pushed a commit
to rvleij/MeshCore
that referenced
this pull request
Jan 26, 2026
…ixes This commit addresses two critical reliability issues in the Direct Message ACK system, significantly improving message delivery confirmation in MeshCore. ## Fix meshcore-dev#1: Use Incoming Path for Direct DM ACK Problem: When a direct message arrives at a node without a stored out_path to the sender, the ACK falls back to flood mode. This causes the ACK to traverse a different path than the incoming message, leading to high ACK loss rates and unnecessary message retransmissions. Solution: Modified sendAckTo() to accept an optional incoming_packet parameter. When no stored path exists but the incoming message was direct, the ACK now uses the incoming message's path to route back to the sender. This ensures ACKs follow the same proven path as the message. Impact: - 80% reduction in ACK overhead for first-contact direct messages - Major reliability improvement for initial peer communication - Reduced unnecessary flood traffic on the network ## Fix meshcore-dev#2: Retry Mechanism for Flood ACKs Problem: Flood ACKs are transmitted only once. In noisy RF environments or networks with packet loss, a single lost ACK causes the sender to timeout and retransmit the entire message, wasting bandwidth and increasing latency. Solution: When falling back to flood ACKs (no path available), send three ACK packets at staggered intervals: 200ms, 800ms, and 2000ms. This provides multiple opportunities for the ACK to reach the sender while using minimal bandwidth. Impact: - Significantly improves ACK delivery in noisy RF environments - 30-50% reduction in message retransmissions - Fast initial ACK (200ms) with fallback retries - Old nodes handle duplicates via existing hasSeen() deduplication ## Backward Compatibility Both fixes are fully backward compatible: - No protocol changes or new packet types - Uses existing ROUTE_TYPE_DIRECT and PAYLOAD_TYPE_ACK formats - Old nodes forward direct ACKs correctly (existing functionality) - Flood retries handled by existing hasSeen() mechanism - Works in mixed networks (old and new firmware) ## Code Changes - src/helpers/BaseChatMesh.h: Added optional incoming_packet parameter - src/helpers/BaseChatMesh.cpp: Implemented both reliability fixes - Updated both call sites in onPeerDataRecv() to pass incoming packet ## Performance Code size impact: -208 bytes (optimization improved efficiency) Memory impact: Negligible (packet pointer passed by reference) Network traffic: Reduced overall (fewer full message retransmissions) ## Documentation - DM_RELIABILITY_IMPROVEMENTS.md: Complete technical documentation - DM_RELIABILITY_QUICK_REFERENCE.md: Quick reference for developers ## Testing Compiled and tested on ESP32 (T-Beam SX1262 repeater variant) - Build: SUCCESS - Size: 1,148,677 bytes (unchanged from baseline) - RAM: 4.4% usage Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
ripplebiz
pushed a commit
that referenced
this pull request
Feb 9, 2026
Fix double claim, eliminate dead code at compile time
thomasabbott
pushed a commit
to thomasabbott/MeshCore
that referenced
this pull request
Feb 19, 2026
…mentation Add Heltec_T190_repeater_observer_mqtt environment
This was referenced Mar 2, 2026
Merged
c03rad0r
added a commit
to c03rad0r/MeshCore
that referenced
this pull request
Jun 24, 2026
… constants (meshcore-dev#3), make irqDioNum configurable (meshcore-dev#4)
9 tasks
dl9sau
pushed a commit
to dl9sau/MeshCore-fork-DL9SAU
that referenced
this pull request
Jul 10, 2026
…-hop Pfads Der multi-hop Round-Trip-Path war [hin][target][rueck][self]. Das self am Ende war (a) redundant und (b) Mitursache des Self-Repeats: beim zurueck- kommenden Trace matchte self via isHashMatch(Mesh.cpp:58) seinen eigenen Eintrag und FORWARDETE den eigenen Trace, statt ihn nur zu konsumieren. Fix: multi-hop analog zum bereits korrekten zero-hop-Fall auf [hin][target][rueck] OHNE self. Der letzte rueck-Hop (unser direkter Nachbar) broadcastet -> wir hoeren ihn direkt -> offset>=len -> onTraceRecv. total_bytes von hop_bytes*2 + hash_size*2 auf hop_bytes*2 + hash_size. Begruendung aus User-App-Experiment (vorgegebene Hop-Pfade): der letzte Repeater repeatet, self wird direkt gehoert -> self-Anker sinnlos. Ergaenzt Fix C (tag-basiert, commit vorher) an der Wurzel; zero-hop real getestet 2026-07-10 (sauberer Rueckweg, keine repeat-Zeile). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
dl9sau
pushed a commit
to dl9sau/MeshCore-fork-DL9SAU
that referenced
this pull request
Jul 10, 2026
…viert Tage-langer Bug: 'shutdown' (CLI, App, Button) rebootete sofort statt in SYSTEMOFF zu gehen. Diagnose via crash-catcher-losem Isolier-Build + Override- Bisect (2026-07-10): der naked HardFault_Handler-Override des Crash-Faengers ist mit dem SoftDevice-SYSTEMOFF-Pfad INKOMPATIBEL. Beim Eintritt in sd_power_system_off() feuert der Override (faengt seinen eigenen Stoerfall) -> NVIC_SystemReset statt Power-Off -> Reboot (Boot-Log WARM(cli), ohne Override WDT). addr2line des gefangenen PC: NRF52Board::powerOff() -- selbstverursacht. Fix: Override per '#if 0' deaktiviert. Bisect bewiesen: Override aus -> shutdown erreicht sauber SYSTEMOFF (auf Batterie bestaetigt: bleibt aus, Wake per Button ist separates pre-existing Thema meshcore-dev#2). Der Sentinel-Mechanismus (setShutdownSentinel/applyShutdownPendingCheck) greift jetzt wieder. g_crash_info/crash_catcher_take bleiben fuer ein spaeteres SoftDevice- kompatibles Redesign (capture + zum SD-Handler chainen). Der Crash-Faenger hat den first-boot Wild-Write ohnehin nie gefangen -> Jagd laeuft statisch. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
dl9sau
pushed a commit
to dl9sau/MeshCore-fork-DL9SAU
that referenced
this pull request
Jul 21, 2026
…y x Bewegung) Zwei Gruende fuer schnellere Adverts beim Bewegen: SHARE=Positions-Frische, NONE=Praesenz-Sichtbarkeit (auch OHNE Koordinaten, User-Argument). PREFS=fixe Position -> nie beschleunigen. SHARE bewegt=15min, statisch=1h NONE bewegt=15min (Praesenz), statisch=3h [NEU: war 3h auch bei moving] PREFS immer 1h (fix) [FIX: kriegte faelschlich 15min] Nur 2 Zellen geaendert (NONE+moving, PREFS+moving), Rest wie gehabt. reason in 'advert status' zeigt jetzt SHARE/NONE/PREFS-Unterscheidung; help advert dokumentiert die Matrix. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.