mirror of
https://github.com/agessaman/meshcore-bot.git
synced 2026-08-14 14:40:00 +00:00
agessaman
c94a3f861e
Three adjustments from review. Role and device type are the same field twice. Measured on the live database they disagree on 16 of 11,028 contacts (ten roomservers and a handful of bots and gateways reporting device Companion); every other row is repeater/Repeater, companion/Companion, type11/Type11 and so on. Charting both filled half a card with a copy of the other half. Keep the role mix, which also carries the type0..type15 bucketing, and move it into the routing row where the old signal card was. Drop the tracked-contacts tile. is_currently_tracked does not describe anything a reader can act on, and node activity is already covered by nodes-heard and gone-quiet. The known-contacts total moves onto the coverage tile, which leaves five tiles splitting the row evenly. Rebuild the signal panel around zero-hop neighbours. Percentiles over every received message answered no question anyone has: SNR on a relayed packet measures the last hop into this radio, not the link to the node that sent it, so averaging across hop counts describes nothing in particular. The panel now shows the nodes heard with no repeater in between — how many, their SNR distribution, and the weakest links named, worst first, on a fixed -12..+14 dB scale so bars mean the same thing between refreshes. On the live database that is 307 neighbours, median 12.0 dB, with eight marginal links surfaced from -9.0 dB down. This also corrects the source. The plan rejected complete_contact_tracking.snr as a badly biased 7% sample; in fact it is populated on exactly the 800 hop_count=0 contacts and NULL on all 10,228 others. It is not a sample of the network, it is a complete census of the neighbours — which is precisely the population the metric applies to. message_stats.hops=0 covers only 34 senders by comparison.