[Feature Request]: NodeDB: Add Direct-Link RSSI Field

[FFAMax]

Platform

Cross-Platform

Description

This feature request proposes extending the Meshtastic NodeDB schema with an optional RSSI field that captures received signal strength for nodes observed via direct (single-hop) reception. The field is populated only when a packet is received directly from a node and remains unset otherwise. The goal is to improve routing and forwarding decisions by incorporating direct-link reliability information in addition to SNR.

Current routing heuristics primarily rely on SNR, which is insufficient to distinguish between directly reachable nodes and those reachable only via multi-hop relays. This limitation reduces the accuracy of delivery probability estimation and complicates correlation with physical distance.

RSSI measured on direct receptions provides complementary information:

• Higher correlation with link margin and path loss
• Better discrimination of single-hop vs. multi-hop visibility
• Improved estimation of direct delivery probability

The field SHALL be updated only upon direct packet reception from the node.
The field SHALL remain unset (null/invalid) if no direct reception has occurred.
Multi-hop forwarded packets SHALL NOT update this field.

Expected Benefits

• Enables routing decisions based on both SNR and direct-link RSSI
• Improves prioritization of nodes with high probability of direct delivery
• Facilitates better distance estimation when combined with SNR and frequency
• Provides a clearer separation between topology visibility and physical link quality

Backward Compatibility

• The proposed field is optional and does not affect existing NodeDB consumers
• Nodes and clients unaware of the field can safely ignore it

Disclaimer and Discussion Notes

This proposal explicitly acknowledges the absence of protection against malicious or misbehaving intermediate routers that may falsify hopStart / hopLimit values. As a result, NodeDB MAY contain partially incorrect topology information. At the current stage, this threat model is accepted, and no mitigation is proposed.

Additionally, this opens a discussion on extending the proposed field with lightweight statistical indicators. Specifically, two counters MAY be beneficial:

• A counter tracking packets received via relay
• A counter tracking packets received directly

For statically deployed nodes with stable line-of-sight connectivity, the relay-received counter would tend toward zero, while the direct-reception counter would monotonically increase. This provides a robust, time-aggregated signal of direct visibility and delivery probability, independent of instantaneous channel conditions.

However, this requires refinement of incoming message handling logic. In particular, cases exist where a packet is received directly but rejected due to CRC errors, followed shortly by successful reception of the same information via a relay. Such events can arise from transient interference or collisions rather than weak signal strength. Blindly classifying these as relay-only receptions would bias statistics.

One possible approach is to introduce limited inspection of CRC-failed frames. If a corrupted frame is received directly and can be heuristically matched to a subsequently relayed packet (e.g., same node identity and similar payload structure), the system MAY treat this as evidence of direct reception for link-quality purposes, while still accepting node information from the relayed packet.

In such ambiguous cases, neither the direct nor relay counters should be incremented. Instead, a third counter MAY be introduced to track disputed or ambiguous receptions. For well-connected direct links, this counter would remain near zero, providing an additional discriminator when selecting peers for packet forwarding based on direct visibility rather than nominal reachability.

These mechanisms aim to preserve node information availability while avoiding systematic distortion of link statistics under interference-dominated conditions.