Fixed and decaying beacon schedules

Two schedules that answer when the next beacon is due, and why.

Scope:

Fixed interval, with a first beacon at start and an optional random offset so many stations don't beacon together.
Decay for objects, items and changed information: send now, then at doubling intervals (for example 10 s, 20 s, 40 s …) up to a ceiling, restarting when the content changes.
Each answer carries the reason (Interval, Changed, Decay) for a UI to show.

Done when:

FakeTimeProvider tests cover the fixed interval, the decay sequence, its ceiling and a restart on change;
the API is listed in PublicAPI.Unshipped.txt.

What AprsMap's F2.2 beacons need from these schedules (AprsMap PR #227, docs/features/F2.2-beacons.md):

Fixed: intervals from 10 min to 24 h. The first beacon comes after a random wait, capped at a tenth of the interval and at most 3 min.
Decay: the first step is a parameter (AprsMap starts at 1 min on RF and 30 s on APRS-IS), then doubles up to a ceiling (the fixed interval). It restarts when the content changes.
Manual send: a "send position now" restarts the decay count.
Reasons: every answer carries its reason (Interval, Changed, Decay), so a status bar can show "next beacon in 12 min" and why.
No catch-up bursts: after a gap (transmit off, connection down, app closed), the next answer is "now" once, and then the schedule carries on. Either the scheduler does this, or it documents that the caller must.
No I/O: it runs on TimeProvider and works with FakeTimeProvider. AprsMap applies the 10-minute floor per RF source and the 10 s spacing between beacons itself.

Corner pegging (#197) can follow; AprsMap uses it only with GPS, in its 0.6.0.

Navigation Menu