2026-10-01 `medithings-rnd/VesiscanBasicAndroid` 의 `demo-final` 을 히스토리째 이 저장소의
`main` 으로 옮겼다. 병원 임상 앱은 일반 사용자 앱과 다른 제품이라 따로 산다.
· rootProject.name: medilightv2android → VesiscanClinicalAndroid (IDE 에 보이는 이름)
· README: 무엇인지 · 어디서 왔는지 · 빌드/설치 · 화면 흐름 · 데이터 위치
· FIRMWARE_BLE_FINDINGS.md 의 저장소 안내를 새 위치로
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
연결 에피소드 464건을 전수 집계해, 반쪽 연결의 서명이 **MTU 응답 중복**임을 찾았다.
MTU 1회: 433건 중 420건 성공 (97.0%)
MTU 2회: 31건 중 7건 성공 (22.6%)
그리고 해제→재연결 간격이 짧을수록 이중 MTU 가 잦고 성공률이 낮다. 2초 미만 재연결은
5건 전부 실패(이중 MTU 60%), 60초 이상은 95.9% 성공(이중 MTU 5.4%). n=5 는 작지만
단조 추세라 방향은 분명하다.
실패가 "느린 것"이 아니라는 근거도 같이 담았다 — 정상 준비 시간은 중앙 0.836초 ·
최대 2.624초(n=420)인데, 실패한 연결은 20~25초를 기다려도 오지 않았다. 중간이 없다.
타이밍이 아니라 상태 문제로 보인다.
날짜와 앱 버전이 다른 두 사례가 같은 서명을 보인다는 점도 축자 로그로 실었다.
09-11 10:50 은 HALF_CONNECTED 두 번, 09-10 13:39 은 status=8 인데 둘 다 해제 직후
재연결 → 이중 MTU → 장시간 침묵 → tx=0 rx=0 이다. 후자는 가드 도입 전이라 OS 의 link
supervision timeout 이 먼저 끊었을 뿐 같은 증상이다. 즉 종전에 status=8 로 보고된 건
중 tx=0 rx=0 인 것들은 실제로는 서비스 탐색 무응답이다.
우리 쪽 가드 값(쿨다운 600ms, 가드 20초)이 근거 없이 정한 값이라는 점을 문서에 명시하고,
펌웨어의 정상 회복 시간을 물었다. 증상 A 의 실측 회복이 48초라 20초로는 첫 재시도가
못 붙는다. 숨기지 않는 편이 답을 받는 데 낫다.
내부 메모의 VBTFW0206 freeze 주장은 철회한다. 로그에 있는 펌웨어는 0200(13)/0203(138)/
0205(507) 뿐이고, 0206 은 로그 파일명의 숫자 110206 을 오독한 것이었다. 근거 없는
주장을 펌웨어팀에 보낼 수는 없다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
dw.jang