影踪定位报警系统 STAS · 技术解读 | ShadowTrace Positioning Alarm System

系统概述

影踪定位报警系统（英文全称 ShadowTrace Positioning Alarm System，缩写 STAS）解决一个具体问题：在一个范围有限的封闭区域内，让观察方持续知道被观察目标的位置，并在双方接近到危险距离之前得到明确提醒。

系统由三段构成。感知段是目标随身携带的定位终端（Eelink GPT60），负责卫星定位并通过 4G 网络周期上报；平台段是部署在云服务器上的接入与分发服务，负责协议解析、位置存储与实时推送；呈现段是观察方手持的安卓接收终端，在 OpenStreetMap 地图上显示目标位置，并独立承担 10 米近距离报警。

需要先讲清一个容易混淆的分工：地图上的位置是“粗定位”，10 米报警是“精报警”，两者使用完全不同的技术通道。GNSS 的定位误差本身就有 5–15 米，用两个 GPS 坐标在服务端算距离来判断 10 米，在数学上就不成立——误差和阈值同量级，必然大量误报漏报。因此 10 米判定改由蓝牙低功耗（BLE）信号在接收终端本地完成：目标一侧另佩戴一枚 BLE 信标持续广播，接收终端持续扫描，信号强度越过经现场标定的阈值即触发报警，全程不经过服务器、不依赖任何一方的 GPS 坐标。这一分工是全系统的核心设计，详见第 02、07 章。

适用边界

区域：小范围封闭区域（如单个校区量级），开阔天空为主，建筑物内部定位能力明显下降（见第 10 章误差分析）。
规模：一对一为主的设计——一个被观察目标、一名观察方；协议与服务端支持多设备接入，但报警逻辑按单目标标定。
网络：目标活动区域需有 4G 覆盖；接收终端经移动网络或 Wi-Fi 访问服务端。
前提：定位终端与 BLE 信标由目标随身携带且保持开机，系统不具备无配合条件下的感知能力。

命名说明。“影踪”取“只见其踪、不见其人”之意：服务端与接收终端能获得的只有目标的位置轨迹，目标本人的影像、声音、身份信息一概不在采集范围内（原则三：最小化采集）。

设计原则

三条原则不是口号，每一条都直接决定了硬件选型、协议选择与代码结构。任何后续改动若与原则冲突，应先修改原则文档并重新评审，而不是绕开。

PRINCIPLE — 01

单向可见

位置信息只沿一个方向流动：目标 → 服务端 → 接收终端。目标终端不接收、不显示接收方的位置；接收方在系统内没有可被查询的位置记录。可见性不对称是刻意设计，而非功能缺失。

PRINCIPLE — 02

粗定位与精报警分工

“目标在哪里”用 GNSS + 4G 链路回答，精度米级、周期 5 秒；“是否已接近到 10 米”用 BLE 近场信号在本地回答，判定延迟亚秒级。两种问题、两种通道，互不替代、互为冗余。

PRINCIPLE — 03

最小化采集

只采集实现功能所必需的数据：目标的位置、时间、电量与设备状态。不采集接收方位置（方案一），不采集音频、影像与通讯录，不接入第三方广告与统计 SDK。数据保留周期可配置，默认从严。

原则一的落地：信息流向对照

数据	产生方	流向	目标终端可见	接收终端可见
目标经纬度 / 速度 / 航向	GPT60	终端 → 服务端 → 接收终端	—（自身产生）	可见
目标电量 / 在线状态	GPT60	终端 → 服务端 → 接收终端	—	可见
接收方经纬度	不产生	无此数据流（方案一不定位）	不存在	不存在
BLE 广播（信标 ID + 发射功率）	BLE 信标	空中广播 → 接收终端本地处理	—	本地可见不上云
报警事件	接收终端	本地产生、本地呈现	不可见	可见

注：BLE 广播是空中信号，物理上任何扫描设备都能接收到，这是蓝牙广播机制的固有属性；系统通过使用非公开的信标 UUID 并定期轮换标识，降低被第三方长期关联跟踪的可能（见第 11 章）。

总体架构

系统按“端—网—云—端”四层组织。两条链路彼此独立：位置链路（实线）走 4G 与互联网，报警链路（虚线）是目标与接收方之间的本地蓝牙直连，云端故障不影响报警，蓝牙故障不影响定位——任何单点失效只降级一半功能。

图 3-1　系统总体架构图FIG. 3-1 · SYSTEM ARCHITECTURE

实线为位置链路：GPT60 每 5 秒经 4G 以 GT06 协议上报，Traccar 解码入库后经 WebSocket 实时推送至接收终端地图。底部虚线为报警链路：BLE 信标广播由接收终端本地扫描判定，与云端完全解耦。

一次完整的位置更新时序

T+0.0s卫星定位GPT60 完成一次 GNSS 定位解算（热启动约 1–2 s）

T+0.2s组帧发送按 GT06 格式打包位置包，经已建立的 TCP 长连接发出

T+0.5s云端解码Traccar 校验、解码、写入数据库，生成位置事件

T+0.8s实时推送WebSocket 将新位置推至已订阅的接收终端

T+1.0s地图刷新接收终端更新目标标记与轨迹线（典型端到端 ≤ 2 s）

上表为 4G 信号良好、无重传条件下的典型值预算，完整时延分析见第 10 章。两次上报之间（5 s 窗口）目标位置不更新，这是地图显示的最大固有延迟来源。

分层职责

层	组成	职责	失效影响
感知层	GPT60、BLE 信标	定位、组帧上报；持续广播近场信号	地图冻结在最后位置；报警失效（信标）
网络层	4G 蜂窝网、互联网	承载 GT06/TCP 长连接与 HTTPS/WSS 流量	位置延迟或中断，终端本地缓存待恢复补传
平台层	Nginx、Traccar、数据库	协议接入、设备鉴权、存储、推送、轨迹查询	地图停止更新；BLE 报警不受影响
应用层	安卓接收终端	OSM 地图呈现、BLE 扫描判定、声光振动报警	观察方失去全部感知（单点，需保持电量与后台存活）

定位终端 GPT60

定位终端选用深圳 Eelink 的 GPT60 个人定位器：一台为“人随身携带”设计的 4G 定位器，而非车载设备——自带电池、无需接线取电、体积重量可揣入口袋，且支持将上报服务器改为自有地址，从而把数据链路完全收回本系统。

图 4-1　GPT60 后盖开启分解草图FIG. 4-1 · EXPLODED VIEW, REAR COVER OPEN

部件说明

① 后盖与贝壳螺丝：后盖由两颗小螺丝固定，开启后露出 SIM 卡槽与内部结构；非日常开合件，换卡后务必拧紧以保持密封。
② SIM 卡槽：装入 4G 物联网卡（Nano-SIM），承担全部数据上报；选卡以流量计费，一天约数 MB 级（见第 10 章）。
③ LED 指示灯：分别指示 GPS 与网络状态——搜星中、已定位、已联网以不同闪烁模式区分，部署时以灯语确认终端工作正常。
④ 电源键：长按开关机；开机后自动搜星、自动联网、自动按设定周期上报，无需其他操作。
⑤ 挂绳孔：穿挂绳佩戴于颈部或固定于包内夹层，避免口袋深处人体遮挡天线。
⑥ 充电口：为 600 mAh 内置电池充电；按 5 秒上报估算续航 5–8 小时，使用前应充满。

内部（虚线示意）：主控板集成 GNSS 芯片、LTE Cat.1 模组与天线；电池位于主控板下方。内部结构不开放维护，草图仅作原理说明。

