Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add setting to transmit NeighborInfo over LoRa #5286

Merged
merged 2 commits into from
Nov 9, 2024

Conversation

GUVWAF
Copy link
Member

@GUVWAF GUVWAF commented Nov 8, 2024

As discussed in #5082 and meshtastic/protobufs#618.

When setting neighbor_info.transmit_over_lora to true (default to false), next to sending it to MQTT/PhoneAPI, it will also broadcast it over LoRa to be able to obtain it from remote nodes. This happens only when not using the default channel as primary, and the channel utilization allows it.

Furthermore, the absolute minimum you can set the NeighborInfo broadcast interval to is bumped to 14400 (4 hours).

@GUVWAF GUVWAF requested review from fifieldt and thebentern November 8, 2024 18:10
@fifieldt fifieldt merged commit 2c2213e into meshtastic:master Nov 9, 2024
48 checks passed
@macvenez
Copy link
Contributor

macvenez commented Nov 9, 2024

This happens only when not using the default channel as primary, and the channel utilization allows it.

Hi, does this mean that NeighborInfo data is only transmitted to the default channel if it's not primary? I don't know if there's still this limitation but I remember position data was sent only on primary channel, would this mean we'll have neighbor info on default channel but not position?

What's the purpose of this? Wouldn't this still generate the same traffic?
Thanks!

@GUVWAF
Copy link
Member Author

GUVWAF commented Nov 9, 2024

Hi @macvenez, indeed, periodic broadcasts only go out on the primary channel, so if that is the default channel, it won’t allow it. It was added upon request here meshtastic/protobufs#618.

When you have a private primary channel, it will automatically use a different frequency slot. When using EU_868 there is only one, so indeed then it would lead to the same channel utilization on the mesh.

@ragnarblackmane
Copy link

@GUVWAF

So:
-if a default channel (e.g. MediumFast), is primary: no NeighborInfo over LoRa (as per pull #5286);
-if a default channel (e.g. MediumFast), is secondary: no NeighborInfo over LoRA (normal behaviour since periodic broadcasts happen only on Primary channel);
-wherever can be used more than one frequency (e.g. USA): NeighborInfo traffic goes on another frequency (since a private primary channel is used);
-in EU (single slot): we'll have a bit less channel utilization because by effectively disabling NeighborInfo over LoRa on primary+default channel.

Am i right?

@GUVWAF
Copy link
Member Author

GUVWAF commented Nov 17, 2024

  • Yes, if also the default key is used.
  • Depends on what is your primary, but yes, no NeighborInfo goes out via a secondary channel.
  • Yes (unless you specifically change the frequency slot again).
  • Correct.

@noon92
Copy link
Contributor

noon92 commented Nov 18, 2024

That's a shame - on our mesh we use neighborinfo quite a bit on default channel.

@todd2982
Copy link

I need to verify this more, but it seems this feature broadcasts info about clients set with the "CLIENT_HIDDEN" preset to other nodes.

@fifieldt
Copy link
Contributor

Ah! that's no good!

@fifieldt
Copy link
Contributor

Nodeinfo defaults the broadcast interval for NodeInfo for HIDDEN nodes to UINT_MAX

667 moduleConfig.neighbor_info.update_interval = UINT32_MAX;

@fifieldt
Copy link
Contributor

How about this: #5464

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.

7 participants