[khagele]

Closes #479

Stacked on #483 (feat/481-trace-tag): the backoff needs to know whether a node answered, and that signal is the trace-tag attribution. Until #483 merges its commit shows in this diff; the change here is the second commit.

What the firmware will answer, and what we were asking for

Autoping sent one kind of probe to one part of what the radio hears: a Discover broadcast plus a trace-ping per selected target. A repeater we heard but had not selected got nothing beyond the broadcast.

probe	gate in firmware	answers per minute
trace-ping	none — Mesh::onRecvPacket (src/Mesh.cpp:41) forwards a DIRECT TRACE on a hash match, and a repeater's allowPacketForward only tests disable_fwd for a direct packet	unbounded
Discover	discover_limiter(4, 120) (examples/simple_repeater/MyMesh.cpp:867)	2.0
anon request (regions/owner/clock share one bucket)	anon_limiter(4, 180) (MyMesh.cpp:868)	1.33

The cheapest probe, and the only unmetered one, was the one we were not sending. Since #455 the retransmission it provokes is captured, and since #481 it is attributed — so a sweep is now measurements rather than anonymous dots.

What changes

• With a selection: nothing. Those targets and nothing else — airtime spent elsewhere is airtime not spent on the hunt.
• With no selection: the cycle rotates a batch of four over every repeater heard directly, taking turns so the whole set gets asked rather than the head of the list.
• The Discover broadcast keeps its cadence. It overruns any one repeater's bucket (12 per two minutes against four answers) and that is fine: a moving hunter keeps meeting nodes whose bucket is untouched, and one broadcast reaches all of them at once.
• A node that does not answer is demoted and backed off (0 / 30 s / 2 min / 10 min). Hearing it again resets that — in range is a property of where the hunter is now, not of the clock, and a repeater we drove back towards should not sit out an old backoff. Any traffic from it counts, not only its reply, which is the cheaper signal and just as good.

Two decisions worth naming

• Batch size four, and the ceiling is the send queue, not the duty cycle. The companion's queue is 16 slots and drops silently on overflow; STAGGER_MS (1.5 s) exists to drain it one packet per slot. Four pings is 6 s of a 10 s cycle, so the broadcast, the pings and their replies all fit and the queue is empty before the next tick. The issue said one per cycle; I raised it and updated the issue.
• Bookkeeping follows the frame, not the plan. The ask is recorded inside the send callback, only when sendTracePing reports the frame went out. Recording it at plan time meant a BLE drop between the tick and the staggered timer cost a node its place in the rotation for something that never left the phone.

What bounds this, since the duty cycle does not

Half-duplex: the radio cannot hear while it transmits. Four pings plus a broadcast is ~230 ms of transmission per 10 s cycle at SF7 (~46 ms per ~13-byte frame, the figure autoping.js already carries), so ~2.3% of listening time. That is the number to watch in the field, and it is the reason the batch is bounded at all.

What a sweep costs the node it asks

The 2.3% above is our own deaf time. The other side of it is not ours to spend: every ping makes a repeater transmit, on a path the firmware rate-limits not at all, and the cost per node rises as the area empties. @efiten's figures from the review:

repeaters heard	replies/min each	that node's airtime
2	12.0	0.92%
4	6.0	0.46%
6	4.0	0.31%
10	2.4	0.18%
Discover, for comparison	2.0	0.15%

In a two-repeater rural hunt each node is asked for six times what a Discover-limited exchange would cost it, and nothing in the firmware refuses.

The batch stays at four, and this is the sentence saying so on purpose rather than by omission:

• The sweep runs only with no target selected. Picking one stops it, so this is what the mapping mode costs, not the hunt.
• Four is what the companion's 16-slot send queue drains in a cycle. Scaling the batch to the set puts that ceiling and the per-node rate in tension on every tick, and the gain is a guess until a sweep is measured against a real repeater's own duty accounting.
• 0.92% is inside the 1% the band allows, but not by much, and it is a cost imposed on hardware we do not own.

What would change it: a repeater reporting its duty near the ceiling during a sweep, or two hunters sweeping the same pair, which doubles every figure above. Both are field observations rather than something this PR can settle.

Verification

• app/: 42 files, 737 tests green. web/: 378 vitest plus all 147 Playwright specs with --fail-on-flaky-tests. Build and eslint clean.
• Mutation-checked, each red for its own reason: the in-range signal removed (2 red), the backoff boundary moved (1), the promotion of answering nodes removed (1), the clamp on the last backoff step removed (1), the forwarding filter removed from heardRepeaterIds (3), the per-frame collapse removed (2).
• heardRepeaterIds shares its body with selectedRepeaterIds rather than restating it, so the sweep and the targeted path cannot disagree about what counts as a repeater or about collapsing ids that produce the byte-identical frame.

Changelog entry added to both copies, where: "app".

[efiten]

The firmware table is right where it matters — discover_limiter(4, 120) and anon_limiter(4, 180) are at simple_repeater/MyMesh.cpp:860-861 (your citation says 867/868, a few lines off but the values are the values), and I verified separately on #483 that the directed-TRACE path really is unmetered: every throttle in allowPacketForward sits behind isRouteFlood(). So "the cheapest probe, and the only unmetered one, was the one we were not sending" holds.

The two named decisions are both good. Bounding the batch by the send queue rather than the duty cycle is the honest constraint — 16 slots that drop silently on overflow is a much harder edge than a percentage. And recording the ask inside the send callback rather than at plan time is the right instinct: a BLE drop between the tick and the staggered timer should not cost a node its place.

Resetting the backoff on any traffic from a node, not only its reply, is the better rule for the reason given — in range is a property of where the hunter is now.

One thing I want to put numbers on, because the PR bounds our transmission and the thing it provokes is someone else's.

Your 2.3% figure is the hunter's own deaf time, and it is fine. But each ping makes a repeater transmit, on a path with no limiter, and that side is not in the table:

repeaters heard	replies/min each	that node's airtime
2	12.0	0.92%
4	6.0	0.46%
6	4.0	0.31%
10	2.4	0.18%
(Discover, for comparison)	2.0	0.15%

So in the sparse case — two repeaters audible, which is a normal rural hunt — we ask each of them for six times what a Discover-limited exchange would, and the firmware has nothing to refuse with. Two hunters sweeping the same pair doubles it again. That is not obviously wrong, and 0.9% is not obviously over anything, but it is a cost we impose on hardware we do not own, and it goes up as the area gets emptier, which is the opposite of the intuition the batch size was chosen against.

Worth either a sentence in the PR that says so plainly, or a floor — scale the batch to the set rather than fixing it at four, so a two-repeater area gets the same per-node rate as a ten-repeater one. I lean towards the latter, but it is a judgement about being a good neighbour on a shared channel rather than a defect, and it is your call and @efiten's.

Approving — the mechanism is right and well-tested, and this is a question about the constant, not the design.

[efiten]

Approved. Stacked on #483, so it rebases after that one lands. The per-node airtime question from my review still stands as a judgement call, not a blocker.