草图按黑线技术图风格绘制：实线为外观可见部件，虚线为内部结构示意，引线编号与右侧部件说明一一对应。

关键规格

项目	参数	对本系统的意义
外形尺寸 / 重量	60 × 45 × 19 mm · 约 40 g	可随身携带，不干扰目标正常活动
蜂窝网络	4G LTE Cat.1（下单确认国内频段版本）	Cat.1 功耗与成本远低于手机级模组，带宽对位置包绰绰有余
定位方式	GNSS（GPS + 北斗）+ LBS 基站定位	开阔环境卫星定位，室内外过渡区以基站定位兜底
定位精度	5–15 m（开阔环境）	满足“粗定位”需求；不承担 10 m 判定（原则二）
电池	600 mAh 可充电	5 秒上报约 5–8 小时（估算，见第 10 章），覆盖单次使用时长
上报周期	可配置，本系统设为 5 s	周期越短轨迹越细、耗电越快，5 s 为平衡点
服务器配置	支持自定义服务器地址 / 端口（下单前向卖家确认）	选型硬条件：数据必须直达自有 Traccar，而非厂家平台
传输协议	GT06 系列协议（TCP）	Traccar 原生支持解码，见第 06 章

选型校验（采购前必问）。市售同名设备存在海外频段版本与车载接线版本，采购时须逐项确认：① 国内 4G 频段版本；② 自带电池、无需外部供电；③ 可修改服务器 IP / 端口；④ 可设置 5 秒上报间隔。四项任一不满足即不适用本系统。

厂家自带的 Keelin 平台仅用于出厂演示，本系统不使用：GPT60 的上报地址直接指向自有 Traccar 服务，位置数据不经过厂家平台。

GNSS / A-GPS / LBS 定位原理

GPT60 的一次“定位”可能来自三种机制，精度相差两个数量级。理解三者的原理与切换逻辑，才能正确解读地图上位置点的可信度。

图 5-1　卫星定位测距原理草图FIG. 5-1 · GNSS RANGING PRINCIPLE

GNSS 接收机测量多颗卫星信号的到达时间差，换算为距离后做球面交汇解算。第四颗卫星用于校正接收机自身的时钟误差——廉价终端的晶振不足以独立提供纳秒级计时。

GNSS 卫星定位（主用）

原理：同时接收 GPS 与北斗信号，测距交汇解算经纬度。
精度：开阔环境 5–15 米；高楼峡谷、树冠、建筑内部显著变差甚至无解。
启动时间：冷启动（无星历）约 30 秒以上；热启动 1–2 秒。终端周期工作时多为热启动。
弱点：信号极弱（约 −160 dBW），任何屋顶都能完全遮挡。

A-GPS 辅助定位（加速）

原理：经 4G 网络预先下发卫星星历、概略位置与时间，接收机免去慢速解码卫星广播星历。
作用：把首次定位时间从几十秒压到数秒；不改变最终精度。
依赖：需要蜂窝网络可用——与上报链路共用同一 4G 通道。
注意：A-GPS 是“辅助 GNSS”，不是独立的定位方式。

LBS 基站定位（兜底）

当卫星信号不可用（如进入建筑内部）时，终端以当前连接的蜂窝基站小区 ID 及邻区信号强度估算位置。其精度取决于基站密度：城区约 100–300 米，郊区可达千米级。LBS 结果只用于“大致在哪个区域”的参考，地图上应以较大的不确定圈呈现，严禁拿来做距离判定——这正是系统把 10 米判定交给 BLE 的另一面理由。

三种机制对照

机制	典型精度	首次定位	室内可用	在本系统中的角色
GNSS（GPS + 北斗）	5–15 m	1–2 s（热）/ 30 s+（冷）	否	主定位来源，地图位置以此为准
A-GPS	同 GNSS	缩短至数秒	否	加速首次定位与重捕获
LBS 基站定位	100–1000 m	即时	是（粗略）	无卫星信号时的区域兜底
BLE 近场判定	阈值判定，非坐标	亚秒级	是	10 米报警专用，不产生坐标（第 07 章）

GT06 传输链路

位置数据从终端到云端走 GT06 系列协议：一种在车载/个人定位器领域沿用多年的二进制 TCP 协议。选它的理由很实际——GPT60 原生输出、Traccar 原生解码，中间不需要任何协议转换网关。

连接模型：TCP 长连接 + 心跳保活

终端开机入网后，主动向服务端约定端口（部署时配置，本站以占位符 <服务器地址>:<GT06端口> 表示）建立一条 TCP 长连接并保持。位置包、心跳包、状态包共用这条连接多路复用：位置包每 5 秒一帧，心跳包在无位置数据的间隙维持连接活性并让服务端确认终端在线。长连接避免了每帧重新建连的时延与流量开销，也使服务端能即时感知掉线（连接断开即标记设备离线）。

图 6-1　GT06 位置帧结构示意FIG. 6-1 · GT06 LOCATION FRAME (SCHEMATIC)

帧结构为原理级示意：字段顺序与构成以协议公开文档为准，具体字节定义（协议号取值、状态位位定义、CRC 算法范围）以部署时采用的协议版本文档与 Traccar 解码实现为据。

链路可靠性处理

应答确认：服务端对登录帧与部分状态帧回确认帧；位置帧依序列号可检测丢帧与乱序。
断线重连：终端检测到连接中断后自动重拨重连；重连成功后恢复周期上报。
弱网表现：4G 信号边缘区会出现帧延迟与成串到达，地图表现为位置“跳步”——这是链路特性而非定位错误，前端以轨迹平滑与时间戳标注区分。
时间基准：位置帧内含 GNSS 时间，服务端以帧内时间记录轨迹，避免网络延迟污染轨迹时间轴。

BLE 10 米近距离报警

报警链路与定位链路彻底分离：不计算坐标、不经过服务器、不依赖网络。目标一侧的 BLE 信标只做一件事——周期性广播自己的存在；接收终端只做一件事——监听这个广播并测量它的强度。

图 7-1　BLE 信标分解草图FIG. 7-1 · BLE BEACON, EXPLODED VIEW

部件说明

① 上盖：圆形外壳上盖，预留 LED 透光点，用于低电量与工作状态提示；卡扣/旋盖结构便于换电池。
② PCB 主板：集成 BLE SoC 与板载天线，固件设定广播间隔（典型数百毫秒一帧）与发射功率——发射功率直接决定报警距离，必须与接收端阈值成套标定。
③ CR2032 电池：3 V 纽扣电池供电，以低占空比广播工作可续航数月；电量耗尽即报警链路失效，须纳入使用前检查清单。
④ 底盖与挂孔：可穿绳佩戴或缝入衣物夹层；佩戴位置应避免紧贴人体躯干正后方——人体对 2.4 GHz 信号有明显衰减。

广播内容仅含信标标识与发射功率参考值，不含任何位置信息——信标本身不知道自己在哪里。

信标为通用 BLE iBeacon 类硬件形态的黑线示意；具体采购型号的内部布局以实物为准，系统只依赖其广播行为与可标定性。

判定原理：RSSI 与距离

蓝牙信号强度（RSSI，单位 dBm）随距离增大而按对数规律衰减。接收终端持续扫描目标信标的广播，读取 RSSI 后与标定阈值比较：RSSI 高于阈值（信号足够强）判定为“已进入 10 米”，低于阈值则未进入。为抑制临界抖动，判定引入双门限与持续确认：连续多次扫描越过阈值才触发报警，连续多次回落才解除——避免在 10 米边界附近反复鸣响。

