Pourquoi la Détection de Mouvement Appartient à Chaque Tag d’Actif

La plupart des déploiements de BLE tag suivent la localisation, mais la localisation seule ne dit pas si une palette a été dropped, une caisse s’est renversée, ou un instrument de haute valeur a vibré sur la plateforme d’un camion pendant six heures. Ajouter un accéléromètre au tag le transforme d’un beacon passif en un nœud sensor actif—capable de détecter les événements d’impact, de classer les patterns de mouvement, et de wake le MCU seulement quand quelque chose se produit réellement.

Le défi d’engineering n’est pas de choisir l’IC accéléromètre (c’est un exercise de spreadsheet). C’est de concevoir la chaîne d’interruptions, la logique de threshold d’impact, le budget de puissance, et le filtre de faux positifs—pour que le tag rapporte les événements réels sans drainer sa batterie ou flood le gateway avec du noise.

Cet article parcourt le chemin complet du signal : de la sélection du silicium aux algorithmes de détection, l’architecture d’interruptions, l’encodage des données, et la calibration—with des nombres réels à chaque étape.

Sélection d’IC Accéléromètre : Ce Qui Compte Vraiment

Les tags d’actifs low-power ne nécessitent pas d’IMUs 16-bit à 20 kHz. Ils nécessitent des accéléromètres 8–12-bit qui sleepent à <1 µA et se wake sur des thresholds programmables. Comparaison des ICs pertinents :

