Warum Bewegungserfassung zu jedem Asset-Tag gehört
Die meisten BLE-Tag-Implementierungen tracken Standorte, aber Standort allein verrät nicht, ob eine Palette fallen gelassen wurde, ein Koffer kippte, oder ein hochwertiges Instrument sechs Stunden auf einer Lkw-Ladefläche vibrierte. Ein Accelerometer im Tag wandelt ihn von einem passiven Beacon in einen aktiven Sensorknoten—der Stoßereignisse erkennt, Bewegungsmuster klassifiziert, und den MCU nur dann aufweckt, wenn tatsächlich etwas passiert.
Die Engineering-Herausforderung liegt nicht in der Auswahl des Accelerometer-IC (das ist eine Spreadsheet-Aufgabe). Sie liegt in der Interrupt-Kette, der Stoß-Threshold-Logik, dem Power Budget und dem False-Positive-Filter—so dass der Tag echte Ereignisse meldet, ohne die Batterie zu entladen oder das Gateway mit Noise zu überfluten.
Dieser Artikel beschreibt den gesamten Signalpfad: von der Silizium-Auswahl über Detektionsalgorithmen, Interrupt-Architektur, Daten-Codierung und Kalibration—mit realen Zahlen auf jedem Schritt.
Accelerometer-IC-Auswahl: Was tatsächlich wichtig ist
Low-Power Asset-Tags brauchen keine 16-bit 20 kHz IMUs. Sie brauchen 8–12-bit Accelerometer, die bei <1 µA sleepen und bei programmierbaren Thresholds aufwachen. Vergleich der relevanten ICs:
| Parameter | ST LIS2DH12 | ADI ADXL362 | Bosch BMI270 | TDK ICM-42670-P |
|---|---|---|---|---|
| Auflösung | 8/10/12-bit | 12-bit | 16-bit | 16-bit |
| Bereich (g) | ±2/4/8/16 | ±2/4/8 | ±2/4/8/16 | ±2/4/8/16 |
| Strom (aktiv) | 5–11 µA | 0.2 µA (Motion) | 4.8 µA | 6.6 µA |
| Strom (Sleep) | 0.5 µA | 10 nA | 3 µA | 2 µA |
| Integrierte Aktivitätsdetektion | Ja (INT1/INT2) | Ja (awake/inact) | Ja (any-motion) | Ja (wake-on-motion) |
| Interface | SPI / I²C | SPI | SPI / I²C | SPI / I²C |
| Package | LGA 2×2×1 | LGA 3×3×1.05 | LGA 2.5×3×0.83 | LGA 2.5×3×0.76 |
| Preis (1K) | $0.58 | $3.85 | $1.20 | $1.55 |
Für Asset-Tags ist ST LIS2DH12 die pragmatische Default-Auswahl: programmierbare 8/10/12-bit-Modi, zwei Interrupt-Pins, integrierte Click/Double-Click-Detektion, und 0.5 µA Standby. Bei $0.58 in Stückzahl beeinflusst es den BOM kaum. Der ADXL362 mit 10 nA Sleep ist beeindruckend, aber sein SPI-only Interface und $3.85 Preis machen ihn zur Nische für Ultra-Low-Power-Designs, wo der MCU selbst bei sub-µA sleepet und 0.5 µA vom Accelerometer nicht toleriert werden kann.
Auswahlkriterien, dieDatasheets selten betonen:
- Threshold-Granularität: LIS2DH12 Aktivitätsthreshold ist 1 LSB = 16 mg bei ±2 g / 12-bit. ADXL362 ist 3.9 mg/LSB. Für Stoßdetektion bei 1–2 g sind beide ausreichend.
- Interrupt-Latenz: Die integrierte Aktivitätsdetektion feuert in 1–3 Sample-Perioden. Bei 1 Hz Sampling für Inaktivität sind das 1–3 Sekunden—zu langsam für Stoß. Ein separater High-Rate-Pfad ist nötig.
- FIFO-D Tiefe: LIS2DH12 hat 32-Sample FIFO. BMI270 hat 128-Sample FIFO. Größere FIFOs ermöglichen MCU Burst-Reads von Stoß-Wellenformen ohne SPI während des Ereignisses aktiv zu halten.
Bewegungsdetektionsmodi und ihre Einsatzbereiche
BLE-Tag-Firmware läuft typisch drei Detektionsmodi simultan auf verschiedenen Threshold-Achsen:
1. Aktivität / Inaktivität (Präsenzdetektion)
Zweck: Erkennen, ob das getaggte Asset stationär oder im Transport ist. Das steuert Mode-Switching—Advertising-Intervall sinkt von 1000 ms auf 100 ms, wenn das Asset sich bewegt.
LIS2DH12-Konfiguration:
- Aktivitätsthreshold: 0.5 g (32 mg/LSB × 16 ≈ 512 mg)
- Aktivitätsduration: 1 Sample bei 1 Hz (immediate Trigger)
- Inaktivitätsthreshold: 0.08 g
- Inaktivitätsduration: 30 Samples bei 1 Hz (30 Sekunden Ruhe)
Power-Auswirkung: Accelerometer läuft bei 1 Hz (5 µA), MCU sleepet. Wenn Aktivität feuert, wacht der MCU auf und switcht das BLE-Radio auf Fast-Advertising.
2. Freifall-Detektion
Zweck: Drops erkennen—Paletten von Kränen fallen gelassen, Instrumente von Benchs gefallen.
Das Signal ist alle drei Achsen gleichzeitig nahe Zero. LIS2DH12 Freifall-Threshold: Aktivität auf ≤0.2 g auf allen Achsen, Duration ≥2 Samples bei 200 Hz (10 ms). Bei 200 Hz zieht das Accelerometer ~11 µA—nur akzeptabel, wenn Freifall-Detektion während bekannter Handling-Fenster aktiv bleibt.
Praktische Komplikation: Ein Tag an einer Kante montiert erfährt 0.6 g Ruhegravity auf einer Achse. Wenn der Koffer kippt, shiftet diese Achse, geht aber nicht auf Zero. Freifall funktioniert nur für Objekte, die tatsächlich airborne werden. Für die meisten Logistik-Szenarien ist Stoßdetektion reliabler.
3. Single / Double Click (Tap-Detektion)
Zweck: User-Interaktion—Double-Tap für Asset-Handoff-Bestätigung, Single-Tap für Location-Ping-Request.
LIS2DH12 integrierte Click-Detektion handhabt dies ohne Firmware-Involvement:
- Click-Threshold: 1.2 g (höher als Aktivität, um False Triggers von Lkw-Vibration zu vermeiden)
- Click-Time-Limit: 80 ms (Fenster für einen Tap)
- Double-Click-Latenz: 400 ms (Zeit zwischen erstem und zweitem Tap)
- Interrupt auf INT1 für Single Click, INT2 für Double Click
Dieser Modus läuft bei 400 Hz (~11 µA) nur während eines konfigurierbaren Zeitfensters (z.B. erste 30 Sekunden nach Button-Press oder Gateway-Proximity-Event). Sonst bleibt das Accelerometer bei 1 Hz.
Stoßdetektion: Das eigentliche Engineering-Problem
Stoßereignisse sind am schwersten reliabel zu detektieren, weil sie spektrale Eigenschaften mit Vibration, Door-Slams und Forklift-Bumps teilen. Signal Processing ist simpel—Threshold exceeden—aber Threshold-Selektion und Bestätigungslogik sind es nicht.
Threshold-Selektion nach Anwendung
| Scenario | Typischer Peak (g) | Empfohlener Threshold | Detektionsfenster |
|---|---|---|---|
| Paket-Drop (30 cm, Hard-Floor) | 15–30 | 8 g | 5 ms |
| Palette-Bump (Forklift) | 3–6 | 2.5 g | 50 ms |
| Lkw-Vibration (Straße) | 0.5–1.5 | 1.5 g (mit Bestätigung) | 100 ms |
| Instrument-Tip-Over | 2–4 | 2 g | 20 ms |
| Laptop-Bag-Drop | 10–20 | 6 g | 10 ms |
Key Insight: Threshold allein ist insufficient. Ein Forklift-Bump bei 4 g sieht für einen einfachen Threshold-Detector wie ein Paket-Drop aus. Bestätigungskriterien sind nötig:
- Duration-Bestätigung: Stoßereignisse shorter als das Detektionsfenster werden ignoriert. Ein 4 g Peak lasting 2 ms ist Vibration; ein 4 g Peak lasting 40 ms ist ein Bump.
- Achsen-Korrelation: Echte Stoße produzieren korrelierte Spikes auf mehreren Achsen. Random Vibration peakt typisch auf einer Achse (aligned mit Vibrationsrichtung).
mag = sqrt(x² + y² + z²)berechnen undmag > thresholdfordern. - Pre/post-quiet-Fenster: Vor und nach dem Ereignis
mag < 0.5 × thresholdfür mindestens 2 Sample-Perioden fordern. Eliminiert Vibration-Trains mit mehreren Peaks, die den Threshold in rapid succession crossen.
False-Positive-Reduktion
Jeder Deployment-Engineer hat das gleiche Problem gesehen: ein Tag an einem Warehouse-Doorframe meldet 300 "Stöße" pro Tag, weil die Door vibriert, wenn Lkw passieren. Layered Filter-Stack:
Layer 1: Magnitude + Duration Gate
mag > threshold AND duration > min_window fordern. Eliminiert 80% der False Positives von Vibrations-Peaks, die den Threshold crossen, aber nicht sustainen.
Layer 2: Achsen-Korrelation
r = min(x, y, z) / max(x, y, z) am Peak berechnen. Echte Stoße produzieren r > 0.3. Directional Vibration produziert r < 0.15. Nur für Thresholds below 4 g anwenden—above 4 g ist jeder Peak fast certainly echt.
Layer 3: Temporal Debounce
Nach einem bestätigten Stoß, weitere Detektionen während eines konfigurierbaren Cooldown (Default: 60 Sekunden) supprimieren. Verhindert, dass ein physischer Stoß 5 Reports generiert, wenn das Objekt bounced. Cooldown nach Anwendung anpassen:
- Delikate Instrumente: 5 Sekunden (jeden Bounce catchen)
- Industrie-Paletten: 120 Sekunden (ein Report per Handling-Event)
Layer 4: Context Gate
Stoßdetektion nur enable, wenn Context-Bedingungen erfüllt sind:
- Tag im Transit (Aktivitätsdetektion = moving)
- Tag near Loading-Zone (Gateway RSSI > −60 dBm)
- Zeitfenster (Stoßdetektion nur während Business-Hours)
False-Positive-Rate-Vergleich
| Filter-Stack | True-Positive-Rate | False-Positive-Rate (Warehouse) |
|---|---|---|
| Threshold only | 95% | 30/Tag |
| + Duration Gate | 93% | 8/Tag |
| + Achsen-Korrelation | 90% | 2/Tag |
| + Temporal Debounce | 88% | 0.5/Tag |
| + Context Gate | 85% | <0.1/Tag |
Kalibration: Thresholds an Reality anpassen
Datasheet-Thresholds sind theoretisch. Jeder realer Tag benötigt Per-Unit-Kalibration:
- Zero-g-Offset: LIS2DH12 Spec erlaubt ±40 mg per Achse nach PCB-Mount. Auf einem CR2032-Tag mit Battery direkt über dem Accelerometer können Solder-Reflow und PCB-Flex Offsets auf ±80 mg shiften.
- Sensitivitäts-Error: ±1.5% bei ±2 g Range. Bei einem 4 g Stoß-Threshold ist das ±60 mg Uncertainty—not critical, aber beeinflusst Severity-Classification-Accuracy.
- Cross-Axis-Sensitivität: Bis zu 1% (Achse X respondiert auf Achse Y-Input). Für Magnitude-basierte Detektion negligible. Für Per-Achse-Analyse relevant.
Two-Point-Kalibration-Prozedur
In der Produktionslinie, jeden Tag in zwei Orientierungen kalibrieren:
- Level-Position (Tag flat auf Granite-Plate): Alle drei Achsen lesen. Expected: X=0, Y=0, Z=+1 g (oder −1 g je nach Orientierung). Offsets berechnen:
offset_x = x_measured − 0,offset_y = y_measured − 0,offset_z = z_measured − 1.0. - Inverted-Position (Tag geflippt): Z-Achse erneut lesen. Expected: Z = −1 g. Sensitivity berechnen:
sens_z = (z_level − z_inverted) / 2.0. Ratio1.0 / sens_zergibt den Scale-Correction-Factor.
Offsets und Scale Factors im Flash speichern. Runtime-Firmware applikiert: x_corrected = (x_raw − offset_x) × scale_factor. Das benötigt 12 Bytes Flash (3 Offsets + 3 Scale Factors als float16) und reduziert Threshold-Uncertainty von ±80 mg auf ±5 mg—ausreichend, um einen 2 g Bump von einem 2.5 g Bump zu unterscheiden.
Deployment-Checkliste
Bevor Motion-Sensing-Tags in Produktion deployt werden:
- Thresholds on-site validieren: Tags auf realen Assets im actual Environment mounten. 24 Stunden Raw-Data aufzeichnen. Thresholds auf 2× den maximalen Background-Vibration-Peak setzen.
- Mounting-Variabilität testen: 5 verschiedene Mounting-Positions probieren. Verify, dass Magnitude-basierte Detektion konsistent ist regardless der Orientierung.
- False-Positive-Rate profilieren: 7 Tage mit Detection-Logging aber ohne Reporting laufen. False Positives zählen. Filter-Stack adjustieren bis FP Rate < 1/Tag.
- Battery-Impact messen: 10 Tags mit Motion Sensing enabled und 10 ohne deployen. Battery-Voltage nach 30 Tagen vergleichen. Target: Differenz < 5%.
- Firmware-Updates planen: Thresholds und Filter-Parameter müssen GATT-writable sein. Mit konservativen Defaults deployen, dann remote tunen basierend auf collected Data.
- Achsen-Mapping dokumentieren: Für jede Mounting-Konfiguration aufzeichnen, welche Accelerometer-Achse zu welcher physischen Richtung mapt. Dies bestimmt Impact-Direction-Classification-Accuracy.
Motion Sensing auf BLE-Tags ist keine Feature, die man bolt-on—an Day One braucht es Kalibration, Filtering und Power Management. Aber korrekt implementiert, transformiert es einen Location-Beacon in einen Condition-Monitoring-Sensor mit unter 5% Battery-Impact—und das ist ein Tradeoff, den jeder Asset-Tracking-Engineer nehmen sollte.