图 7-2　RSSI—距离关系与报警阈值（示意）FIG. 7-2 · RSSI vs DISTANCE, SCHEMATIC

曲线为对数路径损耗模型的原理示意（1 米参考值 −59 dBm 为 BLE 常见出厂标称），不是实测数据。真实阈值必须在部署现场按第 12 章流程标定：同一距离下，信标在口袋、背包、颈挂三种佩戴方式的 RSSI 可相差 10 dB 以上。

为什么不能用 GPS 算 10 米

方案	误差量级	判定延迟	结论
双端 GPS 坐标算距	两端误差叠加，最坏 > 20 m	≥ 5 s（受上报周期）	不成立误差大于阈值本身
服务端算距后下发报警	同上，且接收方须上报自身位置	≥ 6–8 s	不成立且违反原则一、三
BLE 本地 RSSI 判定	阈值判定（经标定约 ±2–3 m 边界模糊带）	< 1 s	采用近场信号对近距离天然敏感

接收终端与 OSM 地图

观察方使用一台普通安卓手机作为接收终端，运行专用应用。它同时承担两件相互独立的事：联网呈现目标位置（地图），以及离线也能工作的 BLE 扫描报警。

图 8-1　接收终端（安卓手机）正面草图FIG. 8-1 · RECEIVER HANDSET, FRONT VIEW

部件与功能说明

① 听筒 / 摄像头：系统不调用摄像头与麦克风（最小化采集）；听筒仅用于常规通话，与报警无关。
② 屏幕与报警横幅：主界面为 OSM 地图 + 目标标记；报警触发时顶部横幅变色，配合声音与振动三通道提示，锁屏状态下亦可呈现。
③ 电源键：熄屏后应用转入后台服务继续扫描与接收推送——须在系统设置中为应用开启后台运行与电池优化豁免，否则国产安卓的后台冻结会同时杀掉两条链路。
④ 音量键：报警音量随媒体/铃声音量设置；部署验收时须实测最大音量在目标环境噪声下可辨识。
⑤ 扬声器：报警声输出通道；建议同时启用振动，避免嘈杂环境漏听。
⑥ USB-C：充电与调试；持续扫描 + 地图渲染是主要耗电项，长时间使用建议接移动电源。

机型无特殊要求：Android 8.0 以上、支持 BLE 4.0 以上、具备移动网络即可；草图为通用直板机形态示意。

黑线草图：实线为机身可见部件，屏幕内细线为 OSM 路网示意，红色元素仅用于标示报警横幅与目标标记。

方案一：接收终端自身不定位

本系统现行方案（方案一）的关键决定是：接收终端应用完全不申请定位权限，不读取自身 GNSS，不向服务端上报任何自身坐标。地图打开时以目标位置（或预设的区域中心）为中心显示，观察方靠对环境的熟悉自行判断方位。这一决定带来三个直接结果：

权限面最小：应用所需权限仅为网络、蓝牙扫描与通知，不含定位权限——安卓的蓝牙扫描在旧版本上曾与定位权限绑定，适配时须按目标系统版本使用 neverForLocation 等声明排除定位用途。
服务端数据面最小：数据库中不存在接收方的任何轨迹记录，数据泄露时的暴露面只有目标一方。
报警逻辑自洽：正因为没有接收方坐标，10 米判定在物理上只能靠 BLE 本地完成，架构反而更简单、延迟更低、断网可用。

为什么用 OpenStreetMap

免实名、免 Key 绑定：OSM 及其开源渲染库（flutter_map / osmdroid 等）无需商业地图 SDK 的实名认证与应用签名绑定流程，部署摩擦最低。
可离线：目标区域瓦片可预先下载缓存，网络中断时地图底图仍可显示（位置更新仍需网络，二者分开看）。
可自托管：规模扩大后可自建瓦片服务，底图数据不受第三方服务条款变化影响。
代价：国内部分区域的 OSM 路网细节与更新速度不及商业地图；本系统区域小且固定，可预先核查并手动补绘关键路径。

服务端流水线

服务端部署在一台云 VPS 上，构成刻意保持简单：一个反向代理、一个成熟的开源位置平台、一份数据库。没有自研协议栈，没有消息队列——一对一规模下，每多一个组件就多一份运维与故障面。

图 9-1　服务端宿主机与 VPS 分层草图FIG. 9-1 · SERVER STACK, LINE DIAGRAM

组件说明

① 宿主机 / VPS：云厂商虚拟机即可，1–2 核、2 GB 内存量级足够本系统负载；本站不写死任何服务商与地址，部署参数见技术文档部署章节的占位配置表。
② Nginx：对外唯一 Web 入口，负责 HTTPS 证书终止、将请求反代至 Traccar，并对管理界面做访问控制。
③ Traccar：开源位置平台，承担 GT06 协议解码、设备注册与鉴权、位置事件生成、轨迹查询 API 与 Web 管理界面，是服务端的核心。
④ WebSocket 推送：Traccar 的实时通道，接收终端订阅后，目标每上报一帧，地图在约 1 秒内刷新（第 03 章时序）。
⑤ 数据库：Traccar 默认嵌入式数据库即可起步；轨迹数据按保留策略定期清理（第 11 章）。

黑线草图：上为宿主机前面板示意，下为 VPS 内部软件分层；组件间细线表示请求/数据流向。

数据流水线（单帧位置的旅程）

STEP 1接入GT06 帧经 TCP 抵达 Traccar 协议端口，按 IMEI 识别设备

STEP 2校验解码CRC 校验 → 字段解码 → 生成标准位置对象（经纬度/时间/速度）

STEP 3落库位置对象写入数据库，形成可回放的轨迹序列

STEP 4分发WebSocket 向在线订阅端推送；离线端下次打开时拉取最新位置与历史轨迹

STEP 5呈现接收终端更新标记、精度圈与“最后更新于 N 秒前”状态

管理面与数据面分离：Web 管理界面用于设备注册、账号与轨迹回看，经 Nginx + HTTPS 暴露且应限制访问来源；GT06 接入端口只处理协议帧，不提供任何管理能力。服务端不参与报警判定——报警事件的产生与呈现全部在接收终端本地完成（原则二）。

时延、误差与性能分析

本章的数字分两类：一类是器件与协议决定的固有量级（精度、帧长、周期），一类是设计估算（续航、端到端时延）。估算均标注口径，部署后应以第 12 章的验收实测替换。

端到端时延预算（位置链路）

环节	典型值	不利条件	说明
上报周期等待	0–5 s（平均 2.5 s）	5 s	固有延迟：事件恰在两帧之间发生时须等下一帧
定位解算	约 1 s	冷启动 30 s+	周期工作为热启动；长时间关机后首次开启除外
4G 上行 + 互联网	0.1–0.5 s	数秒（弱信号重传）	与目标所处位置的信号质量强相关
服务端解码入库	< 0.1 s	< 0.5 s	单设备负载下可忽略
WSS 推送 + 前端渲染	0.2–0.5 s	1–2 s（接收方弱网）	接收方网络独立于目标方网络
合计（地图新鲜度）	典型 ≤ 7 s	不利 ≈ 12 s	界面须显示“最后更新时间”，避免把旧位置当实时位置

报警链路的时延独立计算：BLE 广播间隔数百毫秒 + 接收端扫描窗口 + 双门限确认，从跨过阈值到发出报警典型小于 1 秒，且不经过任何网络环节——这是安全相关的判定必须本地化的根本原因。

误差来源与对策

