OPEN ENGINEERING REALITY · TRACK 002 · OPEN BLUETOOTH REALITY

FROM BLUETOOTH LINK
TO AI WORK.

Use mature, low-cost Bluetooth devices as a local Reality link, then let browser, local runtime, server and GenAI turn that link into understandable, reusable work.

我们不是重新发明蓝牙，也不与成熟芯片、模组、协议栈或设备厂商竞争。研究目标是降低“第一次把一个现成蓝牙设备接进 GenAI 工作”的知识、软件和协作成本。

Reference Case 001 · W610 Smart Glasses Reference Case 002 · TTL/UART Bridge Evidence scope · JSON Restricted research material

PUBLIC C0-002 · Historical engineering references. Device connectivity does not imply person identity, data permission, supplier IP rights or execution Authority.

WHY BLUETOOTH

Do not rebuild a mature radio. Make the existing capability usable.

Cheap and already everywhereWearables, buttons, sensors, audio, cameras and many physical products already expose useful local Bluetooth capability.

Local link, global workThe radio remains local. A browser or Local Edge can turn bounded device data into a server/API/MCP-ready capability that people and AI can continue from anywhere.

AI shortens the integration pathLLMs can help read SDKs, inspect protocol behavior, generate adapters, explain failures and prepare the next bounded test.

Evidence stays separatePairing, GATT connection, a received packet, a decoded photo, an uploaded file and an AI result are different acceptance states.

REFERENCE CASE 001 · W610 SMART GLASSES · 2026

A Bluetooth camera became a browser-visible, server-addressable AI work input.

The historical path started from a mature smart-glasses product and its existing Bluetooth behavior. Early 2026 conversation records report a native Android SDK/app photo path and Mac Bluetooth/audio discovery; the complete original build logs for those early milestones are still under recovery, so they remain historical context rather than primary public evidence.

The strongest surviving public evidence begins in July and August 2026: the archived W610 gallery contains photos associated with multiple distinct W610 device names, including records on 30–31 July; by the 13 September archive snapshot, the gallery reported 115 photos. The later customer guide documents the direct browser workflow: choose Glasses (Bluetooth), press Connect Glasses, select a W610 device, wait for Connected, take a photo and receive the new image on the page.

Accepted historical chain

W610 glasses → local Bluetooth/BLE connection → browser/app adapter → photo packet/chunk assembly → JPEG → optional server upload → per-device gallery/API → AI description/tools → human decision to save, delete, share or continue.

REFERENCE CASE 002 · ZX-D36 / ZX-D30 · TTL/UART TRANSPARENT BRIDGE · 2026-06-09

A byte stream crossed Bluetooth and returned as UART data.

The recovered engineering session records a ZX-D36 on Windows COM6 configured as BLE master, scanning and connecting to a ZX-D30 on COM7. Exact text payloads were then observed in both directions across the transparent link; the D36 was MAC-bound for automatic reconnect and passed a restart / power-cycle check. A later branch also carried PC UART data through the D30 to an iPhone subscriber.

Open Reference Case 002Historical commands, payloads, binding sequence, voltage/wiring pitfalls and a reproducibility checklist based on the newly supplied ZX-D36 documentation.

Why it mattersUART/TTL is already present in enormous numbers of mature sensors, controllers and embedded products. Bluetooth can be a small local Reality Link instead of a new product architecture.

RECOVERED TIMELINE

Success grew in layers—not in one magic jump.

Feb–Apr 2026 · Prehistory under recoveryHistorical conversation records report W610_CADC Bluetooth/audio discovery on macOS and a native Android SDK photo workflow around the April exhibition. Primary logs/build artifacts have not yet been recovered into this public package.

30–31 Jul 2026 · Earliest surviving gallery evidenceArchived gallery records show W610_A9F2, W610_7F0F and W610_33CB photo entries. These are the earliest currently recovered photo records in the public evidence set, not a claim that they were the first ever captures.

10–12 Aug 2026 · Multi-device + API evidenceGallery records expand across multiple W610 identifiers. An archived API response on 12 Aug exposes a latest-photo object with device, filename, URL, bytes and UTC modification time, plus recent photos from multiple devices.

31 Aug–13 Sep 2026 · Usable workflowCustomer/operator guides document browser connection, photo transfer, gallery use, AI analysis, token-controlled upload and multi-device control. A 13 Sep gallery snapshot reports 115 photos.

THE WORKING TECHNICAL PATH

Keep each boundary visible.

Device

Existing W610 hardware advertises a Bluetooth/BLE capability.

不是重新设计无线芯片

Local Adapter

Browser Web Bluetooth or a native/Capacitor bridge requests the device, connects and subscribes to notifications.

本地连接与权限

Protocol

A bounded command starts capture; notifications carry fragmented photo data that must be assembled correctly.

连接成功不等于照片成功

Accepted Data

Assembled bytes decode as a JPEG and become a visible photo.

数据真的形成可用对象

Server / API

Optional upload gives the photo a durable route, device association and API-readable record.

从本地 Link 到可接续 Work

AI + Human

AI can describe, tag or answer bounded questions; a person still decides what to keep, share or act on.

AI interpretation is not Authority

RECOVERED CODE REALITY

The code artifact confirms the implementation shape.

A recovered student/HSIMC Android APK contains a Capacitor Bluetooth LE implementation and application code that requests W610 devices, connects to a GATT service, enables notifications, sends a bounded capture request, receives fragmented photo data, assembles it, checks JPEG magic and decodes the result. The currently recovered APK SHA256 is recorded in the machine-readable evidence file.

The public page deliberately does not publish vendor-specific protocol constants or third-party library binaries until provenance and redistribution boundaries are reviewed. The restricted Research Team layer can retain those engineering details for authorized continuation.

FROM BLUETOOTH TO MCP

The device does not need to become an MCP server by itself.

Bluetooth deviceProvides a local physical capability: capture, button event, sensor value, audio or another bounded function.

Local bridge / RuntimeOwns pairing, BLE protocol details, retry, data assembly, privacy and local device state.

MCP capability surfaceMay later expose higher-level tools such as connect_device, capture_photo, get_latest_photo or read_state without leaking raw radio complexity upward.

LLM / e-PersonWorks with Intent, Work, Authority and Evidence. It should not be given raw device control merely because Bluetooth is reachable.

因此蓝牙本身不是终点。它可以成为最便宜的一类 Reality Link：把已经存在的物理产品接到可理解、可授权、可验证、可持续的 GenAI 工作图里。

WHAT THE SUCCESS TAUGHT US

The valuable asset is the path others can reuse.

Bluetooth ID ≠ person identityA device name/address helps resolve hardware, but a durable Runtime identity and human identity must remain separate.

Capture ≠ accepted knowledgeA photo can enter AI analysis, but descriptions, counts and classifications still require purpose-specific human review.

Local radio ≠ global controlBluetooth stays local; global collaboration happens through durable Work, server/API records and optional MCP adapters.

One success can become a templateThe same method can be reused for BLE buttons, sensors, wearables, audio devices and other mature products without forcing every device to adopt the same app.

Evidence and rights boundary

This release does not claim Bluetooth itself was invented or improved by HSIMC, does not certify the W610 product, and does not publish supplier SDKs or confidential protocol material. The early Android/macOS milestones remain partly historical until primary artifacts are recovered. The July–September browser/photo/API chain is supported by surviving archived project material. Privacy, consent and device-specific permissions remain required for real use.

FROM BLUETOOTH LINKTO AI WORK.