IoT-Link · LevelStream · Note technique

Migration SARA-R422 M8S → M10S
Network survey 2G & positionnement par cellules

Document interne Firmware / Connectivité
📅 4 juin 2026 🔧 Branche master (M10) 🛰️ SARA-R422M10S-01B-02

Résumé exécutif

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).

1Les 4 points de la migration

PointConstatÉtat firmware M10 (master)
TIMEPULSE — safebootla broche doit être NOPULL✓ Résolu PB15 en entrée NOPULL (acté au changelog)
Baud TXD_GNSS9600 (M8) → 38400 (M10), non documenté✓ Résolu USART3 = 38400, buffer GNSS élargi
Trames NMEAdésactivées par défaut sur M10✓ Résolu réactivées (UGGGA=1, UGRMC=1, UGGSA=1)
Network survey 2Gvoir détail ci-dessous⚠ Cassé — réparable
À retenir

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.

2Network survey 2G — investigation & résolution

Ce que fait le firmware

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) :

Constat Damien (Thelis)

Banc — cartes M10 « 059 » et « 162 » · 23/02/2026

Carte connectée en 2G EGPRS par repli automatique (+COPS: 0,0,"Proximus",3) :

  • AT+UCFSCAN=0CME ERROR
    « A scan on a disabled access technology (GSM) is triggered »
  • AT+UCFSCAN=7 (LTE) → OK — 4 cells

Analyse : sur M10S, URAT autorisés = 7, 8, 9 ; URAT=0 (GSM) interdit ; or UCFSCAN=0 scanne la bande GSM, désactivée → CME error.

Réponse Richard Magré

FAE Trasna / Batenburg · fin mai 2026

  • AT+UCFSCAN=2 = WCDMA/UMTS (3G), non supporté.
  • Pour la 2G : forcer AT+URAT=9 puis AT+UCFSCAN=0 ramène les cellules.
  • « CellLocate est toujours supporté par Trasna. »

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

Résolution — les deux constats concordent

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é.

⚠ Conclusion

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.

Correctif firmware (principe)

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)

3Comportement après le survey — persistance du URAT & risque de blocage 2G

Constats issus du code :

Conséquences

⚠ Risque à maîtriser — blocage permanent en 2G

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.

✓ Parade recommandée

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.

4Comment fonctionne le positionnement

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.

Point clé sur les messages

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).

5Mesure du besoin — données flotte M8

Export StatusMessages · juillet 2025 → mai 2026 · 100 sondes enregistrées (31 ayant émis sur la période) · 7 181 messages.

Méthode — quels messages comptent

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 cellulaire56 (28,7 %)
    dont survey 2G31 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).

⚠ Enjeu

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.

6À trancher

Référence numérotation

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.

7Piste alternative à évaluer : CellLocate (+ULOC)

Richard a souligné que CellLocate reste supporté par Trasna. Cette voie pourrait éviter toute la mécanique URAT / CFUN décrite plus haut.

Principe

+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).

Avantages potentiels

Points à vérifier / arbitrages

Action suggérée

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.