误差源	影响	量级	对策
多径反射（楼宇间）	GNSS 位置漂移、跳点	10–30 m	地图端轨迹平滑；精度圈如实绘制；不以单点定论
卫星几何与遮挡	精度下降或短时无定位	—	A-GPS 辅助重捕获；LBS 兜底并标注低可信
人体遮挡（BLE）	信标在身体背侧时 RSSI 骤降	约 −10 dB	信标佩戴于身体前侧/颈挂；标定时覆盖三种佩戴方式取保守阈值
环境多径（BLE）	RSSI 抖动、边界模糊	±6 dB 级	双门限 + 多次确认；接受约 ±2–3 m 的报警边界模糊带
接收方后台被冻结	推送与扫描同时中断	功能性失效	电池优化豁免 + 前台服务保活 + 验收时熄屏实测（第 12 章）

续航估算（交互试算）

GPT60 的 600 mAh 电池是全系统最紧的资源。选择上报间隔，估算续航与流量随之变化——本系统定版为 5 秒，试算用于理解这组取舍：

上报间隔 — 续航 / 流量试算器

估算模型（设计估算，非实测）：每次上报事件（定位 + 发射）约耗 0.55 mAh，待机底电流约 4 mA；单帧连同协议开销约 120 B。实际续航受信号强度与温度影响显著，验收以实测为准。

估算续航

—

每小时上报

—

日流量（连续运行）

—

静止 5 分钟最大位移盲区*

*盲区按步行速度 1.4 m/s 估算：两次上报之间目标可移动的距离。它与续航是一对此消彼长的取舍——间隔越长越省电，轨迹越粗、地图越“旧”。

安全、隐私与合规

位置数据是最敏感的个人数据类别之一。本系统的安全设计目标明确：数据只在“目标终端—自有服务端—授权接收终端”三点之间流动，每一跳都可控、可查、可断。

传输与接入安全

管理与呈现面全程 TLS：Nginx 终止 HTTPS/WSS，证书到期纳入运维日历；管理界面限制来源并启用强口令。
设备身份：GT06 以 IMEI 标识设备，服务端仅接受已注册 IMEI 的连接，未注册设备帧直接丢弃。
协议固有限制（如实记录）：GT06 为明文协议，帧内容不加密、IMEI 可仿冒——这是该成熟协议的历史局限。本系统以“小范围、短时使用、数据价值有限”为风险接受前提；若未来用于高敏感场景，应迁移至支持 TLS 与双向鉴权的协议/终端，此点已列入技术文档的风险登记表。
端口最小暴露：防火墙仅放行必要端口，数据库与 Traccar 管理端口不对公网开放（经 Nginx 或内网访问）。

隐私设计（与原则三对应）

单向数据面：接收方零定位、零上报（方案一），数据库中不存在其轨迹。
BLE 标识轮换：信标标识不使用可长期关联的固定公开 UUID 组合，并建议按使用周期更换，降低被第三方扫描设备长期追踪的可能。
保留周期：轨迹数据默认短期保留（部署时按需设定，建议以天计），到期自动清理；导出与删除操作留痕。
无第三方 SDK：接收终端应用不集成广告、统计与崩溃上报类第三方 SDK，底图瓦片请求是唯一的对外数据请求（可通过区域瓦片预缓存进一步减少）。

合规要点

知情与同意：对他人进行定位属于法律与伦理敏感行为。部署前必须取得被定位方的明确知情同意，并限定使用目的、时段与数据范围；本系统定位为经协商的区域安全/监护类用途的技术方案，不得用于未经同意的跟踪。
个人信息保护：行踪轨迹属于敏感个人信息，处理活动应遵循《个人信息保护法》关于单独同意、最小必要与安全保障的要求。
地图合规：OSM 数据为开放数据（ODbL 许可），使用时保留署名；其坐标为 WGS-84，与国内商业地图的 GCJ-02 偏移体系不同，跨图源叠加时须做坐标系转换，避免系统性偏移误读。
无线电与入网：终端与信标应选用具备相应型号核准/入网手续的市售成品，本方案不涉及自制射频发射设备。

部署、标定与验收

部署分四步：服务端上线、终端开通、现场标定、验收测试。其中标定是本系统特有的关键步骤——BLE 报警距离不存在“出厂默认值”，阈值只能在真实环境中测出来。

部署清单

服务端　VPS 上线，Nginx + Traccar + 数据库就绪，HTTPS 证书生效，防火墙按最小端口策略配置，服务地址与端口记入部署配置表（占位符 <服务器地址>）。
设备注册　在 Traccar 中按 IMEI 注册 GPT60，建立观察方账号并绑定设备可见权限。
终端开通　GPT60 装入物联网卡，向卖家/平台确认服务器地址、端口已指向自有 Traccar，上报间隔设为 5 秒；LED 灯语确认搜星与联网正常。
信标配对　记录信标标识并写入接收终端应用的监听列表，确认发射功率档位并固定（标定后不得更改）。
接收终端　安装应用，授予蓝牙与通知权限，加入电池优化豁免名单，预缓存目标区域 OSM 瓦片。

BLE 阈值标定流程

定点采样：在部署区域的典型空旷点，将信标按实际佩戴方式（颈挂 / 口袋 / 包内）分别置于距接收终端 5 m、8 m、10 m、12 m、15 m 处，每点采样 60 秒 RSSI。
取保守阈值：以 10 m 处三种佩戴方式中信号最强的一组为上限参考、12 m 处最弱一组为下限参考，在其间选取阈值并留出迟滞带（触发阈值与解除阈值相差约 4–6 dB）。
走测验证：携带者以步行速度从 25 m 外径直走近，在 10 m 标线处核对报警是否触发；反向走远核对解除距离；重复 5 次记录触发距离分布。
遮挡复测：增加人体转身（信标位于背侧）、隔一堵墙等不利姿态复测，确认模糊带宽度可接受，并将结果记入标定记录表。
冻结参数：标定后的发射功率、广播间隔、双阈值与确认次数写入配置并冻结；更换信标型号、佩戴方式或主要使用场地后须重新标定。

验收标准

验收项	方法	通过标准
定位精度	在已知坐标点静止采样 5 分钟	开阔环境下位置点 90% 落在真实点 15 m 内
上报连续性	步行环绕区域一圈（约 20 分钟）	轨迹无超过 30 s 的断点（信号盲区除外并记录）
地图新鲜度	终端移动时观察界面更新时间戳	典型 ≤ 7 s，界面正确显示最后更新时间
报警距离	标定后走测 10 次	触发距离落在 8–13 m 区间内 ≥ 9 次
报警时延	跨过阈值瞬间至声/振/横幅出现	< 1 s（本地判定，不含网络）
断网韧性	关闭服务端（或断开云端）后走测报警	BLE 报警功能完全正常；恢复后地图续传
续航	满电 5 秒上报连续运行至自动关机	≥ 5 小时（低于则更换电池/终端个体）
熄屏存活	接收终端熄屏 30 分钟后分别触发位置更新与报警	推送可见、报警可触发，应用未被系统冻结

验收记录应包含：日期、场地、参与设备编号（IMEI / 信标标识脱敏记录）、标定参数快照与每项实测值。验收不通过的项按“标定问题 / 链路问题 / 个体故障”归类处理后复测。

↓

技术文档下载

本页为解读版；完整技术文档（中文版 22 页，含全部黑线图原图、帧格式附录、部署配置表与风险登记表）以 PDF 提供下载，并同时提供英文版 PDF。

影踪定位报警系统 · 技术文档

