AtomFast — retry_delay sweep (sanity)

Параметры серии

retry_delay диапазон

1400, 1500, 1600, 1700, 1800 мс (шаг 100)

итераций на точку

4

окно мониторинга

30 секунд / итерация (sanity; для prod — случайно 10–20 мин)

BLE-пакет дозиметра

28 байт каждые ~2.4 с (≈25 rec/min номинал)

дозиметр

AtomFast

app-сборка

com.youratom.scid.atftest (test-flavor с broadcast SET_RETRY_DELAY)

метод измерения

PC-side adb-наблюдение роста arch_* файлов в /data/data/<app>/files

дата прогона

2026-06-07 (UTC)

Точка retry_delay помечается UNSTABLE если выполняется хотя бы одно из условий:

• (a) в ≥ 2 итерациях зафиксирован sudden_disconnect_count ≥ 1
• (b) median(records_per_minute) < 17.0 по всем итерациям точки

Порог 17 rec/min ≈ 70 % номинала (25 rec/min). Срабатывает на систематически плохой канал, а не на разовый затяжной коннект. Бейдж «STABLE *» — точка прошла правило, но имеет отдельную шумную итерацию (одна с rec/min < 17, ИЛИ одна с sudden_disconnect, ИЛИ одна dirty-stop).

Метод: app пропатчен — каждое получение BLE-пакета пишет rssi=<int> в logcat (тег AtomRssi). PC-side adb logcat -s AtomRssi:I ловит окно 60 с во время обычного подключения. Сэмпл −120 дБм в начале каждого окна — sentinel Nordic-BLE-библиотеки до первого реального чтения readRemoteRssi(), отброшен из steady-state статистики (raw n = 32, steady n = 31).

Дисклеймер: замер выполнен отдельно от sanity-серии (на момент серии RSSI-логирование ещё не было добавлено). Это baseline уровня сигнала на текущей геометрии «телефон ↔ дозиметр». Для production-прогона pre/post RSSI-probe станет частью run_sweep_adaptive.sh — окружит серию двумя окнами и зафиксирует drift сигнала, если он есть.

Уровень ~−84 дБм = средне-слабый стабильный канал. Рабочий диапазон BLE: −50 («вплотную») .. −90 («граница потерь»). Drift −0.55 дБ за 90 с (60 с + 30 с пауза + 60 с) = канал не деградирует на короткой шкале.

latency med / min / max, ms

4470 / 3754 / 8655

rec/min med / min

24.37 / 21.87

iter с sudden_disconnect ≥ 1

0 / 4

dirty planned-disconnect

0 / 4

latency med / min / max, ms

8029 / 5069 / 12382

rec/min med / min

20.68 / 14.95

iter с sudden_disconnect ≥ 1

1 / 4

dirty planned-disconnect

1 / 4

точка прошла, но есть отдельная шумная итерация (rec/min < 17 ИЛИ sudden ИЛИ dirty stop)

latency med / min / max, ms

5668 / 3909 / 8689

rec/min med / min

22.92 / 21.79

iter с sudden_disconnect ≥ 1

0 / 4

dirty planned-disconnect

0 / 4

latency med / min / max, ms

4358 / 3720 / 6294

rec/min med / min

24.04 / 22.48

iter с sudden_disconnect ≥ 1

0 / 4

dirty planned-disconnect

0 / 4

latency med / min / max, ms

5028 / 5012 / 13472

rec/min med / min

23.94 / 19.96

iter с sudden_disconnect ≥ 1

0 / 4

dirty planned-disconnect

0 / 4

• smoke_sweep_v6.sh корректно крутит 5 разных retry_delay'ев подряд без накопления state'а между точками.
• Per-rd persistent save в logs/sweep/rd_<N>/metrics_*.csv работает — данные пишутся сразу, краш в середине не убил бы предыдущие точки.
• Preflight broadcast SET_RETRY_DELAY → logcat verify (AtomRetry tag) прошёл на всех 5 точках.
• Все 5 точек по правилу STABLE — adaptive wrapper в test-mode на этом диапазоне прошёл бы все 5 без early-stop.
• rd = 1700 — самая чистая точка серии (latency med 4.36 с, rec/min med 24.04, 0 sudden, 0 dirty). На N = 4 это не доказательство оптимума — нужна полная статистика на N = 10/точка с bootstrap-CI.

Это sanity-прогон инфраструктуры, не production-исследование. N = 4 итерации на точку слишком мало для статистических выводов о «лучшем» retry_delay. Цель серии — подтвердить, что обвязка sweep'а (`smoke_sweep_v6.sh`, per-rd save, preflight broadcast, stability rule) работает на 5 разных значениях retry_delay без накопления ошибок.

Для production-прогона запланирован run_sweep_adaptive.sh prod: N = 10 итераций на точку × 10–20 минут мониторинга, старт с CENTER = 1600 мс, ход вниз и вверх с early-stop по первой точке, нарушившей stability rule. Результаты пойдут в retry_delay_optimizer.py (Tukey-fence + bootstrap-CI + Mann-Whitney U + Holm correction).