Update hopsAway when packets are received #988
Conversation
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
|
@esev is attempting to deploy a commit to the Meshtastic Team on Vercel. A member of the Team first needs to authorize it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Description
Update the number of hops away for each node in the 'Connections' column of the node list table as new packets arrive.
Related Issues
Follows the logic from the firmware project: meshtastic/firmware#9120
Changes Made
hopsAwayfor a node is calculated each time a new packet is received. It is set based on the difference between the hop_start & hop_limit in the MeshPacket.Prior to firmware version v2.3.0 nodes did not provide a hop_start in packets. This meant that receiving a hop_start value of 0 could mean two different things; either the node was older and didn't supply a hop_start, or the transmitting node had LoRa number of hops set to 0. This PR uses the presence of the bitfield, added in v2.5.0, to distinguish between these two cases.
When hop_start=0 and the bitfield is present, we can trust that the transmitting node had LoRa number of hops set to 0. Otherwise the value for hopsAway is undefined.
Testing Done
Updated existing unit tests and verified the hops are calculated correctly by connecting to a bluetooth device.
Checklist
CONTRIBUTING_I18N_DEVELOPER_GUIDE.md for more details)