Bluetooth Tracker Coexistence: Test Discovery Separately from Connected Communication | 蓝牙防丢器无线共存：将设备发现与连接通信分开验证

ENGLISH ARTICLE

Bluetooth Tracker Coexistence: Test Discovery Separately from Connected Communication

A tracker that connects on a quiet bench has not yet demonstrated reliable discovery in a busy radio environment. Understand where adaptive frequency hopping applies, then build separate discovery and connected-communication tests for an OEM or embedded tracking project.

1. Shared spectrum is a test condition, not a product defect diagnosis

Bluetooth operates in the 2.4 GHz ISM band, which is also used by 2.4 GHz Wi-Fi and other wireless technologies. If transmissions overlap in time and frequency, packets can be corrupted or lost. Bluetooth includes mechanisms to reduce collisions and compensate for packet loss, but these mechanisms should not be presented as a guarantee of interference-free operation. [1]

For a tracker project, record the radio environment alongside the product configuration. A failed interaction in one busy room does not identify the root cause by itself. Conversely, one successful connection beside a development computer is not sufficient evidence for a broad reliability claim. Keep observed behaviour separate from the explanation that still needs to be investigated.

2. Adaptive frequency hopping does not describe every discovery step

The Bluetooth LE primer describes 40 radio channels. Connected LE-ACL communication can use the 37 general-purpose channels, with a channel map identifying which are available for selection. Adaptive frequency hopping changes the selected channel across connection events, and the map can be updated to avoid poorly performing channels. The three primary advertising channels are distinct from those used for LE-ACL connection data. [2]

Legacy advertising uses primary advertising channels 37, 38 and 39. Extended advertising uses primary channels and can also carry data on general-purpose channels. Therefore, do not take a statement about hopping in an established connection and apply it unchanged to every advertising or scanning operation. Record the actual advertising mode and supported platform behaviour before defining a discovery test. These general Bluetooth mechanisms do not establish which features any particular tracker implements. [2]

3. Build two acceptance records instead of one pass/fail result

For discovery, define the starting state, the phone's supported scan or setup workflow, the accessory's advertising state and the observation that counts as discovery. Record time to discovery where it is observable, as well as trials that reach a pre-agreed timeout. Use the same timeout definition across trials; do not silently discard unsuccessful attempts. These are proposed internal test measures, not universal platform certification thresholds.

For connected communication, begin only after the connection is confirmed. Record the supported operation, its completion result, any disconnect and the recovery outcome. A command-completion observation and a packet-level measurement are different kinds of evidence; label them accurately. Likewise, do not treat an application screen change as proof of a particular radio packet exchange without supporting instrumentation.

4. Change one condition at a time and preserve the evidence

A practical internal matrix can compare a quiet baseline with normal, authorised 2.4 GHz Wi-Fi traffic on equipment under the test team's control. Keep the tracker, phone, firmware, battery state, distance and orientation fixed before changing the traffic condition. Then repeat across documented carrying positions or enclosure variants. Do not create disruptive interference on public or third-party networks.

Record the traffic setup and what was actually measured. The presence of a nearby router alone is not a measurement of channel occupancy. If spectrum monitoring or packet capture is unavailable, state that limitation. Keep sample counts, timeout events and failed trials with the successful results. Select numerical acceptance limits for the specific product and use case before testing rather than borrowing an unexplained number from another design.

5. Turn coexistence findings into a clear OEM handoff

Stellarrisetech publicly describes ready-to-brand OEM trackers, custom ODM development and embedded tracking solutions. Those routes provide a context for agreeing on product configuration, validation scope and manufacturing handoff. They do not, by themselves, prove a particular radio-performance result or platform certification. [3]

An actionable handoff identifies the supported ecosystem, discovery workflow, connected operations, hardware and firmware revisions, test environment, acceptance criteria and known limitations. Keep the wording consistent across the product brief, test report and user guidance. The useful claim is performance demonstrated under stated conditions, not that adaptive frequency hopping makes a tracker work everywhere.

中文文章

蓝牙防丢器无线共存：将设备发现与连接通信分开验证

防丢器在安静的台架环境中能够连接，并不代表它已证明在繁忙无线环境下能被可靠发现。先理解自适应跳频的适用环节，再为 OEM 或嵌入式追踪项目分别建立设备发现与连接通信测试。