ShadowTrace Positioning Alarm System — Technical Document。涵盖本页全部章节的完整论述，以及 GPT60 / BLE 信标 / 接收终端 / 服务端的逐部件黑线图与说明表。

22 页约 1.5 MB版本 V1.0编号 STAS-TECH-2026-001

下载中文版 PDF 下载英文版 PDF · English

部署说明：本站与文档中的服务器地址、端口均为占位符（<服务器地址>:<端口>），实际部署时按交付的配置表填写，不在公开页面中出现真实地址。

System Overview

The ShadowTrace Positioning Alarm System (abbreviation STAS) solves a specific problem: within a small enclosed area, the observer continuously knows the position of the observed target and receives a clear warning before the two approach within a dangerous distance.

The system consists of three segments. The sensing segment is the positioning terminal carried by the target (Eelink GPT60), which performs satellite positioning and reports periodically over 4G. The platform segment is the access and distribution service on a cloud server, responsible for protocol decoding, position storage and real-time push. The presentation segment is the Android receiving terminal held by the observer, which displays the target on an OpenStreetMap map and independently handles the 10-metre proximity alarm.

A division of labour that is easily confused must be clarified first: the position on the map is “coarse positioning”, and the 10-metre alarm is a “precise alarm” — they use completely different technical channels. GNSS error itself is 5–15 metres, so calculating distance on the server from two GPS coordinates to judge 10 metres is mathematically unsound: error and threshold are of the same magnitude, causing many false and missed alarms. The 10-metre decision is therefore made locally on the receiving terminal from Bluetooth Low Energy (BLE) signals: a BLE beacon worn by the target broadcasts continuously, the receiver scans continuously, and when signal strength crosses a field-calibrated threshold an alarm is triggered — without passing through the server and without relying on either party's GPS coordinates. See Chapters 02 and 07.

Scope and Boundaries

Area: a small enclosed area (e.g. a single campus), mainly open sky; positioning capability drops markedly inside buildings (see Chapter 10).
Scale: designed primarily for one-to-one use — one observed target, one observer; the protocol and server support multiple devices, but alarm logic is calibrated for a single target.
Network: the target's activity area requires 4G coverage; the receiver accesses the server via mobile network or Wi-Fi.
Prerequisite: the positioning terminal and BLE beacon are carried by the target and remain powered on; the system has no sensing capability without cooperation.

About the name. “ShadowTrace” conveys “seeing only the trace, not the person”: the server and receiver can obtain only the target's position track. No image, sound or identity information of the target is collected (Principle 3: data minimisation).

Design Principles

The three principles are not slogans. Each directly determines hardware selection, protocol choice and code structure. If a later change conflicts with a principle, the principle document should be revised and re-reviewed first, rather than bypassed.

PRINCIPLE — 01

One-Way Visibility

Position information flows in one direction only: target → server → receiving terminal. The target terminal does not receive or display the receiver's position, and the receiver has no queryable position record in the system. Asymmetric visibility is deliberate design, not a missing feature.

PRINCIPLE — 02

Coarse Positioning vs. Precise Alarm

“Where is the target?” is answered by GNSS + 4G, at metre-level accuracy with a 5-second period. “Has the target come within 10 metres?” is answered locally by BLE near-field signals, with sub-second latency. Two questions, two channels — neither substitutes for the other.

PRINCIPLE — 03

Data Minimisation

Only data necessary for the function is collected: the target's position, time, battery and device status. The receiver's position is not collected (Option 1), and no audio, images, contacts, advertising or analytics SDKs are used. Retention is configurable and strict by default.

Principle 1 in Practice: Information Flow

Data	Producer	Flow	Visible to target terminal	Visible to receiver
Target longitude / latitude / speed / heading	GPT60	Terminal → Server → Receiver	— (self-produced)	Visible
Target battery / online status	GPT60	Terminal → Server → Receiver	—	Visible
Receiver longitude / latitude	Never produced	No such data flow (Option 1: no positioning)	Does not exist	Does not exist
BLE broadcast (beacon ID + transmit power)	BLE beacon	Over-the-air broadcast → local processing on receiver	—	Local only Not uploaded
Alarm event	Receiving terminal	Generated and presented locally	Not visible	Visible

Note: BLE broadcasts are over-the-air signals that any scanning device can physically receive — an inherent property of Bluetooth broadcasting. The system uses a non-public beacon UUID and rotates identifiers periodically to reduce long-term third-party tracking (see Chapter 11).

Overall Architecture

The system is organised in four layers: device — network — cloud — device. Two links are independent: the positioning link (solid line) runs over 4G and the Internet, while the alarm link (dashed line) is a local Bluetooth direct connection. A cloud failure does not affect the alarm, and a Bluetooth failure does not affect positioning.

Figure 3-1 System ArchitectureFIG. 3-1 · SYSTEM ARCHITECTURE

Solid line — positioning link: GPT60 reports every 5 seconds over 4G using GT06; Traccar decodes, stores and pushes via WebSocket to the receiver map. Dashed line at the bottom — alarm link: BLE beacon broadcasts are scanned and judged locally by the receiver, fully decoupled from the cloud.

Timing of One Complete Position Update

T+0.0sSatellite FixGPT60 completes a GNSS fix (hot start about 1–2 s)

T+0.2sFrame & SendPosition packet framed in GT06 format and sent over the TCP long connection

T+0.5sCloud DecodingTraccar validates, decodes, stores and generates a position event

T+0.8sReal-Time PushWebSocket pushes the new position to subscribed receivers

T+1.0sMap RefreshReceiver updates marker and track line (typical end-to-end ≤ 2 s)

Values above are typical budgets under good 4G signal with no retransmission; see Chapter 10 for full latency analysis. Between reports (the 5-second window) the target position does not update — the largest inherent source of map delay.

Layer Responsibilities

Layer	Components	Responsibilities	Impact of failure
Sensing	GPT60, BLE beacon	Positioning, framing and reporting; continuous near-field broadcast	Map freezes at last position; alarm fails (beacon)
Network	4G cellular, Internet	Carries GT06/TCP long connections and HTTPS/WSS traffic	Position delayed or interrupted; terminal caches for later upload
Platform	Nginx, Traccar, database	Protocol access, device authentication, storage, push, track query	Map stops updating; BLE alarm unaffected
Application	Android receiver	OSM map, BLE scan decision, audible/visual/vibration alarm	Observer loses all awareness (single point — keep battery and background process alive)

Positioning Terminal GPT60

The terminal is Shenzhen Eelink's GPT60 personal locator: a 4G locator designed to be carried by a person — battery-powered, no wiring, pocket-sized — and it supports changing the reporting server to a self-owned address, keeping the data link entirely within this system.

Figure 4-1 GPT60 Exploded View, Rear Cover OpenFIG. 4-1 · EXPLODED VIEW, REAR COVER OPEN

Component Descriptions

① Rear cover & shell screws: fixed by two small screws; opening reveals the SIM slot and internal structure. Not a daily-opening part — tighten after SIM replacement to maintain sealing.
② SIM card slot: holds a 4G IoT card (Nano-SIM) carrying all data reporting; daily traffic is only a few MB (see Chapter 10).
③ LED indicators: indicate GPS and network status — searching, fixed, connected — with distinct blink patterns; use the LED language at deployment to confirm normal operation.
④ Power button: long-press to power on/off; after power-on the device automatically acquires satellites, connects and reports at the configured interval.
⑤ Lanyard hole: for neck-wearing or fixing inside a bag compartment, avoiding deep-pocket body shielding of the antenna.
⑥ Charging port: charges the 600 mAh built-in battery; estimated 5–8 hours at 5-second reporting — charge fully before use.

