8.2 KiB

Raw Blame History

Technical audit

Status: live feasibility validated, 2026-07-15.

Executive finding

The K1-to-Mac realtime link is feasible and has been demonstrated without LixelGO. The tested Mac provisioned firmware 3.0.2 over BLE, confirmed K1 LAN association, opened the device's MQTT 3.1.1 service on TCP 1883, captured a physical-button scan and decoded both point-cloud and pose reports.

All 1,140 captured lio_pcl frames decoded as raw-LZ4 protobuf blocks, yielding 4,165,862 points. All 1,215 lio_pose messages decoded, and the resulting approximately 1.566 m displacement matched the controlled movement. The remaining feasibility question is the panoramic camera branch, not the core realtime LiDAR/pose path.

The supplied Bible is useful as an OSINT dossier. It is not an executable plan for the actual stand because many experiments assume a phone and LixelGO. The implementation must proceed through explicit gates and stop before speculative writes.

Evidence classes

Version-scoped facts to verify on the physical unit

K1 has LiDAR, panoramic cameras, onboard compute, BLE and Wi-Fi.
Official workflows use BLE before Wi-Fi network/data connection.
Autonomous scan start/stop by the physical button is documented.
A scan project may contain local map.las, poses.csv, project.json, logs, preview/model and raw sensor artifacts depending on firmware and settings.
macOS exposes a CoreBluetooth device UUID rather than a portable hardware MAC.
A normal switched/mesh LAN does not mirror arbitrary client-to-client unicast to the Mac, but the Mac can capture its own future K1 session completely.

Each of these remains scoped to the actual firmware/hardware state observed in the lab. The physical unit is authoritative.

Resolved hypotheses

BLE is the bootstrap/provisioning plane and Wi-Fi/MQTT is the high-rate data plane on the tested firmware.
SSID and PSK use a verified fixed 99-byte GATT frame; the hidden credential path never persists the password.
The report subscriptions require no second MQTT credential, certificate or application publish handshake on the direct LAN path.
The external lio_pcl stream is a processed point cloud rather than raw LiDAR packets.

XGRIDS provides stronger product evidence for an external point-cloud path than the local LAS alone: current LixelStudio materials describe K1 remote control and realtime point-cloud streaming over USB/Wi-Fi. LixelStudio is Windows-only and this does not disclose or guarantee access to the protocol from macOS. It does, however, justify keeping realtime point cloud as the primary stream target. No comparable official evidence proves an exportable raw panorama/camera stream.

Still unsupported until measured

Local map.las layout resembles the network stream.
Raw or stitched panoramic camera frames leave the device.
The upper 24 bits of point rgbi are usable packed RGB.
MQTT application commands can be published safely without first reproducing device/session header state and response handling.

Initial corrections to the source plan

These corrections governed the safe experiment. The resolved outcomes above and the verified profiles now supersede their pre-lab uncertainty.

Experiments requiring LixelGO are removed from the active critical path. There will be no app-session capture, provisioning diff, app-start comparison, or temporary broker mode.
The first go/no-go is device activation and autonomous operation. An unactivated unit may be a hard blocker before BLE provisioning is relevant.
Provisioning is not implemented merely because a characteristic is writable. We need target UUID, framing, field encoding, ordering, integrity/auth fields, connect/commit semantics, status response, and rollback.
Wi-Fi association and application data session are modeled as separate states. Obtaining an IP is not success for the realtime connector.
tcpdump does not create a stream. A useful capture requires either K1 to initiate traffic or Mac to become the authenticated/subscribed endpoint.
Full port/version/UDP scans are active operations, not passive safe defaults. Discovery begins with power on/off diffs, router client list, ARP and broadcast/multicast observations, then targets only the confirmed K1 IP.
Heavy packages are deferred. OpenCV, Open3D, pandas, Scapy, PyShark and NumPy are not prerequisites for proving bootstrap connectivity.
Wi-Fi passwords must never be CLI arguments. Future provisioning will use a hidden interactive prompt or macOS Keychain and must redact payloads.

Router audit

The existing TP-Link Deco/mesh router is adequate for the initial work. No router setting needs to change before the first observations.

We need only DHCP, a shared reachable network, and ideally a way to view the client list. Band steering and a single combined SSID are acceptable. A separate Guest/IoT SSID is optional; on some Deco modes it isolates clients, which would prevent Mac-to-K1 traffic. If a separate SSID is later used, peer-to-peer reachability must be tested before provisioning K1 onto it.

The main-LAN fallback is acceptable for a narrow, target-filtered experiment. It must not include a broad scan or unfiltered capture of household traffic.

Environment audit

Observed host baseline:

Apple Silicon (arm64);
macOS 26.5.1;
uv and Homebrew present;
system Python is 3.13.5, while the project requires 3.12;
tcpdump and ffmpeg present;
tshark and nmap not currently found.
the current default route is a VPN tunnel (utun), while Wi-Fi is en0.

The project therefore pins Python 3.12 via .python-version; uv creates a local .venv. Nothing in setup installs global Python packages. Missing external network-analysis tools are reported by k1link doctor and are not installed until their gate requires them and the change is explicitly accepted. Future network commands must determine the route for the confirmed K1 IP; neither the default route nor en0 may be hardcoded.

Primary blockers

Gate	Blocking condition	Meaning
Device	fault, activation lock, no autonomous project	Stop before networking
BLE	no advertisement or only inaccessible/authenticated surface	Investigate state/permissions before writes
Wi-Fi	no remembered network/AP and opaque custom GATT	Provisioning research is the hard block
Data session	IP exists but service requires unknown token/handshake	Association succeeded; connector has not
Streams	session opens but no useful external stream	Realtime goal may be unsupported
Camera	point cloud works but frames never appear	Camera branch may be unsupported; not an MVP failure

Implementation consequence

The correct order is:

device baseline
  -> autonomous project + USB metadata
  -> passive BLE surface
  -> remembered Wi-Fi / device AP check
  -> evidence-led provisioning gate
  -> application-session gate
  -> targeted capture
  -> flow classification
  -> point cloud / pose / status / optional camera decoders

The chain through point-cloud/pose decoding is now complete. See the MQTT stream profile and redacted lab report for measured formats, counts and artifact hashes.

Verified primary references

Reference-document statements not independently repeated here remain inputs or hypotheses, not verified conclusions of this audit.

8.2 KiB Raw Blame History