Paramètre ST LIS2DH12 ADI ADXL362 Bosch BMI270 TDK ICM-42670-P
Resolution 8/10/12-bit 12-bit 16-bit 16-bit
Plage (g) ±2/4/8/16 ±2/4/8 ±2/4/8/16 ±2/4/8/16
Current (actif) 5–11 µA 0.2 µA (motion) 4.8 µA 6.6 µA
Current (sleep) 0.5 µA 10 nA 3 µA 2 µA
Détection d’activité intégrée Oui (INT1/INT2) Oui (awake/inact) Oui (any-motion) Oui (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
Prix (1K) $0.58 $3.85 $1.20 $1.55

Pour les tags d’actifs, ST LIS2DH12 est la sélection pragmatique par défaut : modes programmables 8/10/12-bit, deux pins d’interruption, détection de click/double-click intégrée, et 0.5 µA standby. À $0.58 en quantité il affecte barely le BOM. L’ADXL362 avec 10 nA sleep est impressionnant, mais son interface SPI-only et le prix de $3.85 le font une sélection niche pour les designs ultra-low-power où le MCU sleep à sub-µA et ne peut tolérer même 0.5 µA de l’accéléromètre.

Critères de sélection que les datasheets ne soulignent rarely :

  • Granularité de threshold : LIS2DH12 threshold d’activité est 1 LSB = 16 mg à ±2 g / 12-bit. ADXL362 est 3.9 mg/LSB. Pour la détection d’impact à 1–2 g, les deux sont suffisants.
  • Latence d’interruption : La détection d’activité intégrée se fire en 1–3 périodes de sample. À 1 Hz sampling pour l’inactivité, c’est 1–3 secondes—pas assez rapide pour l’impact. Un path high-rate séparé est nécessaire.
  • Profondeur FIFO : LIS2DH12 a un FIFO de 32 samples. BMI270 a un FIFO de 128 samples. Les FIFOs plus grands permettent au MCU de burst-read les waveforms d’impact sans maintenir SPI actif pendant l’événement.

Modes de Détection de Mouvement et leurs Applications

Le firmware du BLE tag exécute typiquement trois modes de détection simultanément sur différents axes de threshold :

1. Activité / Inactivité (Détection de Présence)

Objectif : Détecter si l’actif taggé est stationnaire ou en transit. Cela drive le mode-switching—l’intervalle d’advertising baisse de 1000 ms à 100 ms quand l’actif se déplace.

Configuration LIS2DH12 :

  • Threshold d’activité : 0.5 g (32 mg/LSB × 16 ≈ 512 mg)
  • Durée d’activité : 1 sample à 1 Hz (trigger immédiat)
  • Threshold d’inactivité : 0.08 g
  • Durée d’inactivité : 30 samples à 1 Hz (30 secondes de quiet)

Impact sur la puissance : L’accéléromètre run à 1 Hz (5 µA) tandis que le MCU sleep. Quand l’activité se fire, le MCU se wake et switch le radio BLE en fast advertising.

2. Détection de Chute Libre

Objectif : Détecter les drops—palettes lifted par grue et released, instruments knocked off des benches.

La signature est tous trois axes near zero simultanément. Threshold de free-fall LIS2DH12 : set activité à ≤0.2 g sur tous les axes, duration ≥2 samples à 200 Hz (10 ms). À 200 Hz l’accéléromètre draw ~11 µA—acceptable seulement si la détection de free-fall est maintenue active pendant les fenêtres de handling connues.

Complication pratique : Un tag monté sur un coin de caisse expérience 0.6 g de gravity resting sur un axe en orientation normale. Quand la caisse tip, cet axe shift mais ne va pas à zero. Free-fall fonctionne seulement pour les objets qui deviennent truly airborne. Pour la plupart des scénarios logistiques, la détection d’impact est plus reliable.

3. Click Single / Double (Détection de Tap)

Objectif : Interaction utilisateur—double-tap pour confirmer le handoff d’actif, single-tap pour requester un ping de localisation.

La détection de click intégrée LIS2DH12 handle cela sans involvement du firmware :

  • Threshold de click : 1.2 g (plus haut que activité pour éviter les false triggers de vibration de truck)
  • Time limit de click : 80 ms (fenêtre pour un tap)
  • Latence double-click : 400 ms (temps entre premier et second tap)
  • Interruption sur INT1 pour single click, INT2 pour double click

Ce mode run à 400 Hz (~11 µA) seulement pendant une fenêtre de temps configurable (ex : premiers 30 secondes après un button press ou événement de proximity du gateway). Otherwise l’accéléromètre stay à 1 Hz.

Détection d’Impact : Le Vrai Problème d’Engineering

Les événements d’impact sont les plus difficiles à détecter reliably car ils share des caractéristiques spectrales avec la vibration, les door slams, et les forklift bumps. Le signal processing est simple—exceeder un threshold—mais la sélection de threshold et la logique de confirmation ne le sont pas.

Sélection de Threshold par Application

Scénario Peak Typique (g) Threshold Recommandé Fenêtre de Détection
Drop de paquet (30 cm, hard floor) 15–30 8 g 5 ms
Bump de palette (forklift) 3–6 2.5 g 50 ms
Vibration de truck (road) 0.5–1.5 1.5 g (avec confirmation) 100 ms
Tip-over d’instrument sur shelf 2–4 2 g 20 ms
Drop de laptop bag 10–20 6 g 10 ms

Insight clé : le threshold seul est insuffisant. Un bump de forklift à 4 g looks comme un drop de paquet pour un simple threshold detector. Des critères de confirmation sont nécessaires :

  • Confirmation de durée : Les événements d’impact plus courts que la fenêtre de détection sont ignorés. Un peak de 4 g lasting 2 ms est vibration ; un peak de 4 g lasting 40 ms est un bump.
  • Corrélation d’axes : Les impacts réels produisent des spikes corrélés sur plusieurs axes. La vibration random peak typiquement sur un axe (aligné avec la direction de vibration). Calculer mag = sqrt(x² + y² + z²) et requérir mag > threshold.
  • Fenêtre de quiet pre/post : Avant et après l’événement, requérir mag < 0.5 × threshold pour au moins 2 périodes de sample. Cela élimine les vibration trains où plusieurs peaks crossent le threshold en succession rapide.

Réduction des Faux Positifs

Chaque engineer de deployment a vu le même problème : un tag monté sur un doorframe de warehouse rapporte 300 "impacts" par jour car la door vibre quand les trucks passent. Stack de filtres en couches :

Couche 1 : Gate Magnitude + Durée

Requérir mag > threshold AND duration > min_window. Élimine 80% des faux positifs des peaks de vibration qui crossent le threshold mais ne sustain pas.

Couche 2 : Corrélation d'Axes

Calculer r = min(x, y, z) / max(x, y, z) au peak. Les impacts réels produisent r > 0.3. La vibration directional produit r < 0.15. Appliquer seulement pour les thresholds below 4 g—above 4 g, tout peak est presque certainly réel.

Couche 3 : Debounce Temporal

Après un impact confirmé, supprimer les détections ultérieures pendant un cooldown configurable (default : 60 secondes). Cela prévient un impact physique de générer 5 reports quand l'objet bounces. Ajuster le cooldown par application :

  • Instruments délicats : 5 secondes (catch chaque bounce)
  • Palettes industrielles : 120 secondes (un report per événement de handling)

Couche 4 : Gate de Contexte

Enable la détection d'impact seulement quand les conditions de contexte sont met :

  • Tag en transit (détection d'activité = moving)
  • Tag near zone de loading (gateway RSSI > −60 dBm)
  • Fenêtre de temps (détection d'impact seulement pendant les business hours)

Comparaison des Taux de Faux Positifs

Stack de Filtres Taux de True Positive Taux de False Positive (warehouse)
Threshold only 95% 30/jour
+ Gate de durée 93% 8/jour
+ Corrélation d'axes 90% 2/jour
+ Debounce temporal 88% 0.5/jour
+ Gate de contexte 85% <0.1/jour

Calibration : Faire que les Thresholds Match la Reality

Les thresholds de datasheet sont théoriques. Chaque tag réel nécessite une calibration per-unit :

  • Offset zero-g : LIS2DH12 spec permet ±40 mg per axe après mount PCB. Sur un tag CR2032-powered avec la battery directly au-dessus de l'accéléromètre, solder reflow et PCB flex peuvent shift les offsets à ±80 mg.
  • Erreur de sensibilité : ±1.5% à la plage ±2 g. À un threshold d'impact de 4 g, c'est ±60 mg d'uncertainty—not critical, mais affecte la accuracy de classification de severity.
  • Sensibilité cross-axis : Up to 1% (axe X respondant à input d'axe Y). Pour détection magnitude-based, negligible. Pour analyse per-axis, matters.

Procédure de Calibration Two-Point

Sur la ligne de production, calibrer chaque tag en deux orientations :

  1. Position level (tag flat sur granite plate) : Read tous trois axes. Expected : X=0, Y=0, Z=+1 g (ou −1 g selon orientation). Calculer offsets : offset_x = x_measured − 0, offset_y = y_measured − 0, offset_z = z_measured − 1.0.
  2. Position inverted (tag flipped) : Read axe Z again. Expected : Z = −1 g. Calculer sensitivity : sens_z = (z_level − z_inverted) / 2.0. Le ratio 1.0 / sens_z gives le scale correction factor.

Stocker offsets et scale factors en flash. Firmware runtime applique : x_corrected = (x_raw − offset_x) × scale_factor. Cela nécessite 12 bytes de flash (3 offsets + 3 scale factors comme float16) et réduit l'uncertainty de threshold de ±80 mg à ±5 mg—suffisant pour distinguer un bump de 2 g d'un bump de 2.5 g.

Checklist de Deployment

Avant de deployer des tags avec motion sensing en production :

  • Valider thresholds on-site : Monter des tags sur des assets réels dans l'environnement actual. Enregistrer 24 heures de raw data. Set thresholds à 2× le maximum background vibration peak.
  • Tester la variabilité de mounting : Essayer 5 positions de mounting différentes. Verify que la détection magnitude-based est consistent regardless de l'orientation.
  • Profiler le taux de faux positifs : Run pendant 7 jours avec detection logging mais sans reporting. Compter les faux positifs. Ajuster le filter stack jusqu'à FP rate < 1/jour.
  • Mesurer l'impact sur battery : Deployer 10 tags avec motion sensing enabled et 10 without. Comparer battery voltage après 30 jours. Target : différence < 5%.
  • Planifier les firmware updates : Thresholds et filter parameters doivent être GATT-writable. Deployer avec defaults conservatifs, puis tune remotely basé sur les data collected.
  • Documenter le mapping d'axes : Enregistrer quel axe d'accéléromètre map à quelle direction physique pour chaque configuration de mounting. Cela détermine la accuracy de classification de direction d'impact.

Le motion sensing sur les BLE tags n'est pas une feature qu'on bolt-on—c'est un pipeline de signal processing qui nécessite calibration, filtering et power management dès day one. Mais done correctement, il transforme un location beacon en un condition-monitoring sensor avec moins de 5% d'impact sur battery—et c'est un tradeoff que chaque asset-tracking engineer devrait take.