Le SIM800L est un modem GSM/GPRS très utilisé en électronique en raison de son prix très faible et de sa large disponibilité. C’est un moyen abordable d’envoyer des SMS avec un Raspberry Pi ou un Arduino, de se connecter en 3G ou d’implanter un GPS.

Pourtant, il est presque impossible de trouver des explications satisfaisantes sur son utilisation et particulièrement sur son branchement.

Dans ce tutoriel nous allons donc voir comment brancher et alimenter un SIM800L depuis un Raspberry (notez que cela fonctionne aussi pour un Arduino), sans alimentation externe ni batterie !

Le matériel nécessaire pour brancher votre SIM800L à votre Raspberry.

Nous rentrerons dans les détails et les explications plus loin dans ce tutoriel, mais sachez que pour relier un SIM800L à un Raspberry un peu de matériel est nécessaire. Ainsi, vous aurez besoin :

• D’un module SIM800L.
• Un fer à souder pour assembler votre SIM800L si elle ne l’est pas déjà.
• D’une breadboard, d’un condensateur 5 V, 100 µF ou plus, d’une diode 1N4007, de câbles Dupont. Vous pourriez achetez chaque élément seul, mais vous devriez en fait acheter des dizaines de condensateurs et diodes juste pour amortir les frais de port. Je pense donc que le plus simple est de prendre un kit d’électronique comme celui-ci qui contient tout ce que nous venons de citer.

Bien entendu, vous devrez également disposer d’un Raspberry avec raspbian installé et d’une carte SIM avec un abonnement. À noter, la carte SIM doit-être au format micro sim. Si la votre est d’un format plus petit (nano), il vous faudra un adaptateur.

Maintenant, passons aux explications et à la pratique.

Pas le temps ou l’envie de lire les explications ? Passez directement à la partie « En pratique… ».

La théorie, comment utiliser un SIM800L avec un Raspberry Pi ?

Le SIM800L est un modem. C’est lui qui se charge de s’enregistrer auprès du réseau de votre opérateur, etc. Globalement il se comporte comme un téléphone que vous pourriez contrôler directement depuis votre Raspberry.

Pour pouvoir contrôler le SIM800L, depuis le Raspberry, vous allez devoir fournir une alimentation au premier et connecter physiquement et logiciellement les deux en utilisant un port TTL, plus souvent appelé port ou interface série.

À partir de là vous pourrez contrôler le SIM800L en envoyant sur le port série des commandes dites Hayes – on parle en fait plus souvent de commandes AT – qui sont des commandes spécifiques aux fonctions d’un modem. Par exemple, envoyer un SMS, entrer un code PIN, vérifier l’état du réseau, et bien d’autres choses encore !

En théorie, pour utiliser un SIM800L avec le Raspberry Pi vous devez donc faire comme ceci :

1. Brancher le VDD du SIM800L à un GPIO fournissant du courant sur le Raspberry.
2. Connecter le GND du SIM800L à un GPIO GND sur le Raspberry.
3. Relier le TXD du SIM800L au RXD du Raspberry.
4. Relier le RXD du Raspberry au TXD du SIM800L.
5. Envoyer et recevoir des données avec des commandes AT sur le port série.

Seulement voilà, tout ça c’est la théorie, mais vous allez voir qu’en pratique les choses sont un peu plus compliquées…

La réalité, pourquoi est-il difficile de brancher un SIM800L ?

Si la théorie semble simple, en réalité vous trouverez assez peu de tutoriels sur internet vous expliquant comment utiliser le SIM800L avec un Raspberry. Pire, vous trouverez essentiellement des tutoriels incorrects qui, au mieux, rendront votre installation complètement instable, au pire, abîmeront votre SIM800L.

Mais alors, comment se fait-il qu’il n’y ait pas plus de ressources de qualité disponibles pour un module si connu ? Parce-que le SIM800L est particulièrement difficile à alimenter et sensible.

Un module conçu pour les téléphones et les batteries.

À l’origine le SIM800L a été conçu pour être utilisé dans des téléphones par des constructeurs. Son utilisation en électronique grand public est bien plus récente et n’a pas du tout été envisagée par le fabricant.

Conséquence de son utilisation au sein de téléphones, le module est pensé pour être alimenté avec des batteries lithium-ion, lesquelles proposent des tensions d’environ 3,6 à 3,7 volts. Cette particularité va nous poser un premier problème, car en électronique numérique on utilise généralement 3,3 volts ou 5 volts, mais pas 3,6 volts.

