REC-12 — Pull-стрим сегментов водопада
+ шов на лету в единый .aswf

После #REC-11 (pull-эндпоинты /api/waterfall/segments + .../segment + .../segment/delete) плата умеет отдавать финализированные сегменты водопада по HTTP. Но каждый сегмент — отдельный .aswf с собственным заголовком, а длинная запись (> ring_capacity) не восстанавливается постфактум — кольцо keep-last перезаписывает старые строки (#FW-19).

#REC-12 замыкает pull-модель: PC-клиент периодически опрашивает плату, забирает новые сегменты и на лету склеивает их в один растущий .aswf. Тест — 11 ч непрерывной записи с Cs-137 662 кэВ в обычных условиях (комнатная температура, WiFi). Валидируется склейка без швов, отсутствие потерь, идемпотентность и открываемость результата штатным вьюером.

Плата пишет водопад в flash-кольцо, финализирует сегменты по возрасту и объёму. PC-клиент раз в --interval секунд опрашивает список сегментов, тянет новые (по state.json), приписывает только строки в конец растущего файла (заголовок сегмента отбрасывается, первый заголовок остаётся как шапка склеенного файла), fsync, и только затем — POST .../delete для этого сегмента на плате.

Сеть/файл/плата отвалились посреди шага — сегмент останется в списке платы, попадёт в следующий проход. Дубликаты режутся state.json по паре (name, size).

Запуск (двойной клик по wf_recorder.bat) или напрямую:

python scripts\wf_recorder_app.py --host http://atomspectra.local --interval 60

3.1 Готовый Windows exe (#PKG-1)

Для пользователей без Python — самодостаточный wf_recorder.exe (~12 МБ, tkinter + requests + wf_pull_client внутри):

• Скачать: Release wf-recorder-v0.1.0.
• Запуск: двойной клик → GUI откроется. По умолчанию файл записи — received/spectrogram.aswf рядом с exe (создастся автоматически).
• Пересборка из исходников (Python 3.10+, PyInstaller):

cd scripts
python -m PyInstaller --onefile --windowed --name wf_recorder \
  --hidden-import wf_pull_client --paths . wf_recorder_app.py
# результат: scripts/dist/wf_recorder.exe

Логика внутри exe идентична .py-версии (тот же wf_pull_client.Stitcher, тот же state.json, тот же порядок «сшить → fsync → delete на плате»), включая fix _default_output_path() для frozen-запуска.

Asset обновлён 2026-07-05 (commit 85eadb7): исправлен старт exe — режим --windowed PyInstaller обнуляет sys.stdout/sys.stderr; вызов .reconfigure() в wf_recorder_app.py и wf_pull_client.py обёрнут guard-ом if sys.stdout is not None.

Общая длительность

Разброс интервала строки (39 601 / 660 = 60.001 с) — на уровне единиц миллисекунд, точно попадает в номинал без дрейфа.

Склеенный .aswf

4104 байт — размер заголовка сегмента. Stitcher оставляет заголовок первого сегмента как шапку итогового файла и отбрасывает шапки 59 последующих. Совпадение до байта — прямое доказательство, что склейка не добавляет и не теряет ни одного байта данных.

Стабильность стрима

Телеметрия температуры прибора (t1)

t2, t3 = 0 (не задействованы этой сборкой прошивки) — норма.

Кольцо keep-last (make_room(), main/spectrogram.c:304-321) удаляет самый старый завершённый сегмент при нехватке места на flash — кроме текущего открытого и запиненного (s_seg_pinned). Пин ставит только push-выгрузка (#REC-11-A2, wf_offload.c), pull-путь (GET /api/waterfall/segment) сегмент во время скачивания не пинит.

При интервале опроса 60 с и типовой скорости записи (сегмент ~10-11 мин) запас многократный — за час плата добавляет ~5-6 сегментов, клиент делает 60 проходов. На данном тесте кольцо ни разу не приблизилось к границе (seg_dropped = 0, все 60 сегментов забраны).

Но при аварийно длинном интервале клиента или очень быстрой сегментации кольцо может съесть непрочитанный сегмент. Это зафиксировано как известное ограничение в KNOWN_ISSUES.md — обходной путь: держать --interval заметно короче времени съедания кольцом непрочитанного сегмента при текущей скорости записи. Автоматической защиты (аналог s_seg_pinned для pull-скачивания) пока нет — на текущей длительности теста (11 ч) не требуется.

started_at в шапке склеенного файла = time(NULL) платы на момент открытия первого сегмента (SNTP-синк через pool.ntp.org). Абсолютная метка — только если у платы был интернет на старте сегмента. Полное описание — в WATERFALL.md.

dur каждой строки — с живых часов прибора (total_time_sec), от интернета не зависит. Реляционные интервалы между строками честны всегда — и на этом тесте подтверждено: 660 строк × 60.001 с = 39 601 с, ровно совпадает с независимой оценкой по unix_ts из temps.csv (10.75 ч между первым и последним замером).

Артефакты записи (.aswf, .state.json, .temps.csv) — локально, не публикуются (gitignored: *.aswf, *.n42; каталог received/ игнорируется отдельно).

#REC-12 → закрыт. Pull-стрим доказан на железе: 11 ч непрерывной записи, 60 сегментов, 660 строк — 0 потерь, 0 швов, 0 дубликатов, склеенный файл байт-в-байт совпадает с ожидаемым размером (60 × сегмент − 59 × шапка). Открывается штатным вьюером как единая запись.

Схема покрывает основной сценарий длинных записей, обходя ограничение #FW-19 (экспорт n42 обрезан кольцом на ~4.25 ч) — pull-клиент забирает сегменты до заполнения кольца, восстанавливать хвост постфактум не требуется.

Незакрытые связанные

• #FW-19 (task #32, pending) — увеличение ring_capacity и/или документирование требования периодического pull. #REC-12 смягчает симптом, но не устраняет причину.
• #REC-13 (не заведён, потенциально) — пин сегмента для pull-скачивания (аналог s_seg_pinned push-пути). На текущей длительности и типовых интервалах не критично, документировано в KNOWN_ISSUES.md.

Pull-стрим wf_recorder_app.py подтверждён: 11.00 ч непрерывной записи, 60 сегментов склеены на лету в единый 10.32 МБ .aswf. 0 потерь, 0 швов, 0 ребутов, склеенный файл байт-в-байт совпадает с ожидаемым размером. Пик Cs-137 662 кэВ стабилен по всей высоте 3D-водопада и 2D-карты. Схема закрывает основной сценарий длинных записей, обходя ограничение #FW-19 без изменения прошивки.