Inside (dashed): the main board integrates the GNSS chip, LTE Cat.1 module and antenna; the battery sits below the main board. Internal structure is not user-serviceable; the sketch is for principle explanation only.

Black-line technical sketch: solid lines are externally visible parts, dashed lines show internal structure, and leader numbers correspond one-to-one with the component descriptions on the right.

Key Specifications

Item	Specification	Significance for this system
Dimensions / Weight	60 × 45 × 19 mm · approx. 40 g	Carryable without interfering with normal activity
Cellular network	4G LTE Cat.1 (confirm domestic band version when ordering)	Cat.1 power and cost are far below phone-grade modules; bandwidth is ample for position packets
Positioning	GNSS (GPS + BeiDou) + LBS cell positioning	Satellite positioning in open areas; cell positioning as fallback in transition zones
Accuracy	5–15 m (open environment)	Meets “coarse positioning” needs; does not carry the 10 m decision (Principle 2)
Battery	600 mAh rechargeable	About 5–8 hours at 5-second reporting (estimate, Chapter 10)
Reporting interval	Configurable; set to 5 s in this system	Shorter interval = finer track, faster drain; 5 s is the balance point
Server configuration	Custom server address / port supported (confirm with seller before purchase)	Hard selection requirement: data must go directly to the self-owned Traccar, not the vendor platform
Protocol	GT06 family (TCP)	Natively decoded by Traccar — see Chapter 06

Selection checks (ask before purchase). Devices sold under the same name include overseas-band and vehicle-wired variants. Confirm item by item: ① domestic 4G band version; ② built-in battery, no external power; ③ server IP/port can be changed; ④ 5-second reporting interval can be set. If any item is not met, the device is not suitable.

The manufacturer's Keelin platform is for factory demonstration only and is not used: GPT60 reports directly to the self-owned Traccar service, and position data never passes through the vendor platform.

GNSS / A-GPS / LBS Positioning Principles

One “fix” from GPT60 may come from three mechanisms whose accuracy differs by two orders of magnitude. Understanding their principles and switching logic is essential to interpreting the credibility of positions on the map.

Figure 5-1 Satellite Ranging PrincipleFIG. 5-1 · GNSS RANGING PRINCIPLE

The GNSS receiver measures arrival-time differences from multiple satellites, converts them to distances and solves by spherical intersection. The fourth satellite corrects the receiver's own clock error — a low-cost terminal's crystal cannot independently provide nanosecond timing.

GNSS Satellite Positioning (Primary)

Principle: receives GPS and BeiDou simultaneously; solves latitude/longitude by ranging intersection.
Accuracy: 5–15 m in open environments; markedly worse in urban canyons, under canopy or indoors, sometimes with no solution.
Start-up: cold start (no ephemeris) over 30 s; hot start 1–2 s. Periodic operation is mostly hot starts.
Weakness: signals are extremely weak (about −160 dBW); any roof can block them completely.

A-GPS Assisted Positioning (Acceleration)

Principle: ephemeris, approximate position and time are delivered in advance over 4G, so the receiver need not slowly decode satellite broadcast ephemeris.
Effect: first-fix time falls from tens of seconds to a few seconds; final accuracy is unchanged.
Dependency: requires cellular network — shares the same 4G channel as reporting.
Note: A-GPS “assists” GNSS; it is not an independent positioning method.

LBS Cell Positioning (Fallback)

When satellite signals are unavailable (e.g. inside a building), position is estimated from the connected cell ID and neighbouring cell signal strengths. Accuracy depends on base-station density: about 100–300 m in urban areas, up to kilometres in suburbs. LBS results are for “which area, roughly” reference only, should be shown on the map with a large uncertainty circle, and must never be used for distance decisions — the other side of why the 10-metre decision is given to BLE.

Comparison of the Three Mechanisms

Mechanism	Typical accuracy	First fix	Works indoors	Role in this system
GNSS (GPS + BeiDou)	5–15 m	1–2 s (hot) / 30 s+ (cold)	No	Primary source; map position is based on this
A-GPS	Same as GNSS	Reduced to seconds	No	Accelerates first fix and re-acquisition
LBS cell positioning	100–1000 m	Immediate	Yes (coarse)	Area fallback when no satellite signal
BLE near-field decision	Threshold decision, not coordinates	Sub-second	Yes	10 m alarm only; produces no coordinates (Chapter 07)

GT06 Transport Link

Position data from terminal to cloud uses the GT06 family protocol: a binary TCP protocol used for many years in vehicle and personal locators. The reason for choosing it is practical — GPT60 outputs it natively and Traccar decodes it natively, with no protocol-conversion gateway in between.

Connection Model: TCP Long Connection + Heartbeat

After power-on and network registration, the terminal establishes a persistent TCP long connection to the agreed server port (shown here as <server address>:<GT06 port>) and keeps it alive. Position, heartbeat and status packets are multiplexed over this connection: one position frame every 5 seconds, heartbeats in gaps to maintain liveness and confirm the terminal is online. The long connection avoids per-frame setup latency and traffic, and lets the server detect disconnection immediately.

Figure 6-1 GT06 Location Frame Structure (Schematic)FIG. 6-1 · GT06 LOCATION FRAME (SCHEMATIC)

Frame structure is a principle-level schematic: field order and composition follow the public protocol documentation; exact byte definitions follow the protocol version and Traccar decoder used at deployment.

Link Reliability Handling

Acknowledgement: the server acknowledges login and some status frames; position frames use serial numbers to detect loss and reordering.
Reconnection: on disconnection the terminal automatically redials and reconnects, then resumes periodic reporting.
Weak-network behaviour: at 4G coverage edges frames may be delayed and arrive in bursts, appearing as “steps” on the map — a link characteristic, not a positioning error; the front end distinguishes them with track smoothing and timestamps.
Time base: position frames contain GNSS time; the server records tracks using frame time so network delay does not pollute the track timeline.

BLE 10-Metre Proximity Alarm

The alarm link is completely separate from the positioning link: it calculates no coordinates, passes through no server and depends on no network. The BLE beacon on the target side does one thing — broadcast its presence periodically. The receiving terminal does one thing — listen to that broadcast and measure its strength.

Figure 7-1 BLE Beacon Exploded ViewFIG. 7-1 · BLE BEACON, EXPLODED VIEW

Component Descriptions

① Top cover: round shell cover with an LED light point for low-battery and status indication; snap/rotary structure for battery replacement.
② PCB: BLE SoC and on-board antenna; firmware sets broadcast interval (typically a few hundred milliseconds) and transmit power — transmit power directly determines alarm distance and must be calibrated as a set with the receiver threshold.
③ CR2032 battery: 3 V coin cell; months of operation at low duty cycle. Exhaustion disables the alarm link, so it belongs on the pre-use checklist.
④ Bottom cover & hole: wear by cord or sew into a clothing compartment; avoid placing directly behind the torso — the body strongly attenuates 2.4 GHz signals.

Broadcast content contains only beacon identity and a transmit-power reference — the beacon itself does not know where it is.

Black-line sketch of a generic BLE iBeacon-class hardware form; internal layout of a specific purchased model follows the physical unit. The system depends only on its broadcast behaviour and calibrability.

Decision Principle: RSSI and Distance

Bluetooth signal strength (RSSI, in dBm) decays logarithmically with distance. The receiver continuously scans the target beacon, reads RSSI and compares it with a calibrated threshold: RSSI above the threshold (strong enough) means “within 10 metres”. Dual thresholds and sustained confirmation suppress boundary jitter: multiple consecutive scans over the threshold trigger the alarm, and multiple consecutive falls below clear it — avoiding repeated sounding at the 10-metre boundary.

