La plupart des BLE Tag sont soit des emetteurs purs (un localisateur qui n’ecoute jamais), soit des scanners continus (une balise qui doit entendre le ping de la passerelle). L’emetteur pur est invisible aux commandes centralisees; le scanner vide une pile bouton en quelques semaines. Cet article traite du compromis : rendre la balise joignable a la demande tout en gardant le courant moyen dans les microamperes faibles.

Le probleme de la joignabilite

Un BLE Tag qui n’emet que des advertissements ne peut pas etre paged. Si vous voulez “retrouver cet actif precis maintenant” ou pousser une configuration, la passerelle n’a personne a qui parler. La solution naive est de faire scanner la balise en continu :

  • Courant RX sur un SoC type (nRF52840, nRF5340) : 4-8 mA
  • Une CR2032 avec ~220 mAh utilisables : 220 / 8 environ 27 heures

Inacceptable. L’ecoute continue transforme une balise de plusieurs annees en balise d’un jour.

Trois strategies d’ecoute

Strategie Courant ecoute Latence atteinte Cout annuel batterie*
Scan continu 5-8 mA ~10 ms vide en jours
Scan periodique (duty-cycled) 200-400 uA moyen un intervalle (ex. 2 s) mois
Radio reveil (WuR) 50-200 nA symbole wake + boot (~5-50 ms) annees

*CR2032, base d’emission idle 5 uA ajoutee.

Le scan periodique echange latence contre courant : ouvre une fenetre RX de W ms toutes les T ms. Courant moyen d’ecoute environ I_rx * W / T. Avec W=100 ms, T=2000 ms, I_rx=5 mA : moyen environ 250 uA. Ajoutez la base et vous etes a ~300 uA – quelques mois de vie, loin des annees d’un emetteur pur.

Recepteurs de reveil

Une radio wake-up est un second recepteur ultra basse conso accorde sur un symbole wake dedie. Il ecoute presque en continu a 50-200 nA et, en detectant un motif valide, alimente la radio BLE principale. Comme la radio principale ne tourne qu’apres un evenement wake, son courant RX de 5 mA est reparti sur de rares evenements.

Implementations WuR pour balises de classe BLE :

  • WuR Sub-GHz OOK/ASK (ex. 433 MHz, 868 MHz) : longue portee, bon marche, PHY proprietaire. La passerelle reveille toutes les balises a portee ; chacune valide un jeton avant le boot BLE.
  • Inductif 125 kHz : tres courte portee (cm-m), bon pour lecteurs “tape pour reveiller”, immunise contre l’encombrement 2.4 GHz.
  • Sniff de preambule en bande : certains SoC sniffent le preambule BLE a basse conso ; pas un vrai WuR mais moins cher que le RX complet.
  • IC WuR dedie : puce independante en 2.4 GHz donnant une interruption au SoC ; ecoute totale ~100 nA.

Il n’y a pas de wake-up BLE standard ; chaque fabricant le fait en proprietaire. Prevoyez une passerelle qui parle votre PHY WuR.

Calcul de latence

Paging sans connexion : latence max = periode fenetre wake T. Si la passerelle emet le symbole wake L ms et le WuR echantillonne toutes les S ms, une balise repond en S + boot. Avec S=100 ms et boot BLE 20 ms, pire cas ~120 ms.

Oriente connexion (la passerelle connecte ensuite) : ajoute etablissement de connexion (~30-80 ms) et decouverte GATT si non cachee. Budget ~150-250 ms de bout en bout.

Une balise a scan periodique a le pire pire cas : elle peut rater la fenetre de paging de la passerelle et attendre un intervalle T complet. A T=2 s cela fait jusqu’a 2 s de latence – correct pour “localiser un actif” mais mauvais pour un usage interactif.

Exemple de budget puissance

Une balise paged 10 fois/jour, chaque wake bootant BLE 200 ms a 5 mA :

  • Ecoute WuR : 100 nA * 86400 s = 8,64 mC/jour
  • 10 wakes * 200 ms * 5 mA = 10 mC/jour
  • Base emission 5 uA * 86400 = 432 mC/jour
  • Total environ 451 mC/jour -> CR2032 (220 mAh = 792000 mC) -> ~4,8 ans

Le courant d’ecoute WuR est une erreur d’arrondi. C’est tout le point.

Esquisse d’implementation

<h1>pseudo : nRF reveille par interruption depuis IC WuR</h1>

def on_wake_interrupt():
ble.power_on()
ble.advertise_wake_token(signed_token)   # prouve que c'est un page reel
if gateway.connected:
handle_command()
ble.power_off()

<h1>RTC planifie un scan periodique de repli si WuR echoue</h1>

rtc.every(3600s, short_scan, window_ms=50)

Le jeton wake signe compte : sans lui, un attaquant avec emetteur WuR peut reveiller toutes les balises a portee en continu et vider la flotte (attaque denial-of-sleep).

Note securite

Un symbole wake non authentifie est un primitif DoS de batterie. Exigez un jeton authentifie et protege contre le replay (ex. HMAC avec cle par balise + compteur tournant). Une balise qui ne peut pas verifier le jeton doit rester endormie. Aussi limitez le debit : ignorez un second wake dans N secondes pour attenuer une boucle jam-and-drain.

Quand utiliser une balise WuR

  • Vous devez pager des actifs precis (“montre-moi ou est la palette X maintenant”).
  • Les balises dorment des annees entre contacts (chaines du froid, actifs statiques).
  • La densite de passerelles est faible et vous ne pouvez pas payer une couverture continue par balise.

Omettez-la si la balise est un emetteur pur deja couvert par des passerelles fixes, ou si une latence sous ~100 ms est obligatoire (alors gardez un petit scan periodique).

En bref

Un BLE Tag n’a pas a choisir entre “jamais joignable” et “batterie morte en une semaine”. Un recepteur wake-up deplace le cout d’ecoute de milliamperes a nanoamperes, et un scan periodique est le compromis pragmatique sans PHY WuR. Dimensionnez fenetre et intervalle wake selon votre budget de latence, authentifiez le wake, et la balise reste joignable des annees.