1. 共享频谱是测试条件，不是产品故障的直接诊断

蓝牙工作在 2.4 GHz ISM 频段，该频段也被 2.4 GHz Wi-Fi 及其他无线技术使用。当传输在时间和频率上重叠时，数据包可能损坏或丢失。蓝牙包含降低碰撞概率并补偿丢包的机制，但这些机制不应被宣传为完全不受干扰的保证。[1]

对于防丢器项目，应在记录产品配置的同时记录无线环境。繁忙房间里的一次交互失败，本身不能确定根本原因。反过来，在开发电脑旁成功连接一次，也不足以支持宽泛的可靠性承诺。应把已经观察到的行为与仍需调查的原因分开。

2. 自适应跳频并不代表所有设备发现环节

Bluetooth LE 入门指南介绍了 40 个无线电信道。已连接的 LE-ACL 通信可使用其中 37 个通用信道，并通过信道映射表标记哪些信道可供选择。自适应跳频会在连接事件之间改变所选信道，也可通过更新映射表避开表现较差的信道。三个主广播信道与 LE-ACL 连接数据所使用的信道不同。[2]

传统广播使用编号为 37、38 和 39 的主广播信道。扩展广播使用主广播信道，也可在通用信道上传输数据。因此，不能把已建立连接中的跳频描述原样套用到所有广播或扫描操作。定义设备发现测试前，应记录实际广播模式及受支持的平台行为。这些通用蓝牙机制并不能证明某一款防丢器实现了哪些特性。[2]

3. 建立两类验收记录，而不是只有一个通过或失败结果

对于设备发现，应明确起始状态、手机受支持的扫描或设置流程、配件广播状态，以及什么观察结果才算发现成功。在可观察的情况下记录发现耗时，同时记录达到预先约定超时条件的试验。所有试验应使用一致的超时定义，不要悄悄剔除未成功的尝试。这些是建议的内部测试指标，并非通用的平台认证门槛。

对于连接通信，应在确认连接建立后再开始测试。记录受支持的操作、完成结果、是否断开连接及恢复结果。指令完成的观察记录与数据包级测量属于不同证据，应准确标注。同样，没有相应测量手段支持时，不应把应用界面的变化直接当成某一次无线数据包交换的证明。

4. 每次改变一个条件，并保留测试证据

实用的内部测试矩阵，可以对比安静基线与测试团队可控设备上正常、经过授权的 2.4 GHz Wi-Fi 业务流量。改变流量条件前，应固定防丢器、手机、固件、电池状态、距离和朝向，再针对有记录的携带位置或不同外壳方案重复测试。不要对公共网络或第三方网络制造破坏性干扰。

应记录流量设置以及实际测量了什么。附近有一台路由器，本身并不等于已经测量了信道占用情况。如果没有频谱监测或数据包抓取条件，应明确说明这一限制。样本数量、超时事件和失败试验应与成功结果一并保留。数值验收门槛应在测试前依据具体产品和使用场景确定，而不是从其他设计中借用一个无法解释的数字。

5. 将无线共存测试结果转化为清晰的 OEM 交接要求

Stellarrisetech 官网公开介绍了可定牌 OEM 防丢器、ODM 定制开发和嵌入式追踪方案。这些路线适合用于约定产品配置、验证范围和生产交接要求，但服务介绍本身并不能证明某项无线性能结果或平台认证状态。[3]

可执行的交接文件应明确支持的生态、设备发现流程、连接后的操作、硬件与固件版本、测试环境、验收标准和已知限制。产品需求、测试报告和用户指引应保持表述一致。有价值的承诺，是在明确条件下已验证的性能，而不是宣称自适应跳频让防丢器在任何地方都能工作。

Public sources / 公开资料

1. Bluetooth SIG — Bluetooth reliability
2. Bluetooth SIG — The Bluetooth Low Energy primer
3. Stellarrisetech — OEM, ODM and embedded tracking services

Public documentation checked on 17 October 2026. Independently written guidance; internal test suggestions are not platform certification requirements. No model-specific performance or certification is claimed.
公开资料核对日期：2026 年 10 月 17 日。本文独立撰写；内部测试建议并非平台认证要求，未宣称任何具体型号的性能或认证状态。