Skip to content

Comments

Update README.md#2

Closed
m-a-x-s-e-e-l-i-g wants to merge 1 commit intomeshcore-dev:mainfrom
m-a-x-s-e-e-l-i-g:patch-1
Closed

Update README.md#2
m-a-x-s-e-e-l-i-g wants to merge 1 commit intomeshcore-dev:mainfrom
m-a-x-s-e-e-l-i-g:patch-1

Conversation

@m-a-x-s-e-e-l-i-g
Copy link

No description provided.

@ripplebiz ripplebiz closed this Jan 20, 2025
ripplebiz pushed a commit that referenced this pull request May 23, 2025
RAK4631 analogue user button on input 31
ripplebiz pushed a commit that referenced this pull request Aug 29, 2025
agessaman referenced this pull request in agessaman/MeshCore Nov 8, 2025
RAK4631 analogue user button on input 31
agessaman referenced this pull request in agessaman/MeshCore Nov 8, 2025
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
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants