SixFab Pico LTE: Premier test de connexion

Bonjour à tous,

Après l'article "SixFab Pico LTE: Enregistrement de l'Assets", il est temps de dégainer notre terminal REPL favori (Thonny IDE, MPRemote, RShell) pour commencer nos expérimentations mobiles.

Aujourd'hui, nous allons nous connecter sur le réseau mobile.

A propos de SixFab Pico LTE

Sans être onéreux, SixFab propose une solution permettant de transporter l'information entre votre projet Pico vers un nombre significatif de services IoT professionnel ou service grand public.

Source: SixFab Pico-LTE (~50Eur)

C'est l'une des rares fois où je me dis qu'il est possible de surveiller/commander son poulailler sans se ruiner avec les communications.

Bibliothèque Pico LTE

La bibliothèque Pico LTE est déjà installée sur votre Raspberry-Pi Pico. 

Vous pouvez néanmoins la mettre à jour à partir du dépôt GitHub en suivant les instructions d'installation sur de page

C'est parti ...

Par défaut, la bibliothèque cherche à enregistrer le module sur un reseau LTE. Si vous êtes dans une région où le signal LTE est absent ou peu présent, il est possible de passer en mode 3G.

Branchez votre Pico LTE sur un PC (A ce stade, seule la LED rouge est allumée)

Démarrez une session REPL avec Thonny IDE (ou avec MPRemote, Putty ou tout autre outil de votre choix).

Une fois l'invite REPL ">>>" disponible nous allons pouvoir commencer nos tests.
Note: pressez la touche de retour clavier/Enter si l'invite microPython n'apparaît pas!

>>> from pico_lte.utils.status import Status
>>> from pico_lte.core import PicoLTE
>>> from pico_lte.common import debug
>>> picoLTE = PicoLTE()
>>> picoLTE.network.register_network()
{'status': 0, 'response': ['+CREG: 0,5', 'OK'], 'interval': 0}

A la création de l'instance picoLTE = PicoLTE(), le module de communication est mis sous tension.
 

La LED bleue clignote brièvement toutes les 2 secondes. indiquant que le module est en recherche de réseau mobile.

Une fois connecté, la LED bleue reste allumée et s'éteint brièvement toutes les deux secondes.

La carte Embeded SIM correspond a un opérateur US offrant l'accès au réseau "super".

La demande d'enregistrement réseau fait le tour du monde avant de recevoir une réponse. 

Ainsi, cet enregistrement peut prendre de nombreuses minutes et échouer à la fin d'un délai de 5 minutes (avec la poursuite de la recherche du réseau mobile "super").

Note: le réseau "super" étant peut utilisé en Europe/Belgique (Fevrier 2024), l'enregistrement peut prendre plus d'une heure! Cela représente de nombreux appels à register_network() ... il faut être patient. 

Une fois enregistré sur le réseau mobile... tout roule comme sur des roulettes.

register_network() en LTE

L'appel register_network() enregistre le module sur le réseau mobile.

Dans l'exemple, cet appel retourne la valeur.

{'status': 0, 'response': ['+CREG: 0,5', 'OK'], 'interval': 0}

Le 'status': 0 indique que l'enregistrement est fait.
La réponse +CREG: 0,5 retourne deux paramètres:

  • le premier (0) est le mode utilisé par la bibliothèque
  • le second (5) est le statut d'enregistrement sur le réseau.
    La valeur 5 indique ROAMING.

Dans l'exemple du jour ci-dessous, l'appel register_network() retourne la réponse suivante

{'status': 1, 'response': ['+CREG: 0,2', 'OK'], 'interval': 0}

Le 'statut': 1 indique un problème d'enregistrement.
La réponse +CREG: 0,2 contient l'information pertinente:

  • le premier (0) est le mode utilisé par la bibliothèque
  • le second (2) est le statut d'enregistrement sur le réseau.
    La valeur 2 indique NON enregistré mais en recherche de nouvel opérateur.

Voici les statuts d'enregistrement retournés +CREG :

  • 0: Not registered, the device is currently not searching for new operator.
  • 1: Registered to home network.
  • 2: Not registered, but the device is currently searching for a new operator.
  • 3: Registration denied.
  • 4: Unknown. For example, out of range.
  • 5: Registered, roaming. The device is registered on a foreign (national or international) network.

register_network() en GSM

Si l'appel register_network() en LTE échoue systématiquement (ou les appels successif restent infructueux) alors il est fort à parier que le signal LTE est trop faible dans votre région.