Figure 7-2 RSSI–Distance Relationship and Alarm Threshold (Schematic)FIG. 7-2 · RSSI vs DISTANCE, SCHEMATIC

The curve is a principle schematic of the log-distance path-loss model (1 m reference −59 dBm is a common BLE factory nominal), not measured data. The real threshold must be calibrated on site per Chapter 12: at the same distance, RSSI for pocket, bag and lanyard wearing can differ by over 10 dB.

Why GPS Cannot Judge 10 Metres

Approach	Error magnitude	Decision latency	Conclusion
Two-ended GPS coordinate distance	Combined errors, worst > 20 m	≥ 5 s (reporting period)	Invalid Error exceeds the threshold itself
Server-calculated distance, alarm downloaded	Same as above, and receiver must report its own position	≥ 6–8 s	Invalid Also violates Principles 1 & 3
BLE local RSSI decision	Threshold decision (about ±2–3 m boundary blur after calibration)	< 1 s	Adopted Near-field signals are naturally sensitive to short distances

Receiving Terminal and OSM Map

The observer uses an ordinary Android phone as the receiving terminal, running a dedicated app. It handles two independent tasks: networked presentation of the target position (map), and BLE scanning alarm that also works offline.

Figure 8-1 Receiving Terminal (Android Phone), Front ViewFIG. 8-1 · RECEIVER HANDSET, FRONT VIEW

Components and Functions

① Earpiece / camera: the system does not use the camera or microphone (data minimisation); the earpiece is for ordinary calls only.
② Screen & alarm banner: main interface is the OSM map plus target marker; on alarm the top banner changes colour, with sound and vibration on three channels, including on the lock screen.
③ Power key: after screen-off the app continues scanning and receiving push as a background service — enable battery-optimisation exemption in system settings, otherwise domestic Android background freezing kills both links.
④ Volume keys: alarm volume follows media/ringtone settings; verify maximum volume is identifiable in the target environment noise at acceptance.
⑤ Speaker: alarm sound output; enable vibration as well to avoid missing alarms in noisy environments.
⑥ USB-C: charging and debugging; continuous scanning plus map rendering are the main power consumers — use a power bank for long sessions.

No special handset requirements: Android 8.0+, BLE 4.0+, mobile network. The sketch shows a generic slab-phone form.

Black-line sketch: solid lines are visible handset parts, thin lines inside the screen are schematic OSM roads, and red elements mark only the alarm banner and target marker.

Option 1: The Receiving Terminal Does Not Locate Itself

The current scheme (Option 1) is decisive: the receiving app does not request location permission, does not read its own GNSS and does not report any of its own coordinates to the server. The map centres on the target position (or a preset area centre), and the observer judges direction from familiarity with the environment. Three direct results follow:

Minimal permission surface: only network, Bluetooth scan and notifications — no location permission. On older Android versions Bluetooth scan was bound to location permission; use declarations such as neverForLocation for the target OS version.
Minimal server data surface: no receiver track exists in the database; a data leak exposes only the target side.
Self-consistent alarm logic: precisely because there are no receiver coordinates, the 10-metre decision can only be made locally by BLE — simpler architecture, lower latency, works offline.

Why OpenStreetMap

No real-name registration or key binding: OSM and open-source rendering libraries (flutter_map / osmdroid, etc.) need no commercial SDK real-name authentication or app-signature binding, so deployment friction is lowest.
Offline capable: tiles for the target area can be pre-downloaded and cached; the base map still displays when the network drops (position updates still need network — keep the two separate).
Self-hostable: a tile service can be self-built at larger scale, independent of third-party terms changes.
Cost: OSM road detail and update speed in some domestic areas lag commercial maps; the area here is small and fixed, so key paths can be checked and supplemented in advance.

Server Pipeline

The server runs on a single cloud VPS and is deliberately simple: one reverse proxy, one mature open-source positioning platform and one database. No custom protocol stack and no message queue — at one-to-one scale, every extra component adds operations and failure surface.

Figure 9-1 Server Host and VPS StackFIG. 9-1 · SERVER STACK, LINE DIAGRAM

Component Descriptions

① Host / VPS: a cloud VM is sufficient — 1–2 cores and about 2 GB memory cover this system's load; no provider or address is hard-coded on this page.
② Nginx: the sole external Web entry, terminating HTTPS, reverse-proxying to Traccar and controlling access to the management interface.
③ Traccar: open-source positioning platform handling GT06 decoding, device registration and authentication, position events, track-query API and Web management — the core of the server.
④ WebSocket push: Traccar's real-time channel; after the receiver subscribes, each reported frame refreshes the map in about 1 second (Chapter 03 timing).
⑤ Database: Traccar's embedded database is sufficient to start; track data is cleaned periodically per retention policy (Chapter 11).

Black-line sketch: the top is the host front panel, the bottom is the software stack inside the VPS; thin lines between components show request/data flow.

Data Pipeline (Journey of a Single Position Frame)

STEP 1AccessGT06 frame arrives over TCP at the Traccar protocol port; device identified by IMEI

STEP 2Validate & DecodeCRC check → field decoding → standard position object (lat/lon/time/speed)

STEP 3StorePosition object written to the database as a replayable track sequence

STEP 4DistributeWebSocket push to online subscribers; offline receivers fetch latest position and history on next open

STEP 5PresentReceiver updates marker, accuracy circle and “last updated N seconds ago” status

Management and data planes are separate: the Web management interface (device registration, accounts, track review) is exposed via Nginx + HTTPS with source restrictions; the GT06 access port handles protocol frames only and provides no management capability. The server takes no part in alarm decisions — alarm generation and presentation are entirely local to the receiver (Principle 2).

Latency, Error and Performance Analysis

Numbers in this chapter are of two kinds: inherent magnitudes determined by devices and protocols (accuracy, frame length, period), and design estimates (battery life, end-to-end latency). Estimates state their basis and should be replaced by acceptance measurements after deployment (Chapter 12).

End-to-End Latency Budget (Positioning Link)

Stage	Typical	Adverse conditions	Notes
Reporting-period wait	0–5 s (avg. 2.5 s)	5 s	Inherent: an event just after a frame must wait for the next frame
Fix computation	About 1 s	Cold start 30 s+	Periodic operation is hot starts; first power-on after long shutdown excepted
4G uplink + Internet	0.1–0.5 s	Seconds (weak-signal retransmission)	Strongly related to signal quality at the target's location
Server decode & store	< 0.1 s	< 0.5 s	Negligible at single-device load
WSS push + rendering	0.2–0.5 s	1–2 s (receiver on weak network)	Receiver network is independent of target network
Total (map freshness)	Typically ≤ 7 s	Adverse ≈ 12 s	UI must show “last updated” time so old positions are not mistaken for live ones

Alarm-link latency is calculated independently: BLE broadcast interval (hundreds of milliseconds) + receiver scan window + dual-threshold confirmation gives typically under 1 second from crossing the threshold to alarm, with no network involved — the fundamental reason safety-related decisions must be local.

Error Sources and Countermeasures