Un module gourmand en énergie.

Second problème, le SIM800L effectue des opérations radio qui demandent de gros pics de courant très ponctuels. Typiquement les opérations en cause sont l’enregistrement sur le réseau de l’opérateur, l’envoi de messages, etc. Si durant ces phases le module n’obtient pas le courant nécessaire son comportement devient complètement imprédictible, allant du message d’erreur au redémarrage en passant par la perte de réseau.

Il se trouve hélas que les alimentations de façon générale et les ports GPIO du Raspberry Pi en particulier ont beaucoup de mal à répondre à ce genre de pics de consommation.

En fait, la quantité d’énergie consommée est si grande et sur une si courte durée qu’utiliser des câbles d’alimentation trop longs et trop fins peut suffire à faire planter le module ! C’est d’ailleurs typiquement le cas si vous branchez plusieurs câbles Dupont en série.

Rassurez-vous, nous allons vous expliquer comment résoudre ces deux problèmes !

En pratique, comment alimenter un SIM800L directement depuis un Raspberry ?

Nous avons donc vu que deux problèmes se posent à nous pour alimenter un SIM800L depuis un Raspberry : une tension incompatible et des pics de consommation électrique.

Pour commencer, nous allons nous attaquer au problème de tension.

Diminuer la tension fournie par le Raspberry Pi.

Si on lit la datasheet, c’est-à-dire la fiche technique, du SIM800L, on voit que le constructeur indique une tension d’alimentation comprise en 3,4 et 4,4 volts, avec une tension optimale de 4 volts.

Le Raspberry Pi lui peut fournir deux tensions, 3,3 et 5 volts. Nous devrions donc augmenter un peu notre tension ou la diminuer.

Éliminons la première possibilité qui est trop compliquée à mettre en œuvre et penchons-nous sur la deuxième. Nous cherchons donc un moyen fiable, simple et très peu cher de diminuer une tension d’au moins 0,6 volts, sans diminuer l’intensité du courant (ampères). Coup de chance, il se trouve qu’il existe un composant électronique qui fait exactement ça, et qu’en plus ce composant est tellement répandu qu’absolument tous les électroniciens le connaissent : la diode.

Les diodes sont principalement connues pour laisser passer le courant dans un seul sens. Mais une de leur caractéristique est également de provoquer une chute de tension, laquelle est estimée pour les diodes au silicium à 0,7 volts.

Il nous suffit donc d’insérer une diode au silicium, nous prendrons une 1N4007, entre le GPIO 5 volts de notre Pi et le PIN VDD (alimentation) de notre SIM800L. Et voilà, nous avons une tension de 4,3 volts, juste ce qu’il nous faut.

Fournir une source de courant pouvant répondre aux pics de consommation.

Maintenant que nous avons résolu notre problème de tension, reste notre problème de pics de consommation. Cette fois il nous faudrait un composant nous permettant de « stocker du courant » et de le fournir de façon très rapide quand le SIM800L en a besoin. Là encore coup de chance, ça existe et ça s’appelle un condensateur !

Les condensateurs sont utilisés dans de nombreux cas, mais l’une des utilisation les plus connues est la stabilisation d’alimentation. Ils se chargent quand il y a trop de courant et se décharge quand il en manque.

Nous allons donc insérer un condensateur électrolytique (on prendra au minimum un 100 µF 5 V, si on a plus en µF ou en volts aucun problème) en parallèle des pins VDD et GND de notre SIM800L.

Le montage complet.

Maintenant que nous avons résolu nos problèmes, voyons à quoi ressemble notre montage complet avant de tout tester en envoyant un SMS.

Pour maintenir tous nos composants en place et les relier entre eux nous allons utiliser une breadboard et des câbles Dupont.

Voici donc le schéma de branchement final, le fil rouge va au VDD, le noir au GND.

Quelques remarques concernant le montage :

• Effectuez les branchement Raspberry éteinte et non branchée, ne la branchez qu’après avoir tout vérifié et être sûr que votre montage est bon.
• Prenez bien garde à brancher le condensateur le plus près possible des pins VDD et GND du SIM800L, idéalement comme sur le schéma.
• Le condensateur est un composant polarisé, il doit être branché dans un sens précis, anode sur le VDD, cathode sur le GND. La cathode est marquée par une bande blanche sur le coté.
• Comme le condensateur, la diode est un composant polarisé, là encore la cathode est marquée par une bande blanche.

