H2-3 · Power Budget First: Lifetime Is Not “Battery mAh ÷ Average Current”

A tag’s lifetime is governed by state occupancy, burst energy, retries under weak coverage, and battery reality (temperature, internal resistance, aging).

A tracking tag typically spends most of its life in deep sleep, but lifetime collapses when short bursts become frequent or unstable: a GNSS fix turns into repeated attempts under遮挡, a relay scan window stretches longer than planned, or a cellular attach retries under marginal signal. The energy budget must therefore be built around states + actions + failure probability.

Budget the tag in four layers (keeps the worksheet reusable across SKUs):

• Layer A — State occupancy: Sleep, Sense-only, Confirm, Locate, Uplink, Retry/Backoff. Each state contributes time per day.
• Layer B — Energy per action: “One motion event,” “one tamper event,” “one daily heartbeat,” “one GNSS fix attempt,” “one uplink session.”
• Layer C — Failure probability: fix success rate, discovery success rate, uplink success rate, average retries per event (bounded by policy).
• Layer D — Battery reality: usable capacity after derating, temperature-dependent internal resistance, aging/self-discharge reserve.

Practical requirement: log minimal counters (scan count, attach attempts, GNSS fix attempts, reset reason). They turn “battery died early” into a measurable root cause.

H2-4 · Power Path & Energy Management: Peak Handling Drives Stability and Lifetime

A robust tag is built around peak-safe power delivery, clean domain isolation, controlled buffer charging, and a brownout policy that prevents reboot storms.

Peak current is not a corner case in tracking tags—radios and GNSS introduce short, high-demand bursts that interact with battery internal resistance and cold temperature behavior. When the power path is not designed for burst delivery, the result is not only reduced lifetime, but also unstable sessions (attach/fix failures), and in the worst case, brownout → reboot → retry storms.

Write the power path as a controlled chain rather than a single rail:

• Energy source: battery (derated capacity + temperature constraints).
• Protection: reverse protection / transient clamps / inrush shaping (tag-side only).
• Buffer (optional): local storage to smooth bursts, with controlled charging to avoid wasting energy.
• Conversion: DC/DC and/or LDO selection by light-load overhead, burst response, and quiescent/leakage.
• Domain gating: separate always-on vs burst domains using load switches and sequencing.
• PG/reset + brownout policy: enforce safe turn-on and safe turn-off behavior under droop.

Reliability requirement: record minimum evidence for power-related failures (reset reason, PG drop events, minimum battery voltage, attach/fix failure counters). Without these, “battery died early” remains un-actionable.

H2-5 · Wake-up & Event Pipeline: Accel-Wake Needs a System, Not Just a Threshold

A reliable tag uses a multi-stage pipeline: low-power sensing → wake gating → MCU confirmation → locate/report → cooldown/backoff, with counters for field tuning.

An accelerometer wake trigger is often treated as a single threshold, but real deployments face vibration profiles, mounting variation, and temperature drift. A tag must therefore separate “possible motion” from “report-worthy motion” using a staged event pipeline. This keeps the always-on domain cheap while reserving expensive actions (GNSS, radio sessions) for confirmed events.

Common failure modes and why a single threshold fails:

• False triggers: transport vibration, handling shocks, mechanical resonance, periodic motion in vehicles.
• Missed triggers: slow motion, gentle tilt, soft packaging damping, low-amplitude movement when the tag is tightly mounted.
• Drift and variation: temperature drift, orientation differences, mounting stiffness, sensor offset and tolerance spread.

Practical strategies (tag-side):

• Multi-stage gating: keep the accelerometer in a low-power prefilter mode; wake MCU only when a windowed rule is met.
• Debounce + hysteresis: require consecutive hits (N-of-M), integrate over a time window, and use different enter/exit thresholds.
• Event merge + cooldown: merge bursts into one report and enforce a cooldown to prevent repeated wake/report storms.
• Bounded retries: if locate/report fails, enter backoff and cap attempts to protect the battery tail.

H2-6 · Positioning Stack on a Tag: GNSS Success Rate Dominates Both Accuracy and Energy

For tags, GNSS is mainly a decision problem: when to attempt, when to stop early, how to degrade under遮挡, and how antenna/noise constraints affect success rate.

Indoor or metal environments (warehouses, trailers, containers) often produce low satellite visibility and severe multipath. In this regime, the main enemy is not “GNSS spec accuracy,” but low fix success rate and the resulting retry energy. Improving the probability of a valid fix reduces both time-to-first-fix (TTFF) tail and battery drain.

GNSS concepts to include only at decision granularity:

• TTFF distribution: treat TTFF as a tail risk, not a single number; cold starts dominate when assistance is missing.
• Start modes: hot/warm/cold categories map directly to how often the tag can afford re-fixes.
• Fix cadence policy: event-driven (motion) vs time-driven (heartbeat), with explicit attempt budgets.
• Stop conditions: timeouts, low-signal early stop, and bounded attempts to prevent “fix storms.”

Field debug template: Symptom → possible causes → top evidence to check:

• TTFF too slow: cold starts too frequent / weak signal → check start_mode bucket, C/N0 bucket, TTFF distribution.
• Indoor no fix:遮挡/antenna zone compromised/noise coupling → check fix_success_rate, sat_count bucket, low-signal ratio.
• Fix jumps: multipath / edge-of-coverage solution → check position jump flag, quality tier, consecutive bad fixes.
• Energy too high: retry loops / no early-stop → check fix_attempts per event, gnss_on_time, early_stop_count.
• Worse during radio sessions: shared droop/noise → check min_vbat during GNSS, overlap counter.

Antenna and layout (abstract principles) affect success more than minor algorithm tweaks. Keep the antenna zone clean, preserve a stable reference/ground area, and separate it from switching converters and burst transmitters. This is not PCB-level detail; it is a placement and isolation rule that protects the fix probability.

H2-7 · Multi-Radio Strategy: A Scheduler Beats “Stuffing BLE + LoRa + Cellular”

Tag-side only: role separation, time-slicing, window mutual exclusion, bounded retries, and abstract coexistence principles (no protocol tutorials).

A tag can carry multiple radios for flexibility, but it cannot run them as independent features. In battery-powered tags, the dominant failure patterns are scheduling collisions (scan vs transmit), peak-current droop during bursts, and RF path coupling when antenna resources are shared. A practical design starts by assigning a single “best job” to each radio and then expressing everything as a deterministic schedule with explicit time budgets and fallback behavior.

Tag-side radio scheduling rules (keep them explicit):

• Time-slicing: only one radio window may be active at a time on shared resources (antenna, power, clocks).
• Priority: critical events outrank periodic heartbeats; queued pressure may override low-priority scans.
• Mutual exclusion: scanning windows (e.g., BLE scan) must not overlap with high-current TX bursts (cell/LoRa).
• Bounded attempts: registration/attach and repeated TX retries must be capped; failures trigger backoff/cooldown.
• Fallback: when a preferred link fails, degrade to the next-best link for the current event class.

H2-8 · Data Model & Reliability: Traceable, Replayable, and “No Critical Event Lost”

Tag-side only: event IDs, queue semantics, retry/ack/commit, offline buffering, minimal power-loss protection, and minimum diagnostic fields.

Connectivity is intermittent, and tags reboot or brown out under peak load. Reliability therefore cannot be “best effort.” A tag needs a small, deterministic data model that makes events traceable end-to-end, repeatable without duplication, and recoverable after power loss. The simplest robust approach is a bounded event queue backed by a ring log, where an event is only removed after a verified acknowledgment triggers a commit marker.

Tag-side semantics that make replay safe:

• Stable identifiers: each event carries event_id so retries resend the same identity (no new IDs on retry).
• Two-phase lifecycle: record then commit on ack; uncommitted events are replay candidates after reboot.
• Timestamp quality: record ts_source (RTC/GNSS/other) and a simple ts_quality tier for traceability.
• De-dup friendliness: include event_type, pos_source, and fail_code buckets so upstream can reason without large payloads.

Minimal offline buffering and power-loss tolerance (tag-side):

• Ring log: fixed-size circular storage; normal events may be overwritten, critical events are protected by priority or reserved pages.
• CRC + sequence: each record includes a small integrity check so reboot recovery can skip torn writes.
• Brownout-aware path: on early low-voltage detection, write only minimal metadata (event_id + reason + counter) and exit gracefully.
• Recovery scan: at boot, scan for records missing commit markers and re-enqueue them with their original IDs.

H2-9 · Security & Provisioning: “Encryption” Alone Does Not Stop Cloning

Tag-side only: identity, secure boot, key storage, signed payload fields, provisioning states, and audit-friendly evidence logs.

1) Root of trust and secure boot (action-level)

A tag must start from an immutable first stage (boot ROM or equivalent). Each stage verifies the next stage before execution. If verification fails, the device enters a restricted mode that preserves evidence and blocks sensitive operations that would amplify risk.

• Chain verification: ROM → verified bootloader → verified application.
• Anti-rollback: enforce a monotonic version/counter so older images cannot be booted after an update.
• Failure policy: on verify failure, deny OTA activation and emit a minimal diagnostic record.

2) Identity and key storage (unclonable in practice)

Device identity must separate what can be public (a device identifier) from what must remain secret (private keys). The most robust “anti-clone” pattern for tags is to keep private keys non-exportable and perform signing inside a protected boundary such as a secure element or TPM-like block.

• Key injection: provision keys into fixed slots at manufacturing or controlled enrollment.
• Key usage: sign critical payloads and attest boot state using the protected key slots.
• Key rotation/revoke: support replacement of operational keys without exposing old keys.

3) Provisioning states (factory → bound → transfer → retire)

“Binding” should be modeled as a state machine. Each state must define what actions are allowed, what is denied, and what evidence must be logged for audit and incident response.

4) Threat → control point → evidence (audit-friendly)

H2-10 · OTA & Fleet Operations (Tag-side): Scale Requires Gating + A/B + Rollback

Tag-side only: eligibility gating, resumable download, verify, stage to inactive slot, atomic swap, health confirm, and rollback with metrics.

Eligibility gating (upgrade allowed ≠ upgrade possible)

The primary brick-risk drivers are low battery, brownouts during staging/swap, and unstable radio windows during download. Eligibility checks should be evaluated before any high-cost step and re-evaluated before swap.

OTA flow in 6 steps (each step has a failure handler)

Brownout / weak-battery resilience (tag-side):

• Separate budgets: long-tail download vs short critical staging/swap window.
• Re-check before swap: gating is evaluated again right before reboot and atomic swap.
• Early low-voltage detection: exit staging cleanly; preserve progress and logs; avoid torn writes.