Error source	Impact	Magnitude	Countermeasure
Multipath reflection (between buildings)	GNSS drift and jumps	10–30 m	Track smoothing; draw the accuracy circle honestly; do not judge from a single point
Satellite geometry & shielding	Accuracy drops or fixes briefly unavailable	—	A-GPS assisted re-acquisition; LBS fallback marked low-confidence
Body shielding (BLE)	RSSI drops sharply when the beacon is behind the body	About −10 dB	Wear the beacon on the front / on a lanyard; calibrate conservatively across wearing styles
Environmental multipath (BLE)	RSSI jitter, blurred boundary	±6 dB class	Dual thresholds + multiple confirmations; accept about ±2–3 m alarm boundary blur
Receiver background frozen	Push and scanning stop together	Functional failure	Battery-optimisation exemption + foreground-service keep-alive + screen-off test at acceptance (Chapter 12)

Battery Estimate (Interactive Calculator)

GPT60's 600 mAh battery is the tightest resource in the system. Choose a reporting interval to see how estimated battery life and traffic change — this system is fixed at 5 seconds; the calculator is for understanding the trade-off:

Reporting Interval — Battery / Traffic Calculator

Estimation model (design estimate, not measured): each reporting event (fix + transmission) consumes about 0.55 mAh, idle current about 4 mA; one frame with protocol overhead about 120 B. Real battery life is strongly affected by signal strength and temperature; acceptance is by measurement.

Estimated battery life

—

Reports per hour

—

Daily traffic (continuous)

—

Max. blind distance in 5 min*

*Blind distance estimated at walking speed 1.4 m/s: how far the target can move between reports. It trades off against battery life — longer interval saves power but coarsens the track and makes the map “older”.

Security, Privacy and Compliance

Location data is among the most sensitive categories of personal data. The security goal is explicit: data flows only among three points — target terminal, self-owned server, authorised receiving terminal — and every hop is controllable, auditable and cuttable.

Transport and Access Security

TLS throughout for management and presentation: Nginx terminates HTTPS/WSS; certificate expiry is on the operations calendar; the management interface is source-restricted with strong passwords.
Device identity: GT06 identifies devices by IMEI; the server accepts connections only from registered IMEIs and drops frames from unregistered devices.
Protocol limitation (recorded honestly): GT06 is a plaintext protocol — frame content is not encrypted and IMEIs can be spoofed, a historical limitation of this mature protocol. This system accepts the risk on the premise of small area, short duration and limited data value. For highly sensitive future use, migrate to a terminal/protocol supporting TLS and mutual authentication; this is entered in the risk register.
Minimum port exposure: the firewall opens only necessary ports; database and Traccar management ports are not open to the public Internet (accessed via Nginx or internally).

Privacy Design (Corresponding to Principle 3)

One-way data surface: the receiver has zero positioning and zero reporting (Option 1), so no receiver track exists in the database.
BLE identifier rotation: beacon identifiers do not use a fixed public UUID combination that can be linked long-term, and should be changed per usage cycle to reduce third-party long-term tracking.
Retention period: track data is retained only briefly by default (set in days at deployment as needed), with automatic cleanup and logged export/deletion.
No third-party SDKs: the receiver app integrates no advertising, analytics or crash-reporting SDKs; map-tile requests are the only external data requests (further reduced by pre-caching area tiles).

Compliance Points

Informed consent: locating another person is legally and ethically sensitive. Before deployment, obtain the located person's explicit informed consent and limit purpose, time window and data scope. This system is positioned as a negotiated area-safety / guardianship technical solution and must not be used for non-consensual tracking.
Personal-information protection: tracks are sensitive personal information; processing should follow the Personal Information Protection Law requirements on separate consent, minimum necessity and security safeguards.
Map compliance: OSM data is open data (ODbL licence) — retain attribution. Its coordinates are WGS-84, different from the GCJ-02 offset system of domestic commercial maps; cross-source overlay requires coordinate conversion to avoid systematic offset misreading.
Radio and network access: terminals and beacons should be commercially available finished products with applicable type approval; this scheme involves no self-made RF transmitting equipment.

Deployment, Calibration and Acceptance

Deployment has four steps: server go-live, terminal activation, on-site calibration and acceptance testing. Calibration is the distinctive key step — there is no “factory default” for BLE alarm distance; the threshold can only be measured in the real environment.

Deployment Checklist

Server VPS online; Nginx + Traccar + database ready; HTTPS certificate valid; firewall on minimum-port policy; server address and ports recorded in the deployment configuration sheet (placeholder <server address>).
Device registration Register GPT60 by IMEI in Traccar; create the observer account and bind device visibility.
Terminal activation Insert the IoT SIM in GPT60; confirm server address/port point to the self-owned Traccar; set reporting interval to 5 seconds; verify satellite and network status by LED patterns.
Beacon pairing Record the beacon identifier in the receiver app's listening list; confirm and fix the transmit-power level (must not change after calibration).
Receiving terminal Install the app; grant Bluetooth and notification permissions; add battery-optimisation exemption; pre-cache OSM tiles for the target area.

BLE Threshold Calibration Procedure

Fixed-point sampling: at a typical open point in the deployment area, place the beacon in each real wearing style (lanyard / pocket / bag) at 5 m, 8 m, 10 m, 12 m and 15 m from the receiver, sampling RSSI for 60 seconds per point.
Choose a conservative threshold: between the strongest 10 m group and the weakest 12 m group, leaving a hysteresis band (trigger and release thresholds differ by about 4–6 dB).
Walk test: approach at walking speed from 25 m and check alarm triggering at the 10 m line; walk away to check release distance; repeat 5 times and record the trigger-distance distribution.
Occlusion re-test: add adverse postures — body turn (beacon behind the body), one-wall separation — and confirm the blur band is acceptable; record results in the calibration sheet.
Freeze parameters: calibrated transmit power, broadcast interval, dual thresholds and confirmation count are written to configuration and frozen; re-calibrate after changing beacon model, wearing style or main venue.

Acceptance Criteria

Item	Method	Pass criterion
Positioning accuracy	Static sampling at a known point for 5 minutes	90% of points within 15 m of the true point in open environments
Reporting continuity	Walk around the area (about 20 minutes)	No track gap over 30 s (except recorded signal blind spots)
Map freshness	Observe the UI update timestamp while the terminal moves	Typically ≤ 7 s, with correct last-update display
Alarm distance	10 walk tests after calibration	Trigger distance within 8–13 m in at least 9 tests
Alarm latency	From threshold crossing to sound/vibration/banner	< 1 s (local decision, no network)
Offline resilience	Walk-test the alarm with the server shut down	BLE alarm works fully; map resumes after recovery
Battery life	Full charge, 5-second reporting, run to auto power-off	≥ 5 hours (otherwise replace battery / terminal unit)
Screen-off survival	After 30 minutes screen-off, trigger a position update and an alarm	Push visible, alarm triggers, app not frozen by the system

Acceptance records should include: date, venue, participating device numbers (IMEI / beacon ID recorded in masked form), a snapshot of calibration parameters and each measured value. Failed items are categorised as “calibration / link / unit fault”, handled and re-tested.

↓

Technical Document Downloads

This page is the reading edition. The full technical documents are available as PDFs in both Chinese and English — including all black-line figures, frame-format appendices, deployment configuration sheets and the risk register.

ShadowTrace Positioning Alarm System · Technical Document

Full discussion of all chapters on this page, plus per-component black-line diagrams and description tables for GPT60 / BLE beacon / receiving terminal / server. Chinese edition: 22 pages. English edition: full translation, STAS-TECH-2026-001 EN.

Chinese 22 pagesEnglish Edition V1.0STAS-TECH-2026-001

Download English PDF Download Chinese PDF (中文版)

Deployment note: server addresses and ports on this site and in the documents are placeholders (<server address>:<port>), filled in from the delivered configuration sheet at deployment; no real address appears on the public page.