Une fois le montage terminé vous allez pouvoir insérer la carte SIM dans l’emplacement prévu sur le SIM800L.

Faîtes bien attention au sens, ce n’est absolument pas intuitif. Vous devez rentrez la carte coté contacts contre le circuit imprimé, le coin coupé en biais vers l’ouverture (il dépasse un peu). Si vous rentrez la carte à l’envers vous aurez une erreur type SIM not inserted en utilisant le module.

Une fois le montage fini, allumez votre Raspberry Pi, nous allons pouvoir tester en envoyant un SMS !

Envoyer votre premier SMS depuis le Raspberry avec un SIM800L.

Pour finir ce tutoriel, nous allons envoyer un premier SMS pour vérifier que tout fonctionne. Nous n’irons pas plus loin quant à l’utilisation du SIM800L, sachez néanmoins qu’il propose beaucoup d’autres fonctionnalités. Pour une utilisation plus poussée reportez-vous au guide des commandes AT pour la SIM800.

Pour commencer, vous allez devoir suivre notre tutoriel pour activer le port série du Raspberry Pi. Une fois que vous aurez fini d’activer le port série nous pourrons nous connecter à la SIM800L via le port série.

Pour cela, ouvrez une connexion sur /dev/serial0 avec minicom en utilisant la ligne de commande ci-dessous :

sudo minicom -b 115000 -o -D /dev/serial0

Tapez la commande AT (souvent la premières ligne ne s’affiche pas quand on tape, c’est normal) puis faites un retour à la ligne pour valider. Vous devriez avoir un message de réponse OK.

Maintenant nous allons vérifier que la carte SIM est bien débloquée (le code PIN est entré). Pour cela tapez la commande AT+CPIN?. Si la carte est débloquée vous devriez avoir une réponse :

+CPIN: READY
OK

Si vous avez une réponse comme celle ci-dessous c’est que vous devez entrez le code PIN de votre carte.

+CPIN: SIM PIN
OK

Pour cela utilisez la commande AT+CPIN=0000 en remplaçant 0000 par votre propre code PIN. Vous devriez alors avoir une réponse sous la forme :

AT+CPIN=0000
OK
+CPIN: READY
SMS Ready
Call Ready

C’est bon, vous êtes connecté au réseau de votre opérateur. Il ne nous reste plus qu’à envoyer un SMS. Pour cela utilisez les commandes AT+CMGF=1 pour activer le mode texte (ça nous permet d’écrire le SMS dans un format compréhensible pour un humain), puis AT+CMGS="+33612345678" en remplaçant +33612345678 par le numéro auquel vous souhaitez envoyer le SMS.

Un caractère > va apparaître, tapez votre SMS puis une fois que vous avez fini, faîtes Ctrl+Z.

Au final vous devriez avoir quelque chose de la forme suivante :

AT+CMGF=1
OK
AT+CMGS="+33612345678"
> Mon premier SMS avec un SIM800L
+CMGS: 29

OK

Et voilà, vous avez envoyé votre premier SMS avec un Raspberry Pi et un SIM800L !

Comme vous pouvez le constater l’usage au quotidien directement avec les commandes AT n’est pas forcément très pratique, mais rassurez-vous, des logiciels existent pour vous simplifier la vie, et nous en parlerons d’ailleurs très prochainement dans un autre tutoriel !

Lire l'article complet : Comment brancher et utiliser un module GSM SIM800L avec le Raspberry Pi (sans batterie).

Original post of RaspbianFrance.Votez pour ce billet sur Planet Libre.

Original post of genma.Votez pour ce billet sur Planet Libre.

Pour la 36ème semaine de l'année 2020, voici 12 liens intéressants que vous avez peut-être ratés, relayés par le Journal du hacker, votre source d’informations pour le Logiciel Libre francophone !

• [Test] Un NAS à base de Raspberry Pi ?
• La couleur du chapeau, un point de vue
• Gitako, une extension qui affiche l'arborescence des fichiers d'un dépôt Github
• Petit cours de supervision et de métrologie pour débutant·e·s
• GPT-3 : la gigantesque intelligence artificielle qui inquiète
• Nom : logiciel, Durée de vie : pas beaucoup
• Les historiques de navigation sont suffisamment uniques pour identifier les utilisateurs de manière fiable assure Mozilla
• Consentement : le pire de l'expérience utilisateur et de la surveillance avec Lemonde.fr
• Installation de Matomo sur Debian afin d'analyser l'audience de votre site Web
• Tester son application avec Cypress
• Gérez vos secrets Kubernetes dans Vault
• Comment créer un serveur de noms avec DNS-over-TLS (DoT)

