Intermittent visibility of MeshChat RNode in NomadNet / RNSD despite good SNR

[Frozzen]

Hello,

I am observing intermittent visibility issues between MeshChat and NomadNet when using RNode interfaces.

Setup:

• Device A: MeshChat running with a single interface (RNode)

  • RNSD version: 1.0.2
  • Python: 3.11.13

• Device B: Debian system running rnsd with RNode and full network access

  • RNSD version: 1.0.4
  • Python: 3.13.5

Observed behavior:

• From the Mesh side, many nodes from the wider network are visible.

• NomadNet also sees the network correctly.

• However, the MeshChat RNode is only occasionally detected by NomadNet; most of the time it is not visible.

• At times, traffic does pass successfully, but then connectivity stops again without configuration changes.

• Latest signal report during a successful exchange:

  • Link: Direct
  • SNR: 11.75 dB

Additional notes:

• Devices are located in adjacent rooms.
• Version differences between RNSD and Python are minor.
• I attempted to use loramon, but it produces no output.

Question:
Is this behavior indicative of a configuration issue (RNSD, interface settings, announce intervals, or transport filtering), or is there a known issue with RNode discovery/announcements across these versions?

Any guidance on what to verify or adjust would be appreciated.

[markqvist]

If you're connected to a wide network with many announces coming in, and just have the RNode interface on that system in full mode, it will try to retransmit all announces to the RNode part of the network. Depending on you airtime limits and bitrates, this is likely to quickly consume all available bandwidth for management traffic, either by the default 2% announce bandwidth cap, or simply by your (potentially) configured airtime limits.

Unless you have ample bandwidth available on the LoRa side (ie., a fast channel config > 10kbps), the best way to set up something like this is to put the gateway RNode into ap mode. This will allow any clients on the LoRa network to requests paths as needed, and save a lot of bandwidth.

[Frozzen]

Very long discovery / synchronization time (≈3 hours) before communication is established — how to speed this up?

After approximately 3 hours of synchronization and announcing, communication between nodes is finally established.

While this eventually works, such a long convergence time makes the setup impractical for mobile or moving nodes.

Question

Is there any supported or recommended way to significantly reduce discovery and synchronization time?

If not, this behavior would make the system largely unusable for:

• Mobile nodes
• Intermittent connectivity
• Short-lived links

Context

• Communication eventually works, so configuration appears correct

• Delay is dominated by:

  • Announcing
  • Discovery
  • LXMF propagation / trust establishment

• Nodes are not static and cannot wait hours to converge

Questions for maintainers / experienced users

• Can trusted nodes / propagation nodes be preconfigured to avoid long auto-selection delays?
• Is this behavior expected on low-bandwidth links (e.g. LoRa / RNode)?
• Are there best practices for mobile or fast-changing topologies?
• Is there a known lower bound on convergence time for LXMF on LoRa?

Any guidance on reducing time-to-first-message would be very helpful.

[markqvist]

Did you read my previous message and actually try what I told you? You have something completely misconfigured.

Path resolution on a slow LoRa channel (~1 kbps) usually takes around 3-4 seconds, not hours.

[Frozzen]

Of course, I included mode=ap. Announcements from the network stopped coming. But overall the connection is unstable.

  [[rnode 433 local]]
    type = RNodeInterface
    enabled = yes
    mode = ap
    port = /dev/ttyACM0
    frequency = 433100000  # In Hz; use legal freq (e.g., 915000000 for US)
    bandwidth = 125000  # 125 kHz
    txpower = 14  # dBm; max depends on hardware/regs (T-Beam: up to 20)
    spreadingfactor = 8  # 3.12 kbps
    codingrate = 5  # 5-8
    id_callsign = TBEAM-433-1
    id_interval = 600  # Beacon every 10 min

[markqvist]

You probably have something misconfigured somewhere. We can't really help unless you post the full details of your configuration and setup.

Why does that RNode config look so weird? What's up with those random comments? Why did you add the id_callsign and id_interval directives? Are your configs LLM-generated?