Package bounded X4 BLE diagnostics and USB mode reader

This commit is contained in:
DCCONSTRUCTIONS
2026-09-10 11:59:00 +03:00
parent b536f0049a
commit 1a2de8df65
12 changed files with 1178 additions and 3 deletions
@@ -859,3 +859,133 @@ viewer/worker/observer не запускались. Private0600 handoff.json SHA
Python urllib health probe был запрещён sandbox до соединения; штатный
curl GET подтвердил здоровье сервиса, изменения прав/службы не требовались.
Ops MISSIONCOR-77 обновлён; аппаратные acceptance items остались открыты.
## BLE01 — versioned discovery/standard GATT inspection, 10.09.2026
Владелец разрешил реализацию плана12. Read-only preflight08:27:37 UTC подтвердил
Bluetooth active, adapter powered, central/peripheral roles, rfkill unblocked.
BlueZ5.72, python3-dbus1.3.2 и python3-gi3.48.2 уже установлены. Core8000 operational,
Node active. Пароль, установка зависимостей и изменение служб не требовались.
До радиоэксперимента добавлены packaging/ble_diagnostic.py и
build_ble_diagnostic.py; build_deb включает тот же модуль и явные Debian
dependencies bluez>=5.72, python3-dbus, python3-gi. Installed package пока не
меняется: начальная проверка является engineering discovery без новых системных
предпосылок. Если зависимостей нет — artifact завершается ошибкой, не делает
apt/pip repair. Любые последующие persistent prerequisites сначала поставляются
installer/preparation. Никакого глобального исследовательского CLI.
BLE01 source SHA-256 27f6cb9a9623cb8c1a843f098df17b4d5553621f9fcaef931e4affb31abef598;
pyz SHA-256 da02b9d3a9b959b5376304c93495c7d62cec1c50fa9321695685bc2fe9637970.
Syntax passed; immutable-by-hash artifact staging в /var/tmp, private reports.
Сначала только scan: BlueZ client-scoped LE discovery20s/Pattern X4 с проверкой
свежих сигналов. Это active discovery, не passive radio sniffing. StopDiscovery
освобождает только собственную сессию; закрытие private bus убирает фильтр.
Не меняются Powered/Pairable/Trusted, не вызывается RemoveDevice. Отчёт сохраняет
только X4 candidates, не инвентаризацию окружающих BLE устройств.
Отдельный inspect допускает только конкретный свежий адрес X4, без прежнего
connection/bond; Connect<=20s, GATT discovery<=10s, standard DIS reads<=5s.
Нет vendor WriteValue, pairing, notifications или изменения USB mode. Только
2A24/25/26/29 внутри service180A; serial hash сверяется с прежним instance ID.
Имя/MAC сами не являются identity proof. Cleanup отключает только собственное
соединение, не перезапускает адаптер/USB/Node. Повторный scan не сохраняет
device configuration; обычный BlueZ discovery cache возможен, pairing не создаётся.
Результат аппаратного опыта ещё не получен.
BLE01 initial scan complete08:33:09.43960508:33:29.630298 UTC,
Ubuntu monotonic327497.320691854327517.511407622. Свежих X4 advertisements0;
vendor writes0, pairing0, notify0, cleanup errors0. Private scan.json SHA-256
266c1ecf21c97823b2dfbc902b5453bd093a22b5968a31dd87dccf16ca17aae5.
Владелец подтвердил тёмный экран; состояние off/screen-sleep ещё не разделено.
BLE02 подготовлен до повторного наблюдения: тот же workflow теперь допускает
scan20/60s и адресные sysfs USB samples, только Insta360 X4. Пользователь один
раз коротко нажимает Power с уже вставленным USB; агент лишь наблюдает.
Source SHA-256648e0f1ed0b37051af0b4985b5b69f6909f8e1099e0f61241574beb4dd4cca42;
artifact SHA-2567c3daba57990f4365ddd2829059e3aaa88d13ffffdb7db6a134d6224a0f0d86d.
В artifact также добавлен отдельный, по умолчанию выключенный --read-options.
Он требует явного адреса из свежей X4 рекламы; на BE80/BE81 только GetOptions8:
сначала serial15/model48, затем при совпадении exact instance USB95/wakeup97.
BE82 StartNotify/StopNotify выполняют временную CCCD subscription. Нет pairing,
setters, power, reboot, capture и generic arbitrary-command API. Данная ветка
на hardware ещё не запускалась и в BLE02 scan не используется. Package source
0.1.3-4 включает оба модуля/dependencies; установленная0.1.3-3 не менялась.
14 focused synthetic tests прошли: absent scalar не превращается в0, неверный
device/session/response/framing отвергается, timeout не повторяется, чужой notify
сохраняется. Формат header проверен статически по pinned SDK CameraMessage.GetData
0x5e6cd0 и CameraPacket.GetData0x5e6ff0: header7+9, uint32 total length, command16,
content type2, message ID30bit/direction/end. Реальная BLE совместимость ещё не
доказана. Payload GET read не имеет rollback эффекта; cleanup снимает CCCD и
собственное соединение. Неизвестный ответ останавливает последовательность.
BLE02 scan complete08:42:44.76745608:43:44.963861 UTC,
Ubuntu monotonic328072.648544286328132.844958963: USB X4 отсутствует во всех
samples, свежих BLE candidates0, cleanup errors0. Private power-button-scan.json
SHA-2569dbd5e126cd628963fcc65b869abc98a361fee1e1efcbedb25f9434ee279dd44.
Факт нажатия Power владельцем в это окно не подтверждён; результат не считается
отрицательным тестом wake-on-button. --read-options не выполнялся.
B12 intent: собрать и квалифицировать X4 model0.1.3-4 на существующей Ubuntu
через native_build_entry/package source workflow. Artifact18eccc74211a8eb9094fffe2,
58331680 bytes, SHA-2561d93f3e95ba37d3d4af05bc48903d2305c4cf61d47a7daa3f15ff0c62f64fd86.
Entry ограничивает process tree1GiB/180CPU s/nice10, user-owned /var/tmp staging.
Никакой установки, исполнения SDK, камеры/USB/BLE доступа во время build/tests.
В package-tests добавлены14 BLE tests и проверка фактически упакованных модулей
и Debian dependencies. Остальные payload/native/SDK bytes сохраняются.
Core/D455/Node services и маршруты не меняются. Partial build не переигрывается
без сохранения результата; только artifact-owned --clean очищает свою папку.
B12 complete08:45:14.66258008:45:37.358068 UTC,
Ubuntu monotonic328222.54366779, duration22.695515s.52 package tests passed;
result.tar.gz SHA-25626230933c4562f9881585d5dc1fbb3a46318680b13e5389d3d74da6e9d0a8968.
После review добавлен USB ownership guard перед BLE Connect и каждым запросом:
если прежняя X4 уже в2e1a:0002, диагностический запрос не отправляется, SDK owner
сохраняется. Отдельный synthetic case проверяет этот запрет. Cleanup error не
отмечается complete; ByteArray properties сериализуются в private report.
B12-R1 intent: повторная сборка/квалификация только вследствие этих новых правок.
Source artifact fbe65bd0efe313df2ecff17a,58332043 bytes,
SHA-256 ef2f05df12b30c3503ba50403ca1c6caa22656646b8d5838469ae23a18f3b8c2.
Diagnostic artifact a919d293c292935cfd636f0e,
SHA-256 bf1325b882d696314507f98fc627235ec579fa7d910035fb6155ce51f939b698;
source SHA-2563308f4647c9f8420df05147d647376f85051ceb0ea2c8c84d726612cb2fb02b0.
Новая версия пока не запускает аппаратный read-options: камеры нет в discovery,
ответ владельца о результате нажатия Power ожидается. Нет никаких setter/reset
или pairing команд. B12/B12-R1 не устанавливаются как замена Node0.8.19 bundle:
подготовка текущей Node пока использует прежнюю0.1.3-3, это явно открытый шаг.
B12-R1 complete, result archive SHA-256
7c0bfc9ea0595611d86230b2ace7faa0d94e65acf0b807ed36329cba87000724.
Review обнаружил недочёт test harness: новый ownership guard при двух fake
transport tests читал реальные sysfs descriptors, хотя intent ограничивал
тесты синтетикой. Это не открывало USB device nodes и не отправляло команд.
USB snapshot теперь подменяется во всех BLE tests; guard отдельно проверяется
контролируемым synthetic устройством. Рабочий diagnostic/package payload не
менялся после B12-R1, изменён только test harness.
B12-R2 intent: тот же package payload и исправленная изоляция тестов.
Artifact263f37468d091c11d51a6f07,58332087 bytes,
SHA-256 ab361b9239af1a08d32c66908b6eeb12278acd95a5ef776f581f263320770ce6.
Остальные resource/install/device boundaries прежние. Это последняя требуемая
квалификация после обнаруженного дефекта тестов, не расширенный soak/load run.
B12-R2 complete08:50:54.36034908:51:17.109377 UTC,
Ubuntu monotonic328562.241436096, duration22.749061s.53 tests passed (38 прежних
и15 BLE). Cold Python imports/static ELF closure/package contents/dependencies
проверены. Package0.1.3-4:58204178 bytes, revision9c3007af852d7188e65b4706,
SHA-2569f79bf6e6fc9d258db2c329cdf2696aa61004aa409dffec95cb648838db4ae57.
Result archive SHA-2569359f34a4cab94729650a243b1449fce8dd3a14e3c0093b44cde6f87ee19bcf3;
скачан в private ignored ble01/b12-r2, проверены архивные entries и hash .deb.
SDK disassembly evidence SHA-256
bd808c21f07f8acd3af299687e43ed0ead19bac83c4b8730dafe76c54dec0f45.
Handoff08:51:39.716463 UTC,Mac monotonic450779.766443833: Core8000 operational,
Rover006 online, прежняя RealSense online/streaming, X4 offline/idle.
Private handoff.json SHA-256
c2f88192a4f7059db9419df4fd0a5b95f2425101d93bfd36097a62226e62a662.
Все собственные scan/build processes завершены; фоновых viewer/observer нет.
USB/BLE vendor commands0, pairing0, CCCD subscriptions0 на hardware за этот этап.
Открытый вопрос владельцу: результат короткого Power с уже вставленным USB.
Не получив свежего устройства, read-options/setter не запускались.
@@ -1,5 +1,16 @@
# Insta360 X4 — состояние реализации 10.09.2026
## BLE01/BLE02 — первый модуль беспроводной диагностики
Реализован [BLE diagnostic workflow](13_INSTA360_X4_BLE_DIAGNOSTIC.md): bounded
discovery, стандартное GATT inspection и отдельное чтение identity/USB options.
Те же модули и OS dependencies включены в исходники model package0.1.3-4.
На Ubuntu initial scan20s и последующий scan60s не обнаружили X4; владелец
сообщил о тёмном экране. Выполнение предложенного короткого Power не подтверждено.
Read-options, pairing, setters и power-команды на hardware не запускались.
Installed Node0.8.19 / X40.1.3-3 сохранены; bundled Node profile ещё не обновлялся.
Автовозврат Android остаётся открытым; нельзя считать успешную сборку его приёмкой.
## RESEARCH01 — программный возврат Android после USB out/in
[Исследование точного сценария](12_INSTA360_X4_ANDROID_RECONNECT_RESEARCH.md)
+7
View File
@@ -16,6 +16,13 @@ P10/PREP05 complete: Node0.8.19 и X4 model0.1.3-3 установлены шта
OWNER03: владелец видит изображение X4 и D455 через Core при переходах между карточками. Read-only Node snapshot обеих камер online/streaming. Длительная одновременная работа и измерения ещё не приняты.
BLE01/BLE02: [первый диагностический модуль](13_INSTA360_X4_BLE_DIAGNOSTIC.md)
реализован и включён в исходники model package0.1.3-4. На Ubuntu два bounded
наблюдения не обнаружили X4; экран камеры тёмный. Следующий hardware шаг —
состояние после короткого Power с уже вставленным USB, затем fresh BLE candidate
и явный read-options. Ни setter, ни BLE power cycle ещё не выполнялись.
Node0.8.19 bundle пока остаётся0.1.3-3; его обновление не считается завершённым.
## Очередь реализации
**Уточнение владельца10.09 после NET03:** ближайший приоритет после применения
@@ -4,6 +4,9 @@ RESEARCH01, 10.09.2026. Запрос владельца: исследовать
включённой X4 и возможность программно вернуть Android mode. Это исследование
документации и исходных данных, не аппаратная приёмка новой команды.
Продолжение реализации: [BLE diagnostic, BLE01/BLE02/B12](13_INSTA360_X4_BLE_DIAGNOSTIC.md).
Read-only команда подготовлена; ответа самой X4 на Options95 ещё нет.
## Вывод и исправление предыдущего плана
Штатно X4 должна помнить последний USB mode. Подтверждённой готовой команды,
+122
View File
@@ -0,0 +1,122 @@
# X4: диагностика Bluetooth и чтение USB mode
10.09.2026, BLE01/BLE02/B12. Реализация первого проверяемого шага
[исследования reconnect](12_INSTA360_X4_ANDROID_RECONNECT_RESEARCH.md).
Автоматический возврат Android ещё не принят.
Финальный B12-R2: пакет 0.1.3-4 собран на Ubuntu, 53 tests passed, включая
15 BLE cases. Проверены реальные содержимое .deb, зависимости, cold imports
и статическая ELF closure. SHA-256 пакета:
9f79bf6e6fc9d258db2c329cdf2696aa61004aa409dffec95cb648838db4ae57.
Пакет не установлен; рабочие службы и bundled Node payload сохранены.
## Поставляемый код и границы
- `plugins/insta360-x4/packaging/ble_diagnostic.py`: bounded BlueZ discovery,
отдельное GATT inspection и явный режим чтения настроек.
- `ble_options.py`: только GET_OPTIONS, строгие packet/protobuf bounds и
разбор ответов. Нет generic send, SET_OPTIONS, capture, reboot или power-off.
- `build_ble_diagnostic.py`: артефакт с hashes обоих модулей; тот же код
включён в model Debian package 0.1.3-4 через `build_deb.py`.
- `check_package_entry.py`: проверяет наличие/совпадение модулей в реальном
.deb, объявленные зависимости и synthetic tests.
Установленная Node 0.8.19 пока содержит X4 model 0.1.3-3. Сборка новой модели
не является её развёртыванием или аппаратной приёмкой. После проверки BLE
нужно обновить bundled model/profile Node штатным репакером, затем применить
из Core/Node через обычную подготовку. UI состояния пока не меняются.
Зависимости `bluez >= 5.72`, `python3-dbus`, `python3-gi` объявлены в Debian.
На нашей Ubuntu они уже были установлены. Диагностический artifact ничего
не устанавливает и не ремонтирует автоматически: отсутствие зависимости,
прав D-Bus или powered adapter даёт явную ошибку. До первого hardware опыта
не добавлялись apt/pip packages, chmod устройств, polkit grants, udev или
изменения служб. Versioned /var/tmp staging и private evidence — единственные
создаваемые файлы. Этот опыт не квалифицирует чистую Ubuntu.
## Последовательность и идентичность
По умолчанию — только 20 секунд LE discovery, при физическом тесте можно выбрать
60 секунд. Фильтр BlueZ принадлежит конкретному клиенту; дополнительно каждый
результат проверяется локально. Сохраняются только имена `X4 ` плюс 6 символов.
Cached Device object не считается свежим появлением: требуется новый сигнал
advertisement/RSSI/name во время наблюдения. Остальные модели не выбираются.
При отсутствии такого имени результат означает отсутствие кандидата в рамках
данного фильтра, а не доказательство полного отсутствия радиосигнала камеры.
Для GATT требуется явно выбранный свежий адрес и прежний device ID. Имя/MAC
используются только для выбора кандидата; не создаётся новая привязка и не
объединяются камеры. Existing connection/bond отвергается в первоначальном
inspection. Перед Connect и каждым запросом проверяется sysfs: если точный
экземпляр уже в USB SDK mode, диагностика сохраняет владельца SDK и прекращается.
Стандартные reads: service 180A, характеристики 2A24/25/26/29
(model/serial/firmware/manufacturer), без каких-либо записей. Если DIS serial
доступен, его hash сравнивается с прежней USB identity.
`--read-options` дополнительно допускает:
1. Точный service BE80 и его BE81/BE82. Existing notify owner не перехватывается.
2. BE82 StartNotify: BlueZ выполняет временную CCCD subscription. Это реальная
служебная BLE-запись, не provisioning камеры. StopNotify выполняется в cleanup.
3. Один GET_OPTIONS8 на BE81 для serial15 и camera_type48.
4. Только при полном serial hash, совпадающем с прежним `instax4_…`, и точной
модели X4 — второй GET_OPTIONS8 для udisk_mode95 и bt_wakeup_sw97.
5. Cleanup завершает только своё notify/соединение, затем закрывает private
D-Bus connection. Никакого Pair, Trust, RemoveDevice или adapter power cycle.
Если камера требует авторизацию, не отвечает, возвращает другой протокол или
ошибку — последовательность прекращается. Автоматических retries/альтернативных
framing/handshake guesses нет. Успех GATT write ещё не означает успешное чтение.
Поле должно присутствовать в ответе и в списке возвращённых options; отсутствие
scalar не превращается в default PC=0. UNKNOWN не разрешает setter.
## Основание wire format
SDK 2.1.8, SHA-256
6d20aca1930101293308c056cef552c0beb8cbf1d6c7d567a79e95a52f9b1373,
исследован статически. Библиотека не загружалась и не исполнялась.
`CameraMessage::GetData` (0x5e6cd0) сериализует command uint16, content byte,
32-bit message identifier и 2 нулевых байта перед payload: всего 9 байт.
`GetIdentifier` (0x5e6ca0) использует 30-bit message ID, direction bit30 и
end bit31. `CameraPacket::GetData` (0x5e6ff0, обычная ветка без UCD2) добавляет
7 байт: uint32 total size, packet type, два нулевых байта. Поэтому полный
заголовок занимает 16 байт, а length включает его. Не используется неверная
payload-only length из прочитанного insta360ctl Header16 encoder.
Пример synthetic GET_OPTIONS95, message ID1:
`12000000040000080002010000800000085f`.
Параметры команды подтверждены embedded protobuf descriptors из плана12.
Ответ допускается только в том же framing, с direction/end и совпадающим
полным message ID. Code200 — ожидаемая success семантика общего протокола;
реальная X4 BLE с этим codec ещё не проверена. Неподдержанная fragmentation
останавливает read, не разбирается предположительно.
X4 BE80/BE81/BE82 опубликованы в
[аппаратном разборе BLE X4](https://github.com/TheAngryRaven/insta360-ble-gps-spec).
Он подтверждает service family, но сам разбирает главным образом GPS remote;
полный direct-control framing не считается принятым на нашей камере.
BlueZ lifecycle основан на [Adapter API](https://bluez.readthedocs.io/en/latest/adapter-api/)
и [GATT API](https://bluez.readthedocs.io/en/latest/gatt-api/).
## Результат и следующий аппаратный шаг
BLE01: 20 секунд discovery, свежих X4 candidates0. BLE02: 60 секунд discovery
и sysfs sampling, X4 отсутствовала в обоих транспортных наблюдениях.
Владелец сообщил о тёмном экране. Факт короткого нажатия Power в окно BLE02
не подтверждён. Эти результаты не являются отказом команды чтения или
доказательством невозможности Bluetooth wake-up.
Нужно получить состояние после одного короткого Power с уже вставленным USB.
Если появилась штатная USB X4, сначала фиксируется этот успех и сохраняется
SDK owner. Если камера включена в обычный режим — повторный bounded scan,
выбор конкретного кандидата, GATT inspection, затем отдельный read-options.
До этого vendor commands0, pairing0, CCCD subscriptions0.
После реального чтения95 можно решать, есть ли основание для безопасного
Android setter. Если уже ANDROID=1, запись того же значения может быть лишь
сохранением предпочтения. Переход PC→Android и generic reboot остаются вне
реализованного allowlist. BLE remote off/on требует отдельного артефакта и
проверенного wake-up до выключения камеры. Ни один из этих исходов пока
не установлен. Raw reports/hashes/UTC/monotonic — в installation ledger.