Pour ne plus rater aucun article de la communauté francophone, voici :

• Le flux RSS du Journal du hacker
• Le compte Twitter du Journal du hacker
• Le compte Diaspora* du Journal du hacker
• Le compte Mastodon du Journal du hacker

De plus le site web du Journal du hacker est « adaptatif (responsive) ». N’hésitez pas à le consulter depuis votre smartphone ou votre tablette !

Le Journal du hacker fonctionne de manière collaborative, grâce à la participation de ses membres. Rejoignez-nous pour proposer vos contenus à partager avec la communauté du Logiciel Libre francophone et faire connaître vos projets !

Et vous ? Qu’avez-vous pensé de ces articles ? N’hésitez pas à réagir directement dans les commentaires de l’article sur le Journal du hacker :)

Original post of Journal du hacker.Votez pour ce billet sur Planet Libre.

Pourquoi faut-il taper l’option -h des commandes df et free ? Les développeurs de ces outils pensent que cette option est superflue ?

Personnellement une option nommée --human-readable (-h), je pense qu’il serait utile, opportun et judicieux de l’intégrer par défaut.

free
             total       used       free     shared    buffers     cached
Mem:      32634444   27410980    5223464     376440      93224   18234220
-/+ buffers/cache:    9083536   23550908
Swap:            0          0          0

free -h
             total       used       free     shared    buffers     cached
Mem:           31G        26G       5.0G       370M        91M        17G
-/+ buffers/cache:       8.7G        22G
Swap:           0B         0B         0B

Je n’ai pas assez de barbe pour apprécier la notation « moins human-readable » (sans -h). On passe à un niveau supérieur avec la commande df.

df /dev/nvme0n1p1 /dev/sdb
Sys. de fichiers blocs de 1K   Utilisé Disponible Uti% Monté sur
/dev/nvme0n1p1     239314556  50879376  176208928  23% /
/dev/sdb          1921803544 620797656 1203313776  35% /media/cascador/Data

df -h /dev/nvme0n1p1 /dev/sdb
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/nvme0n1p1     229G     49G  169G  23% /
/dev/sdb           1,8T    593G  1,2T  35% /media/cascador/Data

Évidemment la notation « moins human-readable » a des qualités : Plus précise, utile dans des scripts. Cependant à l’heure de l’utilisation de disques en To, il faudrait peut-être s’éloigner d’une notation précise pour se rapprocher d’une notation plus lisible, compréhensible et simple pour l’utilisateur (user-friendly).

Norme et exception (usage par défaut et option)

Cette question rejoint une interrogation plus large chez moi, quand doit-on opérer une bascule entre norme et exception ?

Si 9 fois sur 10 la majorité des utilisateurs font df -h ne faut-il pas considérer -h comme une norme de facto et plus une option ? Et alors modifier le code de df pour que de base sans devoir préciser -h df renvoie les infos en human-readable. Bien entendu une nouvelle option serait ajoutée afin de conserver la notation « moins human-readable » qui reste nécessaire. df en human-readable deviendrait la norme, la notation « moins human-readable » l’exception.

Au doigt mouillé 98% des personnes utilisent la commande ln pour créer un lien symbolique (symbolic link) ln -s, pourquoi ln crée un hard link par défaut ? Le hard link est l’exception dont on se sert 2 fois de l’an et le lien symbolique la norme, quand les développeurs de la commande ln vont la modifier pour qu’elle crée un lien symbolique par défaut ?

La façon dont l’outil est conçu et codé rentre en compte, je ne me suis pas penché sur le code de ln mais je suppose qu’il y a de bonnes raisons à ce que la création d’un hard link soit le choix par défaut. Enfin j’espère.

Remettre l’utilisateur au centre

Cela ne change en rien ma réflexion, en 2020 tout outil devrait être tourné vers l’utilisateur, être user-friendly et human-readable par défaut. Devoir utiliser free -h, df -h, ln -s revient à devoir préciser qu’on est humain et l’utilisation naturelle et simple qu’on veut de l’outil.

Original post of blog-libre.Votez pour ce billet sur Planet Libre.

Sujet simple en apparence, plus complexe en réalité. La documentation en Français chez Red Hat pour Désactiver un service.

Empêcher un service de se lancer automatiquement : systemctl disable

