Node Packet Counter

[musznik]

I’ve implemented a packet counter column. This feature, while targeted towards advanced users, provides valuable statistical insights that can greatly enhance network analysis and optimization.

Benefits:

• Network Load Analysis: The packet counter helps identify nodes that heavily load the network, enabling users to diagnose and mitigate potential bottlenecks, trolls or badly configured nodes.
• Antenna Tuning: Users can evaluate the effectiveness of different antennas by analyzing packet counts, aiding in fine-tuning for optimal performance.
• Node Discovery: This feature is useful for locating distant nodes, which is critical in scenarios like search and rescue or in remote areas.
• Enhanced Functionality: Currently, users mainly rely on node observations, last activity times, or sending Traceroute pings. The packet counter adds another layer of functionality, enriching the experience for advanced users and providing them with more tools for network analysis.

Potential Drawbacks:

• Interface Complexity: Adding another column may add complexity to the UI, which could be overwhelming for less experienced users.

Overall, this enhancement offers significant benefits for users needing deeper network insights, and I believe it will be a valuable addition to the project. This is just a suggestion based on needs of my community.

[b8b8]

cool. when does it reset? every 24 hours or user configurable? This will be helpful to see which people are blasting away telemetry every 5min. This could also be put in or in addition to the upcoming data graphs and separated by data type.

[b8b8]

my only suggestion is to move it down to the "expanded" card area that was recently added.

[musznik]

Good points. Currently, the counter doesn’t reset automatically, but adding a reset feature makes sense. I’ll definitely consider implementing it, along with breaking down the statistics by data type.

[b8b8]

A rolling 1 hour may be a good start actually, not 24 hours. Its nice to see some of the mesh data being more accessible than just in the background and will really help with debugging and testing.

[garthvh]

Take a look at the local stats telemetry https://github.com/meshtastic/protobufs/blob/52cfa2c1c2cd5a1a714e1338d551d967f674fca8/meshtastic/telemetry.proto#L236

[thebentern]

Take a look at the local stats telemetry https://github.com/meshtastic/protobufs/blob/52cfa2c1c2cd5a1a714e1338d551d967f674fca8/meshtastic/telemetry.proto#L236

Yeah, please use this API because we have precedence here on the Apple apps. It has more raw data available from the device as well

[andrekir]

I would add that the node list really isn't the right place for a packet count. our NodeInfo data class simply mirrors the NodeInfo protobuf.

also avoid JSON in SharedPreference for persistence. and no need to add serialization-json lib as it's already being used (but hopefully removed soon).

Meshtastic-Android/app/build.gradle

Line 225 in 7b44fea

implementation "org.jetbrains.kotlinx:kotlinx-serialization-json:1.7.1"