review fixes: shared mock capture window, 2-position controller caveat

Мок-бэкенд ставил каждому трейсу свой capture_end_ns, потому что метка бралась в момент создания трейса. На реальном железе все комбинации коллекции выходят из одного синхронизированного цикла и делят одно окно — мок теперь ведёт себя так же, иначе он вводит в заблуждение при чтении записанных меток. В README контроллера добавлена оговорка: прошивка рассчитана ровно на два положения ключа. Хост допускает и 4, но тогда положение перестаёт быть чередованием одного бита и нужен контроллер на две управляющие линии. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-09 22:15:50 +03:00
parent 7d1879ad79
commit c1f8654677
2 changed files with 13 additions and 1 deletions
@@ -446,9 +446,15 @@ class MultiDeviceLibreVnaService:
                        s11=s11,
                        s21=s21,
                        capture_start_ns=mock_sweep_start_ns,
-                        capture_end_ns=time.monotonic_ns(),
                    )
                )
+        # One shared window, as on real hardware: every combo of a collection comes
+        # out of the same synchronized cycle. Stamping each trace as it is built
+        # would instead spread the ends over the generation loop, which never
+        # happens natively and would mislead anyone reading mock captures.
+        mock_sweep_end_ns = time.monotonic_ns()
+        for trace in traces:
+            trace.capture_end_ns = mock_sweep_end_ns
        self._mock_phase += 0.05
        return SweepCollection(
            collection_id=int(collection_id),