sudo systemctl disable bluetooth empêchera le service de se lancer au boot, cette commande lit la section [Install] de l’unité de service sélectionnée (systemctl cat bluetooth) et supprime les liens symboliques appropriés pointant vers le fichier /usr/lib/systemd/system/name.service du répertoire /etc/systemd/system/ et de ses sous-répertoires.

Personnellement j’utilise toujours sudo systemctl disable --now bluetooth, --now : When used with enable, the units will also be started. When used with disable or mask, the units will also be stopped. The start or stop operation is only carried out when the respective enable or disable operation has been successful. Cette commande désactive le service (disable) et l’arrête (--now).

Pour faire l’opération inverse sudo systemctl enable --now bluetooth va activer le service et le démarrer.

Avec systemctl disable :

• Le service ne sera pas lancé au boot
• On peut lancer le service manuellement (sudo systemctl start bluetooth)
• Le service peut être lancé par un autre service
• Suivant les distributions/packages, la mise à jour du paquet peut activer le service et le démarrer. Dans cette situation il faudrait donc désactiver le service (sudo systemctl disable) à chaque fois que le paquet est mis à jour

Désactiver un service totalement : systemctl mask

sudo systemctl mask --now wpa_supplicant remplace le fichier /etc/systemd/system/name.service par un lien symbolique pointant vers /dev/null, ce qui rend le fichier de l’unité inaccessible à systemd. À noter que sudo ln -s /dev/null /etc/systemd/system/wpa_supplicant.service fait le même travail. Tiré du man systemctl : This will link these unit files to /dev/null, making it impossible to start them. This is a stronger version of disable, since it prohibits all kinds of activation of the unit, including enablement and manual activation.

Pour faire l’opération inverse :

sudo systemctl unmask wpa_supplicant
sudo systemctl start wpa_supplicant

Avec systemctl mask, on ne peut plus « du tout » lancer le service :

• Le service ne sera pas lancé au boot
• On ne peut pas lancer le service manuellement (sudo systemctl start wpa_supplicant)
• Le service ne peut pas être lancé par un autre service
• Le service ne peut pas être activé (sudo systemctl enable wpa_supplicant)

Certains se demandent peut-être pourquoi installer un paquet si c’est pour désactiver son service totalement. Le cas le plus commun est que le paquet est une dépendance d’un autre. wpasupplicant est un bon exemple, network-manager a comme dépendance wpasupplicant (apt-cache depends network-manager). Par conséquent même si vous utilisez iwd et son service (à la place de wpasupplicant), vous ne pouvez pas désinstaller wpasupplicant (alors que vous n’utilisez plus son service).

Cas spécial

J’installe TeamViewer sur mon pc. Je ne souhaite pas que le service tourne tout le temps (lancé au boot) mais j’ai besoin de pouvoir le démarrer quand j’en ai besoin (sudo systemctl start teamviewerd). sudo systemctl disable teamviewerd répond au besoin mais quand le paquet TeamViewer est mis à jour (sudo apt upgrade), le service teamviewerd est de nouveau activé et démarré. Je devrais le désactiver à chaque fois que le paquet est mis à jour… pénible.

J’utilise un drop-in systemd (/etc/systemd/system/teamviewerd.service.d/teamviewer.conf) qui permet de surcharger la configuration du service sans toucher au fichier « principal » du service (/etc/systemd/system/teamviewerd.service) qui peut être modifié lors d’une mise à jour.

sudo systemctl disable --now teamviewerd
sudo mkdir -p /etc/systemd/system/teamviewerd.service.d
sudo nano /etc/systemd/system/teamviewerd.service.d/teamviewer.conf
[Install]
WantedBy=

sudo systemctl daemon-reload

Pour faire l’opération inverse :

sudo rm -r /etc/systemd/system/teamviewerd.service.d
sudo systemctl daemon-reload
sudo systemctl enable --now teamviewerd

Avec cette méthode :

• Le service ne sera pas lancé au boot
• On peut lancer le service manuellement (sudo systemctl start teamviewerd)
• Le service peut être lancé par un autre service
• La mise à jour du paquet va démarrer le service… mais au prochain boot le drop-in systemd va faire son job donc le service ne sera pas démarré

Adaptation

J’ai souhaité parler d’un sujet simple en le traitant en profondeur (sans en faire trop, cela a tendance à perdre le lecteur). J’avais l’article Communautés techniques, utilisateurs libérés en tête, rester accessible, fournir une info technique utile tout en répondant à la question de l’usage.

C’était comment ?

Original post of blog-libre.Votez pour ce billet sur Planet Libre.