Lors de cet atelier nous avons mis en œuvre un ensemble de modules radio émetteur / récepteur à bas coût (quelques euros les deux modules) utilisant la modulation ASK (Amplitude Shift Keying) sur une fréquence de 433 MHz.
L’ASK est l’équivalent numérique de la modulation d’amplitude analogique (radio AM).
La documentation des modules utilisés se trouve sur le site Seeedstudio.
Concernant la modulation ASK, inutile de redire ce que d’autres ont déjà proposé sur le web :
Article du département informatique du CNAM
Document PDF sur domoscomputer.com
Transmission d’état
La base ayant été posée, notre première tentative de communication sans fil s’est résumée à essayer d’allumer et d’éteindre une LED à distance.
Tout d’abord nous avons utilisé une plaque d’essai (breadboard) sur laquelle nous avons installé les deux modules émetteur et récepteur. Nous les avons alimentés en 5V.
Sur la sortie ’data’ du récepteur nous avons branché une led rouge en série avec une résistance de 150 Ohms (le module récepteur étant supposé délivrer une tension de Vcc / 2 sur cette sortie data).
Nous avons ensuite relié l’entrée ’data’ de l’émetteur alternativement à la masse ou au 5V.
Le résultat n’étant pas satisfaisant (la LED n’était pas allumé de façon franche), nous avons utilisé un oscilloscope pour vérifier que le signal en sortie du récepteur n’était pas stable.
Sur une bonne idée de Jean, nous avons alors branché un générateur basse fréquence (GBF) sur l’entrée de l’émetteur. Nous avons réglé le niveau de sortie afin d’obtenir un signal variant entre 0 et 5V (tension crête-crête du signal réglé à 5V et ajout d’une composante continue de 2,5V).
Nous avons réglé la fréquence du générateur BF à 1Hz. La LED s’est alors mise à clignoter.
Par curiosité et pour déterminer la vitesse limite de transmission, nous avons ensuite fait varier la fréquence de 1Hz à 100kHz. La limitation est rapidement apparue à partir de 10kHz. Nous ne savons pas lequel des modules (émetteur ou récepteur) est limitant, toujours est-il qu’en sortie nous voyons bien que le front montant n’est plus vertical.
A 1kHz nous avons le signal de sortie suivant :
A 15kHz, on ne retrouve plus les plateaux mais seulement des pics, et on voit bien que les temps de montée et de descente deviennent prépondérants par rapport à la demi-période :
Ce qui est étrange, c’est que le rapport cyclique du signal reçu est modifié. On se serait plutôt attendu à un signal de cette forme :
C’est à dire un signal montrant un temps de montée et un temps de descente très limité par rapport au front montant et descendant du signal d’origine.
Autre remarque, nous avons utilisé plusieurs types de signaux : sinusoïdal, triangulaire et carré. Quel que soit le type de signal en entrée data de l’émetteur, en sortie on obtient un signal tout ou rien. Néanmoins, le type sinusoïdal en entrée nous a donné le signal le plus ’franc’ en sortie.
Transmission série
Forts de ces constatations, nous avons ensuite essayé de transmettre la sortie TX d’un port série (convertisseur USB série utilisé sous Linux).
Le port série a été reconnu comme /dev/ttyUSB0 sous Linux.
Afin de ne pas être gêné par la limitation à 15kHz, nous avons modifié les vitesses d’émission et de réception du port série à 1200 bauds (1,2 kHz).
Nous avons utilisé la commande stty de cette façon :
$ stty -F /dev/ttyUSB0 ispeed 1200 ospeed 1200
Nous n’avons pas changé les autres paramètres du port série.
Par simplicité, nous avons créé une boucle en script shell afin d’envoyer le caractère ’A’ sur le port série :
$ while true; do echo 'A' > /dev/ttyUSB0; done
Nous avons ensuite connecté la masse du port série sur la masse de notre montage, puis le TX sur l’entrée de l’émetteur. L’oscilloscope nous a permis de vérifier qu’un signal était présent sur la sortie data du récepteur.
Il ne nous restait plus qu’à reboucler la sortie data du récepteur sur l’entrée RX du port série afin de vérifier que le caractère ’A’ était bien reçu !
Bingo ! Le caractère ’A’ arrive, mais il y a des d’erreurs !
On a refait l’expérience avec une chaîne de caractère plus longue :
$ while true; do echo ' Hello world' > /dev/ttyUSB0; done
Les espaces initiaux sont là pour mettre en évidence un comportement bizarre de notre boucle :
port série TX -> émetteur -> ondes -> récepteur -> port série RX
L’ouverture et la fermeture du port qui doit prendre un ’certain temps’ en comparaison des octets transmis, semble faire décrocher le couple émetteur/récepteur ce qui génère quelques caractères inutilisables en début de chaîne.
Dans quelques cas, le port série n’arrive pas du tout à se synchroniser sur la trame reçue et fournit une chaîne non exploitable. Dans les autres cas, on retrouve bien notre ’Hello world’ précédé d’espaces.
Conclusion
L’atelier s’est révélé positif, nous permettant de commander une LED et d’envoyer des octets par port série. Nous avons pu déterminer certaines limitations du couple émetteur/récepteur qui ne sont pas documentées. En revanche, nous nous retrouvons en face d’un aléas (le décrochage) que nous ne comprenons pas encore.
Dès lors que nous comprendrons la raison de ce décrochage, nous pourrons envisager une solution permettant de l’éviter. Une autre solution étant de contourner le problème en émettant plusieurs trames avec un code de vérification permettant
d’être sûr de l’intégrité de la réception (l’émission de plusieurs trames permettant d’espérer une trame valide parmi celle émises).
Nous pourrons étudier ceci lors d’un prochain atelier. D’autre part, nous sommes intéressés par l’avis des personnes ayant de bonnes connaissances en radio. Elles pourrons sûrement nous expliquer le problème et nous permettre d’avancer plus rapidement.
Réponses
Patrick nous a éclairé sur les phénomènes observés, et propose une solution, le code Manchester.
En fait ces émetteurs ne peuvent pas transmettre des états, si l’entrée reste à 1 trop longtemps, la sortie va se mettre à osciller. Dans l’expérience le ’A’ passe bien parce que le ’A’ est 0x41 en hexa, il n’y a que deux bits à 1 et ils sont bien séparés par des 0, la transmission du ’A’ est donc la transmission de deux impulsions ce que ce genre de transmetteur fait bien. Dans le cas d’autres octets, s’il y a des successions de 1 le résultat sera aléatoire. L’état prolongé à 1 entraînera peut-être des oscillations.
Pour éviter ça il faut que les 0 et 1 soient transmis sous forme de transition et pas sous forme d’état, le plus classique est d’utiliser le code Manchester,
voir http://fr.wikipedia.org/wiki/Codage....Pour envoyer une série d’octets il faut donc les encoder au départ et les décoder à l’arrivée pour rendre la transmission fiable.
Vos commentaires
# Le 31 octobre 2016 à 18:30, par Elie Campagnolo En réponse à : Communications sans-fil RF 433MHz
Bonsoir,
J’ai fait un montage équivalent avec deux Arduino Uno (un en emission et l’autre en réception) et j’ai utilisé un analyseur logique pour visualiser ce qui est émis et reçu à partir d’une boucle sur Tx de l’UART réglé comme vous à 1200 bauds. La boucle est un compteur qui balaye de 0 à 255, en plus il ya un délai entre l’émission de chaque code. J’ai vérifié que le code émis suit bien l’évolution du compteur de 0 à 255. En réception lorsque le délai entre chaque trame est inférieur à 50 ms tout ce passe bien, on récupère les bons code.Tout se dégrade lorsqu’on augment le délai, on récupère des codes aléatoires, même chose lorsque l’on coupe l’émetteur on retrouve des codes jamais émis. L’explication est à chercher du côté du récepteur, je crois avoir lu quelque part que ce type de récepteur possède un contrôle automatique de gain, donc lorsqu’il n’y a pas d’émission, le gain est au maximum, on récupère donc du bruit (la bande 433MHz est très occupée), lorsqu’on émet à haute cadence (1/50ms) le récepteur ajuste son gain et tout ce passe bien, manifestement à plus faible cadence le récepteur n’arrive pas à ajuster le gain.
Cordialement
Répondre à ce message