Il est alors possible de donner la priorités aux réseaux GSM pour l'enregistrement comme l'indique ce billet.

>>> from pico_lte.utils.atcom import ATCom
>>> atcom = ATCom()
>>> from pico_lte.modules.base import Base 
>>> base = Base(atcom) 
>>>
>>> from pico_lte.utils.status import Status
>>> from pico_lte.core import PicoLTE
>>> picoLTE = PicoLTE()
>>>
>>> # Donne la priorité au réseau GSM avant LTE
>>> response = base.config_network_scan_sequence("01") 
>>>
>>> picoLTE.network.register_network()
{'status': 1, 'response': ['+CREG: 0,2', 'OK'], 'interval': 0}

Mode debug

La bibliothèque permet d'afficher des messages de débogages... principalement les échanges entre la bibliothèque et le module.

Pour voir ces messages, il faut placer le debug level à 0.

>>> from pico_lte.common import debug
>>> debug.set_level(0)
>>> >>> from pico_lte.utils.atcom import ATCom >>> atcom = ATCom() >>> from pico_lte.modules.base import Base >>> base = Base(atcom) >>> >>> from pico_lte.utils.status import Status >>> from pico_lte.core import PicoLTE >>> picoLTE = PicoLTE() DEBUG: Power status: 1 DEBUG: Power status: 1 DEBUG: Power status: 1 DEBUG: Power status: 0 DEBUG: Response: ['\x00\r\nRDY\r\n'] DEBUG: Processed: ['\x00', 'RDY'] DEBUG: Response: ['\r\nAPP RDY\r\n'] DEBUG: Processed: ['\x00', 'RDY', 'APP RDY'] DEBUG: COM: {'response': 'timeout', 'status': 2} DEBUG: Response: ['AT\r\r\nOK\r\n'] DEBUG: Processed: ['AT\r', 'OK'] DEBUG: COM: {'response': ['AT\r', 'OK'], 'status': 0} DEBUG: Response: ['ATE0\r\r\nOK\r\n'] DEBUG: Processed: ['ATE0\r', 'OK'] >>> response = base.config_network_scan_sequence("01") DEBUG: Response: ['\r\nOK\r\n'] DEBUG: Processed: ['OK'] >>> picoLTE.network.register_network() DEBUG: Response: ['\r\n+CREG: 0,2\r\n\r\nOK\r\n'] DEBUG: Processed: ['+CREG: 0,2', 'OK'] DEBUG: Fault: +CREG: 0,2 DEBUG: check_network_registration : {'response': ['+CREG: 0,2', 'OK'], 'status': 1} DEBUG: Response: ['\r\nOK\r\n'] DEBUG: Processed: ['OK'] DEBUG: check_communication : {'response': ['OK'], 'status': 0} DEBUG: Response: ['\r\n+CPIN: READY\r\n\r\nOK\r\n'] DEBUG: Processed: ['+CPIN: READY', 'OK'] DEBUG: Desired: +CPIN: READY DEBUG: check_sim_ready : {'response': ['+CPIN: READY', 'OK'], 'status': 0} DEBUG: Response: ['\r\n+CGDCONT: 1,"IPV4V6","super","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0\r\n\r\nOK\r\n'] DEBUG: Processed: ['+CGDCONT: 1,"IPV4V6","super","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0', 'OK'] DEBUG: Desired: +CGDCONT: 1,"IPV4V6","super","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0 DEBUG: check_apn : {'response': ['+CGDCONT: 1,"IPV4V6","super","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0', 'OK'], 'status': 0} DEBUG: Response: ['\r\n+CREG: 0,2\r\n\r\nOK\r\n'] DEBUG: Processed: ['+CREG: 0,2', 'OK'] DEBUG: Fault: +CREG: 0,2 DEBUG: check_network_registration : {'response': ['+CREG: 0,2', 'OK'], 'status': 1} DEBUG: Response: ['\r\n+CREG: 0,2\r\n\r\nOK\r\n'] DEBUG: Processed: ['+CREG: 0,2', 'OK'] DEBUG: Fault: +CREG: 0,2 DEBUG: check_network_registration : {'response': ['+CREG: 0,2', 'OK'], 'status': 1} DEBUG: Response: ['\r\n+CREG: 0,2\r\n\r\nOK\r\n']

Pour la suite...

Maintenant que nous pouvons nous connecter sur le réseau... nous allons pouvoir nous pencher sur la première application... l'envoi de message MQTT et la souscription.

A tout bientôt,
Dominique

Aucun commentaire