IoT-Link · LevelStream · Note technique
Sur les 4 différences de comportement rencontrées lors de la migration M8S → M10S, 3 sont résolues et déjà intégrées au firmware M10. La 4ᵉ — le network survey 2G, qui alimente le positionnement par cellules — est confirmée cassée sur M10 en l'état du firmware, mais le mécanisme de contournement est désormais connu et démontré.
Le point dur : le firmware lance AT+UCFSCAN=0 (scan 2G) quand la sonde est rabattue sur la 2G. Sur M10, cette commande échoue (CME error) tant que le URAT n'a pas été forcé sur 9 (2G seule) avec un cycle radio CFUN. Le repli automatique sur la 2G ne suffit pas. Le correctif est possible mais coûteux (plusieurs redémarrages radio sur une sonde sur batterie) et comporte un risque de blocage en 2G à maîtriser — ou à remplacer par CellLocate (+ULOC), à évaluer (dernier volet).
| Point | Constat | État firmware M10 (master) |
|---|---|---|
| TIMEPULSE — safeboot | la broche doit être NOPULL | ✓ Résolu PB15 en entrée NOPULL (acté au changelog) |
| Baud TXD_GNSS | 9600 (M8) → 38400 (M10), non documenté | ✓ Résolu USART3 = 38400, buffer GNSS élargi |
| Trames NMEA | désactivées par défaut sur M10 | ✓ Résolu réactivées (UGGGA=1, UGRMC=1, UGGSA=1) |
| Network survey 2G | voir détail ci-dessous | ⚠ Cassé — réparable |
Les points 1 à 3 ne sont pas des actions à mener : ce sont des confirmations a posteriori de corrections déjà appliquées pendant la migration. Le firmware M10 est aligné sur les recommandations constructeur sur ces trois points.
Le survey n'intervient qu'en repli, quand le GPS échoue (timeout), à certains événements (démarrage, arrêt de mouvement). Il choisit la commande selon le réseau courant (lu via +COPS) :
AT+UCFSCAN=7AT+UCFSCAN=0Banc — cartes M10 « 059 » et « 162 » · 23/02/2026
Carte connectée en 2G EGPRS par repli automatique (+COPS: 0,0,"Proximus",3) :
AT+UCFSCAN=0 → CME ERRORAT+UCFSCAN=7 (LTE) → OK — 4 cellsAnalyse : sur M10S, URAT autorisés = 7, 8, 9 ; URAT=0 (GSM) interdit ; or UCFSCAN=0 scanne la bande GSM, désactivée → CME error.
FAE Trasna / Batenburg · fin mai 2026
AT+UCFSCAN=2 = WCDMA/UMTS (3G), non supporté.AT+URAT=9 puis AT+UCFSCAN=0 ramène les cellules.Séquence démontrée (log à l'appui) ci-dessous.
# Démo Richard — module SARA-R422M10S-01B-02 AT+CFUN=0 ; AT+URAT=9 ; AT+CFUN=16 AT+COPS? → +COPS: 1,0,"vodafone NL",3 AT+UCFSCAN=0 → 6 cellules ramenées, OK
La différence entre l'échec de Damien et le succès de Richard tient à l'état du URAT : Damien était en URAT automatique (7,8,9), simple repli 2G → le scan GSM est refusé ; Richard a forcé URAT=9 seul + reboot radio → la 2G devient le RAT actif → le scan GSM est autorisé.
Le survey 2G sur M10 exige de forcer URAT=9 + cycle CFUN avant UCFSCAN=0. Le firmware ne le fait pas aujourd'hui → le survey 2G est non fonctionnel sur M10.
AT+CFUN=0 ; AT+URAT=9 ; AT+CFUN=16 (forcer 2G seule + reboot) AT+UCFSCAN=0 (scan 2G — fonctionne) AT+CFUN=0 ; AT+URAT=7,8,9 ; AT+CFUN=16 (restaurer le mode auto)
URAT & risque de blocage 2GConstats issus du code :
modemStop → AT+CFUN=10 puis coupure d'alimentation ; modemStart au réveil suivant).URAT : il s'appuie sur la valeur stockée en NVM du module, donc persistante (elle survit à la coupure d'alimentation).URAT stocké. Avec URAT=7,8,9, le module re-tente le LTE-M en priorité → le retour 2G→LTE-M se fait naturellement au réveil suivant, sans bascule « en cours de route ».URAT=9 forcé, on est verrouillé en 2G (LTE-M retiré de la liste) — c'est voulu, le temps du scan.Si le firmware force URAT=9 et ne restaure pas, la valeur persiste en NVM → sonde bloquée en 2G à tous les réveils, indéfiniment.
Pire : si la sonde reset entre le forçage et la restauration (watchdog, glitch, crash), elle reste figée sur URAT=9. Comme le firmware ne normalise jamais le URAT au démarrage, rien ne l'en sort toute seule.
1. Normaliser URAT=7,8,9 à chaque démarrage du modem (séquence d'init) → auto-réparation même après un crash en plein survey.
2. Ne faire la danse URAT=9 + CFUN qu'en exception scopée, la plus courte possible, autour du seul UCFSCAN=0.
Coût : chaque changement de URAT = un reset radio + un ré-attachement réseau (10–60 s). Un cycle de survey 2G enchaîne ~3 attachements, là où le M8 scannait « gratuitement ». Arbitrage conso à poser — par ex. ne déclencher la danse 2G que s'il n'y a vraiment pas de LTE-M.
Le message statut porte soit une position GNSS (GpsData), soit jusqu'à 6 cellules (CellsData : MCC / MNC / LAC / Cell ID / puissance) + RadioAccessTechnology (2 = 2G, 4 = 4G).
Logique : GPS d'abord ; si échec, survey cellulaire → cellules envoyées → trilatération via API côté base de données. Les 6 cellules ne sont remplies que par le survey.
Seuls les messages qui tentent une acquisition exécutent un survey (démarrage firmware, arrêt de mouvement). Les messages périodiques et les alarmes ne localisent pas : ils ré-émettent la dernière position connue. Conséquence directe : pas de survey + pas de fix GPS = aucune position pour cette acquisition (et donc rien à ré-émettre ensuite).
Export StatusMessages · juillet 2025 → mai 2026 · 100 sondes enregistrées (31 ayant émis sur la période) · 7 181 messages.
Sur ces sondes fixes (citernes), la seule occasion où un survey est réellement exécuté est le démarrage firmware (il n'y a pas d'arrêt de mouvement). Les périodiques et alarmes ré-émettent la dernière position. Les chiffres ci-dessous portent donc sur les vraies acquisitions, pas sur le total des messages — sinon les échos périodiques fausseraient les proportions.
| Sur les vraies acquisitions (démarrage firmware) | Valeur |
|---|---|
| Acquisitions réelles (survey exécuté) | 195 |
| → sans fix GPS → repli cellulaire | 56 (28,7 %) |
| dont survey 2G | 31 acquisitions · 9 sondes |
| dont survey 4G (LTE-M) | 25 acquisitions |
| GPS KO + aucune cellule (échec total) | 0 |
Côté flotte : 15 sondes sur 31 ont obtenu leur position par cellules au démarrage, dont 9 via un survey 2G. Ces surveys réussis alimentent ensuite les milliers de messages périodiques qui ré-émettent la position (≈ 1 378 messages périodiques portant une position 2G sur la période). Sur M8, le survey n'a jamais échoué (56 / 56 acquisitions sans GPS ont ramené des cellules).
La 2G n'est pas liée à un type d'emplacement : une sonde tombe en 2G dès que le LTE-M est absent ou trop faible (couverture marginale). Ce n'est donc pas réservé aux lieux enterrés — certaines sondes en 2G ne le sont pas, et des sondes en LTE-M fonctionnent dans des endroits difficiles. Constat : ~29 % des sondes (9 / 31) dépendent d'un survey 2G pour leur position. Si ce survey reste cassé sur M10, ces sondes n'obtiendraient aucune position au démarrage — et n'auraient donc rien à ré-émettre ensuite.
URAT=9/CFUN + parade anti-blocage + normalisation au démarrage), en assumant le coût conso — éventuellement en ne déclenchant la danse 2G que faute de LTE-M.URAT — 0 = GSM (interdit M10S), 9 = GPRS/eGPRS (2G, autorisé) ; autorisées M10S = 7, 8, 9.
UCFSCAN <AcT> — 0 = GSM, 2 = WCDMA, 7 = LTE, 9 = NB-IoT.
+ULOC)Richard a souligné que CellLocate reste supporté par Trasna. Cette voie pourrait éviter toute la mécanique URAT / CFUN décrite plus haut.
+ULOC est le positionnement par cellules géré par le module u-blox lui-même : il effectue le relevé multi-RAT en interne et renvoie directement une position (lat/long), via le service de localisation u-blox (CellLocate).
URAT=9 ni de cycler CFUN → supprime le risque de blocage 2G et le coût des ré-attachements.+ULOC, la position est calculée côté module / service u-blox → cela déplace (voire supprime) notre étage de trilatération.+ULOC peut nécessiter un échange avec le serveur de localisation u-blox (donnée supplémentaire, dépendance à un service tiers, coût data sur eSIM) — à confirmer.Poser la question à Richard / Trasna : pour notre cas d'usage (sonde sur batterie, souvent sans GPS, rabattue en 2G quand le LTE-M est faible), recommandent-ils +ULOC / CellLocate plutôt que le survey manuel UCFSCAN ? Gère-t-il la 2G en interne sans forçage URAT ? Cela tranche entre les deux voies.